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

1. บทนำ

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

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

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

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

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

ด้วยเหตุนี้ โครงการโอเพนซอร์ส Android จึงเป็นทั้งการอ้างอิงและการใช้งาน Android ที่แนะนำ เราขอแนะนำอย่างยิ่งให้ผู้ติดตั้งใช้งานอุปกรณ์ใช้ซอร์สโค้ด "ต้นทาง" ที่มีอยู่ในโครงการโอเพนซอร์ส Android เป็นพื้นฐานในการติดตั้งใช้งานให้มากที่สุด แม้ว่าในทางทฤษฎีแล้วจะสามารถแทนที่คอมโพเนนต์บางอย่างด้วยการติดตั้งใช้งานอื่นได้ แต่เราขอแนะนำอย่างยิ่งว่าอย่าทำตามแนวทางนี้ เนื่องจากจะทำให้การผ่านการทดสอบซอฟต์แวร์ยากขึ้นอย่างมาก ผู้ติดตั้งใช้งานมีหน้าที่รับผิดชอบในการตรวจสอบว่าการทำงานของ SDK เป็นไปตามการติดตั้งใช้งาน 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
  • แท็บ: การติดตั้งใช้งานแท็บเล็ต Android
• รหัสสภาพ
  • เมื่อข้อกำหนดไม่มีเงื่อนไข ระบบจะตั้งค่ารหัสนี้เป็น 0
  • เมื่อข้อกำหนดเป็นแบบมีเงื่อนไข ระบบจะกำหนดหมายเลข 1 ให้กับเงื่อนไขแรก และเพิ่มหมายเลขขึ้นทีละ 1 ภายในส่วนเดียวกันและประเภทอุปกรณ์เดียวกัน
• รหัสข้อกำหนด
  • รหัสนี้จะเริ่มต้นจาก 1 และเพิ่มขึ้นทีละ 1 ภายในส่วนเดียวกันและเงื่อนไขเดียวกัน

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.2.1. ฮาร์ดแวร์

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• [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 และมีบทบาทเป็น Sink() หากฟิลด์ประเภทเทอร์มินัลเสียง 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 และ role isSink() หากฟิลด์ประเภทเทอร์มินัลเสียง USB คือ 0x400

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

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

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

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

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

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

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

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

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

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

• [7.10/H-SR]* ขอแนะนำอย่างยิ่งให้ทำการประเมินคุณภาพสำหรับค่าคงที่ของแฮปติก

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

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

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

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

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

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

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

2.2.3. ซอฟต์แวร์

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.2.7 Handheld Media Performance Class

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

2.2.7.1. สื่อ

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

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

2.2.7.2. กล้อง

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

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

2.2.7.3. ฮาร์ดแวร์

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

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

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

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

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

2.3 ข้อกำหนดเกี่ยวกับทีวี

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

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

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

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

2.3.1. ฮาร์ดแวร์

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.3.3. ซอฟต์แวร์

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 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] ขอแนะนำอย่างยิ่งให้รวมตัววัดความเร่งแบบ 3 แกน

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

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

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

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

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

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

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

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

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

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

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

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

2.4.3. ซอฟต์แวร์

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.5.1. ฮาร์ดแวร์

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

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

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

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

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

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

• [7.3.1/A-1-1] ต้องรายงานเหตุการณ์ได้ด้วยความถี่อย่างน้อย 100 Hz
• [7.3.1/A-1-2] ต้องเป็นไปตามระบบพิกัดเซ็นเซอร์รถยนต์ของ Android

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.5.3. ซอฟต์แวร์

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 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. ฮาร์ดแวร์

ขนาดหน้าจอ

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

Gyroscope

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

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

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

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

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

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

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

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

ประสิทธิภาพสูงของเทคโนโลยีความจริงเสมือน (Virtual Reality) (ส่วนที่ 7.9.2)

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

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

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

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

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

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

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

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

2.6.2. ซอฟต์แวร์

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

3. ซอฟต์แวร์

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

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

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

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

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

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

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

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

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

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

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

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

3.1.1. ส่วนขยาย Android

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

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

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

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

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

3.1.2. ไลบรารี Android

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

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

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

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

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

3.2.1. สิทธิ์

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

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

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

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

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

3.2.3.1. Intent การสมัครที่พบบ่อย

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

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

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

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

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

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

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

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

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

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

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

3.2.3.3. เนมสเปซของความตั้งใจ

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

3.2.3.4. Broadcast Intents

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

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

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

3.2.3.5. ความตั้งใจในการสมัครแบบมีเงื่อนไข

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• [C-12-1] ต้องปฏิบัติตามเจตนาของ android.media.action.STILL_IMAGE_CAMERA และ android.media.action.STILL_IMAGE_CAMERA_SECURE รวมถึงเปิดกล้องในโหมดภาพนิ่งตามที่อธิบายไว้ใน SDK
• [C-12-2] ต้องปฏิบัติตามเจตนาในการเปิดกล้องในโหมดวิดีโอตามที่อธิบายไว้ใน SDK android.media.action.VIDEO_CAMERA
• [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.ADMIN_POLICY_COMPLIANCE, android.app.action.GET_PROVISIONING_MODE, android.app.action.PROVISIONING_SUCCESSFUL, android.app.action.PROVISION_MANAGED_DEVICE, 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 ที่นี่

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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] ต้องรายงานอินเทอร์เฟซแบบไบนารีของแอปพลิเคชัน (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 รวมถึงส่วนขยาย VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain, VK_KHR_maintenance1 และ VK_KHR_get_physical_device_properties2 ผ่านไลบรารี libvulkan.so โปรดทราบว่าแม้ว่าสัญลักษณ์ทั้งหมดจะต้องมีอยู่ แต่ส่วน 7.1.4.2 จะอธิบายรายละเอียดเพิ่มเติมเกี่ยวกับข้อกำหนดในกรณีที่คาดว่าจะมีการใช้งานฟังก์ชันที่เกี่ยวข้องแต่ละรายการอย่างเต็มรูปแบบ
• ควรสร้างโดยใช้ซอร์สโค้ดและไฟล์ส่วนหัวที่มีอยู่ในโปรเจ็กต์โอเพนซอร์สของ Android ต้นทาง

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

กล่าวคือ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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()

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

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

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

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

3.8.2. วิดเจ็ต

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

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

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

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

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

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

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

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] ต้องระบุลักษณะการทำงานทั้งหมดของ API NotificationChannel ที่ระบุไว้ใน SDK
• [C-1-5] ต้องมีตัวเลือกให้ผู้ใช้บล็อกและแก้ไขการแจ้งเตือนของแอปของบุคคลที่สามบางแอปในแต่ละช่องทางและระดับแพ็กเกจแอป
• [C-1-6] ต้องมีส่วนอำนวยความสะดวกให้ผู้ใช้แสดงช่องทางการแจ้งเตือนที่ถูกลบด้วย
• [C-1-7] ต้องแสดงผลทรัพยากรทั้งหมด (รูปภาพ สติกเกอร์ ไอคอน ฯลฯ) ที่ระบุผ่าน Notification.MessagingStyle อย่างถูกต้องควบคู่ไปกับข้อความการแจ้งเตือนโดยไม่ต้องมีการโต้ตอบเพิ่มเติมจากผู้ใช้ เช่น ต้องแสดงทรัพยากรทั้งหมด รวมถึงไอคอนที่ระบุผ่าน android.app.Person ในการสนทนากลุ่มที่ตั้งค่าผ่าน setGroupConversation
• [C-SR] ขอแนะนำอย่างยิ่งให้แสดงความสามารถของผู้ใช้โดยอัตโนมัติเพื่อบล็อกการแจ้งเตือนของแอปของบุคคลที่สามบางแอปในแต่ละช่องทางและระดับแพ็กเกจแอปหลังจากที่ผู้ใช้ปิดการแจ้งเตือนนั้นหลายครั้ง
• ควรรองรับการแจ้งเตือนสมบูรณ์
• ควรแสดงการแจ้งเตือนที่มีลำดับความสำคัญสูงกว่าเป็นการแจ้งเตือนล่วงหน้า
• ควรมีตัวเลือกให้ผู้ใช้เลื่อนการแจ้งเตือน
• MAY จะจัดการเฉพาะระดับการมองเห็นและเวลาที่แอปของบุคคลที่สามจะแจ้งเตือนผู้ใช้เกี่ยวกับเหตุการณ์สำคัญเพื่อลดปัญหาด้านความปลอดภัย เช่น การที่ผู้ขับขี่เสียสมาธิ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.8.3.3. DND (ห้ามรบกวน)

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

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

3.8.4. ค้นหา

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.8.6. ธีม

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.8.11. ภาพพักหน้าจอ (เดิมชื่อดรีม)

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

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
• ควรรองรับอีโมจิสีผิวและอีโมจิครอบครัวที่หลากหลายตามที่ระบุไว้ในรายงานทางเทคนิคของ Unicode #51

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.8.15. คัตเอาท์ดิสเพลย์

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.14. UI ของสื่อ

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

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

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

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

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

3.15. Instant Apps

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

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

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

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

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

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

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

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

3.17. แอปที่มีน้ำหนักมาก

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• [C-2-2] ตัวแปลงรหัสวิดีโอที่มีลักษณะเป็นการเร่งฮาร์ดแวร์ต้องเผยแพร่ข้อมูลจุดประสิทธิภาพ โดยแต่ละรายการต้องแสดงจุดวัดประสิทธิภาพมาตรฐานที่รองรับทั้งหมด (แสดงใน PerformancePoint API) เว้นแต่จะครอบคลุมโดยจุดวัดประสิทธิภาพมาตรฐานอื่นๆ ที่รองรับ
• นอกจากนี้ ครีเอเตอร์ควรเผยแพร่จุดประสิทธิภาพเพิ่มเติมหากรองรับประสิทธิภาพของวิดีโอที่ยั่งยืนนอกเหนือจากจุดประสิทธิภาพมาตรฐานที่ระบุไว้

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

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

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

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

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

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

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

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

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

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

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

5.2.1. H.263

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

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

5.2.2. H.264

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

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

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

• [C-2-1] ต้องรองรับโปรไฟล์การเข้ารหัสในตารางต่อไปนี้

5.2.3. VP8

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

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

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

• [C-2-1] ต้องรองรับโปรไฟล์การเข้ารหัสในตารางต่อไปนี้

5.2.4. VP9

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

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

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

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

5.2.5. H.265

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

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

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] ต้องรองรับ Main Profile High Level

5.3.2. H.263

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

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

5.3.3. MPEG-4

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

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

5.3.4. H.264

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

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

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

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

5.3.5. H.265 (HEVC)

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

• [C-1-1] ต้องรองรับโปรไฟล์หลัก ระดับ 3 ระดับหลัก และโปรไฟล์การถอดรหัสวิดีโอ SD ตามที่ระบุไว้ในตารางต่อไปนี้
• ควรสนับสนุนโปรไฟล์การถอดรหัส HD ตามที่ระบุไว้ในตารางต่อไปนี้
• [C-1-2] ต้องรองรับโปรไฟล์การถอดรหัส HD ตามที่ระบุไว้ในตารางต่อไปนี้หากมีตัวถอดรหัสฮาร์ดแวร์

หากความสูงที่รายงานโดยเมธอด Display.getSupportedModes() เท่ากับหรือมากกว่าความละเอียดของวิดีโอ ให้ทำดังนี้

• [C-2-1] การใช้งานอุปกรณ์ต้องรองรับการถอดรหัส H.265 หรือ VP9 อย่างน้อย 1 รายการของโปรไฟล์ 720, 1080 และ UHD

หากการติดตั้งใช้งานอุปกรณ์อ้างว่ารองรับโปรไฟล์ 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 ในตารางต่อไปนี้

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

หากการติดตั้งใช้งานอุปกรณ์อ้างว่ารองรับ VP9Profile2 หรือ VP9Profile3 ผ่าน API สื่อ 'CodecProfileLevel' ให้ทำดังนี้

• การรองรับรูปแบบ 12 บิตเป็นแบบไม่บังคับ

หากการใช้งานอุปกรณ์อ้างว่ารองรับโปรไฟล์ HDR (VP9Profile2HDR, VP9Profile2HDR10Plus, VP9Profile3HDR, VP9Profile3HDR10Plus) ผ่าน Media API

• [C-4-1] การใช้งานอุปกรณ์ต้องยอมรับข้อมูลเมตา HDR ที่จำเป็น (KEY_HDR_STATIC_INFO สำหรับโปรไฟล์ HDR ทั้งหมด รวมถึง 'KEY_HDR10_PLUS_INFO' สำหรับโปรไฟล์ HDR10Plus) จากแอปพลิเคชัน นอกจากนี้ยังต้องรองรับการแยกและเอาต์พุตข้อมูลเมตา HDR ที่จำเป็นจากบิตสตรีมและ/หรือคอนเทนเนอร์ด้วย
• [C-4-2] การใช้งานอุปกรณ์ต้องแสดงเนื้อหา HDR บนหน้าจออุปกรณ์หรือบนพอร์ตเอาต์พุตวิดีโอมาตรฐาน (เช่น HDMI) อย่างถูกต้อง

5.3.8. Dolby Vision

หากการใช้งานอุปกรณ์ประกาศการรองรับตัวถอดรหัส Dolby Vision ผ่าน HDR_TYPE_DOLBY_VISION จะมีข้อกำหนดดังนี้

• [C-1-1] ต้องมีตัวแยกที่รองรับ Dolby Vision
• [C-1-2] ต้องแสดงเนื้อหา Dolby Vision บนหน้าจออุปกรณ์หรือบนพอร์ตเอาต์พุตวิดีโอมาตรฐาน (เช่น HDMI) อย่างถูกต้อง
• [C-1-3] ต้องตั้งค่าดัชนีแทร็กของเลเยอร์ฐานที่เข้ากันได้แบบย้อนหลัง (หากมี) ให้เหมือนกับดัชนีแทร็กของเลเยอร์ Dolby Vision ที่รวมกัน

5.3.9. AV1

หากการติดตั้งใช้งานอุปกรณ์รองรับตัวแปลงรหัส AV1 อุปกรณ์จะทำสิ่งต่อไปนี้

• [C-1-1] ต้องรองรับโปรไฟล์ 0 รวมถึงเนื้อหา 10 บิต

5.4. การบันทึกเสียง

แม้ว่าข้อกำหนดบางอย่างที่ระบุไว้ในส่วนนี้จะแสดงเป็น "ควร" ตั้งแต่ Android 4.3 แต่เราวางแผนที่จะเปลี่ยนข้อกำหนดเหล่านี้เป็น "ต้อง" ในคำจำกัดความความเข้ากันได้สำหรับเวอร์ชันในอนาคต ขอแนะนำเป็นอย่างยิ่งให้อุปกรณ์ Android ทั้งที่มีอยู่และใหม่เป็นไปตามข้อกำหนดเหล่านี้ที่ระบุเป็น "ควร" มิฉะนั้นอุปกรณ์จะไม่สามารถบรรลุความเข้ากันได้ของ Android เมื่ออัปเกรดเป็นเวอร์ชันในอนาคต

5.4.1. การบันทึกเสียงดิบและข้อมูลไมโครโฟน

หากการติดตั้งใช้งานอุปกรณ์ประกาศ android.hardware.microphone จะมีข้อกำหนดดังนี้

• [C-1-1] ต้องอนุญาตให้บันทึกเนื้อหาเสียงดิบที่มีลักษณะต่อไปนี้

  • รูปแบบ: Linear PCM, 16 บิต
  • อัตราการสุ่มตัวอย่าง: 8000, 11025, 16000, 44100, 48000 Hz
  • ช่อง: โมโน

• ควรอนุญาตให้บันทึกเนื้อหาเสียงดิบที่มีลักษณะต่อไปนี้

  • รูปแบบ: Linear PCM, 16 บิต และ 24 บิต
  • อัตราการสุ่มตัวอย่าง: 8000, 11025, 16000, 22050, 24000, 32000, 44100, 48000 Hz
  • ช่อง: จำนวนช่องเท่ากับจำนวนไมโครโฟนในอุปกรณ์

• [C-1-2] ต้องบันทึกที่อัตราการสุ่มตัวอย่างข้างต้นโดยไม่มีการอัปแซมปลิง

• [C-1-3] ต้องมีตัวกรองป้องกันรอยหยักที่เหมาะสมเมื่อบันทึกอัตราการสุ่มตัวอย่างที่ระบุไว้ข้างต้นด้วยการลดอัตราการสุ่มตัวอย่าง

• ควรอนุญาตให้มีการบันทึกเนื้อหาเสียงดิบในคุณภาพวิทยุ AM และ DVD ซึ่งหมายถึงลักษณะต่อไปนี้

  • รูปแบบ: Linear PCM, 16 บิต
  • อัตราการสุ่มตัวอย่าง: 22050, 48000 Hz
  • ช่อง: สเตอริโอ
  • [C-1-4] ต้องปฏิบัติตาม API ของ MicrophoneInfo และกรอกข้อมูลอย่างถูกต้องสำหรับไมโครโฟนที่พร้อมใช้งานในอุปกรณ์ซึ่งแอปพลิเคชันของบุคคลที่สามเข้าถึงได้ผ่าน API ของ AudioManager.getMicrophones() รวมถึงไมโครโฟนที่ใช้งานอยู่ในปัจจุบันซึ่งแอปพลิเคชันของบุคคลที่สามเข้าถึงได้ผ่าน API ของ AudioRecord.getActiveMicrophones() และ MediaRecorder.getActiveMicrophones() หากการติดตั้งใช้งานอุปกรณ์อนุญาตให้จับภาพเนื้อหาเสียงดิบในคุณภาพวิทยุ AM และ DVD จะต้องมีลักษณะดังนี้

• [C-2-1] ต้องบันทึกโดยไม่มีการอัปแซมปลิงที่อัตราส่วนใดๆ ที่สูงกว่า 16000:22050 หรือ 44100:48000

• [C-2-2] ต้องมีตัวกรองป้องกันรอยหยักที่เหมาะสมสำหรับการอัปแซมปลิงหรือดาวน์แซมปลิง

5.4.2. บันทึกเสียงเพื่อการจดจำเสียงพูด

หากการติดตั้งใช้งานอุปกรณ์ประกาศ android.hardware.microphone จะมีข้อกำหนดดังนี้

• [C-1-1] ต้องบันทึกแหล่งที่มาของเสียง android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION ที่อัตราการสุ่มตัวอย่าง 44100 และ 48000
• [C-1-2] ต้องปิดใช้การประมวลผลเสียงเพื่อลดเสียงรบกวนโดยค่าเริ่มต้นเมื่อบันทึกสตรีมเสียงจากAudioSource.VOICE_RECOGNITIONแหล่งเสียง
• [C-1-3] ต้องปิดใช้การควบคุมอัตราขยายเสียงโดยอัตโนมัติโดยค่าเริ่มต้นเมื่อบันทึกสตรีมเสียงจากAudioSource.VOICE_RECOGNITIONแหล่งเสียง
• ควรบันทึกสตรีมเสียงการจดจำเสียงที่มีลักษณะแอมพลิจูดเทียบกับความถี่ที่ค่อนข้างคงที่ กล่าวคือ ±3 dB จาก 100 Hz ถึง 4000 Hz
• ควรบันทึกสตรีมเสียงการจดจำเสียงพูดโดยตั้งค่าความไวของอินพุตเพื่อให้แหล่งที่มาของระดับกำลังเสียง (SPL) 90 dB ที่ 1000 Hz ให้ค่า RMS เป็น 2500 สำหรับตัวอย่าง 16 บิต
• ควรบันทึกสตรีมเสียงการจดจำเสียงเพื่อให้ระดับแอมพลิจูด PCM ติดตามการเปลี่ยนแปลง SPL ของอินพุตแบบเชิงเส้นในช่วงอย่างน้อย 30 เดซิเบลจาก -18 เดซิเบลถึง +12 เดซิเบลเทียบกับ 90 เดซิเบล SPL ที่ไมโครโฟน
• ควรบันทึกสตรีมเสียงการจดจำเสียงที่มีค่าความเพี้ยนฮาร์มอนิกทั้งหมด (THD) น้อยกว่า 1% สำหรับ 1 kHz ที่ระดับอินพุต 90 dB SPL ที่ไมโครโฟน

หากการใช้งานอุปกรณ์ประกาศ android.hardware.microphone และเทคโนโลยีการตัดเสียงรบกวนที่ปรับแต่งสำหรับการจดจำคำพูด อุปกรณ์จะทำสิ่งต่อไปนี้

• [C-2-1] ต้องอนุญาตให้ควบคุมเอฟเฟกต์เสียงนี้ได้ด้วย android.media.audiofx.NoiseSuppressor API
• [C-2-2] ต้องระบุการติดตั้งใช้งานเทคโนโลยีการตัดเสียงรบกวนแต่ละรายการโดยไม่ซ้ำกันผ่านฟิลด์ AudioEffect.Descriptor.uuid

5.4.3. การจับภาพเพื่อเปลี่ยนเส้นทางการเล่น

คลาส android.media.MediaRecorder.AudioSource มีแหล่งเสียง REMOTE_SUBMIX

หากการติดตั้งใช้งานอุปกรณ์ประกาศทั้ง android.hardware.audio.output และ android.hardware.microphone อุปกรณ์จะทำสิ่งต่อไปนี้

• [C-1-1] ต้องใช้REMOTE_SUBMIXแหล่งที่มาของเสียงอย่างถูกต้องเพื่อให้เมื่อแอปพลิเคชันใช้ API android.media.AudioRecord เพื่อบันทึกจากแหล่งที่มาของเสียงนี้ แอปพลิเคชันจะบันทึกสตรีมเสียงทั้งหมดรวมกัน ยกเว้นสตรีมเสียงต่อไปนี้

  • AudioManager.STREAM_RING
  • AudioManager.STREAM_ALARM
  • AudioManager.STREAM_NOTIFICATION

5.4.4. การตัดเสียงก้อง

หากการติดตั้งใช้งานอุปกรณ์ประกาศ android.hardware.microphone จะมีข้อกำหนดดังนี้

• ควรใช้เทคโนโลยีตัวตัดเสียงก้อง (AEC) ที่ปรับแต่งมาเพื่อการสื่อสารด้วยเสียงและใช้กับเส้นทางการจับภาพเมื่อจับภาพโดยใช้ AudioSource.VOICE_COMMUNICATION

หากการติดตั้งใช้งานอุปกรณ์มีตัวตัดเสียงก้องที่แทรกอยู่ในเส้นทางการบันทึกเสียงเมื่อเลือก AudioSource.VOICE_COMMUNICATION จะมีลักษณะดังนี้

• [C-SR] ขอแนะนำให้ประกาศผ่านเมธอด AcousticEchoCanceler API AcousticEchoCanceler.isAvailable()
• [C-SR] ขอแนะนำเป็นอย่างยิ่งให้เปิดใช้เอฟเฟกต์เสียงนี้เพื่อให้ควบคุมได้ด้วย AcousticEchoCanceler API
• [C-SR] ขอแนะนำเป็นอย่างยิ่งให้ระบุการติดตั้งใช้งานเทคโนโลยี AEC แต่ละรายการโดยไม่ซ้ำกันผ่านฟิลด์ AudioEffect.Descriptor.uuid

5.4.5. การจับภาพพร้อมกัน

หากการใช้งานอุปกรณ์ประกาศ android.hardware.microphone จะต้องใช้การจับภาพพร้อมกันตามที่อธิบายไว้ในเอกสารนี้ ดังนี้

• [C-1-1] ต้องอนุญาตให้บริการการช่วยเหลือพิเศษเข้าถึงไมโครโฟนพร้อมกันได้โดยการบันทึกด้วย AudioSource.VOICE_RECOGNITION และแอปพลิเคชันอย่างน้อย 1 รายการที่บันทึกด้วย AudioSource
• [C-1-2] ต้องอนุญาตให้แอปพลิเคชันที่ติดตั้งไว้ล่วงหน้าซึ่งมีบทบาทเป็น Assistant และแอปพลิเคชันอย่างน้อย 1 รายการที่บันทึกด้วย AudioSource ใดก็ได้ยกเว้น AudioSource.VOICE_COMMUNICATION หรือ AudioSource.CAMCORDER เข้าถึงไมโครโฟนพร้อมกันได้
• [C-1-3] ต้องปิดเสียงที่บันทึกสำหรับแอปพลิเคชันอื่นๆ ทั้งหมด ยกเว้นบริการการช่วยเหลือพิเศษ ขณะที่แอปพลิเคชันกำลังบันทึกด้วย AudioSource.VOICE_COMMUNICATION หรือ AudioSource.CAMCORDER อย่างไรก็ตาม เมื่อแอปบันทึกผ่าน AudioSource.VOICE_COMMUNICATION แอปอื่นจะบันทึกการโทรด้วยเสียงได้หากเป็นแอปที่มีสิทธิ์ (ติดตั้งไว้ล่วงหน้า) ที่มีสิทธิ์ CAPTURE_AUDIO_OUTPUT
• [C-1-4] หากมีแอปพลิเคชัน 2 รายการขึ้นไปที่บันทึกพร้อมกัน และไม่มีแอปใดมี UI อยู่ด้านบน แอปที่เริ่มบันทึกล่าสุดจะได้รับเสียง

5.4.6. ระดับเกนของไมโครโฟน

หากการติดตั้งใช้งานอุปกรณ์ประกาศ android.hardware.microphone จะมีข้อกำหนดดังนี้

• ควรแสดงลักษณะแอมพลิจูดเทียบกับความถี่ที่ค่อนข้างคงที่ในช่วงความถี่กลาง กล่าวคือ ±3dB จาก 100 Hz ถึง 4000 Hz สำหรับไมโครโฟนทุกตัวที่ใช้บันทึกแหล่งเสียงสำหรับการจดจำเสียงพูด
• ควรตั้งค่าความไวของอินพุตเสียงเพื่อให้แหล่งกำเนิดเสียงโทนไซนูโซดัล 1000 Hz ที่เล่นที่ระดับความดันเสียง (SPL) 90 dB ให้ผลลัพธ์ที่มี RMS เท่ากับ 2500 สำหรับตัวอย่าง 16 บิต (หรือ -22.35 dB Full Scale สำหรับตัวอย่างแบบจุดลอย/ความแม่นยำแบบคู่) สำหรับไมโครโฟนทุกตัวที่ใช้บันทึกแหล่งกำเนิดเสียงสำหรับการจดจำเสียง
• [C-SR] ขอแนะนำอย่างยิ่งให้แสดงระดับแอมพลิจูดในช่วงความถี่ต่ำ โดยเฉพาะอย่างยิ่งจาก ±20 dB ตั้งแต่ 5 Hz ถึง 100 Hz เมื่อเทียบกับช่วงความถี่กลางสำหรับไมโครโฟนทุกตัวที่ใช้บันทึกแหล่งเสียงสำหรับการจดจำเสียง
• [C-SR] ขอแนะนำอย่างยิ่งให้แสดงระดับแอมพลิจูดในช่วงความถี่สูง โดยเฉพาะอย่างยิ่งจาก ±30 dB จาก 4000 Hz ถึง 22 KHz เมื่อเทียบกับช่วงความถี่กลางสำหรับไมโครโฟนทุกตัวที่ใช้บันทึกแหล่งเสียงสำหรับการจดจำเสียง

5.5 การเล่นเสียง

Android มีการรองรับเพื่อให้แอปเล่นเสียงผ่านอุปกรณ์ต่อพ่วงเอาต์พุตเสียงได้ตามที่กำหนดไว้ในส่วน 7.8.2

5.5.1. การเล่นเสียงดิบ

หากการติดตั้งใช้งานอุปกรณ์ประกาศ android.hardware.audio.output จะมีข้อกำหนดดังนี้

• [C-1-1] ต้องอนุญาตให้เล่นเนื้อหาเสียงดิบที่มีลักษณะต่อไปนี้

  • รูปแบบแหล่งที่มา: Linear PCM, 16 บิต, 8 บิต, ลอยตัว
  • ช่องสัญญาณ: โมโน สเตอริโอ การกำหนดค่าแบบหลายช่องสัญญาณที่ถูกต้องซึ่งมีช่องสัญญาณสูงสุด 8 ช่อง
  • อัตราการสุ่มตัวอย่าง (ในหน่วย Hz)
    • 8000, 11025, 16000, 22050, 32000, 44100, 48000 ที่การกำหนดค่าแชแนลที่ระบุไว้ข้างต้น
    • 96000 ในระบบเสียงแบบโมโนและสเตอริโอ

• ควรอนุญาตให้เล่นเนื้อหาเสียงดิบที่มีลักษณะต่อไปนี้

  • อัตราการสุ่มตัวอย่าง: 24000, 48000

5.5.2. เอฟเฟกต์เสียง

Android มี API สำหรับเอฟเฟกต์เสียงสำหรับการติดตั้งใช้งานอุปกรณ์

หากการติดตั้งใช้งานอุปกรณ์ประกาศฟีเจอร์ android.hardware.audio.output จะมีผลดังนี้

• [C-1-1] ต้องรองรับการใช้งาน EFFECT_TYPE_EQUALIZER และ EFFECT_TYPE_LOUDNESS_ENHANCER ที่ควบคุมได้ผ่านคลาสย่อย AudioEffect Equalizer และ LoudnessEnhancer
• [C-1-2] ต้องรองรับการใช้งาน Visualizer API ซึ่งควบคุมได้ผ่านคลาส Visualizer
• [C-1-3] ต้องรองรับการใช้งาน EFFECT_TYPE_DYNAMICS_PROCESSING ที่ควบคุมได้ผ่านคลาสย่อย AudioEffect DynamicsProcessing
• ควรรองรับการใช้งาน EFFECT_TYPE_BASS_BOOST, EFFECT_TYPE_ENV_REVERB, EFFECT_TYPE_PRESET_REVERB และ EFFECT_TYPE_VIRTUALIZER ที่ควบคุมได้ผ่านคลาสย่อย AudioEffect BassBoost, EnvironmentalReverb, PresetReverb และ Virtualizer
• [C-SR] ขอแนะนำอย่างยิ่งให้รองรับเอฟเฟกต์ในรูปแบบจุดลอยตัวและหลายช่อง

5.5.3. ระดับเสียงเอาต์พุต

การติดตั้งใช้งานอุปกรณ์ยานยนต์

• ควรอนุญาตให้ปรับระดับเสียงแยกกันสำหรับแต่ละสตรีมเสียงโดยใช้ประเภทเนื้อหาหรือการใช้งานตามที่กำหนดโดย AudioAttributes และการใช้งานเสียงในรถยนต์ตามที่กำหนดไว้แบบสาธารณะใน android.car.CarAudioManager

5.6 เวลาในการตอบสนองของเสียง

เวลาในการตอบสนองของเสียงคือความล่าช้าของเวลาเมื่อสัญญาณเสียงผ่านระบบ แอปพลิเคชันหลายประเภทต้องอาศัยเวลาในการตอบสนองที่สั้นเพื่อให้ได้เอฟเฟกต์เสียงแบบเรียลไทม์

สำหรับวัตถุประสงค์ของส่วนนี้ ให้ใช้คำจำกัดความต่อไปนี้

• เวลาในการตอบสนองของเอาต์พุต ช่วงเวลาระหว่างที่แอปพลิเคชันเขียนเฟรมของข้อมูลที่เข้ารหัส PCM กับเวลาที่เสียงที่เกี่ยวข้องแสดงต่อสภาพแวดล้อมที่ทรานสดิวเซอร์ในอุปกรณ์หรือสัญญาณออกจากอุปกรณ์ผ่านพอร์ตและสังเกตได้จากภายนอก
• เวลาในการตอบสนองของเอาต์พุตที่ไม่ได้แคช เวลาในการตอบสนองของเอาต์พุตสำหรับเฟรมแรก เมื่อระบบเอาต์พุตเสียงไม่ได้ใช้งานและปิดเครื่องก่อนคำขอ
• เวลาในการตอบสนองของเอาต์พุตอย่างต่อเนื่อง เวลาในการตอบสนองของเอาต์พุตสำหรับเฟรมถัดไปหลังจากที่อุปกรณ์เล่นเสียง
• เวลาในการตอบสนองต่อการป้อนข้อมูล ช่วงเวลาระหว่างที่สภาพแวดล้อมส่งเสียงไปยังอุปกรณ์ที่ทรานสดิวเซอร์ในอุปกรณ์หรือสัญญาณเข้าสู่อุปกรณ์ผ่านพอร์ต กับช่วงเวลาที่แอปพลิเคชันอ่านเฟรมที่เกี่ยวข้องของข้อมูลที่เข้ารหัส PCM
• อินพุตสูญหาย ส่วนเริ่มต้นของสัญญาณอินพุตที่ใช้ไม่ได้หรือไม่มี
• เวลาในการตอบสนองต่อการป้อนข้อมูลแบบเย็น ผลรวมของเวลาในการป้อนข้อมูลที่สูญหายและเวลาในการตอบสนองต่อการป้อนข้อมูลสำหรับเฟรมแรก เมื่อระบบป้อนข้อมูลเสียงไม่ได้ใช้งานและปิดเครื่องก่อนคำขอ
• เวลาในการตอบสนองต่อการป้อนข้อมูลอย่างต่อเนื่อง เวลาในการตอบสนองของอินพุตสำหรับเฟรมถัดไปขณะที่อุปกรณ์กำลังบันทึกเสียง
• ความกระตุกของเอาต์พุตขณะเย็น ความแปรปรวนในการวัดค่าเวลาในการตอบสนองของเอาต์พุตเย็นแยกกัน
• ความกระตุกของอินพุตเย็น ความแปรปรวนในการวัดค่าเวลาในการตอบสนองของอินพุตแบบเย็นแยกกัน
• เวลาในการตอบสนองแบบไปกลับอย่างต่อเนื่อง ผลรวมของเวลาในการตอบสนองของอินพุตอย่างต่อเนื่องบวกกับเวลาในการตอบสนองของเอาต์พุตอย่างต่อเนื่องบวกกับระยะเวลาบัฟเฟอร์ 1 ช่วง ระยะเวลาบัฟเฟอร์ช่วยให้แอปมีเวลาประมวลผลสัญญาณและมีเวลาลดความแตกต่างของเฟสระหว่างสตรีมอินพุตและเอาต์พุต
• OpenSL ES PCM คิวบัฟเฟอร์ API ชุด API ของ OpenSL ES ที่เกี่ยวข้องกับ PCM ภายใน Android NDK
• AAudio Native Audio API ชุด API ของ AAudio ภายใน Android NDK
• การประทับเวลา คู่ประกอบด้วยตำแหน่งเฟรมสัมพัทธ์ภายในสตรีมและเวลาโดยประมาณเมื่อเฟรมนั้นเข้าหรือออกจากไปป์ไลน์การประมวลผลเสียงในอุปกรณ์ปลายทางที่เชื่อมโยง ดูAudioTimestamp ด้วย
• ข้อบกพร่อง การหยุดชะงักชั่วคราวหรือค่าตัวอย่างที่ไม่ถูกต้องในสัญญาณเสียง ซึ่งมักเกิดจากบัฟเฟอร์ขาดสำหรับเอาต์พุต บัฟเฟอร์เกินสำหรับอินพุต หรือแหล่งที่มาอื่นๆ ของสัญญาณรบกวนแบบดิจิทัลหรืออนาล็อก

หากการใช้งานอุปกรณ์ประกาศ android.hardware.audio.output จะต้องเป็นไปตามหรือเกินกว่าข้อกำหนดต่อไปนี้

• [C-1-1] การประทับเวลาเอาต์พุตที่ส่งคืนโดย AudioTrack.getTimestamp และ AAudioStream_getTimestamp มีความแม่นยำ +/- 2 มิลลิวินาที
• [C-1-2] เวลาในการตอบสนองของเอาต์พุตเย็นไม่เกิน 500 มิลลิวินาที

หากการติดตั้งใช้งานอุปกรณ์ประกาศ android.hardware.audio.output เราขอแนะนำอย่างยิ่งให้เป็นไปตามหรือเกินกว่าข้อกำหนดต่อไปนี้

• [C-SR] เวลาในการตอบสนองเอาต์พุตแบบเย็นไม่เกิน 100 มิลลิวินาที เราขอแนะนำอย่างยิ่งให้อุปกรณ์ที่มีอยู่และอุปกรณ์ใหม่ที่ใช้ Android เวอร์ชันนี้เป็นไปตามข้อกำหนดเหล่านี้ในตอนนี้ ในการเปิดตัวแพลตฟอร์มในอนาคตในปี 2021 เราจะกำหนดให้เวลาในการตอบสนองของเอาต์พุตแบบ Cold ต้องไม่เกิน 200 มิลลิวินาที
• [C-SR] เวลาในการตอบสนองของเอาต์พุตอย่างต่อเนื่องไม่เกิน 45 มิลลิวินาที
• [C-SR] ลดความกระวนกระวายของเอาต์พุตที่ไม่ได้แคช
• [C-SR] การประทับเวลาเอาต์พุตที่ส่งคืนโดย AudioTrack.getTimestamp และ AAudioStream_getTimestamp มีความแม่นยำ +/- 1 มิลลิวินาที

หากการติดตั้งใช้งานอุปกรณ์เป็นไปตามข้อกำหนดข้างต้น หลังจากทำการปรับเทียบครั้งแรกแล้ว เมื่อใช้ทั้งคิวบัฟเฟอร์ PCM ของ OpenSL ES และ API เสียงดั้งเดิมของ AAudio สำหรับเวลาในการตอบสนองของเอาต์พุตแบบต่อเนื่องและเวลาในการตอบสนองของเอาต์พุตแบบเย็นในอุปกรณ์เอาต์พุตเสียงที่รองรับอย่างน้อย 1 เครื่อง เวลาในการตอบสนองดังกล่าวจะเป็นดังนี้

• [C-SR] ขอแนะนำอย่างยิ่งให้รายงานเสียงที่มีเวลาในการตอบสนองต่ำโดยประกาศแฟล็กฟีเจอร์ android.hardware.audio.low_latency
• [C-SR] ขอแนะนำอย่างยิ่งให้เป็นไปตามข้อกำหนดสำหรับเสียงที่มีเวลาในการตอบสนองต่ำผ่าน AAudio API
• [C-SR] ขอแนะนำอย่างยิ่งเพื่อให้มั่นใจว่าสำหรับสตรีมที่แสดงผล AAUDIO_PERFORMANCE_MODE_LOW_LATENCY จาก AAudioStream_getPerformanceMode() ค่าที่แสดงผลโดย AAudioStream_getFramesPerBurst() จะน้อยกว่าหรือเท่ากับค่าที่แสดงผลโดย android.media.AudioManager.getProperty(String) สำหรับคีย์พร็อพเพอร์ตี้ AudioManager.PROPERTY_OUTPUT_FRAMES_PER_BUFFER

หากการใช้งานอุปกรณ์ไม่เป็นไปตามข้อกำหนดสำหรับเสียงที่มีเวลาในการตอบสนองต่ำผ่านทั้งคิวบัฟเฟอร์ PCM ของ OpenSL ES และ API เสียงดั้งเดิมของ AAudio อุปกรณ์ดังกล่าวจะ

• [C-2-1] ต้องไม่รายงานการรองรับเสียงที่มีเวลาในการตอบสนองต่ำ

หากการใช้งานอุปกรณ์มี android.hardware.microphone อุปกรณ์ต้องเป็นไปตามข้อกำหนดด้านเสียงอินพุตต่อไปนี้

• [C-3-1] จำกัดข้อผิดพลาดในแสตมป์เวลาของอินพุตตามที่ AudioRecord.getTimestamp หรือ AAudioStream_getTimestamp แสดงผลเป็น +/- 2 มิลลิวินาที "ข้อผิดพลาด" ในที่นี้หมายถึงค่าเบี่ยงเบนจากค่าที่ถูกต้อง
• [C-3-2] เวลาในการตอบสนองของอินพุตแบบ Cold Start ไม่เกิน 500 มิลลิวินาที

หากการใช้งานอุปกรณ์มี android.hardware.microphone เราขอแนะนำอย่างยิ่งให้เป็นไปตามข้อกำหนดด้านเสียงอินพุตต่อไปนี้

• [C-SR] เวลาในการตอบสนองของอินพุตเย็นไม่เกิน 100 มิลลิวินาที เราขอแนะนำอย่างยิ่งให้อุปกรณ์ที่มีอยู่และอุปกรณ์ใหม่ที่ใช้ Android เวอร์ชันนี้เป็นไปตามข้อกำหนดเหล่านี้ในตอนนี้ ในการเปิดตัวแพลตฟอร์มในอนาคตในปี 2021 เราจะกำหนดให้เวลาในการตอบสนองอินพุตแบบเย็นต้องไม่เกิน 200 มิลลิวินาที
• [C-SR] เวลาในการตอบสนองของอินพุตอย่างต่อเนื่องไม่เกิน 30 มิลลิวินาที
• [C-SR] เวลาในการตอบสนองไป-กลับอย่างต่อเนื่องไม่เกิน 50 มิลลิวินาที
• [C-SR] ลดความกระตุกของอินพุตเย็น
• [C-SR] จำกัดข้อผิดพลาดในไทม์สแตมป์อินพุตตามที่ AudioRecord.getTimestamp หรือ AAudioStream_getTimestamp แสดงผลไว้เป็น +/- 1 มิลลิวินาที

5.7. โปรโตคอลเครือข่าย

การใช้งานอุปกรณ์ต้องรองรับโปรโตคอลเครือข่ายสื่อสำหรับการเล่นเสียงและวิดีโอตามที่ระบุไว้ในเอกสารประกอบ Android SDK

หากการใช้งานอุปกรณ์มีตัวถอดรหัสเสียงหรือวิดีโอ อุปกรณ์ดังกล่าวจะต้องมีคุณสมบัติดังนี้

• [C-1-1] ต้องรองรับตัวแปลงรหัสและรูปแบบคอนเทนเนอร์ที่จำเป็นทั้งหมดในส่วนที่ 5.1 ผ่าน HTTP(S)

• [C-1-2] ต้องรองรับรูปแบบกลุ่มสื่อที่แสดงในตารางรูปแบบกลุ่มสื่อด้านล่างผ่านร่างโปรโตคอล HTTP Live Streaming เวอร์ชัน 7

• [C-1-3] ต้องรองรับโปรไฟล์เสียงและวิดีโอ RTP และตัวแปลงรหัสที่เกี่ยวข้องในตาราง RTSP ด้านล่าง ดูข้อยกเว้นได้ที่เชิงอรรถของตารางในส่วนที่ 5.1

รูปแบบกลุ่มสื่อ

RTSP (RTP, SDP)

5.8. สื่อที่ปลอดภัย

หากการติดตั้งใช้งานอุปกรณ์รองรับเอาต์พุตวิดีโอที่ปลอดภัยและรองรับพื้นผิวที่ปลอดภัย อุปกรณ์จะดำเนินการต่อไปนี้

• [C-1-1] ต้องประกาศการรองรับ Display.FLAG_SECURE

หากการใช้งานอุปกรณ์ประกาศว่ารองรับ Display.FLAG_SECURE และรองรับโปรโตคอลการแสดงผลแบบไร้สาย อุปกรณ์ดังกล่าวจะดำเนินการต่อไปนี้

• [C-2-1] ต้องรักษาความปลอดภัยของลิงก์ด้วยกลไกที่แข็งแกร่งทางคริปโตกราฟี เช่น HDCP 2.x ขึ้นไปสำหรับจอแสดงผลที่เชื่อมต่อผ่านโปรโตคอลไร้สาย เช่น Miracast

หากการติดตั้งใช้งานอุปกรณ์ประกาศการรองรับ Display.FLAG_SECURE และรองรับจอแสดงผลภายนอกแบบมีสาย อุปกรณ์ดังกล่าวจะทำสิ่งต่อไปนี้

• [C-3-1] ต้องรองรับ HDCP 1.2 ขึ้นไปสำหรับจอแสดงผลภายนอกทั้งหมดที่เชื่อมต่อผ่านพอร์ตแบบใช้สายที่ผู้ใช้เข้าถึงได้

5.9. Musical Instrument Digital Interface (MIDI)

หากการติดตั้งใช้งานอุปกรณ์รายงานการรองรับฟีเจอร์ android.software.midi ผ่านคลาส android.content.pm.PackageManager อุปกรณ์จะทำสิ่งต่อไปนี้

• [C-1-1] ต้องรองรับ MIDI ผ่านการรับส่งฮาร์ดแวร์ที่รองรับ MIDI ทั้งหมด ซึ่งมีการเชื่อมต่อทั่วไปที่ไม่ใช่ MIDI โดยการรับส่งดังกล่าวต้องมีลักษณะดังนี้

  • โหมดโฮสต์ USB ส่วน 7.7
  • MIDI ผ่านบลูทูธ LE ที่ทำหน้าที่เป็นอุปกรณ์กลาง ส่วน 7.4.3

• [C-1-2] ต้องรองรับการส่งซอฟต์แวร์ MIDI ระหว่างแอป (อุปกรณ์ MIDI เสมือน)

• [C-1-3] ต้องมี libamidi.so (การรองรับ MIDI ดั้งเดิม)

• ควรรองรับโหมดอุปกรณ์ต่อพ่วง MIDI ผ่าน USB, ส่วน 7.7

5.10. เสียงระดับมืออาชีพ

หากการติดตั้งใช้งานอุปกรณ์รายงานการรองรับฟีเจอร์ android.hardware.audio.pro ผ่านคลาส android.content.pm.PackageManager อุปกรณ์จะต้องดำเนินการต่อไปนี้

• [C-1-1] ต้องรายงานการรองรับฟีเจอร์ android.hardware.audio.low_latency
• [C-1-2] ต้องมีเวลาในการตอบสนองของเสียงแบบไป-กลับอย่างต่อเนื่องตามที่กำหนดไว้ในส่วนที่ 5.6 เวลาในการตอบสนองของเสียง ต้องไม่เกิน 20 มิลลิวินาที และควรไม่เกิน 10 มิลลิวินาทีในเส้นทางที่รองรับอย่างน้อย 1 เส้นทาง
• [C-1-3] ต้องมีพอร์ต USB ที่รองรับโหมดโฮสต์ USB และโหมดอุปกรณ์ต่อพ่วง USB
• [C-1-4] ต้องรายงานการรองรับฟีเจอร์ android.software.midi
• [C-1-5] ต้องเป็นไปตามข้อกำหนดด้านเวลาในการตอบสนองและเสียง USB โดยใช้ทั้ง API คิวบัฟเฟอร์ PCM ของ OpenSL ES และเส้นทางอย่างน้อย 1 เส้นทางของ API AAudio native audio
• [SR] ขอแนะนำอย่างยิ่งให้ใช้ AAudio native audio API ผ่าน MMAP path เพื่อให้เป็นไปตามข้อกำหนดด้านเวลาในการตอบสนองและเสียง USB
• [C-1-6] ต้องมีเวลาในการตอบสนองของเอาต์พุตแบบเย็นไม่เกิน 200 มิลลิวินาที
• [C-1-7] ต้องมีเวลาในการตอบสนองเมื่อเริ่มทำงานครั้งแรกไม่เกิน 200 มิลลิวินาที
• [SR] ขอแนะนำอย่างยิ่งให้ใช้เพื่อรักษาประสิทธิภาพของ CPU ในระดับที่สม่ำเสมอขณะที่เสียงทำงานอยู่และภาระงานของ CPU เปลี่ยนแปลง โดยควรทดสอบโดยใช้แอป Android เวอร์ชันของรหัสคอมมิต SynthMark 09b13c6f49ea089f8c31e5d035f912cc405b7ab8 SynthMark ใช้ซินธิไซเซอร์ซอฟต์แวร์ที่ทำงานบนเฟรมเวิร์กเสียงจำลองซึ่งวัดประสิทธิภาพของระบบ คุณต้องเรียกใช้แอป SynthMark โดยใช้ตัวเลือก "การทดสอบอัตโนมัติ" และให้ได้ผลลัพธ์ต่อไปนี้
  • voicemark.90 >= 32 เสียง
  • latencymark.fixed.little <= 15 มิลลิวินาที
  • latencymark.dynamic.little <= 50 มิลลิวินาที

ดูคำอธิบายเกณฑ์มาตรฐานได้ในเอกสารประกอบของ SynthMark

• ควรลดความไม่ถูกต้องและการเลื่อนของนาฬิกาเสียงเมื่อเทียบกับเวลามาตรฐาน
• ควรลดการเลื่อนเวลาของนาฬิกาเสียงเมื่อเทียบกับ CPU CLOCK_MONOTONIC เมื่อทั้ง 2 อย่างทำงานอยู่
• ควรลดเวลาในการตอบสนองของเสียงผ่านทรานสดิวเซอร์ในอุปกรณ์
• ควรลดเวลาในการตอบสนองของเสียงผ่านเสียงดิจิทัล USB
• ควรบันทึกการวัดเวลาในการตอบสนองของเสียงในเอกสารผ่านทุกเส้นทาง
• ควรลดความกระวนกระวายในเวลาการเรียกกลับเมื่อบัฟเฟอร์เสียงเสร็จสมบูรณ์ เนื่องจากจะส่งผลต่อเปอร์เซ็นต์ที่ใช้ได้ของแบนด์วิดท์ CPU เต็มรูปแบบโดยการเรียกกลับ
• ควรไม่มีเสียงขัดข้องภายใต้การใช้งานปกติที่เวลาในการตอบสนองที่รายงาน
• ควรมีความแตกต่างของเวลาในการตอบสนองระหว่างช่องเป็น 0
• ควรลดเวลาในการตอบสนองของ MIDI ให้เหลือน้อยที่สุดในทุกการรับส่ง
• ควรลดความแปรปรวนของเวลาในการตอบสนองของ MIDI ภายใต้ภาระงาน (ความกระตุก) ในการรับส่งทั้งหมด
• ควรระบุการประทับเวลา MIDI ที่ถูกต้องในการรับส่งทั้งหมด
• ควรลดสัญญาณรบกวนของสัญญาณเสียงผ่านทรานสดิวเซอร์ในอุปกรณ์ ซึ่งรวมถึงช่วงเวลาหลังจาก Cold Start ทันที
• ควรให้ความแตกต่างของสัญญาณนาฬิกาเสียงเป็น 0 ระหว่างด้านอินพุตและเอาต์พุตของอุปกรณ์ปลายทางที่เกี่ยวข้อง เมื่อทั้ง 2 ด้านทำงานอยู่ ตัวอย่างของปลายทางที่เกี่ยวข้อง ได้แก่ ไมโครโฟนและลำโพงในอุปกรณ์ หรืออินพุตและเอาต์พุตแจ็คเสียง
• ควรจัดการการเรียกกลับเมื่อบัฟเฟอร์เสียงของอินพุตและเอาต์พุตของอุปกรณ์ปลายทางที่เกี่ยวข้องในเธรดเดียวกันเสร็จสมบูรณ์เมื่อทั้ง 2 อย่างทำงานอยู่ และเข้าสู่การเรียกกลับของเอาต์พุตทันทีหลังจากกลับจากการเรียกกลับของอินพุต หรือหากไม่สามารถจัดการการเรียกกลับในเธรดเดียวกัน ให้ป้อนการเรียกกลับเอาต์พุตหลังจากป้อนการเรียกกลับอินพุตไม่นาน เพื่อให้แอปพลิเคชันมีเวลาที่สอดคล้องกันของฝั่งอินพุตและเอาต์พุต
• ควรลดความแตกต่างของเฟสระหว่างการบัฟเฟอร์เสียง HAL สำหรับด้านอินพุตและเอาต์พุตของอุปกรณ์ปลายทางที่เกี่ยวข้อง
• ควรลดเวลาในการตอบสนองต่อการสัมผัส
• ควรลดความแปรปรวนของเวลาในการตอบสนองต่อการสัมผัสภายใต้ภาระงาน (ความกระตุก)
• ควรมีเวลาในการตอบสนองจากอินพุตการแตะไปยังเอาต์พุตเสียงน้อยกว่าหรือเท่ากับ 40 มิลลิวินาที

หากการติดตั้งใช้งานอุปกรณ์เป็นไปตามข้อกำหนดข้างต้นทั้งหมด อุปกรณ์จะทำสิ่งต่อไปนี้ได้

• [SR] ขอแนะนำอย่างยิ่งให้รายงานการรองรับฟีเจอร์ android.hardware.audio.pro ผ่านคลาส android.content.pm.PackageManager

หากการติดตั้งใช้งานอุปกรณ์มีช่องเสียบเสียง 3.5 มม. แบบ 4 คอนดักเตอร์ อุปกรณ์ดังกล่าวจะมีลักษณะดังนี้

• [C-2-1] ต้องมีเวลาในการตอบสนองไป-กลับของเสียงอย่างต่อเนื่องไม่เกิน 20 มิลลิวินาทีผ่านเส้นทางแจ็คเสียง
• [SR] ขอแนะนำอย่างยิ่งให้ปฏิบัติตามส่วนข้อกำหนดเฉพาะของอุปกรณ์เคลื่อนที่ (ช่องเสียบ) ของข้อกำหนดเฉพาะของชุดหูฟังเสียงแบบใช้สาย (v1.1)
• เวลาในการตอบสนองของเสียงไป-กลับอย่างต่อเนื่องควรเป็น 10 มิลลิวินาทีหรือน้อยกว่าผ่านเส้นทางช่องเสียบเสียง

หากการติดตั้งใช้งานอุปกรณ์ไม่มีช่องเสียบเสียง 3.5 มม. แบบ 4 คอนดักเตอร์และมีพอร์ต USB ที่รองรับโหมดโฮสต์ USB อุปกรณ์ดังกล่าวจะ

• [C-3-1] ต้องใช้คลาสเสียง USB
• [C-3-2] ต้องมีเวลาในการตอบสนองไป-กลับของเสียงอย่างต่อเนื่องไม่เกิน 20 มิลลิวินาทีผ่านพอร์ตโหมดโฮสต์ USB โดยใช้คลาสเสียง USB
• เวลาในการตอบสนองของเสียงแบบไป-กลับอย่างต่อเนื่องควรอยู่ที่ 10 มิลลิวินาทีหรือน้อยกว่านั้นผ่านพอร์ตโหมดโฮสต์ USB โดยใช้คลาสเสียง USB
• [C-SR] ขอแนะนำอย่างยิ่งให้รองรับ I/O พร้อมกันได้สูงสุด 8 ช่องต่อทิศทาง อัตราการสุ่มตัวอย่าง 96 kHz และความลึก 24 บิตหรือ 32 บิต เมื่อใช้กับอุปกรณ์ต่อพ่วงเสียง USB ที่รองรับข้อกำหนดเหล่านี้ด้วย

หากการติดตั้งใช้งานอุปกรณ์มีพอร์ต HDMI อุปกรณ์จะต้องมีคุณสมบัติดังนี้

• ควรรองรับเอาต์พุตในระบบสเตอริโอและ 8 ช่องที่ความลึก 20 บิตหรือ 24 บิต และ 192 kHz โดยไม่มีการสูญเสียความลึกของบิตหรือการสุ่มตัวอย่างใหม่ ในการกำหนดค่าอย่างน้อย 1 รายการ

5.11 จับภาพสำหรับรายการที่ยังไม่ได้ประมวลผล

Android รองรับการบันทึกเสียงที่ยังไม่ได้ประมวลผลผ่านแหล่งที่มาของเสียง android.media.MediaRecorder.AudioSource.UNPROCESSED ใน OpenSL ES คุณจะเข้าถึงได้ด้วยค่าที่กำหนดล่วงหน้าสำหรับการบันทึก SL_ANDROID_RECORDING_PRESET_UNPROCESSED

หากการติดตั้งใช้งานอุปกรณ์มีจุดประสงค์เพื่อรองรับแหล่งที่มาของเสียงที่ยังไม่ได้ประมวลผลและทำให้พร้อมใช้งานสำหรับแอปของบุคคลที่สาม อุปกรณ์ดังกล่าวจะต้องมีคุณสมบัติดังนี้

• [C-1-1] ต้องรายงานการรองรับผ่านพร็อพเพอร์ตี้ android.media.AudioManager PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED

• [C-1-2] ต้องแสดงลักษณะแอมพลิจูดเทียบกับความถี่ที่แบนราบโดยประมาณในช่วงความถี่กลาง กล่าวคือ ±10dB จาก 100 Hz ถึง 7000 Hz สำหรับไมโครโฟนทุกตัวที่ใช้บันทึกแหล่งเสียงที่ยังไม่ได้ประมวลผล

• [C-1-3] ต้องแสดงระดับแอมพลิจูดในช่วงความถี่ต่ำ โดยเฉพาะอย่างยิ่งจาก ±20 dB จาก 5 Hz ถึง 100 Hz เมื่อเทียบกับช่วงความถี่กลางสำหรับไมโครโฟนทุกตัวที่ใช้บันทึกแหล่งเสียงที่ยังไม่ได้ประมวลผล

• [C-1-4] ต้องแสดงระดับแอมพลิจูดในช่วงความถี่สูง กล่าวคือ ตั้งแต่ ±30 dB จาก 7000 Hz ถึง 22 KHz เมื่อเทียบกับช่วงความถี่กลางสำหรับไมโครโฟนทุกตัวที่ใช้บันทึกแหล่งเสียงที่ยังไม่ได้ประมวลผล

• [C-1-5] ต้องตั้งค่าความไวของอินพุตเสียงเพื่อให้แหล่งกำเนิดเสียงโทนไซนูโซดัล 1000 Hz ที่เล่นที่ระดับความดันเสียง (SPL) 94 dB ให้ผลลัพธ์ที่มี RMS 520 สำหรับตัวอย่าง 16 บิต (หรือ -36 dB Full Scale สำหรับตัวอย่างแบบจุดลอย/ความแม่นยำสองเท่า) สำหรับไมโครโฟนทุกตัวที่ใช้บันทึกแหล่งกำเนิดเสียงที่ยังไม่ได้ประมวลผล

• [C-1-6] ต้องมีอัตราส่วนสัญญาณต่อสัญญาณรบกวน (SNR) ที่ 60 dB ขึ้นไปสำหรับไมโครโฟนทุกตัวที่ใช้บันทึกแหล่งเสียงที่ยังไม่ได้ประมวลผล (ในขณะที่ SNR วัดเป็นความแตกต่างระหว่าง 94 dB SPL กับ SPL ที่เทียบเท่าของสัญญาณรบกวนในตัวเครื่อง ซึ่งถ่วงน้ำหนัก A)

• [C-1-7] ต้องมีค่าความเพี้ยนฮาร์มอนิกทั้งหมด (THD) น้อยกว่า 1% สำหรับ 1 kHz ที่ระดับอินพุต 90 dB SPL ในไมโครโฟนทุกตัวที่ใช้บันทึกแหล่งเสียงที่ยังไม่ได้ประมวลผล

• ต้องไม่มีการประมวลผลสัญญาณอื่นๆ (เช่น การควบคุมอัตราขยายอัตโนมัติ ตัวกรอง High Pass หรือการตัดเสียงก้อง) ในเส้นทางนอกเหนือจากตัวคูณระดับเพื่อนำระดับไปสู่ช่วงที่ต้องการ กล่าวคือ

• [C-1-8] หากมีการประมวลผลสัญญาณในสถาปัตยกรรมไม่ว่าด้วยเหตุผลใดก็ตาม จะต้องปิดใช้และไม่ทำให้เกิดความล่าช้าหรือเวลาในการตอบสนองเพิ่มเติมในเส้นทางสัญญาณ
• [C-1-9] ตัวคูณระดับ แม้ว่าจะอนุญาตให้ใช้ในเส้นทางได้ แต่ต้องไม่ทำให้เกิดความล่าช้าหรือเวลาในการตอบสนองในเส้นทางสัญญาณ

การวัด SPL ทั้งหมดจะดำเนินการข้างไมโครโฟนที่อยู่ระหว่างการทดสอบโดยตรง สำหรับการกำหนดค่าไมโครโฟนหลายรายการ ข้อกำหนดเหล่านี้จะมีผลกับไมโครโฟนแต่ละตัว

หากการติดตั้งใช้งานอุปกรณ์ประกาศ android.hardware.microphone แต่ไม่รองรับแหล่งที่มาของเสียงที่ไม่ได้ประมวลผล อุปกรณ์จะดำเนินการต่อไปนี้

• [C-2-1] ต้องแสดงผล null สำหรับAudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED)เมธอด API เพื่อระบุการไม่รองรับอย่างถูกต้อง
• [SR] ยังคงเป็นตัวเลือกที่แนะนำอย่างยิ่งเพื่อให้เป็นไปตามข้อกำหนดส่วนใหญ่สำหรับเส้นทางสัญญาณของแหล่งที่มาของการบันทึกที่ยังไม่ได้ประมวลผล

6. ความเข้ากันได้ของเครื่องมือและตัวเลือกสำหรับนักพัฒนาซอฟต์แวร์

6.1 เครื่องมือสำหรับนักพัฒนาซอฟต์แวร์

การติดตั้งใช้งานอุปกรณ์

• [C-0-1] ต้องรองรับเครื่องมือสำหรับนักพัฒนาแอป Android ที่มีให้ใน Android SDK

• Android Debug Bridge (adb)

  • [C-0-2] ต้องรองรับ adb ตามที่ระบุไว้ใน Android SDK และคำสั่งเชลล์ที่ระบุไว้ใน AOSP ซึ่งนักพัฒนาแอปสามารถใช้ได้ รวมถึง dumpsys cmd stats
  • [C-0-11] ต้องรองรับคำสั่ง Shell cmd testharness การอัปเกรดการใช้งานอุปกรณ์จาก Android เวอร์ชันก่อนหน้าโดยไม่มีบล็อกข้อมูลแบบถาวรอาจได้รับการยกเว้นจาก C-0-11
  • [C-0-3] ต้องไม่เปลี่ยนแปลงรูปแบบหรือเนื้อหาของเหตุการณ์ระบบอุปกรณ์ (batterystats , diskstats, fingerprint, graphicsstats, netstats, notification, procstats) ที่บันทึกผ่านคำสั่ง dumpsys
  • [C-0-10] ต้องบันทึกโดยไม่มีการละเว้น และทำให้เหตุการณ์ต่อไปนี้เข้าถึงได้และพร้อมใช้งานสำหรับcmd statsคำสั่ง Shell และคลาส System API ของ StatsManager
    • ActivityForegroundStateChanged
    • AnomalyDetected
    • AppBreadcrumbReported
    • AppCrashOccurred
    • AppStartOccurred
    • BatteryLevelChanged
    • BatterySaverModeStateChanged
    • BleScanResultReceived
    • BleScanStateChanged
    • ChargingStateChanged
    • DeviceIdleModeStateChanged
    • ForegroundServiceStateChanged
    • GpsScanStateChanged
    • JobStateChanged
    • PluggedStateChanged
    • ScheduledJobStateChanged
    • ScreenStateChanged
    • SyncStateChanged
    • SystemElapsedRealtime
    • UidProcessStateChanged
    • WakelockStateChanged
    • WakeupAlarmOccurred
    • WifiLockStateChanged
    • WifiMulticastLockStateChanged
    • WifiScanStateChanged
  • [C-0-4] ต้องมี daemon adb ฝั่งอุปกรณ์ที่ไม่ได้ใช้งานโดยค่าเริ่มต้น และต้องมีกลไกที่ผู้ใช้เข้าถึงได้เพื่อเปิด Android Debug Bridge
  • [C-0-5] ต้องรองรับ adb ที่ปลอดภัย Android รองรับ adb ที่ปลอดภัย adb ที่ปลอดภัยจะเปิดใช้ adb ในโฮสต์ที่ได้รับการตรวจสอบสิทธิ์ที่รู้จัก
  • [C-0-6] ต้องมีกลไกที่อนุญาตให้เชื่อมต่อ adb จากเครื่องโฮสต์ ดังนี้

  หากการติดตั้งใช้งานอุปกรณ์ที่ไม่มีพอร์ต USB รองรับโหมดอุปกรณ์ต่อพ่วง จะมีลักษณะดังนี้

  • [C-3-1] ต้องใช้ adb ผ่านเครือข่ายท้องถิ่น (เช่น อีเทอร์เน็ตหรือ Wi-Fi)
  • [C-3-2] ต้องมีไดรเวอร์สำหรับ Windows 7, 8 และ 10 เพื่อให้นักพัฒนาแอปเชื่อมต่อกับอุปกรณ์โดยใช้โปรโตคอล adb ได้

  หากการติดตั้งใช้งานอุปกรณ์รองรับการเชื่อมต่อ adb กับเครื่องโฮสต์ผ่าน Wi-Fi อุปกรณ์ดังกล่าวจะทำสิ่งต่อไปนี้

  • [C-4-1] ต้องมีAdbManager#isAdbWifiSupported()เมธอดที่แสดงผล true

  หากการติดตั้งใช้งานอุปกรณ์รองรับการเชื่อมต่อ adb กับเครื่องโฮสต์ผ่าน Wi-Fi และมีกล้องอย่างน้อย 1 ตัว อุปกรณ์ดังกล่าวจะทำสิ่งต่อไปนี้

  • [C-5-1] ต้องมีAdbManager#isAdbWifiQrSupported()เมธอดที่แสดงผล true

• บริการตรวจสอบข้อบกพร่องของ Dalvik (ddms)

  • [C-0-7] ต้องรองรับฟีเจอร์ ddms ทั้งหมดตามที่ระบุไว้ใน Android SDK เนื่องจาก ddms ใช้ adb การรองรับ ddms จึงควรปิดใช้งานโดยค่าเริ่มต้น แต่ต้องรองรับทุกครั้งที่ผู้ใช้เปิดใช้งาน Android Debug Bridge ดังที่กล่าวไว้ข้างต้น
• Monkey
  • [C-0-8] ต้องมีเฟรมเวิร์ก Monkey และทำให้แอปพลิเคชันใช้งานได้
• SysTrace
  • [C-0-9] ต้องรองรับเครื่องมือ Systrace ตามที่ระบุไว้ใน Android SDK Systrace ต้องปิดใช้งานโดยค่าเริ่มต้น และต้องมีกลไกที่ผู้ใช้เข้าถึงได้เพื่อเปิด Systrace
• Perfetto
  • [C-SR] Are STRONGLY RECOMMENDED to expose a /system/bin/perfetto binary to the shell user which cmdline complies with the perfetto documentation.
  • [C-SR] ขอแนะนำอย่างยิ่งให้ไบนารีของ Perfetto ยอมรับการกำหนดค่า Protobuf เป็นอินพุตซึ่งเป็นไปตามสคีมาที่กำหนดไว้ในเอกสารประกอบของ Perfetto
  • [C-SR] ขอแนะนำอย่างยิ่งให้ใช้ไบนารีของ Perfetto เพื่อเขียนเอาต์พุตเป็นร่องรอย Protobuf ที่เป็นไปตามสคีมาที่กำหนดไว้ในเอกสารประกอบของ Perfetto
  • [C-SR] ขอแนะนำอย่างยิ่งให้ระบุผ่านไบนารีของ Perfetto อย่างน้อยแหล่งข้อมูลที่อธิบายไว้ในเอกสารประกอบของ Perfetto
• Low Memory Killer
  • [C-0-10] ต้องเขียน LMK_KILL_OCCURRED_FIELD_NUMBER Atom ไปยังบันทึก statsd เมื่อ Low Memory Killer สิ้นสุดแอป
• โหมดโปรแกรมทดสอบอัตโนมัติ หากการติดตั้งใช้งานอุปกรณ์รองรับคำสั่งเชลล์ cmd testharness และเรียกใช้ cmd testharness enable อุปกรณ์จะทำสิ่งต่อไปนี้
  • [C-2-1] ต้องส่งคืน true สำหรับ ActivityManager.isRunningInUserTestHarness()
  • [C-2-2] ต้องใช้โหมดโปรแกรมทดสอบอัตโนมัติตามที่อธิบายไว้ในเอกสารประกอบเกี่ยวกับโหมดโปรแกรมทดสอบอัตโนมัติ

หากการติดตั้งใช้งานอุปกรณ์รายงานการรองรับ Vulkan 1.0 ขึ้นไปผ่านฟีเจอร์แฟล็ก android.hardware.vulkan.version อุปกรณ์ดังกล่าวจะ

• [C-1-1] ต้องมีกลไกสำหรับนักพัฒนาแอปเพื่อเปิด/ปิดใช้เลเยอร์การแก้ไขข้อบกพร่อง GPU
• [C-1-2] ต้องแสดงรายการเลเยอร์ในไลบรารีที่จัดหาโดยเครื่องมือภายนอก (เช่น ไม่ได้เป็นส่วนหนึ่งของแพ็กเกจแพลตฟอร์มหรือแอปพลิเคชัน) ที่พบในไดเรกทอรีฐานของแอปพลิเคชันที่แก้ไขข้อบกพร่องได้เพื่อรองรับเมธอด API vkEnumerateInstanceLayerProperties() และ vkCreateInstance() เมื่อเปิดใช้เลเยอร์การแก้ไขข้อบกพร่องของ GPU

6.2 ตัวเลือกสำหรับนักพัฒนาแอป

Android มีการรองรับให้นักพัฒนาแอปกำหนดการตั้งค่าที่เกี่ยวข้องกับการพัฒนาแอปพลิเคชัน

การใช้งานอุปกรณ์ต้องมอบประสบการณ์การใช้งานที่สอดคล้องกันสำหรับตัวเลือกสำหรับนักพัฒนาแอป โดยมีข้อกำหนดดังนี้

• [C-0-1] ต้องปฏิบัติตาม Intent android.settings.APPLICATION_DEVELOPMENT_SETTINGS เพื่อแสดงการตั้งค่าที่เกี่ยวข้องกับการพัฒนาแอปพลิเคชัน การติดตั้งใช้งาน Android ต้นทางจะซ่อนเมนูตัวเลือกสำหรับนักพัฒนาแอปโดยค่าเริ่มต้น และช่วยให้ผู้ใช้เปิดตัวเลือกสำหรับนักพัฒนาแอปได้หลังจากกด 7 ครั้งในรายการเมนูการตั้งค่า > เกี่ยวกับอุปกรณ์ > หมายเลขบิลด์
• [C-0-2] ต้องซ่อนตัวเลือกสำหรับนักพัฒนาแอปโดยค่าเริ่มต้น
• [C-0-3] ต้องมีกลไกที่ชัดเจนซึ่งไม่ให้สิทธิพิเศษแก่แอปของบุคคลที่สามแอปใดแอปหนึ่งเมื่อเทียบกับแอปอื่นเพื่อเปิดใช้ตัวเลือกสำหรับนักพัฒนาแอป ต้องระบุเอกสารหรือเว็บไซต์ที่มองเห็นได้แบบสาธารณะซึ่งอธิบายวิธีเปิดใช้ตัวเลือกสำหรับนักพัฒนาแอป เอกสารหรือเว็บไซต์นี้ต้องลิงก์จากเอกสาร Android SDK ได้
• ควรมีการแจ้งเตือนแบบภาพอย่างต่อเนื่องแก่ผู้ใช้เมื่อเปิดใช้ตัวเลือกสำหรับนักพัฒนาแอปและมีความกังวลเกี่ยวกับความปลอดภัยของผู้ใช้
• MAY อาจจำกัดการเข้าถึงเมนูตัวเลือกสำหรับนักพัฒนาแอปชั่วคราวโดยการซ่อนหรือปิดใช้เมนูเพื่อป้องกันไม่ให้ผู้ใช้เสียสมาธิในสถานการณ์ที่อาจเป็นอันตรายต่อผู้ใช้

7. ความเข้ากันได้ของฮาร์ดแวร์

หากอุปกรณ์มีคอมโพเนนต์ฮาร์ดแวร์ที่เฉพาะเจาะจงซึ่งมี API ที่เกี่ยวข้องสำหรับนักพัฒนาแอปบุคคลที่สาม

• [C-0-1] การติดตั้งใช้งานอุปกรณ์ต้องติดตั้งใช้งาน API นั้นตามที่อธิบายไว้ในเอกสารประกอบ Android SDK

หาก API ใน SDK โต้ตอบกับคอมโพเนนต์ฮาร์ดแวร์ที่ระบุว่าไม่บังคับและอุปกรณ์ที่ใช้งานไม่มีคอมโพเนนต์ดังกล่าว

• [C-0-2] ต้องยังคงแสดงคำจำกัดความของคลาสที่สมบูรณ์ (ตามที่ SDK ระบุไว้) สำหรับ API ของคอมโพเนนต์
• [C-0-3] ต้องใช้ลักษณะการทำงานของ API เป็นการดำเนินการที่ไม่มีการดำเนินการในลักษณะที่สมเหตุสมผล
• [C-0-4] เมธอด API ต้องแสดงค่า Null ในกรณีที่เอกสารประกอบของ SDK อนุญาต
• [C-0-5] เมธอด API ต้องแสดงผลการติดตั้งใช้งานแบบไม่มีการดำเนินการของคลาสที่เอกสารประกอบของ SDK ไม่อนุญาตให้ใช้ค่า Null
• [C-0-6] เมธอด API ต้องไม่ส่งข้อยกเว้นที่ไม่ได้ระบุไว้ในเอกสารประกอบของ SDK
• [C-0-7] การใช้งานอุปกรณ์ต้องรายงานข้อมูลการกำหนดค่าฮาร์ดแวร์ที่ถูกต้องอย่างสม่ำเสมอผ่านเมธอด getSystemAvailableFeatures() และ hasSystemFeature(String) ในคลาส android.content.pm.PackageManager สำหรับลายนิ้วมือของบิลด์เดียวกัน

ตัวอย่างทั่วไปของสถานการณ์ที่ต้องใช้ข้อกำหนดเหล่านี้คือ Telephony API แม้ในอุปกรณ์ที่ไม่ใช่โทรศัพท์ API เหล่านี้ก็ต้องได้รับการติดตั้งใช้งานเป็นไม่มีการดำเนินการที่สมเหตุสมผล

7.1. จอแสดงผลและกราฟิก

Android มีเครื่องมือที่ปรับชิ้นงานของแอปพลิเคชันและเลย์เอาต์ UI โดยอัตโนมัติให้เหมาะสมกับอุปกรณ์ เพื่อให้มั่นใจว่าแอปพลิเคชันของบุคคลที่สามจะทำงานได้ดีในการกำหนดค่าฮาร์ดแวร์ที่หลากหลาย ในจอแสดงผลที่รองรับ Android ซึ่งแอปพลิเคชันทั้งหมดของบุคคลที่สามที่รองรับ Android สามารถทำงานได้ การติดตั้งใช้งานอุปกรณ์ต้องใช้ API และลักษณะการทำงานเหล่านี้อย่างเหมาะสมตามที่ระบุไว้ในส่วนนี้

หน่วยที่ข้อกำหนดในส่วนนี้อ้างอิงได้รับการกำหนดดังนี้

• ขนาดเส้นทแยงมุมจริง ระยะห่างเป็นนิ้วระหว่างมุมตรงข้าม 2 มุมของส่วนที่สว่างของจอแสดงผล
• จุดต่อนิ้ว (DPI) จํานวนพิกเซลที่ครอบคลุมโดยช่วงแนวนอนหรือแนวตั้งเชิงเส้น 1 นิ้ว เมื่อมีการระบุค่า dpi ทั้ง dpi แนวนอนและแนวตั้งต้องอยู่ในช่วง
• สัดส่วนภาพ อัตราส่วนของพิกเซลด้านที่ยาวกว่าต่อพิกเซลด้านที่สั้นกว่าของหน้าจอ เช่น จอแสดงผลขนาด 480x854 พิกเซลจะมีอัตราส่วนเป็น 854/480 = 1.779 หรือประมาณ "16:9"
• ความหนาแน่นของพิกเซลอิสระ (dp) หน่วยพิกเซลเสมือนที่ปรับให้เป็นหน้าจอ 160 dpi โดยคำนวณเป็นพิกเซล = dp * (ความหนาแน่น/160)

7.1.1. การกำหนดค่าหน้าจอ

7.1.1.1. ขนาดและรูปร่างของหน้าจอ

เฟรมเวิร์ก UI ของ Android รองรับขนาดเลย์เอาต์หน้าจอเชิงตรรกะที่แตกต่างกันหลากหลาย และอนุญาตให้แอปพลิเคชันค้นหาขนาดเลย์เอาต์หน้าจอของการกำหนดค่าปัจจุบันผ่าน Configuration.screenLayout ด้วย SCREENLAYOUT_SIZE_MASK และ Configuration.smallestScreenWidthDp

การติดตั้งใช้งานอุปกรณ์

• [C-0-1] ต้องรายงานขนาดเลย์เอาต์ที่ถูกต้องสำหรับ Configuration.screenLayout ตามที่กำหนดไว้ในเอกสารประกอบของ Android SDK โดยเฉพาะอย่างยิ่ง การใช้งานอุปกรณ์ต้องรายงานขนาดหน้าจอพิกเซลอิสระ (dp) เชิงตรรกะที่ถูกต้องดังนี้

  • อุปกรณ์ที่มี Configuration.uiMode ตั้งค่าเป็นค่าอื่นที่ไม่ใช่ UI_MODE_TYPE_WATCH และรายงานขนาด small สำหรับ Configuration.screenLayout ต้องมีขนาดอย่างน้อย 426 dp x 320 dp
  • อุปกรณ์ที่รายงานnormalขนาดสำหรับConfiguration.screenLayoutต้องมีขนาดอย่างน้อย 480 dp x 320 dp
  • อุปกรณ์ที่รายงานlargeขนาดสำหรับConfiguration.screenLayoutต้องมีขนาดอย่างน้อย 640 dp x 480 dp
  • อุปกรณ์ที่รายงานxlarge ขนาดสำหรับ Configuration.screenLayout ต้องมีขนาดอย่างน้อย 960 dp x 720 dp

• [C-0-2] ต้องรองรับขนาดหน้าจอตามที่แอปพลิเคชันระบุไว้อย่างถูกต้องผ่านแอตทริบิวต์ <supports-screens> ใน AndroidManifest.xml ตามที่อธิบายไว้ในเอกสารประกอบของ Android SDK

• อาจมีจอแสดงผลที่รองรับ Android ที่มีมุมโค้งมน

หากการใช้งานอุปกรณ์รองรับ UI_MODE_TYPE_NORMAL และมีจอแสดงผลที่รองรับ Android พร้อมมุมโค้ง อุปกรณ์จะทำสิ่งต่อไปนี้

• [C-1-1] ต้องตรวจสอบว่ามีคุณสมบัติตรงตามข้อกำหนดต่อไปนี้อย่างน้อย 1 ข้อ
• รัศมีของมุมโค้งมนน้อยกว่าหรือเท่ากับ 38 dp

• เมื่อยึดกล่องขนาด 15 dp x 15 dp ไว้ที่มุมแต่ละมุมของจอแสดงผลเชิงตรรกะ จะมองเห็นอย่างน้อย 1 พิกเซลของแต่ละกล่องบนหน้าจอ

• ควรมีส่วนที่ผู้ใช้สามารถเปลี่ยนเป็นโหมดแสดงผลที่มีมุมเป็นสี่เหลี่ยมผืนผ้า

หากการติดตั้งใช้งานอุปกรณ์มีจอแสดงผลที่รองรับ Android ซึ่งพับได้ หรือมีบานพับระหว่างแผงจอแสดงผลหลายแผง และทำให้จอแสดงผลดังกล่าวพร้อมใช้งานเพื่อแสดงผลแอปของบุคคลที่สาม อุปกรณ์ดังกล่าวจะต้องมีคุณสมบัติดังนี้

• [C-2-1] ต้องใช้ Extensions API เวอร์ชันเสถียรล่าสุดที่มีอยู่ หรือ Sidecar API เวอร์ชันเสถียรที่ใช้โดยไลบรารี Window Manager Jetpack

หากการติดตั้งใช้งานอุปกรณ์มีจอแสดงผลที่เข้ากันได้กับ Android ซึ่งพับได้ หรือมีบานพับที่พับได้ระหว่างแผงจอแสดงผลหลายแผง และหากบานพับหรือการพับตัดผ่านหน้าต่างแอปพลิเคชันแบบเต็มหน้าจอ จะมีลักษณะดังนี้

• [C-3-1] ต้องรายงานตำแหน่ง ขอบเขต และสถานะของบานพับหรือรอยพับผ่านส่วนขยายหรือ API แบบ Sidecar ไปยังแอปพลิเคชัน

ดูรายละเอียดเกี่ยวกับการติดตั้งใช้งาน Sidecar หรือ Extension API อย่างถูกต้องได้ในเอกสารประกอบแบบสาธารณะของ Window Manager Jetpack

7.1.1.2. สัดส่วนการแสดงผลของหน้าจอ

แม้ว่าจะไม่มีข้อจำกัดเกี่ยวกับสัดส่วนภาพของจอแสดงผลจริงสำหรับจอแสดงผลที่ใช้ร่วมกับ Android แต่สัดส่วนภาพของจอแสดงผลเชิงตรรกะที่แอปของบุคคลที่สามแสดงผล ซึ่งได้มาจากค่าความสูงและความกว้างที่รายงานผ่าน API ของ view.Display และ API ของ Configuration จะต้องเป็นไปตามข้อกำหนดต่อไปนี้

• [C-0-1] การใช้งานอุปกรณ์ที่มี Configuration.uiMode ตั้งค่าเป็น UI_MODE_TYPE_NORMAL จะต้องมีค่าสัดส่วนภาพน้อยกว่าหรือเท่ากับ 1.86 (ประมาณ 16:9) เว้นแต่แอปจะมีคุณสมบัติตรงตามเงื่อนไขข้อใดข้อหนึ่งต่อไปนี้

  • แอปได้ประกาศว่ารองรับสัดส่วนภาพของหน้าจอที่ใหญ่ขึ้นผ่านค่าข้อมูลเมตา android.max_aspect
  • แอปประกาศว่าปรับขนาดได้ผ่านแอตทริบิวต์ android:resizeableActivity
  • แอปกำหนดเป้าหมายเป็น API ระดับ 24 ขึ้นไปและไม่ได้ประกาศ android:maxAspectRatio ที่จะจำกัดสัดส่วนภาพที่อนุญาต

• [C-0-2] การติดตั้งใช้งานอุปกรณ์ที่มี Configuration.uiMode ตั้งค่าเป็น UI_MODE_TYPE_NORMAL จะต้องมีค่าสัดส่วนภาพเท่ากับหรือมากกว่า 1.3333 (4:3) เว้นแต่จะขยายแอปให้กว้างขึ้นได้โดยเป็นไปตามเงื่อนไขต่อไปนี้

  • แอปประกาศว่าปรับขนาดได้ผ่านแอตทริบิวต์ android:resizeableActivity
  • แอปประกาศ android:minAspectRatio ที่จะจำกัดสัดส่วนภาพที่อนุญาต

• [C-0-3] การใช้งานอุปกรณ์ที่มี Configuration.uiMode ตั้งค่าเป็น UI_MODE_TYPE_WATCH จะต้องมีค่าสัดส่วนภาพตั้งค่าเป็น 1.0 (1:1)

7.1.1.3. ความหนาแน่นของหน้าจอ

เฟรมเวิร์ก UI ของ Android กำหนดชุดความหนาแน่นเชิงตรรกะมาตรฐานเพื่อช่วยให้นักพัฒนาแอปพลิเคชันกำหนดเป้าหมายทรัพยากรของแอปพลิเคชัน

• [C-0-1] โดยค่าเริ่มต้น การติดตั้งใช้งานอุปกรณ์ต้องรายงานความหนาแน่นของเฟรมเวิร์ก Android เพียงรายการเดียวที่ระบุไว้ใน DisplayMetrics ผ่าน DENSITY_DEVICE_STABLE API และค่านี้ต้องไม่เปลี่ยนแปลงในทุกกรณี อย่างไรก็ตาม อุปกรณ์อาจรายงานความหนาแน่นที่กำหนดเองแตกต่างกันไปตามการเปลี่ยนแปลงการกำหนดค่าการแสดงผลที่ผู้ใช้ทำ (เช่น ขนาดการแสดงผล) ซึ่งตั้งค่าหลังจากบูตครั้งแรก

• การใช้งานอุปกรณ์ควรระบุความหนาแน่นของเฟรมเวิร์ก Android มาตรฐานซึ่งมีค่าตัวเลขใกล้เคียงกับความหนาแน่นจริงของหน้าจอมากที่สุด เว้นแต่ความหนาแน่นเชิงตรรกะดังกล่าวจะทำให้ขนาดหน้าจอที่รายงานต่ำกว่าขนาดต่ำสุดที่รองรับ หากความหนาแน่นของเฟรมเวิร์ก Android มาตรฐานที่ใกล้เคียงกับความหนาแน่นทางกายภาพมากที่สุดส่งผลให้ขนาดหน้าจอเล็กกว่าขนาดหน้าจอที่เล็กที่สุดที่รองรับ (ความกว้าง 320 dp) การติดตั้งใช้งานอุปกรณ์ควรรายงานความหนาแน่นของเฟรมเวิร์ก Android มาตรฐานที่ต่ำที่สุดถัดไป

หากมีตัวเลือกในการเปลี่ยนขนาดการแสดงผลของอุปกรณ์ ให้ทำดังนี้

• [C-1-1] ขนาดการแสดงผลต้องไม่ได้รับการปรับขนาดให้ใหญ่กว่าความหนาแน่นดั้งเดิม 1.5 เท่า หรือสร้างขนาดหน้าจอขั้นต่ำที่มีประสิทธิภาพให้เล็กกว่า 320dp (เทียบเท่ากับตัวระบุทรัพยากร sw320dp) ไม่ว่ากรณีใดจะเกิดขึ้นก่อน
• [C-1-2] ขนาดการแสดงผลต้องไม่ได้รับการปรับขนาดให้เล็กกว่าความหนาแน่นดั้งเดิม 0.85 เท่า
• ขอแนะนำให้ระบุตัวเลือกการปรับขนาดต่อไปนี้ของโฆษณา Display เนทีฟ (ขณะที่ปฏิบัติตามขีดจำกัดที่ระบุไว้ข้างต้น) เพื่อให้มั่นใจว่าใช้งานได้ดีและมีขนาดแบบอักษรที่สอดคล้องกัน
• เล็ก: 0.85x
• ค่าเริ่มต้น: 1x (ขนาดการแสดงผลเนทีฟ)
• ใหญ่: 1.15x
• ใหญ่ขึ้น: 1.3x
• ใหญ่ที่สุด 1.45x

7.1.2. เมตริก Display

หากการติดตั้งใช้งานอุปกรณ์มีจอแสดงผลที่ใช้ได้กับ Android หรือเอาต์พุตวิดีโอไปยังหน้าจอแสดงผลที่ใช้ได้กับ Android อุปกรณ์ดังกล่าวจะต้องมีคุณสมบัติดังนี้

• [C-1-1] ต้องรายงานค่าที่ถูกต้องสำหรับเมตริกโฆษณา Display ทั้งหมดที่ใช้ร่วมกับ Android ได้ซึ่งกำหนดไว้ใน android.util.DisplayMetrics API

หากการติดตั้งใช้งานอุปกรณ์ไม่มีหน้าจอแบบฝังหรือเอาต์พุตวิดีโอ อุปกรณ์ดังกล่าวจะทำสิ่งต่อไปนี้

• [C-2-1] ต้องรายงานค่าที่ถูกต้องของจอแสดงผลที่ใช้ร่วมกับ Android ตามที่กำหนดไว้ใน API ของ android.util.DisplayMetrics สำหรับ view.Display เริ่มต้นที่จำลอง

7.1.3. การวางแนวหน้าจอ

การติดตั้งใช้งานอุปกรณ์

• [C-0-1] ต้องรายงานการวางแนวหน้าจอที่รองรับ (android.hardware.screen.portrait และ/หรือ android.hardware.screen.landscape) และต้องรายงานการวางแนวที่รองรับอย่างน้อย 1 รายการ เช่น อุปกรณ์ที่มีหน้าจอแนวนอนแบบคงที่ เช่น โทรทัศน์หรือแล็ปท็อป ควรรายงานเฉพาะ android.hardware.screen.landscape
• [C-0-2] ต้องรายงานค่าที่ถูกต้องสำหรับการวางแนวปัจจุบันของอุปกรณ์ทุกครั้งที่มีการค้นหาผ่าน android.content.res.Configuration.orientation, android.view.Display.getOrientation() หรือ API อื่นๆ

หากการใช้งานอุปกรณ์รองรับทั้ง 2 รูปแบบหน้าจอ จะมีลักษณะดังนี้

• [C-1-1] ต้องรองรับการวางแนวแบบไดนามิกโดยแอปพลิเคชันให้เป็นแนวตั้งหรือแนวนอน กล่าวคือ อุปกรณ์ต้องปฏิบัติตามคำขอของแอปพลิเคชันสำหรับการวางแนวหน้าจอที่เฉพาะเจาะจง
• [C-1-2] ต้องไม่เปลี่ยนขนาดหรือความหนาแน่นของหน้าจอที่รายงานเมื่อเปลี่ยนการวางแนว
• MAY สามารถเลือกการวางแนวตั้งหรือแนวนอนเป็นค่าเริ่มต้นได้

7.1.4. การเร่งกราฟิก 2 มิติและ 3 มิติ

7.1.4.1 OpenGL ES

การติดตั้งใช้งานอุปกรณ์

• [C-0-1] ต้องระบุเวอร์ชัน OpenGL ES ที่รองรับ (1.1, 2.0, 3.0, 3.1, 3.2) อย่างถูกต้องผ่าน API ที่มีการจัดการ (เช่น ผ่านเมธอด GLES10.getString()) และ API ดั้งเดิม
• [C-0-2] ต้องรองรับ API ที่มีการจัดการและ API ดั้งเดิมที่เกี่ยวข้องทั้งหมดสำหรับ OpenGL ES ทุกเวอร์ชันที่ระบุว่ารองรับ

หากการใช้งานอุปกรณ์มีเอาต์พุตหน้าจอหรือวิดีโอ อุปกรณ์จะต้องมีคุณสมบัติดังนี้

• [C-1-1] ต้องรองรับทั้ง OpenGL ES 1.1 และ 2.0 ตามที่ระบุและอธิบายไว้ในเอกสารประกอบ Android SDK
• [C-SR] ขอแนะนำอย่างยิ่งให้รองรับ OpenGL ES 3.1
• ควรจะรองรับ OpenGL ES 3.2

หากการใช้งานอุปกรณ์รองรับ OpenGL ES เวอร์ชันใดเวอร์ชันหนึ่ง จะต้องมีคุณสมบัติดังนี้

• [C-2-1] ต้องรายงานผ่าน API ที่มีการจัดการของ OpenGL ES และ API ดั้งเดิมของส่วนขยาย OpenGL ES อื่นๆ ที่ได้ติดตั้งใช้งาน และในทางกลับกันต้องไม่รายงานสตริงส่วนขยายที่ไม่รองรับ
• [C-2-2] ต้องรองรับส่วนขยาย EGL_KHR_image, EGL_KHR_image_base, EGL_ANDROID_image_native_buffer, EGL_ANDROID_get_native_client_buffer, EGL_KHR_wait_sync, EGL_KHR_get_all_proc_addresses, EGL_ANDROID_presentation_time, EGL_KHR_swap_buffers_with_damage, EGL_ANDROID_recordable และ EGL_ANDROID_GLES_layers
• [C-SR] ขอแนะนําอย่างยิ่งให้รองรับส่วนขยาย EGL_KHR_partial_update และ OES_EGL_image_external
• ควรรายงานอย่างถูกต้องผ่านgetString()วิธีการ รูปแบบการบีบอัดพื้นผิวใดก็ตามที่รองรับ ซึ่งโดยปกติแล้วจะเฉพาะเจาะจงผู้จำหน่าย

หากการติดตั้งใช้งานอุปกรณ์ประกาศว่ารองรับ OpenGL ES 3.0, 3.1 หรือ 3.2 อุปกรณ์ดังกล่าวจะต้องมีคุณสมบัติดังนี้

• [C-3-1] ต้องส่งออกสัญลักษณ์ฟังก์ชันที่เกี่ยวข้องสำหรับเวอร์ชันเหล่านี้ นอกเหนือจากสัญลักษณ์ฟังก์ชัน OpenGL ES 2.0 ในไลบรารี libGLESv2.so
• [SR] ขอแนะนำอย่างยิ่งให้รองรับส่วนขยาย OES_EGL_image_external_essl3

หากการใช้งานอุปกรณ์รองรับ OpenGL ES 3.2 อุปกรณ์จะ

• [C-4-1] ต้องรองรับ OpenGL ES Android Extension Pack ทั้งหมด

หากการใช้งานอุปกรณ์รองรับ Android Extension Pack ของ OpenGL ES ทั้งหมด อุปกรณ์จะทำสิ่งต่อไปนี้ได้

• [C-5-1] ต้องระบุการรองรับผ่านแฟล็กฟีเจอร์ android.hardware.opengles.aep

หากการติดตั้งใช้งานอุปกรณ์เปิดเผยการรองรับส่วนขยาย EGL_KHR_mutable_render_buffer อุปกรณ์ดังกล่าวจะทำสิ่งต่อไปนี้

• [C-6-1] ต้องรองรับส่วนขยาย EGL_ANDROID_front_buffer_auto_refresh ด้วย

7.1.4.2 Vulkan

Android รองรับ Vulkan ซึ่งเป็น API แบบข้ามแพลตฟอร์มที่มีค่าใช้จ่ายต่ำสำหรับกราฟิก 3 มิติที่มีประสิทธิภาพสูง

หากการใช้งานอุปกรณ์รองรับ OpenGL ES 3.1 อุปกรณ์จะทำสิ่งต่อไปนี้

• [SR] ขอแนะนำอย่างยิ่งให้รวมการรองรับ Vulkan 1.1

หากการใช้งานอุปกรณ์มีเอาต์พุตหน้าจอหรือวิดีโอ อุปกรณ์จะต้องมีคุณสมบัติดังนี้

• ควรมีการรองรับ Vulkan 1.1

การทดสอบ dEQP ของ Vulkan จะแบ่งออกเป็นรายการทดสอบหลายรายการ โดยแต่ละรายการจะมีวันที่/เวอร์ชันที่เชื่อมโยง โดยไฟล์เหล่านี้จะอยู่ในโครงสร้างแหล่งที่มาของ Android ที่ external/deqp/android/cts/main/vk-master-YYYY-MM-DD.txt อุปกรณ์ที่รองรับ Vulkan ในระดับที่รายงานด้วยตนเองจะระบุว่าอุปกรณ์ผ่านการทดสอบ dEQP ในรายการทดสอบทั้งหมดจากระดับนี้และก่อนหน้านี้

หากการติดตั้งใช้งานอุปกรณ์รองรับ Vulkan 1.0 ขึ้นไป อุปกรณ์ดังกล่าวจะ

• [C-1-1] ต้องรายงานค่าจำนวนเต็มที่ถูกต้องด้วยฟีเจอร์แฟล็ก android.hardware.vulkan.level และ android.hardware.vulkan.version
• [C-1-2] ต้องแสดง VkPhysicalDevice อย่างน้อย 1 รายการสำหรับ Vulkan Native API vkEnumeratePhysicalDevices()
• [C-1-3] ต้องใช้ API ของ Vulkan 1.0 อย่างเต็มรูปแบบสำหรับแต่ละ VkPhysicalDevice ที่ระบุ
• [C-1-4] ต้องแสดงรายการชั้นที่อยู่ในไลบรารีแบบเนทีฟซึ่งตั้งชื่อเป็น libVkLayer*.so ในไดเรกทอรีไลบรารีแบบเนทีฟของแพ็กเกจแอปพลิเคชันผ่าน API แบบเนทีฟของ Vulkan vkEnumerateInstanceLayerProperties() และ vkEnumerateDeviceLayerProperties()
• [C-1-5] ต้องไม่แสดงรายการเลเยอร์ที่ไลบรารีภายนอกแพ็กเกจแอปพลิเคชันจัดหาให้ หรือจัดหาวิธีอื่นๆ ในการติดตามหรือสกัดกั้น Vulkan API เว้นแต่แอปพลิเคชันจะมีแอตทริบิวต์ android:debuggable ที่ตั้งค่าเป็น true
• [C-1-6] ต้องรายงานสตริงส่วนขยายทั้งหมดที่รองรับผ่าน Vulkan Native API และในทางกลับกันต้องไม่รายงานสตริงส่วนขยายที่ไม่รองรับอย่างถูกต้อง
• [C-1-7] ต้องรองรับส่วนขยาย VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain และ VK_KHR_incremental_present
• [C-1-8] ต้องรายงานเวอร์ชันสูงสุดของ Vulkan dEQP Tests ที่รองรับผ่านแฟล็กฟีเจอร์ android.software.vulkan.deqp.level
• [C-1-9] ต้องรองรับเวอร์ชัน 132317953 (ตั้งแต่วันที่ 1 มี.ค. 2019) เป็นอย่างน้อยตามที่รายงานในแฟล็กฟีเจอร์ android.software.vulkan.deqp.level
• [C-1-10] ต้องผ่านการทดสอบ dEQP ของ Vulkan ทั้งหมดในรายการทดสอบระหว่างเวอร์ชัน 132317953 กับเวอร์ชันที่ระบุในแฟล็กฟีเจอร์ android.software.vulkan.deqp.level
• [C-SR] ขอแนะนำอย่างยิ่งให้รองรับส่วนขยาย VK_KHR_driver_properties และ VK_GOOGLE_display_timing

หากการใช้งานอุปกรณ์ไม่รองรับ Vulkan 1.0 จะเกิดกรณีต่อไปนี้

• [C-2-1] ต้องไม่ประกาศฟีเจอร์แฟล็ก Vulkan ใดๆ (เช่น android.hardware.vulkan.level, android.hardware.vulkan.version)
• [C-2-2] ต้องไม่แจงนับ VkPhysicalDevice สำหรับ Vulkan Native API vkEnumeratePhysicalDevices()

หากการใช้งานอุปกรณ์รองรับ Vulkan 1.1 และประกาศค่าสถานะฟีเจอร์ Vulkan ใดๆ อุปกรณ์จะต้องมีคุณสมบัติดังนี้

• [C-3-1] ต้องแสดงการรองรับSYNC_FDประเภทภายนอกของ Semaphore และประเภทแฮนเดิล รวมถึงส่วนขยาย VK_ANDROID_external_memory_android_hardware_buffer

7.1.4.3 RenderScript

• [C-0-1] การติดตั้งใช้งานอุปกรณ์ต้องรองรับ Android RenderScript ตามที่ระบุไว้ในเอกสารประกอบของ Android SDK

7.1.4.4 การเร่งกราฟิก 2 มิติ

Android มีกลไกสำหรับแอปพลิเคชันในการประกาศว่าต้องการเปิดใช้การเร่งด้วยฮาร์ดแวร์สำหรับกราฟิก 2 มิติที่ระดับแอปพลิเคชัน กิจกรรม หน้าต่าง หรือมุมมองผ่านการใช้แท็ก Manifest android:hardwareAccelerated หรือการเรียก API โดยตรง

การติดตั้งใช้งานอุปกรณ์

• [C-0-1] ต้องเปิดใช้การเร่งฮาร์ดแวร์โดยค่าเริ่มต้น และต้องปิดใช้การเร่งฮาร์ดแวร์หากนักพัฒนาแอปขอโดยการตั้งค่า android:hardwareAccelerated="false” หรือปิดใช้การเร่งฮาร์ดแวร์โดยตรงผ่าน Android View API
• [C-0-2] ต้องแสดงลักษณะการทำงานที่สอดคล้องกับเอกสารประกอบของ Android SDK เกี่ยวกับการเร่งด้วยฮาร์ดแวร์

Android มีออบเจ็กต์ TextureView ที่ช่วยให้นักพัฒนาแอปผสานรวมพื้นผิว OpenGL ES ที่เร่งด้วยฮาร์ดแวร์โดยตรงเป็นเป้าหมายการแสดงผลในลําดับชั้น UI

การติดตั้งใช้งานอุปกรณ์

• [C-0-3] ต้องรองรับ TextureView API และต้องแสดงลักษณะการทำงานที่สอดคล้องกับการใช้งาน Android ต้นทาง

7.1.4.5 จอแสดงผลที่มีขอบเขตสีกว้าง

หากการติดตั้งใช้งานอุปกรณ์อ้างว่ารองรับจอแสดงผลแบบไวด์แกมมาผ่าน Configuration.isScreenWideColorGamut() จะมีข้อกำหนดดังนี้

• [C-1-1] ต้องมีจอแสดงผลที่ปรับเทียบสีแล้ว
• [C-1-2] ต้องมีจอแสดงผลที่มีขอบเขตสีครอบคลุมขอบเขตสี sRGB ทั้งหมดในพื้นที่ CIE 1931 xyY
• [C-1-3] ต้องมีจอแสดงผลที่มีขอบเขตสีซึ่งมีพื้นที่อย่างน้อย 90% ของ DCI-P3 ในพื้นที่ xyY ของ CIE 1931
• [C-1-4] ต้องรองรับ OpenGL ES 3.1 หรือ 3.2 และรายงานอย่างถูกต้อง
• [C-1-5] ต้องโฆษณาการรองรับส่วนขยาย EGL_KHR_no_config_context, EGL_EXT_pixel_format_float, EGL_KHR_gl_colorspace, EGL_EXT_gl_colorspace_scrgb, EGL_EXT_gl_colorspace_scrgb_linear, EGL_EXT_gl_colorspace_display_p3, EGL_EXT_gl_colorspace_display_p3_linear และ EGL_EXT_gl_colorspace_display_p3_passthrough
• [C-SR] ขอแนะนำอย่างยิ่งให้รองรับ GL_EXT_sRGB

ในทางกลับกัน หากการใช้งานอุปกรณ์ไม่รองรับจอแสดงผลแบบช่วงสีกว้าง อุปกรณ์จะ

• [C-2-1] ควรครอบคลุม sRGB อย่างน้อย 100% ในพื้นที่ CIE 1931 xyY แม้ว่าจะไม่ได้กำหนดขอบเขตสีของหน้าจอไว้ก็ตาม

7.1.5. โหมดความเข้ากันได้ของแอปพลิเคชันเดิม

Android ระบุ "โหมดความเข้ากันได้" ซึ่งเฟรมเวิร์กจะทำงานในโหมดขนาดหน้าจอ "ปกติ" ที่เทียบเท่า (ความกว้าง 320dp) เพื่อประโยชน์ของแอปพลิเคชันเดิมที่ไม่ได้พัฒนาสำหรับ Android เวอร์ชันเก่าที่ก่อนหน้าการไม่ขึ้นอยู่กับขนาดหน้าจอ

7.1.6. เทคโนโลยีหน้าจอ

แพลตฟอร์ม Android มี API ที่อนุญาตให้แอปพลิเคชันแสดงกราฟิกที่สมบูรณ์บนจอแสดงผลที่ใช้ร่วมกับ Android ได้ อุปกรณ์ต้องรองรับ API ทั้งหมดเหล่านี้ตามที่กำหนดโดย Android SDK เว้นแต่จะได้รับอนุญาตเป็นพิเศษในเอกสารนี้

จอแสดงผลทั้งหมดที่รองรับ Android ของการติดตั้งใช้งานอุปกรณ์

• [C-0-1] ต้องแสดงกราฟิกสี 16 บิตได้
• ควรรองรับจอแสดงผลที่แสดงกราฟิกสี 24 บิตได้
• [C-0-2] ต้องสามารถแสดงภาพเคลื่อนไหวได้
• [C-0-3] ต้องมีสัดส่วนพิกเซล (PAR) ระหว่าง 0.9 ถึง 1.15 กล่าวคือ อัตราส่วนพิกเซลต้องใกล้เคียงกับสี่เหลี่ยมจัตุรัส (1.0) โดยมีค่าความคลาดเคลื่อน 10~15%

7.1.7. จอแสดงผลสำรอง

Android รองรับจอแสดงผลรองที่ใช้ได้กับ Android เพื่อเปิดใช้ความสามารถในการแชร์สื่อและ API ของนักพัฒนาแอปสำหรับการเข้าถึงจอแสดงผลภายนอก

หากการใช้งานอุปกรณ์รองรับจอแสดงผลภายนอก ไม่ว่าจะผ่านการเชื่อมต่อแบบใช้สาย ไร้สาย หรือการเชื่อมต่อจอแสดงผลเพิ่มเติมแบบฝัง อุปกรณ์ดังกล่าวจะทำสิ่งต่อไปนี้

• [C-1-1] ต้องใช้บริการและ API ของระบบ DisplayManager ตามที่อธิบายไว้ในเอกสารประกอบของ Android SDK

7.2. อุปกรณ์อินพุต

การติดตั้งใช้งานอุปกรณ์

• [C-0-1] ต้องมีกลไกการป้อนข้อมูล เช่น หน้าจอสัมผัสหรือการนำทางแบบไม่สัมผัส เพื่อไปยังองค์ประกอบ UI ต่างๆ

7.2.1. แป้นพิมพ์

หากการใช้งานอุปกรณ์รวมถึงการรองรับแอปพลิเคชันตัวแก้ไขวิธีการป้อนข้อมูล (IME) ของบุคคลที่สาม อุปกรณ์จะต้องมีคุณสมบัติดังนี้

• [C-1-1] ต้องประกาศแฟล็กฟีเจอร์ android.software.input_methods
• [C-1-2] ต้องติดตั้งใช้งาน Input Management Framework อย่างเต็มรูปแบบ
• [C-1-3] ต้องมีแป้นพิมพ์เสมือนที่ติดตั้งไว้ล่วงหน้า

การใช้งานอุปกรณ์: * [C-0-1] ต้องไม่มีแป้นพิมพ์ฮาร์ดแวร์ที่ไม่ตรงกับรูปแบบใดรูปแบบหนึ่งที่ระบุไว้ใน android.content.res.Configuration.keyboard (QWERTY หรือ 12 ปุ่ม) * ควรมีการติดตั้งใช้งานแป้นพิมพ์เสมือนเพิ่มเติม * อาจมีแป้นพิมพ์ฮาร์ดแวร์

7.2.2. การนำทางแบบไม่ต้องสัมผัส

Android รองรับ D-pad, แทร็กบอล และวงล้อเป็นกลไกสำหรับการไปยังส่วนต่างๆ ที่ไม่ต้องสัมผัส

การติดตั้งใช้งานอุปกรณ์

• [C-0-1] ต้องรายงานค่าที่ถูกต้องสำหรับ android.content.res.Configuration.navigation

หากการใช้งานอุปกรณ์ไม่มีการนำทางแบบไม่สัมผัส อุปกรณ์จะ

• [C-1-1] ต้องมีกลไกอินเทอร์เฟซผู้ใช้ทางเลือกที่สมเหตุสมผลสำหรับการเลือกและแก้ไขข้อความ ซึ่งเข้ากันได้กับเครื่องมือจัดการอินพุต การใช้งานโอเพนซอร์สของ Android ต้นทางมีกลไกการเลือกที่เหมาะกับการใช้กับอุปกรณ์ที่ไม่มีอินพุตการนำทางแบบไม่สัมผัส

7.2.3. ปุ่มการนำทาง

ฟังก์ชันหน้าแรก ล่าสุด และกลับ ซึ่งโดยปกติจะมีการโต้ตอบกับปุ่มจริงเฉพาะหรือส่วนที่แตกต่างกันของหน้าจอสัมผัสเป็นสิ่งจำเป็นสำหรับกระบวนทัศน์การนำทางของ Android และการใช้งานอุปกรณ์

• [C-0-1] ต้องมีส่วนอำนวยความสะดวกให้ผู้ใช้เปิดแอปพลิเคชันที่ติดตั้งไว้ซึ่งมีกิจกรรมที่ตั้งค่า <intent-filter> เป็น ACTION=MAIN และ CATEGORY=LAUNCHER หรือ CATEGORY=LEANBACK_LAUNCHER สำหรับการติดตั้งใช้งานอุปกรณ์โทรทัศน์ ฟังก์ชันหน้าแรกควรเป็นกลไกสำหรับความสามารถในการใช้งานของผู้ใช้
• ควรมีปุ่มสำหรับฟังก์ชันล่าสุดและย้อนกลับ

หากมีฟังก์ชันหน้าแรก ล่าสุด หรือย้อนกลับ ฟังก์ชันเหล่านั้นจะทำสิ่งต่อไปนี้

• [C-1-1] ต้องเข้าถึงได้ด้วยการดำเนินการเดียว (เช่น แตะ ดับเบิลคลิก หรือท่าทางสัมผัส) เมื่อเข้าถึงได้
• [C-1-2] ต้องระบุอย่างชัดเจนว่าการดำเนินการเดียวใดที่จะเรียกใช้แต่ละฟังก์ชัน ตัวอย่างของการระบุเช่นนี้ ได้แก่ การมีไอคอนที่มองเห็นได้ซึ่งพิมพ์อยู่บนปุ่ม การแสดงไอคอนซอฟต์แวร์ในส่วนแถบนำทางของหน้าจอ หรือการแนะนำผู้ใช้ผ่านขั้นตอนการสาธิตแบบทีละขั้นตอนที่มีคำแนะนำในระหว่างประสบการณ์การตั้งค่าเมื่อแกะกล่อง

การติดตั้งใช้งานอุปกรณ์

• [SR] ขอแนะนำอย่างยิ่งว่าไม่ควรระบุกลไกการป้อนข้อมูลสำหรับฟังก์ชันเมนู เนื่องจากเลิกใช้งานแล้วเพื่อสนับสนุนแถบการดำเนินการตั้งแต่ Android 4.0

หากการติดตั้งใช้งานอุปกรณ์มีฟังก์ชันเมนู จะต้องมีลักษณะดังนี้

• [C-2-1] ต้องแสดงปุ่มรายการเพิ่มเติมทุกครั้งที่เมนูรายการเพิ่มเติมแบบป๊อปอัปไม่ว่างเปล่าและแถบการดำเนินการปรากฏอยู่
• [C-2-2] ต้องไม่แก้ไขตำแหน่งของป๊อปอัปการดำเนินการเพิ่มเติมที่แสดงโดยการเลือกปุ่มรายการเพิ่มเติมในแถบการดำเนินการ แต่สามารถแสดงป๊อปอัปการดำเนินการเพิ่มเติมในตำแหน่งที่แก้ไขบนหน้าจอได้เมื่อแสดงโดยการเลือกฟังก์ชันเมนู

หากการติดตั้งใช้งานอุปกรณ์ไม่มีฟังก์ชันเมนู เพื่อให้ใช้งานร่วมกันได้กับเวอร์ชันก่อนหน้า อุปกรณ์จะต้องมีคุณสมบัติดังนี้

• [C-3-1] ต้องทำให้ฟังก์ชันเมนูพร้อมใช้งานในแอปพลิเคชันเมื่อ targetSdkVersion น้อยกว่า 10 ไม่ว่าจะผ่านปุ่มจริง คีย์ซอฟต์แวร์ หรือท่าทางสัมผัส ฟังก์ชันเมนูนี้ควรเข้าถึงได้ เว้นแต่จะซ่อนไว้พร้อมกับฟังก์ชันการนำทางอื่นๆ

หากการใช้งานอุปกรณ์มีฟังก์ชันช่วยเหลือ อุปกรณ์จะทำสิ่งต่อไปนี้

• [C-4-1] ต้องทำให้ฟังก์ชันช่วยเหลือเข้าถึงได้ด้วยการดำเนินการเดียว (เช่น แตะ ดับเบิลคลิก หรือท่าทางสัมผัส) เมื่อแป้นนำทางอื่นๆ เข้าถึงได้
• [SR] ขอแนะนำให้ใช้การกดฟังก์ชันหน้าแรกค้างไว้เป็นอย่างยิ่งเนื่องจากเป็นการโต้ตอบที่กำหนดไว้

หากการใช้งานอุปกรณ์ใช้ส่วนที่แตกต่างกันของหน้าจอเพื่อแสดงปุ่มนำทาง อุปกรณ์ดังกล่าวจะทำสิ่งต่อไปนี้

• [C-5-1] ปุ่มนำทางต้องใช้ส่วนที่แตกต่างกันของหน้าจอ ซึ่งแอปพลิเคชันไม่สามารถเข้าถึงได้ และต้องไม่บดบังหรือรบกวนส่วนของหน้าจอที่แอปพลิเคชันเข้าถึงได้
• [C-5-2] ต้องจัดสรรพื้นที่แสดงผลส่วนหนึ่งให้แก่แอปพลิเคชันที่เป็นไปตามข้อกำหนดที่ระบุไว้ในส่วนที่ 7.1.1
• [C-5-3] ต้องปฏิบัติตามค่าสถานะที่แอปตั้งค่าผ่านเมธอด API View.setSystemUiVisibility() เพื่อให้ส่วนที่แตกต่างกันของหน้าจอ (หรือที่เรียกว่าแถบนำทาง) ซ่อนอยู่อย่างถูกต้องตามที่ระบุไว้ใน SDK

หากฟังก์ชันการนำทางมีให้ใช้งานเป็นการกระทำบนหน้าจอที่อิงตามท่าทางสัมผัส ให้ทำดังนี้

• [C-6-1] WindowInsets#getMandatorySystemGestureInsets() ต้องใช้เพื่อรายงานพื้นที่การจดจำท่าทางสัมผัสหน้าแรกเท่านั้น
• [C-6-2] ท่าทางสัมผัสที่เริ่มต้นภายในสี่เหลี่ยมผืนผ้าการยกเว้นที่แอปพลิเคชันที่ทำงานอยู่เบื้องหน้าให้ไว้ผ่าน View#setSystemGestureExclusionRects() แต่อยู่นอก WindowInsets#getMandatorySystemGestureInsets() จะต้องไม่ถูกสกัดกั้นสำหรับฟังก์ชันการนำทางตราบใดที่สี่เหลี่ยมผืนผ้าการยกเว้นได้รับอนุญาตภายในขีดจำกัดการยกเว้นสูงสุดตามที่ระบุไว้ในเอกสารประกอบสำหรับ View#setSystemGestureExclusionRects()
• [C-6-3] ต้องส่งเหตุการณ์ MotionEvent.ACTION_CANCEL ไปยังแอปที่ทำงานอยู่เบื้องหน้าเมื่อเริ่มมีการสกัดกั้นการแตะสำหรับท่าทางสัมผัสของระบบ หากก่อนหน้านี้มีการส่งเหตุการณ์ MotionEvent.ACTION_DOWN ไปยังแอปที่ทำงานอยู่เบื้องหน้า
• [C-6-4] ต้องมีส่วนอำนวยความสะดวกให้ผู้ใช้เปลี่ยนไปใช้การนำทางบนหน้าจอแบบปุ่ม (เช่น ในการตั้งค่า)
• ควรมีฟังก์ชันหน้าแรกเป็นการปัดขึ้นจากขอบด้านล่างของหน้าจอในแนวนอนปัจจุบัน
• ควรมีฟังก์ชัน "ล่าสุด" เป็นการปัดขึ้นและกดค้างก่อนปล่อยจากพื้นที่เดียวกับท่าทางสัมผัสหน้าแรก
• ท่าทางสัมผัสที่เริ่มต้นภายใน WindowInsets#getMandatorySystemGestureInsets() ไม่ควรได้รับผลกระทบจากสี่เหลี่ยมผืนผ้าการยกเว้นที่แอปพลิเคชันที่ทำงานอยู่เบื้องหน้าให้ไว้ผ่าน View#setSystemGestureExclusionRects()

หากมีฟังก์ชันการนำทางจากที่ใดก็ได้ที่ขอบด้านซ้ายและขวาของแนวหน้าจอปัจจุบัน ให้ทำดังนี้

• [C-7-1] ฟังก์ชันการนำทางต้องเป็น "กลับ" และต้องมีให้ใช้งานโดยการปัดจากขอบทั้งด้านซ้ายและขวาของหน้าจอในแนวนอนปัจจุบัน
• [C-7-2] หากมีแผงระบบที่ปัดได้แบบกำหนดเองที่ขอบด้านซ้ายหรือขวา จะต้องวางแผงดังกล่าวภายใน 1/3 บนสุดของหน้าจอ โดยมีข้อบ่งชี้ที่มองเห็นได้ชัดเจนและต่อเนื่องว่าการลากเข้าจะเรียกใช้แผงที่กล่าวถึงข้างต้น และไม่ใช่การย้อนกลับ ผู้ใช้อาจกำหนดค่าแผงระบบให้แสดงที่ด้านล่าง 1/3 ของขอบหน้าจอ แต่แผงระบบต้องไม่ใช้พื้นที่เกิน 1/3 ของขอบ
• [C-7-3] เมื่อแอปที่ทำงานอยู่เบื้องหน้ามีการตั้งค่าแฟล็ก View.SYSTEM_UI_FLAG_IMMERSIVE หรือ View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY การปัดจากขอบต้องทำงานตามที่ติดตั้งใช้งานใน AOSP ซึ่งมีการบันทึกไว้ใน SDK
• [C-7-4] เมื่อแอปที่ทำงานอยู่เบื้องหน้ามีการตั้งค่าแฟล็ก View.SYSTEM_UI_FLAG_IMMERSIVE หรือ View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY ระบบจะต้องซ่อนแผงระบบที่ปัดได้แบบกำหนดเองจนกว่าผู้ใช้จะนำแถบระบบ (หรือที่เรียกว่าแถบนำทางและแถบสถานะ) เข้ามาตามที่ใช้งานใน AOSP

7.2.4. การป้อนข้อมูลด้วยการสัมผัส

Android รองรับระบบอินพุตพอยน์เตอร์ที่หลากหลาย เช่น หน้าจอสัมผัส ทัชแพด และอุปกรณ์อินพุตแบบสัมผัสจำลอง การใช้งานอุปกรณ์ที่ใช้หน้าจอสัมผัสจะเชื่อมโยงกับจอแสดงผลเพื่อให้ผู้ใช้รู้สึกว่าได้จัดการรายการบนหน้าจอโดยตรง เนื่องจากผู้ใช้สัมผัสหน้าจอโดยตรง ระบบจึงไม่จำเป็นต้องมีองค์ประกอบเพิ่มเติมเพื่อระบุออบเจ็กต์ที่กำลังจัดการ

การติดตั้งใช้งานอุปกรณ์

• ควรมีระบบป้อนข้อมูลด้วยเคอร์เซอร์บางประเภท (ทั้งแบบเมาส์หรือแบบสัมผัส)
• ควรรองรับเคอร์เซอร์ที่ติดตามได้อย่างอิสระอย่างเต็มรูปแบบ

หากการติดตั้งใช้งานอุปกรณ์มีหน้าจอสัมผัส (แบบสัมผัสเดียวหรือดีกว่า) ในจอแสดงผลหลักที่ใช้ร่วมกับ Android ได้ อุปกรณ์ดังกล่าวจะต้องมีคุณสมบัติดังนี้

• [C-1-1] ต้องรายงาน TOUCHSCREEN_FINGER สำหรับฟิลด์ API Configuration.touchscreen
• [C-1-2] ต้องรายงานฟีเจอร์แฟล็ก android.hardware.touchscreen และ android.hardware.faketouch

หากการใช้งานอุปกรณ์มีหน้าจอสัมผัสที่ติดตามการสัมผัสมากกว่า 1 ครั้งบนจอแสดงผลหลักที่ใช้ร่วมกับ Android ได้ อุปกรณ์ดังกล่าวจะต้องมีคุณสมบัติดังนี้

• [C-2-1] ต้องรายงานค่าสถานะฟีเจอร์ที่เหมาะสม android.hardware.touchscreen.multitouch, android.hardware.touchscreen.multitouch.distinct, android.hardware.touchscreen.multitouch.jazzhand ที่สอดคล้องกับประเภทของหน้าจอสัมผัสเฉพาะในอุปกรณ์

หากการใช้งานอุปกรณ์ต้องอาศัยอุปกรณ์ป้อนข้อมูลภายนอก เช่น เมาส์หรือแทร็กบอล (กล่าวคือ ไม่ได้สัมผัสหน้าจอโดยตรง) สำหรับการป้อนข้อมูลในจอแสดงผลหลักที่ใช้ร่วมกับ Android ได้ และเป็นไปตามข้อกำหนดการสัมผัสปลอมในส่วน 7.2.5 อุปกรณ์ดังกล่าวจะต้องมีคุณสมบัติดังนี้

• [C-3-1] ต้องไม่รายงานแฟล็กฟีเจอร์ที่ขึ้นต้นด้วย android.hardware.touchscreen
• [C-3-2] ต้องรายงานเฉพาะ android.hardware.faketouch
• [C-3-3] ต้องรายงาน TOUCHSCREEN_NOTOUCH สำหรับฟิลด์ API Configuration.touchscreen

7.2.5. การป้อนข้อมูลด้วยการสัมผัสปลอม

อินเทอร์เฟซแบบ Fake Touch มีระบบการป้อนข้อมูลของผู้ใช้ที่ประมาณค่าชุดย่อยของความสามารถของหน้าจอสัมผัส ตัวอย่างเช่น เมาส์หรือรีโมตคอนโทรลที่ควบคุมเคอร์เซอร์บนหน้าจอจะคล้ายกับการสัมผัส แต่ผู้ใช้ต้องชี้หรือโฟกัสก่อน แล้วจึงคลิก อุปกรณ์ป้อนข้อมูลจำนวนมาก เช่น เมาส์ แทร็กแพด เมาส์อากาศแบบไจโร ไจโรพอยน์เตอร์ จอยสติ๊ก และแทร็กแพดมัลติทัชสามารถรองรับการโต้ตอบแบบสัมผัสปลอมได้ Android มีฟีเจอร์ค่าคงที่ android.hardware.faketouch ซึ่งสอดคล้องกับอุปกรณ์อินพุตแบบไม่สัมผัส (อิงตามเคอร์เซอร์) ที่มีความเที่ยงตรงสูง เช่น เมาส์หรือแทร็กแพดที่สามารถจำลองอินพุตแบบสัมผัสได้อย่างเหมาะสม (รวมถึงการรองรับท่าทางสัมผัสพื้นฐาน) และระบุว่าอุปกรณ์รองรับฟังก์ชันการทำงานของหน้าจอสัมผัสที่จำลองมาบางส่วน

หากการติดตั้งใช้งานอุปกรณ์ไม่มีหน้าจอสัมผัส แต่มีระบบอินพุตพอยน์เตอร์อื่นที่ต้องการทำให้พร้อมใช้งาน อุปกรณ์จะต้องทำดังนี้

• ควรประกาศการรองรับแฟล็กฟีเจอร์ android.hardware.faketouch

หากการติดตั้งใช้งานอุปกรณ์ประกาศการรองรับ android.hardware.faketouch จะมีลักษณะดังนี้

• [C-1-1] ต้องรายงานตำแหน่ง X และ Y แบบสัมบูรณ์บนหน้าจอของตำแหน่งเคอร์เซอร์ และแสดงเคอร์เซอร์ภาพบนหน้าจอ
• [C-1-2] ต้องรายงานเหตุการณ์การแตะด้วยรหัสการดำเนินการที่ระบุการเปลี่ยนแปลงสถานะที่เกิดขึ้นเมื่อตัวชี้เลื่อนลงหรือขึ้นบนหน้าจอ
• [C-1-3] ต้องรองรับการกดและการปล่อยตัวชี้บนออบเจ็กต์บนหน้าจอ ซึ่งจะช่วยให้ผู้ใช้จำลองการแตะออบเจ็กต์บนหน้าจอได้
• [C-1-4] ต้องรองรับการกดตัวชี้ การปล่อยตัวชี้ การกดตัวชี้แล้วปล่อยตัวชี้ในตำแหน่งเดียวกันบนออบเจ็กต์บนหน้าจอภายในเกณฑ์เวลา ซึ่งจะช่วยให้ผู้ใช้จำลองการแตะสองครั้งบนออบเจ็กต์บนหน้าจอได้
• [C-1-5] ต้องรองรับการกดตัวชี้ที่จุดใดก็ได้บนหน้าจอ การเลื่อนตัวชี้ไปยังจุดใดก็ได้บนหน้าจอ ตามด้วยการปล่อยตัวชี้ ซึ่งจะช่วยให้ผู้ใช้จำลองการลากด้วยการสัมผัสได้
• [C-1-6] ต้องรองรับการกดตัวชี้ จากนั้นอนุญาตให้ผู้ใช้ย้ายออบเจ็กต์ไปยังตำแหน่งอื่นบนหน้าจอได้อย่างรวดเร็ว แล้วปล่อยตัวชี้บนหน้าจอ ซึ่งจะช่วยให้ผู้ใช้ปัดออบเจ็กต์บนหน้าจอได้

หากการติดตั้งใช้งานอุปกรณ์ประกาศการรองรับ android.hardware.faketouch.multitouch.distinct จะมีลักษณะดังนี้

• [C-2-1] ต้องประกาศการรองรับ android.hardware.faketouch
• [C-2-2] ต้องรองรับการติดตามอินพุตพอยน์เตอร์อิสระอย่างน้อย 2 รายการที่แตกต่างกัน

หากการติดตั้งใช้งานอุปกรณ์ประกาศการรองรับ android.hardware.faketouch.multitouch.jazzhand จะมีลักษณะดังนี้

• [C-3-1] ต้องประกาศการรองรับ android.hardware.faketouch
• [C-3-2] ต้องรองรับการติดตามอินพุตพอยน์เตอร์ 5 รายการ (การติดตามมือของนิ้ว) ขึ้นไปอย่างอิสระโดยสมบูรณ์

7.2.6. การรองรับเกมคอนโทรลเลอร์

7.2.6.1. การแมปปุ่ม

การติดตั้งใช้งานอุปกรณ์

• [C-1-1] ต้องสามารถแมปเหตุการณ์ HID กับค่าคงที่ InputEvent ที่เกี่ยวข้องตามที่ระบุไว้ในตารางด้านล่าง การติดตั้งใช้งาน Android ต้นทางเป็นไปตามข้อกำหนดนี้

หากการติดตั้งใช้งานอุปกรณ์ฝังตัวควบคุมหรือจัดส่งพร้อมตัวควบคุมแยกต่างหากในกล่องซึ่งจะช่วยให้ป้อนเหตุการณ์ทั้งหมดที่แสดงในตารางด้านล่างได้ อุปกรณ์ดังกล่าวจะ

• [C-2-1] ต้องประกาศแฟล็กฟีเจอร์ android.hardware.gamepad

1 KeyEvent

2 ต้องประกาศการใช้งาน HID ข้างต้นภายใน CA ของ Game pad (0x01 0x0005)

3 การใช้งานนี้ต้องมีค่าต่ำสุดเชิงตรรกะเป็น 0 ค่าสูงสุดเชิงตรรกะเป็น 7 ค่าต่ำสุดเชิงกายภาพเป็น 0 ค่าสูงสุดเชิงกายภาพเป็น 315 หน่วยเป็นองศา และขนาดรายงานเป็น 4 ค่าตรรกะจะกำหนดเป็นการหมุนตามเข็มนาฬิกาออกจากแกนแนวตั้ง เช่น ค่าตรรกะ 0 หมายถึงไม่มีการหมุนและมีการกดปุ่มขึ้น ในขณะที่ค่าตรรกะ 1 หมายถึงการหมุน 45 องศาและมีการกดทั้งปุ่มขึ้นและปุ่มซ้าย

4 MotionEvent

1 MotionEvent

7.2.7. การควบคุมระยะไกล

ดูข้อกำหนดเฉพาะของอุปกรณ์ได้ที่ส่วนที่ 2.3.1

7.3 เซ็นเซอร์

หากการติดตั้งใช้งานอุปกรณ์มีเซ็นเซอร์ประเภทหนึ่งๆ ที่มี API ที่เกี่ยวข้องสำหรับนักพัฒนาแอปบุคคลที่สาม การติดตั้งใช้งานอุปกรณ์จะต้องใช้ API นั้นตามที่อธิบายไว้ในเอกสารประกอบของ Android SDK และเอกสารประกอบของ Android Open Source เกี่ยวกับเซ็นเซอร์

การติดตั้งใช้งานอุปกรณ์

• [C-0-1] ต้องรายงานการมีหรือไม่มีเซ็นเซอร์อย่างถูกต้องตามคลาส android.content.pm.PackageManager
• [C-0-2] ต้องแสดงรายการเซ็นเซอร์ที่รองรับอย่างถูกต้องผ่าน SensorManager.getSensorList() และวิธีการที่คล้ายกัน
• [C-0-3] ต้องทำงานอย่างสมเหตุสมผลสำหรับ API เซ็นเซอร์อื่นๆ ทั้งหมด (เช่น โดยการแสดงผล true หรือ false ตามความเหมาะสมเมื่อแอปพลิเคชันพยายามลงทะเบียน Listener ไม่เรียกใช้ Listener ของเซ็นเซอร์เมื่อไม่มีเซ็นเซอร์ที่เกี่ยวข้อง เป็นต้น)

หากการติดตั้งใช้งานอุปกรณ์มีเซ็นเซอร์ประเภทหนึ่งๆ ที่มี API ที่เกี่ยวข้องสำหรับนักพัฒนาแอปบุคคลที่สาม

• [C-1-1] ต้องรายงานการวัดเซ็นเซอร์ทั้งหมดโดยใช้ค่าระบบหน่วยวัดสากล (เมตริก) ที่เกี่ยวข้องสำหรับเซ็นเซอร์แต่ละประเภทตามที่กำหนดไว้ในเอกสารประกอบของ Android SDK
• [C-1-2] ต้องรายงานข้อมูลเซ็นเซอร์ที่มีเวลาในการตอบสนองสูงสุด 100 มิลลิวินาที + 2 * sample_time ในกรณีของสตรีมเซ็นเซอร์ที่มีเวลาในการตอบสนองที่ขอสูงสุด 0 มิลลิวินาทีเมื่อโปรเซสเซอร์แอปพลิเคชันทำงานอยู่ ความล่าช้านี้ไม่รวมความล่าช้าในการกรอง
• [C-1-3] ต้องรายงานตัวอย่างเซ็นเซอร์แรกภายใน 400 มิลลิวินาที + 2 * sample_time ของเซ็นเซอร์ที่เปิดใช้งาน ตัวอย่างนี้มีค่าความแม่นยำเป็น 0 ได้
• [C-1-4] สำหรับ API ใดๆ ที่เอกสารประกอบของ Android SDK ระบุว่าเป็นเซ็นเซอร์ต่อเนื่อง การติดตั้งใช้งานอุปกรณ์ต้องให้ตัวอย่างข้อมูลเป็นระยะอย่างต่อเนื่อง ซึ่งควรมีความผันผวนต่ำกว่า 3% โดยที่ความผันผวนหมายถึงค่าเบี่ยงเบนมาตรฐานของความแตกต่างของค่าการประทับเวลาที่รายงานระหว่างเหตุการณ์ที่ต่อเนื่องกัน
• [C-1-5] ต้องตรวจสอบว่าสตรีมเหตุการณ์เซ็นเซอร์ต้องไม่ป้องกันไม่ให้ CPU ของอุปกรณ์เข้าสู่สถานะระงับหรือปลุกจากสถานะระงับ
• [C-1-6] ต้องรายงานเวลาของเหตุการณ์ในหน่วยนาโนวินาทีตามที่กําหนดไว้ในเอกสารประกอบของ Android SDK ซึ่งแสดงเวลาที่เกิดเหตุการณ์และซิงค์กับนาฬิกา SystemClock.elapsedRealtimeNano()
• [C-SR] ขอแนะนำอย่างยิ่งให้มีข้อผิดพลาดในการซิงโครไนซ์การประทับเวลาต่ำกว่า 100 มิลลิวินาที และควรมีข้อผิดพลาดในการซิงโครไนซ์การประทับเวลาต่ำกว่า 1 มิลลิวินาที
• เมื่อเซ็นเซอร์หลายตัวทํางาน การใช้พลังงานไม่ควรเกินผลรวมของการใช้พลังงานที่รายงานของเซ็นเซอร์แต่ละตัว

รายการข้างต้นเป็นเพียงตัวอย่างบางส่วนเท่านั้น โดยพฤติกรรมที่บันทึกไว้ของ Android SDK และเอกสารประกอบแบบโอเพนซอร์สของ Android เกี่ยวกับเซ็นเซอร์ถือเป็นแหล่งข้อมูลที่เชื่อถือได้

หากการติดตั้งใช้งานอุปกรณ์มีเซ็นเซอร์ประเภทหนึ่งๆ ที่มี API ที่เกี่ยวข้องสำหรับนักพัฒนาแอปบุคคลที่สาม

• [C-1-6] ต้องตั้งค่าความละเอียดที่ไม่ใช่ 0 สำหรับเซ็นเซอร์ทั้งหมด และรายงานค่าผ่านเมธอด API Sensor.getResolution()

เซ็นเซอร์บางประเภทเป็นแบบผสม ซึ่งหมายความว่าสามารถได้มาจากข้อมูลที่เซ็นเซอร์อื่นๆ อย่างน้อย 1 ตัวให้ไว้ (ตัวอย่างเช่น เซ็นเซอร์การวางแนวและเซ็นเซอร์ความเร่งเชิงเส้น)

การติดตั้งใช้งานอุปกรณ์

• ควรใช้เซ็นเซอร์ประเภทเหล่านี้เมื่อมีเซ็นเซอร์จริงที่เป็นข้อกำหนดเบื้องต้นตามที่อธิบายไว้ในประเภทเซ็นเซอร์

หากการติดตั้งใช้งานอุปกรณ์มีเซ็นเซอร์แบบผสม อุปกรณ์จะต้องมีคุณสมบัติดังนี้

• [C-2-1] ต้องใช้เซ็นเซอร์ตามที่อธิบายไว้ในเอกสารประกอบ Android Open Source เกี่ยวกับเซ็นเซอร์แบบผสม

หากการใช้งานอุปกรณ์มีเซ็นเซอร์ประเภทหนึ่งๆ ที่มี API ที่เกี่ยวข้องสำหรับนักพัฒนาแอปบุคคลที่สาม และเซ็นเซอร์รายงานค่าเพียงค่าเดียว การใช้งานอุปกรณ์จะเป็นดังนี้

• [C-3-1] ต้องตั้งค่าความละเอียดเป็น 1 สำหรับเซ็นเซอร์และรายงานค่าผ่านเมธอด API Sensor.getResolution()

หากการใช้งานอุปกรณ์มีเซ็นเซอร์ประเภทหนึ่งที่รองรับ SensorAdditionalInfo#TYPE_VEC3_CALIBRATION และมีการเปิดเผยเซ็นเซอร์แก่นักพัฒนาแอปบุคคลที่สาม นักพัฒนาแอปเหล่านั้นจะทำสิ่งต่อไปนี้ได้

• [C-4-1] ต้องไม่รวมพารามิเตอร์การปรับเทียบที่กำหนดจากโรงงานและคงที่ไว้ในข้อมูลที่ให้

หากการติดตั้งใช้งานอุปกรณ์มีส่วนประกอบของตัววัดความเร่งแบบ 3 แกน เซ็นเซอร์ไจโรสโคปแบบ 3 แกน หรือเซ็นเซอร์เครื่องวัดค่าความเข้มข้นของสนามแม่เหล็ก จะมีลักษณะดังนี้

• [C-SR] ขอแนะนำอย่างยิ่งเพื่อให้แน่ใจว่าตัวตรวจวัดความเร่ง เครื่องวัดการหมุน และเครื่องวัดค่าความเข้มข้นของสนามแม่เหล็กมีตำแหน่งสัมพัทธ์คงที่ เพื่อให้หากอุปกรณ์แปลงสภาพได้ (เช่น พับได้) แกนเซ็นเซอร์จะยังคงสอดคล้องและสอดคล้องกับระบบพิกัดเซ็นเซอร์ตลอดสถานะการแปลงสภาพที่เป็นไปได้ทั้งหมดของอุปกรณ์

7.3.1. ตัวตรวจวัดความเร่ง

การติดตั้งใช้งานอุปกรณ์

• [C-SR] ขอแนะนำอย่างยิ่งให้รวมตัวตรวจวัดความเร่งแบบ 3 แกน

หากการติดตั้งใช้งานอุปกรณ์มีตัววัดความเร่งแบบ 3 แกน อุปกรณ์จะทำสิ่งต่อไปนี้

• [C-1-1] ต้องรายงานเหตุการณ์ได้ด้วยความถี่อย่างน้อย 50 Hz
• [C-1-2] ต้องใช้และรายงานเซ็นเซอร์TYPE_ACCELEROMETER
• [C-1-3] ต้องเป็นไปตามระบบพิกัดเซ็นเซอร์ของ Android ตามที่ระบุไว้ใน Android API
• [C-1-4] ต้องวัดได้ตั้งแต่การตกอย่างอิสระจนถึง 4 เท่าของแรงโน้มถ่วง(4g) ขึ้นไปในแกนใดก็ได้
• [C-1-5] ต้องมีความละเอียดอย่างน้อย 12 บิต
• [C-1-6] ต้องมีค่าเบี่ยงเบนมาตรฐานไม่เกิน 0.05 ม./วินาที^ โดยควรคำนวณค่าเบี่ยงเบนมาตรฐานต่อแกนจากตัวอย่างที่รวบรวมในช่วงเวลาอย่างน้อย 3 วินาทีที่อัตราการสุ่มตัวอย่างที่เร็วที่สุด
• [SR] ขอแนะนำเป็นอย่างยิ่งให้ใช้TYPE_SIGNIFICANT_MOTIONเซ็นเซอร์แบบผสม
• [SR] ขอแนะนำเป็นอย่างยิ่งให้ติดตั้งใช้งานและรายงานเซ็นเซอร์ TYPE_ACCELEROMETER_UNCALIBRATED ขอแนะนำอย่างยิ่งให้ใช้อุปกรณ์ Android ที่เป็นไปตามข้อกำหนดนี้ เพื่อให้อัปเกรดเป็นแพลตฟอร์มเวอร์ชันในอนาคตได้ ซึ่งอาจต้องใช้ข้อกำหนดนี้
• ควรใช้เซ็นเซอร์แบบผสม TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER ตามที่อธิบายไว้ในเอกสาร Android SDK
• ควรรายงานเหตุการณ์ที่ความถี่อย่างน้อย 200 Hz
• ควรมีความละเอียดอย่างน้อย 16 บิต
• ควรได้รับการปรับเทียบขณะใช้งานหากลักษณะเปลี่ยนแปลงตลอดวงจรการใช้งานและได้รับการชดเชย และเก็บรักษาพารามิเตอร์การชดเชยระหว่างการรีบูตอุปกรณ์
• ควรมีการชดเชยอุณหภูมิ

หากการใช้งานอุปกรณ์มีมาตรวัดความเร่ง 3 แกนและมีการใช้งานเซ็นเซอร์แบบผสม TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER อย่างใดอย่างหนึ่ง

• [C-2-1] ผลรวมของการใช้พลังงานต้องน้อยกว่า 4 mW เสมอ
• ควรมีกำลังต่ำกว่า 2 มิลลิวัตต์และ 0.5 มิลลิวัตต์เมื่ออุปกรณ์อยู่ในสภาวะไดนามิกหรือสภาวะคงที่

หากการติดตั้งใช้งานอุปกรณ์มีตัววัดความเร่งแบบ 3 แกนและเซ็นเซอร์ไจโรสโคปแบบ 3 แกน อุปกรณ์จะต้องมีคุณสมบัติดังนี้

• [C-3-1] ต้องใช้เซ็นเซอร์ผสม TYPE_GRAVITY และ TYPE_LINEAR_ACCELERATION
• [C-SR] ขอแนะนำเป็นอย่างยิ่งให้ใช้เซ็นเซอร์แบบผสม TYPE_GAME_ROTATION_VECTOR

หากการติดตั้งใช้งานอุปกรณ์มีตัววัดความเร่งแบบ 3 แกน ไจโรสโคปแบบ 3 แกน และเซ็นเซอร์เครื่องวัดค่าความเข้มข้นของสนามแม่เหล็ก อุปกรณ์จะทำสิ่งต่อไปนี้

• [C-4-1] ต้องใช้TYPE_ROTATION_VECTORเซ็นเซอร์ผสม

7.3.2. เครื่องวัดค่าความเข้มข้นของสนามแม่เหล็ก

การติดตั้งใช้งานอุปกรณ์

• [C-SR] ขอแนะนำอย่างยิ่งให้มีเครื่องวัดสนามแม่เหล็กแบบ 3 แกน (เข็มทิศ)

หากการใช้งานอุปกรณ์มีแมกนีโตมิเตอร์ 3 แกน อุปกรณ์จะทำสิ่งต่อไปนี้

• [C-1-1] ต้องติดตั้งใช้งานTYPE_MAGNETIC_FIELDเซ็นเซอร์
• [C-1-2] ต้องรายงานเหตุการณ์ได้ด้วยความถี่อย่างน้อย 10 Hz และควรรายงานเหตุการณ์ได้ด้วยความถี่อย่างน้อย 50 Hz
• [C-1-3] ต้องเป็นไปตามระบบพิกัดเซ็นเซอร์ของ Android ตามที่ระบุไว้ใน Android API
• [C-1-4] ต้องวัดค่าได้ระหว่าง -900 µT ถึง +900 µT ในแต่ละแกนก่อนที่จะอิ่มตัว
• [C-1-5] ต้องมีค่าออฟเซ็ตของเหล็กกล้าต่ำกว่า 700 µT และควรมีค่าต่ำกว่า 200 µT โดยวางแมกนีโตมิเตอร์ให้ห่างจากสนามแม่เหล็กแบบไดนามิก (เกิดจากกระแส) และแบบคงที่ (เกิดจากแม่เหล็ก)
• [C-1-6] ต้องมีความละเอียดเท่ากับหรือหนาแน่นกว่า 0.6 µT
• [C-1-7] ต้องรองรับการปรับเทียบและการชดเชยอคติของฮาร์ดไอรอนแบบออนไลน์ และเก็บรักษาพารามิเตอร์การชดเชยระหว่างการรีบูตอุปกรณ์
• [C-1-8] ต้องมีการชดเชยเหล็กอ่อน การปรับเทียบสามารถทำได้ทั้งขณะใช้งานหรือระหว่างการผลิตอุปกรณ์
• [C-1-9] ต้องมีค่าเบี่ยงเบนมาตรฐานที่คำนวณตามแกนแต่ละแกนจากตัวอย่างที่รวบรวมในช่วงเวลาอย่างน้อย 3 วินาทีที่อัตราการสุ่มตัวอย่างที่เร็วที่สุด โดยต้องไม่เกิน 1.5 µT และควรมีค่าเบี่ยงเบนมาตรฐานไม่เกิน 0.5 µT
• [C-SR] ขอแนะนำเป็นอย่างยิ่งให้ติดตั้งใช้งานเซ็นเซอร์ TYPE_MAGNETIC_FIELD_UNCALIBRATED

หากการติดตั้งใช้งานอุปกรณ์มีเครื่องวัดค่าความเข้มข้นของสนามแม่เหล็กแบบ 3 แกน เซ็นเซอร์ตัวตรวจวัดความเร่ง และเซ็นเซอร์ไจโรสโคปแบบ 3 แกน จะมีลักษณะดังนี้

• [C-2-1] ต้องใช้TYPE_ROTATION_VECTORเซ็นเซอร์ผสม

หากการติดตั้งใช้งานอุปกรณ์มีแมกนีโตมิเตอร์แบบ 3 แกนและตัววัดความเร่ง จะมีลักษณะดังนี้

• MAY จะติดตั้งใช้งานเซ็นเซอร์ TYPE_GEOMAGNETIC_ROTATION_VECTOR

หากการติดตั้งใช้งานอุปกรณ์มีเครื่องวัดค่าความเข้มข้นของสนามแม่เหล็กแบบ 3 แกน ตัวตรวจวัดความเร่ง และเซ็นเซอร์ TYPE_GEOMAGNETIC_ROTATION_VECTOR อุปกรณ์ดังกล่าวจะทำสิ่งต่อไปนี้

• [C-3-1] ต้องใช้พลังงานน้อยกว่า 10 mW
• ควรใช้พลังงานน้อยกว่า 3 mW เมื่อลงทะเบียนเซ็นเซอร์สำหรับโหมดเป็นกลุ่มที่ 10 Hz

7.3.3. GPS

การติดตั้งใช้งานอุปกรณ์

• [C-SR] ขอแนะนำอย่างยิ่งให้มีเครื่องรับ GPS/GNSS

หากการติดตั้งใช้งานอุปกรณ์มีเครื่องรับ GPS/GNSS และรายงานความสามารถไปยังแอปพลิเคชันผ่านแฟล็กฟีเจอร์ android.hardware.location.gps อุปกรณ์จะทำสิ่งต่อไปนี้

• [C-1-1] ต้องรองรับเอาต์พุตตำแหน่งที่อัตราอย่างน้อย 1 Hz เมื่อมีการขอผ่าน LocationManager#requestLocationUpdate
• [C-1-2] ต้องระบุตำแหน่งในสภาพท้องฟ้าเปิด (สัญญาณแรง, มัลติพาธน้อยมาก, HDOP < 2) ได้ภายใน 10 วินาที (เวลาในการหาตำแหน่งครั้งแรกอย่างรวดเร็ว) เมื่อเชื่อมต่อกับอินเทอร์เน็ตที่มีความเร็วในการรับส่งข้อมูลตั้งแต่ 0.5 Mbps ขึ้นไป โดยปกติแล้ว ข้อกำหนดนี้จะได้รับการตอบสนองด้วยการใช้เทคนิค GPS/GNSS รูปแบบใดรูปแบบหนึ่งที่ช่วยหรือคาดการณ์เพื่อลดเวลาการล็อก GPS/GNSS (ข้อมูลความช่วยเหลือประกอบด้วยเวลาอ้างอิง ตำแหน่งอ้างอิง และเอฟีเมอริส/นาฬิกาของดาวเทียม)
  • [C-1-6] หลังจากทำการคำนวณตำแหน่งดังกล่าวแล้ว การติดตั้งใช้งานอุปกรณ์ต้องกำหนดตำแหน่งในที่โล่งภายใน 5 วินาที เมื่อมีการรีสตาร์ทคำขอตำแหน่ง นานถึง 1 ชั่วโมงหลังจากคำนวณตำแหน่งครั้งแรก แม้ว่าคำขอที่ตามมาจะทำโดยไม่มีการเชื่อมต่อข้อมูล และ/หรือหลังจากเปิดปิดเครื่อง

• ในสภาพท้องฟ้าเปิดหลังจากกำหนดตำแหน่งแล้ว ขณะที่อยู่กับที่หรือเคลื่อนที่ด้วยความเร่งน้อยกว่า 1 เมตรต่อวินาทีกำลังสอง

  • [C-1-3] ต้องระบุตำแหน่งภายใน 20 เมตร และความเร็วภายใน 0.5 เมตรต่อวินาทีได้อย่างน้อย 95% ของเวลาทั้งหมด
  • [C-1-4] ต้องติดตามและรายงานผ่าน GnssStatus.Callback พร้อมกันอย่างน้อย 8 ดาวเทียมจากกลุ่มดาวเดียวกัน
  • ควรติดตามดาวเทียมอย่างน้อย 24 ดวงจากกลุ่มดาวหลายกลุ่มได้พร้อมกัน (เช่น GPS + Glonass, Beidou หรือ Galileo อย่างน้อย 1 กลุ่ม)
  • [C-SR] ขอแนะนำอย่างยิ่งให้ส่งเอาต์พุตตำแหน่ง GPS/GNSS ตามปกติผ่าน GNSS Location Provider API ต่อไปในระหว่างการโทรฉุกเฉิน
  • [C-SR] ขอแนะนําอย่างยิ่งให้รายงานการวัด GNSS จากกลุ่มดาวเทียมทั้งหมดที่ติดตาม (ตามที่รายงานในข้อความ GnssStatus) ยกเว้น SBAS
  • [C-SR] ขอแนะนําอย่างยิ่งให้รายงาน AGC และความถี่ของการวัด GNSS
  • [C-SR] ขอแนะนำอย่างยิ่งให้รายงานค่าประมาณความแม่นยำทั้งหมด (รวมถึง Bearing, Speed และ Vertical) เป็นส่วนหนึ่งของตำแหน่ง GPS/GNSS แต่ละตำแหน่ง
  • [C-SR] ขอแนะนำอย่างยิ่งให้รายงานการวัด GNSS ทันทีที่พบ แม้ว่าจะยังไม่ได้รายงานตำแหน่งที่คำนวณจาก GPS/GNSS ก็ตาม
  • [C-SR] ขอแนะนำอย่างยิ่งให้รายงานระยะเทียม GNSS และอัตราการเปลี่ยนแปลงของระยะเทียม ซึ่งในสภาพท้องฟ้าเปิดหลังจากกำหนดตำแหน่งแล้ว ขณะที่อยู่กับที่หรือเคลื่อนที่ด้วยความเร่งน้อยกว่า 0.2 เมตรต่อวินาทีกำลังสอง จะเพียงพอต่อการคำนวณตำแหน่งภายใน 20 เมตร และความเร็วภายใน 0.2 เมตรต่อวินาที อย่างน้อย 95% ของเวลา

7.3.4. เครื่องวัดการหมุน

การติดตั้งใช้งานอุปกรณ์

• [C-SR] ขอแนะนำอย่างยิ่งให้มีเซ็นเซอร์ไจโรสโคป

หากการใช้งานอุปกรณ์มีไจโรสโคปแบบ 3 แกน อุปกรณ์จะต้องมีคุณสมบัติดังนี้

• [C-1-1] ต้องรายงานเหตุการณ์ได้ด้วยความถี่อย่างน้อย 50 Hz
• [C-1-2] ต้องใช้เซ็นเซอร์ TYPE_GYROSCOPE และขอแนะนำอย่างยิ่งให้ใช้เซ็นเซอร์ TYPE_GYROSCOPE_UNCALIBRATED ด้วย
• [C-1-4] ต้องมีความละเอียด 12 บิตขึ้นไป และควรมีความละเอียด 16 บิตขึ้นไป
• [C-1-5] ต้องมีการชดเชยอุณหภูมิ
• [C-1-6] ต้องได้รับการปรับเทียบและชดเชยขณะใช้งาน และรักษาพารามิเตอร์การชดเชยระหว่างการรีบูตอุปกรณ์
• [C-1-7] ต้องมีความแปรปรวนไม่เกิน 1e-7 rad^2 / s^2 ต่อ Hz (ความแปรปรวนต่อ Hz หรือ rad^2 / s) ความแปรปรวนอาจแตกต่างกันไปตามอัตราการสุ่มตัวอย่าง แต่ต้องถูกจำกัดด้วยค่านี้ กล่าวคือ หากคุณวัดความแปรปรวนของไจโรที่อัตราการสุ่มตัวอย่าง 1 Hz ความแปรปรวนดังกล่าวไม่ควรเกิน 1e-7 rad^2/s^2
• [SR] ขอแนะนำอย่างยิ่งว่าข้อผิดพลาดในการปรับเทียบควรน้อยกว่า 0.01 เรเดียน/วินาที เมื่ออุปกรณ์อยู่กับที่ที่อุณหภูมิห้อง
• ควรรายงานเหตุการณ์ที่ความถี่อย่างน้อย 200 Hz

หากการติดตั้งใช้งานอุปกรณ์มีไจโรสโคปแบบ 3 แกน เซ็นเซอร์ตัวตรวจวัดความเร่ง และเซ็นเซอร์เครื่องวัดค่าความเข้มข้นของสนามแม่เหล็ก อุปกรณ์ดังกล่าวจะทำสิ่งต่อไปนี้

• [C-2-1] ต้องใช้TYPE_ROTATION_VECTORเซ็นเซอร์ผสม

หากการติดตั้งใช้งานอุปกรณ์มีตัววัดความเร่งแบบ 3 แกนและเซ็นเซอร์ไจโรสโคปแบบ 3 แกน อุปกรณ์จะต้องมีคุณสมบัติดังนี้

• [C-3-1] ต้องใช้เซ็นเซอร์ผสม TYPE_GRAVITY และ TYPE_LINEAR_ACCELERATION
• [C-SR] ขอแนะนำเป็นอย่างยิ่งให้ใช้เซ็นเซอร์แบบผสม TYPE_GAME_ROTATION_VECTOR

7.3.5. บารอมิเตอร์

การติดตั้งใช้งานอุปกรณ์

• [C-SR] ขอแนะนำอย่างยิ่งให้มีบารอมิเตอร์ (เซ็นเซอร์ความดันอากาศโดยรอบ)

หากการติดตั้งใช้งานอุปกรณ์มีบารอมิเตอร์ อุปกรณ์จะทำสิ่งต่อไปนี้

• [C-1-1] ต้องใช้และรายงานTYPE_PRESSUREเซ็นเซอร์
• [C-1-2] ต้องส่งเหตุการณ์ที่ 5 Hz ขึ้นไปได้
• [C-1-3] ต้องมีการชดเชยอุณหภูมิ
• [SR] ขอแนะนำอย่างยิ่งเพื่อให้สามารถรายงานการวัดความดันในช่วง 300hPa ถึง 1100hPa
• ควรมีความแม่นยำสัมบูรณ์ 1 hPa
• ควรมีความแม่นยำสัมพัทธ์ 0.12hPa ในช่วง 20hPa (เทียบเท่ากับความแม่นยำ ~1 ม. ในการเปลี่ยนแปลง ~200 ม. ที่ระดับน้ำทะเล)

7.3.6. เทอร์โมมิเตอร์

หากการติดตั้งใช้งานอุปกรณ์มีเทอร์โมมิเตอร์วัดอุณหภูมิโดยรอบ (เซ็นเซอร์อุณหภูมิ) อุปกรณ์ดังกล่าวจะต้องมีคุณสมบัติดังนี้

• [C-1-1] ต้องกำหนด SENSOR_TYPE_AMBIENT_TEMPERATURE สำหรับเซ็นเซอร์อุณหภูมิแวดล้อม และเซ็นเซอร์ต้องวัดอุณหภูมิแวดล้อม (ห้อง/ห้องโดยสารของยานพาหนะ) จากตำแหน่งที่ผู้ใช้โต้ตอบกับอุปกรณ์เป็นองศาเซลเซียส

หากการติดตั้งใช้งานอุปกรณ์มีเซ็นเซอร์เทอร์โมมิเตอร์ที่วัดอุณหภูมิอื่นที่ไม่ใช่อุณหภูมิแวดล้อม เช่น อุณหภูมิ CPU อุปกรณ์ดังกล่าวจะต้องมีคุณสมบัติดังนี้

• [C-2-1] ต้องไม่กำหนด SENSOR_TYPE_AMBIENT_TEMPERATURE สำหรับเซ็นเซอร์อุณหภูมิ

7.3.7. โฟโตมิเตอร์

• การติดตั้งใช้งานอุปกรณ์อาจมีโฟโตมิเตอร์ (เซ็นเซอร์แสงแวดล้อม)

7.3.8. พร็อกซิมิตีเซ็นเซอร์

• การติดตั้งใช้งานอุปกรณ์อาจมีพร็อกซิมิตีเซ็นเซอร์

หากการติดตั้งใช้งานอุปกรณ์มีพร็อกซิมิตีเซ็นเซอร์ อุปกรณ์จะทำสิ่งต่อไปนี้

• [C-1-1] ต้องวัดระยะใกล้ของวัตถุในทิศทางเดียวกับหน้าจอ กล่าวคือ พร็อกซิมิตีเซ็นเซอร์ต้องหันไปตรวจจับวัตถุที่อยู่ใกล้หน้าจอ เนื่องจากจุดประสงค์หลักของเซ็นเซอร์ประเภทนี้คือการตรวจจับโทรศัพท์ที่ผู้ใช้กำลังใช้งาน หากการใช้งานอุปกรณ์มีพร็อกซิมิตีเซ็นเซอร์ที่มีการวางแนวอื่นใด จะต้องไม่สามารถเข้าถึงได้ผ่าน API นี้
• [C-1-2] ต้องมีความแม่นยำ 1 บิตขึ้นไป

7.3.9. เซ็นเซอร์ที่มีความแม่นยำสูง

หากการติดตั้งใช้งานอุปกรณ์มีชุดเซ็นเซอร์คุณภาพสูงกว่าตามที่กำหนดไว้ในส่วนนี้ และทำให้แอปของบุคคลที่สามใช้งานได้ อุปกรณ์ดังกล่าวจะทำสิ่งต่อไปนี้

• [C-1-1] ต้องระบุความสามารถผ่านแฟล็กฟีเจอร์ android.hardware.sensor.hifi_sensors

หากการติดตั้งใช้งานอุปกรณ์ประกาศ android.hardware.sensor.hifi_sensors จะมีข้อกำหนดดังนี้

• [C-2-1] ต้องมีเซ็นเซอร์ TYPE_ACCELEROMETER ซึ่งมีคุณสมบัติดังนี้

  • ต้องมีช่วงการวัดอย่างน้อยระหว่าง -8g ถึง +8g และขอแนะนำอย่างยิ่งให้มีช่วงการวัดอย่างน้อยระหว่าง -16g ถึง +16g
  • ต้องมีความละเอียดในการวัดอย่างน้อย 2048 LSB/g
  • ต้องมีความถี่ในการวัดขั้นต่ำ 12.5 Hz หรือต่ำกว่า
  • ต้องมีความถี่ในการวัดสูงสุด 400 Hz ขึ้นไป และควรรองรับ SensorDirectChannel RATE_VERY_FAST
  • ต้องมีสัญญาณรบกวนจากการวัดไม่เกิน 400 μg/√Hz
  • ต้องใช้เซ็นเซอร์รูปแบบที่ไม่ใช่การปลุกนี้ที่มีความสามารถในการบัฟเฟอร์เหตุการณ์เซ็นเซอร์อย่างน้อย 3,000 รายการ
  • ต้องมีการใช้พลังงานแบบกลุ่มไม่เกิน 3 มิลลิวัตต์
  • [C-SR] ขอแนะนำอย่างยิ่งให้มีแบนด์วิดท์การวัด 3dB อย่างน้อย 80% ของความถี่ Nyquist และสเปกตรัมไวท์นอยส์ภายในแบนด์วิดท์นี้
  • ควรมีการเดินแบบสุ่มของการเร่งความเร็วที่น้อยกว่า 30 μg √Hz ซึ่งทดสอบที่อุณหภูมิห้อง
  • ควรมีการเปลี่ยนแปลงอคติเทียบกับอุณหภูมิ ≤ +/- 1 มก./°C
  • ควรมีเส้นแนวโน้มที่เหมาะสมที่สุดซึ่งมีความไม่เชิงเส้น ≤ 0.5% และการเปลี่ยนแปลงความไวเทียบกับอุณหภูมิ ≤ 0.03%/C°
  • ควรมีความไวต่อแกนขวางน้อยกว่า 2.5 % และความแปรปรวนของความไวต่อแกนขวางน้อยกว่า 0.2% ในช่วงอุณหภูมิการทำงานของอุปกรณ์

• [C-2-2] ต้องมี TYPE_ACCELEROMETER_UNCALIBRATED ที่มีข้อกำหนดด้านคุณภาพเดียวกันกับ TYPE_ACCELEROMETER

• [C-2-3] ต้องมีเซ็นเซอร์ TYPE_GYROSCOPE ซึ่งมีคุณสมบัติดังนี้

  • ต้องมีช่วงการวัดอย่างน้อยระหว่าง -1000 ถึง +1000 dps
  • ต้องมีความละเอียดในการวัดอย่างน้อย 16 LSB/dps
  • ต้องมีความถี่ในการวัดขั้นต่ำ 12.5 Hz หรือต่ำกว่า
  • ต้องมีความถี่ในการวัดสูงสุด 400 Hz ขึ้นไป และควรรองรับ SensorDirectChannel RATE_VERY_FAST
  • ต้องมีสัญญาณรบกวนในการวัดไม่เกิน 0.014°/s/√Hz
  • [C-SR] ขอแนะนำอย่างยิ่งให้มีแบนด์วิดท์การวัด 3dB อย่างน้อย 80% ของความถี่ Nyquist และสเปกตรัมไวท์นอยส์ภายในแบนด์วิดท์นี้
  • ควรมีการเดินแบบสุ่มของอัตราที่น้อยกว่า 0.001 °/s √Hz ซึ่งทดสอบที่อุณหภูมิห้อง
  • ควรมีการเปลี่ยนแปลงอคติเทียบกับอุณหภูมิ ≤ +/- 0.05 °/ วินาที / °C
  • ควรมีการเปลี่ยนแปลงความไวเทียบกับอุณหภูมิ ≤ 0.02% / °C
  • ควรมีเส้นที่เหมาะสมที่สุดซึ่งมีความไม่เชิงเส้น ≤ 0.2%
  • ควรมีความหนาแน่นของสัญญาณรบกวน ≤ 0.007 °/s/√Hz
  • ควรมีข้อผิดพลาดในการปรับเทียบน้อยกว่า 0.002 เรเดียน/วินาที ในช่วงอุณหภูมิ 10 ~ 40 ℃ เมื่ออุปกรณ์อยู่กับที่
  • ควรมีความไวต่อแรงโน้มถ่วงน้อยกว่า 0.1°/s/g
  • ควรมีความไวต่อแกนขวางน้อยกว่า 4.0 % และความแปรปรวนของความไวต่อแกนขวางน้อยกว่า 0.3% ในช่วงอุณหภูมิการทำงานของอุปกรณ์

• [C-2-4] ต้องมี TYPE_GYROSCOPE_UNCALIBRATED ที่มีข้อกำหนดด้านคุณภาพเดียวกันกับ TYPE_GYROSCOPE

• [C-2-5] ต้องมีเซ็นเซอร์ TYPE_GEOMAGNETIC_FIELD ซึ่งมีคุณสมบัติดังนี้

  • ต้องมีช่วงการวัดระหว่าง -900 ถึง +900 μT เป็นอย่างน้อย
  • ต้องมีความละเอียดในการวัดอย่างน้อย 5 LSB/uT
  • ต้องมีความถี่ในการวัดอย่างน้อย 5 Hz หรือต่ำกว่า
  • ต้องมีความถี่ในการวัดสูงสุด 50 Hz ขึ้นไป
  • ต้องมีสัญญาณรบกวนในการวัดไม่เกิน 0.5 uT

• [C-2-6] ต้องมี TYPE_MAGNETIC_FIELD_UNCALIBRATED ที่มีข้อกำหนดด้านคุณภาพเดียวกันกับ TYPE_GEOMAGNETIC_FIELD และนอกจากนี้

  • ต้องใช้เซ็นเซอร์รูปแบบที่ไม่ใช่การปลุกที่มีความสามารถในการบัฟเฟอร์เหตุการณ์ของเซ็นเซอร์อย่างน้อย 600 รายการ
  • [C-SR] ขอแนะนำอย่างยิ่งให้มีสเปกตรัมไวท์นอยส์ตั้งแต่ 1 Hz ถึงอย่างน้อย 10 Hz เมื่ออัตราการรายงานอยู่ที่ 50 Hz ขึ้นไป

• [C-2-7] ต้องมีเซ็นเซอร์ TYPE_PRESSURE ซึ่งมีคุณสมบัติดังนี้

  • ต้องมีช่วงการวัดระหว่าง 300 ถึง 1100 hPa เป็นอย่างน้อย
  • ต้องมีความละเอียดในการวัดอย่างน้อย 80 LSB/hPa
  • ต้องมีความถี่ในการวัดขั้นต่ำที่ 1 Hz หรือต่ำกว่า
  • ต้องมีความถี่ในการวัดสูงสุด 10 Hz ขึ้นไป
  • ต้องมีสัญญาณรบกวนในการวัดไม่เกิน 2 Pa/√Hz
  • ต้องใช้เซ็นเซอร์รูปแบบที่ไม่ใช่การปลุกที่มีความสามารถในการบัฟเฟอร์เหตุการณ์เซ็นเซอร์อย่างน้อย 300 รายการ
  • ต้องมีการใช้พลังงานแบบกลุ่มไม่เกิน 2 มิลลิวัตต์
• [C-2-8] ต้องมีเซ็นเซอร์ TYPE_GAME_ROTATION_VECTOR
• [C-2-9] ต้องมีเซ็นเซอร์ TYPE_SIGNIFICANT_MOTION ซึ่งมีลักษณะดังนี้
  • ต้องมีอัตราการใช้พลังงานไม่เกิน 0.5 มิลลิวัตต์เมื่ออุปกรณ์อยู่กับที่ และ 1.5 มิลลิวัตต์เมื่ออุปกรณ์เคลื่อนที่
• [C-2-10] ต้องมีเซ็นเซอร์ TYPE_STEP_DETECTOR ซึ่งมีลักษณะดังนี้
  • ต้องใช้เซ็นเซอร์รูปแบบที่ไม่ใช่การปลุกนี้ที่มีความสามารถในการบัฟเฟอร์เหตุการณ์เซ็นเซอร์อย่างน้อย 100 รายการ
  • ต้องมีอัตราการใช้พลังงานไม่เกิน 0.5 มิลลิวัตต์เมื่ออุปกรณ์อยู่กับที่ และ 1.5 มิลลิวัตต์เมื่ออุปกรณ์เคลื่อนที่
  • ต้องมีการใช้พลังงานแบบกลุ่มไม่แย่กว่า 4 มิลลิวัตต์
• [C-2-11] ต้องมีเซ็นเซอร์ TYPE_STEP_COUNTER ซึ่งมีลักษณะดังนี้
  • ต้องมีอัตราการใช้พลังงานไม่เกิน 0.5 มิลลิวัตต์เมื่ออุปกรณ์อยู่กับที่ และ 1.5 มิลลิวัตต์เมื่ออุปกรณ์เคลื่อนที่
• [C-2-12] ต้องมีเซ็นเซอร์ TILT_DETECTOR ซึ่งมีลักษณะดังนี้
  • ต้องมีอัตราการใช้พลังงานไม่เกิน 0.5 มิลลิวัตต์เมื่ออุปกรณ์อยู่กับที่ และ 1.5 มิลลิวัตต์เมื่ออุปกรณ์เคลื่อนที่
• [C-2-13] การประทับเวลาของเหตุการณ์ทางกายภาพเดียวกันที่รายงานโดยเครื่องวัดความเร่ง ไจโรสโคป และเครื่องวัดสนามแม่เหล็กต้องอยู่ภายใน 2.5 มิลลิวินาทีของกันและกัน การประทับเวลาเหตุการณ์ของเหตุการณ์ทางกายภาพเดียวกันที่รายงานโดยเครื่องวัดความเร่งและไจโรสโคปควรอยู่ภายใน 0.25 มิลลิวินาทีของกันและกัน
• [C-2-14] ต้องมีการประทับเวลาของเหตุการณ์เซ็นเซอร์ไจโรสโคปบนฐานเวลาเดียวกันกับระบบย่อยของกล้องและมีข้อผิดพลาดไม่เกิน 1 มิลลิวินาที
• [C-2-15] ต้องส่งตัวอย่างไปยังแอปพลิเคชันภายใน 5 มิลลิวินาทีนับจากเวลาที่ข้อมูลพร้อมใช้งานในเซ็นเซอร์จริงข้างต้นไปยังแอปพลิเคชัน
• [C-2-16] ต้องมีอัตราการใช้พลังงานไม่เกิน 0.5 มิลลิวัตต์เมื่ออุปกรณ์อยู่กับที่ และ 2.0 มิลลิวัตต์เมื่ออุปกรณ์เคลื่อนที่เมื่อเปิดใช้เซ็นเซอร์ต่อไปนี้ร่วมกัน
  • SENSOR_TYPE_SIGNIFICANT_MOTION
  • SENSOR_TYPE_STEP_DETECTOR
  • SENSOR_TYPE_STEP_COUNTER
  • SENSOR_TILT_DETECTORS
• [C-2-17] อาจมีTYPE_PROXIMITYเซ็นเซอร์ แต่หากมีจะต้องมีความสามารถในการบัฟเฟอร์อย่างน้อย 100 เหตุการณ์จากเซ็นเซอร์

โปรดทราบว่าข้อกำหนดการใช้พลังงานทั้งหมดในส่วนนี้ไม่รวมการใช้พลังงานของ Application Processor ซึ่งรวมถึงกำลังไฟที่ใช้โดยห่วงโซ่เซ็นเซอร์ทั้งหมด ได้แก่ เซ็นเซอร์ วงจรที่รองรับ ระบบประมวลผลเซ็นเซอร์เฉพาะ ฯลฯ

หากการใช้งานอุปกรณ์รวมถึงการรองรับเซ็นเซอร์โดยตรง อุปกรณ์จะทำสิ่งต่อไปนี้

• [C-3-1] ต้องประกาศการรองรับประเภทแชแนลโดยตรงและระดับอัตราการรายงานโดยตรงอย่างถูกต้องผ่าน API isDirectChannelTypeSupported และ getHighestDirectReportRateLevel
• [C-3-2] ต้องรองรับประเภทช่องทางเซ็นเซอร์โดยตรงอย่างน้อย 1 ประเภทจาก 2 ประเภทสำหรับเซ็นเซอร์ทั้งหมดที่ประกาศว่ารองรับช่องทางเซ็นเซอร์โดยตรง
  • TYPE_HARDWARE_BUFFER
  • TYPE_MEMORY_FILE
• ควรรองรับการรายงานเหตุการณ์ผ่านช่องทางเซ็นเซอร์โดยตรงสำหรับเซ็นเซอร์หลัก (รุ่นที่ไม่ใช่การปลุก) ของประเภทต่อไปนี้
  • TYPE_ACCELEROMETER
  • TYPE_ACCELEROMETER_UNCALIBRATED
  • TYPE_GYROSCOPE
  • TYPE_GYROSCOPE_UNCALIBRATED
  • TYPE_MAGNETIC_FIELD
  • TYPE_MAGNETIC_FIELD_UNCALIBRATED

7.3.10. เซ็นเซอร์ไบโอเมตริก

ดูข้อมูลพื้นฐานเพิ่มเติมเกี่ยวกับการวัดความปลอดภัยของการปลดล็อกด้วยไบโอเมตริกได้ที่เอกสารประกอบเกี่ยวกับการวัดความปลอดภัยของไบโอเมตริก

หากการใช้งานอุปกรณ์มีหน้าจอล็อกที่ปลอดภัย อุปกรณ์จะต้องมีคุณสมบัติดังนี้

• ควรมีเซ็นเซอร์ไบโอเมตริก

เซ็นเซอร์ไบโอเมตริกสามารถจัดประเภทเป็นคลาส 3 (เดิมคือแข็งแกร่ง) คลาส 2 (เดิมคืออ่อน) หรือคลาส 1 (เดิมคือสะดวก) โดยอิงตามอัตราการยอมรับการสวมรอยและการแอบอ้างเป็นบุคคลอื่น รวมถึงความปลอดภัยของไปป์ไลน์ไบโอเมตริก การจัดประเภทนี้จะกำหนดความสามารถของเซ็นเซอร์ไบโอเมตริกในการเชื่อมต่อกับแพลตฟอร์มและแอปพลิเคชันของบุคคลที่สาม เซ็นเซอร์จะได้รับการจัดประเภทเป็นคลาส 1 โดยค่าเริ่มต้น และต้องเป็นไปตามข้อกำหนดเพิ่มเติมตามรายละเอียดด้านล่างหากต้องการจัดประเภทเป็นคลาส 2 หรือคลาส 3 ทั้งไบโอเมตริกคลาส 2 และคลาส 3 จะได้รับความสามารถเพิ่มเติมตามที่ระบุไว้ด้านล่าง

หากการติดตั้งใช้งานอุปกรณ์ทำให้เซ็นเซอร์ไบโอเมตริกพร้อมใช้งานสำหรับแอปพลิเคชันของบุคคลที่สามผ่าน android.hardware.biometrics.BiometricManager, android.hardware.biometrics.BiometricPrompt และ android.provider.Settings.ACTION_BIOMETRIC_ENROLL แอปพลิเคชันดังกล่าวจะทำสิ่งต่อไปนี้

• [C-4-1] ต้องเป็นไปตามข้อกำหนดสำหรับไบโอเมตริกคลาส 3 หรือคลาส 2 ตามที่กำหนดไว้ในเอกสารนี้
• [C-4-2] ต้องจดจำและใช้ชื่อพารามิเตอร์แต่ละชื่อที่กำหนดเป็นค่าคงที่ในคลาส Authenticators และการผสมผสานใดๆ ของพารามิเตอร์เหล่านั้น ในทางกลับกัน จะต้องไม่ยอมรับหรือรับรู้ค่าคงที่จำนวนเต็มที่ส่งไปยังเมธอด canAuthenticate(int) และ setAllowedAuthenticators(int) นอกเหนือจากค่าคงที่สาธารณะที่ระบุไว้ใน Authenticators และการรวมกันของค่าคงที่เหล่านั้น
• [C-4-3] ต้องใช้การดำเนินการ ACTION_BIOMETRIC_ENROLL ในอุปกรณ์ที่มีข้อมูลไบโอเมตริกระดับ 3 หรือระดับ 2 การดำเนินการนี้ต้องแสดงเฉพาะจุดแรกเข้าของการลงทะเบียนสำหรับข้อมูลไบโอเมตริกระดับ 3 หรือระดับ 2 เท่านั้น

หากการติดตั้งใช้งานอุปกรณ์รองรับไบโอเมตริกแบบพาสซีฟ อุปกรณ์จะทำสิ่งต่อไปนี้

• [C-5-1] ต้องกำหนดให้มีขั้นตอนการยืนยันเพิ่มเติมโดยค่าเริ่มต้น (เช่น การกดปุ่ม)
• [C-SR] ขอแนะนำอย่างยิ่งให้มีการตั้งค่าที่อนุญาตให้ผู้ใช้ลบล้างค่ากำหนดของแอปพลิเคชันและกำหนดให้มีขั้นตอนการยืนยันประกอบเสมอ
• [C-SR] ขอแนะนำอย่างยิ่งให้ดำเนินการยืนยันอย่างปลอดภัยเพื่อไม่ให้ระบบปฏิบัติการหรือเคอร์เนลที่ถูกบุกรุกปลอมแปลงการดำเนินการดังกล่าวได้ ตัวอย่างเช่น การดำเนินการยืนยันที่อิงตามปุ่มจริงจะกำหนดเส้นทางผ่านพินอินพุต/เอาต์พุตอเนกประสงค์ (GPIO) แบบอินพุตเท่านั้นขององค์ประกอบความปลอดภัย (SE) ซึ่งไม่สามารถขับเคลื่อนด้วยวิธีอื่นนอกเหนือจากการกดปุ่มจริง
• [C-5-2] ต้องใช้โฟลว์การตรวจสอบสิทธิ์โดยนัย (ไม่มีขั้นตอนการยืนยัน) ที่สอดคล้องกับ setConfirmationRequired(boolean) เพิ่มเติมด้วย ซึ่งแอปพลิเคชันสามารถตั้งค่าเพื่อใช้สำหรับโฟลว์การลงชื่อเข้าใช้ได้

หากการติดตั้งใช้งานอุปกรณ์มีเซ็นเซอร์ไบโอเมตริกหลายตัว จะมีลักษณะดังนี้

• [C-SR] ขอแนะนำอย่างยิ่งให้กำหนดให้ยืนยันข้อมูลไบโอเมตริกเพียงรายการเดียวต่อการตรวจสอบสิทธิ์ 1 ครั้ง (เช่น หากมีทั้งเซ็นเซอร์ลายนิ้วมือและเซ็นเซอร์ใบหน้าในอุปกรณ์ ควรส่ง onAuthenticationSucceeded หลังจากยืนยันข้อมูลไบโอเมตริกรายการใดรายการหนึ่งแล้ว)

การติดตั้งใช้งานอุปกรณ์ต้องอนุญาตให้แอปพลิเคชันของบุคคลที่สามเข้าถึงคีย์ในที่เก็บคีย์ โดยมีข้อกำหนดดังนี้

• [C-6-1] ต้องเป็นไปตามข้อกำหนดสำหรับคลาส 3 ตามที่กำหนดไว้ในส่วนด้านล่างนี้
• [C-6-2] ต้องแสดงเฉพาะข้อมูลไบโอเมตริกระดับ 3 เมื่อการตรวจสอบสิทธิ์ต้องใช้ BIOMETRIC_STRONG หรือเมื่อเรียกใช้การตรวจสอบสิทธิ์ด้วย CryptoObject

หากการใช้งานอุปกรณ์ต้องการถือว่าเซ็นเซอร์ไบโอเมตริกเป็นคลาส 1 (เดิมคือความสะดวก) จะต้องมีคุณสมบัติดังนี้

• [C-1-1] ต้องมีอัตราการยอมรับที่ผิดพลาดน้อยกว่า 0.002%
• [C-1-2] ต้องเปิดเผยว่าโหมดนี้อาจปลอดภัยน้อยกว่า PIN, รูปแบบ หรือรหัสผ่านที่รัดกุม และระบุความเสี่ยงของการเปิดใช้โหมดนี้อย่างชัดเจน หากอัตราการยอมรับการสวมรอยและการแอบอ้างเป็นบุคคลอื่นสูงกว่า 7% ตามที่วัดโดยโปรโตคอลการทดสอบไบโอเมตริกของ Android
• [C-1-3] ต้องจำกัดอัตราการพยายามเป็นเวลาอย่างน้อย 30 วินาทีหลังจากพยายามยืนยันตัวตนด้วยข้อมูลไบโอเมตริกไม่สำเร็จ 5 ครั้ง โดยการพยายามไม่สำเร็จคือการพยายามที่มีคุณภาพการจับภาพเพียงพอ (BIOMETRIC_ACQUIRED_GOOD) ซึ่งไม่ตรงกับข้อมูลไบโอเมตริกที่ลงทะเบียนไว้
• [C-1-4] ต้องป้องกันการเพิ่มข้อมูลไบโอเมตริกใหม่โดยไม่สร้างห่วงโซ่ความน่าเชื่อถือก่อนด้วยการให้ผู้ใช้ยืนยันข้อมูลเข้าสู่ระบบของอุปกรณ์ที่มีอยู่หรือเพิ่มข้อมูลเข้าสู่ระบบของอุปกรณ์ใหม่ (PIN/รูปแบบ/รหัสผ่าน) ที่ TEE รักษาความปลอดภัยไว้ การติดตั้งใช้งาน Android Open Source Project มีกลไกในเฟรมเวิร์กเพื่อดำเนินการดังกล่าว
• [C-1-5] ต้องนำข้อมูลไบโอเมตริกที่ระบุตัวตนได้ทั้งหมดของผู้ใช้ออกอย่างสมบูรณ์เมื่อมีการนำบัญชีของผู้ใช้ออก (รวมถึงผ่านการรีเซ็ตเป็นค่าเริ่มต้น)
• [C-1-6] ต้องปฏิบัติตามเครื่องหมายแต่ละรายการสำหรับข้อมูลไบโอเมตริกนั้น (เช่น DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT, DevicePolicymanager.KEYGUARD_DISABLE_FACE หรือ DevicePolicymanager.KEYGUARD_DISABLE_IRIS )
• [C-1-7] ต้องขอให้ผู้ใช้ยืนยันตัวตนด้วยการตรวจสอบสิทธิ์หลักที่แนะนำ (เช่น PIN, รูปแบบ, รหัสผ่าน) ทุกๆ 24 ชั่วโมงหรือน้อยกว่าสำหรับอุปกรณ์ใหม่ที่เปิดตัวด้วย Android เวอร์ชัน 10 และทุกๆ 72 ชั่วโมงหรือน้อยกว่าสำหรับอุปกรณ์ที่อัปเกรดจาก Android เวอร์ชันก่อนหน้า

• [C-1-8] ต้องท้าทายผู้ใช้สำหรับการตรวจสอบสิทธิ์หลักที่แนะนำ (เช่น PIN, รูปแบบ, รหัสผ่าน) หลังจากดำเนินการอย่างใดอย่างหนึ่งต่อไปนี้

  • ระยะเวลาที่ไม่มีการใช้งาน 4 ชั่วโมง หรือ
  • พยายามตรวจสอบสิทธิ์ด้วยข้อมูลไบโอเมตริก 3 ครั้งไม่สำเร็จ
  • ระบบจะรีเซ็ตระยะหมดเวลาเนื่องจากไม่มีการใช้งานและจำนวนครั้งที่ตรวจสอบสิทธิ์ไม่สำเร็จหลังจากยืนยันข้อมูลเข้าสู่ระบบของอุปกรณ์สำเร็จ

  การอัปเกรดอุปกรณ์จาก Android เวอร์ชันก่อนหน้าอาจได้รับการยกเว้นจาก C-1-8 * [C-SR] ขอแนะนำอย่างยิ่งให้ใช้ตรรกะในเฟรมเวิร์กที่จัดทำโดยโครงการโอเพนซอร์ส Android เพื่อบังคับใช้ข้อจำกัดที่ระบุไว้ใน [C-1-7] และ [C-1-8] สำหรับอุปกรณ์ใหม่ * [C-SR] ขอแนะนำอย่างยิ่งให้มีอัตราการปฏิเสธที่ผิดพลาดน้อยกว่า 10% ตามที่วัดในอุปกรณ์ * [C-SR] ขอแนะนำอย่างยิ่งให้มีเวลาในการตอบสนองต่ำกว่า 1 วินาที โดยวัดจากเวลาที่ตรวจพบไบโอเมตริกจนกว่าจะปลดล็อกหน้าจอสำหรับไบโอเมตริกแต่ละรายการที่ลงทะเบียนไว้

หากการติดตั้งใช้งานอุปกรณ์ต้องการถือว่าเซ็นเซอร์ไบโอเมตริกเป็นคลาส 2 (เดิมคืออ่อน) จะต้องดำเนินการดังนี้

• [C-2-1] ต้องเป็นไปตามข้อกำหนดทั้งหมดสำหรับคลาส 1 ด้านบน
• [C-2-2] ต้องมีอัตราการยอมรับการสวมรอยและการแอบอ้างไม่เกิน 20% ตามที่วัดโดยโปรโตคอลการทดสอบไบโอเมตริกของ Android
• [C-2-3] ต้องทำการจับคู่ไบโอเมตริกในสภาพแวดล้อมการดำเนินการที่แยกจากกันภายนอกพื้นที่ผู้ใช้หรือเคอร์เนลของ Android เช่น สภาพแวดล้อมการดำเนินการที่เชื่อถือได้ (TEE) หรือในชิปที่มีช่องทางที่ปลอดภัยไปยังสภาพแวดล้อมการดำเนินการที่แยกจากกัน
• [C-2-4] ต้องเข้ารหัสข้อมูลที่ระบุตัวบุคคลได้ทั้งหมดและตรวจสอบสิทธิ์ด้วยการเข้ารหัสลับเพื่อให้ไม่สามารถรับ อ่าน หรือเปลี่ยนแปลงข้อมูลภายนอกสภาพแวดล้อมการดำเนินการที่แยกไว้หรือชิปที่มีแชแนลที่ปลอดภัยไปยังสภาพแวดล้อมการดำเนินการที่แยกไว้ตามที่ระบุไว้ในหลักเกณฑ์การใช้งานในเว็บไซต์ Android Open Source Project
• [C-2-5] สำหรับข้อมูลไบโอเมตริกที่อิงตามกล้อง ขณะที่การตรวจสอบสิทธิ์หรือการลงทะเบียนด้วยข้อมูลไบโอเมตริกกำลังดำเนินการอยู่ ให้ทำดังนี้
  • ต้องใช้งานกล้องในโหมดที่ป้องกันไม่ให้อ่านหรือแก้ไขเฟรมกล้องภายนอกสภาพแวดล้อมการดำเนินการที่แยกต่างหากหรือชิปที่มีช่องทางที่ปลอดภัยไปยังสภาพแวดล้อมการดำเนินการที่แยกต่างหาก
  • สำหรับโซลูชันกล้องเดี่ยว RGB เฟรมกล้องจะอ่านได้นอกสภาพแวดล้อมการดำเนินการที่แยกต่างหากเพื่อรองรับการดำเนินการต่างๆ เช่น การแสดงตัวอย่างสำหรับการลงทะเบียน แต่จะยังคงต้องแก้ไขไม่ได้
• [C-2-6] ต้องไม่เปิดใช้แอปพลิเคชันของบุคคลที่สามเพื่อแยกความแตกต่างระหว่างการลงทะเบียนไบโอเมตริกของแต่ละบุคคล
• [C-2-7] ต้องไม่อนุญาตให้เข้าถึงข้อมูลไบโอเมตริกที่ระบุตัวบุคคลนั้นได้หรือข้อมูลใดๆ ที่ได้มาจากข้อมูลดังกล่าว (เช่น การฝัง) โดยไม่มีการเข้ารหัสไปยัง Application Processor นอกบริบทของ TEE

• [C-2-8] ต้องมีไปป์ไลน์การประมวลผลที่ปลอดภัยเพื่อไม่ให้ระบบปฏิบัติการหรือเคอร์เนลที่ถูกบุกรุกสามารถแทรกข้อมูลโดยตรงเพื่อทำการตรวจสอบสิทธิ์เท็จในฐานะผู้ใช้

  หากมีการเปิดตัวการใช้งานอุปกรณ์ใน Android เวอร์ชันก่อนหน้าแล้วและไม่สามารถปฏิบัติตามข้อกำหนด C-2-8 ผ่านการอัปเดตซอฟต์แวร์ระบบได้ ระบบอาจยกเว้นข้อกำหนดดังกล่าว

• [C-SR] ขอแนะนำอย่างยิ่งให้รวมการตรวจจับความมีชีวิตสำหรับรูปแบบไบโอเมตริกทั้งหมด และการตรวจจับความสนใจสำหรับไบโอเมตริกใบหน้า

หากการใช้งานอุปกรณ์ต้องการถือว่าเซ็นเซอร์ไบโอเมตริกเป็นคลาส 3 (เดิมคือแข็งแกร่ง) จะต้องดำเนินการดังนี้

• [C-3-1] ต้องเป็นไปตามข้อกำหนดทั้งหมดของคลาส 2 ด้านบน ยกเว้น [C-1-7] และ [C-1-8] การอัปเกรดอุปกรณ์จาก Android เวอร์ชันก่อนหน้าจะไม่ได้รับการยกเว้นจาก C-2-7
• [C-3-2] ต้องมีการติดตั้งใช้งานที่เก็บคีย์ที่อิงฮาร์ดแวร์
• [C-3-3] ต้องมีอัตราการยอมรับการสวมรอยและการแอบอ้างไม่เกิน 7% ตามที่วัดโดยโปรโตคอลการทดสอบไบโอเมตริกของ Android
• [C-3-4] ต้องแจ้งให้ผู้ใช้ยืนยันตัวตนด้วยการตรวจสอบสิทธิ์หลักที่แนะนำ (เช่น PIN, รูปแบบ, รหัสผ่าน) ทุกๆ 72 ชั่วโมงหรือน้อยกว่า

7.3.12. เซ็นเซอร์ท่าทาง

การติดตั้งใช้งานอุปกรณ์

• อาจรองรับเซ็นเซอร์ท่าทางที่มีองศาอิสระ 6 องศา

หากการใช้งานอุปกรณ์รองรับเซ็นเซอร์ท่าทางที่มีอิสระ 6 ระดับ อุปกรณ์จะทำสิ่งต่อไปนี้

• [C-1-1] ต้องใช้และรายงานเซ็นเซอร์TYPE_POSE_6DOF
• [C-1-2] ต้องแม่นยำกว่าเวกเตอร์การหมุนเพียงอย่างเดียว

7.3.13. เซ็นเซอร์มุมบานพับ

หากการติดตั้งใช้งานอุปกรณ์รองรับเซ็นเซอร์มุมบานพับ อุปกรณ์จะทำสิ่งต่อไปนี้

• [C-1-1] ต้องใช้และรายงาน TYPE_HINGLE_ANGLE
• [C-1-2] ต้องรองรับค่าอย่างน้อย 2 ค่าระหว่าง 0 ถึง 360 องศา (รวม 0 และ 360 องศา)
• [C-1-3] ต้องแสดงผลเซ็นเซอร์ปลุกสำหรับ getDefaultSensor(SENSOR_TYPE_HINGE_ANGLE)

7.4 การเชื่อมต่อข้อมูล

7.4.1. โทรศัพท์

"โทรศัพท์" ตามที่ใช้โดย Android API และเอกสารนี้หมายถึงฮาร์ดแวร์ที่เกี่ยวข้องกับการโทรด้วยเสียงและการส่งข้อความ SMS ผ่านเครือข่าย GSM หรือ CDMA โดยเฉพาะ แม้ว่าการโทรด้วยเสียงเหล่านี้อาจใช้หรือไม่ใช้การสลับแพ็กเก็ต แต่ก็มีไว้เพื่อวัตถุประสงค์ของ Android ซึ่งถือว่าแยกจากการเชื่อมต่อข้อมูลใดๆ ที่อาจใช้เครือข่ายเดียวกัน กล่าวคือ ฟังก์ชันการทำงานและ API ของ "โทรศัพท์" ใน Android จะหมายถึงการโทรด้วยเสียงและ SMS โดยเฉพาะ ตัวอย่างเช่น การติดตั้งใช้งานอุปกรณ์ที่ไม่สามารถโทรออกหรือส่ง/รับข้อความ SMS จะไม่ถือว่าเป็นอุปกรณ์โทรศัพท์ ไม่ว่าอุปกรณ์นั้นจะใช้เครือข่ายมือถือเพื่อการเชื่อมต่อข้อมูลหรือไม่ก็ตาม

• Android อาจใช้ในอุปกรณ์ที่ไม่มีฮาร์ดแวร์โทรศัพท์ กล่าวคือ Android ใช้ได้กับอุปกรณ์ที่ไม่ใช่โทรศัพท์

หากการใช้งานอุปกรณ์รวมถึงโทรศัพท์ GSM หรือ CDMA อุปกรณ์จะต้องมีคุณสมบัติดังนี้

• [C-1-1] ต้องประกาศandroid.hardware.telephonyฟีเจอร์แฟล็กและฟีเจอร์แฟล็กย่อยอื่นๆ ตามเทคโนโลยี
• [C-1-2] ต้องรองรับ API สำหรับเทคโนโลยีนั้นอย่างเต็มรูปแบบ

หากการติดตั้งใช้งานอุปกรณ์ไม่มีฮาร์ดแวร์โทรศัพท์ อุปกรณ์จะต้องมีคุณสมบัติดังนี้

• [C-2-1] ต้องใช้ API ทั้งหมดเป็นแบบไม่มีการดำเนินการ

หากการติดตั้งใช้งานอุปกรณ์รองรับ eUICC หรือ eSIM/ซิมแบบฝัง และมีกลไกที่เป็นกรรมสิทธิ์เพื่อให้ฟังก์ชัน eSIM พร้อมใช้งานสำหรับนักพัฒนาแอปบุคคลที่สาม อุปกรณ์ดังกล่าวจะดำเนินการต่อไปนี้

• [C-3-1] ต้องมีการติดตั้งใช้งาน EuiccManager API อย่างสมบูรณ์

7.4.1.1. ความเข้ากันได้ของการบล็อกหมายเลข

หากการติดตั้งใช้งานอุปกรณ์รายงาน android.hardware.telephony feature จะมีลักษณะดังนี้

• [C-1-1] ต้องมีการรองรับการบล็อกหมายเลข
• [C-1-2] ต้องใช้ BlockedNumberContract และ API ที่เกี่ยวข้องอย่างเต็มรูปแบบตามที่อธิบายไว้ในเอกสารประกอบของ SDK
• [C-1-3] ต้องบล็อกสายและข้อความทั้งหมดจากหมายเลขโทรศัพท์ใน "BlockedNumberProvider" โดยไม่ต้องมีการโต้ตอบกับแอป ข้อยกเว้นเพียงอย่างเดียวคือเมื่อมีการยกเลิกการบล็อกหมายเลขชั่วคราวตามที่อธิบายไว้ในเอกสารประกอบของ SDK
• [C-1-4] ต้องไม่เขียนไปยังผู้ให้บริการบันทึกการโทรของแพลตฟอร์มสำหรับการโทรที่ถูกบล็อก
• [C-1-5] ต้องไม่เขียนถึงผู้ให้บริการโทรศัพท์สำหรับข้อความที่ถูกบล็อก
• [C-1-6] ต้องใช้ UI การจัดการหมายเลขที่ถูกบล็อก ซึ่งจะเปิดด้วย Intent ที่ส่งคืนโดยเมธอด TelecomManager.createManageBlockedNumbersIntent()
• [C-1-7] ต้องไม่อนุญาตให้ผู้ใช้ระดับรองดูหรือแก้ไขหมายเลขที่ถูกบล็อกในอุปกรณ์ เนื่องจากแพลตฟอร์ม Android ถือว่าผู้ใช้หลักมีสิทธิ์ควบคุมบริการโทรศัพท์อย่างเต็มรูปแบบ ซึ่งเป็นอินสแตนซ์เดียวในอุปกรณ์ ระบบต้องซ่อน UI ที่เกี่ยวข้องกับการบล็อกทั้งหมดสำหรับผู้ใช้รอง และต้องยังคงใช้รายการที่ถูกบล็อก
• ควรย้ายหมายเลขที่ถูกบล็อกไปยังผู้ให้บริการเมื่ออุปกรณ์อัปเดตเป็น Android 7.0

7.4.1.2. Telecom API

หากการติดตั้งใช้งานอุปกรณ์รายงาน android.hardware.telephony จะมีลักษณะดังนี้

• [C-1-1] ต้องรองรับ API ConnectionService ที่อธิบายไว้ใน SDK
• [C-1-2] ต้องแสดงสายเรียกเข้าใหม่และให้ผู้ใช้ยอมรับหรือปฏิเสธสายเรียกเข้าเมื่อผู้ใช้กำลังอยู่ในสายที่แอปของบุคคลที่สามซึ่งไม่รองรับฟีเจอร์พักสายที่ระบุผ่าน CAPABILITY_SUPPORT_HOLD โทร
• [C-1-3] ต้องมีแอปพลิเคชันที่ใช้ InCallService

• [C-SR] ขอแนะนำอย่างยิ่งให้แจ้งผู้ใช้ว่าการรับสายเรียกเข้าจะทำให้สายที่กำลังสนทนาอยู่หลุด

  การติดตั้งใช้งาน AOSP เป็นไปตามข้อกำหนดเหล่านี้โดยการแจ้งเตือนล่วงหน้า ซึ่งจะแจ้งให้ผู้ใช้ทราบว่าการรับสายเรียกเข้าจะทำให้สายอื่นถูกตัด

• [C-SR] ขอแนะนำอย่างยิ่งให้โหลดแอปโทรออกเริ่มต้นล่วงหน้าซึ่งจะแสดงรายการบันทึกการโทรและชื่อของแอปของบุคคลที่สามในบันทึกการโทรเมื่อแอปของบุคคลที่สามตั้งค่าคีย์พิเศษ EXTRA_LOG_SELF_MANAGED_CALLS ใน PhoneAccount เป็น true

• [C-SR] ขอแนะนำอย่างยิ่งให้จัดการเหตุการณ์ KEYCODE_MEDIA_PLAY_PAUSE และ KEYCODE_HEADSETHOOK ของชุดหูฟังเสียงสำหรับ API android.telecom ดังนี้
  • เรียกใช้ Connection.onDisconnect() เมื่อตรวจพบการกดเหตุการณ์สำคัญสั้นๆ ระหว่างการโทรที่กำลังดำเนินอยู่
  • เรียกใช้ Connection.onAnswer() เมื่อตรวจพบการกดเหตุการณ์คีย์สั้นๆ ระหว่างการโทรเข้า
  • เรียกใช้ Connection.onReject() เมื่อตรวจพบการกดเหตุการณ์สำคัญค้างระหว่างสายเรียกเข้า
  • สลับสถานะการปิดเสียงของ CallAudioState

7.4.2. IEEE 802.11 (Wi-Fi)

การติดตั้งใช้งานอุปกรณ์

• ควรมีการรองรับรูปแบบ 802.11 อย่างน้อย 1 รูปแบบ

หากการติดตั้งใช้งานอุปกรณ์รวมถึงการรองรับ 802.11 และเปิดเผยฟังก์ชันการทำงานให้กับแอปพลิเคชันของบุคคลที่สาม อุปกรณ์ดังกล่าวจะต้องมีคุณสมบัติดังนี้

• [C-1-1] ต้องใช้ Android API ที่เกี่ยวข้อง
• [C-1-2] ต้องรายงานแฟล็กฟีเจอร์ของฮาร์ดแวร์ android.hardware.wifi
• [C-1-3] ต้องใช้ Multicast API ตามที่อธิบายไว้ในเอกสารประกอบของ SDK
• [C-1-4] ต้องรองรับมัลติแคสต์ DNS (mDNS) และต้องไม่กรองแพ็กเก็ต mDNS (224.0.0.251) ในเวลาใดก็ตามของการดำเนินการ ซึ่งรวมถึง
  • แม้ว่าหน้าจอจะไม่ได้อยู่ในสถานะที่ใช้งานอยู่
  • สำหรับการใช้งานอุปกรณ์ Android Television แม้จะอยู่ในสถานะพลังงานสแตนด์บาย
• [C-1-5] ต้องไม่ถือว่าการเรียกใช้เมธอด API ของ WifiManager.enableNetwork() เป็นข้อบ่งชี้ที่เพียงพอในการเปลี่ยน Network ที่ใช้งานอยู่ในปัจจุบันซึ่งใช้โดยค่าเริ่มต้นสำหรับการรับส่งข้อมูลของแอปพลิเคชัน และส่งคืนโดยเมธอด API ของ ConnectivityManager เช่น getActiveNetwork และ registerDefaultNetworkCallback กล่าวคือ แอปอาจปิดใช้การเข้าถึงอินเทอร์เน็ตที่ผู้ให้บริการเครือข่ายรายอื่น (เช่น เน็ตมือถือ) ให้บริการได้ก็ต่อเมื่อตรวจสอบแล้วว่าเครือข่าย Wi-Fi ให้บริการการเข้าถึงอินเทอร์เน็ต
• [C-1-6] ขอแนะนำอย่างยิ่งให้เมื่อมีการเรียกใช้เมธอด API ของ ConnectivityManager.reportNetworkConnectivity() ให้ประเมินการเข้าถึงอินเทอร์เน็ตใน Network อีกครั้ง และเมื่อการประเมินระบุว่า Network ปัจจุบันไม่สามารถเข้าถึงอินเทอร์เน็ตได้อีกต่อไป ให้เปลี่ยนไปใช้เครือข่ายอื่นที่พร้อมใช้งาน (เช่น เน็ตมือถือ) ซึ่งมีการเข้าถึงอินเทอร์เน็ต
• [C-SR] ขอแนะนำอย่างยิ่งให้สุ่มที่อยู่ MAC ต้นทางและหมายเลขลำดับของเฟรมคำขอ Probe เมื่อเริ่มต้นการสแกนแต่ละครั้งขณะที่ STA ไม่ได้เชื่อมต่อ
  • แต่ละกลุ่มของเฟรมคำขอ Probe ที่ประกอบกันเป็นการสแกน 1 ครั้งควรใช้ที่อยู่ MAC ที่สอดคล้องกัน 1 รายการ (ไม่ควรสุ่มที่อยู่ MAC กลางคันระหว่างการสแกน)
  • หมายเลขลำดับคำขอ Probe ควรวนซ้ำตามปกติ (ตามลำดับ) ระหว่างคำขอ Probe ในการสแกน
  • หมายเลขลำดับคำขอ Probe ควรสุ่มระหว่างคำขอ Probe สุดท้ายของการสแกนกับคำขอ Probe แรกของการสแกนครั้งถัดไป
• [C-SR] ขอแนะนำอย่างยิ่ง ขณะที่ STA ไม่ได้เชื่อมต่อ เพื่ออนุญาตเฉพาะองค์ประกอบต่อไปนี้ในเฟรมคำขอ Probe
  • ชุดพารามิเตอร์ SSID (0)
  • ชุดพารามิเตอร์ DS (3)

หากการติดตั้งใช้งานอุปกรณ์รวมถึงการรองรับโหมดประหยัดพลังงาน Wi-Fi ตามที่กำหนดไว้ในมาตรฐาน IEEE 802.11 อุปกรณ์จะดำเนินการต่อไปนี้

• [C-3-1] ต้องปิดโหมดประหยัดพลังงาน Wi-Fi ทุกครั้งที่แอปได้รับWIFI_MODE_FULL_HIGH_PERFล็อกหรือWIFI_MODE_FULL_LOW_LATENCYล็อกผ่าน API WifiManager.createWifiLock() และ WifiManager.WifiLock.acquire() และล็อกยังคงใช้งานอยู่
• [C-3-2] เวลาในการตอบสนองไป-กลับโดยเฉลี่ยระหว่างอุปกรณ์กับจุดเข้าใช้งานขณะที่อุปกรณ์อยู่ในโหมดล็อก Wi-Fi ที่มีความหน่วงต่ำ (WIFI_MODE_FULL_LOW_LATENCY) ต้องน้อยกว่าเวลาในการตอบสนองในโหมดล็อก Wi-Fi ที่มีประสิทธิภาพสูง (WIFI_MODE_FULL_HIGH_PERF)
• [C-SR] ขอแนะนำอย่างยิ่งให้ใช้เพื่อลดเวลาในการตอบสนองไป-กลับของ Wi-Fi ทุกครั้งที่ได้รับ Low Latency Lock (WIFI_MODE_FULL_LOW_LATENCY) และมีผล

หากการใช้งานอุปกรณ์รองรับ Wi-Fi และใช้ Wi-Fi สำหรับการสแกนตำแหน่ง อุปกรณ์จะทำสิ่งต่อไปนี้

• [C-2-1] ต้องมีส่วนที่ผู้ใช้สามารถเปิด/ปิดการอ่านค่าผ่านเมธอด WifiManager.isScanAlwaysAvailable API

7.4.2.1. Wi-Fi Direct

การติดตั้งใช้งานอุปกรณ์

• ควรรองรับ Wi-Fi Direct (Wi-Fi แบบเพียร์ทูเพียร์)

หากการติดตั้งใช้งานอุปกรณ์รองรับ Wi-Fi Direct อุปกรณ์จะต้องมีคุณสมบัติดังนี้

• [C-1-1] ต้องใช้ Android API ที่เกี่ยวข้องตามที่อธิบายไว้ในเอกสารประกอบของ SDK
• [C-1-2] ต้องรายงานฟีเจอร์ฮาร์ดแวร์ android.hardware.wifi.direct
• [C-1-3] ต้องรองรับการทำงานของ Wi-Fi ปกติ
• [C-1-4] ต้องรองรับการทำงานของ Wi-Fi และ Wi-Fi Direct พร้อมกัน

7.4.2.2. การตั้งค่าลิงก์โดยตรงที่ผ่านอุโมงค์ Wi-Fi

การติดตั้งใช้งานอุปกรณ์

• ควรมีการรองรับการตั้งค่า Direct Link แบบ Tunnel ผ่าน Wi-Fi (TDLS) ตามที่อธิบายไว้ในเอกสารประกอบ Android SDK

หากการใช้งานอุปกรณ์รวมถึงการรองรับ TDLS และ API ของ WiFiManager เปิดใช้ TDLS อุปกรณ์จะทำสิ่งต่อไปนี้

• [C-1-1] ต้องประกาศการรองรับ TDLS ผ่าน WifiManager.isTdlsSupported
• ควรใช้ TDL เฉพาะในกรณีที่เป็นไปได้และเป็นประโยชน์
• ควรมีฮิวริสติกบางอย่างและไม่ใช้ TDLS เมื่อประสิทธิภาพอาจแย่กว่าการผ่านจุดเข้าถึง Wi-Fi

7.4.2.3. Wi-Fi Aware

การติดตั้งใช้งานอุปกรณ์

• ควรรองรับ Wi-Fi Aware

หากการใช้งานอุปกรณ์รวมถึงการรองรับ Wi-Fi Aware และเปิดเผยฟังก์ชันการทำงานต่อแอปของบุคคลที่สาม อุปกรณ์ดังกล่าวจะต้องมีคุณสมบัติดังนี้

• [C-1-1] ต้องใช้ WifiAwareManager API ตามที่อธิบายไว้ในเอกสารประกอบของ SDK
• [C-1-2] ต้องประกาศandroid.hardware.wifi.awareแฟล็กฟีเจอร์
• [C-1-3] ต้องรองรับการทำงานของ Wi-Fi และ Wi-Fi Aware พร้อมกัน
• [C-1-4] ต้องสุ่มที่อยู่อินเทอร์เฟซการจัดการ Wi-Fi Aware เป็นระยะเวลาไม่เกิน 30 นาที และทุกครั้งที่เปิดใช้ Wi-Fi Aware เว้นแต่จะมีการดำเนินการวัดระยะ Aware อย่างต่อเนื่องหรือเส้นทางข้อมูล Aware ใช้งานอยู่ (ไม่จำเป็นต้องสุ่มตราบใดที่เส้นทางข้อมูลใช้งานอยู่)

หากการใช้งานอุปกรณ์รวมถึงการรองรับ Wi-Fi Aware และตำแหน่ง Wi-Fi ตามที่อธิบายไว้ในส่วน 7.4.2.5 และเปิดเผยฟังก์ชันการทำงานเหล่านี้ต่อแอปของบุคคลที่สาม อุปกรณ์จะต้องดำเนินการต่อไปนี้

• [C-2-1] ต้องใช้ API การค้นหาที่รับรู้ตำแหน่ง: setRangingEnabled, setMinDistanceMm, setMaxDistanceMm และ onServiceDiscoveredWithinRange

7.4.2.4. Passpoint ของ Wi-Fi

หากการติดตั้งใช้งานอุปกรณ์รวมถึงการรองรับ 802.11 (Wi-Fi) อุปกรณ์จะต้องมีคุณสมบัติดังนี้

• ควรรองรับ Wi-Fi Passpoint

หากการติดตั้งใช้งานอุปกรณ์รวมถึงการรองรับ Wi-Fi Passpoint อุปกรณ์จะทำสิ่งต่อไปนี้

• [C-1-2] ต้องใช้ WifiManager API ที่เกี่ยวข้องกับ Passpoint ตามที่อธิบายไว้ในเอกสารประกอบ SDK
• [C-1-3] ต้องรองรับมาตรฐาน IEEE 802.11u โดยเฉพาะที่เกี่ยวข้องกับการค้นหาและการเลือกเครือข่าย เช่น Generic Advertisement Service (GAS) และ Access Network Query Protocol (ANQP)

ในทางกลับกัน หากการติดตั้งใช้งานอุปกรณ์ไม่รองรับ Wi-Fi Passpoint

• [C-2-1] การใช้งาน API ที่เกี่ยวข้องกับ Passpoint WifiManager ต้องส่ง UnsupportedOperationException

7.4.2.5. ตำแหน่งของ Wi-Fi (ระยะเวลารับส่งข้อมูลของ Wi-Fi - RTT)

การติดตั้งใช้งานอุปกรณ์

• ควรรองรับตำแหน่ง Wi-Fi

หากการใช้งานอุปกรณ์รองรับตำแหน่ง Wi-Fi และเปิดเผยฟังก์ชันการทำงานต่อแอปของบุคคลที่สาม อุปกรณ์จะต้องดำเนินการต่อไปนี้

• [C-1-1] ต้องใช้ WifiRttManager API ตามที่อธิบายไว้ในเอกสารประกอบของ SDK
• [C-1-2] ต้องประกาศandroid.hardware.wifi.rttแฟล็กฟีเจอร์
• [C-1-3] ต้องสุ่มที่อยู่ MAC ต้นทางสำหรับแต่ละ RTT Burst ซึ่งดำเนินการในขณะที่อินเทอร์เฟซ Wi-Fi ที่ดำเนินการ RTT ไม่ได้เชื่อมโยงกับ Access Point

7.4.2.6. Wi-Fi Keepalive Offload

การติดตั้งใช้งานอุปกรณ์

• ควรมีการรองรับการส่งต่อการทำงานของ Wi-Fi Keepalive

หากการติดตั้งใช้งานอุปกรณ์รวมถึงการรองรับการออฟโหลดการทำงานของ Wi-Fi Keepalive และเปิดเผยฟังก์ชันการทำงานต่อแอปของบุคคลที่สาม อุปกรณ์ดังกล่าวจะดำเนินการต่อไปนี้

• [C-1-1] ต้องรองรับ API SocketKeepAlive

• [C-1-2] ต้องรองรับช่อง Keepalive พร้อมกันอย่างน้อย 3 ช่องผ่าน Wi-Fi และช่อง Keepalive อย่างน้อย 1 ช่องผ่านเครือข่ายมือถือ

หากการใช้งานอุปกรณ์ไม่รองรับการส่งต่อการทำงานของ Wi-Fi Keepalive

• [C-2-1] ต้องแสดงผล ERROR_UNSUPPORTED

7.4.2.7. Wi-Fi Easy Connect (โปรโตคอลการจัดสรรอุปกรณ์)

การติดตั้งใช้งานอุปกรณ์

• ควรมีการรองรับ Wi-Fi Easy Connect (DPP)

หากการใช้งานอุปกรณ์รวมถึงการรองรับ Wi-Fi Easy Connect และเปิดเผยฟังก์ชันการทำงานต่อแอปของบุคคลที่สาม อุปกรณ์ดังกล่าวจะทำสิ่งต่อไปนี้

• [C-1-1] ต้องให้เมธอด WifiManager#isEasyConnectSupported() แสดงผลเป็น true

7.4.3. บลูทูธ

หากการใช้งานอุปกรณ์รองรับโปรไฟล์เสียงบลูทูธ อุปกรณ์จะทำสิ่งต่อไปนี้

• ควรรองรับตัวแปลงสัญญาณเสียงขั้นสูงและตัวแปลงสัญญาณเสียงบลูทูธ (เช่น LDAC)

หากการใช้งานอุปกรณ์รองรับ HFP, A2DP และ AVRCP อุปกรณ์จะทำสิ่งต่อไปนี้

• ควรรองรับอุปกรณ์ที่เชื่อมต่อทั้งหมดอย่างน้อย 5 เครื่อง

หากการติดตั้งใช้งานอุปกรณ์ประกาศฟีเจอร์ android.hardware.vr.high_performance จะมีข้อกำหนดดังนี้

• [C-1-1] ต้องรองรับบลูทูธ 4.2 และส่วนขยายความยาวข้อมูลของบลูทูธ LE

Android รองรับบลูทูธและบลูทูธพลังงานต่ำ

หากการติดตั้งใช้งานอุปกรณ์รองรับบลูทูธและบลูทูธพลังงานต่ำ อุปกรณ์จะต้องมีคุณสมบัติดังนี้

• [C-2-1] ต้องประกาศฟีเจอร์แพลตฟอร์มที่เกี่ยวข้อง (android.hardware.bluetooth และ android.hardware.bluetooth_le ตามลำดับ) และใช้ API ของแพลตฟอร์ม
• ควรใช้โปรไฟล์บลูทูธที่เกี่ยวข้อง เช่น A2DP, AVRCP, OBEX, HFP ฯลฯ ตามความเหมาะสมกับอุปกรณ์

หากการติดตั้งใช้งานอุปกรณ์รวมถึงการรองรับบลูทูธพลังงานต่ำ (BLE) อุปกรณ์จะต้องมีคุณสมบัติดังนี้

• [C-3-1] ต้องประกาศฟีเจอร์ฮาร์ดแวร์ android.hardware.bluetooth_le
• [C-3-2] ต้องเปิดใช้ API บลูทูธที่อิงตาม GATT (Generic Attribute Profile) ตามที่อธิบายไว้ในเอกสารประกอบของ SDK และ android.bluetooth
• [C-3-3] ต้องรายงานค่าที่ถูกต้องสำหรับ BluetoothAdapter.isOffloadedFilteringSupported() เพื่อระบุว่ามีการใช้ตรรกะการกรองสำหรับคลาส API ของ ScanFilter หรือไม่
• [C-3-4] ต้องรายงานค่าที่ถูกต้องสำหรับ BluetoothAdapter.isMultipleAdvertisementSupported() เพื่อระบุว่ารองรับการโฆษณาแบบประหยัดพลังงานหรือไม่
• [C-3-5] ต้องใช้การหมดเวลาของที่อยู่ส่วนตัวที่แก้ไขได้ (RPA) ไม่เกิน 15 นาที และหมุนเวียนที่อยู่เมื่อหมดเวลาเพื่อปกป้องความเป็นส่วนตัวของผู้ใช้เมื่ออุปกรณ์ใช้ BLE อย่างต่อเนื่องเพื่อสแกนหรือโฆษณา ช่วงหมดเวลาต้องสุ่มระหว่าง 5 ถึง 15 นาทีด้วยเพื่อป้องกันการโจมตีแบบกำหนดเวลา
• ควรรองรับการส่งต่อตรรกะการกรองไปยังชิปเซ็ตบลูทูธเมื่อใช้ ScanFilter API
• ควรสนับสนุนการส่งต่อการสแกนแบบเป็นชุดไปยังชิปเซ็ตบลูทูธ
• ควรรองรับโฆษณาหลายรายการที่มีช่องอย่างน้อย 4 ช่อง

หากการติดตั้งใช้งานอุปกรณ์รองรับบลูทูธ LE และใช้บลูทูธ LE สำหรับการสแกนหาตำแหน่ง อุปกรณ์จะทำสิ่งต่อไปนี้

• [C-4-1] ต้องมีส่วนที่ผู้ใช้สามารถเปิด/ปิดใช้ค่าที่อ่านผ่าน System API BluetoothAdapter.isBleScanAlwaysAvailable() ได้

หากการใช้งานอุปกรณ์รวมถึงการรองรับโปรไฟล์บลูทูธ LE และเครื่องช่วยฟังตามที่อธิบายไว้ในการรองรับเสียงของเครื่องช่วยฟังโดยใช้บลูทูธ LE อุปกรณ์ดังกล่าวจะทำสิ่งต่อไปนี้

• [C-5-1] ต้องแสดงผล true สำหรับ BluetoothAdapter.getProfileProxy(context, listener, BluetoothProfile.HEARING_AID)

7.4.4. Near Field Communication

การติดตั้งใช้งานอุปกรณ์

• ควรมีตัวรับส่งและฮาร์ดแวร์ที่เกี่ยวข้องสำหรับ Near-Field Communication (NFC)
• [C-0-1] ต้องใช้ API android.nfc.NdefMessage และ android.nfc.NdefRecord แม้ว่าจะไม่รองรับ NFC หรือประกาศฟีเจอร์ android.hardware.nfc เนื่องจากคลาสต่างๆ แสดงรูปแบบการแสดงข้อมูลที่ไม่ขึ้นกับโปรโตคอล

หากการติดตั้งใช้งานอุปกรณ์มีฮาร์ดแวร์ NFC และวางแผนที่จะทำให้พร้อมใช้งานสำหรับแอปของบุคคลที่สาม อุปกรณ์จะต้องมีคุณสมบัติดังนี้

• [C-1-1] ต้องรายงานฟีเจอร์ android.hardware.nfc จากเมธอด android.content.pm.PackageManager.hasSystemFeature()
• ต้องอ่านและเขียนข้อความ NDEF ผ่านมาตรฐาน NFC ต่อไปนี้ได้
• [C-1-2] ต้องทำหน้าที่เป็นเครื่องอ่าน/เขียนของ NFC Forum ได้ (ตามที่กำหนดไว้ในข้อกำหนดทางเทคนิคของ NFC Forum NFCForum-TS-DigitalProtocol-1.0) ผ่านมาตรฐาน NFC ต่อไปนี้
  • NfcA (ISO14443-3A)
  • NfcB (ISO14443-3B)
  • NfcF (JIS X 6319-4)
  • IsoDep (ISO 14443-4)
  • ประเภทแท็ก NFC Forum 1, 2, 3, 4, 5 (กำหนดโดย NFC Forum)

• [SR] ขอแนะนำอย่างยิ่งให้สามารถอ่านและเขียนข้อความ NDEF รวมถึงข้อมูลดิบผ่านมาตรฐาน NFC ต่อไปนี้ โปรดทราบว่าแม้ว่ามาตรฐาน NFC จะระบุว่า "ขอแนะนำอย่างยิ่ง" แต่คำจำกัดความความเข้ากันได้สำหรับเวอร์ชันในอนาคตมีแผนที่จะเปลี่ยนมาตรฐานเหล่านี้เป็น "ต้อง" มาตรฐานเหล่านี้ไม่บังคับในเวอร์ชันนี้ แต่จะต้องใช้ในเวอร์ชันต่อๆ ไป เราขอแนะนำอย่างยิ่งให้อุปกรณ์ที่มีอยู่และอุปกรณ์ใหม่ที่ใช้ Android เวอร์ชันนี้เป็นไปตามข้อกำหนดเหล่านี้ในตอนนี้ เพื่อให้อัปเกรดเป็นแพลตฟอร์มเวอร์ชันในอนาคตได้

• [C-1-13] ต้องสำรวจเทคโนโลยีที่รองรับทั้งหมดขณะอยู่ในโหมดการค้นพบ NFC

• ควรอยู่ในโหมดการค้นหา NFC ขณะที่อุปกรณ์ทำงานโดยที่หน้าจอเปิดอยู่และปลดล็อกหน้าจอล็อกแล้ว
• ควรอ่านบาร์โค้ดและ URL (หากมีการเข้ารหัส) ของผลิตภัณฑ์ Thinfilm NFC Barcode ได้

โปรดทราบว่าลิงก์ที่เผยแพร่ต่อสาธารณะจะไม่มีให้บริการสำหรับข้อกำหนด JIS, ISO และ NFC Forum ที่อ้างอิงข้างต้น

Android รองรับโหมด Host Card Emulation (HCE) ของ NFC

หากการติดตั้งใช้งานอุปกรณ์มีชิปเซ็ตตัวควบคุม NFC ที่รองรับ HCE (สำหรับ NfcA และ/หรือ NfcB) และรองรับการกำหนดเส้นทางรหัสแอปพลิเคชัน (AID) อุปกรณ์ดังกล่าวจะทำสิ่งต่อไปนี้

• [C-2-1] ต้องรายงานค่าคงที่ของฟีเจอร์ android.hardware.nfc.hce
• [C-2-2] ต้องรองรับ NFC HCE API ตามที่กำหนดไว้ใน Android SDK

หากการติดตั้งใช้งานอุปกรณ์มีชิปเซ็ตตัวควบคุม NFC ที่รองรับ HCE สำหรับ NfcF และติดตั้งใช้งานฟีเจอร์สำหรับแอปพลิเคชันของบุคคลที่สาม จะต้องมีคุณสมบัติดังนี้

• [C-3-1] ต้องรายงานandroid.hardware.nfc.hcefค่าคงที่ของฟีเจอร์
• [C-3-2] ต้องใช้ NfcF Card Emulation APIs ตามที่กำหนดไว้ใน Android SDK

หากการใช้งานอุปกรณ์รวมถึงการรองรับ NFC ทั่วไปตามที่อธิบายไว้ในส่วนนี้และรองรับเทคโนโลยี MIFARE (MIFARE Classic, MIFARE Ultralight, NDEF ใน MIFARE Classic) ในบทบาทของเครื่องอ่าน/เครื่องเขียน อุปกรณ์ดังกล่าวจะทำสิ่งต่อไปนี้

• [C-4-1] ต้องใช้ Android API ที่เกี่ยวข้องตามที่ระบุไว้ในเอกสารประกอบของ Android SDK
• [C-4-2] ต้องรายงานฟีเจอร์ com.nxp.mifare จากเมธอด android.content.pm.PackageManager.hasSystemFeature() โปรดทราบว่านี่ไม่ใช่ฟีเจอร์มาตรฐานของ Android จึงไม่ปรากฏเป็นค่าคงที่ในคลาส android.content.pm.PackageManager

7.4.5. โปรโตคอลและ API ของเครือข่าย

7.4.5.1. ความสามารถของเครือข่ายขั้นต่ำ

การติดตั้งใช้งานอุปกรณ์

• [C-0-1] ต้องรองรับการเชื่อมต่อเครือข่ายข้อมูลอย่างน้อย 1 รูปแบบ โดยเฉพาะอย่างยิ่ง การติดตั้งใช้งานอุปกรณ์ต้องรองรับมาตรฐานข้อมูลอย่างน้อย 1 รายการที่สามารถรองรับ 200 Kbit/วินาทีขึ้นไป ตัวอย่างเทคโนโลยีที่ตรงตามข้อกำหนดนี้ ได้แก่ EDGE, HSPA, EV-DO, 802.11g, Ethernet และ Bluetooth PAN
• ควรมีการรองรับมาตรฐานข้อมูลไร้สายทั่วไปอย่างน้อย 1 มาตรฐาน เช่น 802.11 (Wi-Fi) เมื่อมาตรฐานเครือข่ายแบบมีสาย (เช่น อีเทอร์เน็ต) เป็นการเชื่อมต่อข้อมูลหลัก
• อาจใช้การเชื่อมต่อข้อมูลมากกว่า 1 รูปแบบ

7.4.5.2. IPv6

การติดตั้งใช้งานอุปกรณ์

• [C-0-2] ต้องมีสแต็กเครือข่าย IPv6 และรองรับการสื่อสาร IPv6 โดยใช้ API ที่มีการจัดการ เช่น java.net.Socket และ java.net.URLConnection รวมถึง API ดั้งเดิม เช่น ซ็อกเก็ต AF_INET6
• [C-0-3] ต้องเปิดใช้ IPv6 โดยค่าเริ่มต้น
• ต้องตรวจสอบว่าการสื่อสาร IPv6 มีความน่าเชื่อถือเท่ากับ IPv4 เช่น
  • [C-0-4] ต้องรักษาการเชื่อมต่อ IPv6 ในโหมดพัก
  • [C-0-5] การจำกัดอัตราต้องไม่ทำให้อุปกรณ์สูญเสียการเชื่อมต่อ IPv6 ในเครือข่ายที่รองรับ IPv6 ซึ่งใช้ช่วงเวลาที่ RA มีผลอย่างน้อย 180 วินาที
• [C-0-6] ต้องให้การเชื่อมต่อ IPv6 โดยตรงกับเครือข่ายแก่แอปพลิเคชันของบุคคลที่สามเมื่อเชื่อมต่อกับเครือข่าย IPv6 โดยไม่มีการแปลที่อยู่หรือพอร์ตในรูปแบบใดๆ เกิดขึ้นในอุปกรณ์ ทั้ง API ที่มีการจัดการ เช่น Socket#getLocalAddress หรือ Socket#getLocalPort) และ API ของ NDK เช่น getsockname() หรือ IPV6_PKTINFO จะต้องแสดงที่อยู่ IP และพอร์ตที่ใช้จริงในการส่งและรับแพ็กเก็ตในเครือข่าย และมองเห็นเป็น IP และพอร์ตต้นทางไปยังเซิร์ฟเวอร์อินเทอร์เน็ต (เว็บ)

ระดับการรองรับ IPv6 ที่จำเป็นจะขึ้นอยู่กับประเภทเครือข่าย ดังที่แสดงในข้อกำหนดต่อไปนี้

หากการติดตั้งใช้งานอุปกรณ์รองรับ Wi-Fi อุปกรณ์จะทำสิ่งต่อไปนี้

• [C-1-1] ต้องรองรับการทำงานแบบ Dual Stack และ IPv6 เท่านั้นบน Wi-Fi

หากการติดตั้งใช้งานอุปกรณ์รองรับอีเทอร์เน็ต อุปกรณ์จะต้องมีคุณสมบัติดังนี้

• [C-2-1] ต้องรองรับการทำงานแบบ Dual Stack และ IPv6 เท่านั้นในอีเทอร์เน็ต

หากการติดตั้งใช้งานอุปกรณ์รองรับอินเทอร์เน็ตมือถือ อุปกรณ์จะทำสิ่งต่อไปนี้

• [C-3-1] ต้องรองรับการทำงานของ IPv6 (IPv6 เท่านั้นและอาจเป็นแบบ Dual-stack) บนเครือข่ายมือถือ

หากการติดตั้งใช้งานอุปกรณ์รองรับประเภทเครือข่ายมากกว่า 1 ประเภท (เช่น Wi-Fi และอินเทอร์เน็ตบนมือถือ) อุปกรณ์จะทำสิ่งต่อไปนี้

• [C-4-1] ต้องเป็นไปตามข้อกำหนดข้างต้นพร้อมกันในแต่ละเครือข่ายเมื่ออุปกรณ์เชื่อมต่อกับประเภทเครือข่ายมากกว่า 1 ประเภทพร้อมกัน

7.4.5.3. แคพทีฟพอร์ทัล

แคพทีฟพอร์ทัลหมายถึงเครือข่ายที่ต้องลงชื่อเข้าใช้เพื่อรับสิทธิ์เข้าถึงอินเทอร์เน็ต

หากการติดตั้งใช้งานอุปกรณ์มีการติดตั้งใช้งาน android.webkit.Webview API อย่างสมบูรณ์ อุปกรณ์จะทำสิ่งต่อไปนี้

• [C-1-1] ต้องมีแอปพลิเคชันแคปทีฟพอร์ทัลเพื่อจัดการ Intent ACTION_CAPTIVE_PORTAL_SIGN_IN และแสดงหน้าเข้าสู่ระบบแคปทีฟพอร์ทัลโดยการส่ง Intent นั้นเมื่อเรียกใช้ System API ConnectivityManager#startCaptivePortalApp(Network, Bundle)
• [C-1-2] ต้องตรวจหาแคปทีฟพอร์ทัลและรองรับการเข้าสู่ระบบผ่านแอปพลิเคชันแคปทีฟพอร์ทัลเมื่ออุปกรณ์เชื่อมต่อกับประเภทเครือข่ายใดก็ตาม ซึ่งรวมถึงเครือข่ายมือถือ/เซลลูลาร์, Wi-Fi, อีเทอร์เน็ต หรือบลูทูธ
• [C-1-3] ต้องรองรับการเข้าสู่ระบบแคปทีฟพอร์ทัลโดยใช้ DNS แบบข้อความธรรมดาเมื่อมีการกำหนดค่าอุปกรณ์ให้ใช้โหมดเข้มงวดของ DNS ส่วนตัว
• [C-1-4] ต้องใช้ DNS ที่เข้ารหัสตามเอกสารประกอบ SDK สำหรับ android.net.LinkProperties.getPrivateDnsServerName และ android.net.LinkProperties.isPrivateDnsActive สำหรับการรับส่งข้อมูลทั้งหมดในเครือข่ายที่ไม่ได้สื่อสารกับแคปทีฟพอร์ทัลอย่างชัดเจน
• [C-1-5] ต้องตรวจสอบว่าในขณะที่ผู้ใช้เข้าสู่ระบบแคปทีฟพอร์ทัล เครือข่ายเริ่มต้นที่แอปพลิเคชันใช้ (ตามที่ส่งคืนโดย ConnectivityManager.getActiveNetwork, ConnectivityManager.registerDefaultNetworkCallback และใช้โดยค่าเริ่มต้นโดย Java Networking API เช่น java.net.Socket และ Native API เช่น connect()) คือเครือข่ายอื่นที่พร้อมใช้งานซึ่งให้สิทธิ์เข้าถึงอินเทอร์เน็ต หากมี

7.4.6. การตั้งค่าการซิงค์

การติดตั้งใช้งานอุปกรณ์

• [C-0-1] ต้องมีการตั้งค่าการซิงค์อัตโนมัติหลักเป็นเปิดโดยค่าเริ่มต้น เพื่อให้เมธอด getMasterSyncAutomatically() แสดงผลเป็น "จริง"

7.4.7. ประหยัดอินเทอร์เน็ต

หากการติดตั้งใช้งานอุปกรณ์มีการเชื่อมต่อแบบคิดตามปริมาณการใช้งาน อุปกรณ์จะ

• [SR] ขอแนะนำอย่างยิ่งให้ระบุโหมดประหยัดอินเทอร์เน็ต

หากการใช้งานอุปกรณ์มีโหมดประหยัดอินเทอร์เน็ต อุปกรณ์จะดำเนินการต่อไปนี้

• [C-1-1] ต้องรองรับ API ทั้งหมดในคลาส ConnectivityManager ตามที่อธิบายไว้ในเอกสารประกอบ SDK

หากการติดตั้งใช้งานอุปกรณ์ไม่ได้มีโหมดประหยัดอินเทอร์เน็ต จะเกิดสิ่งต่อไปนี้

• [C-2-1] ต้องแสดงผลค่า RESTRICT_BACKGROUND_STATUS_DISABLED สำหรับ ConnectivityManager.getRestrictBackgroundStatus()
• [C-2-2] ต้องไม่แพร่ภาพConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED

7.4.8. องค์ประกอบความปลอดภัย

หากการติดตั้งใช้งานอุปกรณ์รองรับองค์ประกอบที่ปลอดภัยซึ่งใช้ Open Mobile API ได้และทำให้แอปของบุคคลที่สามใช้งานได้ อุปกรณ์จะทำสิ่งต่อไปนี้

• [C-1-1] ต้องแสดงรายการเครื่องอ่านองค์ประกอบที่ปลอดภัยที่พร้อมใช้งานผ่าน android.se.omapi.SEService.getReaders() API

• [C-1-2] ต้องประกาศฟีเจอร์แฟล็กที่ถูกต้องผ่าน android.hardware.se.omapi.uicc สำหรับอุปกรณ์ที่มีองค์ประกอบความปลอดภัยที่อิงตาม UICC, android.hardware.se.omapi.ese สำหรับอุปกรณ์ที่มีองค์ประกอบความปลอดภัยที่อิงตาม eSE และ android.hardware.se.omapi.sd สำหรับอุปกรณ์ที่มีองค์ประกอบความปลอดภัยที่อิงตาม SD

7.5 กล้องถ่ายรูป

หากการติดตั้งใช้งานอุปกรณ์มีกล้องอย่างน้อย 1 ตัว อุปกรณ์ดังกล่าวจะต้องมีคุณสมบัติดังนี้

• [C-1-1] ต้องประกาศandroid.hardware.camera.anyแฟล็กฟีเจอร์
• [C-1-2] แอปพลิเคชันต้องสามารถจัดสรรบิตแมป RGBA_8888 จำนวน 3 รายการพร้อมกันซึ่งมีขนาดเท่ากับรูปภาพที่สร้างโดยเซ็นเซอร์กล้องที่มีความละเอียดสูงสุดในอุปกรณ์ ขณะที่กล้องเปิดอยู่เพื่อวัตถุประสงค์ในการแสดงตัวอย่างพื้นฐานและการจับภาพนิ่ง
• [C-1-3] ต้องตรวจสอบว่าแอปพลิเคชันกล้องเริ่มต้นที่ติดตั้งไว้ล่วงหน้าซึ่งจัดการ Intent MediaStore.ACTION_IMAGE_CAPTURE, MediaStore.ACTION_IMAGE_CAPTURE_SECURE หรือ MediaStore.ACTION_VIDEO_CAPTURE มีหน้าที่ลบตำแหน่งของผู้ใช้ในข้อมูลเมตาของรูปภาพก่อนที่จะส่งไปยังแอปพลิเคชันที่รับ เมื่อแอปพลิเคชันที่รับไม่มี ACCESS_FINE_LOCATION

7.5.1. กล้องหลัง

กล้องหลังคือกล้องที่อยู่ด้านข้างของอุปกรณ์ตรงข้ามกับจอแสดงผล ซึ่งหมายความว่ากล้องจะถ่ายภาพฉากที่อยู่ด้านไกลของอุปกรณ์ เช่น กล้องทั่วไป

การติดตั้งใช้งานอุปกรณ์

• ควรมีกล้องหลัง

หากการติดตั้งใช้งานอุปกรณ์มีกล้องด้านหลังอย่างน้อย 1 ตัว อุปกรณ์ดังกล่าวจะต้องมีคุณสมบัติดังนี้

• [C-1-1] ต้องรายงานแฟล็กฟีเจอร์ android.hardware.camera และ android.hardware.camera.any
• [C-1-2] ต้องมีความละเอียดอย่างน้อย 2 เมกะพิกเซล
• ควรมีการโฟกัสอัตโนมัติด้วยฮาร์ดแวร์หรือซอฟต์แวร์ที่ติดตั้งใช้งานในไดรเวอร์กล้อง (โปร่งใสต่อซอฟต์แวร์แอปพลิเคชัน)
• อาจมีฮาร์ดแวร์โฟกัสคงที่หรือ EDOF (ระยะชัดลึกที่ขยาย)
• อาจมีแฟลช

หากกล้องมีแฟลช ให้ทำดังนี้

• [C-2-1] ต้องไม่เปิดหลอดแฟลชขณะที่ลงทะเบียนอินสแตนซ์ android.hardware.Camera.PreviewCallback บนพื้นผิวแสดงตัวอย่างกล้อง เว้นแต่แอปพลิเคชันจะเปิดใช้แฟลชอย่างชัดเจนโดยการเปิดใช้แอตทริบิวต์ FLASH_MODE_AUTO หรือ FLASH_MODE_ON ของออบเจ็กต์ Camera.Parameters โปรดทราบว่าข้อจำกัดนี้ไม่มีผลกับแอปพลิเคชันกล้องของระบบในตัวของอุปกรณ์ แต่มีผลกับแอปพลิเคชันของบุคคลที่สามที่ใช้ Camera.PreviewCallback เท่านั้น

7.5.2. กล้องหน้า

กล้องด้านหน้าคือกล้องที่อยู่ด้านเดียวกับจอแสดงผลของอุปกรณ์ ซึ่งโดยปกติแล้วจะเป็นกล้องที่ใช้ถ่ายภาพผู้ใช้ เช่น สำหรับการประชุมผ่านวิดีโอและแอปพลิเคชันที่คล้ายกัน

การติดตั้งใช้งานอุปกรณ์

• อาจมีกล้องหน้า

หากการติดตั้งใช้งานอุปกรณ์มีกล้องหน้าอย่างน้อย 1 ตัว อุปกรณ์ดังกล่าวจะต้องมีคุณสมบัติดังนี้

• [C-1-1] ต้องรายงานแฟล็กฟีเจอร์ android.hardware.camera.any และ android.hardware.camera.front
• [C-1-2] ต้องมีความละเอียดอย่างน้อย VGA (640x480 พิกเซล)
• [C-1-3] ต้องไม่ใช้กล้องหน้าเป็นค่าเริ่มต้นสำหรับ Camera API และต้องไม่กำหนดค่า API ให้ถือว่ากล้องหน้าเป็นกล้องหลังเริ่มต้น แม้ว่าจะเป็นกล้องเดียวในอุปกรณ์ก็ตาม
• [C-1-4] พรีวิวของกล้องต้องมีการมิเรอร์ในแนวนอนเทียบกับการวางแนวที่แอปพลิเคชันระบุ เมื่อแอปพลิเคชันปัจจุบันได้ขอให้หมุนจอแสดงผลของกล้องอย่างชัดเจนผ่านการเรียกใช้เมธอด android.hardware.Camera.setDisplayOrientation() ในทางกลับกัน ระบบจะต้องทำสำเนามุมมองตามแกนแนวนอนเริ่มต้นของอุปกรณ์เมื่อแอปพลิเคชันปัจจุบันไม่ได้ขอให้หมุนจอแสดงผลกล้องอย่างชัดเจนผ่านการเรียกใช้เมธอด android.hardware.Camera.setDisplayOrientation()
• [C-1-5] ต้องไม่กลับด้านภาพนิ่งหรือสตรีมวิดีโอที่จับภาพสุดท้ายซึ่งส่งคืนไปยังการเรียกกลับของแอปพลิเคชันหรือจัดเก็บไว้ในที่เก็บข้อมูลสื่อ
• [C-1-6] ต้องมิเรอร์รูปภาพที่แสดงโดยการดูภายหลังในลักษณะเดียวกับสตรีมรูปภาพตัวอย่างของกล้อง
• อาจมีฟีเจอร์ (เช่น โฟกัสอัตโนมัติ แฟลช ฯลฯ) ที่ใช้ได้กับกล้องด้านหลังตามที่อธิบายไว้ในส่วนที่ 7.5.1

หากการติดตั้งใช้งานอุปกรณ์สามารถหมุนได้โดยผู้ใช้ (เช่น โดยอัตโนมัติผ่านเครื่องวัดความเร่งหรือด้วยตนเองผ่านอินพุตของผู้ใช้) ให้ทำดังนี้

• [C-2-1] พรีวิวของกล้องต้องเป็นภาพที่ปรับให้เหมือนภาพในกระจกในแนวนอนเมื่อเทียบกับการวางแนวปัจจุบันของอุปกรณ์

7.5.3. กล้องภายนอก

การติดตั้งใช้งานอุปกรณ์

• อาจรวมถึงการรองรับกล้องภายนอกที่ไม่จำเป็นต้องเชื่อมต่ออยู่เสมอ

หากการใช้งานอุปกรณ์รองรับกล้องภายนอก อุปกรณ์จะต้องมีคุณสมบัติดังนี้

• [C-1-1] ต้องประกาศแฟล็กฟีเจอร์ของแพลตฟอร์ม android.hardware.camera.external และ android.hardware camera.any
• [C-1-2] ต้องรองรับ USB Video Class (UVC 1.0 ขึ้นไป) หากกล้องภายนอกเชื่อมต่อผ่านพอร์ตโฮสต์ USB
• [C-1-3] ต้องผ่านการทดสอบ CTS ของกล้องเมื่อเชื่อมต่ออุปกรณ์กล้องภายนอกจริง ดูรายละเอียดการทดสอบ CTS ของกล้องได้ที่ source.android.com
• ควรรองรับการบีบอัดวิดีโอ เช่น MJPEG เพื่อให้โอนสตรีมคุณภาพสูงที่ไม่ได้เข้ารหัสได้ (เช่น สตรีมรูปภาพแบบดิบหรือแบบบีบอัดแยกกัน)
• อาจรองรับกล้องหลายตัว
• อาจรองรับการเข้ารหัสวิดีโอที่อิงตามกล้อง

หากระบบรองรับการเข้ารหัสวิดีโอที่ใช้กล้อง ให้ทำดังนี้

• [C-2-1] การติดตั้งใช้งานอุปกรณ์ต้องเข้าถึงสตรีมที่ไม่ได้เข้ารหัส / MJPEG พร้อมกัน (ความละเอียด QVGA ขึ้นไป) ได้

7.5.4. ลักษณะการทำงานของ Camera API

Android มีแพ็กเกจ API 2 รายการสำหรับเข้าถึงกล้อง โดย API android.hardware.camera2 ที่ใหม่กว่าจะเปิดเผยการควบคุมกล้องระดับล่างให้กับแอป ซึ่งรวมถึงโฟลว์การสตรีม/การถ่ายภาพต่อเนื่องแบบไม่มีการคัดลอกที่มีประสิทธิภาพ และการควบคุมการเปิดรับแสง เกน สมดุลสีขาว เกน การแปลงสี การลดสัญญาณรบกวน การเพิ่มความคมชัด และอื่นๆ ต่อเฟรม

แพ็กเกจ API รุ่นเก่าandroid.hardware.Cameraได้รับการทำเครื่องหมายว่าเลิกใช้งานแล้วใน Android 5.0 แต่ควรยังคงพร้อมให้แอปใช้งานได้ การใช้งานอุปกรณ์ Android ต้องรับประกันการสนับสนุน API อย่างต่อเนื่องตามที่อธิบายไว้ในส่วนนี้และใน Android SDK

ฟีเจอร์ทั้งหมดที่ใช้ร่วมกันระหว่างคลาส android.hardware.Camera ที่เลิกใช้งานแล้วกับแพ็กเกจ android.hardware.camera2 ที่ใหม่กว่าจะต้องมีประสิทธิภาพและคุณภาพเทียบเท่ากันในทั้ง 2 API ตัวอย่างเช่น เมื่อใช้การตั้งค่าที่เทียบเท่า ความเร็วและความแม่นยำของโฟกัสอัตโนมัติต้องเหมือนกัน และคุณภาพของรูปภาพที่ถ่ายต้องเหมือนกัน ฟีเจอร์ที่ขึ้นอยู่กับความหมายที่แตกต่างกันของ API ทั้ง 2 ไม่จำเป็นต้องมีความเร็วหรือคุณภาพที่ตรงกัน แต่ควรตรงกันให้มากที่สุด

การใช้งานอุปกรณ์ต้องใช้ลักษณะการทำงานต่อไปนี้สำหรับ API ที่เกี่ยวข้องกับกล้องสำหรับกล้องที่มีอยู่ทั้งหมด การติดตั้งใช้งานอุปกรณ์

• [C-0-1] ต้องใช้ android.hardware.PixelFormat.YCbCr_420_SP สำหรับข้อมูลตัวอย่างที่ระบุในการเรียกกลับของแอปพลิเคชันเมื่อแอปพลิเคชันไม่เคยเรียกใช้ android.hardware.Camera.Parameters.setPreviewFormat(int)
• [C-0-2] ต้องอยู่ในรูปแบบการเข้ารหัส NV21 เมื่อแอปพลิเคชันลงทะเบียนอินสแตนซ์ android.hardware.Camera.PreviewCallback และระบบเรียกใช้เมธอด onPreviewFrame() และรูปแบบตัวอย่างเป็น YCbCr_420_SP ข้อมูลในไบต์[] ที่ส่งไปยัง onPreviewFrame() กล่าวคือ NV21 ต้องเป็นค่าเริ่มต้น
• [C-0-3] ต้องรองรับรูปแบบ YV12 (ตามที่ระบุโดยค่าคงที่ android.graphics.ImageFormat.YV12) สำหรับตัวอย่างกล้องทั้งกล้องหน้าและกล้องหลังสำหรับ android.hardware.Camera (โปรแกรมเปลี่ยนไฟล์วิดีโอและกล้องฮาร์ดแวร์อาจใช้รูปแบบพิกเซลดั้งเดิมใดก็ได้ แต่การติดตั้งใช้งานอุปกรณ์ต้องรองรับการแปลงเป็น YV12)
• [C-0-4] ต้องรองรับรูปแบบ android.hardware.ImageFormat.YUV_420_888 และ android.hardware.ImageFormat.JPEG เป็นเอาต์พุตผ่าน android.media.ImageReader API สำหรับอุปกรณ์ android.hardware.camera2 ที่โฆษณาความสามารถ REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE ใน android.request.availableCapabilities
• [C-0-5] ต้องยังคงใช้ Camera API แบบเต็มที่รวมอยู่ในเอกสารประกอบ Android SDK ไม่ว่าอุปกรณ์จะมีฮาร์ดแวร์โฟกัสอัตโนมัติหรือความสามารถอื่นๆ หรือไม่ก็ตาม เช่น กล้องที่ไม่มีโฟกัสอัตโนมัติยังคงต้องเรียกใช้android.hardware.Camera.AutoFocusCallbackที่ลงทะเบียนไว้ (แม้ว่าการดำเนินการนี้จะไม่เกี่ยวข้องกับกล้องที่ไม่มีโฟกัสอัตโนมัติ) โปรดทราบว่าการดำเนินการนี้ใช้กับกล้องหน้าด้วย ตัวอย่างเช่น แม้ว่ากล้องหน้าส่วนใหญ่จะไม่รองรับการโฟกัสอัตโนมัติ แต่การเรียกกลับของ API ก็ยังต้อง "จำลอง" ตามที่อธิบายไว้
• [C-0-6] ต้องรับรู้และปฏิบัติตามชื่อพารามิเตอร์แต่ละชื่อที่กำหนดเป็นค่าคงที่ในคลาส android.hardware.Camera.Parameters และคลาส android.hardware.camera2.CaptureRequest ในทางกลับกัน การใช้งานอุปกรณ์ต้องไม่ยอมรับหรือจดจำค่าคงที่สตริงที่ส่งไปยังเมธอด android.hardware.Camera.setParameters() นอกเหนือจากค่าคงที่ที่ระบุไว้ในเอกสารของ android.hardware.Camera.Parameters กล่าวคือ การใช้งานอุปกรณ์ต้องรองรับพารามิเตอร์กล้องมาตรฐานทั้งหมดหากฮาร์ดแวร์อนุญาต และต้องไม่รองรับประเภทพารามิเตอร์กล้องที่กำหนดเอง เช่น การใช้งานอุปกรณ์ที่รองรับการจับภาพโดยใช้เทคนิคการถ่ายภาพแบบ High Dynamic Range (HDR) จะต้องรองรับพารามิเตอร์กล้อง Camera.SCENE_MODE_HDR
• [C-0-7] ต้องรายงานระดับการสนับสนุนที่เหมาะสมด้วยพร็อพเพอร์ตี้ android.info.supportedHardwareLevel ตามที่อธิบายไว้ใน Android SDK และรายงานฟีเจอร์แฟล็กของเฟรมเวิร์กที่เหมาะสม
• [C-0-8] ต้องประกาศความสามารถของกล้องแต่ละตัวของ android.hardware.camera2 ผ่านพร็อพเพอร์ตี้ android.request.availableCapabilities และประกาศฟีเจอร์แฟล็กที่เหมาะสมด้วย ต้องกำหนดฟีเจอร์แฟล็กหากอุปกรณ์กล้องที่เชื่อมต่อรองรับฟีเจอร์ดังกล่าว
• [C-0-9] ต้องออกอากาศCamera.ACTION_NEW_PICTUREเจตนาทุกครั้งที่กล้องถ่ายภาพใหม่และมีการเพิ่มรายการรูปภาพลงในร้านค้าสื่อ
• [C-0-10] ต้องออกอากาศCamera.ACTION_NEW_VIDEOเจตนาทุกครั้งที่กล้องบันทึกวิดีโอใหม่และมีการเพิ่มรายการรูปภาพลงในร้านค้าสื่อ
• [C-0-11] ต้องมีกล้องทั้งหมดที่เข้าถึงได้ผ่าน API ของ android.hardware.Camera ที่เลิกใช้งานแล้ว ซึ่งเข้าถึงได้ผ่าน API ของ android.hardware.camera2 ด้วย
• [C-0-12] ต้องตรวจสอบว่าลักษณะใบหน้าไม่ได้รับการดัดแปลง ซึ่งรวมถึงแต่ไม่จำกัดเพียงการดัดแปลงรูปทรงเรขาคณิตของใบหน้า สีผิวของใบหน้า หรือการปรับผิวหน้าให้เนียนสำหรับ API android.hardware.camera2 หรือ android.hardware.Camera
• [C-SR] สำหรับอุปกรณ์ที่มีกล้อง RGB หลายตัวที่หันไปในทิศทางเดียวกัน ขอแนะนำอย่างยิ่งให้รองรับอุปกรณ์กล้องแบบตรรกะที่แสดงความสามารถ CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA ซึ่งประกอบด้วยกล้อง RGB ทั้งหมดที่หันไปในทิศทางนั้นเป็นอุปกรณ์ย่อยทางกายภาพ

หากการติดตั้งใช้งานอุปกรณ์มี API กล้องที่เป็นกรรมสิทธิ์สำหรับแอปของบุคคลที่สาม จะต้องมีลักษณะดังนี้

• [C-1-1] ต้องใช้ Camera API ดังกล่าวโดยใช้ android.hardware.camera2 API
• อาจระบุแท็กผู้ให้บริการและ/หรือส่วนขยายไปยัง android.hardware.camera2 API

7.5.5. การวางแนวของกล้อง

หากการติดตั้งใช้งานอุปกรณ์มีกล้องหน้าหรือกล้องหลัง กล้องดังกล่าวจะต้องมีคุณสมบัติดังนี้

• [C-1-1] ต้องวางแนวให้มิติยาวของกล้องตรงกับมิติยาวของหน้าจอ กล่าวคือ เมื่อถืออุปกรณ์ในแนวนอน กล้องต้องถ่ายภาพในแนวนอน โดยการดำเนินการนี้จะมีผลไม่ว่าอุปกรณ์จะวางในแนวใดก็ตาม กล่าวคือ จะมีผลกับอุปกรณ์ที่วางในแนวนอนเป็นหลักและอุปกรณ์ที่วางในแนวตั้งเป็นหลัก

7.6. หน่วยความจำและพื้นที่เก็บข้อมูล

7.6.1. หน่วยความจำและพื้นที่เก็บข้อมูลขั้นต่ำ

การติดตั้งใช้งานอุปกรณ์

• [C-0-1] ต้องมีตัวจัดการการดาวน์โหลดที่แอปพลิเคชันอาจใช้เพื่อดาวน์โหลดไฟล์ข้อมูล และต้องสามารถดาวน์โหลดไฟล์แต่ละไฟล์ที่มีขนาดอย่างน้อย 100 MB ไปยังตำแหน่ง "แคช" เริ่มต้น

7.6.2. Application Shared Storage

การติดตั้งใช้งานอุปกรณ์

• [C-0-1] ต้องมีพื้นที่เก็บข้อมูลที่แอปพลิเคชันใช้ร่วมกันได้ ซึ่งมักเรียกว่า "พื้นที่เก็บข้อมูลภายนอกที่แชร์" "พื้นที่เก็บข้อมูลที่แชร์ของแอปพลิเคชัน" หรือตามเส้นทาง Linux ที่ติดตั้งไว้คือ "/sdcard"
• [C-0-2] ต้องได้รับการกำหนดค่าให้มีที่เก็บข้อมูลที่แชร์ซึ่งติดตั้งโดยค่าเริ่มต้น กล่าวคือ "พร้อมใช้งาน" ไม่ว่าที่เก็บข้อมูลจะติดตั้งใช้งานในคอมโพเนนต์ที่เก็บข้อมูลภายในหรือสื่อที่เก็บข้อมูลแบบถอดได้ (เช่น ช่องเสียบการ์ด Secure Digital)
• [C-0-3] ต้องติดตั้งที่เก็บข้อมูลที่แชร์ของแอปพลิเคชันโดยตรงในเส้นทาง Linux sdcard หรือรวมลิงก์สัญลักษณ์ Linux จาก sdcard ไปยังจุดติดตั้งจริง
• [C-0-4] ต้องเปิดใช้พื้นที่เก็บข้อมูลที่จำกัดขอบเขตโดยค่าเริ่มต้นสำหรับแอปทั้งหมดที่กำหนดเป้าหมายเป็น API ระดับ 29 ขึ้นไป ยกเว้นในกรณีต่อไปนี้
  • เมื่อแอปขอ android:requestLegacyExternalStorage="true" ในไฟล์ Manifest
• [C-0-5] ต้องปกปิดข้อมูลเมตาของตำแหน่ง เช่น แท็ก Exif ของ GPS ที่จัดเก็บไว้ในไฟล์สื่อเมื่อมีการเข้าถึงไฟล์เหล่านั้นผ่าน MediaStore เว้นแต่แอปที่เรียกใช้จะมีสิทธิ์ ACCESS_MEDIA_LOCATION

การใช้งานอุปกรณ์อาจเป็นไปตามข้อกำหนดข้างต้นโดยใช้อย่างใดอย่างหนึ่งต่อไปนี้

• ที่เก็บข้อมูลแบบถอดออกได้ที่ผู้ใช้เข้าถึงได้ เช่น ช่องเสียบการ์ด Secure Digital (SD)
• พื้นที่เก็บข้อมูลภายใน (ถอดออกไม่ได้) บางส่วนตามที่ใช้ในโครงการโอเพนซอร์ส Android (AOSP)

หากการติดตั้งใช้งานอุปกรณ์ใช้พื้นที่เก็บข้อมูลแบบถอดได้เพื่อให้เป็นไปตามข้อกำหนดข้างต้น อุปกรณ์จะต้องมีคุณสมบัติดังนี้

• [C-1-1] ต้องใช้คำเตือนแบบข้อความป๊อปอัปหรืออินเทอร์เฟซผู้ใช้แบบป๊อปอัปเพื่อเตือนผู้ใช้เมื่อไม่มีสื่อบันทึกข้อมูลเสียบอยู่ในช่อง
• [C-1-2] ต้องมีสื่อบันทึกข้อมูลที่ฟอร์แมตเป็น FAT (เช่น การ์ด SD) หรือแสดงบนกล่องและสื่ออื่นๆ ที่มีในขณะที่ซื้อว่าต้องซื้อสื่อบันทึกข้อมูลแยกต่างหาก

หากการติดตั้งใช้งานอุปกรณ์ใช้พื้นที่เก็บข้อมูลแบบถอดไม่ได้บางส่วนเพื่อให้เป็นไปตามข้อกำหนดข้างต้น อุปกรณ์ดังกล่าวจะต้องมีคุณสมบัติดังนี้

• ควรใช้การติดตั้งใช้งานพื้นที่เก็บข้อมูลที่ใช้ร่วมกันของแอปพลิเคชันภายในของ AOSP
• อาจแชร์พื้นที่เก็บข้อมูลกับข้อมูลส่วนตัวของแอปพลิเคชัน

หากการติดตั้งใช้งานอุปกรณ์มีพอร์ต USB ที่รองรับโหมดอุปกรณ์ต่อพ่วง USB จะมีลักษณะดังนี้

• [C-3-1] ต้องมีกลไกในการเข้าถึงข้อมูลในที่เก็บข้อมูลที่แชร์ของแอปพลิเคชันจากคอมพิวเตอร์โฮสต์
• ควรแสดงเนื้อหาจากทั้ง 2 เส้นทางการจัดเก็บอย่างโปร่งใสผ่านบริการ Media Scanner ของ Android และ android.provider.MediaStore
• อาจใช้ที่เก็บข้อมูลจำนวนมากใน USB แต่ควรใช้โปรโตคอลการโอนสื่อเพื่อให้เป็นไปตามข้อกำหนดนี้

หากการใช้งานอุปกรณ์มีพอร์ต USB ที่มีโหมดอุปกรณ์ต่อพ่วง USB และรองรับโปรโตคอลการโอนสื่อ อุปกรณ์ดังกล่าวจะทำสิ่งต่อไปนี้

• ควรใช้ร่วมกับโฮสต์ MTP ของ Android อ้างอิง ซึ่งก็คือ Android File Transfer
• ควรรายงานคลาสอุปกรณ์ USB เป็น 0x00
• ควรรายงานชื่ออินเทอร์เฟซ USB เป็น "MTP"

7.6.3. พื้นที่เก็บข้อมูลแบบ Adoptable

หากคาดว่าอุปกรณ์จะเคลื่อนที่ได้เหมือนโทรศัพท์มือถือ ไม่ใช่โทรทัศน์ การติดตั้งใช้งานอุปกรณ์จะเป็นดังนี้

• [SR] ขอแนะนำอย่างยิ่งให้ติดตั้งใช้งานพื้นที่เก็บข้อมูลแบบ Adoptable ในตำแหน่งที่เสถียรในระยะยาว เนื่องจากหากถอดการเชื่อมต่อโดยไม่ตั้งใจอาจทำให้ข้อมูลสูญหาย/เสียหาย

หากพอร์ตอุปกรณ์เก็บข้อมูลแบบถอดได้อยู่ในตำแหน่งที่เสถียรในระยะยาว เช่น ภายในช่องใส่แบตเตอรี่หรือฝาครอบป้องกันอื่นๆ การติดตั้งใช้งานอุปกรณ์จะเป็นดังนี้

• [SR] ขอแนะนำอย่างยิ่งให้ใช้พื้นที่เก็บข้อมูลแบบ Adoptable

7.7. USB

หากการติดตั้งใช้งานอุปกรณ์มีพอร์ต USB จะต้องมีคุณสมบัติดังนี้

• ควรจะรองรับโหมดอุปกรณ์ต่อพ่วง USB และควรจะรองรับโหมดโฮสต์ USB

7.7.1. โหมดอุปกรณ์ต่อพ่วง USB

หากการติดตั้งใช้งานอุปกรณ์มีพอร์ต USB ที่รองรับโหมดอุปกรณ์ต่อพ่วง ให้ทำดังนี้

• [C-1-1] พอร์ตต้องเชื่อมต่อกับโฮสต์ USB ที่มีพอร์ต USB มาตรฐานประเภท A หรือประเภท C ได้
• [C-1-2] ต้องรายงานค่าที่ถูกต้องของ iSerialNumber ในตัวอธิบายอุปกรณ์มาตรฐาน USB ผ่าน android.os.Build.SERIAL
• [C-1-3] ต้องตรวจจับเครื่องชาร์จ 1.5A และ 3.0A ตามมาตรฐานตัวต้านทาน Type-C และต้องตรวจจับการเปลี่ยนแปลงในโฆษณาหากรองรับ USB Type-C
• [SR] พอร์ตควรใช้รูปแบบ USB แบบ Micro-B, Micro-AB หรือ Type-C ขอแนะนำอย่างยิ่งให้อุปกรณ์ Android ที่มีอยู่และอุปกรณ์ใหม่เป็นไปตามข้อกำหนดเหล่านี้ เพื่อให้อัปเกรดเป็นแพลตฟอร์มรุ่นต่อๆ ไปได้
• [SR] พอร์ตควรอยู่ที่ด้านล่างของอุปกรณ์ (ตามการวางแนวปกติ) หรือเปิดใช้การหมุนหน้าจอซอฟต์แวร์สำหรับแอปทั้งหมด (รวมถึงหน้าจอหลัก) เพื่อให้จอแสดงผลวาดได้อย่างถูกต้องเมื่ออุปกรณ์วางแนวโดยให้พอร์ตอยู่ด้านล่าง ขอแนะนำอย่างยิ่งให้อุปกรณ์ Android ทั้งที่มีอยู่และใหม่เป็นไปตามข้อกำหนดเหล่านี้ เพื่อให้อัปเกรดเป็นแพลตฟอร์มรุ่นต่อๆ ไปได้
• [SR] ควรใช้การรองรับเพื่อดึงกระแสไฟ 1.5 A ระหว่างการส่งเสียงร้อง HS และการรับส่งข้อมูลตามที่ระบุไว้ในข้อกำหนดการชาร์จแบตเตอรี่ผ่าน USB ฉบับแก้ไข 1.2 ขอแนะนำอย่างยิ่งให้อุปกรณ์ Android ที่มีอยู่และอุปกรณ์ใหม่เป็นไปตามข้อกำหนดเหล่านี้ เพื่อให้อัปเกรดเป็นแพลตฟอร์มรุ่นต่อๆ ไปได้
• [SR] ขอแนะนำอย่างยิ่งว่าไม่ควรสนับสนุนวิธีการชาร์จที่เป็นกรรมสิทธิ์ซึ่งแก้ไขแรงดันไฟฟ้า Vbus ให้เกินระดับเริ่มต้น หรือเปลี่ยนบทบาทของ Sink/Source เนื่องจากอาจทำให้เกิดปัญหาในการทำงานร่วมกันกับเครื่องชาร์จหรืออุปกรณ์ที่รองรับวิธีการ USB Power Delivery มาตรฐาน แม้ว่าเราจะระบุว่า "ขอแนะนำอย่างยิ่ง" แต่ใน Android เวอร์ชันในอนาคต เราอาจกำหนดให้อุปกรณ์ Type-C ทั้งหมดรองรับการทำงานร่วมกันอย่างเต็มรูปแบบกับที่ชาร์จ Type-C มาตรฐาน
• [SR] ขอแนะนำอย่างยิ่งให้รองรับการชาร์จไฟ (Power Delivery) สำหรับการสลับบทบาทของข้อมูลและพลังงานเมื่ออุปกรณ์รองรับ USB Type-C และโหมดโฮสต์ USB
• ควรรองรับ Power Delivery สำหรับการชาร์จแรงดันไฟฟ้าสูงและรองรับโหมดอื่น เช่น การแสดงผล
• ควรใช้ Android Open Accessory (AOA) API และข้อกำหนดตามที่ระบุไว้ในเอกสารประกอบของ Android SDK

หากการติดตั้งใช้งานอุปกรณ์มีพอร์ต USB และใช้ข้อกำหนด AOA อุปกรณ์ดังกล่าวจะดำเนินการต่อไปนี้

• [C-2-1] ต้องประกาศการรองรับฟีเจอร์ฮาร์ดแวร์ android.hardware.usb.accessory
• [C-2-2] คลาสพื้นที่เก็บข้อมูลจำนวนมากของ USB ต้องมีสตริง "android" ที่ท้ายสตริงคำอธิบายอินเทอร์เฟซ iInterface ของพื้นที่เก็บข้อมูลจำนวนมากของ USB

7.7.2. โหมดโฮสต์ USB

หากการใช้งานอุปกรณ์มีพอร์ต USB ที่รองรับโหมดโฮสต์ อุปกรณ์ดังกล่าวจะทำสิ่งต่อไปนี้

• [C-1-1] ต้องใช้ Android USB Host API ตามที่ระบุไว้ใน Android SDK และต้องประกาศการรองรับฟีเจอร์ฮาร์ดแวร์ android.hardware.usb.host
• [C-1-2] ต้องรองรับการเชื่อมต่ออุปกรณ์ต่อพ่วง USB มาตรฐาน กล่าวคือ ต้องทำอย่างใดอย่างหนึ่งต่อไปนี้
  • มีพอร์ต Type C ในอุปกรณ์หรือจัดส่งพร้อมสายที่แปลงพอร์ตที่เป็นกรรมสิทธิ์ในอุปกรณ์เป็นพอร์ต USB Type-C มาตรฐาน (อุปกรณ์ USB Type-C)
  • มีพอร์ต Type A ในอุปกรณ์หรือมาพร้อมสายที่แปลงพอร์ตที่เป็นกรรมสิทธิ์ในอุปกรณ์ให้เป็นพอร์ต USB Type-A มาตรฐาน
  • มีพอร์ต Micro-AB ในอุปกรณ์ ซึ่งควรจัดส่งพร้อมสายที่แปลงเป็นพอร์ต Type-A มาตรฐาน
• [C-1-3] ต้องไม่จัดส่งพร้อมอะแดปเตอร์ที่แปลงจากพอร์ต USB ประเภท A หรือ micro-AB เป็นพอร์ตประเภท C (เต้ารับ)
• [C-SR] ขอแนะนำอย่างยิ่งให้ใช้คลาสเสียง USB ตามที่ระบุไว้ในเอกสารประกอบของ Android SDK
• ควรรองรับการชาร์จอุปกรณ์ต่อพ่วง USB ที่เชื่อมต่อขณะอยู่ในโหมดโฮสต์ โดยประกาศกระแสไฟต้นทางอย่างน้อย 1.5A ตามที่ระบุไว้ในส่วนพารามิเตอร์การสิ้นสุดของข้อกำหนดเฉพาะของสายและขั้วต่อ USB Type-C ฉบับแก้ไข 1.2 สำหรับขั้วต่อ USB Type-C หรือใช้ช่วงกระแสไฟขาออกของพอร์ตดาวน์สตรีมสำหรับการชาร์จ(CDP) ตามที่ระบุไว้ในข้อกำหนดเฉพาะสำหรับการชาร์จแบตเตอรี่ USB ฉบับแก้ไข 1.2 สำหรับขั้วต่อ Micro-AB
• ควรใช้และรองรับมาตรฐาน USB Type-C

หากการติดตั้งใช้งานอุปกรณ์มีพอร์ต USB ที่รองรับโหมดโฮสต์และคลาสเสียง USB อุปกรณ์ดังกล่าวจะทำสิ่งต่อไปนี้ได้

• [C-2-1] ต้องรองรับคลาส USB HID
• [C-2-2] ต้องรองรับการตรวจหาและการแมปฟิลด์ข้อมูล HID ต่อไปนี้ที่ระบุไว้ในตารางการใช้งาน HID ของ USB และคำขอการใช้งานคำสั่งเสียงกับค่าคงที่ KeyEvent ดังนี้
  • หน้าการใช้งาน (0xC) รหัสการใช้งาน (0x0CD): KEYCODE_MEDIA_PLAY_PAUSE
  • หน้าการใช้งาน (0xC) รหัสการใช้งาน (0x0E9): KEYCODE_VOLUME_UP
  • หน้าการใช้งาน (0xC) รหัสการใช้งาน (0x0EA): KEYCODE_VOLUME_DOWN
  • หน้าการใช้งาน (0xC) รหัสการใช้งาน (0x0CF): KEYCODE_VOICE_ASSIST

หากการใช้งานอุปกรณ์มีพอร์ต USB ที่รองรับโหมดโฮสต์และ Storage Access Framework (SAF) อุปกรณ์ดังกล่าวจะทำสิ่งต่อไปนี้

• [C-3-1] ต้องรู้จักอุปกรณ์ MTP (โปรโตคอลการโอนสื่อ) ที่เชื่อมต่อจากระยะไกลและทำให้เข้าถึงเนื้อหาของอุปกรณ์ได้ผ่าน Intent ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT และ ACTION_CREATE_DOCUMENT .

หากการติดตั้งใช้งานอุปกรณ์มีพอร์ต USB ที่รองรับโหมดโฮสต์และ USB Type-C อุปกรณ์ดังกล่าวจะมีลักษณะดังนี้

• [C-4-1] ต้องใช้ฟังก์ชันพอร์ตแบบ 2 บทบาทตามที่กำหนดโดยข้อกำหนดเฉพาะของ USB Type-C (ส่วน 4.5.1.3.3)
• [SR] ขอแนะนำอย่างยิ่งให้รองรับ DisplayPort, ควรจะรองรับอัตราการรับส่งข้อมูล USB SuperSpeed และขอแนะนำอย่างยิ่งให้รองรับ Power Delivery สำหรับการสลับบทบาทด้านข้อมูลและพลังงาน
• [SR] ขอแนะนำอย่างยิ่งว่าไม่ควรสนับสนุนโหมดอุปกรณ์เสริมของอะแดปเตอร์เสียงตามที่อธิบายไว้ในภาคผนวก ก ของข้อกำหนดของสายและขั้วต่อ USB Type-C ฉบับแก้ไข 1.2
• ควรใช้โมเดล Try.* ที่เหมาะสมที่สุดสำหรับรูปแบบอุปกรณ์ เช่น อุปกรณ์พกพาควรใช้โมเดล Try.SNK

7.8. เสียง

7.8.1. ไมโครโฟน

หากการติดตั้งใช้งานอุปกรณ์มีไมโครโฟน อุปกรณ์จะต้องมีคุณสมบัติดังนี้

• [C-1-1] ต้องรายงานค่าคงที่ของฟีเจอร์ android.hardware.microphone
• [C-1-2] ต้องเป็นไปตามข้อกำหนดในการบันทึกเสียงในส่วนที่ 5.4
• [C-1-3] ต้องเป็นไปตามข้อกำหนดด้านเวลาในการตอบสนองของเสียงในส่วนที่ 5.6
• [SR] ขอแนะนำอย่างยิ่งให้รองรับการบันทึกเสียงที่ใกล้กับอัลตราซาวด์ตามที่อธิบายไว้ในส่วน 7.8.3

หากการติดตั้งใช้งานอุปกรณ์ไม่มีไมโครโฟน อุปกรณ์ดังกล่าวจะ

• [C-2-1] ต้องไม่รายงานค่าคงที่ของฟีเจอร์ android.hardware.microphone
• [C-2-2] ต้องใช้ API การบันทึกเสียงอย่างน้อยเป็นแบบไม่มีการดำเนินการ ตามส่วนที่ 7

7.8.2. เอาต์พุตเสียง

หากการติดตั้งใช้งานอุปกรณ์มีลำโพงหรือพอร์ตเอาต์พุตเสียง/มัลติมีเดียสำหรับอุปกรณ์ต่อพ่วงเอาต์พุตเสียง เช่น แจ็กเสียง 3.5 มม. แบบ 4 คอนดักเตอร์หรือพอร์ตโหมดโฮสต์ USB ที่ใช้คลาสเสียง USB อุปกรณ์ดังกล่าวจะต้องมีคุณสมบัติดังนี้

• [C-1-1] ต้องรายงานค่าคงที่ของฟีเจอร์ android.hardware.audio.output
• [C-1-2] ต้องเป็นไปตามข้อกำหนดการเล่นเสียงในส่วน 5.5
• [C-1-3] ต้องเป็นไปตามข้อกำหนดด้านเวลาในการตอบสนองของเสียงในส่วนที่ 5.6
• [SR] ขอแนะนำอย่างยิ่งให้รองรับการเล่นเสียงที่เกือบจะเป็นอัลตราซาวด์ตามที่อธิบายไว้ในส่วน 7.8.3

หากการติดตั้งใช้งานอุปกรณ์ไม่มีลำโพงหรือพอร์ตเอาต์พุตเสียง อุปกรณ์ดังกล่าวจะ

• [C-2-1] ต้องไม่รายงานฟีเจอร์ android.hardware.audio.output
• [C-2-2] ต้องใช้ API ที่เกี่ยวข้องกับเอาต์พุตเสียงเป็นฟังก์ชันที่ไม่มีการดำเนินการอย่างน้อย

สำหรับวัตถุประสงค์ของส่วนนี้ "พอร์ตเอาต์พุต" คืออินเทอร์เฟซจริง เช่น ช่องเสียบเสียง 3.5 มม., HDMI หรือพอร์ตโหมดโฮสต์ USB ที่มีคลาสเสียง USB การรองรับเอาต์พุตเสียงผ่านโปรโตคอลที่ใช้คลื่นวิทยุ เช่น บลูทูธ, Wi-Fi หรือเครือข่ายมือถือ ไม่ถือว่าเป็นการรวม "พอร์ตเอาต์พุต"

7.8.2.1. พอร์ตเสียงแอนะล็อก

หากต้องการให้ใช้งานร่วมกับชุดหูฟังและอุปกรณ์เสริมสำหรับเสียงอื่นๆ ที่ใช้ปลั๊กเสียง 3.5 มม. ในระบบนิเวศ Android ได้ หากการติดตั้งใช้งานอุปกรณ์มีพอร์ตเสียงแอนะล็อกอย่างน้อย 1 พอร์ต อุปกรณ์จะต้องมีคุณสมบัติดังนี้

• [C-SR] ขอแนะนำอย่างยิ่งให้มีพอร์ตเสียงอย่างน้อย 1 พอร์ตเป็นแจ็กเสียง 3.5 มม. แบบ 4 คอนดักเตอร์

หากการติดตั้งใช้งานอุปกรณ์มีช่องเสียบเสียง 3.5 มม. แบบ 4 คอนดักเตอร์ จะมีลักษณะดังนี้

• [C-1-1] ต้องรองรับการเล่นเสียงไปยังหูฟังสเตอริโอและชุดหูฟังสเตอริโอที่มีไมโครโฟน
• [C-1-2] ต้องรองรับปลั๊กเสียง TRRS ที่มีลำดับการต่อขาของ CTIA
• [C-1-3] ต้องรองรับการตรวจจับและการแมปกับรหัสคีย์สำหรับช่วงความต้านทานสมมูล 3 ช่วงต่อไปนี้ระหว่างไมโครโฟนกับตัวนำกราวด์บนปลั๊กเสียง
  • 70 โอห์มหรือน้อยกว่า: KEYCODE_HEADSETHOOK
  • 210-290 โอห์ม: KEYCODE_VOLUME_UP
  • 360-680 โอห์ม: KEYCODE_VOLUME_DOWN
• [C-1-4] ต้องทริกเกอร์ ACTION_HEADSET_PLUG เมื่อเสียบปลั๊ก แต่หลังจากที่ขั้วต่อทั้งหมดบนปลั๊กสัมผัสกับส่วนที่เกี่ยวข้องบนแจ็คแล้วเท่านั้น
• [C-1-5] ต้องสามารถขับแรงดันไฟฟ้าขาออกอย่างน้อย 150mV ± 10% ที่อิมพีแดนซ์ของลำโพง 32 โอห์ม
• [C-1-6] ต้องมีแรงดันไฟฟ้าไบแอสของไมโครโฟนระหว่าง 1.8V ~ 2.9V
• [C-1-7] ต้องตรวจหาและแมปกับรหัสแป้นสำหรับช่วงความต้านทานที่เทียบเท่าต่อไปนี้ระหว่างไมโครโฟนกับตัวนำกราวด์บนปลั๊กเสียง
  • 110-180 โอห์ม: KEYCODE_VOICE_ASSIST
• [C-SR] ขอแนะนำอย่างยิ่งให้รองรับปลั๊กเสียงที่มีลำดับการต่อพิน OMTP
• [C-SR] ขอแนะนำอย่างยิ่งให้รองรับเสียงที่บันทึกไว้จากชุดหูฟังสเตอริโอที่มีไมโครโฟน

หากการติดตั้งใช้งานอุปกรณ์มีช่องเสียบเสียง 3.5 มม. แบบ 4 คอนดักเตอร์และรองรับไมโครโฟน รวมถึงออกอากาศ android.intent.action.HEADSET_PLUG โดยตั้งค่าไมโครโฟนที่มีค่าเพิ่มเติมเป็น 1 อุปกรณ์จะทำสิ่งต่อไปนี้

• [C-2-1] ต้องรองรับการตรวจจับไมโครโฟนในอุปกรณ์เสริมเสียงที่เสียบอยู่

7.8.2.2. พอร์ตเสียงดิจิทัล

เพื่อให้ใช้งานร่วมกับชุดหูฟังและอุปกรณ์เสริมสำหรับเสียงอื่นๆ ที่ใช้ขั้วต่อ USB-C และใช้ (USB audio class) ในระบบนิเวศ Android ตามที่กำหนดไว้ในข้อกำหนดเฉพาะของชุดหูฟัง USB สำหรับ Android

ดูข้อกำหนดเฉพาะของอุปกรณ์ได้ที่ส่วน 2.2.1

7.8.3. เกือบอัลตราซาวด์

เสียงย่านความถี่ใกล้อัลตราซาวด์คือย่านความถี่ 18.5 kHz ถึง 20 kHz

การติดตั้งใช้งานอุปกรณ์

• ต้องรายงานการรองรับความสามารถด้านเสียงย่านใกล้อัลตราซาวด์อย่างถูกต้องผ่าน API AudioManager.getProperty ดังนี้

หาก PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND เป็น "จริง" แหล่งที่มาของเสียง VOICE_RECOGNITION และ UNPROCESSED จะต้องเป็นไปตามข้อกำหนดต่อไปนี้

• [C-1-1] การตอบสนองต่อกำลังเฉลี่ยของไมโครโฟนในแถบความถี่ 18.5 kHz ถึง 20 kHz ต้องไม่ต่ำกว่าการตอบสนองที่ 2 kHz เกิน 15 dB
• [C-1-2] อัตราส่วนสัญญาณต่อสัญญาณรบกวนแบบไม่ถ่วงน้ำหนักของไมโครโฟนในช่วง 18.5 kHz ถึง 20 kHz สำหรับโทน 19 kHz ที่ -26 dBFS ต้องไม่ต่ำกว่า 50 dB

หาก PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND เป็น "จริง"

• [C-2-1] การตอบสนองเฉลี่ยของลำโพงที่ 18.5 kHz - 20 kHz ต้องไม่ต่ำกว่า 40 dB ที่ต่ำกว่าการตอบสนองที่ 2 kHz

7.8.4. ความสมบูรณ์ของสัญญาณ

การใช้งานอุปกรณ์: * ควรมีเส้นทางสัญญาณเสียงที่ราบรื่นสำหรับทั้งสตรีมอินพุตและเอาต์พุตในอุปกรณ์พกพา ตามที่กำหนดโดยไม่มีข้อบกพร่องที่วัดได้ในระหว่างการทดสอบ 1 นาทีต่อเส้นทาง ทดสอบโดยใช้ [OboeTester] (https://github.com/google/oboe/tree/master/apps/OboeTester) "การทดสอบข้อบกพร่องอัตโนมัติ"

การทดสอบต้องใช้ดองเกิลเสียงแบบลูปแบ็กที่ใช้ในแจ็ก 3.5 มม. โดยตรง และ/หรือใช้ร่วมกับอะแดปเตอร์ USB-C เป็น 3.5 มม. ควรทดสอบพอร์ตเอาต์พุตเสียงทั้งหมด

ปัจจุบัน OboeTester รองรับเส้นทาง AAudio ดังนั้นควรทดสอบชุดค่าผสมต่อไปนี้เพื่อหาข้อบกพร่องโดยใช้ AAudio

สตรีมที่เชื่อถือได้ควรเป็นไปตามเกณฑ์ต่อไปนี้สำหรับอัตราส่วนสัญญาณต่อสัญญาณรบกวน (SNR) และความเพี้ยนฮาร์มอนิกทั้งหมด (THD) สำหรับไซน์ 2000 Hz

7.9. Virtual Reality

Android มี API และเครื่องมือในการสร้างแอปพลิเคชัน "Virtual Reality" (VR) ซึ่งรวมถึงประสบการณ์การใช้งาน VR บนอุปกรณ์เคลื่อนที่คุณภาพสูง การติดตั้งใช้งานอุปกรณ์ต้องใช้ API และลักษณะการทำงานเหล่านี้อย่างถูกต้องตามที่ระบุไว้ในส่วนนี้

7.9.1. โหมดความจริงเสมือน

Android รองรับโหมด VR ซึ่งเป็นฟีเจอร์ที่จัดการการแสดงผลแบบสเตอริโอของการแจ้งเตือนและปิดใช้คอมโพเนนต์ UI ของระบบแบบตาเดียวในขณะที่แอปพลิเคชัน VR ได้รับความสนใจจากผู้ใช้

7.9.2. โหมดความจริงเสมือน - ประสิทธิภาพสูง

หากการใช้งานอุปกรณ์รองรับโหมด VR อุปกรณ์จะทำสิ่งต่อไปนี้

• [C-1-1] ต้องมี Physical Core อย่างน้อย 2 Core
• [C-1-2] ต้องประกาศฟีเจอร์ android.hardware.vr.high_performance
• [C-1-3] ต้องรองรับโหมดประสิทธิภาพที่ยั่งยืน
• [C-1-4] ขอแนะนำอย่างยิ่งให้รองรับ OpenGL ES 3.2
• [C-1-5] ต้องรองรับ android.hardware.vulkan.level 0
• ควรสนับสนุน android.hardware.vulkan.level 1 ขึ้นไป
• [C-1-6] ต้องใช้ EGL_KHR_mutable_render_buffer, EGL_ANDROID_front_buffer_auto_refresh, EGL_ANDROID_get_native_client_buffer, EGL_KHR_fence_sync, EGL_KHR_wait_sync, EGL_IMG_context_priority, EGL_EXT_protected_content, EGL_EXT_image_gl_colorspace และแสดงส่วนขยายในรายการส่วนขยาย EGL ที่พร้อมใช้งาน
• [C-1-8] ต้องใช้ GL_EXT_multisampled_render_to_texture2, GL_OVR_multiview, GL_OVR_multiview2, GL_EXT_protected_textures และแสดงส่วนขยายในรายการส่วนขยาย GL ที่พร้อมใช้งาน
• [C-SR] ขอแนะนำอย่างยิ่งให้ใช้ GL_EXT_external_buffer, GL_EXT_EGL_image_array, GL_OVR_multiview_multisampled_render_to_texture และแสดงส่วนขยายในรายการส่วนขยาย GL ที่พร้อมใช้งาน
• [C-SR] ขอแนะนำอย่างยิ่งให้รองรับ Vulkan 1.1
• [C-SR] ขอแนะนำอย่างยิ่งให้ใช้ VK_ANDROID_external_memory_android_hardware_buffer, VK_GOOGLE_display_timing, VK_KHR_shared_presentable_image และแสดงในรายการส่วนขยาย Vulkan ที่พร้อมใช้งาน
• [C-SR] ขอแนะนำอย่างยิ่งให้แสดงคิวตระกูล Vulkan อย่างน้อย 1 รายการที่ flags มีทั้ง VK_QUEUE_GRAPHICS_BIT และ VK_QUEUE_COMPUTE_BIT และ queueCount มีค่าอย่างน้อย 2
• [C-1-7] GPU และจอแสดงผลต้องซิงค์การเข้าถึงบัฟเฟอร์ด้านหน้าที่แชร์ได้ เพื่อให้การแสดงผลเนื้อหา VR แบบสลับตาที่ 60fps ด้วยบริบทการแสดงผล 2 รายการแสดงโดยไม่มีอาร์ติแฟกต์การฉีกขาดที่มองเห็นได้
• [C-1-9] ต้องรองรับแฟล็ก AHardwareBuffer AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER, AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA และ AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT ตามที่อธิบายไว้ใน NDK
• [C-1-10] ต้องรองรับ AHardwareBuffer โดยใช้ชุดค่าผสมใดก็ได้ของแฟล็กการใช้งาน AHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT, AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE, AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT สำหรับรูปแบบต่อไปนี้อย่างน้อย AHARDWAREBUFFER_FORMAT_R5G6B5_UNORM, AHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM, AHARDWAREBUFFER_FORMAT_R10G10B10A2_UNORM, AHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT
• [C-SR] ขอแนะนำอย่างยิ่งให้รองรับการจัดสรร AHardwareBuffer ที่มีเลเยอร์มากกว่า 1 เลเยอร์ รวมถึงรองรับการตั้งค่าสถานะและรูปแบบที่ระบุไว้ใน C-1-10
• [C-1-11] ต้องรองรับการถอดรหัส H.264 อย่างน้อย 3840 x 2160 ที่ 30 FPS โดยบีบอัดให้มีค่าเฉลี่ย 40 Mbps (เทียบเท่ากับ 4 อินสแตนซ์ของ 1920 x 1080 ที่ 30 FPS - 10 Mbps หรือ 2 อินสแตนซ์ของ 1920 x 1080 ที่ 60 FPS - 20 Mbps)
• [C-1-12] ต้องรองรับ HEVC และ VP9 ต้องถอดรหัสอย่างน้อย 1920 x 1080 ที่ 30 FPS ที่บีบอัดเป็นค่าเฉลี่ย 10 Mbps ได้ และควรถอดรหัส 3840 x 2160 ที่ 30 FPS-20 Mbps ได้ (เทียบเท่ากับ 1920 x 1080 ที่ 30 FPS-5 Mbps จำนวน 4 รายการ)
• [C-1-13] ต้องรองรับ HardwarePropertiesManager.getDeviceTemperatures API และแสดงค่าที่ถูกต้องสำหรับอุณหภูมิผิวหนัง
• [C-1-14] ต้องมีหน้าจอแบบฝัง และต้องมีความละเอียดอย่างน้อย 1920 x 1080
• [C-SR] ขอแนะนำอย่างยิ่งให้มีความละเอียดในการแสดงผลอย่างน้อย 2560 x 1440
• [C-1-15] จอแสดงผลต้องอัปเดตอย่างน้อย 60 Hz ขณะอยู่ในโหมด VR
• [C-1-17] จอแสดงผลต้องรองรับโหมดความคงทนต่ำที่มีความคงทน ≤ 5 มิลลิวินาที โดยความคงทนหมายถึงระยะเวลาที่พิกเซลเปล่งแสง
• [C-1-18] ต้องรองรับบลูทูธ 4.2 และส่วนขยายความยาวข้อมูลของบลูทูธ LE ส่วนที่ 7.4.3
• [C-1-19] ต้องรองรับและรายงานประเภทแชแนลโดยตรงอย่างถูกต้องสำหรับเซ็นเซอร์เริ่มต้นทุกประเภทต่อไปนี้
  • TYPE_ACCELEROMETER
  • TYPE_ACCELEROMETER_UNCALIBRATED
  • TYPE_GYROSCOPE
  • TYPE_GYROSCOPE_UNCALIBRATED
  • TYPE_MAGNETIC_FIELD
  • TYPE_MAGNETIC_FIELD_UNCALIBRATED
• [C-SR] ขอแนะนำอย่างยิ่งให้รองรับประเภทแชแนลโดยตรง TYPE_HARDWARE_BUFFER สำหรับประเภทแชแนลโดยตรงทั้งหมดที่ระบุไว้ข้างต้น
• [C-1-21] ต้องเป็นไปตามข้อกำหนดที่เกี่ยวข้องกับเครื่องวัดการหมุน ตัวตรวจวัดความเร่ง และเครื่องวัดค่าความเข้มข้นของสนามแม่เหล็กสำหรับ android.hardware.hifi_sensors ตามที่ระบุไว้ในส่วนที่ 7.3.9
• [C-SR] ขอแนะนำอย่างยิ่งให้รองรับandroid.hardware.sensor.hifi_sensors
• [C-1-22] ต้องมีเวลาในการตอบสนองตั้งแต่ต้นจนจบ (Motion to Photon) ไม่เกิน 28 มิลลิวินาที
• [C-SR] ขอแนะนำอย่างยิ่งให้มีเวลาในการตอบสนองแบบต้นทางถึงปลายทางตั้งแต่การเคลื่อนไหวจนถึงโฟตอนไม่เกิน 20 มิลลิวินาที
• [C-1-23] ต้องมีอัตราส่วนเฟรมแรก ซึ่งเป็นอัตราส่วนระหว่างความสว่างของพิกเซลในเฟรมแรกหลังจากเปลี่ยนจากสีดำเป็นสีขาวกับความสว่างของพิกเซลสีขาวในสถานะคงที่ อย่างน้อย 85%
• [C-SR] ขอแนะนำอย่างยิ่งให้มีอัตราส่วนเฟรมแรกอย่างน้อย 90%
• อาจจัดสรรคอร์หลักแบบเฉพาะให้กับแอปพลิเคชันที่ทำงานอยู่ และอาจรองรับ Process.getExclusiveCores API เพื่อแสดงจำนวนคอร์ CPU ที่จัดสรรแบบเฉพาะให้กับแอปพลิเคชันที่ทำงานอยู่ด้านบนสุด

หากรองรับคอร์แบบเฉพาะ คอร์จะมีลักษณะดังนี้

• [C-2-1] ต้องไม่อนุญาตให้กระบวนการในพื้นที่ผู้ใช้ใดๆ อื่นทำงานบนนั้น (ยกเว้นไดรเวอร์อุปกรณ์ที่แอปพลิเคชันใช้) แต่สามารถอนุญาตให้กระบวนการเคอร์เนลบางอย่างทำงานได้ตามความจำเป็น

7.10. การโต้ตอบการสัมผัส

ดูข้อกำหนดเฉพาะของอุปกรณ์ได้ที่ส่วน 2.2.1

7.11. คลาสประสิทธิภาพของสื่อ

คุณสามารถรับคลาสประสิทธิภาพสื่อของการใช้งานอุปกรณ์ได้จาก android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS API ข้อกำหนด สำหรับคลาสประสิทธิภาพของสื่อจะกำหนดไว้สำหรับ Android แต่ละเวอร์ชันโดยเริ่มจาก R (เวอร์ชัน 30) ค่าพิเศษ 0 หมายความว่าอุปกรณ์ไม่ได้อยู่ใน คลาสประสิทธิภาพสื่อ

หากการติดตั้งใช้งานอุปกรณ์แสดงค่าที่ไม่ใช่ 0 สำหรับ android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS จะมีลักษณะดังนี้

• [C-1-1] ต้องแสดงผลค่าอย่างน้อย android.os.Build.VERSION_CODES.R

• [C-1-2] ต้องเป็นการใช้งานอุปกรณ์พกพา

• [C-1-3] ต้องมีคุณสมบัติตรงตามข้อกำหนดทั้งหมดสำหรับ "คลาสประสิทธิภาพของสื่อ" ที่อธิบายไว้ ในส่วน 2.2.7

ดูข้อกำหนดเฉพาะของอุปกรณ์ได้ที่ส่วน 2.2.7

8. ประสิทธิภาพและพลังงาน

เกณฑ์ด้านประสิทธิภาพและกำลังขั้นต่ำบางอย่างมีความสำคัญต่อประสบการณ์ของผู้ใช้ และส่งผลต่อสมมติฐานพื้นฐานที่นักพัฒนาแอปจะมีเมื่อพัฒนาแอป

8.1. ความสอดคล้องของประสบการณ์ของผู้ใช้

คุณสามารถมอบอินเทอร์เฟซผู้ใช้ที่ราบรื่นให้แก่ผู้ใช้ปลายทางได้หากมีข้อกำหนดขั้นต่ำบางอย่างเพื่อให้มั่นใจว่าแอปพลิเคชันและเกมจะมีอัตราเฟรมและเวลาตอบสนองที่สอดคล้องกัน การติดตั้งใช้งานอุปกรณ์อาจมีข้อกำหนดที่วัดได้สำหรับเวลาในการตอบสนองของอินเทอร์เฟซผู้ใช้และการสลับงานตามที่อธิบายไว้ในส่วนที่ 2 ทั้งนี้ขึ้นอยู่กับประเภทอุปกรณ์

8.2. ประสิทธิภาพการเข้าถึง I/O ของไฟล์

การกำหนดเกณฑ์พื้นฐานทั่วไปสำหรับประสิทธิภาพการเข้าถึงไฟล์ที่สอดคล้องกันในที่เก็บข้อมูลส่วนตัวของแอปพลิเคชัน (พาร์ติชัน /data) ช่วยให้นักพัฒนาแอปตั้งความคาดหวังที่เหมาะสมซึ่งจะช่วยในการออกแบบซอฟต์แวร์ได้ การใช้งานอุปกรณ์อาจมีข้อกำหนดบางอย่างที่อธิบายไว้ในส่วนที่ 2 สำหรับการอ่านและการเขียนต่อไปนี้ ทั้งนี้ขึ้นอยู่กับประเภทอุปกรณ์

• ประสิทธิภาพการเขียนตามลำดับ วัดโดยการเขียนไฟล์ขนาด 256 MB โดยใช้บัฟเฟอร์การเขียนขนาด 10 MB
• ประสิทธิภาพการเขียนแบบสุ่ม วัดโดยการเขียนไฟล์ขนาด 256 MB โดยใช้บัฟเฟอร์การเขียนขนาด 4 KB
• ประสิทธิภาพการอ่านแบบต่อเนื่อง วัดโดยการอ่านไฟล์ขนาด 256 MB โดยใช้บัฟเฟอร์การเขียนขนาด 10 MB
• ประสิทธิภาพการอ่านแบบสุ่ม วัดโดยการอ่านไฟล์ขนาด 256 MB โดยใช้บัฟเฟอร์การเขียนขนาด 4 KB

8.3 โหมดประหยัดพลังงาน

หากการใช้งานอุปกรณ์มีฟีเจอร์เพื่อปรับปรุงการจัดการพลังงานของอุปกรณ์ซึ่งรวมอยู่ใน AOSP (เช่น กลุ่มพักแอป, โหมดพักเครื่อง) หรือขยายฟีเจอร์ที่ไม่ได้ใช้ข้อจำกัดที่เข้มงวดกว่ากลุ่มพักแอปที่ใช้ไม่บ่อย จะมีลักษณะดังนี้

• [C-1-1] ต้องไม่เบี่ยงเบนจากการใช้งาน AOSP สำหรับอัลกอริทึมการทริกเกอร์ การบำรุงรักษา การปลุกระบบ และการใช้การตั้งค่าระบบส่วนกลางของโหมดประหยัดพลังงาน สแตนด์บายแอป และโหมด Doze
• [C-1-2] ต้องไม่เบี่ยงเบนจากการติดตั้งใช้งาน AOSP สำหรับการใช้การตั้งค่าส่วนกลางเพื่อจัดการการจำกัดอัตราของงาน การปลุก และเครือข่ายสำหรับแอปในแต่ละ Bucket สำหรับ App Standby
• [C-1-3] ต้องไม่เบี่ยงเบนจากการใช้งาน AOSP สำหรับจำนวนกลุ่มสแตนด์บายแอปที่ใช้สำหรับสแตนด์บายแอป
• [C-1-4] ต้องใช้ที่เก็บสแตนด์บายแอปและ Doze ตามที่อธิบายไว้ในการจัดการพลังงาน
• [C-1-5] ต้องส่งคืน true สำหรับ PowerManager.isPowerSaveMode() เมื่ออุปกรณ์อยู่ในโหมดประหยัดพลังงาน
• [C-SR] ขอแนะนำอย่างยิ่งให้ระบุความสามารถของผู้ใช้ในการเปิดและปิดใช้ฟีเจอร์ประหยัดแบตเตอรี่
• [C-SR] ขอแนะนำอย่างยิ่งให้ระบุข้อบ่งชี้การใช้งานของผู้ใช้ในการแสดงแอปทั้งหมดที่ได้รับการยกเว้นจากโหมดสแตนด์บายแอปและโหมดประหยัดพลังงาน Doze

หากการใช้งานอุปกรณ์ขยายฟีเจอร์การจัดการพลังงานที่รวมอยู่ใน AOSP และส่วนขยายนั้นใช้ข้อจำกัดที่เข้มงวดกว่าที่เก็บข้อมูลสแตนด์บายแอปที่ใช้ไม่บ่อย โปรดดูส่วนที่ 3.5.1

นอกเหนือจากโหมดประหยัดพลังงานแล้ว การติดตั้งใช้งานอุปกรณ์ Android อาจใช้สถานะพลังงานขณะพักทั้ง 4 สถานะตามที่กำหนดโดย Advanced Configuration and Power Interface (ACPI)

หากการใช้งานอุปกรณ์ใช้สถานะเปิด/ปิด S4 ตามที่กำหนดโดย ACPI จะมีลักษณะดังนี้

• [C-1-1] ต้องเข้าสู่สถานะนี้หลังจากที่ผู้ใช้ดำเนินการอย่างชัดเจนเพื่อให้อุปกรณ์อยู่ในสถานะไม่ได้ใช้งานเท่านั้น (เช่น ปิดฝาซึ่งเป็นส่วนหนึ่งของอุปกรณ์ หรือปิดรถหรือโทรทัศน์) และก่อนที่ผู้ใช้จะเปิดใช้งานอุปกรณ์อีกครั้ง (เช่น เปิดฝาหรือเปิดรถหรือโทรทัศน์อีกครั้ง)

หากการใช้งานอุปกรณ์ใช้สถานะการเปิด/ปิด S3 ตามที่ ACPI กำหนด อุปกรณ์จะทำสิ่งต่อไปนี้

• [C-2-1] ต้องเป็นไปตาม C-1-1 ด้านบน หรือต้องเข้าสู่สถานะ S3 เฉพาะเมื่อแอปพลิเคชันของบุคคลที่สามไม่ต้องการทรัพยากรของระบบ (เช่น หน้าจอ, CPU)

  ในทางกลับกัน จะต้องออกจากสถานะ S3 เมื่อแอปพลิเคชันของบุคคลที่สามต้องการทรัพยากรของระบบ ตามที่อธิบายไว้ใน SDK นี้

  ตัวอย่างเช่น ขณะที่แอปพลิเคชันของบุคคลที่สามขอให้เปิดหน้าจอไว้ผ่าน FLAG_KEEP_SCREEN_ON หรือให้ CPU ทำงานต่อไปผ่าน PARTIAL_WAKE_LOCK อุปกรณ์ต้องไม่เข้าสู่สถานะ S3 เว้นแต่ว่าผู้ใช้ได้ดำเนินการอย่างชัดแจ้งเพื่อให้อุปกรณ์อยู่ในสถานะไม่ได้ใช้งาน ตามที่อธิบายไว้ใน C-1-1 ในทางกลับกัน เมื่อมีการทริกเกอร์งานที่แอปของบุคคลที่สามใช้ผ่าน JobScheduler หรือเมื่อมีการส่ง Firebase Cloud Messaging ไปยังแอปของบุคคลที่สาม อุปกรณ์จะต้องออกจากสถานะ S3 เว้นแต่ผู้ใช้จะทำให้อุปกรณ์อยู่ในสถานะไม่ได้ใช้งาน นี่เป็นเพียงตัวอย่างโดยสังเขปเท่านั้น และ AOSP ใช้สัญญาณปลุกที่หลากหลายซึ่งทริกเกอร์การปลุกจากสถานะนี้

8.4. การบัญชีการใช้พลังงาน

การบัญชีและการรายงานการใช้พลังงานที่แม่นยำยิ่งขึ้นจะช่วยให้นักพัฒนาแอปได้รับทั้งสิ่งจูงใจและเครื่องมือในการเพิ่มประสิทธิภาพรูปแบบการใช้พลังงานของแอปพลิเคชัน

การติดตั้งใช้งานอุปกรณ์

• [SR] ขอแนะนำอย่างยิ่งให้ระบุโปรไฟล์พลังงานต่อคอมโพเนนต์ที่กำหนดค่าการใช้พลังงานปัจจุบันสำหรับคอมโพเนนต์ฮาร์ดแวร์แต่ละรายการ และการระบายแบตเตอรี่โดยประมาณที่เกิดจากคอมโพเนนต์เมื่อเวลาผ่านไปตามที่ระบุไว้ในเว็บไซต์ Android Open Source Project
• [SR] ขอแนะนำอย่างยิ่งให้รายงานค่าการใช้พลังงานทั้งหมดเป็นมิลลิแอมแปร์ชั่วโมง (mAh)
• [SR] ขอแนะนำอย่างยิ่งให้รายงานการใช้พลังงาน CPU ต่อ UID ของแต่ละกระบวนการ โครงการโอเพนซอร์ส Android เป็นไปตามข้อกำหนดผ่านuid_cputimeการติดตั้งใช้งานโมดูลเคอร์เนล
• [SR] ขอแนะนำอย่างยิ่งให้เปิดใช้การใช้พลังงานนี้ผ่านคำสั่งเชลล์ adb shell dumpsys batterystats แก่นักพัฒนาแอป
• ควรระบุแหล่งที่มาของคอมโพเนนต์ฮาร์ดแวร์เองหากระบุแหล่งที่มาของการใช้พลังงานของคอมโพเนนต์ฮาร์ดแวร์ไปยังแอปพลิเคชันไม่ได้

8.5 ประสิทธิภาพที่สม่ำเสมอ

ประสิทธิภาพอาจผันผวนอย่างมากสำหรับแอปที่มีประสิทธิภาพสูงซึ่งทำงานเป็นเวลานาน ไม่ว่าจะเป็นเพราะแอปอื่นๆ ที่ทำงานในเบื้องหลังหรือการควบคุมปริมาณ CPU เนื่องจากขีดจำกัดด้านอุณหภูมิ Android มีอินเทอร์เฟซแบบเป็นโปรแกรมเพื่อให้แอปพลิเคชันที่อยู่ด้านบนสุดในเบื้องหน้าสามารถขอให้ระบบเพิ่มประสิทธิภาพการจัดสรรทรัพยากรเพื่อรับมือกับความผันผวนดังกล่าวได้เมื่ออุปกรณ์พร้อม

การติดตั้งใช้งานอุปกรณ์

• [C-0-1] ต้องรายงานการรองรับโหมดประสิทธิภาพที่ยั่งยืนอย่างถูกต้องผ่านเมธอด API ของ PowerManager.isSustainedPerformanceModeSupported()

• ควรสนับสนุนโหมดประสิทธิภาพที่ยั่งยืน

หากการใช้งานอุปกรณ์รายงานว่ารองรับโหมดประสิทธิภาพที่ยั่งยืน อุปกรณ์จะต้องมีคุณสมบัติดังนี้

• [C-1-1] ต้องมอบประสิทธิภาพระดับคงที่ให้กับแอปพลิเคชันที่อยู่เบื้องหน้าสูงสุดเป็นเวลาอย่างน้อย 30 นาที เมื่อแอปขอ
• [C-1-2] ต้องปฏิบัติตาม API ของ Window.setSustainedPerformanceMode() และ API อื่นๆ ที่เกี่ยวข้อง

หากการติดตั้งใช้งานอุปกรณ์มีคอร์ CPU 2 คอร์ขึ้นไป อุปกรณ์จะต้องมีคุณสมบัติดังนี้

• ควรมีคอร์หลักแบบพิเศษอย่างน้อย 1 คอร์ที่แอปพลิเคชันส่วนหน้าด้านบนสามารถจองได้

หากการใช้งานอุปกรณ์รองรับการจองคอร์แบบพิเศษ 1 คอร์สำหรับแอปพลิเคชันที่ทำงานอยู่เบื้องหน้าสูงสุด อุปกรณ์จะดำเนินการต่อไปนี้

• [C-2-1] ต้องรายงานผ่านวิธีการ API ของ Process.getExclusiveCores() หมายเลขรหัสของคอร์แบบพิเศษที่แอปพลิเคชันที่ทำงานอยู่เบื้องหน้าด้านบนสามารถจองได้
• [C-2-2] ต้องไม่อนุญาตให้กระบวนการในพื้นที่ผู้ใช้ใดๆ ยกเว้นไดรเวอร์อุปกรณ์ที่แอปพลิเคชันใช้เพื่อเรียกใช้ในคอร์แบบเฉพาะ แต่สามารถอนุญาตให้กระบวนการเคอร์เนลบางอย่างทำงานได้ตามความจำเป็น

หากการติดตั้งใช้งานอุปกรณ์ไม่รองรับคอร์แบบเฉพาะ จะเกิดกรณีต่อไปนี้

• [C-3-1] ต้องแสดงรายการว่างผ่านเมธอด API Process.getExclusiveCores()

9. ความเข้ากันได้ของโมเดลความปลอดภัย

การติดตั้งใช้งานอุปกรณ์

• [C-0-1] ต้องใช้โมเดลการรักษาความปลอดภัยที่สอดคล้องกับโมเดลการรักษาความปลอดภัยของแพลตฟอร์ม Android ตามที่กำหนดไว้ในเอกสารอ้างอิงด้านความปลอดภัยและสิทธิ์ใน API ในเอกสารประกอบสำหรับนักพัฒนาแอป Android

• [C-0-2] ต้องรองรับการติดตั้งแอปพลิเคชันที่ลงนามด้วยตนเองโดยไม่ต้องขอสิทธิ์/ใบรับรองเพิ่มเติมจากบุคคลที่สาม/หน่วยงานใดๆ โดยเฉพาะอย่างยิ่ง อุปกรณ์ที่รองรับต้องรองรับกลไกการรักษาความปลอดภัยที่อธิบายไว้ในส่วนย่อยต่อไปนี้

9.1. สิทธิ์

การติดตั้งใช้งานอุปกรณ์

• [C-0-1] ต้องรองรับโมเดลสิทธิ์ของ Android ตามที่กำหนดไว้ในเอกสารประกอบสำหรับนักพัฒนาแอป Android โดยเฉพาะอย่างยิ่ง แอปต้องบังคับใช้สิทธิ์แต่ละรายการที่กำหนดไว้ตามที่อธิบายไว้ในเอกสารประกอบของ SDK โดยจะละเว้น เปลี่ยนแปลง หรือเพิกเฉยต่อสิทธิ์ใดๆ ไม่ได้

• อาจเพิ่มสิทธิ์เพิ่มเติมได้ หากสตริงรหัสสิทธิ์ใหม่ไม่ได้อยู่ในเนมสเปซ android.\*

• [C-0-2] สิทธิ์ที่มี protectionLevel เป็น PROTECTION_FLAG_PRIVILEGED ต้องให้เฉพาะแอปที่ติดตั้งล่วงหน้าในเส้นทางที่ได้รับสิทธิ์ของอิมเมจระบบและภายในชุดย่อยของสิทธิ์ที่อนุญาตอย่างชัดเจนสำหรับแต่ละแอปเท่านั้น การติดตั้งใช้งาน AOSP เป็นไปตามข้อกำหนดนี้โดยการอ่านและให้สิทธิ์ที่อนุญาตสำหรับแต่ละแอปจากไฟล์ในเส้นทาง etc/permissions/ และใช้เส้นทาง system/priv-app เป็นเส้นทางที่ได้รับสิทธิ์

สิทธิ์ที่มีระดับการป้องกันเป็น "อันตราย" คือสิทธิ์รันไทม์ แอปพลิเคชันที่มี targetSdkVersion > 22 จะขอสิทธิ์เหล่านี้ในรันไทม์

การติดตั้งใช้งานอุปกรณ์

• [C-0-3] ต้องแสดงอินเทอร์เฟซเฉพาะเพื่อให้ผู้ใช้ตัดสินใจว่าจะให้สิทธิ์รันไทม์ที่ขอหรือไม่ และต้องมีอินเทอร์เฟซให้ผู้ใช้จัดการสิทธิ์รันไทม์ด้วย
• [C-0-4] ต้องมีการติดตั้งใช้งานอินเทอร์เฟซผู้ใช้ทั้ง 2 แบบเพียงแบบเดียวเท่านั้น
• [C-0-5] ต้องไม่ให้สิทธิ์รันไทม์แก่แอปที่ติดตั้งไว้ล่วงหน้า เว้นแต่ในกรณีต่อไปนี้
  • คุณขอความยินยอมจากผู้ใช้ได้ก่อนที่แอปพลิเคชันจะใช้ข้อมูล
  • สิทธิ์รันไทม์จะเชื่อมโยงกับรูปแบบ Intent ที่ตั้งค่าแอปพลิเคชันที่ติดตั้งไว้ล่วงหน้าเป็นตัวแฮนเดิลเริ่มต้น
• [C-0-6] ต้องให้android.permission.RECOVER_KEYSTOREสิทธิ์เฉพาะแอปของระบบที่ลงทะเบียน Recovery Agent ที่ปลอดภัยอย่างเหมาะสม ตัวแทนการกู้คืนที่ปลอดภัยอย่างเหมาะสมหมายถึงตัวแทนซอฟต์แวร์ในอุปกรณ์ที่ซิงค์กับพื้นที่เก็บข้อมูลระยะไกลนอกอุปกรณ์ ซึ่งติดตั้งฮาร์ดแวร์ที่ปลอดภัยพร้อมการป้องกันที่เทียบเท่าหรือแข็งแกร่งกว่าที่อธิบายไว้ในบริการ Google Cloud Key Vault เพื่อป้องกันการโจมตีแบบ Brute Force ในปัจจัยความรู้ของหน้าจอล็อก

การติดตั้งใช้งานอุปกรณ์

• [C-0-7] ต้องปฏิบัติตามพร็อพเพอร์ตี้สิทธิ์เข้าถึงตำแหน่งของ Android เมื่อแอปขอข้อมูลตำแหน่งหรือข้อมูลกิจกรรมการเคลื่อนไหวร่างกายผ่าน Android API มาตรฐานหรือกลไกที่เป็นกรรมสิทธิ์ ข้อมูลดังกล่าวรวมถึงแต่ไม่จำกัดเพียงข้อมูลต่อไปนี้

  • ตำแหน่งของอุปกรณ์ (เช่น ละติจูดและลองจิจูด)
  • ข้อมูลที่ใช้ในการระบุหรือประมาณตำแหน่งของอุปกรณ์ได้ (เช่น SSID, BSSID, รหัสเซลล์ หรือตำแหน่งของเครือข่ายที่อุปกรณ์เชื่อมต่ออยู่)
  • กิจกรรมการเคลื่อนไหวร่างกายของผู้ใช้หรือการจัดประเภทกิจกรรมการเคลื่อนไหวร่างกาย

โดยเฉพาะอย่างยิ่ง การใช้งานอุปกรณ์มีดังนี้

• [C-0-8] ต้องได้รับความยินยอมจากผู้ใช้เพื่ออนุญาตให้แอปเข้าถึง ข้อมูลตำแหน่งหรือกิจกรรมการเคลื่อนไหวร่างกาย
• [C-0-9] ต้องให้สิทธิ์รันไทม์แก่แอปที่มี สิทธิ์เพียงพอตามที่อธิบายไว้ใน SDK เท่านั้น เช่น TelephonyManager#getServiceState ต้องใช้ android.permission.ACCESS_FINE_LOCATION

คุณสามารถทําเครื่องหมายสิทธิ์เป็นแบบจํากัดเพื่อเปลี่ยนลักษณะการทํางานของสิทธิ์ได้

• [C-0-10] ต้องไม่ให้สิทธิ์ที่มีเครื่องหมาย hardRestricted แก่แอป เว้นแต่ในกรณีต่อไปนี้

  • ไฟล์ APK ของแอปอยู่ในพาร์ติชันระบบ
  • ผู้ใช้กำหนดบทบาทที่เชื่อมโยงกับสิทธิ์ hardRestricted ให้กับแอป
  • โปรแกรมติดตั้งจะให้สิทธิ์ hardRestricted แก่แอป
  • แอปได้รับhardRestrictedใน Android เวอร์ชันก่อนหน้า

• [C-0-11] แอปที่ถือสิทธิ์ softRestricted ต้องได้รับสิทธิ์เข้าถึงแบบจำกัดเท่านั้น และต้องไม่ได้รับสิทธิ์เข้าถึงแบบเต็มจนกว่าจะได้รับอนุญาตตามที่อธิบายไว้ใน SDK ซึ่งมีการกำหนดสิทธิ์เข้าถึงแบบเต็มและแบบจำกัดสำหรับสิทธิ์ softRestricted แต่ละรายการ (เช่น READ_EXTERNAL_STORAGE)

หากการติดตั้งใช้งานอุปกรณ์มีตัวเลือกให้ผู้ใช้เลือกแอปที่สามารถวาดทับแอปอื่นๆ ด้วยกิจกรรมที่จัดการ Intent ACTION_MANAGE_OVERLAY_PERMISSION จะมีลักษณะดังนี้

• [C-2-1] ต้องตรวจสอบว่ากิจกรรมทั้งหมดที่มีตัวกรอง Intent สำหรับ Intent ACTION_MANAGE_OVERLAY_PERMISSION มีหน้าจอ UI เดียวกัน ไม่ว่าแอปที่เริ่มต้นหรือข้อมูลใดๆ ที่แอปนั้นระบุจะเป็นอย่างไรก็ตาม

9.2. UID และการแยกกระบวนการ

การติดตั้งใช้งานอุปกรณ์

• [C-0-1] ต้องรองรับรูปแบบแซนด์บ็อกซ์ของแอปพลิเคชัน Android ซึ่งแต่ละแอปพลิเคชันจะทำงานเป็น UID รูปแบบ Unix ที่ไม่ซ้ำกันและในกระบวนการแยกต่างหาก
• [C-0-2] ต้องรองรับการเรียกใช้แอปพลิเคชันหลายรายการเป็นรหัสผู้ใช้ Linux เดียวกัน โดยแอปพลิเคชันจะต้องได้รับการลงนามและสร้างอย่างถูกต้องตามที่กำหนดไว้ในข้อมูลอ้างอิงด้านความปลอดภัยและสิทธิ์

9.3 สิทธิ์ของระบบไฟล์

การติดตั้งใช้งานอุปกรณ์

• [C-0-1] ต้องรองรับรูปแบบสิทธิ์การเข้าถึงไฟล์ของ Android ตามที่กำหนดไว้ในข้อมูลอ้างอิงด้านความปลอดภัยและสิทธิ์

9.4 สภาพแวดล้อมการดำเนินการอื่น

การติดตั้งใช้งานอุปกรณ์ต้องรักษาความสอดคล้องของโมเดลความปลอดภัยและสิทธิ์ของ Android แม้ว่าจะมีสภาพแวดล้อมรันไทม์ที่เรียกใช้แอปพลิเคชันโดยใช้ซอฟต์แวร์หรือเทคโนโลยีอื่นๆ นอกเหนือจากรูปแบบที่เรียกใช้งานได้ของ Dalvik หรือโค้ดแบบเนทีฟก็ตาม กล่าวคือ

• [C-0-1] รันไทม์สำรองต้องเป็นแอปพลิเคชัน Android และต้องปฏิบัติตามรูปแบบความปลอดภัยมาตรฐานของ Android ตามที่อธิบายไว้ในส่วนที่ 9

• [C-0-2] รันไทม์สำรองต้องไม่ได้รับสิทธิ์เข้าถึงทรัพยากรที่ได้รับการปกป้องโดยสิทธิ์ที่ไม่ได้ขอในไฟล์ AndroidManifest.xml ของรันไทม์ผ่านกลไก <uses-permission>

• [C-0-3] รันไทม์ทางเลือกต้องไม่อนุญาตให้แอปพลิเคชันใช้ฟีเจอร์ที่ได้รับการปกป้องโดยสิทธิ์ของ Android ซึ่งจำกัดไว้สำหรับแอปพลิเคชันระบบ

• [C-0-4] รันไทม์สำรองต้องเป็นไปตามรูปแบบแซนด์บ็อกซ์ของ Android และแอปพลิเคชันที่ติดตั้งโดยใช้รันไทม์สำรองต้องไม่นำแซนด์บ็อกซ์ของแอปอื่นที่ติดตั้งในอุปกรณ์มาใช้ซ้ำ ยกเว้นผ่านกลไกมาตรฐานของ Android สำหรับรหัสผู้ใช้ที่แชร์และใบรับรองการลงนาม

• [C-0-5] รันไทม์สำรองต้องไม่เปิดตัวพร้อมกับ ไม่ให้สิทธิ์ หรือไม่ได้รับสิทธิ์เข้าถึงแซนด์บ็อกซ์ที่สอดคล้องกับแอปพลิเคชัน Android อื่นๆ

• [C-0-6] รันไทม์สำรองต้องไม่เปิดตัว ไม่ได้รับ หรือไม่ให้สิทธิ์ใดๆ ของผู้ใช้ขั้นสูง (รูท) หรือรหัสผู้ใช้ใดๆ แก่แอปพลิเคชันอื่นๆ

• [C-0-7] เมื่อรวมไฟล์ .apk ของรันไทม์สำรองไว้ในอิมเมจระบบของการติดตั้งใช้งานอุปกรณ์ จะต้องลงนามด้วยคีย์ที่แตกต่างจากคีย์ที่ใช้ลงนามแอปพลิเคชันอื่นๆ ที่รวมอยู่ในการติดตั้งใช้งานอุปกรณ์

• [C-0-8] เมื่อติดตั้งแอปพลิเคชัน รันไทม์สำรองต้องได้รับความยินยอมจากผู้ใช้สำหรับสิทธิ์ Android ที่แอปพลิเคชันใช้

• [C-0-9] เมื่อแอปพลิเคชันต้องการใช้ทรัพยากรของอุปกรณ์ซึ่งมีสิทธิ์ Android ที่เกี่ยวข้อง (เช่น กล้อง, GPS ฯลฯ) รันไทม์สำรองต้องแจ้งให้ผู้ใช้ทราบว่าแอปพลิเคชันจะเข้าถึงทรัพยากรดังกล่าวได้

• [C-0-10] เมื่อสภาพแวดล้อมรันไทม์ไม่ได้บันทึกความสามารถของแอปพลิเคชันในลักษณะนี้ สภาพแวดล้อมรันไทม์จะต้องแสดงรายการสิทธิ์ทั้งหมดที่รันไทม์ถือครองอยู่เมื่อติดตั้งแอปพลิเคชันใดก็ตามที่ใช้รันไทม์นั้น

• รันไทม์สำรองควรติดตั้งแอปผ่าน PackageManager ลงในแซนด์บ็อกซ์ Android แยกต่างหาก (รหัสผู้ใช้ Linux ฯลฯ)

• รันไทม์สำรองอาจมีแซนด์บ็อกซ์ Android เดียวที่แชร์โดยแอปพลิเคชันทั้งหมดที่ใช้รันไทม์สำรอง

9.5 การรองรับผู้ใช้หลายคน

Android มีการรองรับผู้ใช้หลายคนและรองรับการแยกผู้ใช้อย่างเต็มรูปแบบ

• การใช้งานอุปกรณ์อาจเปิดใช้ผู้ใช้หลายคนได้ แต่ไม่ควรเปิดใช้หากใช้สื่อแบบถอดได้สำหรับพื้นที่เก็บข้อมูลภายนอกหลัก

หากการใช้งานอุปกรณ์มีผู้ใช้หลายคน จะต้องมีคุณสมบัติดังนี้

• [C-1-1] ต้องเป็นไปตามข้อกำหนดต่อไปนี้ที่เกี่ยวข้องกับการรองรับผู้ใช้หลายคน
• [C-1-2] ต้องใช้โมเดลความปลอดภัยที่สอดคล้องกับโมเดลความปลอดภัยของแพลตฟอร์ม Android ตามที่กำหนดไว้ในเอกสารอ้างอิงด้านความปลอดภัยและสิทธิ์ใน API สำหรับผู้ใช้แต่ละราย
• [C-1-3] ต้องมีไดเรกทอรีที่เก็บข้อมูลแอปพลิเคชันที่ใช้ร่วมกันแยกต่างหากและแยกกัน (หรือที่เรียกว่า /sdcard) สำหรับอินสแตนซ์ของผู้ใช้แต่ละราย
• [C-1-4] ต้องตรวจสอบว่าแอปพลิเคชันที่เป็นของและทำงานในนามของผู้ใช้ที่ระบุไม่สามารถแสดง อ่าน หรือเขียนไฟล์ที่เป็นของผู้ใช้รายอื่น แม้ว่าข้อมูลของผู้ใช้ทั้ง 2 รายจะจัดเก็บอยู่ในวอลุ่มหรือระบบไฟล์เดียวกันก็ตาม
• [C-1-5] ต้องเข้ารหัสเนื้อหาของการ์ด SD เมื่อเปิดใช้ผู้ใช้หลายคนโดยใช้คีย์ที่จัดเก็บไว้ในสื่อที่ถอดออกไม่ได้เท่านั้น ซึ่งระบบจะเข้าถึงได้เท่านั้น หากการติดตั้งใช้งานอุปกรณ์ใช้สื่อที่ถอดออกได้สำหรับ API พื้นที่เก็บข้อมูลภายนอก เนื่องจากวิธีนี้จะทำให้โฮสต์พีซีอ่านสื่อไม่ได้ การติดตั้งใช้งานอุปกรณ์จะต้องเปลี่ยนไปใช้ MTP หรือระบบที่คล้ายกันเพื่อให้โฮสต์พีซีเข้าถึงข้อมูลของผู้ใช้ปัจจุบันได้

9.6 คำเตือนเกี่ยวกับ SMS แบบพรีเมียม

Android รองรับการแจ้งเตือนผู้ใช้เกี่ยวกับข้อความ SMS พรีเมียมขาออก ข้อความ SMS แบบพรีเมียมคือข้อความที่ส่งไปยังบริการที่ลงทะเบียนกับผู้ให้บริการ ซึ่งอาจมีการเรียกเก็บเงินจากผู้ใช้

หากการติดตั้งใช้งานอุปกรณ์ประกาศการรองรับ android.hardware.telephony จะมีลักษณะดังนี้

• [C-1-1] ต้องเตือนผู้ใช้ก่อนส่งข้อความ SMS ไปยังหมายเลขที่ระบุโดยนิพจน์ทั่วไปที่กำหนดไว้ใน/data/misc/sms/codes.xmlไฟล์ในอุปกรณ์ Android Open Source Project ต้นทางมีการติดตั้งใช้งานที่เป็นไปตามข้อกำหนดนี้

9.7. Security Features

การติดตั้งใช้งานอุปกรณ์ต้องเป็นไปตามฟีเจอร์ความปลอดภัยทั้งในเคอร์เนลและแพลตฟอร์มตามที่อธิบายไว้ด้านล่าง

แซนด์บ็อกซ์ของ Android มีฟีเจอร์ที่ใช้ระบบการควบคุมการเข้าถึงที่จำเป็น (MAC) ของ Security-Enhanced Linux (SELinux), การแซนด์บ็อกซ์ seccomp และฟีเจอร์ความปลอดภัยอื่นๆ ในเคอร์เนลของ Linux การติดตั้งใช้งานอุปกรณ์

• [C-0-1] ต้องรักษาความเข้ากันได้กับแอปพลิเคชันที่มีอยู่ แม้ว่าจะมีการติดตั้งใช้งาน SELinux หรือฟีเจอร์ความปลอดภัยอื่นๆ ใต้เฟรมเวิร์ก Android ก็ตาม
• [C-0-2] ต้องไม่มีอินเทอร์เฟซผู้ใช้ที่มองเห็นได้เมื่อตรวจพบการละเมิดความปลอดภัยและฟีเจอร์ความปลอดภัยที่ติดตั้งใช้งานด้านล่างเฟรมเวิร์ก Android บล็อกการละเมิดดังกล่าวได้สำเร็จ แต่จะมีอินเทอร์เฟซผู้ใช้ที่มองเห็นได้เมื่อเกิดการละเมิดความปลอดภัยที่ไม่ได้บล็อกซึ่งส่งผลให้มีการใช้ช่องโหว่สำเร็จ
• [C-0-3] ต้องไม่อนุญาตให้ผู้ใช้หรือนักพัฒนาแอปกำหนดค่า SELinux หรือฟีเจอร์ความปลอดภัยอื่นๆ ที่ติดตั้งไว้ใต้เฟรมเวิร์ก Android
• [C-0-4] ต้องไม่อนุญาตให้แอปพลิเคชันที่อาจส่งผลต่อแอปพลิเคชันอื่นผ่าน API (เช่น Device Administration API) กำหนดค่านโยบายที่ทำให้เกิดความไม่เข้ากัน
• [C-0-5] ต้องแยกเฟรมเวิร์กสื่อออกเป็นหลายกระบวนการเพื่อให้สามารถให้สิทธิ์เข้าถึงแต่ละกระบวนการได้แคบลงตามที่อธิบายไว้ในเว็บไซต์โครงการโอเพนซอร์ส Android
• [C-0-6] ต้องใช้กลไกแซนด์บ็อกซ์ของแอปพลิเคชันเคอร์เนลที่อนุญาตให้กรองการเรียกใช้ระบบโดยใช้นโยบายที่กำหนดค่าได้จากโปรแกรมแบบมัลติเธรด โปรเจ็กต์โอเพนซอร์สของ Android ต้นทางเป็นไปตามข้อกำหนดนี้โดยการเปิดใช้ seccomp-BPF ที่มีการซิงโครไนซ์กลุ่มเธรด (TSYNC) ตามที่อธิบายไว้ในส่วนการกำหนดค่าเคอร์เนลของ source.android.com

ฟีเจอร์ความสมบูรณ์ของเคอร์เนลและการปกป้องตนเองเป็นส่วนสำคัญของการรักษาความปลอดภัยของ Android การติดตั้งใช้งานอุปกรณ์

• [C-0-7] ต้องใช้กลไกการป้องกันการเขียนไปยังสแตกเกินขอบเขตที่กำหนดของเคอร์เนล (kernel stack buffer overflow) ตัวอย่างกลไกดังกล่าว ได้แก่ CC_STACKPROTECTOR_REGULAR และ CONFIG_CC_STACKPROTECTOR_STRONG
• [C-0-8] ต้องใช้การป้องกันหน่วยความจำเคอร์เนลอย่างเข้มงวด โดยที่โค้ดที่เรียกใช้งานได้เป็นแบบอ่านอย่างเดียว ข้อมูลแบบอ่านอย่างเดียวเรียกใช้งานและเขียนไม่ได้ และข้อมูลที่เขียนได้เรียกใช้งานไม่ได้ (เช่น CONFIG_DEBUG_RODATA หรือ CONFIG_STRICT_KERNEL_RWX)
• [C-0-9] ต้องใช้การตรวจสอบขอบเขตขนาดออบเจ็กต์แบบคงที่และแบบไดนามิกของสำเนาระหว่างพื้นที่ผู้ใช้และพื้นที่เคอร์เนล (เช่น CONFIG_HARDENED_USERCOPY) ในอุปกรณ์ที่จัดส่งพร้อมระดับ API 28 ขึ้นไป
• [C-0-10] ต้องไม่ดำเนินการหน่วยความจำในพื้นที่ผู้ใช้เมื่อดำเนินการในโหมดเคอร์เนล (เช่น PXN ของฮาร์ดแวร์ หรือจำลองผ่าน CONFIG_CPU_SW_DOMAIN_PAN หรือ CONFIG_ARM64_SW_TTBR0_PAN) ในอุปกรณ์ที่จัดส่งพร้อม API ระดับ 28 ขึ้นไป
• [C-0-11] ต้องไม่อ่านหรือเขียนหน่วยความจำในพื้นที่ผู้ใช้ในเคอร์เนลนอก API การเข้าถึง usercopy ปกติ (เช่น PAN ของฮาร์ดแวร์ หรือจำลองผ่าน CONFIG_CPU_SW_DOMAIN_PAN หรือ CONFIG_ARM64_SW_TTBR0_PAN) ในอุปกรณ์ที่จัดส่งพร้อม API ระดับ 28 ขึ้นไป
• [C-0-12] ต้องใช้การแยกตารางหน้าเคอร์เนลหากฮาร์ดแวร์มีความเสี่ยงต่อ CVE-2017-5754 ในอุปกรณ์ทั้งหมดที่จัดส่งพร้อม API ระดับ 28 ขึ้นไป (เช่น CONFIG_PAGE_TABLE_ISOLATION หรือ CONFIG_UNMAP_KERNEL_AT_EL0)
• [C-0-13] ต้องใช้การเสริมความแข็งแกร่งในการคาดการณ์สาขาหากฮาร์ดแวร์มีความเสี่ยงต่อ CVE-2017-5715 ในอุปกรณ์ทั้งหมดที่จัดส่งพร้อม API ระดับ 28 ขึ้นไป (เช่น CONFIG_HARDEN_BRANCH_PREDICTOR)
• [SR] ขอแนะนำอย่างยิ่งให้เก็บข้อมูลเคอร์เนลซึ่งเขียนเฉพาะในระหว่างการเริ่มต้นระบบ โดยทำเครื่องหมายเป็นแบบอ่านอย่างเดียวหลังจากการเริ่มต้นระบบ (เช่น __ro_after_init)

• [C-SR] ขอแนะนำอย่างยิ่งให้สุ่มเลย์เอาต์ของโค้ดเคอร์เนลและหน่วยความจำ และหลีกเลี่ยงการเปิดเผยที่จะทำให้การสุ่มเสี่ยงต่อการถูกบุกรุก (เช่น CONFIG_RANDOMIZE_BASE ด้วยเอนโทรปีของ Bootloader ผ่าน /chosen/kaslr-seed Device Tree node หรือ EFI_RNG_PROTOCOL)

• [C-SR] ขอแนะนำอย่างยิ่งให้เปิดใช้การตรวจสอบความสมบูรณ์ของโฟลว์การควบคุม (CFI) ในเคอร์เนลเพื่อเพิ่มการป้องกันการโจมตีแบบนำโค้ดกลับมาใช้ใหม่ (เช่น CONFIG_CFI_CLANG และ CONFIG_SHADOW_CALL_STACK)

• [C-SR] ขอแนะนำอย่างยิ่งว่าอย่าปิดใช้การตรวจสอบความสมบูรณ์ของโฟลว์การควบคุม (CFI), สแต็กการเรียกแบบเงา (SCS) หรือการล้างข้อมูลการล้นของจำนวนเต็ม (IntSan) ในคอมโพเนนต์ที่เปิดใช้
• [C-SR] ขอแนะนำเป็นอย่างยิ่งให้เปิดใช้ CFI, SCS และ IntSan สำหรับคอมโพเนนต์พื้นที่ผู้ใช้ที่คำนึงถึงความปลอดภัยเพิ่มเติมตามที่อธิบายไว้ใน CFI และ IntSan
• [C-SR] ขอแนะนําอย่างยิ่งให้เปิดใช้การเริ่มต้นสแต็กในเคอร์เนลเพื่อป้องกันการใช้ตัวแปรภายในที่ไม่ได้เริ่มต้น (CONFIG_INIT_STACK_ALL หรือ CONFIG_INIT_STACK_ALL_ZERO) นอกจากนี้ การใช้งานอุปกรณ์ไม่ควรสมมติค่าที่คอมไพเลอร์ใช้ในการเริ่มต้นตัวแปรภายใน
• [C-SR] ขอแนะนำอย่างยิ่งให้เปิดใช้การเริ่มต้นฮีปในเคอร์เนลเพื่อป้องกันการใช้การจัดสรรฮีปที่ไม่ได้เริ่มต้น (CONFIG_INIT_ON_ALLOC_DEFAULT_ON) และไม่ควรสมมติค่าที่เคอร์เนลใช้เพื่อเริ่มต้นการจัดสรรเหล่านั้น

หากการติดตั้งใช้งานอุปกรณ์ใช้เคอร์เนล Linux จะต้องมีคุณสมบัติดังนี้

• [C-1-1] ต้องใช้ SELinux
• [C-1-2] ต้องตั้งค่า SELinux เป็นโหมดบังคับใช้แบบส่วนกลาง
• [C-1-3] ต้องกำหนดค่าโดเมนทั้งหมดในโหมดบังคับใช้ ไม่อนุญาตโดเมนโหมดที่อนุญาต รวมถึงโดเมนที่เฉพาะเจาะจงสำหรับอุปกรณ์/ผู้ให้บริการ
• [C-1-4] ต้องไม่แก้ไข ละเว้น หรือแทนที่กฎ neverallow ที่อยู่ในโฟลเดอร์ system/sepolicy ที่ระบุไว้ในโครงการโอเพนซอร์ส Android (AOSP) ต้นทาง และนโยบายต้องคอมไพล์กับกฎ neverallow ทั้งหมดที่มีอยู่ ทั้งสำหรับโดเมน SELinux ของ AOSP และโดเมนเฉพาะของอุปกรณ์/ผู้ให้บริการ
• [C-1-5] ต้องเรียกใช้แอปพลิเคชันของบุคคลที่สามที่กำหนดเป้าหมายเป็น API ระดับ 28 ขึ้นไปในแซนด์บ็อกซ์ SELinux ต่อแอปพลิเคชัน โดยมีข้อจำกัด SELinux ต่อแอปในไดเรกทอรีข้อมูลส่วนตัวของแต่ละแอปพลิเคชัน
• ควรเก็บนโยบาย SELinux เริ่มต้นที่อยู่ในโฟลเดอร์ system/sepolicy ของ Android Open Source Project ต้นทางไว้ และเพิ่มนโยบายนี้เพิ่มเติมสำหรับการกำหนดค่าเฉพาะอุปกรณ์ของตนเองเท่านั้น

หากมีการเปิดตัวการใช้งานอุปกรณ์ใน Android เวอร์ชันก่อนหน้าแล้วและไม่สามารถปฏิบัติตามข้อกำหนด [C-1-1] และ [C-1-5] ผ่านการอัปเดตซอฟต์แวร์ระบบได้ ระบบอาจยกเว้นข้อกำหนดเหล่านี้ให้

หากการใช้งานอุปกรณ์ใช้เคอร์เนลอื่นที่ไม่ใช่ Linux จะต้องมีคุณสมบัติดังนี้

• [C-2-1] ต้องใช้ระบบควบคุมการเข้าถึงที่จำเป็นซึ่งเทียบเท่ากับ SELinux

Android มีฟีเจอร์การป้องกันหลายชั้นซึ่งเป็นส่วนสำคัญของความปลอดภัยของอุปกรณ์

9.8. ความเป็นส่วนตัว

9.8.1. ประวัติการใช้งาน

Android จะจัดเก็บประวัติตัวเลือกของผู้ใช้และจัดการประวัติดังกล่าวโดย UsageStatsManager

การติดตั้งใช้งานอุปกรณ์

• [C-0-1] ต้องเก็บประวัติผู้ใช้ดังกล่าวไว้ตามระยะเวลาการเก็บรักษาที่สมเหตุสมผล
• [SR] ขอแนะนำอย่างยิ่งให้คงระยะเวลาเก็บรักษา 14 วันตามที่กำหนดค่าไว้โดยค่าเริ่มต้นในการติดตั้งใช้งาน AOSP

Android จะจัดเก็บเหตุการณ์ของระบบโดยใช้ตัวระบุ StatsLog และจัดการประวัติดังกล่าวผ่าน StatsManager และ IncidentManager System API

การติดตั้งใช้งานอุปกรณ์

• [C-0-2] ต้องมีเฉพาะฟิลด์ที่ทำเครื่องหมายด้วย DEST_AUTOMATIC ในรายงานเหตุการณ์ที่สร้างโดยคลาส System API IncidentManager
• [C-0-3] ต้องไม่ใช้ตัวระบุเหตุการณ์ของระบบเพื่อบันทึกเหตุการณ์อื่นๆ นอกเหนือจากที่อธิบายไว้ในเอกสาร SDK ของ StatsLog หากมีการบันทึกเหตุการณ์ของระบบเพิ่มเติม เหตุการณ์เหล่านั้นอาจใช้ตัวระบุ Atom อื่นในช่วงระหว่าง 100,000 ถึง 200,000

9.8.2. กำลังบันทึก

การติดตั้งใช้งานอุปกรณ์

• [C-0-1] ต้องไม่โหลดล่วงหน้าหรือแจกจ่ายคอมโพเนนต์ซอฟต์แวร์ที่ส่งข้อมูลส่วนตัวของผู้ใช้ (เช่น การกดแป้นพิมพ์ ข้อความที่แสดงบนหน้าจอ รายงานข้อบกพร่อง) ออกจากอุปกรณ์โดยไม่ได้รับความยินยอมจากผู้ใช้หรือการแจ้งเตือนที่ชัดเจนอย่างต่อเนื่อง
• [C-0-2] ต้องแสดงและขอความยินยอมอย่างชัดแจ้งจากผู้ใช้ที่อนุญาตให้บันทึกข้อมูลที่ละเอียดอ่อน ซึ่งแสดงบนหน้าจอของผู้ใช้ได้ทุกครั้งที่เปิดใช้การแคสต์หน้าจอหรือการบันทึกหน้าจอผ่าน MediaProjection หรือ API ที่เป็นกรรมสิทธิ์ ต้องไม่ให้ผู้ใช้มีตัวเลือกในการปิดใช้การแสดงความยินยอมของผู้ใช้ในอนาคต
• [C-0-3] ต้องมีการแจ้งเตือนต่อเนื่องให้ผู้ใช้ทราบขณะเปิดใช้การแคสต์หน้าจอหรือการบันทึกหน้าจอ AOSP เป็นไปตามข้อกำหนดนี้โดยการแสดงไอคอนการแจ้งเตือนต่อเนื่องในแถบสถานะ

หากการติดตั้งใช้งานอุปกรณ์มีฟังก์ชันการทำงานในระบบที่จับภาพเนื้อหาที่แสดงบนหน้าจอและ/หรือบันทึกสตรีมเสียงที่เล่นบนอุปกรณ์นอกเหนือจากผ่าน System API ContentCaptureService หรือวิธีการที่เป็นกรรมสิทธิ์อื่นๆ ที่อธิบายไว้ในส่วนที่ 9.8.6 การจับภาพเนื้อหา จะต้องมีลักษณะดังนี้

• [C-1-1] ต้องมีการแจ้งเตือนอย่างต่อเนื่องให้ผู้ใช้ทราบทุกครั้งที่เปิดใช้ฟังก์ชันนี้และมีการจับภาพ/บันทึกอย่างต่อเนื่อง

หากการติดตั้งใช้งานอุปกรณ์มีคอมโพเนนต์ที่เปิดใช้ทันทีที่แกะกล่อง ซึ่งสามารถบันทึกเสียงรอบข้างและ/หรือบันทึกเสียงที่เล่นบนอุปกรณ์เพื่ออนุมานข้อมูลที่เป็นประโยชน์เกี่ยวกับบริบทของผู้ใช้ คอมโพเนนต์ดังกล่าวจะต้องมีลักษณะดังนี้

• [C-2-1] ต้องไม่จัดเก็บเสียงดิบที่บันทึกไว้หรือรูปแบบใดๆ ที่แปลงกลับเป็นเสียงต้นฉบับหรือเสียงที่คล้ายกันมากไว้ในที่เก็บข้อมูลแบบถาวรในอุปกรณ์หรือส่งออกจากอุปกรณ์ เว้นแต่จะได้รับความยินยอมอย่างชัดแจ้งจากผู้ใช้

9.8.3. การเชื่อมต่อ

หากการติดตั้งใช้งานอุปกรณ์มีพอร์ต USB ที่รองรับโหมดอุปกรณ์ต่อพ่วง USB จะมีลักษณะดังนี้

• [C-1-1] ต้องแสดงอินเทอร์เฟซผู้ใช้ที่ขอความยินยอมจากผู้ใช้ก่อนอนุญาตให้เข้าถึงเนื้อหาของพื้นที่เก็บข้อมูลที่แชร์ผ่านพอร์ต USB

9.8.4. การจราจรของข้อมูลในเครือข่าย

การติดตั้งใช้งานอุปกรณ์

• [C-0-1] ต้องติดตั้งใบรับรองรูทเดียวกันล่วงหน้าสำหรับที่เก็บผู้ออกใบรับรอง (CA) ที่ระบบเชื่อถือตามที่ระบุไว้ใน Android Open Source Project ต้นทาง
• [C-0-2] ต้องจัดส่งพร้อมกับที่เก็บ CA รูทของผู้ใช้ที่ว่างเปล่า
• [C-0-3] ต้องแสดงคำเตือนแก่ผู้ใช้ซึ่งระบุว่าอาจมีการตรวจสอบการรับส่งข้อมูลเครือข่าย เมื่อมีการเพิ่ม CA หลักของผู้ใช้

หากการรับส่งข้อมูลของอุปกรณ์ผ่าน VPN การติดตั้งใช้งานอุปกรณ์จะมีลักษณะดังนี้

• [C-1-1] ต้องแสดงคำเตือนแก่ผู้ใช้ซึ่งระบุอย่างใดอย่างหนึ่งต่อไปนี้
  • การจราจรของข้อมูลในเครือข่ายดังกล่าวอาจได้รับการตรวจสอบ
  • การรับส่งข้อมูลในเครือข่ายดังกล่าวจะได้รับการกำหนดเส้นทางผ่านแอปพลิเคชัน VPN ที่เฉพาะเจาะจงซึ่งให้บริการ VPN

หากการติดตั้งใช้งานอุปกรณ์มีกลไกที่เปิดใช้ทันทีโดยค่าเริ่มต้นซึ่งกำหนดเส้นทางการรับส่งข้อมูลในเครือข่ายผ่านเซิร์ฟเวอร์พร็อกซีหรือเกตเวย์ VPN (เช่น การโหลดบริการ VPN ล่วงหน้าโดยได้รับandroid.permission.CONTROL_VPN) กลไกดังกล่าวจะทำสิ่งต่อไปนี้

• [C-2-1] ต้องขอความยินยอมจากผู้ใช้ก่อนเปิดใช้กลไกดังกล่าว เว้นแต่ว่า Device Policy Controller จะเปิดใช้ VPN นั้นผ่าน DevicePolicyManager.setAlwaysOnVpnPackage() ในกรณีนี้ ผู้ใช้ไม่จำเป็นต้องให้ความยินยอมแยกต่างหาก แต่ต้องได้รับการแจ้งเตือนเท่านั้น

หากการติดตั้งใช้งานอุปกรณ์ใช้ความสามารถของผู้ใช้ในการเปิด/ปิดฟังก์ชัน "VPN แบบเปิดตลอดเวลา" ของแอป VPN ของบุคคลที่สาม การติดตั้งใช้งานดังกล่าวจะต้องมีลักษณะดังนี้

• [C-3-1] ต้องปิดใช้ความสามารถนี้สำหรับแอปที่ไม่รองรับบริการ VPN ที่เปิดตลอดเวลาในไฟล์ AndroidManifest.xml โดยตั้งค่าแอตทริบิวต์ SERVICE_META_DATA_SUPPORTS_ALWAYS_ON เป็น false

9.8.5. ตัวระบุอุปกรณ์

การติดตั้งใช้งานอุปกรณ์

• [C-0-1] ต้องป้องกันไม่ให้แอปเข้าถึงหมายเลขซีเรียลของอุปกรณ์ และในกรณีที่เกี่ยวข้อง IMEI/MEID, หมายเลขซีเรียลของซิม และ International Mobile Subscriber Identity (IMSI) เว้นแต่จะเป็นไปตามข้อกำหนดต่อไปนี้ข้อใดข้อหนึ่ง
  • เป็นแอปของผู้ให้บริการที่ลงนามแล้วซึ่งได้รับการยืนยันจากผู้ผลิตอุปกรณ์
  • ได้รับสิทธิ์ READ_PRIVILEGED_PHONE_STATE
  • มีสิทธิ์ของผู้ให้บริการตามที่กำหนดไว้ในสิทธิ์ของผู้ให้บริการ UICC
  • เป็นเจ้าของอุปกรณ์หรือเจ้าของโปรไฟล์ที่ได้รับREAD_PHONE_STATEสิทธิ์
  • (สำหรับหมายเลขซีเรียลของซิม/ICCID เท่านั้น) มีข้อกำหนดตามกฎระเบียบท้องถิ่นที่แอปต้องตรวจหาการเปลี่ยนแปลงข้อมูลระบุตัวตนของผู้สมัครใช้บริการ

9.8.6. การบันทึกเนื้อหา

Android รองรับกลไกสำหรับอุปกรณ์ที่ใช้ในการบันทึกการโต้ตอบต่อไปนี้ระหว่างแอปพลิเคชันกับผู้ใช้ผ่าน System API ContentCaptureService หรือโดยวิธีการที่เป็นกรรมสิทธิ์อื่นๆ

• ข้อความและกราฟิกที่แสดงบนหน้าจอ ซึ่งรวมถึงแต่ไม่จำกัดเพียงการแจ้งเตือนและข้อมูลความช่วยเหลือผ่าน AssistStructure API
• ข้อมูลสื่อ เช่น เสียงหรือวิดีโอที่อุปกรณ์บันทึกหรือเล่น
• เหตุการณ์การป้อนข้อมูล (เช่น คีย์ เมาส์ ท่าทางสัมผัส เสียง วิดีโอ และการช่วยเหลือพิเศษ)
• เหตุการณ์อื่นๆ ที่แอปพลิเคชันระบุให้กับระบบผ่าน Content Capture API หรือ API ที่เป็นกรรมสิทธิ์ซึ่งมีความสามารถคล้ายกัน
• ข้อความหรือข้อมูลอื่นๆ ที่ส่งผ่าน TextClassifier API ไปยัง TextClassifier ของระบบ กล่าวคือ ไปยังบริการของระบบเพื่อทำความเข้าใจความหมายของข้อความ รวมถึงสร้างการดำเนินการถัดไปที่คาดการณ์ไว้ตามข้อความ

หากการติดตั้งใช้งานอุปกรณ์บันทึกข้อมูลข้างต้น อุปกรณ์จะทำสิ่งต่อไปนี้

• [C-1-1] ต้องเข้ารหัสข้อมูลดังกล่าวทั้งหมดเมื่อจัดเก็บไว้ในอุปกรณ์ การเข้ารหัสนี้อาจดำเนินการโดยใช้การเข้ารหัสตามไฟล์ของ Android หรือการเข้ารหัสใดๆ ที่ระบุเป็น API เวอร์ชัน 26 ขึ้นไปตามที่อธิบายไว้ใน Cipher SDK
• [C-1-2] ต้องไม่สำรองข้อมูลดิบหรือข้อมูลที่เข้ารหัสโดยใช้วิธีการสำรองข้อมูล Android หรือวิธีการสำรองข้อมูลอื่นๆ
• [C-1-3] ต้องส่งข้อมูลดังกล่าวทั้งหมดและบันทึกของอุปกรณ์โดยใช้กลไกการรักษาความเป็นส่วนตัวเท่านั้น กลไกการรักษาความเป็นส่วนตัวกําหนดไว้ว่า "กลไกที่อนุญาตให้วิเคราะห์แบบรวมเท่านั้น และป้องกันการจับคู่เหตุการณ์ที่บันทึกไว้หรือผลลัพธ์ที่ได้กับผู้ใช้แต่ละราย" เพื่อป้องกันไม่ให้ข้อมูลต่อผู้ใช้แต่ละรายสามารถตรวจสอบได้ (เช่น การใช้เทคโนโลยีความเป็นส่วนตัวเชิงอนุพันธ์ เช่น RAPPOR)
• [C-1-4] ต้องไม่เชื่อมโยงข้อมูลดังกล่าวกับข้อมูลประจำตัวของผู้ใช้ (เช่น Account) ในอุปกรณ์ เว้นแต่จะได้รับความยินยอมอย่างชัดแจ้งจากผู้ใช้ทุกครั้งที่มีการเชื่อมโยงข้อมูล
• [C-1-5] ต้องไม่แชร์ข้อมูลดังกล่าวกับแอปอื่นๆ เว้นแต่จะได้รับความยินยอมของผู้ใช้ทุกครั้งที่มีการแชร์
• [C-1-6] ต้องมีตัวเลือกให้ผู้ใช้ลบข้อมูลดังกล่าวที่ ContentCaptureService หรือวิธีการที่เป็นกรรมสิทธิ์รวบรวม หากมีการจัดเก็บข้อมูลในรูปแบบใดก็ตามในอุปกรณ์

หากการติดตั้งใช้งานอุปกรณ์มีบริการที่ใช้ System API ContentCaptureService หรือบริการที่เป็นกรรมสิทธิ์ซึ่งบันทึกข้อมูลตามที่อธิบายไว้ข้างต้น บริการดังกล่าวจะต้องมีคุณสมบัติดังนี้

• [C-2-1] ต้องไม่อนุญาตให้ผู้ใช้แทนที่บริการจับภาพเนื้อหาด้วยแอปพลิเคชันหรือบริการที่ผู้ใช้ติดตั้งได้ และต้องอนุญาตให้เฉพาะบริการที่ติดตั้งไว้ล่วงหน้าจับภาพข้อมูลดังกล่าว
• [C-2-2] ต้องไม่อนุญาตให้แอปอื่นนอกเหนือจากกลไกบริการจับภาพเนื้อหาที่ติดตั้งไว้ล่วงหน้าสามารถจับภาพข้อมูลดังกล่าวได้
• [C-2-3] ต้องมีตัวเลือกให้ผู้ใช้ปิดใช้บริการจับภาพเนื้อหา
• [C-2-4] ต้องไม่ละเลยความสามารถของผู้ใช้ในการจัดการสิทธิ์ของ Android ที่บริการจับภาพเนื้อหามี และต้องปฏิบัติตามโมเดลสิทธิ์ของ Android ตามที่อธิบายไว้ในส่วนที่ 9.1 สิทธิ์

• [C-SR] ขอแนะนำอย่างยิ่งให้แยกคอมโพเนนต์บริการจับภาพเนื้อหาออกจากคอมโพเนนต์อื่นๆ ของระบบ เช่น ไม่ผูกรหัสกระบวนการบริการหรือการแชร์กับคอมโพเนนต์อื่นๆ ของระบบ ยกเว้นคอมโพเนนต์ต่อไปนี้

  • โทรศัพท์ รายชื่อติดต่อ UI ของระบบ และสื่อ

9.8.7. การเข้าถึงคลิปบอร์ด

การติดตั้งใช้งานอุปกรณ์

• [C-0-1] ต้องไม่แสดงข้อมูลที่ตัดในคลิปบอร์ด (เช่น ผ่าน ClipboardManager API) เว้นแต่แอปจะเป็น IME เริ่มต้นหรือเป็นแอปที่โฟกัสอยู่

9.8.8. ตำแหน่ง

การติดตั้งใช้งานอุปกรณ์

• [C-0-1] ต้องไม่เปิด/ปิดการตั้งค่าตำแหน่งของอุปกรณ์และการตั้งค่าการสแกน Wi-Fi/บลูทูธโดยไม่ได้รับความยินยอมอย่างชัดแจ้งจากผู้ใช้หรือผู้ใช้ไม่ได้เป็นผู้เริ่มดำเนินการ
• [C-0-2] ต้องมีเครื่องมือสำหรับผู้ใช้เพื่อเข้าถึงข้อมูลที่เกี่ยวข้องกับตำแหน่ง ซึ่งรวมถึงคำขอตำแหน่งล่าสุด สิทธิ์ระดับแอป และการใช้การสแกนหาบลูทูธ/Wi-Fi เพื่อระบุตำแหน่ง
• [C-0-3] ต้องตรวจสอบว่าแอปพลิเคชันที่ใช้ Emergency Location Bypass API [LocationRequest.setLocationSettingsIgnored()] เป็นเซสชันฉุกเฉินที่ผู้ใช้เริ่มต้น (เช่น โทรหา 911 หรือส่งข้อความถึง 911) อย่างไรก็ตาม สำหรับยานยนต์ ยานพาหนะอาจเริ่มเซสชันฉุกเฉินโดยไม่ต้องมีการโต้ตอบจากผู้ใช้ในกรณีที่ตรวจพบการชน/อุบัติเหตุ (เช่น เพื่อให้เป็นไปตามข้อกำหนดของ eCall)
• [C-0-4] ต้องคงความสามารถของ Emergency Location Bypass API ในการข้ามการตั้งค่าตำแหน่งของอุปกรณ์โดยไม่ต้องเปลี่ยนการตั้งค่า
• [C-0-5] ต้องตั้งเวลาการแจ้งเตือนที่ช่วยเตือนผู้ใช้หลังจากที่แอปในเบื้องหลังเข้าถึงตำแหน่งของผู้ใช้โดยใช้สิทธิ์ [ACCESS_BACKGROUND_LOCATION]

9.8.9. แอปที่ติดตั้ง

แอป Android ที่กำหนดเป้าหมายเป็น API ระดับ 30 ขึ้นไปจะดูรายละเอียดเกี่ยวกับแอปอื่นๆ ที่ติดตั้งไว้ไม่ได้โดยค่าเริ่มต้น (ดูระดับการเข้าถึงแพ็กเกจในเอกสารประกอบ Android SDK)

การติดตั้งใช้งานอุปกรณ์

• [C-0-1] ต้องไม่เปิดเผยรายละเอียดเกี่ยวกับแอปอื่นๆ ที่ติดตั้งไว้ต่อแอปใดๆ ที่กำหนดเป้าหมายเป็น API ระดับ 30 ขึ้นไป เว้นแต่แอปจะดูรายละเอียดเกี่ยวกับแอปอื่นๆ ที่ติดตั้งไว้ได้อยู่แล้วผ่าน API ที่มีการจัดการ ซึ่งรวมถึงแต่ไม่จำกัดเพียงรายละเอียดที่เปิดเผยโดย API ที่กำหนดเองซึ่งผู้ติดตั้งใช้งานอุปกรณ์เพิ่ม หรือเข้าถึงได้ผ่านระบบไฟล์

9.8.10. รายงานข้อบกพร่องด้านการเชื่อมต่อ

หากการติดตั้งใช้งานอุปกรณ์สร้างรายงานข้อบกพร่องโดยใช้ System API BUGREPORT_MODE_TELEPHONY กับ BugreportManager จะมีลักษณะดังนี้

• [C-1-1] ต้องได้รับความยินยอมจากผู้ใช้ทุกครั้งที่มีการเรียกใช้ System API BUGREPORT_MODE_TELEPHONY เพื่อสร้างรายงาน และต้องไม่แจ้งให้ผู้ใช้ยินยอมสำหรับคำขอในอนาคตทั้งหมดจากแอปพลิเคชัน
• [C-1-2] ต้องแสดงและขอความยินยอมอย่างชัดแจ้งจากผู้ใช้เมื่อเริ่มสร้างรายงาน และต้องไม่ส่งคืนรายงานที่สร้างขึ้นไปยังแอปที่ขอโดยไม่ได้รับความยินยอมอย่างชัดแจ้งจากผู้ใช้
• [C-1-3] ต้องสร้างรายงานที่ขอซึ่งมีข้อมูลต่อไปนี้เป็นอย่างน้อย
  • ดัมพ์ TelephonyDebugService
  • การดัมพ์ TelephonyRegistry
  • ดัมพ์ WifiService
  • ดัมพ์ ConnectivityService
  • การดัมพ์อินสแตนซ์ CarrierService ของแพ็กเกจการโทร (หากมีการเชื่อมโยง)
  • บัฟเฟอร์บันทึกวิทยุ
• [C-1-4] ต้องไม่รวมข้อมูลต่อไปนี้ในรายงานที่สร้างขึ้น
  • ข้อมูลทุกประเภทที่ไม่เกี่ยวข้องกับการแก้ไขข้อบกพร่องด้านการเชื่อมต่อ
  • บันทึกการเข้าชมแอปพลิเคชันที่ผู้ใช้ติดตั้ง หรือโปรไฟล์โดยละเอียดของแอปพลิเคชัน/แพ็กเกจที่ผู้ใช้ติดตั้ง (UID ใช้ได้ แต่ชื่อแพ็กเกจใช้ไม่ได้)
• อาจมีข้อมูลเพิ่มเติมที่ไม่ได้เชื่อมโยงกับข้อมูลระบุตัวตนของผู้ใช้ (เช่น บันทึกของผู้ให้บริการ)

หากการติดตั้งใช้งานอุปกรณ์มีข้อมูลเพิ่มเติม (เช่น บันทึกของผู้ให้บริการ) ในรายงานข้อบกพร่อง และข้อมูลดังกล่าวส่งผลต่อความเป็นส่วนตัว/ความปลอดภัย/แบตเตอรี่/พื้นที่เก็บข้อมูล/หน่วยความจำ จะต้องดำเนินการดังนี้

• [C-SR] ขอแนะนำอย่างยิ่งให้ตั้งค่าเริ่มต้นของนักพัฒนาซอฟต์แวร์เป็นปิดใช้ AOSP ตอบสนองข้อกำหนดนี้โดยมีEnable verbose vendor logging ตัวเลือกในการตั้งค่าสำหรับนักพัฒนาแอปเพื่อรวมบันทึกเวนเดอร์เพิ่มเติมเฉพาะอุปกรณ์ไว้ในรายงานข้อบกพร่อง

9.8.11. การแชร์ Blob ข้อมูล

Android อนุญาตให้แอปมีส่วนร่วมในการส่ง Blob ข้อมูลไปยังระบบเพื่อแชร์กับชุดแอปที่เลือกผ่าน BlobStoreManager

หากการติดตั้งใช้งานอุปกรณ์รองรับ Blob ข้อมูลที่แชร์ตามที่อธิบายไว้ในเอกสารประกอบ SDK อุปกรณ์จะดำเนินการต่อไปนี้

• [C-1-1] ต้องไม่แชร์ Blob ข้อมูลที่เป็นของแอปเกินกว่าที่ตั้งใจจะอนุญาต (กล่าวคือ ขอบเขตของการเข้าถึงเริ่มต้นและโหมดการเข้าถึงอื่นๆ ที่ระบุได้โดยใช้ BlobStoreManager.session#allowPackageAccess(), BlobStoreManager.session#allowSameSignatureAccess() หรือ BlobStoreManager.session#allowPublicAccess() ต้องไม่ได้รับการแก้ไข) การติดตั้งใช้งานอ้างอิงของ AOSP เป็นไปตามข้อกำหนดเหล่านี้
• [C-1-2] ต้องไม่ส่งออกจากอุปกรณ์หรือแชร์กับแอปอื่นๆ ซึ่งแฮชที่ปลอดภัยของ Blob ข้อมูล (ซึ่งใช้เพื่อควบคุมการเข้าถึง)

9.9. การเข้ารหัสพื้นที่เก็บข้อมูล

อุปกรณ์ทั้งหมดต้องเป็นไปตามข้อกำหนดของส่วน 9.9.1 อุปกรณ์ที่เปิดตัวในระดับ API ก่อนหน้านี้ในเอกสารนี้จะได้รับการยกเว้นจากข้อกำหนดในส่วนที่ 9.9.2 และ 9.9.3 แต่จะต้องเป็นไปตามข้อกำหนดในส่วนที่ 9.9 ของเอกสารประกอบเกี่ยวกับข้อกำหนดความเข้ากันได้ของ Android ที่สอดคล้องกับระดับ API ที่อุปกรณ์เปิดตัว

9.9.1. Direct Boot

การติดตั้งใช้งานอุปกรณ์

• [C-0-1] ต้องใช้ API Direct Boot mode แม้ว่าจะไม่รองรับการเข้ารหัสพื้นที่เก็บข้อมูลก็ตาม

• [C-0-2] ต้องยังคงออกอากาศ Intent ACTION_LOCKED_BOOT_COMPLETED และ ACTION_USER_UNLOCKED เพื่อส่งสัญญาณไปยังแอปพลิเคชันที่รับรู้การบูตโดยตรงว่าตำแหน่งที่เก็บข้อมูลที่เข้ารหัสอุปกรณ์ (DE) และที่เก็บข้อมูลที่เข้ารหัสข้อมูลเข้าสู่ระบบ (CE) พร้อมใช้งานสำหรับผู้ใช้

9.9.2. ข้อกำหนดด้านการเข้ารหัส

การติดตั้งใช้งานอุปกรณ์

• [C-0-1] ต้องเข้ารหัสข้อมูลส่วนตัวของแอปพลิเคชัน (พาร์ติชัน /data) รวมถึงพาร์ติชันพื้นที่เก็บข้อมูลที่แชร์ของแอปพลิเคชัน (พาร์ติชัน /sdcard) หากเป็นส่วนถาวรที่ถอดออกไม่ได้ของอุปกรณ์
• [C-0-2] ต้องเปิดใช้การเข้ารหัสพื้นที่เก็บข้อมูลโดยค่าเริ่มต้นเมื่อผู้ใช้ตั้งค่าประสบการณ์การใช้งานครั้งแรกเสร็จสมบูรณ์

• [C-0-3] ต้องเป็นไปตามข้อกำหนดการเข้ารหัสพื้นที่เก็บข้อมูลข้างต้นโดยใช้วิธีการเข้ารหัส 2 วิธีต่อไปนี้

  • การเข้ารหัสตามไฟล์ (FBE) และการเข้ารหัสข้อมูลเมตาตามที่อธิบายไว้ในส่วน 9.9.3.1
  • การเข้ารหัสระดับบล็อกต่อผู้ใช้ตามที่อธิบายไว้ในส่วน 9.9.3.2

9.9.3. วิธีการเข้ารหัส

หากการติดตั้งใช้งานอุปกรณ์มีการเข้ารหัส จะมีลักษณะดังนี้

• [C-1-1] ต้องเปิดเครื่องโดยไม่ต้องขอข้อมูลเข้าสู่ระบบจากผู้ใช้ และอนุญาตให้แอปที่รับรู้การเปิดเครื่องโดยตรงเข้าถึงพื้นที่เก็บข้อมูลที่เข้ารหัสอุปกรณ์ (DE) หลังจากที่ออกอากาศข้อความ ACTION_LOCKED_BOOT_COMPLETED
• [C-1-2] ต้องอนุญาตให้เข้าถึงที่เก็บข้อมูลที่เข้ารหัสด้วยข้อมูลเข้าสู่ระบบ (CE) หลังจากที่ผู้ใช้ปลดล็อกอุปกรณ์โดยระบุข้อมูลเข้าสู่ระบบ (เช่น รหัสผ่าน, PIN, รูปแบบ หรือลายนิ้วมือ) และมีการออกอากาศข้อความ ACTION_USER_UNLOCKED เท่านั้น
• [C-1-13] ต้องไม่เสนอวิธีการใดๆ ในการปลดล็อกที่เก็บข้อมูลที่ได้รับการปกป้องด้วย CE โดยไม่มีข้อมูลเข้าสู่ระบบที่ผู้ใช้ระบุ คีย์การฝากที่ลงทะเบียน หรือการดำเนินการต่อเมื่อรีบูตที่ตรงตามข้อกำหนดในส่วน 9.9.4
• [C-1-4] ต้องใช้การเปิดเครื่องที่ได้รับการยืนยัน

9.9.3.1. การเข้ารหัสตามไฟล์ที่มีการเข้ารหัสข้อมูลเมตา

หากการติดตั้งใช้งานอุปกรณ์ใช้การเข้ารหัสตามไฟล์ที่มีการเข้ารหัสข้อมูลเมตา อุปกรณ์จะต้องมีคุณสมบัติดังนี้

• [C-1-5] ต้องเข้ารหัสเนื้อหาไฟล์และข้อมูลเมตาของระบบไฟล์โดยใช้ AES-256-XTS หรือ Adiantum AES-256-XTS หมายถึงมาตรฐานการเข้ารหัสขั้นสูงที่มีความยาวของคีย์การเข้ารหัส 256 บิต ซึ่งทำงานในโหมด XTS โดยมีความยาวของคีย์ทั้งหมด 512 บิต Adiantum หมายถึง Adiantum-XChaCha12-AES ตามที่ระบุไว้ที่ https://github.com/google/adiantum ข้อมูลเมตาของระบบไฟล์คือข้อมูล เช่น ขนาดไฟล์ การเป็นเจ้าของ โหมด และแอตทริบิวต์เพิ่มเติม (xattrs)
• [C-1-6] ต้องเข้ารหัสชื่อไฟล์โดยใช้ AES-256-CBC-CTS หรือ Adiantum
• [C-1-12] หากอุปกรณ์มีคำสั่งมาตรฐานการเข้ารหัสขั้นสูง (AES) (เช่น ส่วนขยายการเข้ารหัส ARMv8 ในอุปกรณ์ที่ใช้ ARM หรือ AES-NI ในอุปกรณ์ที่ใช้ x86) จะต้องใช้ตัวเลือกที่ใช้ AES ด้านบนสำหรับการเข้ารหัสชื่อไฟล์ เนื้อหาไฟล์ และข้อมูลเมตาของระบบไฟล์ ไม่ใช่ Adiantum
• [C-1-13] ต้องใช้ฟังก์ชันการได้คีย์ (KDF) ที่รัดกุมและย้อนกลับไม่ได้ (เช่น HKDF-SHA512) เพื่อได้คีย์ย่อยที่จำเป็น (เช่น คีย์ต่อไฟล์) จากคีย์ CE และ DE "เข้ารหัสอย่างแน่นหนาและย้อนกลับไม่ได้" หมายความว่าฟังก์ชันการได้คีย์มีความแข็งแกร่งด้านความปลอดภัยอย่างน้อย 256 บิต และทํางานเป็นตระกูลฟังก์ชันแบบสุ่มเทียมในอินพุต

• [C-1-14] ต้องไม่ใช้คีย์หรือคีย์ย่อยของการเข้ารหัสที่อิงตามไฟล์ (FBE) เดียวกันเพื่อวัตถุประสงค์ในการเข้ารหัสที่แตกต่างกัน (เช่น ทั้งสำหรับการเข้ารหัสและการสร้างคีย์ หรือสำหรับอัลกอริทึมการเข้ารหัส 2 แบบที่แตกต่างกัน)

• คีย์ที่ปกป้องพื้นที่เก็บข้อมูล CE และ DE รวมถึงข้อมูลเมตาของระบบไฟล์

• [C-1-7] ต้องผูกกับการเข้ารหัสกับที่เก็บคีย์ที่อิงฮาร์ดแวร์ Keystore นี้ต้องเชื่อมโยงกับการเปิดเครื่องที่ได้รับการยืนยันและฮาร์ดแวร์รูทของความน่าเชื่อถือของอุปกรณ์

• [C-1-8] คีย์ CE ต้องผูกไว้กับข้อมูลเข้าสู่ระบบของหน้าจอล็อกของผู้ใช้
• [C-1-9] ต้องเชื่อมโยงคีย์ CE กับรหัสผ่านเริ่มต้นเมื่อผู้ใช้ไม่ได้ระบุข้อมูลเข้าสู่ระบบของหน้าจอล็อก
• [C-1-10] ต้องไม่ซ้ำกันและแตกต่างกัน กล่าวคือ คีย์ CE หรือ DE ของผู้ใช้รายใดรายหนึ่งต้องไม่ตรงกับคีย์ CE หรือ DE ของผู้ใช้รายอื่น

• [C-1-11] ต้องใช้การเข้ารหัส ความยาวคีย์ และโหมดที่รองรับตามข้อกำหนด

• ควรทำให้แอปที่จำเป็นซึ่งติดตั้งไว้ล่วงหน้า (เช่น นาฬิกาปลุก โทรศัพท์ Messenger) รู้จักการบูตโดยตรง

โปรเจ็กต์ Android Open Source ต้นทางมีการติดตั้งใช้งานที่ต้องการสำหรับการเข้ารหัสตามไฟล์โดยอิงตามฟีเจอร์การเข้ารหัส "fscrypt" ของเคอร์เนล Linux และการเข้ารหัสข้อมูลเมตาโดยอิงตามฟีเจอร์ "dm-default-key" ของเคอร์เนล Linux

9.9.3.2. การเข้ารหัสระดับบล็อกต่อผู้ใช้

หากการใช้งานอุปกรณ์ใช้การเข้ารหัสระดับบล็อกต่อผู้ใช้ อุปกรณ์จะทำสิ่งต่อไปนี้

• [C-1-1] ต้องเปิดใช้การรองรับผู้ใช้หลายคนหนึ่งเครื่องตามที่อธิบายไว้ในส่วน 9.5
• [C-1-2] ต้องจัดเตรียมพาร์ติชันต่อผู้ใช้ โดยใช้พาร์ติชันดิบหรือวอลุ่มเชิงตรรกะ
• [C-1-3] ต้องใช้คีย์การเข้ารหัสที่ไม่ซ้ำและแตกต่างกันต่อผู้ใช้สำหรับการเข้ารหัสอุปกรณ์บล็อกพื้นฐาน

• [C-1-4] ต้องใช้ AES-256-XTS สำหรับการเข้ารหัสระดับบล็อกของพาร์ติชันผู้ใช้

• คีย์ที่ปกป้องอุปกรณ์ที่เข้ารหัสระดับบล็อกต่อผู้ใช้

• [C-1-5] ต้องผูกกับที่เก็บคีย์ที่อิงฮาร์ดแวร์ด้วยการเข้ารหัส Keystore นี้ต้องเชื่อมโยงกับการเปิดเครื่องที่ได้รับการยืนยันและฮาร์ดแวร์รูทของความน่าเชื่อถือของอุปกรณ์

• [C-1-6] ต้องผูกไว้กับข้อมูลเข้าสู่ระบบของหน้าจอล็อกของผู้ใช้ที่เกี่ยวข้อง

การเข้ารหัสระดับบล็อกต่อผู้ใช้สามารถใช้ได้โดยใช้ฟีเจอร์ "dm-crypt" ของเคอร์เนล Linux ผ่านพาร์ติชันต่อผู้ใช้

9.9.4. เปิดต่อเมื่อรีบูต

การกลับมาทำงานต่อเมื่อรีบูตช่วยให้ปลดล็อกที่เก็บข้อมูล CE ของแอปทั้งหมดได้ ซึ่งรวมถึงแอปที่ยังไม่รองรับการบูตโดยตรงหลังจากรีบูตที่เริ่มต้นโดย OTA ฟีเจอร์นี้ช่วยให้ผู้ใช้ได้รับการแจ้งเตือนจากแอปที่ติดตั้งไว้หลังจากรีบูต

การใช้งานฟีเจอร์กลับมาทำงานต่อเมื่อรีบูตต้องดำเนินการต่อไปเพื่อให้มั่นใจว่าเมื่ออุปกรณ์ตกอยู่ในมือของผู้โจมตี ผู้โจมตีจะกู้คืนข้อมูลที่เข้ารหัส CE ของผู้ใช้ได้ยากมาก แม้ว่าอุปกรณ์จะเปิดอยู่ ที่เก็บข้อมูล CE จะปลดล็อก และผู้ใช้ได้ปลดล็อกอุปกรณ์หลังจากได้รับ OTA แล้วก็ตาม นอกจากนี้ เรายังถือว่าผู้โจมตีได้รับสิทธิ์เข้าถึงคีย์การลงนามแบบเข้ารหัสสำหรับการออกอากาศเพื่อป้องกันการโจมตีจากคนใน

ดังนี้

• [C-0-1] ที่เก็บข้อมูล CE ต้องอ่านไม่ได้แม้แต่ผู้โจมตีที่มีอุปกรณ์อยู่กับตัวและมีความสามารถและข้อจำกัดต่อไปนี้

  • ใช้คีย์การลงนามของผู้ให้บริการหรือบริษัทใดก็ได้เพื่อลงนามข้อความที่กำหนดเอง
  • อาจทำให้อุปกรณ์ได้รับการอัปเดต OTA
  • สามารถแก้ไขการทำงานของฮาร์ดแวร์ (AP, แฟลช ฯลฯ) ได้ ยกเว้นตามที่ระบุไว้ด้านล่าง แต่การแก้ไขดังกล่าวจะทำให้เกิดความล่าช้าอย่างน้อย 1 ชั่วโมงและต้องปิดเปิดเครื่องใหม่ซึ่งจะล้างเนื้อหาใน RAM
  • แก้ไขการทำงานของฮาร์ดแวร์ที่ป้องกันการดัดแปลง (เช่น Titan M) ไม่ได้
  • อ่าน RAM ของอุปกรณ์ที่ใช้งานจริงไม่ได้
  • ไม่สามารถขอข้อมูลเข้าสู่ระบบของผู้ใช้ (PIN, รูปแบบ, รหัสผ่าน) หรือทำให้มีการป้อนข้อมูลดังกล่าว

ตัวอย่างเช่น การใช้งานอุปกรณ์ที่ใช้และเป็นไปตามคำอธิบายทั้งหมดที่ระบุที่นี่จะเป็นไปตาม [C-0-1]

9.10. ความสมบูรณ์ของอุปกรณ์

ข้อกำหนดต่อไปนี้ช่วยให้มั่นใจได้ถึงความโปร่งใสเกี่ยวกับสถานะความสมบูรณ์ของอุปกรณ์ การติดตั้งใช้งานอุปกรณ์

• [C-0-1] ต้องรายงานอย่างถูกต้องผ่านเมธอด System API PersistentDataBlockManager.getFlashLockState() ว่าสถานะ Bootloader อนุญาตให้แฟลชอิมเมจระบบหรือไม่ สถานะ FLASH_LOCK_UNKNOWN สงวนไว้สำหรับการติดตั้งใช้งานอุปกรณ์ที่อัปเกรดจาก Android เวอร์ชันก่อนหน้าซึ่งไม่มีเมธอด API ของระบบใหม่นี้

• [C-0-2] ต้องรองรับการเปิดเครื่องที่ได้รับการยืนยันเพื่อความสมบูรณ์ของอุปกรณ์

หากมีการเปิดตัวการใช้งานอุปกรณ์โดยไม่รองรับการเปิดเครื่องที่ได้รับการยืนยันใน Android เวอร์ชันก่อนหน้า และไม่สามารถเพิ่มการรองรับฟีเจอร์นี้ด้วยการอัปเดตซอฟต์แวร์ระบบ อุปกรณ์ดังกล่าวอาจได้รับการยกเว้นจากข้อกำหนด

การเปิดเครื่องที่ได้รับการยืนยันเป็นฟีเจอร์ที่รับประกันความสมบูรณ์ของซอฟต์แวร์ในอุปกรณ์ หากการติดตั้งใช้งานอุปกรณ์รองรับฟีเจอร์นี้ อุปกรณ์จะทำสิ่งต่อไปนี้

• [C-1-1] ต้องประกาศฟีเจอร์ Flag ของแพลตฟอร์ม android.software.verified_boot
• [C-1-2] ต้องทำการยืนยันในทุกๆ ลำดับการบูต
• [C-1-3] ต้องเริ่มการยืนยันจากคีย์ฮาร์ดแวร์ที่เปลี่ยนแปลงไม่ได้ซึ่งเป็นรูทของความน่าเชื่อถือ และดำเนินการไปจนถึงพาร์ติชันของระบบ
• [C-1-4] ต้องใช้การยืนยันแต่ละขั้นตอนเพื่อตรวจสอบความสมบูรณ์และความถูกต้องของไบต์ทั้งหมดในขั้นตอนถัดไปก่อนที่จะเรียกใช้โค้ดในขั้นตอนถัดไป
• [C-1-5] ต้องใช้อัลกอริทึมการยืนยันที่แข็งแกร่งเท่ากับคำแนะนำปัจจุบันจาก NIST สำหรับอัลกอริทึมการแฮช (SHA-256) และขนาดคีย์สาธารณะ (RSA-2048)
• [C-1-6] ต้องไม่อนุญาตให้บูตจนเสร็จเมื่อการยืนยันระบบล้มเหลว เว้นแต่ผู้ใช้จะยินยอมให้ลองบูตต่อไป ในกรณีนี้ต้องไม่ใช้ข้อมูลจากบล็อกพื้นที่เก็บข้อมูลที่ไม่ได้ยืนยัน
• [C-1-7] ต้องไม่อนุญาตให้แก้ไขพาร์ติชันที่ได้รับการยืนยันในอุปกรณ์ เว้นแต่ผู้ใช้จะปลดล็อก Bootloader อย่างชัดเจน
• [C-SR] หากมีชิปแยกกันหลายตัวในอุปกรณ์ (เช่น วิทยุ หน่วยประมวลผลภาพเฉพาะ) ขอแนะนำอย่างยิ่งให้กระบวนการบูตของชิปแต่ละตัวตรวจสอบทุกขั้นตอนเมื่อบูต
• [C-1-8] ต้องใช้พื้นที่เก็บข้อมูลที่ป้องกันการดัดแปลง: สำหรับจัดเก็บว่ามีการปลดล็อก Bootloader หรือไม่ พื้นที่เก็บข้อมูลที่ป้องกันการดัดแปลงหมายความว่า Bootloader สามารถตรวจหาได้ว่ามีการดัดแปลงพื้นที่เก็บข้อมูลจากภายใน Android หรือไม่
• [C-1-9] ต้องแจ้งให้ผู้ใช้ทราบขณะใช้อุปกรณ์ และต้องมีการยืนยันทางกายภาพก่อนที่จะอนุญาตให้เปลี่ยนจากโหมด Bootloader ที่ล็อกเป็นโหมด Bootloader ที่ปลดล็อก
• [C-1-10] ต้องใช้การป้องกันการย้อนกลับสำหรับพาร์ติชันที่ Android ใช้ (เช่น พาร์ติชันการบูต พาร์ติชันระบบ) และใช้พื้นที่เก็บข้อมูลที่ตรวจพบการดัดแปลงได้เพื่อจัดเก็บข้อมูลเมตาที่ใช้ในการกำหนดเวอร์ชัน OS ขั้นต่ำที่อนุญาต
• [C-SR] ขอแนะนำอย่างยิ่งให้ยืนยันไฟล์ APK ของแอปที่มีสิทธิ์ทั้งหมดด้วยห่วงโซ่ความน่าเชื่อถือที่ฝังอยู่ในพาร์ติชันที่ได้รับการปกป้องโดยการบูตที่ยืนยันแล้ว
• [C-SR] ขอแนะนำอย่างยิ่งให้ตรวจสอบอาร์ติแฟกต์ที่เรียกใช้งานได้ซึ่งแอปที่มีสิทธิ์พิเศษโหลดจากภายนอกไฟล์ APK (เช่น โค้ดที่โหลดแบบไดนามิกหรือโค้ดที่คอมไพล์แล้ว) ก่อนที่จะเรียกใช้งาน หรือขอแนะนำอย่างยิ่งไม่ให้เรียกใช้งานเลย
• ควรใช้การป้องกันการย้อนกลับสำหรับคอมโพเนนต์ที่มีเฟิร์มแวร์แบบถาวร (เช่น โมเด็ม กล้อง) และควรใช้ที่เก็บข้อมูลที่ป้องกันการดัดแปลงเพื่อจัดเก็บข้อมูลเมตาที่ใช้ในการกำหนดเวอร์ชันขั้นต่ำที่อนุญาต

หากมีการเปิดตัวการติดตั้งใช้งานอุปกรณ์โดยไม่รองรับ C-1-8 ถึง C-1-10 ใน Android เวอร์ชันก่อนหน้า และเพิ่มการรองรับข้อกำหนดเหล่านี้ด้วยการอัปเดตซอฟต์แวร์ระบบไม่ได้ อุปกรณ์ดังกล่าวอาจได้รับการยกเว้นจากข้อกำหนด

โครงการโอเพนซอร์ส Android ต้นทางมีการติดตั้งใช้งานฟีเจอร์นี้ที่แนะนำในที่เก็บ external/avb/ ซึ่งสามารถผสานรวมเข้ากับ Bootloader ที่ใช้ในการโหลด Android ได้

การติดตั้งใช้งานอุปกรณ์

• [C-0-3] ต้องรองรับการยืนยันเนื้อหาของไฟล์โดยใช้การเข้ารหัสเทียบกับคีย์ที่เชื่อถือได้โดยไม่ต้องอ่านทั้งไฟล์
• [C-0-4] ต้องไม่อนุญาตให้คำขออ่านในไฟล์ที่ได้รับการปกป้องสำเร็จเมื่อเนื้อหาที่อ่านไม่ได้รับการยืนยันเทียบกับคีย์ที่เชื่อถือได้

หากมีการเปิดตัวการใช้งานอุปกรณ์โดยที่ไม่มีความสามารถในการยืนยันเนื้อหาไฟล์กับคีย์ที่เชื่อถือได้ใน Android เวอร์ชันก่อนหน้า และไม่สามารถเพิ่มการรองรับฟีเจอร์นี้ด้วยการอัปเดตซอฟต์แวร์ระบบ อุปกรณ์ดังกล่าวอาจได้รับการยกเว้นจากข้อกำหนด โปรเจ็กต์โอเพนซอร์ส Android ต้นทางมีการติดตั้งใช้งานฟีเจอร์นี้ที่แนะนำโดยอิงตามฟีเจอร์ fs-verity ของเคอร์เนล Linux

การติดตั้งใช้งานอุปกรณ์

• [C-R] ขอแนะนำให้รองรับ Android Protected Confirmation API

หากการติดตั้งใช้งานอุปกรณ์รองรับ Android Protected Confirmation API จะมีลักษณะดังนี้

• [C-3-1] ต้องรายงาน true สำหรับ ConfirmationPrompt.isSupported() API

• [C-3-2] ต้องตรวจสอบว่าโค้ดที่ทำงานในระบบปฏิบัติการ Android รวมถึงเคอร์เนล ไม่ว่าจะเป็นโค้ดที่เป็นอันตรายหรือไม่ก็ตาม จะไม่สามารถสร้างการตอบกลับเชิงบวกได้โดยไม่ต้องมีการโต้ตอบจากผู้ใช้

• [C-3-3] ต้องตรวจสอบว่าผู้ใช้สามารถตรวจสอบและอนุมัติข้อความที่แจ้งได้ แม้ในกรณีที่ระบบปฏิบัติการ Android รวมถึงเคอร์เนลถูกบุกรุก

9.11. คีย์และข้อมูลเข้าสู่ระบบ

ระบบ Android Keystore ช่วยให้นักพัฒนาแอปจัดเก็บคีย์การเข้ารหัสในคอนเทนเนอร์และใช้คีย์เหล่านั้นในการดำเนินการเข้ารหัสผ่าน KeyChain API หรือ Keystore API ได้ การติดตั้งใช้งานอุปกรณ์

• [C-0-1] ต้องอนุญาตให้นำเข้าหรือสร้างคีย์อย่างน้อย 8,192 รายการ
• [C-0-2] การตรวจสอบสิทธิ์หน้าจอล็อกต้องจำกัดอัตราการพยายามและต้องมีอัลกอริทึมการถอยแบบทวีคูณ หากพยายามไม่สำเร็จเกิน 150 ครั้ง การหน่วงเวลาต้องเป็นอย่างน้อย 24 ชั่วโมงต่อครั้ง
• ไม่ควรจำกัดจำนวนคีย์ที่สร้างได้

เมื่อการติดตั้งใช้งานอุปกรณ์รองรับหน้าจอล็อกที่ปลอดภัย ระบบจะดำเนินการต่อไปนี้

• [C-1-1] ต้องสำรองข้อมูลการใช้งาน Keystore ด้วยสภาพแวดล้อมการดำเนินการที่แยกต่างหาก
• [C-1-2] ต้องมีการติดตั้งใช้งานอัลกอริทึมการเข้ารหัส RSA, AES, ECDSA และ HMAC รวมถึงฟังก์ชันแฮช MD5, SHA1 และ SHA-2 เพื่อรองรับอัลกอริทึมที่ระบบ Android Keystore รองรับอย่างเหมาะสมในพื้นที่ที่แยกออกจากโค้ดที่ทำงานในเคอร์เนลและเหนือกว่านั้นอย่างปลอดภัย การแยกอย่างปลอดภัยต้องบล็อกกลไกที่เป็นไปได้ทั้งหมดซึ่งโค้ดเคอร์เนลหรือโค้ดในพื้นที่ผู้ใช้อาจใช้เพื่อเข้าถึงสถานะภายในของสภาพแวดล้อมที่แยก รวมถึง DMA โครงการโอเพนซอร์ส Android (AOSP) ต้นทางเป็นไปตามข้อกำหนดนี้โดยใช้การติดตั้งใช้งาน Trusty แต่โซลูชันอื่นที่ใช้ ARM TrustZone หรือการติดตั้งใช้งานที่ปลอดภัยซึ่งได้รับการตรวจสอบจากบุคคลที่สามของการแยกตามไฮเปอร์ไวเซอร์ที่เหมาะสมก็เป็นตัวเลือกอื่นเช่นกัน
• [C-1-3] ต้องทำการตรวจสอบสิทธิ์หน้าจอล็อกในสภาพแวดล้อมการดำเนินการที่แยกจากกัน และอนุญาตให้ใช้คีย์ที่เชื่อมโยงกับการตรวจสอบสิทธิ์ได้เมื่อดำเนินการสำเร็จเท่านั้น ต้องจัดเก็บข้อมูลเข้าสู่ระบบของหน้าจอล็อกในลักษณะที่อนุญาตให้เฉพาะสภาพแวดล้อมการดำเนินการที่แยกจากกันทำการตรวจสอบสิทธิ์ของหน้าจอล็อกได้ โปรเจ็กต์โอเพนซอร์สของ Android ต้นทางมีเลเยอร์การแยกฮาร์ดแวร์ (HAL) ของ Gatekeeper และ Trusty ซึ่งใช้เพื่อตอบสนองข้อกำหนดนี้ได้
• [C-1-4] ต้องรองรับเอกสารรับรองคีย์ในกรณีที่คีย์การลงนามเอกสารรับรองได้รับการปกป้องโดยฮาร์ดแวร์ที่ปลอดภัย และการลงนามดำเนินการในฮาร์ดแวร์ที่ปลอดภัย ต้องแชร์คีย์การลงนามการรับรองในอุปกรณ์จำนวนมากพอเพื่อป้องกันไม่ให้มีการใช้คีย์เป็นตัวระบุอุปกรณ์ วิธีหนึ่งในการปฏิบัติตามข้อกำหนดนี้คือการแชร์คีย์การรับรองเดียวกัน เว้นแต่จะมีการผลิต SKU ที่กำหนดอย่างน้อย 100,000 หน่วย หากผลิต SKU มากกว่า 100,000 หน่วย คุณอาจใช้คีย์ที่แตกต่างกันสำหรับทุกๆ 100,000 หน่วย

โปรดทราบว่าหากมีการเปิดตัวการใช้งานอุปกรณ์ใน Android เวอร์ชันก่อนหน้าแล้ว อุปกรณ์ดังกล่าวจะได้รับการยกเว้นจากข้อกำหนดในการมีที่เก็บคีย์ที่ได้รับการสนับสนุนโดยสภาพแวดล้อมการดำเนินการที่แยกจากกันและรองรับการรับรองคีย์ เว้นแต่จะประกาศฟีเจอร์ android.hardware.fingerprint ซึ่งต้องมีที่เก็บคีย์ที่ได้รับการสนับสนุนโดยสภาพแวดล้อมการดำเนินการที่แยกจากกัน

• [C-1-5] ต้องอนุญาตให้ผู้ใช้เลือกการหมดเวลาสลีปสำหรับการเปลี่ยนจากสถานะปลดล็อกเป็นสถานะล็อก โดยมีการหมดเวลาขั้นต่ำที่อนุญาตได้ไม่เกิน 15 วินาที อุปกรณ์ยานยนต์ที่ล็อกหน้าจอทุกครั้งที่ปิดเฮดยูนิตหรือเปลี่ยนผู้ใช้อาจไม่มีการกำหนดค่าการหมดเวลาสลีป

9.11.1. การล็อกที่ปลอดภัยและการตรวจสอบสิทธิ์

การใช้งาน AOSP เป็นไปตามรูปแบบการตรวจสอบสิทธิ์แบบแบ่งระดับ ซึ่งการตรวจสอบสิทธิ์หลักที่อิงตามปัจจัยด้านความรู้สามารถรองรับได้ทั้งด้วยไบโอเมตริกที่รัดกุมรองลงมา หรือด้วยรูปแบบการตรวจสอบสิทธิ์ระดับที่สามที่รัดกุมน้อยกว่า

การติดตั้งใช้งานอุปกรณ์

• [C-SR] ขอแนะนำอย่างยิ่งให้ตั้งค่าวิธีใดวิธีหนึ่งต่อไปนี้เป็นวิธีการตรวจสอบสิทธิ์หลักเท่านั้น
  • PIN ที่เป็นตัวเลข
  • รหัสผ่านที่เป็นตัวอักษรและตัวเลขคละกัน
  • รูปแบบการปัดบนตารางกริดที่มีจุด 3x3 พอดี

โปรดทราบว่าวิธีการตรวจสอบสิทธิ์ข้างต้นถือเป็นวิธีการตรวจสอบสิทธิ์หลักที่แนะนำในเอกสารนี้

หากการใช้งานอุปกรณ์เพิ่มหรือแก้ไขวิธีการตรวจสอบสิทธิ์หลักที่แนะนำ และใช้วิธีการตรวจสอบสิทธิ์ใหม่เป็นวิธีที่ปลอดภัยในการล็อกหน้าจอ วิธีการตรวจสอบสิทธิ์ใหม่จะมีลักษณะดังนี้

• [C-2-1] ต้องเป็นวิธีการตรวจสอบสิทธิ์ผู้ใช้ตามที่อธิบายไว้ในการกำหนดให้มีการตรวจสอบสิทธิ์ผู้ใช้สำหรับการใช้คีย์

หากการใช้งานอุปกรณ์เพิ่มหรือแก้ไขวิธีการตรวจสอบสิทธิ์เพื่อปลดล็อกหน้าจอล็อกโดยอิงตามข้อมูลลับที่ทราบ และใช้วิธีการตรวจสอบสิทธิ์ใหม่เพื่อถือเป็นวิธีที่ปลอดภัยในการล็อกหน้าจอ ให้ทำดังนี้

• [C-3-1] เอนโทรปีของความยาวอินพุตที่สั้นที่สุดที่อนุญาตต้องมากกว่า 10 บิต
• [C-3-2] เอนโทรปีสูงสุดของอินพุตที่เป็นไปได้ทั้งหมดต้องมากกว่า 18 บิต
• [C-3-3] วิธีการตรวจสอบสิทธิ์ใหม่ต้องไม่แทนที่วิธีการตรวจสอบสิทธิ์หลักที่แนะนำ (เช่น PIN, รูปแบบ, รหัสผ่าน) ที่ใช้งานและระบุไว้ใน AOSP
• [C-3-4] ต้องปิดใช้การตรวจสอบสิทธิ์แบบใหม่เมื่อแอปพลิเคชัน Device Policy Controller (DPC) ได้ตั้งค่านโยบายคุณภาพรหัสผ่านผ่านเมธอด DevicePolicyManager.setPasswordQuality() ที่มีค่าคงที่คุณภาพที่เข้มงวดกว่า PASSWORD_QUALITY_SOMETHING
• [C-3-5] วิธีการตรวจสอบสิทธิ์ใหม่ต้องเปลี่ยนกลับไปใช้วิธีการตรวจสอบสิทธิ์หลักที่แนะนำ (เช่น PIN, รูปแบบ, รหัสผ่าน) ทุกๆ 72 ชั่วโมงหรือน้อยกว่านั้น หรือเปิดเผยต่อผู้ใช้อย่างชัดเจนว่าระบบจะไม่สำรองข้อมูลบางอย่างเพื่อรักษาความเป็นส่วนตัวของข้อมูล

หากการใช้งานอุปกรณ์เพิ่มหรือแก้ไขวิธีการตรวจสอบสิทธิ์หลักที่แนะนำเพื่อปลดล็อกหน้าจอล็อก และใช้วิธีการตรวจสอบสิทธิ์ใหม่ที่อิงตามข้อมูลไบโอเมตริกเพื่อให้ถือเป็นวิธีที่ปลอดภัยในการล็อกหน้าจอ วิธีการใหม่นี้จะมีลักษณะดังนี้

• [C-4-1] ต้องเป็นไปตามข้อกำหนดทั้งหมดที่อธิบายไว้ในส่วน 7.3.10 สำหรับคลาส 1 (เดิมคือความสะดวก)
• [C-4-2] ต้องมีกลไกสำรองเพื่อใช้วิธีการตรวจสอบสิทธิ์หลักที่แนะนำวิธีใดวิธีหนึ่งซึ่งอิงตามข้อมูลลับที่ทราบ
• [C-4-3] ต้องปิดใช้และอนุญาตให้ใช้การตรวจสอบสิทธิ์หลักที่แนะนำเท่านั้นเพื่อปลดล็อกหน้าจอเมื่อแอปพลิเคชัน Device Policy Controller (DPC) ได้ตั้งค่านโยบายฟีเจอร์ Keyguard โดยการเรียกใช้เมธอด DevicePolicyManager.setKeyguardDisabledFeatures() พร้อมด้วยค่าสถานะไบโอเมตริกที่เชื่อมโยง (เช่น KEYGUARD_DISABLE_BIOMETRICS, KEYGUARD_DISABLE_FINGERPRINT, KEYGUARD_DISABLE_FACE หรือ KEYGUARD_DISABLE_IRIS)

หากวิธีการตรวจสอบสิทธิ์ด้วยข้อมูลไบโอเมตริกไม่เป็นไปตามข้อกำหนดสำหรับคลาส 3 (เดิมคือเข้มงวด) ตามที่อธิบายไว้ในส่วน 7.3.10

• [C-5-1] ต้องปิดใช้เมธอดหากแอปพลิเคชัน Device Policy Controller (DPC) ได้ตั้งค่านโยบายคุณภาพรหัสผ่านผ่านเมธอด DevicePolicyManager.setPasswordQuality() ที่มีค่าคงที่คุณภาพที่เข้มงวดกว่า PASSWORD_QUALITY_BIOMETRIC_WEAK
• [C-5-2] ระบบต้องแจ้งให้ผู้ใช้ยืนยันตัวตนหลักที่แนะนำ (เช่น PIN, รูปแบบ, รหัสผ่าน) ตามที่อธิบายไว้ใน [C-1-7] และ [C-1-8] ในส่วนที่ 7.3.10
• [C-5-3] ต้องไม่ถือว่าวิธีการดังกล่าวเป็นหน้าจอล็อกที่ปลอดภัย และต้องเป็นไปตามข้อกำหนดที่เริ่มต้นด้วย C-8 ในส่วนนี้ด้านล่าง

หากการใช้งานอุปกรณ์เพิ่มหรือแก้ไขวิธีการตรวจสอบสิทธิ์เพื่อปลดล็อกหน้าจอล็อก และวิธีการตรวจสอบสิทธิ์ใหม่นั้นอิงตามโทเค็นจริงหรือตำแหน่ง ให้ทำดังนี้

• [C-6-1] ต้องมีกลไกสำรองเพื่อใช้วิธีการตรวจสอบสิทธิ์หลักที่แนะนำวิธีใดวิธีหนึ่งซึ่งอิงตามข้อมูลลับที่ทราบและเป็นไปตามข้อกำหนดในการถือว่าเป็นหน้าจอล็อกที่ปลอดภัย
• [C-6-2] ต้องปิดใช้เมธอดใหม่และอนุญาตให้ใช้วิธีการตรวจสอบสิทธิ์หลักที่แนะนำเพียง 1 วิธีเพื่อปลดล็อกหน้าจอเมื่อแอปพลิเคชัน Device Policy Controller (DPC) ได้ตั้งค่านโยบายด้วยเมธอด DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS) หรือเมธอด DevicePolicyManager.setPasswordQuality() ที่มีค่าคงที่ด้านคุณภาพที่เข้มงวดกว่า PASSWORD_QUALITY_UNSPECIFIED
• [C-6-3] ผู้ใช้ต้องได้รับแจ้งให้ใช้วิธีการตรวจสอบสิทธิ์หลักที่แนะนำ (เช่น PIN, รูปแบบ, รหัสผ่าน) อย่างน้อย 1 ครั้งทุกๆ 4 ชั่วโมงหรือน้อยกว่านั้น
• [C-6-4] วิธีการใหม่ต้องไม่ถือเป็นหน้าจอล็อกที่ปลอดภัย และต้องเป็นไปตามข้อจำกัดที่ระบุไว้ใน C-8 ด้านล่าง

หากการใช้งานอุปกรณ์มีหน้าจอล็อกที่ปลอดภัยและมีเอเจนต์ความน่าเชื่อถืออย่างน้อย 1 รายที่ใช้ TrustAgentService System API อุปกรณ์ดังกล่าวจะทำสิ่งต่อไปนี้ได้

• [C-7-1] ต้องมีข้อบ่งชี้ที่ชัดเจนในเมนูการตั้งค่าและบนหน้าจอล็อกเมื่อมีการเลื่อนการล็อกอุปกรณ์ออกไปหรือเมื่อเอเจนต์ที่เชื่อถือได้ปลดล็อกอุปกรณ์ได้ ตัวอย่างเช่น AOSP เป็นไปตามข้อกำหนดนี้โดยแสดงคำอธิบายข้อความสำหรับการตั้งค่า "ล็อกอัตโนมัติ" และ "ปุ่มเปิด/ปิดจะล็อกทันที" ในเมนูการตั้งค่า และไอคอนที่แยกแยะได้บนหน้าจอล็อก
• [C-7-2] ต้องเคารพและใช้ API ของตัวแทนที่เชื่อถือได้ทั้งหมดในคลาส DevicePolicyManager อย่างเต็มรูปแบบ เช่น ค่าคงที่ KEYGUARD_DISABLE_TRUST_AGENTS
• [C-7-3] ต้องไม่ใช้ฟังก์ชัน TrustAgentService.addEscrowToken() อย่างเต็มรูปแบบในอุปกรณ์ที่ใช้เป็นอุปกรณ์ส่วนตัวหลัก (เช่น อุปกรณ์พกพา) แต่สามารถใช้ฟังก์ชันนี้อย่างเต็มรูปแบบในการติดตั้งใช้งานอุปกรณ์ที่มักใช้ร่วมกัน (เช่น อุปกรณ์ Android Television หรือ Automotive)
• [C-7-4] ต้องเข้ารหัสโทเค็นที่จัดเก็บทั้งหมดซึ่งเพิ่มโดย TrustAgentService.addEscrowToken()
• [C-7-5] ต้องไม่จัดเก็บคีย์การเข้ารหัสหรือโทเค็นการฝากคีย์บนอุปกรณ์เดียวกันกับที่ใช้คีย์ เช่น อนุญาตให้คีย์ที่จัดเก็บไว้ในโทรศัพท์ปลดล็อกบัญชีผู้ใช้ในทีวีได้ สำหรับอุปกรณ์ยานยนต์ ระบบไม่อนุญาตให้จัดเก็บโทเค็นการดูแลจัดการในส่วนใดๆ ของยานพาหนะ
• [C-7-6] ต้องแจ้งให้ผู้ใช้ทราบถึงผลกระทบด้านความปลอดภัยก่อนที่จะเปิดใช้โทเค็นการฝากไว้เพื่อถอดรหัสที่จัดเก็บข้อมูล
• [C-7-7] ต้องมีกลไกสำรองเพื่อใช้วิธีการตรวจสอบสิทธิ์หลักที่แนะนำวิธีใดวิธีหนึ่ง
• [C-7-8] ผู้ใช้ต้องได้รับแจ้งให้ใช้วิธีการตรวจสอบสิทธิ์หลักที่แนะนำ (เช่น PIN, รูปแบบ, รหัสผ่าน) อย่างน้อย 1 ครั้งทุกๆ 72 ชั่วโมงหรือน้อยกว่านั้น เว้นแต่จะมีความกังวลเกี่ยวกับความปลอดภัยของผู้ใช้ (เช่น การรบกวนสมาธิของผู้ขับขี่)
• [C-7-9] ระบบต้องขอให้ผู้ใช้ยืนยันตัวตนด้วยวิธีการยืนยันตัวตนหลักที่แนะนำวิธีใดวิธีหนึ่ง (เช่น PIN, รูปแบบ, รหัสผ่าน) ตามที่อธิบายไว้ใน [C-1-7] และ [C-1-8] ในส่วน 7.3.10 เว้นแต่จะมีความกังวลเกี่ยวกับความปลอดภัยของผู้ใช้ (เช่น การที่ผู้ขับขี่เสียสมาธิ)
• [C-7-10] ต้องไม่ถือเป็นหน้าจอล็อกที่ปลอดภัยและต้องเป็นไปตามข้อจำกัดที่ระบุไว้ใน C-8 ด้านล่าง
• [C-7-11] ต้องไม่อนุญาตให้ TrustAgent ในอุปกรณ์ส่วนตัวหลัก (เช่น อุปกรณ์พกพา) ปลดล็อกอุปกรณ์ และใช้ได้เฉพาะเพื่อให้อุปกรณ์ที่ปลดล็อกแล้วอยู่ในสถานะปลดล็อกได้นานสูงสุด 4 ชั่วโมง การใช้งาน TrustManagerService เริ่มต้นใน AOSP เป็นไปตามข้อกำหนดนี้
• [C-7-12] ต้องใช้ช่องทางการสื่อสารที่มีการเข้ารหัสที่รัดกุม (เช่น UKEY2) เพื่อส่งโทเค็นการดูแลจากอุปกรณ์จัดเก็บข้อมูลไปยังอุปกรณ์เป้าหมาย

หากการใช้งานอุปกรณ์เพิ่มหรือแก้ไขวิธีการตรวจสอบสิทธิ์เพื่อปลดล็อกหน้าจอล็อกที่ไม่ใช่หน้าจอล็อกที่ปลอดภัยตามที่อธิบายไว้ข้างต้น และใช้วิธีการตรวจสอบสิทธิ์ใหม่เพื่อปลดล็อก Keyguard ให้ทำดังนี้

• [C-8-1] ต้องปิดใช้เมธอดใหม่เมื่อแอปพลิเคชัน Device Policy Controller (DPC) ได้ตั้งค่านโยบายคุณภาพรหัสผ่านผ่านเมธอด DevicePolicyManager.setPasswordQuality() ที่มีค่าคงที่คุณภาพที่เข้มงวดกว่า PASSWORD_QUALITY_UNSPECIFIED
• [C-8-2] ผู้ให้บริการต้องไม่รีเซ็ตตัวจับเวลาการหมดอายุของรหัสผ่านที่ DevicePolicyManager.setPasswordExpirationTimeout() ตั้งค่าไว้
• [C-8-3] ต้องไม่เปิดเผย API เพื่อให้แอปของบุคคลที่สามใช้เปลี่ยนสถานะล็อก

9.11.2. StrongBox

ระบบที่เก็บคีย์ของ Android ช่วยให้นักพัฒนาแอปจัดเก็บคีย์การเข้ารหัสไว้ในโปรเซสเซอร์ที่ปลอดภัยโดยเฉพาะ รวมถึงสภาพแวดล้อมการดำเนินการที่แยกไว้ตามที่อธิบายไว้ข้างต้น ตัวประมวลผลที่ปลอดภัยโดยเฉพาะดังกล่าวเรียกว่า "StrongBox" ข้อกำหนด C-1-3 ถึง C-1-11 ด้านล่างนี้กำหนดข้อกำหนดที่อุปกรณ์ต้องมีจึงจะมีสิทธิ์เป็น StrongBox

การติดตั้งใช้งานอุปกรณ์ที่มีโปรเซสเซอร์ที่ปลอดภัยโดยเฉพาะ

• [C-SR] ขอแนะนำอย่างยิ่งให้รองรับ StrongBox StrongBox มีแนวโน้มที่จะกลายเป็นข้อกำหนดในการเปิดตัวรุ่นต่อๆ ไป

หากการติดตั้งใช้งานอุปกรณ์รองรับ StrongBox อุปกรณ์จะทำสิ่งต่อไปนี้

• [C-1-1] ต้องประกาศ FEATURE_STRONGBOX_KEYSTORE

• [C-1-2] ต้องมีฮาร์ดแวร์ที่ปลอดภัยโดยเฉพาะซึ่งใช้เพื่อสำรองที่เก็บคีย์และรักษาความปลอดภัยในการตรวจสอบสิทธิ์ผู้ใช้ นอกจากนี้ ฮาร์ดแวร์ที่ปลอดภัยโดยเฉพาะอาจใช้เพื่อวัตถุประสงค์อื่นๆ ได้ด้วย

• [C-1-3] ต้องมี CPU แยกต่างหากที่ไม่แชร์แคช, DRAM, ตัวประมวลผลร่วม หรือทรัพยากรหลักอื่นๆ กับตัวประมวลผลแอปพลิเคชัน (AP)

• [C-1-4] ต้องตรวจสอบว่าอุปกรณ์ต่อพ่วงที่แชร์กับ AP ไม่สามารถเปลี่ยนแปลงการประมวลผล StrongBox ในทางใดทางหนึ่ง หรือรับข้อมูลใดๆ จาก StrongBox AP อาจปิดใช้หรือบล็อกการเข้าถึง StrongBox

• [C-1-5] ต้องมีนาฬิกาภายในที่มีความแม่นยำที่สมเหตุสมผล (+-10%) ซึ่งไม่ได้รับผลกระทบจากการจัดการโดย AP

• [C-1-6] ต้องมีเครื่องสร้างตัวเลขสุ่มจริงที่สร้างเอาต์พุตที่กระจายอย่างสม่ำเสมอและคาดเดาไม่ได้

• [C-1-7] ต้องมีความต้านทานการดัดแปลง ซึ่งรวมถึงความต้านทานต่อการเจาะทางกายภาพและการเกิดข้อบกพร่อง

• [C-1-8] ต้องมีความต้านทานช่องทางด้านข้าง ซึ่งรวมถึงความต้านทานต่อการรั่วไหลของข้อมูลผ่านช่องทางด้านข้างของกำลังไฟฟ้า เวลา การแผ่รังสีแม่เหล็กไฟฟ้า และการแผ่รังสีความร้อน

• [C-1-9] ต้องมีพื้นที่เก็บข้อมูลที่ปลอดภัยซึ่งรับประกันความลับ ความสมบูรณ์ ความถูกต้อง ความสอดคล้อง และความใหม่ของเนื้อหา ระบบต้องอ่านหรือแก้ไขที่เก็บไม่ได้ เว้นแต่จะได้รับอนุญาตจาก StrongBox API

• หากต้องการตรวจสอบความสอดคล้องกับ [C-1-3] ถึง [C-1-9] การใช้งานอุปกรณ์ต้องมีลักษณะดังนี้

  • [C-1-10] ต้องมีฮาร์ดแวร์ที่ได้รับการรับรองตามโปรไฟล์การป้องกัน IC ที่ปลอดภัย BSI-CC-PP-0084-2014 หรือได้รับการประเมินโดยห้องปฏิบัติการทดสอบที่ได้รับการรับรองระดับประเทศซึ่งรวมการประเมินช่องโหว่ที่มีศักยภาพในการโจมตีสูงตามการใช้ศักยภาพในการโจมตีกับสมาร์ทการ์ดตามเกณฑ์ร่วมกัน
  • [C-1-11] ต้องมีเฟิร์มแวร์ที่ได้รับการประเมินโดยห้องปฏิบัติการทดสอบที่ได้รับการรับรองระดับประเทศซึ่งรวมการประเมินช่องโหว่ที่มีศักยภาพในการโจมตีสูงตามการประยุกต์ใช้ศักยภาพในการโจมตีกับสมาร์ทการ์ดตามเกณฑ์ร่วม
  • [C-SR] ขอแนะนำอย่างยิ่งให้รวมฮาร์ดแวร์ที่ได้รับการประเมินโดยใช้เป้าหมายด้านความปลอดภัย ระดับการรับประกันการประเมิน (EAL) 5 ซึ่งเสริมด้วย AVA_VAN.5 การรับรอง EAL 5 มีแนวโน้มที่จะกลายเป็นข้อกำหนดในรุ่นต่อๆ ไป

• [C-SR] ขอแนะนำอย่างยิ่งให้ใช้เพื่อป้องกันการโจมตีจากภายใน (IAR) ซึ่งหมายความว่าผู้ที่อยู่ภายในซึ่งมีสิทธิ์เข้าถึงคีย์การลงนามเฟิร์มแวร์จะไม่สามารถสร้างเฟิร์มแวร์ที่ทำให้ StrongBox รั่วไหลข้อมูลลับ บายพาสข้อกำหนดด้านความปลอดภัยในการทำงาน หรือเปิดใช้การเข้าถึงข้อมูลผู้ใช้ที่ละเอียดอ่อน วิธีที่แนะนำในการติดตั้งใช้งาน IAR คือการอนุญาตให้อัปเดตเฟิร์มแวร์เฉพาะเมื่อมีการระบุรหัสผ่านของผู้ใช้หลักผ่าน IAuthSecret HAL

9.11.3. ข้อมูลประจำตัว

ระบบข้อมูลเข้าสู่ระบบประจำตัวได้รับการกำหนดและสร้างขึ้นโดยการติดตั้งใช้งาน API ทั้งหมดในแพ็กเกจ android.security.identity.* API เหล่านี้ช่วยให้นักพัฒนาแอปจัดเก็บและดึงเอกสารระบุตัวตนของผู้ใช้ได้ การติดตั้งใช้งานอุปกรณ์

• [C-SR] ขอแนะนำอย่างยิ่งให้ติดตั้งใช้งานระบบข้อมูลเข้าสู่ระบบเพื่อยืนยันตัวตน

หากการติดตั้งใช้งานอุปกรณ์ใช้ระบบข้อมูลเข้าสู่ระบบประจำตัว อุปกรณ์จะต้องดำเนินการต่อไปนี้

• [C-0-1] ต้องแสดงผลที่ไม่ใช่ Null สำหรับเมธอด IdentityCredentialStore#getInstance()

• [C-0-2] ต้องใช้ระบบข้อมูลเข้าสู่ระบบประจำตัว (เช่น android.security.identity.* API) กับโค้ดที่สื่อสารกับแอปพลิเคชันที่เชื่อถือได้ในพื้นที่ที่แยกออกจากโค้ดที่ทำงานในเคอร์เนลและเหนือกว่าอย่างปลอดภัย การแยกอย่างปลอดภัยต้องบล็อกกลไกที่เป็นไปได้ทั้งหมดซึ่งโค้ดเคอร์เนลหรือโค้ดในพื้นที่ผู้ใช้อาจใช้เพื่อเข้าถึงสถานะภายในของสภาพแวดล้อมที่แยก รวมถึง DMA

• [C-0-3] การดำเนินการเข้ารหัสที่จำเป็นต่อการติดตั้งใช้งานระบบข้อมูลประจำตัว (เช่น android.security.identity.* API) ต้องดำเนินการในแอปพลิเคชันที่เชื่อถือได้อย่างสมบูรณ์ และห้ามไม่ให้คีย์ส่วนตัวออกจากสภาพแวดล้อมการดำเนินการที่แยกจากกัน เว้นแต่ API ระดับสูงกว่าจะกำหนดไว้โดยเฉพาะ (เช่น เมธอด createEphemeralKeyPair())

• [C-0-4] ต้องติดตั้งใช้งานแอปพลิเคชันที่เชื่อถือได้ในลักษณะที่พร็อพเพอร์ตี้ความปลอดภัยไม่ได้รับผลกระทบ (เช่น จะไม่เผยแพร่ข้อมูลเข้าสู่ระบบจนกว่าจะตรงตามเงื่อนไขการควบคุมการเข้าถึง ไม่สามารถสร้าง MAC สำหรับข้อมูลที่กำหนดเองได้) แม้ว่า Android จะทำงานผิดปกติหรือถูกบุกรุกก็ตาม

9.12. การลบข้อมูล

การติดตั้งใช้งานอุปกรณ์ทั้งหมด

• [C-0-1] ต้องจัดหากลไกให้ผู้ใช้ดำเนินการ "รีเซ็ตข้อมูลเป็นค่าเริ่มต้น"
• [C-0-2] ต้องลบข้อมูลทั้งหมดในระบบไฟล์ userdata
• [C-0-3] ต้องลบข้อมูลในลักษณะที่จะเป็นไปตามมาตรฐานอุตสาหกรรมที่เกี่ยวข้อง เช่น NIST SP800-88
• [C-0-4] ต้องทริกเกอร์กระบวนการ "รีเซ็ตข้อมูลเป็นค่าเริ่มต้นจากโรงงาน" ข้างต้นเมื่อแอปเครื่องมือควบคุมนโยบายด้านอุปกรณ์ของผู้ใช้หลักเรียกใช้ API DevicePolicyManager.wipeData()
• อาจมีตัวเลือกการล้างข้อมูลอย่างรวดเร็วที่ดำเนินการลบข้อมูลเชิงตรรกะเท่านั้น

9.13. โหมดการเปิดเครื่องที่ปลอดภัย

Android มีโหมดการรีบูตอย่างปลอดภัย ซึ่งอนุญาตให้ผู้ใช้รีบูตเข้าสู่โหมดที่อนุญาตให้เฉพาะแอประบบที่ติดตั้งไว้ล่วงหน้าเท่านั้นที่ทำงานได้ และปิดใช้แอปของบุคคลที่สามทั้งหมด โหมดนี้เรียกว่า "โหมดการบูตอย่างปลอดภัย" ซึ่งช่วยให้ผู้ใช้สามารถถอนการติดตั้งแอปของบุคคลที่สามที่อาจเป็นอันตรายได้

การติดตั้งใช้งานอุปกรณ์มีดังนี้

• [SR] ขอแนะนำอย่างยิ่งให้ใช้โหมดการเปิดเครื่องที่ปลอดภัย

หากการใช้งานอุปกรณ์ใช้โหมดการเริ่มต้นระบบอย่างปลอดภัย อุปกรณ์จะทำสิ่งต่อไปนี้

• [C-1-1] ต้องมีตัวเลือกให้ผู้ใช้เข้าสู่โหมดปลอดภัยในลักษณะที่แอปของบุคคลที่สามที่ติดตั้งในอุปกรณ์ไม่สามารถขัดขวางได้ เว้นแต่ว่าแอปของบุคคลที่สามจะเป็นตัวควบคุมนโยบายอุปกรณ์และได้ตั้งค่าสถานะ UserManager.DISALLOW_SAFE_BOOT เป็นจริง

• [C-1-2] ต้องให้ผู้ใช้สามารถถอนการติดตั้งแอปของบุคคลที่สามในโหมดปลอดภัย

• ควรมีตัวเลือกให้ผู้ใช้เข้าสู่โหมดการบูตอย่างปลอดภัยจากเมนูการบูตโดยใช้เวิร์กโฟลว์ที่แตกต่างจากการบูตปกติ

9.14. การแยกระบบยานยนต์

อุปกรณ์ Android Automotive คาดว่าจะแลกเปลี่ยนข้อมูลกับระบบย่อยที่สำคัญของยานพาหนะโดยใช้ HAL ของยานพาหนะเพื่อส่งและรับข้อความผ่านเครือข่ายยานพาหนะ เช่น CAN Bus

การแลกเปลี่ยนข้อมูลสามารถรักษาความปลอดภัยได้โดยการใช้ฟีเจอร์ความปลอดภัยที่อยู่ใต้เลเยอร์เฟรมเวิร์กของ Android เพื่อป้องกันการโต้ตอบที่เป็นอันตรายหรือไม่ตั้งใจกับระบบย่อยเหล่านี้

9.15. แพ็กเกจการสมัครใช้บริการ

"แพ็กเกจการสมัครใช้บริการ" หมายถึงรายละเอียดแพ็กเกจความสัมพันธ์ในการเรียกเก็บเงินที่ผู้ให้บริการเครือข่ายมือถือระบุผ่าน SubscriptionManager.setSubscriptionPlans()

การติดตั้งใช้งานอุปกรณ์ทั้งหมด

• [C-0-1] ต้องแสดงแพ็กเกจการสมัครใช้บริการเฉพาะในแอปของผู้ให้บริการเครือข่ายมือถือที่ให้บริการแพ็กเกจดังกล่าวตั้งแต่แรกเท่านั้น
• [C-0-2] ต้องไม่สำรองข้อมูลหรืออัปโหลดแพ็กเกจการสมัครใช้บริการจากระยะไกล
• [C-0-3] ต้องอนุญาตการลบล้าง เช่น SubscriptionManager.setSubscriptionOverrideCongested() จากแอปผู้ให้บริการเครือข่ายมือถือที่ให้บริการแพ็กเกจการสมัครใช้บริการที่ถูกต้องในปัจจุบันเท่านั้น

9.16. การย้ายข้อมูลแอปพลิเคชัน

หากการใช้งานอุปกรณ์มีความสามารถในการย้ายข้อมูลจากอุปกรณ์หนึ่งไปยังอีกอุปกรณ์หนึ่ง และไม่ได้จำกัดข้อมูลแอปพลิเคชันที่คัดลอกไว้ตามที่นักพัฒนาแอปพลิเคชันกำหนดค่าไว้ในไฟล์ Manifest ผ่านแอตทริบิวต์ android:fullBackupContent การใช้งานดังกล่าวจะมีลักษณะดังนี้

• [C-1-1] ต้องไม่เริ่มการโอนข้อมูลแอปพลิเคชันจากอุปกรณ์ที่ผู้ใช้ไม่ได้ตั้งค่าการตรวจสอบสิทธิ์หลักตามที่อธิบายไว้ใน9.11.1 หน้าจอล็อกและการตรวจสอบสิทธิ์ที่ปลอดภัย
• [C-1-2] ต้องยืนยันการตรวจสอบสิทธิ์หลักในอุปกรณ์แหล่งที่มาอย่างปลอดภัย และยืนยันความตั้งใจของผู้ใช้ที่จะคัดลอกข้อมูลในอุปกรณ์แหล่งที่มาก่อนที่จะโอนข้อมูล
• [C-1-3] ต้องใช้เอกสารรับรองคีย์ความปลอดภัยเพื่อให้แน่ใจว่าทั้งอุปกรณ์ต้นทางและอุปกรณ์ปลายทางในการย้ายข้อมูลจากอุปกรณ์หนึ่งไปยังอีกอุปกรณ์หนึ่งเป็นอุปกรณ์ Android ที่ถูกต้องและมี Bootloader ที่ล็อกอยู่
• [C-1-4] ต้องย้ายข้อมูลแอปพลิเคชันไปยังแอปพลิเคชันเดียวกันในอุปกรณ์เป้าหมายเท่านั้น โดยมีชื่อแพ็กเกจและใบรับรองการลงนามเดียวกัน
• [C-1-5] ต้องแสดงข้อบ่งชี้ว่าอุปกรณ์ต้นทางได้ย้ายข้อมูลโดยการย้ายข้อมูลจากอุปกรณ์หนึ่งไปยังอีกอุปกรณ์หนึ่งในเมนูการตั้งค่า ผู้ใช้ไม่ควรนำข้อบ่งชี้นี้ออกได้

10. การทดสอบความเข้ากันได้ของซอฟต์แวร์

การใช้งานอุปกรณ์ต้องผ่านการทดสอบทั้งหมดที่อธิบายไว้ในส่วนนี้ อย่างไรก็ตาม โปรดทราบว่าแพ็กเกจทดสอบซอฟต์แวร์ไม่มีแพ็กเกจใดที่ครอบคลุมทั้งหมด ด้วยเหตุนี้ เราจึงขอแนะนำอย่างยิ่งให้ผู้ติดตั้งใช้งานอุปกรณ์ทำการเปลี่ยนแปลงจำนวนน้อยที่สุดเท่าที่จะเป็นไปได้ในการติดตั้งใช้งาน Android ที่อ้างอิงและแนะนำจากโครงการโอเพนซอร์ส Android ซึ่งจะช่วยลดความเสี่ยงในการทำให้เกิดข้อบกพร่องที่สร้างความไม่เข้ากันซึ่งต้องมีการแก้ไขและอาจต้องอัปเดตอุปกรณ์

10.1. ชุดเครื่องมือทดสอบความเข้ากันได้

การติดตั้งใช้งานอุปกรณ์

• [C-0-1] ต้องผ่านชุดเครื่องมือทดสอบความเข้ากันได้ของ Android (CTS) ที่พร้อมใช้งานจากโครงการโอเพนซอร์ส Android โดยใช้ซอฟต์แวร์ที่จัดส่งขั้นสุดท้ายในอุปกรณ์

• [C-0-2] ต้องตรวจสอบความเข้ากันได้ในกรณีที่มีความคลุมเครือใน CTS และสำหรับการนำส่วนต่างๆ ของซอร์สโค้ดอ้างอิงกลับมาใช้ใหม่

CTS ออกแบบมาให้ทำงานบนอุปกรณ์จริง เช่นเดียวกับซอฟต์แวร์อื่นๆ CTS เองก็อาจมีข้อบกพร่อง CTS จะมีการกำหนดเวอร์ชันแยกต่างหากจากคำจำกัดความความเข้ากันได้นี้ และอาจมีการเผยแพร่ CTS หลายฉบับสำหรับ Android 11

การติดตั้งใช้งานอุปกรณ์

• [C-0-3] ต้องผ่าน CTS เวอร์ชันล่าสุดที่พร้อมใช้งานในขณะที่ซอฟต์แวร์ของอุปกรณ์เสร็จสมบูรณ์

• ควรใช้การติดตั้งใช้งานอ้างอิงในโครงสร้าง Android Open Source ให้มากที่สุด

10.2. โปรแกรมตรวจสอบ CTS

CTS Verifier รวมอยู่ในชุดเครื่องมือทดสอบความเข้ากันได้ และมีไว้สำหรับให้ผู้ปฏิบัติงานที่เป็นมนุษย์เรียกใช้เพื่อทดสอบฟังก์ชันการทำงานที่ระบบอัตโนมัติทดสอบไม่ได้ เช่น การทำงานที่ถูกต้องของกล้องและเซ็นเซอร์

การติดตั้งใช้งานอุปกรณ์

• [C-0-1] ต้องดำเนินการกรณีที่เกี่ยวข้องทั้งหมดใน CTS Verifier อย่างถูกต้อง

CTS Verifier มีการทดสอบสำหรับฮาร์ดแวร์หลายประเภท รวมถึงฮาร์ดแวร์บางอย่างที่ไม่บังคับ

การติดตั้งใช้งานอุปกรณ์

• [C-0-2] ต้องผ่านการทดสอบทั้งหมดสำหรับฮาร์ดแวร์ที่มี เช่น หากอุปกรณ์มีเครื่องวัดความเร่ง อุปกรณ์ต้องเรียกใช้กรณีทดสอบเครื่องวัดความเร่งใน CTS Verifier อย่างถูกต้อง

ระบบอาจข้ามหรือละเว้นกรณีทดสอบสำหรับฟีเจอร์ที่เอกสารนิยามความเข้ากันได้นี้ระบุว่าเป็นฟีเจอร์ที่ไม่บังคับ

• [C-0-2] อุปกรณ์และบิลด์ทุกรายการต้องเรียกใช้ CTS Verifier อย่างถูกต้องตามที่ระบุไว้ข้างต้น อย่างไรก็ตาม เนื่องจากบิลด์จำนวนมากมีความคล้ายคลึงกันมาก เราจึงไม่คาดหวังให้ผู้ติดตั้งใช้งานอุปกรณ์เรียกใช้ CTS Verifier อย่างชัดเจนในบิลด์ที่แตกต่างกันเพียงเล็กน้อย โดยเฉพาะอย่างยิ่ง การใช้งานอุปกรณ์ที่แตกต่างจากการใช้งานที่ผ่าน CTS Verifier เฉพาะชุดภาษาที่รวมไว้ การสร้างแบรนด์ ฯลฯ อาจละเว้นการทดสอบ CTS Verifier ได้

11. ซอฟต์แวร์ที่อัปเดตได้

• [C-0-1] การติดตั้งใช้งานอุปกรณ์ต้องมีกลไกในการแทนที่ซอฟต์แวร์ระบบทั้งหมด กลไกไม่จำเป็นต้องทำการอัปเกรด "แบบเรียลไทม์" กล่าวคือ อาจต้องรีสตาร์ทอุปกรณ์ คุณใช้วิธีใดก็ได้ตราบใดที่สามารถแทนที่ซอฟต์แวร์ทั้งหมดที่ติดตั้งไว้ล่วงหน้าในอุปกรณ์ได้ เช่น วิธีการต่อไปนี้จะตรงตามข้อกำหนดนี้

  • การดาวน์โหลด "ผ่านอากาศ (OTA)" พร้อมการอัปเดตแบบออฟไลน์ผ่านการรีบูต
  • การอัปเดตแบบ "เชื่อมต่อ" ผ่าน USB จาก PC โฮสต์
  • การอัปเดต "ออฟไลน์" ผ่านการรีบูตและการอัปเดตจากไฟล์ในที่เก็บข้อมูลแบบถอดได้

• [C-0-2] กลไกการอัปเดตที่ใช้ต้องรองรับการอัปเดตโดยไม่ล้างข้อมูลผู้ใช้ กล่าวคือ กลไกการอัปเดตต้องรักษาข้อมูลส่วนตัวของแอปพลิเคชันและข้อมูลที่แอปพลิเคชันแชร์ โปรดทราบว่าซอฟต์แวร์ Android ต้นทางมีกลไกการอัปเดตที่ตรงตามข้อกำหนดนี้

• [C-0-3] การอัปเดตทั้งหมดต้องได้รับการลงนาม และกลไกการอัปเดตในอุปกรณ์ต้องยืนยันการอัปเดตและลายเซ็นกับคีย์สาธารณะที่จัดเก็บไว้ในอุปกรณ์

• [C-SR] ขอแนะนำอย่างยิ่งให้กลไกการลงนามแฮชการอัปเดตด้วย SHA-256 และตรวจสอบแฮชกับคีย์สาธารณะโดยใช้ ECDSA NIST P-256

หากการติดตั้งใช้งานอุปกรณ์รวมถึงการรองรับการเชื่อมต่ออินเทอร์เน็ตแบบไม่มีการวัดปริมาณอินเทอร์เน็ต เช่น โปรไฟล์ 802.11 หรือ Bluetooth PAN (เครือข่ายส่วนบุคคล) อุปกรณ์ดังกล่าวจะมีลักษณะดังนี้

• [C-1-1] ต้องรองรับการดาวน์โหลด OTA พร้อมการอัปเดตแบบออฟไลน์ผ่านการรีบูต

สำหรับการติดตั้งใช้งานอุปกรณ์ที่เปิดตัวด้วย Android 6.0 ขึ้นไป กลไกการอัปเดตควรจะรองรับการยืนยันว่าอิมเมจระบบเป็นไบนารีที่เหมือนกับผลลัพธ์ที่คาดไว้หลังจากการอัปเดต OTA การติดตั้งใช้งาน OTA แบบบล็อกในโปรเจ็กต์โอเพนซอร์สของ Android ต้นทาง ซึ่งเพิ่มเข้ามาตั้งแต่ Android 5.1 เป็นไปตามข้อกำหนดนี้

นอกจากนี้ การติดตั้งใช้งานอุปกรณ์ควรจะรองรับการอัปเดตระบบ A/B AOSP จะใช้ฟีเจอร์นี้โดยใช้ HAL ของการควบคุมการบูต

หากพบข้อผิดพลาดในการติดตั้งใช้งานอุปกรณ์หลังจากที่เผยแพร่แล้ว แต่ยังอยู่ในช่วงอายุการใช้งานผลิตภัณฑ์ที่สมเหตุสมผลซึ่งกำหนดขึ้นโดยการปรึกษากับทีมความเข้ากันได้ของ Android เพื่อส่งผลต่อความเข้ากันได้ของแอปพลิเคชันของบุคคลที่สาม ให้ทำดังนี้

• [C-2-1] ผู้ติดตั้งใช้งานอุปกรณ์ต้องแก้ไขข้อผิดพลาดผ่านการอัปเดตซอฟต์แวร์ที่พร้อมใช้งานซึ่งสามารถใช้ได้ตามกลไกที่อธิบายไว้ข้างต้น

Android มีฟีเจอร์ที่ช่วยให้แอปเจ้าของอุปกรณ์ (หากมี) ควบคุมการติดตั้งการอัปเดตระบบได้ หากระบบย่อยการอัปเดตระบบสำหรับอุปกรณ์รายงาน android.software.device_admin แสดงว่าอุปกรณ์มีลักษณะดังนี้

• [C-3-1] ต้องใช้ลักษณะการทำงานที่อธิบายไว้ในคลาส SystemUpdatePolicy

12. บันทึกการเปลี่ยนแปลงของเอกสาร

สรุปการเปลี่ยนแปลงคำจำกัดความความเข้ากันได้ในรุ่นนี้

• บันทึกการเปลี่ยนแปลงของเอกสาร

สรุปการเปลี่ยนแปลงในแต่ละส่วนมีดังนี้

1. บทนำ
2. ประเภทอุปกรณ์
3. ซอฟต์แวร์
4. การแพ็กเกจแอปพลิเคชัน
5. มัลติมีเดีย
6. เครื่องมือและตัวเลือกสำหรับนักพัฒนาซอฟต์แวร์
7. ความเข้ากันได้ของฮาร์ดแวร์
8. ประสิทธิภาพและกำลัง
9. โมเดลความปลอดภัย
10. การทดสอบความเข้ากันได้ของซอฟต์แวร์
11. ซอฟต์แวร์ที่อัปเดตได้
12. บันทึกการเปลี่ยนแปลงของเอกสาร
13. ติดต่อเรา

12.1. เคล็ดลับในการดูบันทึกการเปลี่ยนแปลง

การเปลี่ยนแปลงจะมีการทำเครื่องหมายดังนี้

• CDD
  การเปลี่ยนแปลงที่สำคัญต่อข้อกำหนดความเข้ากันได้

• เอกสาร
  การเปลี่ยนแปลงที่เกี่ยวข้องกับการสร้างหรือการปรับแต่ง

หากต้องการให้แสดงผลได้ดีที่สุด ให้เพิ่มพารามิเตอร์ URL pretty=full และ no-merges ลงใน URL ของบันทึกการเปลี่ยนแปลง

13. ติดต่อเรา

คุณเข้าร่วมฟอรัมความเข้ากันได้ของ Android และขอคำชี้แจงหรือแจ้งปัญหาที่คิดว่าเอกสารไม่ได้กล่าวถึงได้