1. ข้อมูลเบื้องต้น
เอกสารนี้แจกแจงข้อกำหนดที่ต้องปฏิบัติตามเพื่อให้อุปกรณ์ใช้งานร่วมกับ Android 11 ได้
การใช้ "ต้อง" "ต้องไม่" "ต้องระบุ" "จะ" "จะไม่" "ไม่ควร" "ไม่ควร" "แนะนำ" "อาจ" และ "ไม่บังคับ" เป็นไปตามมาตรฐาน IETF ที่ระบุไว้ใน RFC2119
ตามที่ใช้ในเอกสารนี้ "ผู้ติดตั้งใช้งานอุปกรณ์" หรือ "ผู้ติดตั้งใช้งาน" คือบุคคลหรือองค์กรที่พัฒนาโซลูชันฮาร์ดแวร์/ซอฟต์แวร์ที่ใช้ Android 11 "การติดตั้งใช้งานอุปกรณ์" หรือ "การใช้งาน" คือโซลูชันฮาร์ดแวร์/ซอฟต์แวร์ที่ได้รับการพัฒนาขึ้นมา
หากต้องการรับการพิจารณาว่าเข้ากันได้กับ Android 11 การใช้งานอุปกรณ์จะต้องเป็นไปตามข้อกำหนดที่ระบุไว้ในคำจำกัดความความเข้ากันได้นี้ รวมถึงเอกสารใดๆ ที่รวบรวมผ่านข้อมูลอ้างอิง
เมื่อคำจำกัดความนี้หรือการทดสอบซอฟต์แวร์ที่อธิบายไว้ในส่วนที่ 10 เป็นแบบไม่มีเสียง กำกวม หรือไม่สมบูรณ์ ผู้ติดตั้งใช้งานอุปกรณ์มีหน้าที่ตรวจสอบว่าความเข้ากันได้กับการติดตั้งใช้งานที่มีอยู่
ด้วยเหตุนี้ โครงการโอเพนซอร์ส Android จึงเป็นทั้งการอ้างอิงและการติดตั้งใช้งานที่ต้องการของ Android ขอแนะนำเป็นอย่างยิ่งให้ผู้ใช้ใช้อุปกรณ์เพื่อยึดถือในการติดตั้งใช้งานเป็นหลักในซอร์สโค้ด "อัปสตรีม" ที่มีให้จากโครงการโอเพนซอร์สของ Android แม้ว่าองค์ประกอบบางอย่างจะสามารถแทนที่โดยการติดตั้งแบบอื่นได้ แต่เราขอแนะนำเป็นอย่างยิ่งว่าคุณไม่ควรทำตามแนวทางปฏิบัตินี้ เนื่องจากการผ่านการทดสอบซอฟต์แวร์จะยากขึ้นมาก ผู้ติดตั้งใช้งานมีหน้าที่ตรวจสอบความเข้ากันได้ทางพฤติกรรมอย่างสมบูรณ์กับการใช้งาน Android มาตรฐาน ซึ่งรวมถึงและนอกเหนือจากชุดทดสอบความเข้ากันได้ สุดท้ายนี้ โปรดทราบว่าเอกสารนี้ไม่อนุญาตให้มีการแทนที่และการแก้ไขคอมโพเนนต์บางอย่างอย่างชัดเจน
ทรัพยากรหลายรายการที่เชื่อมโยงกับเอกสารนี้ได้มาจาก Android SDK โดยตรงหรือโดยอ้อม และมีฟังก์ชันการทำงานเหมือนกับข้อมูลในเอกสารประกอบของ SDK นั้น ในกรณีที่คำจำกัดความความเข้ากันได้หรือชุดทดสอบความเข้ากันได้นี้ไม่สอดคล้องกับเอกสารประกอบของ SDK เอกสาร SDK จะถือว่าเชื่อถือได้ รายละเอียดทางเทคนิคใดๆ ที่ระบุไว้ในทรัพยากรที่ลิงก์ตลอดทั้งเอกสารนี้จะถือว่ารวมอยู่ในคำจำกัดความความเข้ากันได้นี้
1.1 โครงสร้างเอกสาร
1.1.1 ข้อกำหนดตามประเภทอุปกรณ์
ส่วนที่ 2 มีข้อกำหนดทั้งหมดที่ใช้กับอุปกรณ์แต่ละประเภท ส่วนย่อยของส่วนที่ 2 มีไว้สำหรับประเภทอุปกรณ์ที่เฉพาะเจาะจง
ข้อกำหนดอื่นๆ ทั้งหมดซึ่งมีผลกับการใช้งานอุปกรณ์ Android ทั้งหมดจะแสดงอยู่ในส่วนหลังจากส่วนที่ 2 ข้อกำหนดเหล่านี้เรียกว่า "ข้อกำหนดหลัก" ในเอกสารนี้
1.1.2 รหัสข้อกำหนด
มีการกำหนดรหัสข้อกำหนดสำหรับข้อกำหนด "ต้อง" แล้ว
- รหัสได้รับการกำหนดสำหรับข้อกำหนด "ต้อง" เท่านั้น
- ข้อกำหนดที่แนะนำอย่างยิ่งจะมีเครื่องหมายเป็น [SR] แต่ยังไม่มีการกำหนดบัตรประจำตัว
- รหัสประกอบด้วย : รหัสประเภทอุปกรณ์ - รหัสเงื่อนไข - รหัสข้อกำหนด (เช่น C-0-1)
แต่ละรหัสจะมีคำจำกัดความดังนี้
- รหัสประเภทอุปกรณ์ (ดูข้อมูลเพิ่มเติมใน 2. ประเภทอุปกรณ์)
- C: หลัก (ข้อกำหนดที่ใช้กับการใช้งานอุปกรณ์ Android ใดๆ ก็ตาม)
- H: อุปกรณ์ Android แบบพกพา
- T: อุปกรณ์ Android TV
- ตอบ: การติดตั้งใช้งาน Android Automotive
- W: การใช้งาน Android Watch
- แท็บ: การใช้งานแท็บเล็ต Android
- รหัสเงื่อนไข
- เมื่อข้อกำหนดไม่มีเงื่อนไข ระบบจะกำหนดรหัสนี้เป็น 0
- เมื่อข้อกำหนดเป็นแบบมีเงื่อนไข ระบบจะกำหนด 1 ให้กับเงื่อนไขที่ 1 และเพิ่มตัวเลขครั้งละ 1 ในส่วนเดียวกันและอุปกรณ์ประเภทเดียวกัน
- รหัสข้อกำหนด
- รหัสนี้จะเริ่มต้นจาก 1 และเพิ่มทีละ 1 ภายในส่วนเดียวกันและอยู่ในเงื่อนไขเดียวกัน
1.1.3 รหัสข้อกำหนดในส่วนที่ 2
รหัสข้อกำหนดในส่วนที่ 2 ขึ้นต้นด้วยรหัสส่วนที่เกี่ยวข้อง ตามด้วยรหัสข้อกำหนดที่อธิบายไว้ข้างต้น
- รหัสในส่วนที่ 2 ประกอบด้วยรหัสส่วน / รหัสประเภทอุปกรณ์ - รหัสเงื่อนไข - รหัสข้อกำหนด (เช่น 7.4.3/A-0-1)
2. ประเภทอุปกรณ์
แม้ว่าโครงการโอเพนซอร์สของ Android จะมีกลุ่มซอฟต์แวร์ที่สามารถใช้งานได้กับอุปกรณ์และรูปแบบของอุปกรณ์หลากหลายประเภท แต่ก็มีอุปกรณ์ 2-3 ประเภทที่ระบบนิเวศการเผยแพร่แอปพลิเคชันในระดับที่ค่อนข้างดีกว่า
ส่วนนี้จะอธิบายประเภทอุปกรณ์เหล่านั้น รวมถึงข้อกำหนดและคำแนะนำเพิ่มเติมที่เกี่ยวข้องกับอุปกรณ์แต่ละประเภท
การใช้งานอุปกรณ์ 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 ก่อนวันที่ของเอกสารนี้จะได้รับการยกเว้นจากข้อกำหนดนี้
หากการใช้งานอุปกรณ์เคลื่อนที่อ้างว่ารองรับการแสดงผลภาพที่มีช่วงการรับแสงสูงกว่าปกติถึง Configuration.isScreenHdr()
ระบบจะดำเนินการดังต่อไปนี้
- [7.1.4.5/H-1-1] ต้องโฆษณาการรองรับส่วนขยาย
EGL_EXT_gl_colorspace_bt2020_pq
,EGL_EXT_surface_SMPTE2086_metadata
,EGL_EXT_surface_CTA861_3_metadata
,VK_EXT_swapchain_colorspace
และVK_EXT_hdr_metadata
การใช้งานอุปกรณ์เคลื่อนที่
- [7.1.4.6/H-0-1] ต้องรายงานว่าอุปกรณ์รองรับความสามารถในการทำโปรไฟล์ GPU ผ่านพร็อพเพอร์ตี้ของระบบ
graphics.gpu.profiler.support
หรือไม่
หากการใช้งานอุปกรณ์พกพาประกาศการรองรับผ่านพร็อพเพอร์ตี้ของระบบ graphics.gpu.profiler.support
การใช้งานจะได้รับอนุญาตดังนี้
- [7.1.4.6/H-1-1] ต้องรายงานว่าแสดงผลเป็นการติดตาม Protobuf ที่สอดคล้องกับสคีมาสำหรับตัวนับ GPU และขั้นตอนการแสดงผลของ GPU ที่ระบุในเอกสารประกอบของ Perfetto
- [7.1.4.6/H-1-2] ต้องรายงานค่าที่สอดคล้องกันสำหรับตัวนับ GPU ของอุปกรณ์ตาม โปรโตคอลการติดตามตัวนับ gpu
- [7.1.4.6/H-1-3] ต้องรายงานค่าที่สอดคล้องกันสำหรับ GPU RenderStag ของอุปกรณ์ตาม 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] ต้องมีการรองรับแอปพลิเคชัน Input Method Editor (IME) ของบุคคลที่สาม
- [7.2.3/H-0-3] ต้องระบุฟังก์ชันหน้าแรกในจอแสดงผลที่รองรับ Android ทั้งหมดที่มีหน้าจอหลัก
- [7.2.3/H-0-4] ต้องระบุฟังก์ชันกลับในจอแสดงผลที่รองรับ Android และฟังก์ชันล่าสุดในจอแสดงผลที่รองรับ Android อย่างน้อย 1 จอ
- [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] ต้องรายงานช่วง Pseudoranges และอัตรา Pseudorange ของ GNSS ในสภาพท้องฟ้าเปิดหลังจากระบุตำแหน่งขณะที่อยู่นิ่งหรือเคลื่อนที่ด้วยความเร่งน้อยกว่า 0.2 เมตรต่อวินาทียกกำลังสอง เพียงพอที่จะคำนวณตำแหน่งภายใน 20 เมตร และความเร็วอย่างน้อย 0.2 เมตรต่อวินาที อย่างน้อยที่สุด .9% ต่อวินาที
หากการใช้งานอุปกรณ์พกพามีเครื่องวัดการหมุน 3 แกน สิ่งที่จะเกิดขึ้นมีดังนี้
- [7.3.4/H-3-1] ต้องรายงานเหตุการณ์ได้ด้วยความถี่อย่างน้อย 100 Hz
- [7.3.4/H-3-2] ต้องมีความสามารถในการวัดการวางแนวที่เปลี่ยนไปได้สูงสุด 1,000 องศาต่อวินาที
การใช้งานอุปกรณ์เคลื่อนที่ที่สามารถโทรออกและระบุค่าอื่นๆ ที่ไม่ใช่ PHONE_TYPE_NONE
ใน getPhoneType
:
- [7.3.8/H] ควรมีพร็อกซิมิตีเซ็นเซอร์
การใช้งานอุปกรณ์เคลื่อนที่
- [7.3.11/H-SR] แนะนำให้รองรับเซ็นเซอร์ท่าทางที่มีอิสระ 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] ต้องแสดงผล "true" สำหรับ
ActivityManager.isLowRamDevice()
เมื่อมีหน่วยความจำที่ใช้ได้น้อยกว่า 1 GB สำหรับเคอร์เนลและพื้นที่ผู้ใช้
หากการใช้งานอุปกรณ์พกพาประกาศว่ารองรับ ABI แบบ 32 บิตเท่านั้น
-
[7.6.1/H-1-1] หน่วยความจำที่พร้อมให้เคอร์เนลและพื้นที่ผู้ใช้ต้องมีขนาดอย่างน้อย 416 MB หากจอแสดงผลเริ่มต้นใช้ความละเอียดเฟรมบัฟเฟอร์สูงสุดถึง qHD (เช่น FWVGA)
-
[7.6.1/H-2-1] หน่วยความจำที่มีให้กับเคอร์เนลและพื้นที่ผู้ใช้ต้องมีขนาดอย่างน้อย 592 MB หากจอแสดงผลเริ่มต้นใช้ความละเอียดของเฟรมบัฟเฟอร์สูงสุดถึง HD+ (เช่น HD, WSVGA)
-
[7.6.1/H-3-1] หน่วยความจำที่พร้อมให้เคอร์เนลและพื้นที่ผู้ใช้ต้องมีขนาดอย่างน้อย 896 MB หากจอแสดงผลเริ่มต้นใช้ความละเอียดของเฟรมบัฟเฟอร์สูงสุด FHD (เช่น WSXGA+)
-
[7.6.1/H-4-1] หน่วยความจำที่พร้อมให้เคอร์เนลและพื้นที่ผู้ใช้ต้องมีขนาดอย่างน้อย 1344 MB หากจอแสดงผลเริ่มต้นใช้ความละเอียดของเฟรมบัฟเฟอร์สูงสุดถึง QHD (เช่น QWXGA)
หากการใช้งานอุปกรณ์พกพาประกาศว่ารองรับ ABI 64 บิต (มีหรือไม่มี ABI แบบ 32 บิต) ให้ทำดังนี้
-
[7.6.1/H-5-1] หน่วยความจำที่พร้อมให้เคอร์เนลและพื้นที่ผู้ใช้ต้องมีขนาดอย่างน้อย 816 MB หากจอแสดงผลเริ่มต้นใช้ความละเอียดเฟรมบัฟเฟอร์สูงสุดถึง qHD (เช่น FWVGA)
-
[7.6.1/H-6-1] หน่วยความจำที่พร้อมใช้งานสำหรับเคอร์เนลและพื้นที่ผู้ใช้ต้องมีขนาดอย่างน้อย 944 MB หากจอแสดงผลเริ่มต้นใช้ความละเอียดของเฟรมบัฟเฟอร์สูงสุดถึง HD+ (เช่น HD, WSVGA)
-
[7.6.1/H-7-1] หน่วยความจำที่พร้อมให้เคอร์เนลและพื้นที่ผู้ใช้ต้องมีขนาดอย่างน้อย 1280 MB หากจอแสดงผลเริ่มต้นใช้ความละเอียดของเฟรมบัฟเฟอร์สูงสุด FHD (เช่น WSXGA+)
-
[7.6.1/H-8-1] หน่วยความจำที่พร้อมให้เคอร์เนลและพื้นที่ผู้ใช้ต้องมีขนาดอย่างน้อย 1824 MB หากจอแสดงผลเริ่มต้นใช้ความละเอียดของเฟรมบัฟเฟอร์สูงสุดถึง QHD (เช่น QWXGA)
โปรดทราบว่า "หน่วยความจำที่พร้อมใช้งานสำหรับเคอร์เนลและพื้นที่ผู้ใช้" ข้างต้นหมายถึงพื้นที่หน่วยความจำที่มีให้นอกเหนือจากหน่วยความจำที่จัดสรรให้กับส่วนประกอบของฮาร์ดแวร์อยู่แล้ว เช่น วิทยุ วิดีโอ และอื่นๆ ซึ่งไม่อยู่ภายใต้การควบคุมของเคอร์เนลในการใช้งานอุปกรณ์
หากการใช้งานอุปกรณ์พกพามีหน่วยความจำน้อยกว่าหรือเท่ากับ 1 GB สำหรับเคอร์เนลและพื้นที่ผู้ใช้ สิ่งที่จะเกิดขึ้นมีดังนี้
- [7.6.1/H-9-1] ต้องประกาศแฟล็กฟีเจอร์
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 และมีการรองรับโหมด VR ระบบจะดำเนินการดังต่อไปนี้
- [7.9.1/H-1-1] ต้องประกาศแฟล็กฟีเจอร์
android.hardware.vr.high_performance
- [7.9.1/H-1-2] ต้องมีแอปพลิเคชันที่ใช้งาน
android.service.vr.VrListenerService
ซึ่งแอปพลิเคชัน VR เปิดใช้ได้ผ่านandroid.app.Activity#setVrModeEnabled
หากการใช้งานอุปกรณ์พกพามีพอร์ต USB-C อย่างน้อย 1 พอร์ตในโหมดโฮสต์และมีการใช้งาน (คลาสเสียง USB) นอกเหนือจากข้อกำหนดในส่วนที่ 7.7.2 อุปกรณ์เหล่านี้จะมีลักษณะดังนี้
- [7.8.2.2/H-1-1] ต้องระบุการแมปซอฟต์แวร์ต่อไปนี้สำหรับโค้ด HID
การทำงาน | การแมป | บริบท | ลักษณะการทำงาน |
---|---|---|---|
ก |
หน้าการใช้งาน HID: 0x0C การใช้งาน HID: 0x0CD คีย์เคอร์เนล: KEY_PLAYPAUSE คีย์ Android: KEYCODE_MEDIA_PLAY_PAUSE
|
การเล่นสื่อ |
อินพุต: กดสั้น เอาต์พุต: เล่นหรือหยุดชั่วคราว |
อินพุต: กดค้าง เอาต์พุต: เปิดคำสั่งเสียง ส่ง: android.speech.action.VOICE_SEARCH_HANDS_FREE หากอุปกรณ์ล็อกอยู่หรือปิดหน้าจอ ส่งandroid.speech.RecognizerIntent.ACTION_WEB_SEARCH หากไม่มี
|
|||
สายเรียกเข้า |
อินพุต: กดสั้น เอาต์พุต: รับสาย |
||
อินพุต: กดค้าง เอาต์พุต: ปฏิเสธสาย |
|||
สายที่สนทนาอยู่ |
อินพุต: กดสั้น เอาต์พุต: วางสาย |
||
อินพุต: กดค้าง เอาต์พุต: ปิดหรือเปิดเสียงไมโครโฟน |
|||
B |
หน้าการใช้งาน HID: 0x0C การใช้งาน HID: 0x0E9 คีย์เคอร์เนล: KEY_VOLUMEUP คีย์ Android: VOLUME_UP
|
การเล่นสื่อ การโทรที่ดำเนินอยู่ |
อินพุต: กดสั้นหรือค้าง เอาต์พุต: เพิ่มระดับเสียงของระบบหรือชุดหูฟัง |
C |
หน้าการใช้งาน HID: 0x0C การใช้งาน HID: 0x0EA คีย์เคอร์เนล: KEY_VOLUMEDOWN คีย์ Android: VOLUME_DOWN
|
การเล่นสื่อ การโทรที่ดำเนินอยู่ |
อินพุต: กดสั้นหรือค้าง เอาต์พุต: ลดระดับเสียงของระบบหรือชุดหูฟัง |
D |
หน้าการใช้งาน HID: 0x0C การใช้งาน HID: 0x0CF คีย์เคอร์เนล: KEY_VOICECOMMAND คีย์ Android: KEYCODE_VOICE_ASSIST
|
ทั้งหมด ทริกเกอร์ได้ในทุกอินสแตนซ์ |
อินพุต: กดสั้นหรือค้าง เอาต์พุต: เปิดคำสั่งเสียง |
- [7.8.2.2/H-1-2] ต้องเรียกใช้ ACTION_HEADSET_PLUG เมื่อเสียบปลั๊ก แต่เฉพาะหลังจากระบุอินเทอร์เฟซเสียงและปลายทาง USB อย่างถูกต้องเพื่อระบุประเภทของเทอร์มินัลที่เชื่อมต่อแล้ว
เมื่อตรวจพบขั้วปลายสายไฟ USB ประเภท 0x0302 จะเกิดสิ่งต่อไปนี้
- [7.8.2.2/H-2-1] ต้องประกาศ Intent ACTION_HEADSET_PLUG ด้วย "ไมโครโฟน" ตั้งค่าพิเศษเป็น 0
เมื่อตรวจพบขั้วปลายสายไฟ USB ประเภท 0x0402 จะเกิดสิ่งต่อไปนี้
- [7.8.2.2/H-3-1] ต้องประกาศ Intent ACTION_HEADSET_PLUG ด้วย "ไมโครโฟน" ตั้งค่าเพิ่มเติมเป็น 1
เมื่อมีการเรียกใช้ API AudioManager.getDevices() ขณะที่อุปกรณ์ต่อพ่วง USB เชื่อมต่ออยู่
-
[7.8.2.2/H-4-1] ต้องระบุอุปกรณ์ประเภท AudioDeviceInfo.TYPE_USB_HEADSET และบทบาท isSink() หากช่องประเภทขั้วต่อเสียง USB คือ 0x0302
-
[7.8.2.2/H-4-2] ต้องระบุอุปกรณ์ประเภท AudioDeviceInfo.TYPE_USB_HEADSET และบทบาท isSink() หากช่องประเภทขั้วต่อเสียง USB คือ 0x0402
-
[7.8.2.2/H-4-3] ต้องระบุอุปกรณ์ประเภท AudioDeviceInfo.TYPE_USB_HEADSET และบทบาท isSource() หากช่องประเภทเทอร์มินัลเสียง USB คือ 0x0402
-
[7.8.2.2/H-4-4] ต้องระบุอุปกรณ์ประเภท AudioDeviceInfo.TYPE_USB_DEVICE และบทบาท isSink() หากช่องประเภทขั้วต่อเสียง USB คือ 0x603
-
[7.8.2.2/H-4-5] ต้องระบุอุปกรณ์ประเภท AudioDeviceInfo.TYPE_USB_DEVICE และบทบาท isSource() หากช่องประเภทเทอร์มินัลเสียง USB คือ 0x604
-
[7.8.2.2/H-4-6] ต้องระบุอุปกรณ์ประเภท AudioDeviceInfo.TYPE_USB_DEVICE และบทบาท isSink() หากช่องประเภทขั้วต่อเสียง USB คือ 0x400
-
[7.8.2.2/H-4-7] ต้องระบุอุปกรณ์ประเภท AudioDeviceInfo.TYPE_USB_DEVICE และบทบาท isSource() หากช่องประเภทเทอร์มินัลเสียง USB คือ 0x400
-
[7.8.2.2/H-SR] แนะนำอย่างยิ่งเมื่อมีการเชื่อมต่ออุปกรณ์ต่อพ่วงเสียง USB-C เพื่อทำการแจงตัวข้อบ่งชี้ USB, ระบุประเภทเทอร์มินัล และออกอากาศ Intent ACTION_HEADSET_PLUG ในเวลาน้อยกว่า 1, 000 มิลลิวินาที
หากการใช้งานอุปกรณ์พกพามีตัวกระตุ้นการโต้ตอบแบบรู้สึกได้อย่างน้อย 1 ตัว สิ่งที่จะเกิดขึ้นมีดังนี้
- [7.10/H-SR]* แนะนำอย่างยิ่งว่าอย่าใช้มวลการหมุนรอบตัวเอง (ERM) ตัวดำเนินการแบบรู้สึกได้(การสั่น)
- [7.10/H]* ควรวางตำแหน่งของตัวเปิดใช้งานใกล้กับตำแหน่งที่มักถือหรือสัมผัสอุปกรณ์ด้วยมือ
- [7.10/H-SR]* ขอแนะนำอย่างยิ่งให้ปรับใช้ค่าคงที่สาธารณะทั้งหมดเพื่อการโต้ตอบการสัมผัสที่ชัดเจนใน android.view.HapticFeedbackConstantsonstants ใน android.view.HapticFeedbackConstantsonstants ใน android.view.HapticFeedbackConstantsonstants ใน android.view.HapticFeedbackConstantsonstants ใน android.view.HapticFeedbackConstantsonstants ใน android.view.HapticFeedbackConstantsonstants ควรใช้ค่าคงที่สาธารณะ ค่าคงที่สาธารณะทั้งหมด ค่าคงที่สาธารณะ ให้ค่าคงที่สาธารณะ ให้การรับสัมผัสที่ชัดเจน ใน android.view.HapticFeedbackConstantsonstants (สำหรับ android.view.HapticFeedbackConstantsonstants (สำหรับ android.view.HapticFeedbackConstantsonstants) (CLOCK_TICK, CONTEXT_CLICK, KEYBOARD_PRESS, G ขอ
- [7.10/H-SR]* ขอแนะนําอย่างยิ่งให้ใช้ค่าคงที่สาธารณะทั้งหมดสําหรับการโต้ตอบการสัมผัสที่ชัดเจนใน android.os.VibrationEffect ซึ่งได้แก่ (EFFECT_TICK, EFFECT_CLICK, EFFECT_HEAVY_CLICK และ EFFECT_DOUBLE_CLICK) และ cipection แบบไร้รอยต่อ
- [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)
การใช้งานอุปกรณ์มือถือต้องรองรับรูปแบบการเข้ารหัสวิดีโอต่อไปนี้ และทำให้ใช้งานกับแอปพลิเคชันของบุคคลที่สามได้
การใช้งานอุปกรณ์มือถือต้องรองรับรูปแบบการถอดรหัสวิดีโอต่อไปนี้ และทำให้ใช้งานกับแอปพลิเคชันของบุคคลที่สามได้
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 และมอบโอกาสในการเข้าถึงข้อมูลผู้ให้บริการเอกสารโดยใช้ APIDocumentsProvider
- [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] แนะนำอย่างยิ่งให้ใช้ Launcher เริ่มต้นที่รองรับการปักหมุดทางลัด วิดเจ็ต และ WidgetFeatures ในแอป
- [3.8.1/H-SR] แนะนำอย่างยิ่งให้ใช้ Launcher เริ่มต้นที่ให้การเข้าถึงด่วนสำหรับทางลัดเพิ่มเติมที่มาจากแอปของบุคคลที่สามผ่าน 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]* ต้องแสดงการแจ้งเตือนการสนทนาก่อนการแจ้งเตือนที่ไม่ใช่การสนทนา ยกเว้นการแจ้งเตือนบริการที่ทำงานอยู่เบื้องหน้าและการแจ้งเตือนสำคัญ:สูง
การใช้งานอุปกรณ์มือถือ Android รองรับหน้าจอล็อกจะส่งผลดังนี้
- [3.8.10/H-1-1] ต้องแสดงการแจ้งเตือนในหน้าจอล็อก รวมถึงเทมเพลตการแจ้งเตือนสื่อ
หากการใช้งานอุปกรณ์พกพารองรับหน้าจอล็อกที่ปลอดภัย สิ่งที่จะเกิดขึ้นมีดังนี้
- [3.9/H-1-1] ต้องใช้นโยบายการดูแลระบบอุปกรณ์ทั้งหมดที่กำหนดไว้ในเอกสาร Android SDK
- [3.9/H-1-2] ต้องประกาศการรองรับโปรไฟล์ที่มีการจัดการผ่านแฟล็กฟีเจอร์
android.software.managed_users
ยกเว้นเมื่อกำหนดค่าอุปกรณ์ให้รายงานว่าเป็นอุปกรณ์ที่มี RAM ต่ำ หรือเพื่อจัดสรรพื้นที่เก็บข้อมูลภายใน (แบบถอดไม่ได้) เป็นพื้นที่เก็บข้อมูลที่ใช้ร่วมกัน
หากการใช้งานอุปกรณ์พกพารวมถึงการรองรับ API ของ ControlsProviderService
และ Control
และอนุญาตให้แอปพลิเคชันของบุคคลที่สามเผยแพร่ระบบควบคุมอุปกรณ์ ระบบจะดำเนินการต่อไปนี้
- [3.8.16/H-1-1] ต้องประกาศแฟล็กฟีเจอร์
android.software.controls
และตั้งค่าเป็นtrue
- [3.8.16/H-1-2] ต้องระบุความสามารถในการเพิ่ม แก้ไข เลือก และใช้งานระบบควบคุมอุปกรณ์ที่ผู้ใช้ชื่นชอบจากการควบคุมที่ลงทะเบียนโดยแอปพลิเคชันบุคคลที่สามผ่าน
ControlsProviderService
และControl
API - [3.8.16/H-1-3] ต้องให้สิทธิ์เข้าถึงแก่ผู้ใช้รายนี้ภายใน 3 การโต้ตอบจาก Launcher เริ่มต้น
- [3.8.16/H-1-4] ต้องแสดงผลในผู้ใช้รายนี้อย่างถูกต้องตามชื่อและไอคอนของแอปบุคคลที่สามแต่ละแอปที่แสดงการควบคุมผ่าน
ControlsProviderService
API รวมถึงช่องที่ระบุโดย API ของControl
ในทางตรงกันข้าม หากใช้อุปกรณ์พกพาไม่ได้ใช้การควบคุมดังกล่าว จะมีผลดังนี้
- [3.8.16/H-2-1] ต้องรายงาน
null
สำหรับControlsProviderService
และ API ของ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] โซนการจดจำท่าทางสัมผัสสำหรับฟังก์ชัน Home ควรสูงจากด้านล่างของหน้าจอไม่เกิน 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/วินาที
- [8.2/H-0-2] ต้องตรวจสอบประสิทธิภาพการเขียนแบบสุ่มอย่างน้อย 0.5 MB/วินาที
- [8.2/H-0-3] ต้องมีประสิทธิภาพการอ่านตามลำดับอย่างน้อย 15 MB/วินาที
- [8.2/H-0-4] ต้องตรวจสอบประสิทธิภาพการอ่านแบบสุ่มอย่างน้อย 3.5 MB/วินาที
หากการใช้งานอุปกรณ์เคลื่อนที่มีฟีเจอร์ที่ช่วยปรับปรุงการจัดการพลังงานของอุปกรณ์ซึ่งรวมอยู่ใน AOSP หรือขยายขอบเขตของฟีเจอร์ที่รวมอยู่ใน AOSP ฟีเจอร์ดังกล่าวจะมีลักษณะดังนี้
- [8.3/H-1-1] ต้องให้เงินแก่ผู้ใช้ในการเปิดและปิดใช้ฟีเจอร์โหมดประหยัดแบตเตอรี่
- [8.3/H-1-2] ต้องมีเงินเพียงพอในการแสดงแอปทั้งหมดที่ได้รับการยกเว้นจากโหมดสแตนด์บายแอปและโหมดประหยัดพลังงานของ Doze
การใช้งานอุปกรณ์เคลื่อนที่
- [8.4/H-0-1] ต้องระบุโปรไฟล์พลังงานต่อองค์ประกอบที่กำหนดค่าการใช้งานปัจจุบันสำหรับส่วนประกอบของฮาร์ดแวร์แต่ละอย่างและการสิ้นเปลืองแบตเตอรี่โดยประมาณที่เกิดจากส่วนประกอบในช่วงเวลาต่างๆ ตามที่ระบุไว้ในเว็บไซต์โครงการโอเพนซอร์ส Android
- [8.4/H-0-2] ต้องรายงานค่าการใช้พลังงานทั้งหมดในหน่วยมิลลิแอมแปร์ (mAh)
- [8.4/H-0-3] ต้องรายงานการใช้พลังงานของ CPU ต่อ UID ของกระบวนการแต่ละรายการ โครงการโอเพนซอร์ส Android มีคุณสมบัติตรงตามข้อกำหนดผ่านการใช้งานโมดูลเคอร์เนลของ
uid_cputime
- [8.4/H-0-4] ต้องให้นักพัฒนาแอปเข้าถึงการใช้พลังงานนี้ผ่านทางคำสั่ง Shell
adb shell dumpsys batterystats
- [8.4/H] ควรระบุแหล่งที่มาให้กับคอมโพเนนต์ฮาร์ดแวร์เองหากไม่สามารถระบุการใช้พลังงานของคอมโพเนนต์ฮาร์ดแวร์ไปยังแอปพลิเคชัน
การใช้งานอุปกรณ์พกพารวมถึงหน้าจอหรือเอาต์พุตวิดีโอจะส่งผลดังนี้
- [8.4/H-1-1] ต้องเป็นไปตาม Intent ของ
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]* ต้องสำรองข้อมูลการใช้งานคีย์สโตร์ด้วยสภาพแวดล้อมการดำเนินการแบบแยกต่างหาก
- [9.11/H-0-3]* ต้องมีการใช้งานอัลกอริทึมการเข้ารหัส RSA, AES, ECDSA และ HMAC รวมถึงฟังก์ชันแฮชแบบครอบครัว MD5, SHA1 และ SHA-2 เพื่อให้รองรับอัลกอริทึมที่รองรับของระบบคีย์สโตร์ Android อย่างเหมาะสมในพื้นที่ที่แยกออกจากโค้ดที่ทำงานในเคอร์เนลขึ้นไปอย่างปลอดภัย การแยกที่ปลอดภัยต้องบล็อกกลไกที่เป็นไปได้ทั้งหมดที่โค้ดเคอร์เนลหรือรหัสพื้นที่ผู้ใช้อาจเข้าถึงสถานะภายในของสภาพแวดล้อมที่แยกไว้ ซึ่งรวมถึง DMA โปรเจ็กต์โอเพนซอร์ส Android ต้นทาง (AOSP) เป็นไปตามข้อกำหนดนี้โดยใช้การติดตั้งใช้งาน Trusty แต่โซลูชันอื่นที่ใช้ ARM TrustZone หรือการใช้งานที่ปลอดภัยของบุคคลที่สามผ่านการตรวจสอบของการแยกที่อิงตามไฮเปอร์ไวเซอร์ที่เหมาะสมเป็นตัวเลือกอื่น
- [9.11/H-0-4]* ต้องดำเนินการตรวจสอบสิทธิ์หน้าจอล็อกในสภาพแวดล้อมการดำเนินการแบบแยกต่างหาก และอนุญาตให้ใช้คีย์ที่เชื่อมโยงกับการตรวจสอบสิทธิ์ได้ก็ต่อเมื่อทำสำเร็จเท่านั้น ข้อมูลเข้าสู่ระบบสำหรับหน้าจอล็อกต้องจัดเก็บไว้ในรูปแบบที่อนุญาตให้เฉพาะสภาพแวดล้อมการดำเนินการที่แยกต่างหากเท่านั้น จึงจะตรวจสอบสิทธิ์หน้าจอล็อกได้ โปรเจ็กต์โอเพนซอร์ส Android มอบ Gatekeeper hardware Abstraction Layer (HAL) และ Trusty ซึ่งสามารถนำไปใช้ตามข้อกำหนดนี้ได้
- [9.11/H-0-5]* ต้องรองรับเอกสารรับรองคีย์เมื่อคีย์การรับรองได้รับการป้องกันโดยฮาร์ดแวร์ที่ปลอดภัยและมีการรับรองในฮาร์ดแวร์ที่ปลอดภัย ต้องมีการแชร์คีย์การรับรองเอกสารรับรองกับอุปกรณ์จำนวนมากเพื่อป้องกันไม่ให้คีย์ใช้เป็นตัวระบุอุปกรณ์ วิธีหนึ่งที่จะทำให้เป็นไปตามข้อกำหนดนี้คือการแชร์คีย์เอกสารรับรองเดียวกัน เว้นแต่ว่าจะมีการผลิตอย่างน้อย 100,000 หน่วยของ SKU ที่ระบุ หากผลิต SKU มากกว่า 100,000 หน่วย อาจใช้คีย์ที่แตกต่างกันสำหรับแต่ละ 100,000 หน่วย
โปรดทราบว่าหากมีการใช้อุปกรณ์ใน Android เวอร์ชันก่อนหน้าแล้ว อุปกรณ์ดังกล่าวจะได้รับการยกเว้นจากข้อกำหนดในการมีคีย์สโตร์ที่สนับสนุนโดยสภาพแวดล้อมการดำเนินการแบบแยกต่างหากและรองรับเอกสารรับรองคีย์ เว้นแต่ว่าจะประกาศฟีเจอร์ android.hardware.fingerprint
ซึ่งต้องใช้คีย์สโตร์ที่ได้รับการสนับสนุนโดยสภาพแวดล้อมการดำเนินการที่แยกต่างหาก
การใช้งานอุปกรณ์เคลื่อนที่ที่รองรับหน้าจอล็อกที่ปลอดภัยจะส่งผลดังนี้
- [9.11/H-1-1] ต้องอนุญาตให้ผู้ใช้เลือกระยะหมดเวลาสลีปที่สั้นที่สุด นั่นคือเวลาเปลี่ยนจากการปลดล็อกมาเป็นสถานะล็อก ซึ่งต้องไม่เกิน 15 วินาที
- [9.11/H-1-2] ต้องให้สิทธิ์เข้าถึงแก่ผู้ใช้ในการซ่อนการแจ้งเตือนและปิดใช้การตรวจสอบสิทธิ์ทุกรูปแบบ ยกเว้นการตรวจสอบสิทธิ์หลักที่อธิบายไว้ในหน้าจอล็อกที่ปลอดภัยใน 9.11.1 AOSP มีคุณสมบัติตรงตามข้อกำหนดเป็นโหมดปิดล็อก
หากการใช้งานอุปกรณ์พกพามีผู้ใช้หลายราย และไม่ได้ประกาศ Flag ฟีเจอร์ android.hardware.telephony
สิ่งที่จะเกิดขึ้นมีดังนี้
- [9.5/H-2-1] ต้องรองรับโปรไฟล์ที่ถูกจำกัด ซึ่งเป็นฟีเจอร์ที่ช่วยให้เจ้าของอุปกรณ์จัดการผู้ใช้เพิ่มเติมและความสามารถของผู้ใช้ในอุปกรณ์ได้ โปรไฟล์ที่จำกัดช่วยให้เจ้าของอุปกรณ์สามารถตั้งค่าสภาพแวดล้อมแยกต่างหากเพื่อให้ผู้ใช้อื่นทำงานได้ด้วย พร้อมกับจัดการข้อจำกัดที่ละเอียดขึ้นในแอปที่พร้อมใช้งานในสภาพแวดล้อมเหล่านั้น
หากการใช้งานอุปกรณ์พกพามีผู้ใช้หลายคนและประกาศ Flag ฟีเจอร์ android.hardware.telephony
สิ่งที่จะเกิดขึ้นมีดังนี้
- [9.5/H-3-1] ต้องไม่รองรับโปรไฟล์ที่จำกัด แต่ต้องสอดคล้องกับการใช้ตัวควบคุม AOSP เพื่อเปิด /ปิดใช้ผู้ใช้รายอื่นไม่ให้เข้าถึงการโทรและ SMS
2.2.6 เครื่องมือสำหรับนักพัฒนาซอฟต์แวร์และความเข้ากันได้ของตัวเลือก
การใช้งานอุปกรณ์เคลื่อนที่ (* ใช้ไม่ได้กับแท็บเล็ต):
- [6.1/H-0-1]* ต้องรองรับคำสั่ง Shell
cmd testharness
การใช้งานอุปกรณ์เคลื่อนที่ (* ใช้ไม่ได้กับแท็บเล็ต):
-
Perfetto
- [6.1/H-0-2]* ต้องแสดงไบนารี
/system/bin/perfetto
แก่ผู้ใช้ Shell ที่ cmdline เป็นไปตามเอกสารประกอบที่เกี่ยวข้อง - [6.1/H-0-3]* ไบนารี Perfetto ต้องยอมรับเป็นอินพุตการกำหนดค่า Protobuf ที่สอดคล้องกับสคีมาที่ระบุไว้ในเอกสารประกอบ Perfetto
- [6.1/H-0-4]* ไบนารี Perfetto ต้องเขียนเป็นเอาต์พุตของการติดตาม Protobuf ที่สอดคล้องกับสคีมาที่ระบุไว้ในเอกสารประกอบของ Perfetto
- [6.1/H-0-5]* ต้องระบุแหล่งข้อมูลที่อธิบายไว้ในเอกสารประกอบ Perfetto ผ่านไบนารี Perfetto
- [6.1/H-0-6]* ต้องเปิดใช้ Daemon ที่ติดตาม Perfetto โดยค่าเริ่มต้น (คุณสมบัติของระบบ
persist.traced.enable
)
- [6.1/H-0-2]* ต้องแสดงไบนารี
2.2.7 ชั้นเรียนประสิทธิภาพของสื่อแบบมือถือ
ดูคำจำกัดความของคลาสประสิทธิภาพของสื่อในส่วน 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 เฟรมต่อวินาที
- [5.1/H-1-3] ต้องโฆษณาโปรแกรมเปลี่ยนไฟล์วิดีโอฮาร์ดแวร์ถึงจำนวนสูงสุด
เซสชันที่สามารถทำงานพร้อมกันในชุดค่าผสมตัวแปลงรหัสใดก็ได้ผ่าน
CodecCapabilities.getMaxSupportedInstances()
และVideoCapabilities.getSupportedPerformancePoints()
เมธอด - [5.1/H-1-4] ต้องรองรับเซสชันโปรแกรมเปลี่ยนไฟล์วิดีโอฮาร์ดแวร์ 6 อินสแตนซ์ (AVC หรือ HEVC) ในชุดค่าผสมตัวแปลงรหัสใดก็ได้ที่ทำงานพร้อมกันที่ 720p ความละเอียด@30 เฟรมต่อวินาที
- [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 หรือต่ำกว่าสำหรับโปรแกรมเปลี่ยนไฟล์เสียงทั้งหมด ภายใต้load.Load ในที่นี้ หมายถึงระดับวิดีโอแบบ 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 128 Kbps
- [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] ต้องมีกล้องหลังตัวหลักที่มีความละเอียดอยู่ที่ รองรับการจับภาพวิดีโอที่ 4k@30fps อย่างน้อย 12 ล้านพิกเซล องค์ประกอบหลัก กล้องหลังคือกล้องหลังที่มีรหัสกล้องต่ำสุด
- [7.5/H-1-2] ต้องมีกล้องหน้าหลักที่มีความละเอียดอยู่ที่ และรองรับการบันทึกวิดีโอที่ 1080p@30fps อย่างน้อย 4 เมกะพิกเซล องค์ประกอบหลัก กล้องหน้าคือกล้องหน้าที่มีรหัสกล้องต่ำสุด
- [7.5/H-1-3] ต้องรองรับพร็อพเพอร์ตี้ android.info.supportedSupportLevel ในฐานะ เต็มรูปแบบหรือดีกว่าสำหรับรายการหลักแบบกลับ และ LIMITED หรือดีกว่าสำหรับด้านหน้าหลัก กล้อง
- [7.5/H-1-4] ต้องรองรับ CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME สำหรับกล้องหลักทั้ง 2 ตัว
- [7.5/H-1-5] ต้องมีเวลาในการตอบสนองของการบันทึกภาพ Camera2 JPEG < 1000 มิลลิวินาทีสำหรับ ความละเอียด 1080p ตามที่วัดโดย PerformanceTest สำหรับกล้อง CTS ภายใต้ สภาพแสงของ ITS (3,000K) สำหรับกล้องหลักทั้ง 2 ตัว
- [7.5/H-1-6] ต้องมีเวลาในการตอบสนองเริ่มต้น Camera2 (เปิดกล้องเพื่อดูตัวอย่างแรก เฟรม) < 600 มิลลิวินาทีตามที่วัดโดย PerformanceTest ของกล้อง CTS ภายใต้ 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/วินาที
- [8.2/H-1-2] ต้องตรวจสอบประสิทธิภาพการเขียนแบบสุ่มอย่างน้อย 10 MB/วินาที
- [8.2/H-1-3] ต้องมีประสิทธิภาพการอ่านตามลำดับอย่างน้อย 200 MB/วินาที
- [8.2/H-1-4] ต้องตรวจสอบประสิทธิภาพการอ่านแบบสุ่มอย่างน้อย 25 MB/วินาที
2.3 ข้อกำหนดสำหรับโทรทัศน์
อุปกรณ์ Android TV หมายถึงการใช้งานอุปกรณ์ Android ที่เป็นอินเทอร์เฟซความบันเทิงสำหรับการบริโภคสื่อดิจิทัล ภาพยนตร์ เกม แอป และ/หรือรายการทีวีสดสำหรับผู้ใช้ที่อยู่ห่างออกไปประมาณ 10 ฟุต ("อินเทอร์เฟซผู้ใช้หลังเอนหลัง" หรือ "อินเทอร์เฟซผู้ใช้ 10 ฟุต")
การใช้งานอุปกรณ์ Android จัดเป็นทีวีหากเป็นไปตามเกณฑ์ต่อไปนี้ทั้งหมด
- มีกลไกในการควบคุมอินเทอร์เฟซผู้ใช้ที่แสดงผลจากระยะไกลบนจอแสดงผลที่สามารถอยู่ห่างจากผู้ใช้ 10 ฟุต
- มีจอแสดงผลแบบฝังที่มีความยาวแนวทแยงมากกว่า 24 นิ้ว หรือใส่พอร์ตเอาต์พุตวิดีโอ เช่น VGA, HDMI, DisplayPort หรือพอร์ตไร้สายสำหรับแสดงผล
ข้อกำหนดเพิ่มเติมในส่วนอื่นของส่วนนี้เกี่ยวข้องกับการใช้งานอุปกรณ์ Android TV เท่านั้น
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 ขึ้นไปบนหน้าจอขนาดใหญ่พิเศษ
โปรดทราบว่า "หน่วยความจำที่พร้อมใช้งานสำหรับเคอร์เนลและพื้นที่ผู้ใช้" ข้างต้นหมายถึงพื้นที่หน่วยความจำที่มีให้นอกเหนือจากหน่วยความจำที่จัดสรรให้กับส่วนประกอบของฮาร์ดแวร์อยู่แล้ว เช่น วิทยุ วิดีโอ และอื่นๆ ซึ่งไม่อยู่ภายใต้การควบคุมของเคอร์เนลในการใช้งานอุปกรณ์
การติดตั้งใช้งานอุปกรณ์ทีวี
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.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 เฟรมต่อวินาทีเมื่อใช้โปรไฟล์หลักระดับสูง
- [5.3.1/T-1-2] HD 1080i ที่ 59.94 เฟรมต่อวินาทีเมื่อใช้โปรไฟล์หลักระดับสูง วิดีโอ MPEG-2 ที่มีการสอดประสานและต้องใช้งานบนแอปพลิเคชันของบุคคลที่สามได้
การใช้งานอุปกรณ์โทรทัศน์ต้องรองรับการถอดรหัส H.264 ตามที่อธิบายไว้ในส่วนที่ 5.3.4 ที่อัตราเฟรมและความละเอียดวิดีโอมาตรฐานสูงสุดและรวมถึง
- [5.3.4/T-1-1] HD 1080p ที่ 60 ภาพต่อวินาทีด้วยโปรไฟล์พื้นฐาน
- [5.3.4/T-1-2] HD 1080p ที่ 60 ภาพต่อวินาทีด้วยโปรไฟล์หลัก
- [5.3.4/T-1-3] HD 1080p ที่ 60 ภาพต่อวินาทีด้วย High Profile ระดับ 4.2
การใช้อุปกรณ์โทรทัศน์ที่ใช้ตัวถอดรหัสฮาร์ดแวร์ H.265 ต้องรองรับการถอดรหัส H.265 ตามที่อธิบายไว้ในส่วน 5.3.5 ที่อัตราเฟรมและความละเอียดวิดีโอมาตรฐานสูงสุด รวมถึงรายการต่อไปนี้
- [5.3.5/T-1-1] HD 1080p ที่ 60 ภาพต่อวินาทีด้วยโปรไฟล์หลักระดับ 4.1
หากอุปกรณ์ทีวีที่ใช้ตัวถอดรหัสฮาร์ดแวร์ H.265 รองรับการถอดรหัส H.265 และโปรไฟล์การถอดรหัส UHD อุปกรณ์เหล่านี้จะมีลักษณะดังนี้
- [5.3.5/T-2-1] ต้องรองรับโปรไฟล์การถอดรหัส UHD ที่ 60 เฟรมต่อวินาทีด้วยโปรไฟล์ Main Tier หลัก 10 ระดับ 5
การใช้งานอุปกรณ์โทรทัศน์ต้องรองรับการถอดรหัส VP8 ตามรายละเอียดในส่วนที่ 5.3.6 ที่อัตราเฟรมและความละเอียดวิดีโอมาตรฐานสูงสุดและรวมถึง
- [5.3.6/T-1-1] โปรไฟล์การถอดรหัสแบบ HD 1080p ที่ 60 เฟรมต่อวินาที
การใช้อุปกรณ์โทรทัศน์ที่ใช้ตัวถอดรหัสฮาร์ดแวร์ VP9 ต้องรองรับการถอดรหัส VP9 ตามที่อธิบายไว้ในส่วน 5.3.7 ที่อัตราเฟรมวิดีโอมาตรฐานและความละเอียดสูงสุด รวมถึงสิ่งต่อไปนี้
- [5.3.7/T-1-1] HD 1080p ที่ 60 เฟรมต่อวินาทีพร้อมโปรไฟล์ 0 (ความลึกของสี 8 บิต)
หากอุปกรณ์โทรทัศน์ที่ใช้ตัวถอดรหัสฮาร์ดแวร์ VP9 รองรับการถอดรหัส VP9 และโปรไฟล์การถอดรหัส UHD อุปกรณ์เหล่านั้นจะมีลักษณะดังนี้
- [5.3.7/T-2-1] ต้องรองรับโปรไฟล์การถอดรหัส UHD ที่ 60 เฟรมต่อวินาทีด้วยโปรไฟล์ 0 (ความลึกของสี 8 บิต)
- [5.3.7/T-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 เป็น 50 Hz หรือ 60 Hz ขึ้นอยู่กับอัตราการรีเฟรชวิดีโอสําหรับภูมิภาคที่ขายอุปกรณ์
หากอุปกรณ์ทีวีไม่มีจอแสดงผลในตัว แต่รองรับจอแสดงผลภายนอกที่เชื่อมต่อผ่าน HDMI แทน ระบบจะดำเนินการดังต่อไปนี้
- [5.8/T-1-1] ต้องรองรับ HDCP 2.2
หากอุปกรณ์ทีวีไม่รองรับการถอดรหัส UHD แต่รองรับจอแสดงผลภายนอกที่เชื่อมต่อผ่าน HDMI แทน ระบบจะดำเนินการดังต่อไปนี้
- [5.8/T-2-1] ต้องรองรับ HDCP 1.4
2.3.3 ซอฟต์แวร์
การติดตั้งใช้งานอุปกรณ์ทีวี
- [3/T-0-1] ต้องประกาศฟีเจอร์
android.software.leanback
และandroid.hardware.type.television
- [3.2.3.1/T-0-1] ต้องโหลดแอปพลิเคชันหรือคอมโพเนนต์บริการอย่างน้อย 1 รายการด้วยเครื่องจัดการ Intent สำหรับรูปแบบตัวกรอง Intent สาธารณะทั้งหมดที่กำหนดโดย Intent ของแอปพลิเคชันต่อไปนี้ซึ่งแสดงไว้ที่นี่
- [3.4.1/T-0-1] ต้องติดตั้งใช้งาน
android.webkit.Webview
API โดยสมบูรณ์
หากใช้งานอุปกรณ์ Android TV รองรับหน้าจอล็อก สิ่งที่จะเกิดขึ้นมีดังนี้
- [3.8.10/T-1-1] ต้องแสดงการแจ้งเตือนในหน้าจอล็อก รวมถึงเทมเพลตการแจ้งเตือนสื่อ
การติดตั้งใช้งานอุปกรณ์ทีวี
- [3.8.14/T-SR] ขอแนะนำอย่างยิ่งให้รองรับหลายหน้าต่างในโหมดการแสดงภาพซ้อนภาพ (PIP)
- [3.10/T-0-1] ต้องรองรับบริการการช่วยเหลือพิเศษของบุคคลที่สาม
- [3.10/T-SR] ขอแนะนำอย่างยิ่งให้โหลดบริการการช่วยเหลือพิเศษล่วงหน้าในอุปกรณ์เทียบเท่ากับหรือเกินฟังก์ชันของการเข้าถึงด้วยสวิตช์และ TalkBack (สำหรับภาษาที่รองรับโดยเครื่องมืออ่านออกเสียงข้อความที่ติดตั้งไว้ล่วงหน้า) ตามที่ระบุไว้ในโปรเจ็กต์โอเพนซอร์ส TalkBack
หากการใช้งานอุปกรณ์ทีวีรายงานฟีเจอร์ android.hardware.audio.output
อุปกรณ์เหล่านั้นจะมีลักษณะดังนี้
- [3.11/T-SR] ขอแนะนำอย่างยิ่งให้รวมเครื่องมือ TTS ที่รองรับภาษาที่พร้อมใช้งานในอุปกรณ์
- [3.11/T-1-1] ต้องรองรับการติดตั้งเครื่องมือ TTS ของบุคคลที่สาม
การติดตั้งใช้งานอุปกรณ์ทีวี
- [3.12/T-0-1] ต้องรองรับเฟรมเวิร์กอินพุตทีวี
2.3.4 ประสิทธิภาพและศักยภาพ
- [8.1/T-0-1] เวลาในการตอบสนองเฟรมที่สม่ำเสมอ เวลาในการตอบสนองเฟรมไม่สอดคล้องกันหรือการหน่วงเวลาในการแสดงผลเฟรมต้องไม่เกิดขึ้นบ่อยเกินกว่า 5 เฟรมในวินาที และควรต่ำกว่า 1 เฟรมในวินาที
- [8.2/T-0-1] ต้องตรวจสอบประสิทธิภาพการเขียนตามลำดับอย่างน้อย 5 MB/วินาที
- [8.2/T-0-2] ต้องตรวจสอบประสิทธิภาพการเขียนแบบสุ่มอย่างน้อย 0.5 MB/วินาที
- [8.2/T-0-3] ต้องตรวจสอบประสิทธิภาพการอ่านตามลำดับอย่างน้อย 15 MB/วินาที
- [8.2/T-0-4] ต้องตรวจสอบประสิทธิภาพการอ่านแบบสุ่มอย่างน้อย 3.5 MB/วินาที
หากการใช้งานอุปกรณ์ทีวีมีฟีเจอร์ที่ช่วยปรับปรุงการจัดการพลังงานของอุปกรณ์ซึ่งรวมอยู่ใน AOSP หรือขยายฟีเจอร์ที่รวมอยู่ใน AOSP ฟีเจอร์ดังกล่าวจะมีลักษณะดังนี้
- [8.3/T-1-1] ต้องให้เงินแก่ผู้ใช้ในการเปิดและปิดใช้ฟีเจอร์โหมดประหยัดแบตเตอรี่
สิ่งที่จะเกิดขึ้นหากการใช้งานอุปกรณ์ทีวีไม่มีแบตเตอรี่มีดังนี้
- [8.3/T-1-2] ต้องลงทะเบียนอุปกรณ์เป็นอุปกรณ์แบบไม่ใช้แบตเตอรี่ตามที่อธิบายไว้ในหัวข้อการรองรับอุปกรณ์แบบใช้แบตเตอรี่
สิ่งที่จะเกิดขึ้นหากการใช้งานอุปกรณ์ทีวีมีแบตเตอรี่มีดังนี้
- [8.3/T-1-3] ต้องมีเงินเพียงพอในการแสดงแอปทั้งหมดที่ได้รับการยกเว้นจากโหมดสแตนด์บายแอปและโหมดประหยัดพลังงานของ Doze
การติดตั้งใช้งานอุปกรณ์ทีวี
- [8.4/T-0-1] ต้องระบุโปรไฟล์พลังงานต่อคอมโพเนนต์ที่กำหนดค่าการใช้งานปัจจุบันสำหรับส่วนประกอบของฮาร์ดแวร์แต่ละอย่างและการสิ้นเปลืองแบตเตอรี่โดยประมาณที่เกิดจากส่วนประกอบในช่วงเวลาต่างๆ ตามที่ระบุไว้ในเว็บไซต์โครงการโอเพนซอร์ส Android
- [8.4/T-0-2] ต้องรายงานค่าการใช้พลังงานทั้งหมดในหน่วยมิลลิแอมแปร์ (mAh)
- [8.4/T-0-3] ต้องรายงานการใช้พลังงานของ CPU ต่อ UID ของกระบวนการแต่ละรายการ โครงการโอเพนซอร์ส Android มีคุณสมบัติตรงตามข้อกำหนดผ่านการใช้งานโมดูลเคอร์เนลของ
uid_cputime
- [8.4/T] ควรมีการระบุแหล่งที่มาให้กับคอมโพเนนต์ฮาร์ดแวร์เองหากไม่สามารถระบุการใช้พลังงานของคอมโพเนนต์ฮาร์ดแวร์ไปยังแอปพลิเคชัน
- [8.4/T-0-4] ต้องให้นักพัฒนาแอปเข้าถึงการใช้พลังงานนี้ผ่านทางคำสั่ง Shell
adb shell dumpsys batterystats
2.3.5 โมเดลการรักษาความปลอดภัย
การติดตั้งใช้งานอุปกรณ์ทีวี
- [9.11/T-0-1] ต้องสำรองข้อมูลการใช้งานคีย์สโตร์ด้วยสภาพแวดล้อมการดำเนินการแบบแยกต่างหาก
- [9.11/T-0-2] ต้องมีการใช้งานอัลกอริทึมการเข้ารหัส RSA, AES, ECDSA และ HMAC รวมถึงฟังก์ชันแฮชของครอบครัว MD5, SHA1 และ SHA-2 เพื่อให้รองรับอัลกอริทึมที่รองรับของระบบคีย์สโตร์ Android อย่างเหมาะสมในพื้นที่ที่แยกออกจากโค้ดที่ทำงานในเคอร์เนลขึ้นไปอย่างปลอดภัย การแยกที่ปลอดภัยต้องบล็อกกลไกที่เป็นไปได้ทั้งหมดที่โค้ดเคอร์เนลหรือรหัสพื้นที่ผู้ใช้อาจเข้าถึงสถานะภายในของสภาพแวดล้อมที่แยกไว้ ซึ่งรวมถึง DMA โปรเจ็กต์โอเพนซอร์ส Android ต้นทาง (AOSP) เป็นไปตามข้อกำหนดนี้โดยใช้การติดตั้งใช้งาน Trusty แต่โซลูชันอื่นที่ใช้ ARM TrustZone หรือการใช้งานที่ปลอดภัยของบุคคลที่สามผ่านการตรวจสอบของการแยกที่อิงตามไฮเปอร์ไวเซอร์ที่เหมาะสมเป็นตัวเลือกอื่น
- [9.11/T-0-3] ต้องดำเนินการตรวจสอบสิทธิ์หน้าจอล็อกในสภาพแวดล้อมการดำเนินการที่แยกต่างหาก และอนุญาตให้ใช้คีย์ที่ผูกกับการตรวจสอบสิทธิ์ได้ก็ต่อเมื่อดำเนินการสำเร็จเท่านั้น ข้อมูลเข้าสู่ระบบสำหรับหน้าจอล็อกต้องจัดเก็บไว้ในรูปแบบที่อนุญาตให้เฉพาะสภาพแวดล้อมการดำเนินการที่แยกต่างหากเท่านั้น จึงจะตรวจสอบสิทธิ์หน้าจอล็อกได้ โปรเจ็กต์โอเพนซอร์ส Android มอบ Gatekeeper hardware Abstraction Layer (HAL) และ Trusty ซึ่งสามารถนำไปใช้ตามข้อกำหนดนี้ได้
- [9.11/T-0-4] ต้องรองรับเอกสารรับรองคีย์เมื่อคีย์การรับรองได้รับการป้องกันโดยฮาร์ดแวร์ที่ปลอดภัยและมีการรับรองในฮาร์ดแวร์ที่ปลอดภัย ต้องมีการแชร์คีย์การรับรองเอกสารรับรองกับอุปกรณ์จำนวนมากเพื่อป้องกันไม่ให้คีย์ใช้เป็นตัวระบุอุปกรณ์ วิธีหนึ่งที่จะทำให้เป็นไปตามข้อกำหนดนี้คือการแชร์คีย์เอกสารรับรองเดียวกัน เว้นแต่ว่าจะมีการผลิตอย่างน้อย 100,000 หน่วยของ SKU ที่ระบุ หากผลิต SKU มากกว่า 100,000 หน่วย อาจใช้คีย์ที่แตกต่างกันสำหรับแต่ละ 100,000 หน่วย
โปรดทราบว่าหากมีการใช้อุปกรณ์ใน Android เวอร์ชันก่อนหน้าแล้ว อุปกรณ์ดังกล่าวจะได้รับการยกเว้นจากข้อกำหนดในการมีคีย์สโตร์ที่สนับสนุนโดยสภาพแวดล้อมการดำเนินการแบบแยกต่างหากและรองรับเอกสารรับรองคีย์ เว้นแต่ว่าจะประกาศฟีเจอร์ android.hardware.fingerprint
ซึ่งต้องใช้คีย์สโตร์ที่ได้รับการสนับสนุนโดยสภาพแวดล้อมการดำเนินการที่แยกต่างหาก
หากการใช้งานอุปกรณ์ทีวีรองรับหน้าจอล็อกที่ปลอดภัย สิ่งที่จะเกิดขึ้นมีดังนี้
- [9.11/T-1-1] ต้องอนุญาตให้ผู้ใช้เลือกระยะหมดเวลาสลีปเพื่อเปลี่ยนจากสถานะปลดล็อกเป็นล็อก โดยมีการหมดเวลาขั้นต่ำที่อนุญาตไม่เกิน 15 วินาที
หากการใช้งานอุปกรณ์ทีวีมีผู้ใช้หลายราย และไม่ประกาศ Flag ฟีเจอร์ android.hardware.telephony
สิ่งที่จะเกิดขึ้นมีดังนี้
- [9.5/T-2-1] ต้องรองรับโปรไฟล์ที่ถูกจำกัด ซึ่งเป็นฟีเจอร์ที่ช่วยให้เจ้าของอุปกรณ์จัดการผู้ใช้เพิ่มเติมและความสามารถของผู้ใช้ในอุปกรณ์ได้ โปรไฟล์ที่จำกัดช่วยให้เจ้าของอุปกรณ์สามารถตั้งค่าสภาพแวดล้อมแยกต่างหากเพื่อให้ผู้ใช้อื่นทำงานได้ด้วย พร้อมกับจัดการข้อจำกัดที่ละเอียดขึ้นในแอปที่พร้อมใช้งานในสภาพแวดล้อมเหล่านั้น
หากการติดตั้งใช้งานอุปกรณ์ทีวีมีผู้ใช้หลายราย และประกาศ Flag ฟีเจอร์ android.hardware.telephony
สิ่งที่จะเกิดขึ้นมีดังนี้
- [9.5/T-3-1] ต้องไม่รองรับโปรไฟล์ที่จำกัด แต่ต้องสอดคล้องกับการใช้ตัวควบคุม AOSP เพื่อเปิด /ปิดใช้ผู้ใช้รายอื่นไม่ให้เข้าถึงการโทรและ SMS
2.3.6 เครื่องมือสำหรับนักพัฒนาซอฟต์แวร์และความเข้ากันได้ของตัวเลือก
การติดตั้งใช้งานอุปกรณ์ทีวี
-
Perfetto
- [6.1/T-0-1] ต้องแสดงไบนารี
/system/bin/perfetto
แก่ผู้ใช้ Shell ที่ cmdline เป็นไปตามเอกสารประกอบที่เกี่ยวข้อง - [6.1/T-0-2] ไบนารี Perfetto ต้องยอมรับเป็นอินพุตการกำหนดค่า Protobuf ที่สอดคล้องกับสคีมาที่ระบุไว้ในเอกสารประกอบ Perfetto
- [6.1/T-0-3] ไบนารี Perfetto ต้องเขียนเป็นเอาต์พุตของการติดตาม Protobuf ที่สอดคล้องกับสคีมาที่ระบุไว้ในเอกสารประกอบ Perfetto
- [6.1/T-0-4] ต้องระบุแหล่งข้อมูลที่อธิบายไว้ในเอกสารประกอบ Perfetto ผ่านไบนารี Perfetto
- [6.1/T-0-1] ต้องแสดงไบนารี
2.4 ข้อกำหนดของนาฬิกา
อุปกรณ์ Android Watch หมายถึงการใช้งานอุปกรณ์ Android ที่มีจุดประสงค์เพื่อสวมใส่บนร่างกาย หรืออาจเป็นบนข้อมือ
การใช้งานอุปกรณ์ Android จะได้รับการจัดประเภทเป็น "นาฬิกา" หากเป็นไปตามเกณฑ์ต่อไปนี้ทั้งหมด
- มีหน้าจอที่มีความยาวตามเส้นทแยงมุมจริงอยู่ในช่วง 1.1-2.5 นิ้ว
- มีกลไกสำหรับสวมใส่ร่างกาย
ข้อกำหนดเพิ่มเติมในส่วนอื่นๆ ของส่วนนี้เกี่ยวข้องกับการใช้งานอุปกรณ์ Android Watch เท่านั้น
2.4.1 ฮาร์ดแวร์
ดูการติดตั้งใช้งานอุปกรณ์
-
[7.1.1.1/W-0-1] ต้องมีหน้าจอที่มีขนาดเส้นทแยงมุมจริงอยู่ในช่วง 1.1 ถึง 2.5 นิ้ว
-
[7.2.3/W-0-1] ต้องมีฟังก์ชัน "หน้าแรก" สำหรับผู้ใช้ และฟังก์ชัน "กลับ" ยกเว้นเมื่ออยู่ใน
UI_MODE_TYPE_WATCH
-
[7.2.4/W-0-1] ต้องรองรับอินพุตหน้าจอสัมผัส
-
[7.3.1/W-SR] ขอแนะนำอย่างยิ่งให้มีตัวตรวจวัดความเร่งแบบ 3 แกน
หากการใช้งานอุปกรณ์นาฬิกามีตัวรับสัญญาณ GPS/GNSS และรายงานความสามารถของแอปพลิเคชันผ่านแฟล็กฟีเจอร์ android.hardware.location.gps
อุปกรณ์ดังกล่าวจะดำเนินการดังนี้
- [7.3.3/W-1-1] ต้องรายงานการวัด GNSS ทันทีที่พบ แม้ว่ายังไม่มีการรายงานตำแหน่งที่คำนวณจาก GPS/GNSS ก็ตาม
- [7.3.3/W-1-2] ต้องรายงานช่วง Pseudoranges และอัตรา Pseudorange ของ GNSS ในสภาพท้องฟ้าเปิดหลังจากระบุตำแหน่งขณะที่อยู่นิ่งหรือเคลื่อนที่ด้วยความเร่งน้อยกว่า 0.2 เมตรต่อวินาทียกกำลังสอง เพียงพอที่จะคำนวณตำแหน่งภายใน 20 เมตร และความเร็วอย่างน้อย 0.2 เมตรต่อวินาที อย่างน้อยที่สุด .9% ต่อวินาที
หากการใช้งานอุปกรณ์นาฬิกามีเครื่องวัดการหมุน 3 แกน สิ่งที่จะเกิดขึ้นมีดังนี้
- [7.3.4/W-2-1] ต้องมีความสามารถในการวัดการวางแนวที่เปลี่ยนไปได้สูงสุด 1,000 องศาต่อวินาที
ดูการติดตั้งใช้งานอุปกรณ์
-
[7.4.3/W-0-1] ต้องรองรับบลูทูธ
-
[7.6.1/W-0-1] ต้องมีพื้นที่เก็บข้อมูลที่ไม่ผันผวนอย่างน้อย 1 GB สำหรับข้อมูลส่วนตัวของแอปพลิเคชัน (หรือที่เรียกว่าพาร์ติชัน "/data")
-
[7.6.1/W-0-2] ต้องมีหน่วยความจำอย่างน้อย 416 MB สำหรับเคอร์เนลและพื้นที่ผู้ใช้
-
[7.8.1/W-0-1] ต้องมีไมโครโฟน
-
[7.8.2/W] อาจมีเอาต์พุตเสียง
2.4.2 มัลติมีเดีย
ไม่มีข้อกำหนดเพิ่มเติม
2.4.3 ซอฟต์แวร์
ดูการติดตั้งใช้งานอุปกรณ์
- [3/W-0-1] ต้องประกาศฟีเจอร์
android.hardware.type.watch
- [3/W-0-2] ต้องรองรับ uiMode = UI_MODE_TYPE_Wwatch
- [3.2.3.1/W-0-1] ต้องโหลดแอปพลิเคชันหรือคอมโพเนนต์บริการอย่างน้อย 1 รายการด้วยเครื่องจัดการ Intent สำหรับรูปแบบตัวกรอง Intent สาธารณะทั้งหมดที่กำหนดโดย Intent ของแอปพลิเคชันต่อไปนี้ซึ่งแสดงไว้ที่นี่
ดูการติดตั้งใช้งานอุปกรณ์
- [3.8.4/W-SR] ขอแนะนําอย่างยิ่งให้ใช้ผู้ช่วยในอุปกรณ์เพื่อจัดการการดําเนินการของตัวช่วย
ดูการใช้งานอุปกรณ์ที่ประกาศแฟล็กฟีเจอร์ 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 ประสิทธิภาพและศักยภาพ
หากการใช้งานอุปกรณ์นาฬิกามีฟีเจอร์ที่ช่วยปรับปรุงการจัดการพลังงานของอุปกรณ์ที่รวมอยู่ใน AOSP หรือขยายฟีเจอร์ต่างๆ ที่รวมอยู่ใน AOSP ฟีเจอร์ดังกล่าวจะมีผลดังนี้
- [8.3/W-SR] แนะนำอย่างยิ่งเพื่ออำนวยความสะดวกแก่ผู้ใช้ในการแสดงแอปทั้งหมดที่ได้รับการยกเว้นจากโหมดสแตนด์บายแอปและโหมดประหยัดพลังงานของ Doze
- [8.3/W-SR] แนะนำอย่างยิ่งเพื่อให้ผู้ใช้สามารถเปิดและปิดใช้ฟีเจอร์โหมดประหยัดแบตเตอรี่
ดูการติดตั้งใช้งานอุปกรณ์
- [8.4/W-0-1] ต้องระบุโปรไฟล์พลังงานต่อคอมโพเนนต์ที่กำหนดค่าการใช้งานปัจจุบันสำหรับส่วนประกอบของฮาร์ดแวร์แต่ละอย่างและการสิ้นเปลืองแบตเตอรี่โดยประมาณที่เกิดจากส่วนประกอบในช่วงเวลาต่างๆ ตามที่ระบุไว้ในเว็บไซต์โครงการโอเพนซอร์ส Android
- [8.4/W-0-2] ต้องรายงานค่าการใช้พลังงานทั้งหมดในหน่วยมิลลิแอมแปร์ (mAh)
- [8.4/W-0-3] ต้องรายงานการใช้พลังงานของ CPU ต่อ UID ของกระบวนการแต่ละรายการ โครงการโอเพนซอร์ส Android มีคุณสมบัติตรงตามข้อกำหนดผ่านการใช้งานโมดูลเคอร์เนลของ
uid_cputime
- [8.4/W-0-4] ต้องให้นักพัฒนาแอปเข้าถึงการใช้พลังงานนี้ผ่านคำสั่ง Shell
adb shell dumpsys batterystats
- [8.4/W] ควรระบุว่ามาจากคอมโพเนนต์ฮาร์ดแวร์เอง หากไม่สามารถระบุการใช้พลังงานของคอมโพเนนต์ฮาร์ดแวร์ไปยังแอปพลิเคชัน
2.4.5 โมเดลการรักษาความปลอดภัย
หากการใช้งานอุปกรณ์นาฬิกามีผู้ใช้หลายราย แต่ไม่ได้ประกาศ Flag ฟีเจอร์ android.hardware.telephony
สิ่งที่จะเกิดขึ้นมีดังนี้
- [9.5/W-1-1] ต้องรองรับโปรไฟล์ที่ถูกจำกัด ซึ่งเป็นฟีเจอร์ที่ช่วยให้เจ้าของอุปกรณ์จัดการผู้ใช้เพิ่มเติมและความสามารถของผู้ใช้ในอุปกรณ์ได้ โปรไฟล์ที่จำกัดช่วยให้เจ้าของอุปกรณ์สามารถตั้งค่าสภาพแวดล้อมแยกต่างหากเพื่อให้ผู้ใช้อื่นทำงานได้ด้วย พร้อมกับจัดการข้อจำกัดที่ละเอียดขึ้นในแอปที่พร้อมใช้งานในสภาพแวดล้อมเหล่านั้น
หากการใช้งานอุปกรณ์นาฬิกามีผู้ใช้หลายคนและประกาศแฟล็กฟีเจอร์ของ android.hardware.telephony
การดำเนินการดังกล่าวจะส่งผลดังต่อไปนี้
- [9.5/W-2-1] ต้องไม่รองรับโปรไฟล์ที่จำกัด แต่ต้องสอดคล้องกับการใช้ตัวควบคุม AOSP เพื่อเปิด /ปิดใช้ผู้ใช้รายอื่นไม่ให้เข้าถึงการโทรและ SMS
2.5 ข้อกำหนดด้านยานยนต์
การติดตั้งใช้งาน Android Automotive หมายถึงเครื่องเล่นวิทยุของยานพาหนะที่ใช้ Android เป็นระบบปฏิบัติการสำหรับระบบ และ/หรือฟังก์ชันสาระบันเทิงบางส่วนหรือทั้งหมด
การใช้งานอุปกรณ์ Android จะได้รับการจัดประเภทเป็น Automotive หากมีการประกาศฟีเจอร์ android.hardware.type.automotive
หรือตรงตามเกณฑ์ต่อไปนี้ทั้งหมด
- ฝังเป็นส่วนหนึ่งของหรือเชื่อมต่อกับรถยนต์ยานยนต์
- ใช้หน้าจอในแถวที่นั่งคนขับเป็นจอแสดงผลหลัก
ข้อกำหนดเพิ่มเติมในส่วนที่เหลือของส่วนนี้ใช้สำหรับการติดตั้งใช้งานอุปกรณ์ Android Automotive เท่านั้น
2.5.1 ฮาร์ดแวร์
การติดตั้งใช้งานอุปกรณ์ในรถยนต์:
- [7.1.1.1/A-0-1] ต้องมีหน้าจอขนาดแนวทแยงมุมจริงอย่างน้อย 6 นิ้ว
-
[7.1.1.1/A-0-2] ต้องมีเลย์เอาต์ขนาดหน้าจออย่างน้อย 750 dp x 480 dp
-
[7.2.3/A-0-1] ต้องมีฟังก์ชัน "หน้าแรก" และอาจจัดให้มีฟังก์ชัน "กลับ" และ "ล่าสุด"
- [7.2.3/A-0-2] ต้องส่งทั้งเหตุการณ์การกดค้างและเหตุการณ์ปกติของฟังก์ชันกลับ (
KEYCODE_BACK
) ไปยังแอปพลิเคชันเบื้องหน้า - [7.3/A-0-1] ต้องใช้และรายงาน
GEAR_SELECTION
,NIGHT_MODE
,PERF_VEHICLE_SPEED
และPARKING_BRAKE_ON
- [7.3/A-0-2] ค่าของ Flag
NIGHT_MODE
ต้องสอดคล้องกับโหมดกลางวัน/กลางคืนของแดชบอร์ด และควรอิงตามอินพุตเซ็นเซอร์แสงแวดล้อม เซ็นเซอร์แสงแวดล้อมที่อยู่ข้างใต้อาจเหมือนกับ Photometer - [7.3/A-0-3] ต้องให้ช่องข้อมูลเพิ่มเติมของเซ็นเซอร์
TYPE_SENSOR_PLACEMENT
เป็นส่วนหนึ่งของ SensorAdditionalInfo สำหรับเซ็นเซอร์ทุกรายการที่มีให้ - [7.3/A-0-1] อาจสูญเสียตำแหน่งโดยการรวม GPS/GNSS กับเซ็นเซอร์เพิ่มเติม หากยกเลิกตำแหน่งแล้ว เราขอแนะนำเป็นอย่างยิ่งให้ใช้และรายงานประเภทเซ็นเซอร์และ/หรือรหัสทรัพย์สินของยานพาหนะที่เกี่ยวข้อง
- [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] ขอแนะนำอย่างยิ่งให้กำหนดค่าช่วงการวัดของเครื่องวัดการหมุนเป็น +/-250 dps เพื่อให้ได้ความละเอียดสูงสุดที่เป็นไปได้
หากการติดตั้งใช้งานอุปกรณ์ Automotive มีตัวรับสัญญาณ GPS/GNSS แต่ไม่รวมการเชื่อมต่อข้อมูลตามเครือข่ายมือถือ อุปกรณ์เหล่านี้จะมีลักษณะดังนี้
- [7.3.3/A-3-1] ต้องระบุตำแหน่งในครั้งแรกที่ตัวรับสัญญาณ GPS/GNSS เปิดอยู่ หรือหลังจากผ่านไป 4 วันขึ้นไปภายใน 60 วินาที
- [7.3.3/A-3-2] ต้องเป็นไปตามเกณฑ์กำหนดเวลาเพื่อแก้ไขครั้งแรกตามที่อธิบายไว้ใน 7.3.3/C-1-2 และ 7.3.3/C-1-6 สำหรับคำขอตำแหน่งอื่นๆ ทั้งหมด (คำขอที่ไม่ใช่ครั้งแรกหรือหลังผ่านไป 4 วันขึ้นไป) โดยทั่วไปแล้ว ข้อกำหนด 7.3.3/C-1-2 จะทำได้ในรถที่ไม่มีการเชื่อมต่ออินเทอร์เน็ตผ่านเครือข่ายมือถือ โดยใช้การคาดการณ์วงโคจรของ GNSS ที่คำนวณจากเครื่องรับ หรือใช้ตำแหน่งของรถที่ทราบล่าสุดควบคู่กับความสามารถในการตกแท่นนานอย่างน้อย 60 วินาทีโดยมีความแม่นยำของตำแหน่งเป็นไปตาม 7.3.3/C-1-3 หรือทั้ง 2 อย่างร่วมกัน
การติดตั้งใช้งานอุปกรณ์ในรถยนต์:
- [7.4.3/A-0-1] ต้องรองรับบลูทูธและควรรองรับ Bluetooth LE
- [7.4.3/A-0-2] การติดตั้งใช้งาน Android Automotive ต้องรองรับโปรไฟล์บลูทูธต่อไปนี้
- การโทรผ่านโทรศัพท์ผ่านโปรไฟล์แฮนด์ฟรี (HFP)
- การเล่นสื่อผ่าน Audio Distribution Profile (A2DP)
- การควบคุมการเล่นสื่อบนโปรไฟล์รีโมตคอนโทรล (AVRCP)
- การแชร์รายชื่อติดต่อโดยใช้โปรไฟล์การเข้าถึงสมุดโทรศัพท์ (PBAP)
-
[7.4.3/A-SR] ได้รับการแนะนำอย่างยิ่งให้รองรับ Message Access Profile (MAP)
-
[7.4.5/A] ควรมีการรองรับการเชื่อมต่อข้อมูลตามเครือข่ายมือถือ
- [7.4.5/A] อาจใช้ค่าคงที่
NetworkCapabilities#NET_CAPABILITY_OEM_PAID
ของระบบสำหรับเครือข่ายที่ควรใช้งานได้ในแอประบบ
กล้องมองภายนอกคือกล้องที่ใช้ถ่ายภาพทิวทัศน์นอกตัวอุปกรณ์ เช่น กล้องติดรถยนต์
การติดตั้งใช้งานอุปกรณ์ในรถยนต์:
- ควรมีกล้องมุมมองภายนอกอย่างน้อย 1 ตัว
หากการใช้งานอุปกรณ์ยานยนต์มีกล้องมองภายนอกสำหรับกล้องดังกล่าว สิ่งที่จะเกิดขึ้นมีดังนี้
- [7.5/A-1-1] ต้องไม่มีกล้องมุมมองภายนอกที่เข้าถึงได้ผ่าน Android Camera API เว้นแต่ว่าจะเป็นไปตามข้อกำหนดหลักของกล้อง
- [7.5/A-SR] ขอแนะนำอย่างยิ่งไม่ให้หมุนหรือมิเรอร์ในแนวนอนของการแสดงตัวอย่างจากกล้อง
- [7.5.5/A-SR] ขอแนะนำอย่างยิ่งให้ปรับทิศทางเพื่อให้ด้านยาวของกล้องอยู่ในแนวเดียวกับแนวเส้นขอบฟ้า
- [7.5/A-SR] ขอแนะนำอย่างยิ่งให้มีความละเอียดอย่างน้อย 1.3 เมกะพิกเซล
- ควรมีฮาร์ดแวร์โฟกัสคงที่หรือ EDOF (ระยะชัดลึกที่ขยาย)
- ควรรองรับเฟรมเวิร์กการซิงค์ของ Android
- อาจใช้การโฟกัสอัตโนมัติด้วยฮาร์ดแวร์หรือซอฟต์แวร์การโฟกัสอัตโนมัติในไดรเวอร์กล้อง
การติดตั้งใช้งานอุปกรณ์ในรถยนต์:
-
[7.6.1/A-0-1] ต้องมีพื้นที่เก็บข้อมูลที่ไม่ผันผวนอย่างน้อย 4 GB สำหรับข้อมูลส่วนตัวของแอปพลิเคชัน (หรือที่เรียกว่าพาร์ติชัน "/data")
-
[7.6.1/A] ควรจัดรูปแบบพาร์ติชันข้อมูลเพื่อเพิ่มประสิทธิภาพและอายุการใช้งานพื้นที่เก็บข้อมูล Flash เช่น ใช้ระบบไฟล์
f2fs
หากการใช้งานอุปกรณ์ Automotive มีพื้นที่เก็บข้อมูลภายนอกที่แชร์ผ่านส่วนหนึ่งของพื้นที่เก็บข้อมูลภายในแบบถอดไม่ได้ สิ่งที่จะเกิดขึ้นมีดังนี้
- [7.6.1/A-SR] แนะนำอย่างยิ่งให้ลดค่าใช้จ่ายในการดำเนินงาน I/O ของการดำเนินการบนพื้นที่เก็บข้อมูลภายนอก เช่น โดยใช้
SDCardFS
หากใช้อุปกรณ์ Automotive เป็นแบบ 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 ขึ้นไปบนหน้าจอขนาดใหญ่พิเศษ
หากใช้อุปกรณ์ Automotive เป็นแบบ 64 บิต
-
[7.6.1/A-2-1] หน่วยความจำที่พร้อมใช้งานสำหรับเคอร์เนลและพื้นที่ผู้ใช้ต้องมีขนาดอย่างน้อย 816 MB หากใช้ความหนาแน่นดังต่อไปนี้
- 280dpi หรือต่ำกว่าบนหน้าจอขนาดเล็ก/ปกติ
- ldpi หรือต่ำกว่าบนหน้าจอขนาดใหญ่พิเศษ
- mdpi หรือต่ำกว่าบนหน้าจอขนาดใหญ่
-
[7.6.1/A-2-2] หน่วยความจำที่พร้อมใช้งานสำหรับเคอร์เนลและพื้นที่ผู้ใช้ต้องมีขนาดอย่างน้อย 944 MB หากใช้ความหนาแน่นดังต่อไปนี้
- xhdpi ขึ้นไปสำหรับหน้าจอขนาดเล็ก/ปกติ
- hdpi ขึ้นไปบนหน้าจอขนาดใหญ่
- MDPI ขึ้นไปบนหน้าจอขนาดใหญ่พิเศษ
-
[7.6.1/A-2-3] หน่วยความจำที่พร้อมใช้งานสำหรับเคอร์เนลและพื้นที่ผู้ใช้ต้องมีขนาดอย่างน้อย 1280 MB หากใช้ความหนาแน่นดังต่อไปนี้
- 400dpi ขึ้นไปบนหน้าจอขนาดเล็ก/ปกติ
- xhdpi ขึ้นไปบนหน้าจอขนาดใหญ่
- tvdpi ขึ้นไปบนหน้าจอขนาดใหญ่พิเศษ
-
[7.6.1/A-2-4] หน่วยความจำที่พร้อมใช้งานสำหรับเคอร์เนลและพื้นที่ผู้ใช้ต้องมีขนาดอย่างน้อย 1824 MB หากใช้ความหนาแน่นดังต่อไปนี้
- 560dpi ขึ้นไปบนหน้าจอขนาดเล็ก/ปกติ
- 400dpi ขึ้นไปบนหน้าจอขนาดใหญ่
- xhdpi ขึ้นไปบนหน้าจอขนาดใหญ่พิเศษ
โปรดทราบว่า "หน่วยความจำที่พร้อมใช้งานสำหรับเคอร์เนลและพื้นที่ผู้ใช้" ข้างต้นหมายถึงพื้นที่หน่วยความจำที่มีให้นอกเหนือจากหน่วยความจำที่จัดสรรให้กับส่วนประกอบของฮาร์ดแวร์อยู่แล้ว เช่น วิทยุ วิดีโอ และอื่นๆ ซึ่งไม่อยู่ภายใต้การควบคุมของเคอร์เนลในการใช้งานอุปกรณ์
การติดตั้งใช้งานอุปกรณ์ในรถยนต์:
- [7.7.1/A] ควรมีพอร์ต USB ที่รองรับโหมดอุปกรณ์ต่อพ่วง
การติดตั้งใช้งานอุปกรณ์ในรถยนต์:
- [7.8.1/A-0-1] ต้องมีไมโครโฟน
การติดตั้งใช้งานอุปกรณ์ในรถยนต์:
- [7.8.2/A-0-1] ต้องมีเอาต์พุตเสียงและประกาศ
android.hardware.audio.output
2.5.2 มัลติมีเดีย
การติดตั้งใช้งานอุปกรณ์ในรถยนต์ต้องรองรับรูปแบบการเข้ารหัสและถอดรหัสเสียงต่อไปนี้ รวมถึงทำให้รูปแบบดังกล่าวพร้อมใช้งานสำหรับแอปพลิเคชันของบุคคลที่สาม
- [5.1/A-0-1] โปรไฟล์ MPEG-4 AAC (AAC LC)
- [5.1/A-0-2] โปรไฟล์ MPEG-4 HE AAC (AAC+)
- [5.1/A-0-3] AAC ELD (ปรับปรุงความหน่วงต่ำ AAC)
การติดตั้งใช้งานอุปกรณ์ในรถยนต์ต้องรองรับรูปแบบการเข้ารหัสวิดีโอต่อไปนี้ และทำให้ใช้งานกับแอปพลิเคชันของบุคคลที่สามได้
การติดตั้งใช้งานอุปกรณ์ในรถยนต์ต้องรองรับรูปแบบการถอดรหัสวิดีโอต่อไปนี้ และทำให้ใช้งานกับแอปพลิเคชันของบุคคลที่สามได้
เราขอแนะนำเป็นอย่างยิ่งให้ใช้อุปกรณ์ในรถยนต์เพื่อรองรับการถอดรหัสวิดีโอต่อไปนี้
- [5.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.*
หากการติดตั้งใช้งานอุปกรณ์ Automotive มี API ที่เป็นกรรมสิทธิ์โดยใช้ android.car.CarPropertyManager
กับ android.car.VehiclePropertyIds
สิ่งที่จะเกิดขึ้นมีดังนี้
- [3/A-1-1] ต้องไม่แนบสิทธิ์พิเศษกับการใช้พร็อพเพอร์ตี้เหล่านี้ของแอปพลิเคชันระบบ หรือป้องกันไม่ให้แอปพลิเคชันของบุคคลที่สามใช้พร็อพเพอร์ตี้เหล่านี้
- [3/A-1-2] ต้องไม่จำลองพร็อพเพอร์ตี้ยานพาหนะที่มีอยู่แล้วใน SDK
การติดตั้งใช้งานอุปกรณ์ในรถยนต์:
-
[3.2.1/A-0-1] ต้องรองรับและบังคับใช้ค่าคงที่ของสิทธิ์ทั้งหมดตามที่หน้าข้อมูลอ้างอิงสิทธิ์สำหรับยานยนต์ระบุไว้
-
[3.2.3.1/A-0-1] ต้องโหลดแอปพลิเคชันหรือคอมโพเนนต์บริการอย่างน้อย 1 รายการด้วยเครื่องจัดการ Intent สำหรับรูปแบบตัวกรอง Intent สาธารณะทั้งหมดที่กำหนดโดย Intent ของแอปพลิเคชันต่อไปนี้ซึ่งแสดงไว้ที่นี่
-
[3.4.1/A-0-1] ต้องติดตั้งใช้งาน
android.webkit.Webview
API โดยสมบูรณ์ -
[3.8.3/A-0-1] ต้องแสดงการแจ้งเตือนที่ใช้
Notification.CarExtender
API เมื่อแอปพลิเคชันของบุคคลที่สามขอ -
[3.8.4/A-SR] ขอแนะนำอย่างยิ่งให้ใช้ผู้ช่วยในอุปกรณ์เพื่อจัดการการดำเนินการของตัวช่วย
หากการใช้งานอุปกรณ์ยานยนต์มีปุ่มกดเพื่อพูด ฟีเจอร์ดังกล่าวจะมีลักษณะดังนี้
- [3.8.4/A-1-1] ต้องใช้การกดปุ่ม Push-to-Talk สั้นๆ เป็นการโต้ตอบที่กำหนดเพื่อเปิดแอปช่วยเหลือที่ผู้ใช้เลือก กล่าวคือ แอปที่ใช้
VoiceInteractionService
การติดตั้งใช้งานอุปกรณ์ในรถยนต์:
- [3.8.3.1/A-0-1] ต้องแสดงผลทรัพยากรอย่างถูกต้องตามที่อธิบายไว้ในเอกสารประกอบของ SDK
Notifications on Automotive OS
- [3.8.3.1/A-0-2] ต้องแสดง "เล่น" และ "ปิดเสียง" สำหรับการดำเนินการแจ้งเตือนแทนการดำเนินการที่ดำเนินการผ่าน
Notification.Builder.addAction()
- [3.8.3.1/A] ควรจำกัดการใช้งานงานการจัดการแบบสมบูรณ์ เช่น การควบคุมต่อการแจ้งเตือนต่อช่องทาง อาจใช้ความสามารถของ UI ต่อแอปพลิเคชันเพื่อลดการควบคุม
การติดตั้งใช้งานอุปกรณ์ในรถยนต์:
- [3.14/A-0-1] ต้องระบุเฟรมเวิร์ก UI เพื่อรองรับแอปของบุคคลที่สามที่ใช้ API สื่อตามที่อธิบายไว้ในส่วน 3.14
- [3.14/A-0-2] ต้องอนุญาตให้ผู้ใช้โต้ตอบกับแอปพลิเคชันสื่อได้อย่างปลอดภัยขณะขับรถ
- [3.14/A-0-3] ต้องรองรับการดำเนินการ Intent แบบไม่เจาะจงปลายทาง
CAR_INTENT_ACTION_MEDIA_TEMPLATE
ด้วยส่วนเสริมCAR_EXTRA_MEDIA_PACKAGE
- [3.14/A-0-4] ต้องให้เงินช่วยเหลือในการไปยังกิจกรรมที่ต้องการของแอปพลิเคชันสื่อ แต่ต้องเปิดใช้เฉพาะเมื่อข้อจำกัด UX ของรถยนต์ไม่มีผลเท่านั้น
- [3.14/A-0-5] ต้องแสดงข้อความแสดงข้อผิดพลาดที่ตั้งค่าโดยแอปพลิเคชันสื่อ และต้องรองรับตัวเลือกเพิ่มเติมเสริม
ERROR_RESOLUTION_ACTION_LABEL
และERROR_RESOLUTION_ACTION_INTENT
- [3.14/A-0-6] ต้องรองรับราคาในการค้นหาในแอปสำหรับแอปที่รองรับการค้นหา
- [3.14/A-0-7] ต้องเป็นไปตามคำจำกัดความของ
CONTENT_STYLE_BROWSABLE_HINT
และCONTENT_STYLE_PLAYABLE_HINT
เมื่อแสดงลำดับชั้น MediaBrowser
หากการติดตั้งใช้งานอุปกรณ์ Automotive มีแอป Launcher เริ่มต้น ระบบจะดำเนินการต่อไปนี้
- [3.14/A-1-1] ต้องระบุบริการสื่อและเปิดบริการด้วย Intent
CAR_INTENT_ACTION_MEDIA_TEMPLATE
การติดตั้งใช้งานอุปกรณ์ในรถยนต์:
- [3.8/A] อาจจำกัดคำขอให้แอปพลิเคชันเข้าสู่โหมดเต็มหน้าจอตามที่อธิบายไว้ใน
immersive documentation
- [3.8/A] อาจทำให้แถบสถานะและแถบนำทางมองเห็นได้ตลอดเวลา
- [3.8/A] อาจจำกัดให้แอปพลิเคชันเปลี่ยนสีองค์ประกอบ UI ของระบบเพื่อให้มั่นใจว่าสามารถมองเห็นองค์ประกอบเหล่านั้นได้อย่างชัดเจนตลอดเวลา
2.5.4 ประสิทธิภาพและศักยภาพ
การติดตั้งใช้งานอุปกรณ์ในรถยนต์:
- [8.2/A-0-1] ต้องรายงานจำนวนไบต์ที่อ่านและเขียนไปยังพื้นที่เก็บข้อมูลที่ไม่ผันผวนต่อ UID ของกระบวนการแต่ละรายการ เพื่อให้นักพัฒนาซอฟต์แวร์ดูสถิติได้ผ่าน System API
android.car.storagemonitoring.CarStorageMonitoringManager
โครงการโอเพนซอร์ส Android มีคุณสมบัติตรงตามข้อกำหนดผ่านโมดูลเคอร์เนลของuid_sys_stats
- [8.3/A-1-3] ต้องรองรับโหมดโรงรถ
- [8.3/A] ควรอยู่ในโหมดโรงรถอย่างน้อย 15 นาทีหลังการขับรถทุกครั้ง ยกเว้นในกรณีต่อไปนี้
- แบตเตอรี่หมด
- ไม่มีกำหนดเวลางานที่ไม่มีการใช้งาน
- คนขับออกจากโหมด Garage
- [8.4/A-0-1] ต้องระบุโปรไฟล์พลังงานต่อคอมโพเนนต์ที่กำหนดค่าการใช้งานปัจจุบันสำหรับส่วนประกอบของฮาร์ดแวร์แต่ละอย่างและการสิ้นเปลืองแบตเตอรี่โดยประมาณที่เกิดจากส่วนประกอบในช่วงเวลาต่างๆ ตามที่ระบุไว้ในเว็บไซต์โครงการโอเพนซอร์ส Android
- [8.4/A-0-2] ต้องรายงานค่าการใช้พลังงานทั้งหมดในหน่วยมิลลิแอมแปร์ (mAh)
- [8.4/A-0-3] ต้องรายงานการใช้พลังงานของ CPU ต่อ UID ของกระบวนการแต่ละรายการ โครงการโอเพนซอร์ส Android มีคุณสมบัติตรงตามข้อกำหนดผ่านการใช้งานโมดูลเคอร์เนลของ
uid_cputime
- [8.4/A] ควรมีการระบุแหล่งที่มาให้กับคอมโพเนนต์ฮาร์ดแวร์เองหากไม่สามารถระบุการใช้พลังงานของคอมโพเนนต์ฮาร์ดแวร์ไปยังแอปพลิเคชัน
- [8.4/A-0-4] ต้องให้นักพัฒนาแอปเข้าถึงการใช้พลังงานนี้ผ่านคำสั่ง Shell
adb shell dumpsys batterystats
2.5.5 โมเดลการรักษาความปลอดภัย
หากการติดตั้งใช้งานอุปกรณ์ Automotive รองรับผู้ใช้หลายคน สิ่งที่จะเกิดขึ้นมีดังนี้
- [9.5/A-1-1] ต้องไม่อนุญาตให้ผู้ใช้โต้ตอบหรือเปลี่ยนไปใช้ผู้ใช้ระบบแบบไม่มีส่วนหัว ยกเว้นการจัดสรรอุปกรณ์
- [9.5/A-1-2] ต้องเปลี่ยนเป็นผู้ใช้รองก่อนวันที่
BOOT_COMPLETED
- [9.5/A-1-3] ต้องรองรับความสามารถในการสร้างผู้ใช้ที่เป็นผู้มาเยือน แม้ว่าจำนวนผู้ใช้ในอุปกรณ์ถึงขีดจำกัดสูงสุดแล้ว
การติดตั้งใช้งานอุปกรณ์ในรถยนต์:
- [9.11/A-0-1] ต้องสำรองข้อมูลการใช้งานคีย์สโตร์ด้วยสภาพแวดล้อมการดำเนินการแบบแยกต่างหาก
- [9.11/A-0-2] ต้องมีการใช้งานอัลกอริทึมการเข้ารหัส RSA, AES, ECDSA และ HMAC รวมถึงฟังก์ชันแฮชของครอบครัว MD5, SHA1 และ SHA-2 เพื่อให้รองรับอัลกอริทึมที่รองรับของระบบคีย์สโตร์ Android อย่างเหมาะสมในพื้นที่ที่แยกออกจากโค้ดที่ทำงานในเคอร์เนลขึ้นไปอย่างปลอดภัย การแยกที่ปลอดภัยต้องบล็อกกลไกที่เป็นไปได้ทั้งหมดที่โค้ดเคอร์เนลหรือรหัสพื้นที่ผู้ใช้อาจเข้าถึงสถานะภายในของสภาพแวดล้อมที่แยกไว้ ซึ่งรวมถึง DMA โปรเจ็กต์โอเพนซอร์ส Android ต้นทาง (AOSP) เป็นไปตามข้อกำหนดนี้โดยใช้การติดตั้งใช้งาน Trusty แต่โซลูชันอื่นที่ใช้ ARM TrustZone หรือการใช้งานที่ปลอดภัยของบุคคลที่สามผ่านการตรวจสอบของการแยกที่อิงตามไฮเปอร์ไวเซอร์ที่เหมาะสมเป็นตัวเลือกอื่น
- [9.11/A-0-3] ต้องดำเนินการตรวจสอบสิทธิ์หน้าจอล็อกในสภาพแวดล้อมการดำเนินการที่แยกต่างหาก และอนุญาตให้ใช้คีย์ที่ผูกกับการตรวจสอบสิทธิ์ได้ก็ต่อเมื่อดำเนินการสำเร็จเท่านั้น ข้อมูลเข้าสู่ระบบสำหรับหน้าจอล็อกต้องจัดเก็บไว้ในรูปแบบที่อนุญาตให้เฉพาะสภาพแวดล้อมการดำเนินการที่แยกต่างหากเท่านั้น จึงจะตรวจสอบสิทธิ์หน้าจอล็อกได้ โปรเจ็กต์โอเพนซอร์ส Android มอบ Gatekeeper hardware Abstraction Layer (HAL) และ Trusty ซึ่งสามารถนำไปใช้ตามข้อกำหนดนี้ได้
- [9.11/A-0-4] ต้องรองรับเอกสารรับรองคีย์เมื่อคีย์การรับรองได้รับการป้องกันโดยฮาร์ดแวร์ที่ปลอดภัยและมีการรับรองในฮาร์ดแวร์ที่ปลอดภัย ต้องมีการแชร์คีย์การรับรองเอกสารรับรองกับอุปกรณ์จำนวนมากเพื่อป้องกันไม่ให้คีย์ใช้เป็นตัวระบุอุปกรณ์ วิธีหนึ่งที่จะทำให้เป็นไปตามข้อกำหนดนี้คือการแชร์คีย์เอกสารรับรองเดียวกัน เว้นแต่ว่าจะมีการผลิตอย่างน้อย 100,000 หน่วยของ SKU ที่ระบุ หากผลิต 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
แก่ผู้ใช้ Shell ที่ cmdline เป็นไปตามเอกสารประกอบที่เกี่ยวข้อง - [6.1/A-0-2] ไบนารี Perfetto ต้องยอมรับเป็นอินพุตการกำหนดค่า Protobuf ที่สอดคล้องกับสคีมาที่ระบุไว้ในเอกสารประกอบ Perfetto
- [6.1/A-0-3] ไบนารี Perfetto ต้องเขียนเป็นเอาต์พุตการติดตาม Protobuf ที่สอดคล้องกับสคีมาที่ระบุไว้ในเอกสารประกอบ Perfetto
- [6.1/A-0-4] ต้องระบุแหล่งข้อมูลที่อธิบายไว้ในเอกสารประกอบ Perfetto ผ่านไบนารี Perfetto
- [6.1/A-0-1] ต้องแสดงไบนารี
2.6 ข้อกำหนดสำหรับแท็บเล็ต
อุปกรณ์แท็บเล็ต Android หมายถึงการใช้งานอุปกรณ์ Android ที่มักจะเป็นไปตามเกณฑ์ต่อไปนี้ทั้งหมด
- ใช้โดยถือไว้ในมือทั้ง 2 ข้าง
- ไม่มีการกำหนดค่าแบบฝาพับหรือแบบพับจอได้
- การใช้แป้นพิมพ์จริงที่ใช้กับอุปกรณ์เชื่อมต่อโดยใช้การเชื่อมต่อมาตรฐาน (เช่น USB, บลูทูธ)
- มีแหล่งพลังงานที่ช่วยให้เคลื่อนไหวได้ เช่น แบตเตอรี่
- มีขนาดหน้าจอในแนวทแยงมุม 7 ถึง 18 นิ้ว
การใช้งานอุปกรณ์แท็บเล็ตมีข้อกำหนดที่คล้ายกับการใช้งานอุปกรณ์มือถือ โดยข้อยกเว้นดังกล่าวจะระบุด้วยเครื่องหมาย * ในหัวข้อดังกล่าวและมีหมายเหตุไว้เพื่อใช้อ้างอิงในส่วนนี้
2.6.1 ฮาร์ดแวร์
ขนาดหน้าจอ
- [7.1.1.1/Tab-0-1] ต้องมีหน้าจอในช่วง 7-18 นิ้ว
เครื่องวัดการหมุน
หากอุปกรณ์แท็บเล็ตมีเครื่องวัดการหมุน 3 แกน สิ่งที่จะเกิดขึ้นมีดังนี้
- [7.3.4/Tab-1-1] ต้องมีความสามารถในการวัดการวางแนวที่เปลี่ยนไปได้สูงสุด 1,000 องศาต่อวินาที
หน่วยความจำและพื้นที่เก็บข้อมูลขั้นต่ำ (ส่วนที่ 7.6.1)
ความหนาแน่นของหน้าจอที่แสดงสำหรับหน้าจอขนาดเล็ก/ปกติในข้อกำหนดด้านอุปกรณ์พกพาไม่สามารถใช้ได้กับแท็บเล็ต
โหมดอุปกรณ์ต่อพ่วง USB (ส่วนที่ 7.7.1)
หากอุปกรณ์แท็บเล็ตมีพอร์ต USB ที่รองรับโหมดอุปกรณ์ต่อพ่วง อุปกรณ์เหล่านี้จะมีผลดังนี้
- [7.7.1/Tab] อาจใช้ Android Open Accessory (AOA) API
โหมด Virtual Reality (ส่วนที่ 7.9.1)
ความเป็นจริงเสมือนประสิทธิภาพสูง (ส่วนที่ 7.9.2)
ข้อกำหนดเกี่ยวกับ Virtual Reality ใช้ไม่ได้กับแท็บเล็ต
2.6.2 โมเดลการรักษาความปลอดภัย
คีย์และข้อมูลเข้าสู่ระบบ (ส่วนที่ 9.11)
โปรดดูหัวข้อ [9.11]
หากการใช้งานอุปกรณ์แท็บเล็ตมีผู้ใช้หลายราย และไม่ประกาศ Flag ฟีเจอร์ android.hardware.telephony
สิ่งที่จะเกิดขึ้นมีดังนี้
- [9.5/T-1-1] ต้องรองรับโปรไฟล์ที่ถูกจำกัด ซึ่งเป็นฟีเจอร์ที่ช่วยให้เจ้าของอุปกรณ์จัดการผู้ใช้เพิ่มเติมและความสามารถของผู้ใช้ในอุปกรณ์ได้ โปรไฟล์ที่จำกัดช่วยให้เจ้าของอุปกรณ์สามารถตั้งค่าสภาพแวดล้อมแยกต่างหากเพื่อให้ผู้ใช้อื่นทำงานได้ด้วย พร้อมกับจัดการข้อจำกัดที่ละเอียดขึ้นในแอปที่พร้อมใช้งานในสภาพแวดล้อมเหล่านั้น
หากการใช้งานอุปกรณ์แท็บเล็ตมีผู้ใช้หลายคนและประกาศ Flag ฟีเจอร์ android.hardware.telephony
สิ่งที่จะเกิดขึ้นมีดังนี้
- [9.5/T-2-1] ต้องไม่รองรับโปรไฟล์ที่จำกัด แต่ต้องสอดคล้องกับการใช้ตัวควบคุม AOSP เพื่อเปิด /ปิดใช้ผู้ใช้รายอื่นไม่ให้เข้าถึงการโทรและ SMS
2.6.2 ซอฟต์แวร์
- [3.2.3.1/Tab-0-1] ต้องโหลดแอปพลิเคชันหรือคอมโพเนนต์บริการอย่างน้อย 1 รายการด้วยเครื่องจัดการ Intent สำหรับรูปแบบตัวกรอง Intent สาธารณะทั้งหมดที่กำหนดโดย Intent ของแอปพลิเคชันต่อไปนี้ซึ่งแสดงไว้ที่นี่
3. ซอฟต์แวร์
3.1 ความเข้ากันได้กับ API ที่มีการจัดการ
สภาพแวดล้อมการดำเนินการแบบไบต์โค้ด Dalvik ที่มีการจัดการเป็นพาหนะหลักสำหรับแอปพลิเคชัน Android Android Application Programming Interface (API) คือชุดอินเทอร์เฟซแพลตฟอร์ม Android ที่เปิดเผยต่อแอปพลิเคชันที่ทำงานในสภาพแวดล้อมรันไทม์ที่มีการจัดการ
การติดตั้งใช้งานอุปกรณ์
-
[C-0-1] ต้องมีการติดตั้งใช้งานที่สมบูรณ์ รวมถึงลักษณะการทำงานที่บันทึกไว้ทั้งหมดของ API ที่บันทึกไว้ใน Android SDK หรือ API ใดๆ ที่ตกแต่งด้วยเครื่องหมาย “@SystemApi” ในซอร์สโค้ดอัปสตรีม Android
-
[C-0-2] ต้องสนับสนุน/เก็บรักษาคลาส เมธอด และองค์ประกอบที่เกี่ยวข้องทั้งหมดที่ทำเครื่องหมายโดยคำอธิบายประกอบ TestApi (@TestApi)
-
[C-0-3] ต้องไม่ละเว้น API ที่มีการจัดการ เปลี่ยนแปลงอินเทอร์เฟซหรือลายเซ็นของ API เบี่ยงเบนไปจากลักษณะการทำงานที่บันทึกไว้ หรือรวมสิ่งที่ไม่ดำเนินการ เว้นแต่ได้รับอนุญาตเป็นการเฉพาะโดยคำจำกัดความความเข้ากันได้นี้
-
[C-0-4] ต้องทำให้ API ยังอยู่และทำงานได้อย่างสมเหตุสมผล แม้ว่าจะละเว้นฟีเจอร์ของฮาร์ดแวร์บางอย่างที่ Android มี API ก็ตาม โปรดดูที่ส่วนที่ 7 สำหรับข้อกำหนดเฉพาะสำหรับสถานการณ์นี้
-
[C-0-5] ต้องไม่อนุญาตให้แอปของบุคคลที่สามใช้อินเทอร์เฟซที่ไม่ใช่ SDK ซึ่งเป็นเมธอดและฟิลด์ในแพ็กเกจภาษา Java ที่อยู่ในคลาสการเปิดเครื่องใน AOSP และไม่ได้เป็นส่วนหนึ่งของ SDK สาธารณะ ซึ่งรวมถึง API ที่ตกแต่งด้วยคำอธิบายประกอบ
@hide
แต่ไม่มี@SystemAPI
ตามที่อธิบายไว้ในเอกสาร SDK และสมาชิกในชั้นเรียนแบบส่วนตัวและแพ็กเกจส่วนตัว -
[C-0-6] ต้องจัดส่งมาพร้อมกับอินเทอร์เฟซที่ไม่ใช่ SDK แต่ละรายการในรายการแบบจำกัดเดียวกันกับที่ระบุผ่านแฟล็กชั่วคราวและรายการที่ปฏิเสธในเส้นทาง
prebuilts/runtime/appcompat/hiddenapi-flags.csv
สำหรับสาขาระดับ API ที่เหมาะสมใน AOSP -
[C-0-7] ต้องรองรับกลไกการอัปเดตแบบไดนามิกของการกำหนดค่าที่ลงนามเพื่อนำอินเทอร์เฟซที่ไม่ใช่ SDK ออกจากรายการที่ถูกจำกัดโดยการฝังการกำหนดค่าที่ลงนามใน APK ใดๆ ก็ตามโดยใช้คีย์สาธารณะที่มีอยู่ที่มีอยู่ใน AOSP
อย่างไรก็ตาม
- อาจหากไม่มี API ที่ซ่อนไว้หรือมีการใช้งานในอุปกรณ์ที่แตกต่างออกไป ให้ย้าย API ที่ซ่อนไว้ไปยังรายการที่ไม่อนุญาตหรือยกเว้นจากรายการที่ถูกจำกัดทั้งหมด (เช่น สีเทาอ่อน สีเทาเข้ม สีดำ)
- เป็นไปได้ หากยังไม่มี API ที่ซ่อนไว้ใน AOSP ให้เพิ่ม API ที่ซ่อนไว้ลงในรายการที่ถูกจำกัด (เช่น สีเทาอ่อน เทาเข้ม ดำ)
3.1.1. ส่วนขยาย Android
Android รองรับการขยายแพลตฟอร์ม API ที่มีการจัดการของ API ระดับใดระดับหนึ่งโดยการอัปเดตเวอร์ชันส่วนขยายสำหรับระดับ API นั้น android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel)
API จะแสดงเวอร์ชันส่วนขยายของ apiLevel
ที่ระบุ หากมีส่วนขยายสำหรับ API ระดับนั้น
การติดตั้งใช้งานอุปกรณ์ Android
-
[C-0-1] ต้องโหลดการใช้งาน AOSP ของทั้งไลบรารีที่ใช้ร่วมกัน
ExtShared
และบริการExtServices
ที่มีเวอร์ชันสูงกว่าหรือเท่ากับเวอร์ชันขั้นต่ำที่อนุญาตต่อ API แต่ละระดับล่วงหน้า ตัวอย่างเช่น การใช้งานอุปกรณ์ Android 7.0 ที่ใช้ API ระดับ 24 จะต้องมีเวอร์ชัน 1 เป็นอย่างน้อย -
[C-0-2] ต้องส่งคืนหมายเลขเวอร์ชันส่วนขยายที่ถูกต้องซึ่ง AOSP กำหนดเท่านั้น
-
[C-0-3] ต้องรองรับ API ทั้งหมดที่กำหนดโดยเวอร์ชันส่วนขยายที่
android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel)
แสดงผลในลักษณะเดียวกับที่รองรับ API ที่มีการจัดการอื่นๆ ตามข้อกำหนดในส่วนที่ 3.1
3.1.2. ไลบรารี Android
การติดตั้งใช้งานอุปกรณ์จะเกิดขึ้นเนื่องจากการเลิกใช้งานไคลเอ็นต์ Apache HTTP
- [C-0-1] ต้องไม่วางไลบรารี
org.apache.http.legacy
ใน Bootclasspath - [C-0-2] ต้องเพิ่มไลบรารี
org.apache.http.legacy
ไปยังคลาสพาธของแอปพลิเคชันเฉพาะเมื่อแอปเป็นไปตามเงื่อนไขข้อใดข้อหนึ่งต่อไปนี้- กำหนดเป้าหมาย API ระดับ 28 หรือต่ำกว่า
- ประกาศในไฟล์ Manifest ว่าต้องมีไลบรารีโดยการตั้งค่าแอตทริบิวต์
android:name
ของ<uses-library>
เป็นorg.apache.http.legacy
การติดตั้งใช้งาน AOSP จะเป็นไปตามข้อกำหนดเหล่านี้
3.2 ความเข้ากันได้ของ Soft API
นอกจาก API ที่มีการจัดการจากส่วนที่ 3.1 แล้ว Android ยังมี API แบบ "soft" ที่สำคัญเฉพาะรันไทม์เท่านั้น ในรูปแบบของสิ่งต่างๆ เช่น Intent, สิทธิ์ และลักษณะที่คล้ายกันของแอปพลิเคชัน Android ซึ่งไม่สามารถบังคับใช้ได้ขณะคอมไพล์แอปพลิเคชัน
3.2.1. สิทธิ์
- [C-0-1] ผู้ติดตั้งใช้งานอุปกรณ์ต้องรองรับและบังคับใช้ค่าคงที่สิทธิ์ทั้งหมดตามที่บันทึกในหน้าอ้างอิงสิทธิ์ โปรดทราบว่าส่วนที่ 9 แสดงข้อกำหนดเพิ่มเติมเกี่ยวกับรูปแบบความปลอดภัยของ Android
3.2.2 พารามิเตอร์บิลด์
Android API มีค่าคงที่ในคลาส android.os.Build ที่มีวัตถุประสงค์เพื่ออธิบายอุปกรณ์ปัจจุบัน
- [C-0-1] ตารางด้านล่างระบุข้อจำกัดเพิ่มเติมเกี่ยวกับรูปแบบของค่าเหล่านี้ที่การใช้งานอุปกรณ์จะต้องเป็นไปตามข้อกำหนด ทั้งนี้เพื่อให้ค่าที่มีความหมายและสอดคล้องกันในทุกการใช้งานอุปกรณ์
พารามิเตอร์ | รายละเอียด |
---|---|
VERSION.RELEASE | เวอร์ชันของระบบ Android ที่ดำเนินการอยู่ในปัจจุบันในรูปแบบที่มนุษย์อ่านได้ ช่องนี้ต้องมีค่าสตริงค่าใดค่าหนึ่งตามที่กำหนดไว้ใน 11 |
VERSION.SDK | เวอร์ชันของระบบ Android ที่กำลังใช้งานอยู่ในขณะนี้ ในรูปแบบที่โค้ดของแอปพลิเคชันของบุคคลที่สามสามารถเข้าถึงได้ สำหรับ Android 11 ช่องนี้ต้องมีค่าจำนวนเต็ม 11_INT |
VERSION.SDK_INT | เวอร์ชันของระบบ Android ที่กำลังใช้งานอยู่ในขณะนี้ ในรูปแบบที่โค้ดของแอปพลิเคชันของบุคคลที่สามสามารถเข้าถึงได้ สำหรับ Android 11 ช่องนี้ต้องมีค่าจำนวนเต็ม 11_INT |
เวอร์ชันที่เพิ่มขึ้น | ค่าที่ผู้ติดตั้งใช้งานอุปกรณ์เลือกซึ่งกำหนดบิลด์ที่เฉพาะเจาะจงของระบบ Android ที่กำลังใช้งานอยู่ในปัจจุบันในรูปแบบที่มนุษย์อ่านได้ ต้องไม่นำค่านี้มาใช้ซ้ำกับบิลด์ต่างๆ ที่ผู้ใช้ปลายทางเข้าถึงได้ โดยทั่วไปแล้ว ช่องนี้มีไว้เพื่อระบุหมายเลขบิลด์หรือตัวระบุการเปลี่ยนแปลงการควบคุมแหล่งที่มาที่ใช้สร้างบิลด์ ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII แบบ 7 บิตที่สามารถพิมพ์ได้ และตรงกับนิพจน์ทั่วไป "^[^ :\/~]+$" |
กระดาน | ค่าที่เลือกโดยผู้ใช้อุปกรณ์ซึ่งระบุฮาร์ดแวร์ภายในที่เจาะจงซึ่งอุปกรณ์ใช้ในรูปแบบที่มนุษย์อ่านได้ การใช้ช่องนี้ที่เป็นไปได้คือระบุเวอร์ชันที่เจาะจงของบอร์ดจ่ายไฟของอุปกรณ์ ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII แบบ 7 บิต และตรงกับนิพจน์ทั่วไป “^[a-zA-Z0-9_-]+$" |
แบรนด์ | ค่าที่แสดงชื่อแบรนด์ที่เชื่อมโยงกับอุปกรณ์ซึ่งผู้ใช้ปลายทางทราบ ต้องอยู่ในรูปแบบที่มนุษย์อ่านได้ และควรเป็นตัวแทนของผู้ผลิตอุปกรณ์หรือแบรนด์ของบริษัทที่จำหน่ายอุปกรณ์ ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII แบบ 7 บิต และตรงกับนิพจน์ทั่วไป “^[a-zA-Z0-9_-]+$" |
SUPPORTED_ABIS | ชื่อของชุดคำสั่ง (ประเภท CPU + แบบแผน ABI) ของโค้ดแบบเนทีฟ ดูส่วนที่ 3.3 ความเข้ากันได้กับ API เดิม |
SUPPORTED_32 BIT_ABIS | ชื่อของชุดคำสั่ง (ประเภท CPU + แบบแผน ABI) ของโค้ดแบบเนทีฟ ดูส่วนที่ 3.3 ความเข้ากันได้กับ API เดิม |
SUPPORTED_64 BIT_ABIS | ชื่อของชุดคำสั่งที่ 2 (ประเภท CPU + แบบแผน ABI) ของโค้ดแบบเนทีฟ ดูส่วนที่ 3.3 ความเข้ากันได้กับ API เดิม |
CPU ABI | ชื่อของชุดคำสั่ง (ประเภท CPU + แบบแผน ABI) ของโค้ดแบบเนทีฟ ดูส่วนที่ 3.3 ความเข้ากันได้กับ API เดิม |
CPU ABI2 | ชื่อของชุดคำสั่งที่ 2 (ประเภท CPU + แบบแผน ABI) ของโค้ดแบบเนทีฟ ดูส่วนที่ 3.3 ความเข้ากันได้กับ API เดิม |
อุปกรณ์ | ค่าที่เลือกโดยผู้ใช้อุปกรณ์ซึ่งมีชื่อการพัฒนาหรือชื่อโค้ดที่ระบุการกำหนดค่าฟีเจอร์ของฮาร์ดแวร์และการออกแบบเชิงอุตสาหกรรมของอุปกรณ์ ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII แบบ 7 บิต และตรงกับนิพจน์ทั่วไป “^[a-zA-Z0-9_-]+$" ชื่ออุปกรณ์นี้ต้องไม่เปลี่ยนแปลงตลอดอายุการใช้งานของผลิตภัณฑ์ |
Fingerprint |
สตริงที่ระบุบิลด์นี้ได้โดยไม่ซ้ำกัน เอกสารควรให้มนุษย์อ่านเข้าใจได้พอสมควร ต้องเป็นไปตามเทมเพลตนี้
$(BRAND)/$(ผลิตภัณฑ์)/ เช่น
acme/myproduct/ ลายนิ้วมือต้องไม่มีอักขระช่องว่าง ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII แบบ 7 บิต |
ฮาร์ดแวร์ | ชื่อของฮาร์ดแวร์ (จากบรรทัดคำสั่งของเคอร์เนลหรือ /proc) เอกสารควรให้มนุษย์อ่านเข้าใจได้พอสมควร ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII แบบ 7 บิต และตรงกับนิพจน์ทั่วไป “^[a-zA-Z0-9_-]+$" |
ผู้จัด | สตริงที่ระบุโฮสต์แบบไม่ซ้ำที่สร้างขึ้นมาในรูปแบบที่มนุษย์อ่านได้ ไม่มีข้อกำหนดสำหรับรูปแบบที่เฉพาะเจาะจงของฟิลด์นี้ ยกเว้นว่าจะต้องไม่เป็น Null หรือสตริงว่างเปล่า ("") |
รหัส | ตัวระบุที่ผู้ติดตั้งใช้งานอุปกรณ์เลือกเพื่ออ้างถึงรุ่นที่เฉพาะเจาะจงในรูปแบบที่มนุษย์อ่านได้ ช่องนี้สามารถเหมือนกับ android.os.Build.VERSION.INCREMENTAL แต่ควรเป็นค่าที่มีความหมายเพียงพอสำหรับผู้ใช้ปลายทางในการแยกความแตกต่างระหว่างเวอร์ชันของซอฟต์แวร์ ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII แบบ 7 บิต และตรงกับนิพจน์ทั่วไป “^[a-zA-Z0-9._-]+$" |
ผู้ผลิต | ชื่อทางการค้าของผู้ผลิตอุปกรณ์ดั้งเดิม (OEM) ของผลิตภัณฑ์ ไม่มีข้อกำหนดสำหรับรูปแบบที่เฉพาะเจาะจงของฟิลด์นี้ ยกเว้นว่าจะต้องไม่เป็น Null หรือสตริงว่างเปล่า ("") ช่องนี้ต้องไม่เปลี่ยนแปลงตลอดอายุการใช้งานของผลิตภัณฑ์ |
MODEL | ค่าที่เลือกโดยผู้ติดตั้งใช้งานอุปกรณ์ซึ่งมีชื่ออุปกรณ์ที่ผู้ใช้ปลายทางทราบ ซึ่งควรเป็นชื่อเดียวกับที่อุปกรณ์ใช้ในการทำการตลาดและขายให้แก่ผู้ใช้ปลายทาง ไม่มีข้อกำหนดสำหรับรูปแบบที่เฉพาะเจาะจงของฟิลด์นี้ ยกเว้นว่าจะต้องไม่เป็น Null หรือสตริงว่างเปล่า ("") ช่องนี้ต้องไม่เปลี่ยนแปลงตลอดอายุการใช้งานของผลิตภัณฑ์ |
ผลิตภัณฑ์ | ค่าที่เลือกโดยผู้ใช้อุปกรณ์ที่มีชื่อการพัฒนาหรือชื่อรหัสของผลิตภัณฑ์ที่เจาะจง (SKU) ซึ่งต้องไม่ซ้ำกันภายในแบรนด์เดียวกัน ต้องเป็นเนื้อหาที่มนุษย์อ่านได้ แต่ไม่จำเป็นต้องมีสำหรับให้ผู้ใช้ปลายทางอ่าน ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII แบบ 7 บิต และตรงกับนิพจน์ทั่วไป “^[a-zA-Z0-9_-]+$" ชื่อผลิตภัณฑ์นี้ต้องไม่เปลี่ยนแปลงตลอดอายุการใช้งานของผลิตภัณฑ์ |
ซีเรียล | ต้องส่งคืน "UNKNOWN" |
แท็ก | รายการแท็กที่คั่นด้วยคอมมาซึ่งเครื่องมือติดตั้งใช้งานอุปกรณ์ได้เลือกไว้ ซึ่งจะแยกความแตกต่างของบิลด์เพิ่มเติม แท็กต้องเข้ารหัสได้เป็น ASCII แบบ 7 บิต และตรงกับนิพจน์ทั่วไป "^[a-zA-Z0-9._-]+" และต้องมีค่าใดค่าหนึ่งที่สอดคล้องกับการกำหนดค่าการรับรองแพลตฟอร์ม Android ทั่วไป 3 แบบ ได้แก่ คีย์การเผยแพร่ คีย์นักพัฒนาซอฟต์แวร์ และคีย์ทดสอบ |
เวลา | ค่าที่แสดงการประทับเวลาเมื่อมีการสร้างบิลด์ |
ประเภท | ค่าที่ผู้ติดตั้งใช้งานอุปกรณ์เลือกซึ่งระบุการกำหนดค่ารันไทม์ของบิลด์ ช่องนี้ต้องมีค่าใดค่าหนึ่งที่สอดคล้องกับการกำหนดค่ารันไทม์ทั่วไปของ Android 3 รายการ ได้แก่ user, userdebug หรือ eng |
ผู้ใช้ | ชื่อหรือรหัสผู้ใช้ของผู้ใช้ (หรือผู้ใช้อัตโนมัติ) ที่สร้างบิลด์ ไม่มีข้อกำหนดสำหรับรูปแบบที่เฉพาะเจาะจงของฟิลด์นี้ ยกเว้นว่าจะต้องไม่เป็น Null หรือสตริงว่างเปล่า ("") |
VERSION.SECURITY_Patch | ค่าที่ระบุระดับแพตช์ความปลอดภัยของบิลด์ ต้องหมายความว่าเวอร์ชันดังกล่าวไม่มีช่องโหว่ต่อปัญหาต่างๆ ที่อธิบายไว้ผ่านกระดานข่าวสารด้านความปลอดภัยสาธารณะของ Android ที่กำหนดไว้ โดยต้องอยู่ในรูปแบบ [YYYY-MM-DD] โดยตรงกับสตริงที่กำหนดในกระดานข่าวสารด้านความปลอดภัยสาธารณะของ Android หรือในคำแนะนำด้านความปลอดภัยของ Android เช่น "2015-11-01" |
VERSION.BASE_OS | ค่าที่แสดงพารามิเตอร์ FINGERPRINT ของบิลด์ที่เหมือนกับบิลด์นี้ ยกเว้นแพตช์ที่ระบุไว้ในกระดานข่าวสารความปลอดภัยสาธารณะของ Android โดยต้องรายงานค่าที่ถูกต้อง และหากไม่มีบิลด์ดังกล่าว ให้รายงานสตริงว่าง ("") |
รองเท้าบู๊ต | ค่าที่ผู้ให้บริการอุปกรณ์เลือกซึ่งระบุเวอร์ชัน Bootloader ภายในที่ใช้ในอุปกรณ์ในรูปแบบที่มนุษย์อ่านได้ ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII แบบ 7 บิต และตรงกับนิพจน์ทั่วไป “^[a-zA-Z0-9._-]+$" |
getRadioVersion() | ต้อง (หรือส่งคืน) ค่าที่เลือกโดยเครื่องมือของอุปกรณ์ ซึ่งระบุเวอร์ชันวิทยุ/โมเด็มภายในที่ใช้ในอุปกรณ์ในรูปแบบที่มนุษย์อ่านได้ หากอุปกรณ์ไม่มีวิทยุ/โมเด็มภายใน จะต้องแสดงผลเป็น NULL ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII แบบ 7 บิต และตรงกับนิพจน์ทั่วไป “^[a-zA-Z0-9._-,]+$” |
getSerial() | ต้อง (หรือส่งคืน) หมายเลขซีเรียลของฮาร์ดแวร์ ซึ่งต้องมีและไม่ซ้ำกันในอุปกรณ์ที่มี MODEL และ MANUFACTURER เดียวกัน ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII แบบ 7 บิต และตรงกับนิพจน์ทั่วไป “^[a-zA-Z0-9._-,]+$” |
3.2.3 ความเข้ากันได้กับ Intent
3.2.3.1 Intent ทั่วไปของแอปพลิเคชัน
Intent ของ Android อนุญาตให้คอมโพเนนต์ของแอปพลิเคชันขอฟังก์ชันการทำงานจากคอมโพเนนต์อื่นๆ ของ Android ได้ โปรเจ็กต์ต้นทางของ Android ประกอบด้วยรายการแอปพลิเคชันที่ใช้รูปแบบ Intent ต่างๆ เพื่อดำเนินการทั่วไป
การติดตั้งใช้งานอุปกรณ์
- [C-SR] แนะนำอย่างยิ่งให้โหลดแอปพลิเคชันหรือคอมโพเนนต์บริการอย่างน้อย 1 รายการด้วยเครื่องจัดการ Intent สำหรับรูปแบบตัวกรอง Intent สาธารณะทั้งหมดที่กำหนดโดย Intent ของแอปพลิเคชันต่อไปนี้ตามที่ระบุไว้ที่นี่ และมีการดำเนินการตามความคาดหวังของนักพัฒนาซอฟต์แวร์สำหรับ Intent ทั่วไปของแอปพลิเคชันตามที่อธิบายไว้ใน SDK
โปรดดูส่วนที่ 2 สำหรับ Intent ของแอปพลิเคชันที่จำเป็นสำหรับอุปกรณ์แต่ละประเภท
3.2.3.2 ความละเอียดของความตั้งใจ
-
[C-0-1] เนื่องจาก Android เป็นแพลตฟอร์มที่ขยายได้ การใช้งานอุปกรณ์ต้องอนุญาตให้แอปพลิเคชันของบุคคลที่สามลบล้างรูปแบบ Intent แต่ละรูปแบบที่อ้างอิงในหัวข้อ 3.2.3.1 ยกเว้นการตั้งค่า การติดตั้งใช้งานโอเพนซอร์ส Android ต้นทางอนุญาตการดำเนินการนี้โดยค่าเริ่มต้น
-
[C-0-2] ผู้ปฏิบัติงานใช้อุปกรณ์ต้องไม่แนบสิทธิ์พิเศษกับแอปพลิเคชันระบบ" การใช้รูปแบบจุดประสงค์เหล่านี้ หรือป้องกันไม่ให้แอปพลิเคชันของบุคคลที่สามเชื่อมโยงและควบคุมรูปแบบเหล่านี้เอง ข้อห้ามนี้รวมถึงแต่ไม่จำกัดเพียงการปิดใช้อินเทอร์เฟซผู้ใช้ "เครื่องมือเลือก" ที่ให้ผู้ใช้เลือกระหว่างแอปพลิเคชันหลายรายการที่จัดการรูปแบบ Intent เดียวกัน
-
[C-0-3] การใช้งานอุปกรณ์ต้องมีอินเทอร์เฟซผู้ใช้เพื่อให้ผู้ใช้แก้ไขกิจกรรมเริ่มต้นสำหรับ Intent
-
อย่างไรก็ตาม การใช้งานอุปกรณ์อาจมีกิจกรรมเริ่มต้นสำหรับรูปแบบ URI ที่เฉพาะเจาะจง (เช่น http://play.google.com) เมื่อกิจกรรมเริ่มต้นมีแอตทริบิวต์ที่เจาะจงมากกว่าสำหรับ URI ข้อมูล เช่น รูปแบบตัวกรอง Intent ที่ระบุ URI ข้อมูล "http://www.android.com" จะเฉพาะเจาะจงกว่ารูปแบบ Intent หลักสำหรับ "http://" ของเบราว์เซอร์
Android ยังมีกลไกสำหรับแอปของบุคคลที่สามเพื่อประกาศลักษณะการลิงก์แอปเริ่มต้นที่เชื่อถือได้สำหรับ Intent URI ของเว็บบางประเภท เมื่อกำหนดการประกาศที่เชื่อถือได้ดังกล่าวในรูปแบบตัวกรอง Intent ของแอป การใช้งานอุปกรณ์จะมีลักษณะดังนี้
- [C-0-4] ต้องพยายามตรวจสอบตัวกรอง Intent โดยทำตามขั้นตอนการตรวจสอบที่ระบุไว้ในข้อกำหนดของลิงก์เนื้อหาดิจิทัล ตามที่กำหนดโดยตัวจัดการแพ็กเกจในโปรเจ็กต์โอเพนซอร์สของ Android
- [C-0-5] ต้องตรวจสอบความถูกต้องของตัวกรอง Intent ระหว่างการติดตั้งแอปพลิเคชัน และตั้งค่าตัวกรอง Intent ของ URI ที่ผ่านการตรวจสอบความถูกต้องแล้วทั้งหมดเป็นตัวแฮนเดิลแอปเริ่มต้นสำหรับ URI
- อาจตั้งค่าตัวกรอง Intent ของ URI ที่เจาะจงเป็นตัวแฮนเดิลแอปเริ่มต้นสำหรับ URI ของตน หากตัวกรองดังกล่าวได้รับการยืนยันเรียบร้อยแล้ว แต่ตัวกรอง URI อื่นได้ยืนยันไม่สำเร็จ หากการติดตั้งใช้งานอุปกรณ์มีลักษณะเช่นนี้ ต้องระบุการลบล้างรูปแบบ URL ที่เหมาะสมให้กับผู้ใช้ในเมนูการตั้งค่า
- ต้องระบุการควบคุม App Link สำหรับแต่ละแอปให้กับผู้ใช้ในการตั้งค่าดังนี้
- [C-0-6] ผู้ใช้ต้องสามารถลบล้างลักษณะการทำงานของ App Link เริ่มต้นในภาพรวมสำหรับแอปให้เป็น "เปิดเสมอ" ถามเสมอ หรือไม่เปิดได้ ซึ่งต้องใช้กับตัวกรอง Intent URI ที่เลือกทั้งหมดเท่าๆ กัน
- [C-0-7] ผู้ใช้ต้องดูรายการตัวกรอง Intent ของ URI ที่เลือกได้
- การติดตั้งใช้งานอุปกรณ์อาจช่วยให้ผู้ใช้ลบล้างตัวกรอง Intent ของ URI ของตัวเลือกบางรายการที่ได้รับการยืนยันเรียบร้อยแล้ว โดยอิงตามตัวกรองต่อความตั้งใจ
- [C-0-8] การใช้งานอุปกรณ์ต้องทำให้ผู้ใช้สามารถดูและลบล้างตัวกรอง Intent ของ URI ตัวเลือกบางรายการได้ หากการใช้งานอุปกรณ์อนุญาตให้ตัวกรอง Intent ของ URI ที่มีตัวเลือกบางรายการทำการยืนยันได้สำเร็จ ขณะที่บางตัวกรองอาจล้มเหลวได้
3.2.3.3 เนมสเปซ Intent
- [C-0-1] การใช้งานอุปกรณ์ต้องไม่มีคอมโพเนนต์ Android ที่เป็นไปตามรูปแบบ Intent การออกอากาศหรือการออกอากาศใหม่ที่ใช้ ACTION, CATEGORY หรือสตริงคีย์อื่นๆ ใน Android หรือ com.android.
- [C-0-2] ผู้ติดตั้งใช้งานอุปกรณ์ต้องไม่มีคอมโพเนนต์ใดๆ ของ Android ที่เป็นไปตามรูปแบบ Intent ใหม่ในการออกอากาศ โดยใช้ ACTION, CATEGORY หรือสตริงคีย์อื่นๆ ในพื้นที่แพ็กเกจที่เป็นขององค์กรอื่น
- [C-0-3] ผู้ติดตั้งใช้งานอุปกรณ์ต้องไม่เปลี่ยนแปลงหรือขยายรูปแบบความตั้งใจใดๆ ที่ระบุไว้ในหัวข้อ 3.2.3.1
- การใช้งานอุปกรณ์อาจรวมถึงรูปแบบความตั้งใจที่ใช้เนมสเปซอย่างชัดเจนและเห็นได้ชัดว่าเกี่ยวข้องกับองค์กรของตน ข้อห้ามนี้คล้ายกับที่ระบุสำหรับคลาสภาษา Java ในส่วนที่ 3.6
3.2.3.4 ความตั้งใจในการออกอากาศ
แอปพลิเคชันของบุคคลที่สามต้องอาศัยแพลตฟอร์มในการเผยแพร่ความตั้งใจบางอย่าง เพื่อแจ้งเตือนผู้ใช้เกี่ยวกับการเปลี่ยนแปลงในสภาพแวดล้อมของฮาร์ดแวร์หรือซอฟต์แวร์
การติดตั้งใช้งานอุปกรณ์
- [C-0-1] ต้องออกอากาศ Intent การออกอากาศแบบสาธารณะตามที่ระบุไว้ที่นี่เพื่อตอบสนองต่อเหตุการณ์ของระบบที่เหมาะสมตามที่อธิบายไว้ในเอกสาร SDK โปรดทราบว่าข้อกำหนดนี้ไม่ขัดแย้งกับส่วนที่ 3.5 เนื่องจากมีการอธิบายข้อจำกัดสำหรับแอปพลิเคชันในเบื้องหลังไว้ในเอกสาร SDK ด้วย นอกจากนี้ วัตถุประสงค์การเผยแพร่บางอย่างจะมีเงื่อนไขสำหรับการสนับสนุนฮาร์ดแวร์ หากอุปกรณ์รองรับฮาร์ดแวร์ที่จำเป็น ก็ต้องเผยแพร่ Intent และแสดงลักษณะการทำงานไปพร้อมกับเอกสาร SDK
3.2.3.5 Intent ของแอปพลิเคชันแบบมีเงื่อนไข
Android มีการตั้งค่าที่ช่วยให้ผู้ใช้เลือกแอปพลิเคชันเริ่มต้นต่างๆ ได้อย่างง่ายดาย เช่น หน้าจอหลักหรือ SMS
การใช้งานอุปกรณ์ต้องมีเมนูการตั้งค่าที่คล้ายกันและเข้ากันได้กับรูปแบบตัวกรอง Intent และเมธอด API ที่อธิบายไว้ในเอกสาร SDK ตามด้านล่าง หากจะเหมาะสม
หากการติดตั้งใช้งานอุปกรณ์รายงาน android.software.home_screen
สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-1-1] ต้องปฏิบัติตาม Intent ของ
android.settings.HOME_SETTINGS
จึงจะแสดงเมนูการตั้งค่าแอปเริ่มต้นสำหรับหน้าจอหลักได้
หากการติดตั้งใช้งานอุปกรณ์รายงาน android.hardware.telephony
สิ่งที่จะเกิดขึ้นมีดังนี้
-
[C-2-1] ต้องระบุเมนูการตั้งค่าที่จะเรียกใช้ Intent ของ
android.provider.Telephony.ACTION_CHANGE_DEFAULT
เพื่อแสดงกล่องโต้ตอบเพื่อเปลี่ยนแอปพลิเคชัน SMS เริ่มต้น -
[C-2-2] ต้องเป็นไปตาม Intent ของ
android.telecom.action.CHANGE_DEFAULT_DIALER
ในการแสดงกล่องโต้ตอบเพื่อให้ผู้ใช้เปลี่ยนแอปพลิเคชันโทรศัพท์เริ่มต้นได้- ต้องใช้ UI ของแอปโทรศัพท์เริ่มต้นที่ผู้ใช้เลือกสำหรับการโทรเข้าและโทรออก ยกเว้นการโทรหาหมายเลขฉุกเฉิน ซึ่งจะใช้แอปโทรศัพท์ที่ติดตั้งไว้ล่วงหน้า
-
[C-2-3] ต้องปฏิบัติตามเจตนาของ android.telecom.action.CHANGE_PHONE_ACCOUNTS เพื่อให้ผู้ใช้สามารถกำหนดค่า
ConnectionServices
ที่เชื่อมโยงกับPhoneAccounts
รวมถึงบัญชีโทรศัพท์เริ่มต้นที่ผู้ให้บริการโทรคมนาคมจะใช้ในการโทรออก การติดตั้งใช้งาน 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] เราขอแนะนำอย่างยิ่งให้ใช้ android.intent.action.ANSWER, android.intent.action.CALL, android.intent.action.CALL_BUTTON, android.intent.action.VIEW และ android.intent.action.DIAL Intent ที่มีแอปพลิเคชันแป้นโทรศัพท์ที่โหลดล่วงหน้า ซึ่งสามารถจัดการ 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
และมีแอปพลิเคชันที่ใช้ API นี้ติดตั้งมากกว่า 1 แอปพลิเคชันพร้อมกัน ระบบจะดำเนินการต่อไปนี้
- [C-4-1] ต้องทำตาม Intent ของ
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" และแสดงกิจกรรมของระบบที่ขอโหมดที่ค้นพบได้
หากอุปกรณ์รองรับฟีเจอร์ DND ระบบจะดำเนินการดังต่อไปนี้
- [C-6-1] ต้องใช้กิจกรรมที่จะตอบสนองต่อความตั้งใจ
ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS
ซึ่งในการใช้งานร่วมกับ UI_mode_TYPE_NORMAL กิจกรรมดังกล่าวต้องเป็นกิจกรรมที่ผู้ใช้สามารถให้หรือปฏิเสธการเข้าถึงแอปในการกำหนดค่านโยบาย DND ได้
หากการติดตั้งใช้งานอุปกรณ์อนุญาตให้ผู้ใช้ใช้วิธีการป้อนข้อมูลของบุคคลที่สามในอุปกรณ์ดังกล่าวได้ การดำเนินการดังกล่าวจะส่งผลดังนี้
- [C-7-1] ต้องระบุกลไกที่ผู้ใช้เข้าถึงได้เพื่อเพิ่มและกำหนดค่าวิธีการป้อนข้อมูลของบุคคลที่สามเพื่อตอบสนองต่อ Intent ของ
android.settings.INPUT_METHOD_SETTINGS
หากการใช้งานอุปกรณ์รองรับบริการช่วยเหลือพิเศษของบุคคลที่สาม บริการเหล่านั้นจะมีลักษณะดังนี้
- [C-8-1] ต้องปฏิบัติตาม Intent ของ
android.settings.ACCESSIBILITY_SETTINGS
ในการจัดให้มีกลไกที่ผู้ใช้เข้าถึงได้ เพื่อเปิดและปิดใช้บริการการช่วยเหลือพิเศษของบุคคลที่สามควบคู่ไปกับบริการการช่วยเหลือพิเศษที่โหลดไว้ล่วงหน้า
หากการใช้งานอุปกรณ์มีการสนับสนุนสำหรับ Wi-Fi Easy Connect และแสดงฟังก์ชันดังกล่าวให้แอปของบุคคลที่สาม เหตุการณ์ดังกล่าวจะส่งผลดังนี้
- [C-9-1] ต้องใช้ Settings#ACTION_PROCESS_WIFI_EASY_CONNECT_URI Intent API ตามที่อธิบายไว้ในเอกสารประกอบของ SDK
หากใช้อุปกรณ์ให้โหมดประหยัดอินเทอร์เน็ต จะมีเงื่อนไขดังนี้ * [C-10-1] ต้องมีอินเทอร์เฟซผู้ใช้ในการตั้งค่าที่จัดการ Intent ของ Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS
เพื่อให้ผู้ใช้เพิ่มแอปพลิเคชันหรือนำแอปพลิเคชันออกจากรายการที่อนุญาตได้
หากอุปกรณ์ไม่มีโหมดประหยัดอินเทอร์เน็ต ระบบจะดำเนินการดังนี้
- [C-11-1] ต้องมีกิจกรรมที่จัดการ Intent ของ
Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS
แต่อาจใช้งานโดยไม่มีการดำเนินการ
หากการใช้งานอุปกรณ์ประกาศการรองรับกล้องผ่าน android.hardware.camera.any
อุปกรณ์เหล่านั้นจะมีลักษณะดังนี้
- [C-12-1] ต้องปฏิบัติตาม Intent ของ
android.media.action.STILL_IMAGE_CAMERA
และandroid.media.action.STILL_IMAGE_CAMERA_SECURE
และเปิดตัวกล้องในโหมดภาพนิ่งตามที่อธิบายไว้ใน SDK - [C-12-2] ต้องทำตาม Intent ของ
android.media.action.VIDEO_CAMERA
ในการเปิดตัวกล้องในโหมดวิดีโอตามที่อธิบายไว้ใน SDK - [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] ต้องปฏิบัติตาม Intent
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}{NEW_PROFILE.END_END_LINK android.app.action.START_ENCRYPTION และมีกิจกรรมเพื่อดำเนินการตาม Intent เหล่านี้ตามที่อธิบายไว้ใน SDK ที่นี่
หากการติดตั้งใช้งานอุปกรณ์ประกาศ Flag ฟีเจอร์ android.software.autofill
สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-14-1] ต้องใช้ API ของ
AutofillService
และAutofillManager
อย่างสมบูรณ์และปฏิบัติตาม Intent ของ android.settings.REQUEST_SET_AUTOFILL_SERVICE เพื่อแสดงเมนูการตั้งค่าแอปเริ่มต้นเพื่อเปิดใช้และปิดใช้การป้อนข้อความอัตโนมัติ รวมถึงเปลี่ยนบริการป้อนข้อความอัตโนมัติเริ่มต้นสำหรับผู้ใช้
หากการใช้งานอุปกรณ์มีแอปที่ติดตั้งมาล่วงหน้า หรือต้องการอนุญาตให้แอปของบุคคลที่สามเข้าถึงสถิติการใช้งานได้ สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-SR] แนะนำอย่างยิ่งให้กลไกที่ผู้ใช้เข้าถึงได้เพื่อให้หรือเพิกถอนการเข้าถึงสถิติการใช้งานตามจุดประสงค์ android.settings.ACTION_USAGE_ACCESS_SETTINGS สำหรับแอปที่ประกาศสิทธิ์
android.permission.PACKAGE_USAGE_STATS
หากการใช้งานอุปกรณ์ตั้งใจที่จะไม่อนุญาตแอปใดๆ รวมถึงแอปที่ติดตั้งไว้ล่วงหน้า ไม่ให้เข้าถึงสถิติการใช้งาน พวกเขาจะ:
- [C-15-1] ต้องมีกิจกรรมที่จัดการรูปแบบ Intent android.settings.ACTION_USAGE_ACCESS_SETTINGS แต่ "ต้อง" ดำเนินการ "ไม่มีการดำเนินการ" กล่าวคือต้องมีลักษณะการทำงานที่เทียบเท่าเมื่อผู้ใช้ถูกปฏิเสธไม่ให้เข้าถึง
การนำอุปกรณ์ไปใช้งานรายงานฟีเจอร์ android.hardware.audio.output
สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-SR] ขอแนะนำอย่างยิ่งให้ใช้ android.intent.action.TTS_SERVICE, android.speech.tts.engine.INSTALL_TTS_DATA และ Intent android.speech.tts.engine.GET_SAMPLE_TEXT มีกิจกรรมเพื่อดำเนินการตาม Intent เหล่านี้ตามที่อธิบายไว้ใน SDK ที่นี่
Android รองรับสกรีนเซฟเวอร์แบบอินเทอร์แอกทีฟ ซึ่งก่อนหน้านี้เรียกว่า Dreams โปรแกรมรักษาหน้าจอช่วยให้ผู้ใช้โต้ตอบกับแอปพลิเคชันเมื่ออุปกรณ์ที่เชื่อมต่อกับแหล่งจ่ายไฟไม่มีการใช้งานหรือวางอยู่บนแท่นชาร์จ การใช้งานอุปกรณ์:
- ควรมีการรองรับโปรแกรมรักษาหน้าจอและเสนอตัวเลือกการตั้งค่าเพื่อให้ผู้ใช้กำหนดค่าโปรแกรมรักษาหน้าจอเพื่อตอบสนองต่อความตั้งใจของ
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] ต้องเข้าชมกิจกรรมใหม่ในจอแสดงผลเดียวกับกิจกรรมที่เรียกใช้กิจกรรมนั้น เมื่อกิจกรรมใหม่เริ่มขึ้นโดยไม่ระบุการแสดงเป้าหมายผ่าน
ActivityOptions.setLaunchDisplayId()
API - [C-1-4] ต้องทำลายกิจกรรมทั้งหมดเมื่อนำจอแสดงผลที่มีแฟล็ก
Display.FLAG_PRIVATE
ออก - [C-1-5] ต้องซ่อนเนื้อหาในหน้าจอทั้งหมดอย่างปลอดภัยเมื่ออุปกรณ์ล็อกอยู่ด้วยหน้าจอล็อกที่ปลอดภัย เว้นแต่แอปจะเลือกให้แสดงที่ด้านบนของหน้าจอล็อกโดยใช้
Activity#setShowWhenLocked()
API - ควรมี
android.content.res.Configuration
ที่สอดคล้องกับจอแสดงผลดังกล่าวเพื่อให้แสดง ดำเนินการได้อย่างถูกต้อง และคงความเข้ากันได้ไว้หากมีการเปิดตัวกิจกรรมในจอแสดงผลรอง
หากการใช้งานอุปกรณ์อนุญาตให้เปิดใช้กิจกรรม Android ปกติในจอแสดงผลรองและจอแสดงผลรองจะมีแฟล็ก android.view.Display.FLAG_PRIVATE ให้ทำดังนี้
- [C-3-1] เฉพาะเจ้าของจอแสดงผล ระบบ และกิจกรรมที่อยู่บนจอแสดงผลนั้นเท่านั้นที่ต้องเปิดจอแสดงผลได้ ทุกคนจะเปิดจอแสดงผลที่มี Flag android.view.Display.FLAG_PUBLIC ได้
3.3 ความเข้ากันได้กับ API เดิม
ความเข้ากันได้ของโค้ดเนทีฟนั้นทำได้ยาก ด้วยเหตุนี้ ผู้ที่ติดตั้งใช้งานอุปกรณ์จึงทำสิ่งต่อไปนี้
- [SR] แนะนำอย่างยิ่งให้ใช้การใช้งานไลบรารีที่ระบุไว้ด้านล่างจากโปรเจ็กต์โอเพนซอร์ส Android ต้นทาง
3.3.1 อินเทอร์เฟซแบบไบนารีของแอปพลิเคชัน
ไบต์โค้ด Dalvik ที่มีการจัดการจะเรียกใช้โค้ดแบบเนทีฟที่ระบุไว้ในไฟล์ .apk
ของแอปพลิเคชันเป็นไฟล์ ELF .so
ที่คอมไพล์สำหรับสถาปัตยกรรมฮาร์ดแวร์อุปกรณ์ที่เหมาะสมได้ เนื่องจากโค้ดแบบเนทีฟต้องอาศัยเทคโนโลยีโปรเซสเซอร์ที่เกี่ยวข้องเป็นหลัก Android จึงกำหนดอินเทอร์เฟซแบบไบนารีของแอปพลิเคชัน (ABI) จำนวนหนึ่งไว้ใน Android NDK
การติดตั้งใช้งานอุปกรณ์
- [C-0-1] ต้องเข้ากันได้กับ Android NDK ABI ที่กำหนดไว้อย่างน้อย 1 รายการ
- [C-0-2] ต้องรวมการสนับสนุนสำหรับโค้ดที่ทำงานในสภาพแวดล้อมที่มีการจัดการเพื่อเรียกโค้ดแบบเนทีฟ โดยใช้ความหมายมาตรฐานของ Java Native Interface (JNI)
- [C-0-3] ต้องเข้ากันได้กับต้นทาง (เช่น เข้ากันได้กับส่วนหัว) และเข้ากันได้กับไบนารี (สำหรับ ABI) พร้อมด้วยไลบรารีที่จำเป็นแต่ละรายการในรายการด้านล่าง
- [C-0-5] ต้องรายงานอินเทอร์เฟซแบบไบนารีของแอปพลิเคชัน (ABI) แบบเนทีฟที่อุปกรณ์รองรับผ่านพารามิเตอร์
android.os.Build.SUPPORTED_ABIS
,android.os.Build.SUPPORTED_32_BIT_ABIS
และandroid.os.Build.SUPPORTED_64_BIT_ABIS
โดยแต่ละรายการจะคั่นด้วยคอมมาของ ABI โดยเรียงลำดับจากมากที่สุดไปน้อยที่สุด -
[C-0-6] ต้องรายงาน กลุ่มย่อยของรายชื่อ ABI ต่อไปนี้ และต้องไม่รายงาน ABI ใดๆ ที่ไม่ได้อยู่ในรายการ โดยใช้พารามิเตอร์ข้างต้น
-
armeabi
(NDK ไม่รองรับการกําหนดเป้าหมายอีกต่อไป) -
armeabi-v7a
-
arm64-v8a
-
x86
-
x86-64
-
-
[C-0-7] ต้องทำให้ไลบรารีต่อไปนี้ทั้งหมดซึ่งมี API แบบเนทีฟพร้อมใช้งานสำหรับแอปที่มีโค้ดแบบเนทีฟ
- libaaudio.so (รองรับเสียงแบบเนทีฟ)
- libamidi.so (การรองรับ MIDI เนทีฟ หากมีการอ้างสิทธิ์ฟีเจอร์
android.software.midi
ตามที่อธิบายไว้ในส่วน 5.9) - libandroid.so (การสนับสนุนกิจกรรมในเครื่องของ Android)
- libc (ไลบรารี C)
- libcamera2ndk.so
- libdl (ลิงก์แบบไดนามิก)
- libEGL.so (การจัดการแพลตฟอร์ม OpenGL ของระบบ)
- libGLESv1_CM.so (OpenGL ES 1.x)
- libGLESv2.so (OpenGL ES 2.0)
- libGLESv3.so (OpenGL ES 3.x)
- libicui18n.so
- libicuuc.so
- libjnigraphics.so
- liblog (การบันทึกของ Android)
- libmediandk.so (รองรับ API สื่อเนทีฟ)
- libm (ห้องสมุดคณิตศาสตร์)
- libneuralnetworks.so (API เครือข่ายประสาทเทียม)
- libOpenMAXAL.so (การสนับสนุน OpenMAX AL 1.0.1)
- libOpenSLES.so (การสนับสนุนระบบเสียง OpenSL ES 1.0.1)
- libRS.so
- libstdc++ (การสนับสนุนขั้นต่ำสำหรับ C++)
- libvulkan.so (วัลคาน)
- libz (การบีบอัด Zlib)
- อินเทอร์เฟซ JNI
-
[C-0-8] ต้องไม่เพิ่มหรือนำฟังก์ชันสาธารณะสำหรับไลบรารีเนทีฟที่แสดงข้างต้นออก
- [C-0-9] ต้องระบุไลบรารีเพิ่มเติมที่ไม่ใช่ AOSP ที่เปิดเผยกับแอปของบุคคลที่สามโดยตรงใน
/vendor/etc/public.libraries.txt
- [C-0-10] ต้องไม่แสดงไลบรารีแบบเนทีฟอื่นๆ ที่นำไปใช้และจัดหาให้ใน AOSP เป็นไลบรารีระบบแก่แอปของบุคคลที่สามที่กำหนดเป้าหมายเป็น API ระดับ 24 ขึ้นไป เนื่องจากมีการจองไว้
- [C-0-11] ต้องส่งออกสัญลักษณ์ฟังก์ชัน OpenGL ES 3.1 และ Android Extension Pack ทั้งหมดตามที่กำหนดไว้ใน NDK ผ่านไลบรารี
libGLESv3.so
โปรดทราบว่าจะต้องมีสัญลักษณ์ทั้งหมด แต่ส่วนที่ 7.1.4.1 ได้อธิบายรายละเอียดเพิ่มเติมถึงข้อกำหนดในการติดตั้งใช้งานฟังก์ชันที่เกี่ยวข้องแต่ละรายการอย่างครบถ้วน - [C-0-12] ต้องส่งออกสัญลักษณ์ฟังก์ชันสำหรับสัญลักษณ์ฟังก์ชันหลักของ Vulkan 1.0 รวมถึงส่วนขยาย
VK_KHR_surface
,VK_KHR_android_surface
,VK_KHR_swapchain
,VK_KHR_maintenance1
และVK_KHR_get_physical_device_properties2
ผ่านไลบรารีlibvulkan.so
โปรดทราบว่าจะต้องมีสัญลักษณ์ทั้งหมด แต่ส่วนที่ 7.1.4.2 จะอธิบายรายละเอียดเกี่ยวกับข้อกำหนดในการติดตั้งใช้งานฟังก์ชันที่เกี่ยวข้องแต่ละรายการอย่างครบถ้วนยิ่งขึ้น - ควรสร้างโดยใช้ซอร์สโค้ดและไฟล์ส่วนหัวที่มีอยู่ในโปรเจ็กต์โอเพนซอร์ส Android ต้นทาง
โปรดทราบว่า Android รุ่นต่อๆ ไปอาจเพิ่มการรองรับ ABI เพิ่มเติม
3.3.2 ความเข้ากันได้กับโค้ดแบบเนทีฟของ ARM 32 บิต
การนำอุปกรณ์ไปใช้งานรายงานการรองรับ ABI ของ armeabi
สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-3-1] ต้องรองรับ
armeabi-v7a
และรายงานการรองรับด้วย เนื่องจากarmeabi
มีไว้สำหรับความเข้ากันได้แบบย้อนหลังกับแอปรุ่นเก่าเท่านั้น
หากการติดตั้งใช้งานอุปกรณ์รายงานการรองรับ ABI ของ armeabi-v7a
สําหรับแอปที่ใช้ ABI นี้ ระบบจะดำเนินการดังนี้
-
[C-2-1] ต้องระบุบรรทัดต่อไปนี้ใน
/proc/cpuinfo
และไม่ควรเปลี่ยนค่าในอุปกรณ์เดียวกัน แม้ว่า ABI อื่นๆ จะอ่านค่าเหล่านั้นก็ตาม-
Features:
ตามด้วยรายการฟีเจอร์เสริมของ CPU ARMv7 ที่อุปกรณ์รองรับ -
CPU architecture:
ตามด้วยจำนวนเต็มที่อธิบายสถาปัตยกรรม ARM ที่รองรับสูงสุดของอุปกรณ์ (เช่น "8" สำหรับอุปกรณ์ ARMv8)
-
-
[C-2-2] ต้องทำให้การดำเนินการต่อไปนี้พร้อมใช้งานเสมอ แม้ในกรณีที่มีการใช้ ABI ในสถาปัตยกรรม ARMv8 ไม่ว่าจะผ่านการรองรับ CPU ในระบบหรือผ่านการจำลองซอฟต์แวร์ก็ตาม
- วิธีการสำหรับ SWP และ SWPB
- 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 Branch สําหรับการใช้งาน API
android.webkit.WebView
-
[C-1-3] สตริง User Agent ที่ WebView รายงานต้องอยู่ในรูปแบบต่อไปนี้
Mozilla/5.0 (Linux; Android $(VERSION); [$(MODEL)] [Build/$(BUILD)]; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 $(CHROMIUM_VER) Mobile Safari/537.36
- ค่าของสตริง $(VERSION) ต้องเหมือนกับค่าของ android.os.Build.VERSION.RELEASE
- สตริง $(MODEL) อาจว่างเปล่า แต่หากไม่ว่างเปล่า สตริงต้องมีค่าเหมือนกับ android.os.Build.MODEL
- "สร้าง/$(สร้าง)" อาจละเว้นได้ แต่หากมีสตริง $(BUILD) ต้องเหมือนกับค่าสำหรับ android.os.Build.ID
- ค่าของสตริง $(CHROMIUM_VER) ต้องเป็นเวอร์ชันของ Chromium ในโปรเจ็กต์โอเพนซอร์ส Android ต้นทาง
- การใช้งานอุปกรณ์อาจเว้น "อุปกรณ์เคลื่อนที่" ในสตริง User Agent
-
คอมโพเนนต์ WebView ควรมีการรองรับฟีเจอร์ HTML5 มากที่สุดเท่าที่จะเป็นไปได้ และหากรองรับฟีเจอร์ ก็ควรเป็นไปตามข้อกำหนดของ HTML5
-
[C-1-3] ต้องแสดงผลเนื้อหาที่ระบุหรือเนื้อหา URL ระยะไกลในกระบวนการที่แตกต่างจากแอปพลิเคชันที่สร้างอินสแตนซ์ WebView กล่าวคือ กระบวนการแสดงผลที่แยกต่างหากต้องถือสิทธิ์ระดับล่าง เรียกใช้เป็นรหัสผู้ใช้แยกต่างหาก ไม่มีสิทธิ์เข้าถึงไดเรกทอรีข้อมูลของแอป ไม่มีการเข้าถึงเครือข่ายโดยตรง และมีสิทธิ์เข้าถึงเฉพาะบริการระบบที่จำเป็นขั้นต่ำผ่าน Binder เท่านั้น การใช้ AOSP ของ WebView เป็นไปตามข้อกำหนดนี้
โปรดทราบว่าหากติดตั้งใช้งานอุปกรณ์เป็นแบบ 32 บิตหรือประกาศแฟล็กฟีเจอร์ android.hardware.ram.low
อุปกรณ์จะได้รับการยกเว้นจาก C-1-3
3.4.2 ความเข้ากันได้กับเบราว์เซอร์
หากอุปกรณ์มีแอปพลิเคชันเบราว์เซอร์แบบสแตนด์อโลนสำหรับการท่องเว็บทั่วไป การใช้งานจะต้องมีคุณสมบัติดังนี้
- [C-1-1] ต้องสนับสนุน API แต่ละรายการเหล่านี้ที่เชื่อมโยงกับ HTML5
- [C-1-2] ต้องรองรับ webstorage API ของ HTML5/W3C และควรรองรับ IndexedDB API ของ HTML5/W3C โปรดทราบว่าเนื่องจากมาตรฐานการพัฒนาเว็บกำลังเปลี่ยนไปใช้ IndexedDB แทน Webstorage คาดว่า IndexedDB จะกลายเป็นคอมโพเนนต์ที่จำเป็นใน Android เวอร์ชันในอนาคต
- อาจจัดส่งสตริง User Agent ที่กำหนดเองในแอปพลิเคชันเบราว์เซอร์แบบสแตนด์อโลน
- ควรรองรับ HTML5 ในแอปพลิเคชันเบราว์เซอร์แบบสแตนด์อโลนให้มากที่สุด (ไม่ว่าจะทำงานบนแอปพลิเคชันเบราว์เซอร์ WebKit ต้นทางหรือการแทนที่ของบุคคลที่สาม)
อย่างไรก็ตาม หากการใช้งานอุปกรณ์ไม่รวมแอปพลิเคชันเบราว์เซอร์แบบสแตนด์อโลน การทำงานจะมีลักษณะดังนี้
- [C-2-1] ต้องรองรับรูปแบบความตั้งใจสาธารณะตามที่อธิบายไว้ในส่วนที่ 3.2.3.1
3.5 ความเข้ากันได้ด้านพฤติกรรมของ API
การติดตั้งใช้งานอุปกรณ์
- [C-0-9] ต้องตรวจสอบว่ามีการใช้ความเข้ากันได้ของลักษณะการทำงานของ API กับแอปที่ติดตั้งไว้ทั้งหมด เว้นแต่จะถูกจำกัดไว้ตามที่อธิบายไว้ในส่วนที่ 3.5.1
- [C-0-10] ต้องไม่ใช้แนวทางการให้อนุญาตที่รับรองความเข้ากันได้ด้านลักษณะการทำงานของ API สำหรับแอปที่เลือกโดยผู้ใช้อุปกรณ์เท่านั้น
ลักษณะการทำงานของ API แต่ละประเภท (แบบจัดการ ซอฟต์ เนทีฟ และเว็บ) ต้องสอดคล้องกับการติดตั้งใช้งานอัปสตรีมโปรเจ็กต์โอเพนซอร์ส Android ขอบเขตความเข้ากันได้บางประการมีดังนี้
- [C-0-1] อุปกรณ์ต้องไม่เปลี่ยนลักษณะการทำงานหรือความหมายของความตั้งใจมาตรฐาน
- [C-0-2] อุปกรณ์ต้องไม่เปลี่ยนแปลงวงจรหรือความหมายขององค์ประกอบระบบบางประเภท (เช่น บริการ กิจกรรม ผู้ให้บริการเนื้อหา ฯลฯ)
- [C-0-3] อุปกรณ์ต้องไม่เปลี่ยนความหมายของสิทธิ์มาตรฐาน
- อุปกรณ์ต้องไม่เปลี่ยนแปลงข้อจำกัดที่บังคับใช้กับแอปพลิเคชันในเบื้องหลัง กล่าวอย่างเจาะจงคือ สำหรับแอปพื้นหลัง
- [C-0-4] ลูกค้าต้องหยุดเรียกใช้ Callback ที่แอปลงทะเบียนไว้เพื่อรับเอาต์พุตจาก
GnssMeasurement
และGnssNavigationMessage
- [C-0-5] ผู้ใช้ต้องจำกัดความถี่ในการอัปเดตที่ให้ไว้กับแอปผ่านคลาส API
LocationManager
หรือเมธอดWifiManager.startScan()
- [C-0-6] หากแอปกำหนดเป้าหมายเป็น API ระดับ 25 ขึ้นไป จะต้องไม่อนุญาตให้ลงทะเบียน Broadcast Receiver สำหรับการเผยแพร่ Intent มาตรฐานของ Android แบบโดยนัยในไฟล์ Manifest ของแอป เว้นแต่ Intent การเผยแพร่ต้องใช้สิทธิ์
"signature"
หรือ"signatureOrSystem"
protectionLevel
หรืออยู่ในรายการการยกเว้น - [C-0-7] หากแอปกำหนดเป้าหมายเป็น API ระดับ 25 ขึ้นไป จะต้องหยุดบริการในเบื้องหลังของแอป เช่นเดียวกับกรณีที่แอปเรียกใช้เมธอด
stopSelf()
ของบริการ ยกเว้นกรณีที่แอปอยู่ในรายการที่อนุญาตชั่วคราวเพื่อจัดการงานที่ผู้ใช้มองเห็นได้ - [C-0-8] หากแอปกำหนดเป้าหมายเป็น API ระดับ 25 ขึ้นไป แอปดังกล่าวจะต้องปล่อยการทำงานขณะล็อกที่การคงไว้ชั่วคราวของแอป
- [C-0-4] ลูกค้าต้องหยุดเรียกใช้ Callback ที่แอปลงทะเบียนไว้เพื่อรับเอาต์พุตจาก
- [C-0-9] อุปกรณ์ต้องแสดงผู้ให้บริการการรักษาความปลอดภัยต่อไปนี้เป็นค่าอาร์เรย์ 7 ค่าแรกจากเมธอด
Security.getProviders()
ตามลําดับที่ระบุ (ตามที่Provider.getName()
แสดงผล) และคลาส เว้นแต่แอปได้แก้ไขรายการผ่านinsertProviderAt()
หรือremoveProvider()
อุปกรณ์อาจส่งคืนผู้ให้บริการเพิ่มเติมหลังจากรายชื่อผู้ให้บริการที่ระบุด้านล่าง-
AndroidNSSP -
android.security.net.config.NetworkSecurityConfigProvider
-
AndroidOpenSSL -
com.android.org.conscrypt.OpenSSLProvider
-
CertPathProvider -
sun.security.provider.CertPathProvider
-
AndroidKeyStoreBCวิธีแก้ปัญหา -
android.security.keystore.AndroidKeyStoreBCWorkaroundProvider
-
BC -
com.android.org.bouncycastle.jce.provider.BouncyCastleProvider
-
HarmonyJSSE -
com.android.org.conscrypt.JSSEProvider
-
AndroidKeyStore -
android.security.keystore.AndroidKeyStoreProvider
-
AndroidNSSP -
รายการด้านบนเป็นเพียงตัวอย่างบางส่วนเท่านั้น ความเข้ากันได้ Test Suite (CTS) จะทดสอบความเข้ากันได้ของแพลตฟอร์มในส่วนประกอบสำคัญ แต่ไม่ใช่ทั้งหมด ผู้ติดตั้งใช้งานมีหน้าที่ตรวจสอบความเข้ากันได้ด้านพฤติกรรมกับโครงการโอเพนซอร์ส Android ด้วยเหตุนี้ ผู้ติดตั้งอุปกรณ์จึงควรใช้ซอร์สโค้ดที่มีให้ผ่านทางโครงการโอเพนซอร์ส Android หากทำได้ แทนการนำส่วนต่างๆ ที่สำคัญของระบบมาใช้ใหม่
3.5.1 ข้อจำกัดแอปพลิเคชัน
หากการนำอุปกรณ์ไปใช้งานใช้กลไกที่เป็นกรรมสิทธิ์เพื่อจำกัดแอปและกลไกนั้นมีข้อจำกัดมากกว่าที่เก็บข้อมูลสแตนด์บายแอปหายาก สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-1-1] ต้องให้สิทธิ์เข้าถึงแก่ผู้ใช้ซึ่งผู้ใช้จะดูรายการแอปที่ถูกจำกัดได้
- [C-1-2] ต้องให้เงินแก่ผู้ใช้ในการเปิด / ปิดข้อจำกัดของแต่ละแอป
- [C-1-3] ต้องไม่ใช้ข้อจำกัดโดยอัตโนมัติโดยไม่มีหลักฐานแสดงการทำงานของระบบที่ไม่ดี แต่อาจใช้ข้อจำกัดกับแอปเมื่อตรวจพบลักษณะการทำงานที่ไม่มีประสิทธิภาพของระบบ เช่น การทำงานขณะล็อกที่ค้าง บริการที่ทำงานเป็นเวลานาน และเกณฑ์อื่นๆ เกณฑ์อาจกำหนดโดยผู้ติดตั้งใช้งานอุปกรณ์ แต่ต้องเกี่ยวข้องกับผลกระทบที่แอปมีต่อประสิทธิภาพของระบบ เกณฑ์อื่นๆ ที่ไม่เกี่ยวข้องกับประสิทธิภาพการทำงานของระบบเพียงอย่างเดียว เช่น แอปไม่ได้รับความนิยมในตลาด ต้องไม่ใช้เป็นเกณฑ์
- [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 ให้กับบริษัทอื่น Namespace - [C-0-6] ต้องมีแพ็กเกจในไลบรารีที่ใช้ร่วมกันของ Android เพื่อให้เฉพาะแอปที่ใช้งานอย่างชัดแจ้ง (ผ่านกลไก <uses-library>) ได้รับผลกระทบจากการใช้งานหน่วยความจำที่เพิ่มขึ้นของ API ดังกล่าว
หากผู้ติดตั้งใช้งานอุปกรณ์เสนอที่จะปรับปรุงเนมสเปซของแพ็กเกจรายการใดรายการหนึ่งข้างต้น (เช่น โดยการเพิ่มฟังก์ชันใหม่ที่มีประโยชน์ลงใน API ที่มีอยู่ หรือเพิ่ม API ใหม่) ผู้ติดตั้งใช้งานควรไปที่ source.android.com และเริ่มขั้นตอนการมีส่วนร่วมในการเปลี่ยนแปลงและโค้ดตามข้อมูลในเว็บไซต์นั้น
โปรดทราบว่าข้อจำกัดข้างต้นสอดคล้องกับแบบแผนมาตรฐานสำหรับการตั้งชื่อ API ในภาษาโปรแกรม Java ส่วนนี้เพียงแต่มีเป้าหมายเพื่อเน้นย้ำข้อตกลงเหล่านั้นและทำให้ข้อตกลงเหล่านั้นผูกพันด้วยการรวมไว้ในคำจำกัดความความเข้ากันได้นี้
3.7 ความเข้ากันได้ของรันไทม์
การติดตั้งใช้งานอุปกรณ์
-
[C-0-1] ต้องรองรับรูปแบบ Dalvik Executable (DEX) แบบเต็ม และข้อมูลจำเพาะและความหมายของไบต์โค้ด Dalvik
-
[C-0-2] ต้องกำหนดค่ารันไทม์ของ Dalvik เพื่อจัดสรรหน่วยความจำให้สอดคล้องกับแพลตฟอร์ม Android ต้นทางและตามที่ระบุไว้ในตารางต่อไปนี้ (โปรดดูส่วนที่ 7.1.1 สำหรับการกำหนดขนาดหน้าจอและความหนาแน่นของหน้าจอ)
-
ควรใช้ Android RunTime (ART) การติดตั้งใช้งานอัปสตรีมอ้างอิงของ Dalvik Executable Format และระบบการจัดการแพ็กเกจของการใช้ข้อมูลอ้างอิง
-
ควรเรียกใช้การทดสอบ Fuzz ภายใต้โหมดของการดำเนินการและสถาปัตยกรรมเป้าหมายที่หลากหลายเพื่อรักษาความเสถียรของรันไทม์ โปรดดู JFuzz และ DexFuzz ในเว็บไซต์โครงการโอเพนซอร์ส Android
โปรดทราบว่าค่าหน่วยความจำที่ระบุไว้ด้านล่างถือว่าเป็นค่าขั้นต่ำ และการใช้งานอุปกรณ์อาจจัดสรรหน่วยความจำต่อแอปพลิเคชันมากขึ้นได้
รูปแบบหน้าจอ | ความหนาแน่นของหน้าจอ | หน่วยความจำแอปพลิเคชันขั้นต่ำ |
---|---|---|
นาฬิกาข้อมือ Android | 120 dpi (ldpi) | 32MB |
140 dpi (140dpi) | ||
160 dpi (mdpi) | ||
180 dpi (180dpi) | ||
200 dpi (200dpi) | ||
213 dpi (tvdpi) | ||
220 dpi (220dpi) | 36MB | |
240 dpi (hdpi) | ||
280 dpi (280dpi) | ||
320 dpi (Xhdpi) | 48MB | |
360 dpi (360dpi) | ||
400 dpi (400dpi) | 56MB | |
420 dpi (420dpi) | 64MB | |
480 dpi (xxhdpi) | 88MB | |
560 dpi (560dpi) | 112MB | |
640 dpi (xxxhdpi) | 154MB | |
เล็ก/ปกติ | 120 dpi (ldpi) | 32MB |
140 dpi (140dpi) | ||
160 dpi (mdpi) | ||
180 dpi (180dpi) | 48MB | |
200 dpi (200dpi) | ||
213 dpi (tvdpi) | ||
220 dpi (220dpi) | ||
240 dpi (hdpi) | ||
280 dpi (280dpi) | ||
320 dpi (Xhdpi) | 80MB | |
360 dpi (360dpi) | ||
400 dpi (400dpi) | 96MB | |
420 dpi (420dpi) | 112MB | |
480 dpi (xxhdpi) | 128MB | |
560 dpi (560dpi) | 192MB | |
640 dpi (xxxhdpi) | 256MB | |
ใหญ่ | 120 dpi (ldpi) | 32MB |
140 dpi (140dpi) | 48MB | |
160 dpi (mdpi) | ||
180 dpi (180dpi) | 80MB | |
200 dpi (200dpi) | ||
213 dpi (tvdpi) | ||
220 dpi (220dpi) | ||
240 dpi (hdpi) | ||
280 dpi (280dpi) | 96MB | |
320 dpi (Xhdpi) | 128MB | |
360 dpi (360dpi) | 160MB | |
400 dpi (400dpi) | 192MB | |
420 dpi (420dpi) | 228MB | |
480 dpi (xxhdpi) | 256MB | |
560 dpi (560dpi) | 384MB | |
640 dpi (xxxhdpi) | 512MB | |
xlarge | 120 dpi (ldpi) | 48MB |
140 dpi (140dpi) | 80MB | |
160 dpi (mdpi) | ||
180 dpi (180dpi) | 96MB | |
200 dpi (200dpi) | ||
213 dpi (tvdpi) | ||
220 dpi (220dpi) | ||
240 dpi (hdpi) | ||
280 dpi (280dpi) | 144MB | |
320 dpi (Xhdpi) | 192MB | |
360 dpi (360dpi) | 240MB | |
400 dpi (400dpi) | 288MB | |
420 dpi (420dpi) | 336MB | |
480 dpi (xxhdpi) | 384MB | |
560 dpi (560dpi) | 576MB | |
640 dpi (xxxhdpi) | 768MB |
3.8 ความเข้ากันได้ของอินเทอร์เฟซผู้ใช้
3.8.1 Launcher (หน้าจอหลัก)
Android มีแอปพลิเคชัน Launcher (หน้าจอหลัก) และการสนับสนุนแอปพลิเคชันของบุคคลที่สามเพื่อแทนที่ Launcher ของอุปกรณ์ (หน้าจอหลัก)
หากการใช้งานอุปกรณ์อนุญาตให้แอปพลิเคชันของบุคคลที่สามแทนที่หน้าจอหลักของอุปกรณ์ได้ การดำเนินการดังกล่าวจะส่งผลดังนี้
- [C-1-1] ต้องประกาศฟีเจอร์ของแพลตฟอร์ม
android.software.home_screen
- [C-1-2] ต้องแสดงผลออบเจ็กต์
AdaptiveIconDrawable
เมื่อแอปพลิเคชันของบุคคลที่สามใช้แท็ก<adaptive-icon>
เพื่อระบุไอคอน และจะเรียกใช้เมธอดPackageManager
เพื่อเรียกไอคอน
หากอุปกรณ์มี Launcher เริ่มต้นที่รองรับการปักหมุดทางลัดในแอป ระบบจะดำเนินการต่อไปนี้
- [C-2-1] ต้องรายงาน
true
สำหรับShortcutManager.isRequestPinShortcutSupported()
- [C-2-2] ต้องมีสิทธิ์การเข้าถึงของผู้ใช้ในการถามผู้ใช้ก่อนเพิ่มทางลัดที่ขอโดยแอปผ่านเมธอด
ShortcutManager.requestPinShortcut()
API - [C-2-3] ต้องรองรับแป้นพิมพ์ลัดที่ปักหมุดไว้ รวมถึงทางลัดแบบไดนามิกและแบบคงที่ตามที่ระบุไว้ในหน้าทางลัดของแอป
ในทางกลับกัน หากอุปกรณ์ไม่รองรับการปักหมุดทางลัดในแอป ระบบจะดำเนินการต่อไปนี้
- [C-3-1] ต้องรายงาน
false
สำหรับShortcutManager.isRequestPinShortcutSupported()
หากการนำอุปกรณ์ไปใช้งานใช้ Launcher เริ่มต้นที่ให้การเข้าถึงด่วนไปยังทางลัดเพิ่มเติมที่มาจากแอปของบุคคลที่สามผ่าน ShortcutManager API แป้นพิมพ์ลัดดังกล่าวจะมีผลดังนี้
- [C-4-1] ต้องรองรับฟีเจอร์ทางลัดทั้งหมดที่บันทึกไว้ (เช่น ทางลัดแบบคงที่และแบบไดนามิก ทางลัดการปักหมุด) และใช้ API ของคลาส API
ShortcutManager
อย่างเต็มรูปแบบ
หากการใช้งานอุปกรณ์มีแอป Launcher เริ่มต้นซึ่งแสดงป้ายสำหรับไอคอนแอปต่างๆ อุปกรณ์จะมีลักษณะดังนี้
- [C-5-1] ต้องเป็นไปตามเมธอด API ของ
NotificationChannel.setShowBadge()
กล่าวคือ แสดงความสามารถในการมองเห็นที่เชื่อมโยงกับไอคอนแอปหากกำหนดค่าไว้เป็นtrue
และไม่แสดงรูปแบบการติดป้ายไอคอนแอปเมื่อช่องทางการแจ้งเตือนทั้งหมดของแอปกำหนดค่าเป็นfalse
- อาจลบล้างป้ายไอคอนแอปด้วยรูปแบบการติดป้ายที่เป็นกรรมสิทธิ์เมื่อแอปพลิเคชันของบุคคลที่สามระบุการรองรับรูปแบบการติดป้ายที่เป็นกรรมสิทธิ์ผ่านการใช้ API ที่เป็นกรรมสิทธิ์ แต่ควรใช้ทรัพยากรและค่าที่ให้ไว้ผ่าน API ป้ายการแจ้งเตือนที่อธิบายไว้ใน SDK เช่น
Notification.Builder.setNumber()
และNotification.Builder.setBadgeIconType()
API
3.8.2 วิดเจ็ต
Android รองรับวิดเจ็ตแอปของบุคคลที่สามโดยการกำหนดประเภทคอมโพเนนต์และ API และวงจรการใช้งานที่เกี่ยวข้องที่อนุญาตให้แอปพลิเคชันแสดง "AppWidget" แก่ผู้ใช้ปลายทาง
หากการใช้งานอุปกรณ์รองรับวิดเจ็ตแอปของบุคคลที่สาม วิดเจ็ตจะดำเนินการดังนี้
- [C-1-1] ต้องประกาศการรองรับฟีเจอร์แพลตฟอร์ม
android.software.app_widgets
- [C-1-2] ต้องมีการรองรับ AppWidgets ในตัวและแสดงความสามารถของอินเทอร์เฟซผู้ใช้เพื่อเพิ่ม กำหนดค่า ดู และนำ AppWidgets ออกภายใน Launcher โดยตรง
- [C-1-3] ต้องแสดงภาพวิดเจ็ตขนาด 4 x 4 ในขนาดตารางกริดมาตรฐานได้ โปรดดูรายละเอียดที่หลักเกณฑ์การออกแบบวิดเจ็ตของแอปในเอกสารประกอบ Android SDK
- อาจสนับสนุนวิดเจ็ตของแอปพลิเคชันบนหน้าจอล็อก
หากการใช้งานอุปกรณ์รองรับวิดเจ็ตแอปของบุคคลที่สามและการปักหมุดทางลัดในแอป ระบบจะดำเนินการต่อไปนี้
- [C-2-1] ต้องรายงาน
true
สำหรับAppWidgetManager.html.isRequestPinAppWidgetSupported()
- [C-2-2] ต้องมีสิทธิ์การเข้าถึงของผู้ใช้ในการถามผู้ใช้ก่อนเพิ่มทางลัดที่ขอโดยแอปผ่านเมธอด
AppWidgetManager.requestPinAppWidget()
API
3.8.3 การแจ้งเตือน
Android มี API ของ Notification
และ NotificationManager
ที่ช่วยให้นักพัฒนาแอปของบุคคลที่สามสามารถแจ้งผู้ใช้เกี่ยวกับกิจกรรมที่น่าสนใจและดึงดูดผู้ใช้ ความสนใจโดยใช้ส่วนประกอบของฮาร์ดแวร์ (เช่น เสียง การสั่น และแสง) และฟีเจอร์ของซอฟต์แวร์ (เช่น หน้าต่างแจ้งเตือน แถบระบบ) ของอุปกรณ์
3.8.3.1 การนำเสนอการแจ้งเตือน
หากการนำอุปกรณ์ไปใช้งานอนุญาตให้แอปของบุคคลที่สามแจ้งเตือนผู้ใช้เกี่ยวกับเหตุการณ์ที่น่าจดจำ สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-1-1] ต้องรองรับการแจ้งเตือนที่ใช้ฟีเจอร์ของฮาร์ดแวร์ตามที่อธิบายไว้ในเอกสารประกอบของ SDK และในขอบเขตที่เป็นไปได้สำหรับฮาร์ดแวร์การติดตั้งใช้งานอุปกรณ์ ตัวอย่างเช่น ถ้าการใช้งานอุปกรณ์มีการสั่นเตือน อุปกรณ์นั้นต้องใช้ API การสั่นอย่างถูกต้อง หากการใช้งานอุปกรณ์ขาดฮาร์ดแวร์ ต้องติดตั้งใช้งาน API ที่เกี่ยวข้องเป็นแบบไม่ต้องดำเนินการ ดูรายละเอียดการทำงานนี้เพิ่มเติมในส่วนที่ 7
- [C-1-2] ต้องแสดงทรัพยากร (ไอคอน ไฟล์ภาพเคลื่อนไหว ฯลฯ) ทั้งหมดที่มีให้ใน API หรือในคู่มือรูปแบบไอคอนของแถบสถานะ/แถบระบบได้อย่างถูกต้อง แม้ว่าเครื่องมือเหล่านี้อาจให้ประสบการณ์ทางเลือกสำหรับผู้ใช้สำหรับการแจ้งเตือนนอกเหนือจากที่ได้มาจากการใช้งานโอเพนซอร์สของ Android อ้างอิง
- [C-1-3] ต้องยึดตามและดำเนินการตามลักษณะการทำงานที่อธิบายไว้สำหรับ API อย่างเหมาะสมในการอัปเดต นำออก และรับการแจ้งเตือนของกลุ่ม
- [C-1-4] ต้องระบุลักษณะการทำงานทั้งหมดของ NotificationChannel API ที่บันทึกไว้ใน SDK
- [C-1-5] ต้องเสนอค่าตอบแทนให้กับผู้ใช้ในการบล็อกและแก้ไขการแจ้งเตือนของแอปบุคคลที่สามตามช่องทางและระดับแพ็กเกจแอปแต่ละช่อง
- [C-1-6] ต้องให้สิทธิ์เข้าถึงแก่ผู้ใช้ในการแสดงช่องทางการแจ้งเตือนที่ลบไปแล้ว
- [C-1-7] ต้องแสดงผลทรัพยากรทั้งหมด (รูปภาพ สติกเกอร์ ไอคอน ฯลฯ) ที่จัดเตรียมไว้อย่างถูกต้องผ่าน Notification.MessagingStyle พร้อมกับข้อความแจ้งเตือนโดยไม่ต้องโต้ตอบกับผู้ใช้เพิ่มเติม เช่น "ต้อง" แสดงทรัพยากรทั้งหมดรวมถึงไอคอนที่มีให้ผ่าน android.app.Person ในการสนทนากลุ่มที่ตั้งค่าไว้ผ่าน setGroupConversation
- [C-SR] ขอแนะนำอย่างยิ่งให้แสดงตัวเลือกแก่ผู้ใช้โดยอัตโนมัติในการบล็อกการแจ้งเตือนของแอปของบุคคลที่สามตามช่องทางและระดับแพ็กเกจแอปแต่ละรายการ หลังจากที่ผู้ใช้ปิดการแจ้งเตือนหลายครั้งแล้ว
- ควรรองรับการแจ้งเตือนที่สมบูรณ์
- ควรแสดงการแจ้งเตือนที่มีลำดับความสำคัญสูงกว่าเป็นการแจ้งเตือนล่วงหน้า
- ผู้ใช้ควรสามารถเลื่อนการแจ้งเตือน
- อาจจัดการได้เฉพาะระดับการเข้าถึงและช่วงเวลาที่แอปของบุคคลที่สามสามารถแจ้งเตือนผู้ใช้เกี่ยวกับเหตุการณ์ที่น่าจดจำ เพื่อลดปัญหาด้านความปลอดภัย เช่น การรบกวนผู้ขับขี่
Android 11 เพิ่มการรองรับการแจ้งเตือนการสนทนา ซึ่งเป็นการแจ้งเตือนที่ใช้ MessagingStyle และให้รหัสทางลัดของ People ที่เผยแพร่แล้ว
การติดตั้งใช้งานอุปกรณ์
- [C-SR] ขอแนะนำอย่างยิ่งให้จัดกลุ่มและแสดง
conversation notifications
ก่อนการแจ้งเตือนที่ไม่ใช่การสนทนา ยกเว้นการแจ้งเตือนบริการที่ทำงานอยู่เบื้องหน้าและการแจ้งเตือนของimportance:high
ที่ดำเนินอยู่
หากการติดตั้งใช้งานอุปกรณ์รองรับ conversation notifications
และแอปให้ข้อมูลที่จำเป็นสำหรับ bubbles
อุปกรณ์ดังกล่าวจะดำเนินการดังนี้
- [C-SR] ขอแนะนำอย่างยิ่งให้แสดงการสนทนานี้เป็นบับเบิล การใช้งาน AOSP จะเป็นไปตามข้อกำหนดเหล่านี้พร้อมด้วย UI, การตั้งค่า และ Launcher เริ่มต้นของระบบ
หากอุปกรณ์รองรับการแจ้งเตือนที่สมบูรณ์ สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-2-1] ต้องใช้ทรัพยากรตามที่ระบุไว้ผ่านคลาส API
Notification.Style
และคลาสย่อยสำหรับองค์ประกอบทรัพยากรที่แสดงอยู่ - ควรนำเสนอองค์ประกอบทรัพยากรแต่ละรายการ (เช่น ไอคอน ชื่อ และข้อความสรุป) ที่กำหนดไว้ในคลาส API
Notification.Style
และคลาสย่อย
หากการใช้งานอุปกรณ์รองรับการแจ้งเตือนล่วงหน้า สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-3-1] ต้องใช้มุมมองการแจ้งเตือนล่วงหน้าและทรัพยากรตามที่อธิบายไว้ในคลาส API ของ
Notification.Builder
เมื่อมีการแสดงการแจ้งเตือนล่วงหน้า - [C-3-2] ต้องแสดงการดำเนินการที่ได้รับจาก
Notification.Builder.addAction()
ร่วมกับเนื้อหาการแจ้งเตือน โดยไม่ต้องมีการโต้ตอบเพิ่มเติมจากผู้ใช้ตามที่อธิบายไว้ใน SDK
3.8.3.2 บริการฟังการแจ้งเตือน
Android มี API ของ NotificationListenerService
ที่อนุญาตให้แอป (เมื่อผู้ใช้เปิดใช้อย่างชัดแจ้ง) เพื่อรับสำเนาของการแจ้งเตือนทั้งหมดเมื่อมีการโพสต์หรืออัปเดต
การติดตั้งใช้งานอุปกรณ์
- [C-0-1] ต้องอัปเดตการแจ้งเตือนทั้งหมดอย่างถูกต้องและทันท่วงทีสำหรับบริการ Listener ที่ติดตั้งและเปิดใช้งานดังกล่าวทั้งหมด รวมถึงข้อมูลเมตาทั้งหมดที่แนบกับออบเจ็กต์การแจ้งเตือน
- [C-0-2] ต้องเป็นไปตามการเรียกใช้ API
snoozeNotification()
และปิดการแจ้งเตือนและทำการติดต่อกลับหลังจากระยะเวลาเลื่อนการแจ้งเตือนซึ่งกำหนดไว้ในการเรียก API
หากการติดตั้งอุปกรณ์ทำให้ผู้ใช้สามารถเลื่อนการแจ้งเตือนได้ สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-1-1] ต้องแสดงสถานะการแจ้งเตือนเลื่อนการแจ้งเตือนอย่างถูกต้องผ่าน API มาตรฐาน เช่น
NotificationListenerService.getSnoozedNotifications()
- [C-1-2] ต้องทำให้ผู้ใช้รายนี้มีสิทธิ์เข้าถึงเพื่อปิดการแจ้งเตือนชั่วคราวจากแอปของบุคคลที่สามแต่ละแอปที่ติดตั้ง ยกเว้นว่ามาจากบริการที่ทำงานอยู่เบื้องหน้า/ถาวร
3.8.3.3 DND (ห้ามรบกวน)
หากอุปกรณ์รองรับฟีเจอร์ DND ระบบจะดำเนินการดังต่อไปนี้
- [C-1-1] เมื่อการใช้อุปกรณ์ระบุวิธีการให้ผู้ใช้ให้สิทธิ์หรือปฏิเสธแอปของบุคคลที่สามในการเข้าถึงการกำหนดค่านโยบาย DND ให้แสดงกฎ DND อัตโนมัติที่สร้างโดยแอปพลิเคชันพร้อมกับกฎที่ผู้ใช้สร้างขึ้นและที่กำหนดไว้ล่วงหน้า
- [C-1-3] ต้องปฏิบัติตามค่า
suppressedVisualEffects
ที่ส่งผ่านNotificationManager.Policy
และหากแอปตั้งค่าแฟล็ก SUPPRESSED_EFFECT_SCREEN_OFF หรือ SUPPRESSED_EFFECT_SCREEN_ON ควรแจ้งให้ผู้ใช้ทราบว่าเอฟเฟกต์ภาพไม่แสดงในเมนูการตั้งค่า DND
3.8.4 ค้นหา
Android มี API ที่เปิดโอกาสให้นักพัฒนาซอฟต์แวร์รวมการค้นหาไว้ในแอปพลิเคชันของตนและเปิดเผยข้อมูลของแอปพลิเคชันในการค้นหาระบบทั่วโลก กล่าวโดยทั่วไปคือ ฟังก์ชันการทำงานนี้ประกอบด้วยอินเทอร์เฟซผู้ใช้แบบทั้งระบบแบบเดียวที่ให้ผู้ใช้สามารถป้อนคำค้นหา แสดงคำแนะนำขณะที่ผู้ใช้พิมพ์ และแสดงผลลัพธ์ได้ Android API ช่วยให้นักพัฒนาแอปนำอินเทอร์เฟซนี้กลับมาใช้ใหม่เพื่อให้บริการการค้นหาภายในแอปของตนเองและช่วยให้นักพัฒนาแอปแสดงผลการค้นหาไปยังอินเทอร์เฟซผู้ใช้ทั่วไปของการค้นหาส่วนกลางได้
- การใช้งานอุปกรณ์ Android ควรมีการค้นหาส่วนกลาง อินเทอร์เฟซผู้ใช้การค้นหาแบบใช้ร่วมกันการค้นหาทั้งระบบที่สามารถให้คำแนะนำแบบเรียลไทม์เพื่อตอบสนองต่อข้อมูลจากผู้ใช้
หากการติดตั้งใช้งานอุปกรณ์ใช้อินเทอร์เฟซการค้นหาส่วนกลาง
- [C-1-1] ต้องใช้ API ที่อนุญาตให้แอปพลิเคชันของบุคคลที่สามเพิ่มคำแนะนำในช่องค้นหาเมื่อทำงานในโหมดการค้นหาส่วนกลาง
หากไม่ได้ติดตั้งแอปพลิเคชันของบุคคลที่สามที่ใช้การค้นหาส่วนกลาง
- ลักษณะการทำงานเริ่มต้นควรเป็น แสดงผลการค้นหาและคำแนะนำของเครื่องมือค้นหาเว็บ
Android ยังมี Assist API เพื่อให้แอปพลิเคชันเลือกได้ว่าจะแชร์ข้อมูลบริบทปัจจุบันกับ Assistant ในอุปกรณ์มากน้อยแค่ไหน
หากการติดตั้งใช้งานอุปกรณ์รองรับการดำเนินการสนับสนุน การดำเนินการต่อไปนี้จะเกิดขึ้น
- [C-2-1] ต้องระบุอย่างชัดเจนถึงผู้ใช้ปลายทางเมื่อมีการแชร์บริบท โดยทำอย่างใดอย่างหนึ่งต่อไปนี้
- ทุกครั้งที่แอปผู้ช่วยเข้าถึงบริบท ระบบจะแสดงไฟสีขาวรอบขอบหน้าจอที่ด้านหรือเกินระยะเวลาและความสว่างของการดำเนินโครงการโอเพนซอร์ส Android
- สำหรับแอปผู้ช่วยที่ติดตั้งไว้ล่วงหน้า ให้ผู้ใช้มีการนำทางน้อยกว่า 2 ด้านในการป้อนข้อมูลด้วยเสียงเริ่มต้นและเมนูการตั้งค่าแอปผู้ช่วย และจะแชร์บริบทเมื่อผู้ใช้เรียกใช้แอปผู้ช่วยอย่างชัดเจนผ่านการป้อนข้อมูลด้วยคำสั่งให้ดำเนินการหรือการป้อนข้อมูลผ่านแป้นนำทางช่วยเท่านั้น
- [C-2-2] การโต้ตอบที่กำหนดเพื่อเปิดแอปผู้ช่วยตามที่อธิบายไว้ในส่วนที่ 7.2.3 ต้องเปิดแอปผู้ช่วยที่ผู้ใช้เลือก กล่าวคือ แอปที่ใช้
VoiceInteractionService
หรือกิจกรรมที่จัดการ IntentACTION_ASSIST
3.8.5 การแจ้งเตือนและขนมปังปิ้ง
แอปพลิเคชันสามารถใช้ Toast
API เพื่อแสดงสตริงที่ไม่ใช่โมดัลสั้นๆ แก่ผู้ใช้ปลายทางซึ่งจะหายไปหลังจากช่วงเวลาสั้นๆ และใช้ API ประเภทหน้าต่าง TYPE_APPLICATION_OVERLAY
เพื่อแสดงหน้าต่างการแจ้งเตือนเป็นหน้าต่างวางซ้อนเหนือแอปอื่นๆ
หากการใช้งานอุปกรณ์มีหน้าจอหรือเอาต์พุตวิดีโอ ระบบจะดำเนินการดังต่อไปนี้
-
[C-1-1] ต้องเสนอค่าตอบแทนให้กับผู้ใช้ในการบล็อกแอปไม่ให้แสดงหน้าต่างการแจ้งเตือนที่ใช้
TYPE_APPLICATION_OVERLAY
การใช้งาน AOSP เป็นไปตามข้อกำหนดนี้โดยการควบคุมในหน้าต่างแจ้งเตือน -
[C-1-2] ต้องปฏิบัติตาม Toast API และแสดง Toasts จากแอปพลิเคชันแก่ผู้ใช้ปลายทางในลักษณะที่เห็นได้ชัดเจน
3.8.6 ธีม
Android มี "ธีม" เป็นกลไกเพื่อให้แอปพลิเคชันนำสไตล์ไปใช้กับทั้งกิจกรรมหรือแอปพลิเคชัน
Android มี "Holo" และ "Material" ชุดธีมเป็นชุดรูปแบบที่กำหนดไว้เพื่อให้นักพัฒนาแอปพลิเคชันใช้หากต้องการให้ตรงกับรูปลักษณ์ของธีม Holo ตามที่ Android SDK กำหนด
หากการใช้งานอุปกรณ์มีหน้าจอหรือเอาต์พุตวิดีโอ ระบบจะดำเนินการดังต่อไปนี้
- [C-1-1] ต้องไม่เปลี่ยนแปลงแอตทริบิวต์ธีม Holo ที่แอปพลิเคชันเห็น
- [C-1-2] ต้องรองรับกลุ่มธีม "Material" และต้องไม่เปลี่ยนแปลงแอตทริบิวต์ธีม Material หรือเนื้อหาที่แสดงในแอปพลิเคชัน
- [C-1-3] ต้องตั้งค่า "sans-serif" ชุดแบบอักษรเป็น Roboto เวอร์ชัน 2.x สำหรับภาษาที่ Roboto รองรับ หรือเสนอค่าใช้จ่ายในการเปลี่ยนแบบอักษรที่ใช้สำหรับ "sans-serif" ชุดแบบอักษรเป็น Roboto เวอร์ชัน 2.x สำหรับภาษาที่ Roboto รองรับ
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 การควบคุมสื่อสำหรับหน้าจอล็อก
API ไคลเอ็นต์รีโมตคอนโทรลเลิกใช้งานจาก Android 5.0 แล้วไปสนับสนุนเทมเพลตการแจ้งเตือนสื่อที่ช่วยให้แอปพลิเคชันสื่อสามารถผสานรวมเข้ากับตัวควบคุมการเล่นที่แสดงบนหน้าจอล็อก
3.8.11 ภาพพักหน้าจอ (ก่อนหน้านี้เรียกว่า Dreams)
ดูส่วนที่ 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 แบบสมบูรณ์ของภาษาละติน กรีก และซีริลลิก รวมถึงช่วงภาษาละติน Extended 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] ต้องโหลด Launcher ที่ปรับขนาดได้ไว้ล่วงหน้าเป็นค่าเริ่มต้น
- [C-2-2] ต้องครอบตัดกิจกรรมที่อยู่บนแท่นชาร์จของหลายหน้าต่างในโหมดแยกหน้าจอ แต่ควรแสดงเนื้อหาบางอย่าง หากแอป Launcher เป็นหน้าต่างที่โฟกัสอยู่
- [C-2-3] ต้องปฏิบัติตามค่า
AndroidManifestLayout_minWidth
และAndroidManifestLayout_minHeight
ที่ประกาศไว้ของแอปพลิเคชัน Launcher ของบุคคลที่สาม และไม่ลบล้างค่าเหล่านี้ในช่วงที่แสดงเนื้อหาบางส่วนของกิจกรรมบนแท่นชาร์จ
หากการใช้งานอุปกรณ์รองรับโหมดหลายหน้าต่างและโหมดหลายหน้าต่างการแสดงภาพซ้อนภาพ ระบบจะดำเนินการต่อไปนี้
- [C-3-1] ต้องเปิดกิจกรรมในโหมดหลายหน้าต่างการแสดงภาพซ้อนภาพเมื่อแอปดำเนินการต่อไปนี้ * API การกำหนดเป้าหมายระดับ 26 ขึ้นไปและประกาศ
android:supportsPictureInPicture
* API การกำหนดเป้าหมายระดับ 25 หรือต่ำกว่า และประกาศทั้งandroid:resizeableActivity
และandroid:supportsPictureInPicture
- [C-3-2] ต้องแสดงการดำเนินการใน SystemUI ตามที่ระบุโดยกิจกรรม PIP ปัจจุบันผ่าน
setActions()
API - [C-3-3] ต้องรองรับสัดส่วนภาพที่มากกว่าหรือเท่ากับ 1:2.39 และน้อยกว่าหรือเท่ากับ 2.39:1 ตามที่ระบุไว้โดยกิจกรรม PIP ผ่าน
setAspectRatio()
API - [C-3-4] ต้องใช้
KeyEvent.KEYCODE_WINDOW
เพื่อควบคุมหน้าต่าง PIP หากไม่ได้ใช้โหมด PIP คีย์ "ต้อง" พร้อมใช้งานสำหรับกิจกรรมเบื้องหน้า - [C-3-5] ต้องเสนอค่าตอบแทนให้กับผู้ใช้ในการบล็อกแอปไม่ให้แสดงในโหมด PIP การติดตั้งใช้งาน AOSP เป็นไปตามข้อกำหนดนี้โดยการควบคุมในหน้าต่างแจ้งเตือน
-
[C-3-6] ต้องจัดสรรความกว้างและความสูงขั้นต่ำต่อไปนี้สำหรับหน้าต่าง PIP เมื่อแอปพลิเคชันไม่ได้ประกาศค่าใดๆ สำหรับ
AndroidManifestLayout_minWidth
และAndroidManifestLayout_minHeight
:- อุปกรณ์ที่มี Configuration.uiMode ที่ตั้งค่าอื่นที่ไม่ใช่
UI_MODE_TYPE_TELEVISION
ต้องจัดสรรความกว้างและความสูงขั้นต่ำเป็น 108 dp - อุปกรณ์ที่มี Configuration.uiMode ที่ตั้งค่าเป็น
UI_MODE_TYPE_TELEVISION
ต้องจัดสรรความกว้างอย่างน้อย 240 dp และความสูงขั้นต่ำ 135 dp
- อุปกรณ์ที่มี Configuration.uiMode ที่ตั้งค่าอื่นที่ไม่ใช่
3.8.15 หน้าจอรอยบาก
Android รองรับหน้าจอรอยบากตามที่อธิบายไว้ในเอกสาร SDK DisplayCutout
API กำหนดพื้นที่ที่ขอบของจอแสดงผลซึ่งอาจใช้งานไม่ได้สำหรับแอปพลิเคชันเนื่องจากมีหน้าจอรอยบากหรือหน้าจอโค้ง
หากการใช้งานอุปกรณ์รวมหน้าจอรอยบากไว้ จะมีผลดังนี้
- [C-1-5] ต้องไม่มีรอยบากหากสัดส่วนภาพของอุปกรณ์คือ 1.0(1:1)
- [C-1-2] ต้องไม่มีคัตเอาต์มากกว่า 1 คัตเอาต์ต่อขอบ
- [C-1-3] ต้องปฏิบัติตาม Flag หน้าจอรอยบากที่แอปกำหนดผ่าน
WindowManager.LayoutParams
API ตามที่อธิบายไว้ใน SDK - [C-1-4] ต้องรายงานค่าที่ถูกต้องสำหรับเมตริกคัตเอาต์ทั้งหมดที่กำหนดไว้ใน
DisplayCutout
API
3.8.16 ระบบควบคุมอุปกรณ์
Android มี 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] ต้องรองรับการลงทะเบียนไคลเอ็นต์ Device Policy (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 ที่มีระเบียนประเภท MIMEMIME_TYPE_PROVISIONING_NFC
- [C-1-3] ต้องรายงาน
- เมื่อติดตั้งอุปกรณ์มีข้อมูลผู้ใช้ จะดำเนินการดังนี้
- [C-1-6] ต้องรายงาน
false
สำหรับDevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE)
- [C-1-7] ต้องไม่ลงทะเบียนแอปพลิเคชัน DPC เป็นแอปเจ้าของอุปกรณ์อีกต่อไป
- [C-1-6] ต้องรายงาน
- เมื่อการติดตั้งใช้งานอุปกรณ์ยังไม่มีข้อมูลผู้ใช้ ระบบจะดำเนินการดังนี้
- [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] ต้องระบุค่าบริการต่อไปนี้ของผู้ใช้ภายในการตั้งค่า เพื่อแจ้งให้ผู้ใช้ทราบเมื่อตัวควบคุมนโยบายด้านอุปกรณ์ (DPC) ปิดใช้งานฟังก์ชันของระบบบางอย่าง
- ไอคอนที่สอดคล้องกันหรือการชำระเงินอื่นๆ ของผู้ใช้ (เช่น ไอคอนข้อมูล AOSP ต้นทาง) เพื่อแสดงเมื่อผู้ดูแลระบบอุปกรณ์จำกัดการตั้งค่าบางอย่าง
- ข้อความอธิบายสั้นๆ ตามที่ผู้ดูแลระบบอุปกรณ์ระบุไว้ผ่าน
setShortSupportMessage
- ไอคอนของแอปพลิเคชัน DPC
3.9.2 การรองรับโปรไฟล์ที่มีการจัดการ
การใช้งานอุปกรณ์จะประกาศ android.software.managed_users
ดังต่อไปนี้
- [C-1-1] ต้องรองรับโปรไฟล์ที่มีการจัดการผ่าน API ของ
android.app.admin.DevicePolicyManager
- [C-1-2] ต้องอนุญาตให้สร้างโปรไฟล์ที่มีการจัดการได้ 1 รายการเท่านั้น
- [C-1-3] ต้องใช้ป้ายไอคอน (คล้ายกับป้ายงานต้นทางของ AOSP) เพื่อแสดงแอปพลิเคชันและวิดเจ็ตที่มีการจัดการ และองค์ประกอบ UI ที่มีตราสถานะอื่นๆ เช่น ล่าสุด & การแจ้งเตือน
- [C-1-4] ต้องแสดงไอคอนการแจ้งเตือน (คล้ายกับป้ายงานต้นทางของ AOSP) เพื่อระบุว่าผู้ใช้อยู่ในแอปพลิเคชันโปรไฟล์ที่มีการจัดการเมื่อใด
- [C-1-5] ต้องแสดงข้อความโทสต์ที่ระบุว่าผู้ใช้อยู่ในโปรไฟล์ที่มีการจัดการหากและเมื่ออุปกรณ์เริ่มทำงาน (ACTION_USER_PRESENT) และแอปพลิเคชันที่ทำงานอยู่เบื้องหน้าอยู่ภายในโปรไฟล์ที่มีการจัดการ
- [C-1-6] เมื่อมีโปรไฟล์ที่มีการจัดการอยู่ จะต้องมีความสามารถในการมองเห็นได้ใน "ตัวเลือก" ของ Intent เพื่ออนุญาตให้ผู้ใช้ส่งต่อความตั้งใจจากโปรไฟล์ที่มีการจัดการไปยังผู้ใช้หลัก หรือในทางกลับกัน หากเปิดใช้โดยเครื่องมือควบคุมนโยบายด้านอุปกรณ์
- [C-1-7] ในกรณีที่มีโปรไฟล์ที่มีการจัดการอยู่ จะต้องมีการจ่ายเงินสำหรับผู้ใช้ดังต่อไปนี้สำหรับทั้งผู้ใช้หลักและโปรไฟล์ที่มีการจัดการ
- แยกการพิจารณาการใช้งานแบตเตอรี่ ตำแหน่ง อินเทอร์เน็ตมือถือ และพื้นที่เก็บข้อมูลสำหรับผู้ใช้หลักและโปรไฟล์ที่มีการจัดการ
- การจัดการแอปพลิเคชัน VPN ที่ติดตั้งภายในผู้ใช้หลักหรือโปรไฟล์ที่มีการจัดการโดยอิสระ
- การจัดการอิสระของแอปพลิเคชันที่ติดตั้งภายในผู้ใช้หลักหรือโปรไฟล์ที่มีการจัดการ
- การจัดการบัญชีอิสระภายในผู้ใช้หลักหรือโปรไฟล์ที่มีการจัดการ
- [C-1-8] ต้องตรวจสอบว่าแอปพลิเคชันแป้นโทรศัพท์ ที่อยู่ติดต่อ และข้อความที่ติดตั้งไว้ล่วงหน้าสามารถค้นหาและค้นหาข้อมูลผู้โทรจากโปรไฟล์ที่มีการจัดการ (หากมี) ควบคู่ไปกับโปรไฟล์จากโปรไฟล์หลักได้ หากตัวควบคุมนโยบายด้านอุปกรณ์อนุญาต
- [C-1-9] ต้องตรวจสอบว่าโปรไฟล์นั้นเป็นไปตามข้อกำหนดด้านความปลอดภัยทั้งหมดที่บังคับใช้กับอุปกรณ์ที่เปิดใช้ผู้ใช้หลายคน (ดูส่วนที่ 9.5) แม้ว่าโปรไฟล์ที่มีการจัดการจะไม่นับเป็นผู้ใช้รายอื่นนอกเหนือจากผู้ใช้หลัก
หากการติดตั้งใช้งานอุปกรณ์ประกาศ android.software.managed_users
และ android.software.secure_lock_screen
เงื่อนไขจะมีลักษณะดังนี้
- [C-2-1] ต้องรองรับความสามารถในการระบุหน้าจอล็อกแยกต่างหากที่เป็นไปตามข้อกำหนดต่อไปนี้ เพื่อให้สิทธิ์เข้าถึงแอปที่ทำงานในโปรไฟล์ที่มีการจัดการเท่านั้น
- การนำอุปกรณ์ไปใช้งานต้องเป็นไปตาม Intent ของ
DevicePolicyManager.ACTION_SET_NEW_PASSWORD
และแสดงอินเทอร์เฟซเพื่อกำหนดค่าข้อมูลเข้าสู่ระบบในหน้าจอล็อกแยกต่างหากสำหรับโปรไฟล์ที่มีการจัดการ - ข้อมูลเข้าสู่ระบบในหน้าจอล็อกของโปรไฟล์ที่มีการจัดการต้องใช้ที่เก็บข้อมูลเข้าสู่ระบบและกลไกการจัดการเดียวกับโปรไฟล์หลักตามที่ระบุไว้ในเว็บไซต์โครงการโอเพนซอร์สของ Android
- นโยบายรหัสผ่านของ DPC ต้องมีผลเฉพาะกับข้อมูลเข้าสู่ระบบบนหน้าจอล็อกของโปรไฟล์ที่มีการจัดการ เว้นแต่ว่ามีการเรียกใช้อินสแตนซ์
DevicePolicyManager
ที่แสดงผลโดย getParentProfileInstance
- การนำอุปกรณ์ไปใช้งานต้องเป็นไปตาม Intent ของ
- เมื่อรายชื่อติดต่อจากโปรไฟล์ที่มีการจัดการแสดงในบันทึกการโทรที่ติดตั้งไว้ล่วงหน้า, UI ระหว่างการโทร, การแจ้งเตือนระหว่างสายและสายที่ไม่ได้รับ รายชื่อติดต่อและแอปรับส่งข้อความ รายชื่อติดต่อดังกล่าวควรมีป้ายติดป้ายเดียวกับที่ใช้เพื่อระบุแอปพลิเคชันโปรไฟล์ที่มีการจัดการ
3.9.3 การสนับสนุนผู้ใช้ที่มีการจัดการ
การใช้งานอุปกรณ์จะประกาศ android.software.managed_users
ดังต่อไปนี้
- [C-1-1] ต้องให้สิทธิ์เข้าถึงแก่ผู้ใช้ในการออกจากระบบของผู้ใช้ปัจจุบัน และสลับกลับไปเป็นผู้ใช้หลักในเซสชันที่มีผู้ใช้หลายคนเมื่อ
isLogoutEnabled
แสดงผลtrue
ราคาของผู้ใช้ต้องเข้าถึงได้จากหน้าจอล็อกโดยไม่ต้องปลดล็อกอุปกรณ์
3.10 การช่วยเหลือพิเศษ
Android มีเลเยอร์การช่วยเหลือพิเศษที่ช่วยให้ผู้ใช้ที่มีความพิการสามารถไปยังส่วนต่างๆ ในอุปกรณ์ได้ง่ายขึ้น นอกจากนี้ Android ยังมี API ของแพลตฟอร์มที่ช่วยให้ติดตั้งใช้งานบริการการช่วยเหลือพิเศษเพื่อรับ Callback สำหรับเหตุการณ์ของผู้ใช้และระบบ และสร้างกลไกการแสดงความคิดเห็นแบบอื่น เช่น การอ่านออกเสียงข้อความ การตอบสนองแบบรู้สึกได้ และการนำทางแทร็กบอล/D-pad
หากการใช้งานอุปกรณ์รองรับบริการช่วยเหลือพิเศษของบุคคลที่สาม บริการเหล่านั้นจะมีลักษณะดังนี้
- [C-1-1] ต้องใช้งานเฟรมเวิร์กการช่วยเหลือพิเศษของ Android ตามที่อธิบายไว้ในเอกสารประกอบของ SDK เกี่ยวกับ API การช่วยเหลือพิเศษ
- [C-1-2] ต้องสร้างเหตุการณ์การช่วยเหลือพิเศษและส่ง
AccessibilityEvent
ที่เหมาะสมไปยังการใช้งานAccessibilityService
ที่ลงทะเบียนไว้ทั้งหมดตามที่ระบุไว้ใน SDK - [C-1-4] ต้องเพิ่มปุ่มในแถบนำทางของระบบเพื่อให้ผู้ใช้ควบคุมบริการการช่วยเหลือพิเศษได้เมื่อบริการการช่วยเหลือพิเศษที่เปิดใช้ประกาศปุ่ม
AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_BUTTON
โปรดทราบว่าสำหรับการใช้อุปกรณ์ที่ไม่มีแถบนำทางของระบบ ข้อกำหนดนี้จะไม่มีผล แต่การใช้งานอุปกรณ์ควรให้ผู้ใช้มีสิทธิ์ในการควบคุมบริการการช่วยเหลือพิเศษเหล่านี้
หากการใช้งานอุปกรณ์มีบริการการช่วยเหลือพิเศษที่ติดตั้งไว้ล่วงหน้า สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-2-1] ต้องใช้บริการการช่วยเหลือพิเศษที่ติดตั้งไว้ล่วงหน้าเหล่านี้เป็นแอป Direct Boot Aware เมื่อพื้นที่เก็บข้อมูลได้รับการเข้ารหัสด้วย Fileตาม Encryption (FBE)
- ควรมีกลไกในขั้นตอนการตั้งค่าที่พร้อมใช้งานทันทีเพื่อให้ผู้ใช้เปิดใช้บริการการช่วยเหลือพิเศษที่เกี่ยวข้อง รวมถึงตัวเลือกในการปรับขนาดแบบอักษร ขนาดการแสดงผล และท่าทางสัมผัสการขยาย
3.11 การอ่านออกเสียงข้อความ
Android มี API ที่อนุญาตให้แอปพลิเคชันใช้ประโยชน์จากบริการอ่านออกเสียงข้อความ (TTS) และช่วยให้ผู้ให้บริการติดตั้งใช้งานบริการ TTS ได้
หากอุปกรณ์รายงานฟีเจอร์ android.hardware.audio.output ระบบจะดำเนินการต่อไปนี้
- [C-1-1] ต้องรองรับ API ของ Android TTS Framework
หากการติดตั้งอุปกรณ์รองรับการติดตั้งเครื่องมือ TTS ของบุคคลที่สาม การติดตั้งจะดำเนินการดังนี้
- [C-2-1] ต้องให้เงินแก่ผู้ใช้เพื่อให้ผู้ใช้เลือกเครื่องมือ TTS สำหรับการใช้งานในระดับระบบ
3.12 เฟรมเวิร์กอินพุตทีวี
Android Television Input Framework (TIF) ทำให้การส่งเนื้อหาสดไปยังอุปกรณ์ Android TV ง่ายขึ้น 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] ต้องอนุญาตให้ผู้ใช้เพิ่มหรือนำไทล์ที่ให้บริการผ่าน
quicksettings
API ออกจากแอปของบุคคลที่สาม - [C-1-2] ต้องไม่เพิ่มการ์ดจากแอปของบุคคลที่สามลงในการตั้งค่าด่วนโดยตรง
- [C-1-3] ต้องแสดงการ์ดที่ผู้ใช้เพิ่มทั้งหมดจากแอปของบุคคลที่สามควบคู่ไปกับการ์ดการตั้งค่าด่วนที่ระบบมีให้
3.14 UI สื่อ
หากการใช้งานอุปกรณ์มีแอปพลิเคชันที่ไม่ได้เปิดใช้งานด้วยเสียง (แอป) ซึ่งโต้ตอบกับแอปพลิเคชันของบุคคลที่สามผ่าน MediaBrowser
หรือ MediaSession
แอปจะดำเนินการดังนี้
-
[C-1-2] ต้องแสดงไอคอนที่ได้รับจาก getIconBitmap() หรือ getIconUri() อย่างชัดเจน รวมถึงชื่อที่ได้รับผ่าน getTitle() ตามที่อธิบายไว้ใน
MediaDescription
อาจย่อชื่อเพื่อให้สอดคล้องกับกฎระเบียบด้านความปลอดภัย (เช่น สิ่งรบกวนผู้ขับขี่) -
[C-1-3] ต้องแสดงไอคอนแอปพลิเคชันของบุคคลที่สามทุกครั้งที่แสดงเนื้อหาที่มาจากแอปพลิเคชันของบุคคลที่สามนี้
-
[C-1-4] ต้องอนุญาตให้ผู้ใช้โต้ตอบกับ
MediaBrowser
ทั้งลำดับชั้น อาจจำกัดการเข้าถึงในบางลำดับชั้นเพื่อปฏิบัติตามกฎระเบียบด้านความปลอดภัย (เช่น การรบกวนผู้ขับขี่) แต่ต้องไม่ให้การดูแลเป็นพิเศษตามเนื้อหาหรือผู้ให้บริการเนื้อหา -
[C-1-5] ต้องแตะ
KEYCODE_HEADSETHOOK
สองครั้งหรือKEYCODE_MEDIA_PLAY_PAUSE
เป็นKEYCODE_MEDIA_NEXT
สำหรับMediaSession.Callback#onMediaButtonEvent
3.15 Instant Apps
การใช้งานอุปกรณ์ต้องเป็นไปตามข้อกำหนดต่อไปนี้
- [C-0-1] Instant Apps ต้องได้รับสิทธิ์ที่ตั้งค่า
android:protectionLevel
เป็น"instant"
เท่านั้น - [C-0-2] Instant Apps ต้องไม่โต้ตอบกับแอปที่ติดตั้งผ่าน implicit Intents เว้นแต่จะเป็นไปตามข้อใดข้อหนึ่งต่อไปนี้
- แสดงตัวกรองรูปแบบ 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 จะเชื่อมต่อกับแอปพลิเคชันที่ติดตั้งไว้อย่างชัดเจน
หากอุปกรณ์รองรับ Instant App ระบบจะดำเนินการต่อไปนี้
- [C-1-1] ต้องมีค่าใช้จ่ายสำหรับผู้ใช้ดังต่อไปนี้ในการโต้ตอบกับ Instant Apps AOSP ตรงตามข้อกำหนดของ UI, การตั้งค่า และ Launcher เริ่มต้นของระบบ
- [C-1-2] ต้องมีค่าใช้จ่ายให้กับผู้ใช้ในการดูและลบ Instant Apps ที่แคชไว้ในเครื่องสำหรับแพ็กเกจแอปแต่ละรายการ
- [C-1-3] ต้องระบุการแจ้งเตือนผู้ใช้ถาวรที่สามารถยุบได้ขณะที่ Instant App ทำงานอยู่ในเบื้องหน้า การแจ้งเตือนผู้ใช้นี้ต้องรวม Instant Apps โดยไม่ต้องติดตั้ง และมอบค่าตอบแทนที่จะนำผู้ใช้ไปยังหน้าจอข้อมูลแอปพลิเคชันในการตั้งค่า สำหรับ Instant App ที่เปิดใช้ผ่าน Intent ของเว็บ กำหนดโดยใช้ Intent ที่มีการตั้งค่าการดำเนินการเป็น Intent.ACTION_VIEW และด้วยรูปแบบ "http" หรือ "https" ผู้ใช้เพิ่มเติมควรอนุญาตให้ผู้ใช้เปิด Instant App และเปิดลิงก์ที่เชื่อมโยงกับเว็บเบราว์เซอร์ที่กำหนดค่าไว้ในอุปกรณ์ได้ หากมีเบราว์เซอร์
- [C-1-4] ต้องอนุญาตให้เรียกใช้ Instant Apps จากฟังก์ชัน "ล่าสุด" ได้ หากฟังก์ชัน "ล่าสุด" ใช้งานได้ในอุปกรณ์
- [C-1-5] ต้องโหลดแอปพลิเคชันหรือคอมโพเนนต์บริการอย่างน้อย 1 รายการล่วงหน้าด้วยเครื่องจัดการ Intent สำหรับ Intent ที่แสดงอยู่ใน SDK ที่นี่ และทำให้ Intent ปรากฏขึ้นสำหรับ Instant Apps
3.16 การจับคู่อุปกรณ์ที่ใช้ร่วมกัน
Android รองรับการจับคู่อุปกรณ์ที่ใช้ร่วมกันเพื่อให้จัดการการเชื่อมโยงกับอุปกรณ์ที่ใช้ร่วมกันได้อย่างมีประสิทธิภาพมากขึ้น รวมถึงมี CompanionDeviceManager
API เพื่อให้แอปเข้าถึงฟีเจอร์นี้ได้
หากการใช้งานอุปกรณ์รองรับฟีเจอร์การจับคู่อุปกรณ์ที่ใช้ร่วมกัน การใช้งานจะมีลักษณะดังนี้
- [C-1-1] ต้องประกาศแฟล็กฟีเจอร์
FEATURE_COMPANION_DEVICE_SETUP
- [C-1-2] ต้องตรวจสอบให้แน่ใจว่า API ในแพ็กเกจ
android.companion
ใช้งานได้โดยสมบูรณ์แล้ว - [C-1-3] ต้องให้ข้อมูลสำหรับผู้ใช้แก่ผู้ใช้ในการเลือก/ยืนยันว่ามีอุปกรณ์ที่ใช้ร่วมกันพร้อมใช้งานและทำงานได้
3.17. แอปขนาดใหญ่
หากการติดตั้งใช้งานอุปกรณ์ประกาศฟีเจอร์ FEATURE_CANT_SAVE_STATE
ระบบจะดำเนินการต่อไปนี้
- [C-1-1] ต้องมีแอปที่ติดตั้งไว้เพียงแอปเดียวที่ระบุว่า
cantSaveState
ทำงานอยู่ในระบบในแต่ละครั้ง หากผู้ใช้ออกจากแอปดังกล่าวโดยไม่ได้ออกจากแอปอย่างชัดเจน (เช่น กดปุ่มหน้าแรกขณะออกจากระบบซึ่งมีกิจกรรมที่ใช้งานอยู่ แทนที่จะกดกลับโดยไม่มีกิจกรรมที่ใช้งานอยู่เหลืออยู่ในระบบ) การใช้งานอุปกรณ์จะต้องให้ความสำคัญกับแอปนั้นใน RAM เช่นเดียวกับการดำเนินการอื่นๆ ที่คาดว่าจะยังคงทำงานอยู่ เช่น บริการที่ทำงานอยู่เบื้องหน้า ในขณะที่แอปเหล่านั้นทำงานอยู่เบื้องหลัง ระบบจะยังคงใช้ฟีเจอร์การจัดการพลังงานกับแอปได้ เช่น การจำกัดการเข้าถึง CPU และเครือข่าย - [C-1-2] ต้องระบุราคา UI เพื่อเลือกแอปที่จะไม่เข้าร่วมในกลไกการบันทึก/กู้คืนสถานะปกติเมื่อผู้ใช้เปิดแอปที่ 2 ที่ประกาศด้วยแอตทริบิวต์
cantSaveState
- [C-1-3] ต้องไม่ใช้การเปลี่ยนแปลงอื่นๆ ในนโยบายกับแอปที่ระบุ
cantSaveState
เช่น การเปลี่ยนประสิทธิภาพของ CPU หรือการเปลี่ยนลำดับความสำคัญของกำหนดการ
การติดตั้งใช้งานอุปกรณ์ไม่ได้ประกาศฟีเจอร์ FEATURE_CANT_SAVE_STATE
จะมีผลดังนี้
- [C-1-1] ต้องละเว้นแอตทริบิวต์
cantSaveState
ที่แอปกำหนด และต้องไม่เปลี่ยนลักษณะการทำงานของแอปตามแอตทริบิวต์นั้น
3.18 รายชื่อติดต่อ
Android มี Contacts Provider
API เพื่อช่วยให้แอปพลิเคชันจัดการข้อมูลติดต่อที่เก็บไว้ในอุปกรณ์ได้ โดยทั่วไปแล้ว ข้อมูลรายชื่อติดต่อที่ป้อนในอุปกรณ์โดยตรงจะซิงค์กับบริการบนเว็บ แต่ข้อมูลดังกล่าวอาจอยู่ในตัวอุปกรณ์เท่านั้น รายชื่อติดต่อที่จัดเก็บไว้ในอุปกรณ์เท่านั้นจะเรียกว่ารายชื่อติดต่อในเครื่อง
RawContacts นั้น "เชื่อมโยงกับ" หรือ "จัดเก็บไว้ใน" บัญชี เมื่อคอลัมน์ ACCOUNT_NAME
และ ACCOUNT_TYPE
ของรายชื่อติดต่อดิบตรงกับช่อง Account.name และ Account.type ที่เกี่ยวข้องของบัญชี
บัญชีเริ่มต้นในเครื่อง: บัญชีสำหรับรายชื่อติดต่อดิบที่จัดเก็บไว้ในอุปกรณ์เท่านั้นและไม่ได้เชื่อมโยงกับบัญชีใน Account Manager ซึ่งสร้างขึ้นด้วยค่า null สำหรับคอลัมน์ ACCOUNT_NAME
และ ACCOUNT_TYPE
บัญชีในเครื่องที่กำหนดเอง: บัญชีสำหรับรายชื่อติดต่อดิบที่จัดเก็บไว้ในอุปกรณ์เท่านั้นและไม่ได้เชื่อมโยงกับบัญชีใน Account Manager ซึ่งสร้างขึ้นด้วยค่าที่ไม่ใช่ค่า Null อย่างน้อย 1 ค่าสำหรับคอลัมน์ ACCOUNT_NAME
และ ACCOUNT_TYPE
การติดตั้งใช้งานอุปกรณ์
- [C-SR] ขอแนะนำเป็นอย่างยิ่งว่าอย่าสร้างบัญชีในพื้นที่ที่กำหนดเอง
หากการใช้อุปกรณ์ใช้บัญชีในเครื่องที่กำหนดเอง ให้ทำดังนี้
- [C-1-1]
ContactsContract.RawContacts.getLocalAccountName
ต้องส่งคืนACCOUNT_NAME
ของบัญชีในเครื่องที่กำหนดเอง - [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] ต้องติดตั้งและเรียกใช้ไฟล์ Android “.apk” ได้ ซึ่งสร้างโดยเครื่องมือ “aapt” ที่รวมอยู่ใน Android SDK อย่างเป็นทางการ
- เนื่องจากข้อกำหนดข้างต้นอาจเป็นเรื่องท้าทาย จึงขอแนะนำให้ติดตั้งใช้งานอุปกรณ์เพื่อใช้ระบบการจัดการแพ็กเกจของการใช้งานข้อมูลอ้างอิง AOSP
การติดตั้งใช้งานอุปกรณ์
- [C-0-2] ต้องรองรับการยืนยันไฟล์ “.apk” โดยใช้ APK Signature Scheme v3 , APK Signature Scheme v2 และการลงนาม JAR
- [C-0-3] ต้องไม่ขยายรูปแบบ .apk, Android Manifest, Dalvik bytescode หรือ RenderScript Bycode ในลักษณะที่จะป้องกันไม่ให้ไฟล์เหล่านั้นติดตั้งและทำงานได้อย่างถูกต้องในอุปกรณ์อื่นๆ ที่เข้ากันได้
-
[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] ต้องแสดงกล่องโต้ตอบคำเตือนพร้อมสตริงคำเตือนที่ได้รับจาก API ของระบบ
PackageManager.setHarmfulAppWarning
ต่อผู้ใช้ก่อนเปิดตัวกิจกรรมในแอปพลิเคชันที่มีการทำเครื่องหมายโดย API ระบบเดียวกันว่าPackageManager.setHarmfulAppWarning
ว่าอาจเป็นอันตราย -
ควรเสนอทางเลือกแก่ผู้ใช้ในการเลือกที่จะถอนการติดตั้งหรือเปิดแอปพลิเคชันในหน้าคำเตือน
-
[C-0-8] ต้องใช้การรองรับระบบไฟล์ส่วนเพิ่มตามเอกสารประกอบที่นี่
-
[C-0-9] ต้องรองรับการยืนยันไฟล์ .apk โดยใช้ APK Signature Scheme v4
-
หากมีการเปิดตัวอุปกรณ์ใน Android เวอร์ชันก่อนหน้าแล้ว และไม่เป็นไปตามข้อกำหนด [C-0-8] และ [C-0-9] ผ่านการอัปเดตซอฟต์แวร์ระบบ อุปกรณ์เหล่านี้อาจได้รับการยกเว้นจากข้อกำหนดเหล่านี้
5. ความเข้ากันได้กับมัลติมีเดีย
การติดตั้งใช้งานอุปกรณ์
- [C-0-1] ต้องรองรับรูปแบบสื่อ โปรแกรมเปลี่ยนไฟล์ โปรแกรมถอดรหัส ประเภทไฟล์ และรูปแบบคอนเทนเนอร์ที่กำหนดไว้ในส่วนที่ 5.1 สำหรับตัวแปลงรหัสทุกตัวที่ประกาศโดย
MediaCodecList
- [C-0-2] ต้องประกาศและรายงานการรองรับโปรแกรมเปลี่ยนไฟล์และตัวถอดรหัสที่มีให้กับแอปพลิเคชันของบุคคลที่สามผ่าน
MediaCodecList
- [C-0-3] ต้องถอดรหัสและเปิดให้แอปของบุคคลที่สามใช้งานได้ทุกรูปแบบที่สามารถเข้ารหัสได้อย่างถูกต้อง ซึ่งรวมถึงบิตสตรีมทั้งหมดที่โปรแกรมเปลี่ยนไฟล์สร้างขึ้นและโปรไฟล์ที่รายงานใน
CamcorderProfile
การติดตั้งใช้งานอุปกรณ์
- ควรใช้เวลาในการตอบสนองของตัวแปลงรหัสขั้นต่ำ หรือพูดอีกอย่างก็คือ
- ไม่ควรใช้และจัดเก็บบัฟเฟอร์อินพุต รวมถึงแสดงผลบัฟเฟอร์อินพุตเมื่อประมวลผลแล้วเท่านั้น
- ไม่ควรเก็บบัฟเฟอร์ที่ถอดรหัสแล้วไว้นานกว่าที่มาตรฐานระบุไว้ (เช่น SPS)
- ไม่ควรเก็บบัฟเฟอร์ที่เข้ารหัสไว้นานกว่าที่โครงสร้าง GOP กำหนด
ตัวแปลงรหัสทั้งหมดที่ระบุไว้ในส่วนด้านล่างมีไว้เพื่อเป็นการติดตั้งซอฟต์แวร์ในการใช้งาน Android ที่ต้องการจากโครงการโอเพนซอร์ส Android
โปรดทราบว่าทั้ง Google และ Open Handset Alliance ไม่รับรองว่าตัวแปลงรหัสเหล่านี้ปราศจากสิทธิบัตรของบุคคลที่สาม ผู้ที่ตั้งใจจะใช้ซอร์สโค้ดนี้ในผลิตภัณฑ์ฮาร์ดแวร์หรือซอฟต์แวร์ได้รับคำแนะนำว่า การใช้โค้ดนี้ รวมทั้งในซอฟต์แวร์โอเพนซอร์สหรือ Shareware อาจต้องมีใบอนุญาตสิทธิบัตรจากผู้ถือครองสิทธิบัตรที่เกี่ยวข้อง
5.1 ตัวแปลงสัญญาณสื่อ
5.1.1 การเข้ารหัสเสียง
ดูรายละเอียดเพิ่มเติมใน 5.1.3 รายละเอียดตัวแปลงสัญญาณเสียง
หากการใช้งานอุปกรณ์ประกาศ android.hardware.microphone
อุปกรณ์ต้องรองรับการเข้ารหัสรูปแบบเสียงต่อไปนี้และทำให้ใช้งานกับแอปของบุคคลที่สามได้
- [C-1-1] PCM/WAVE
- [C-1-2] FLAC
- [C-1-3] โอปัส
โปรแกรมเปลี่ยนไฟล์เสียงทั้งหมดต้องสนับสนุนรายการต่อไปนี้
- [C-3-1] เฟรมเสียงสำหรับสั่งซื้อไบต์ดั้งเดิมของ PCM 16 บิตผ่าน
android.media.MediaCodec
API
5.1.2 การถอดรหัสเสียง
ดูรายละเอียดเพิ่มเติมใน 5.1.3 รายละเอียดตัวแปลงสัญญาณเสียง
หากการใช้งานอุปกรณ์ประกาศการรองรับฟีเจอร์ android.hardware.audio.output
การใช้งานอุปกรณ์จะต้องรองรับการถอดรหัสรูปแบบเสียงต่อไปนี้
- [C-1-1] โปรไฟล์ MPEG-4 AAC (AAC LC)
- [C-1-2] โปรไฟล์ MPEG-4 HE AAC (AAC+)
- [C-1-3] โปรไฟล์ MPEG-4 HE AACv2 (AAC+ ที่ปรับปรุงใหม่)
- [C-1-4] AAC ELD (ปรับปรุงความหน่วงต่ำ AAC)
- [C-1-11] xHE-AAC (ISO/IEC 23003-3 Extended HE AAC Profile ซึ่งรวมถึงโปรไฟล์ฐานของ USAC และโปรไฟล์ควบคุมช่วงไดนามิก ISO/IEC 23003-4)
- [C-1-5] FLAC
- MP3 [C-1-6]
- [C-1-7] MIDI
- [C-1-8] เวอร์บี
- [C-1-9] PCM/WAVE ประกอบด้วยรูปแบบเสียงความละเอียดสูงสูงสุด 24 บิต อัตราการสุ่มตัวอย่าง 192 kHz และช่อง 8 ช่อง โปรดทราบว่าข้อกำหนดนี้มีไว้สำหรับการถอดรหัสเท่านั้น และอนุญาตให้อุปกรณ์ลดตัวอย่างและดาวน์มิกซ์ได้ในระยะการเล่น
- [C-1-10] โอปัส
หากการใช้งานอุปกรณ์รองรับการถอดรหัสบัฟเฟอร์อินพุต AAC ของสตรีมแบบหลายช่อง (เช่น มากกว่า 2 ช่อง) ไปยัง PCM ผ่านตัวถอดรหัสเสียง AAC เริ่มต้นใน android.media.MediaCodec
API ต้องมีการรองรับดังต่อไปนี้
- [C-2-1] การถอดรหัสต้องดำเนินการโดยไม่ดาวน์มิกซ์ (เช่น ต้องถอดรหัสสตรีม 5.0 AAC เป็น PCM 5 ช่อง ต้องถอดรหัสสตรีม 5.1 AAC เป็น PCM 6 ช่อง)
- [C-2-2] ข้อมูลเมตาของช่วงไดนามิกต้องระบุไว้ใน "การควบคุมช่วงไดนามิก (DRC)" ใน ISO/IEC 14496-3 และคีย์ DRC
android.media.MediaFormat
เพื่อกำหนดค่าพฤติกรรมที่เกี่ยวข้องกับช่วงไดนามิกของเครื่องถอดรหัสเสียง คีย์ AAC DRC เปิดตัวใน API 21 ซึ่งได้แก่KEY_AAC_DRC_ATTENUATION_FACTOR
,KEY_AAC_DRC_BOOST_FACTOR
,KEY_AAC_DRC_HEAVY_COMPRESSION
,KEY_AAC_DRC_TARGET_REFERENCE_LEVEL
และKEY_AAC_ENCODED_TARGET_LEVEL
- [SR] เราขอแนะนำเป็นอย่างยิ่งว่าตัวถอดรหัสเสียง AAC ทั้งหมดเป็นไปตามข้อกำหนด C-2-1 และ C-2-2 ข้างต้น
เมื่อถอดรหัสเสียง USAC, MPEG-D (ISO/IEC 23003-4)
- [C-3-1] ความดังและข้อมูลเมตา DRC ต้องตีความและนำไปใช้ตาม MPEG-D DRC Dynamic Range Control Profile Level 1
- [C-3-2] ตัวถอดรหัสต้องทำงานตามการกำหนดค่าที่ตั้งไว้ด้วยคีย์
android.media.MediaFormat
ต่อไปนี้KEY_AAC_DRC_TARGET_REFERENCE_LEVEL
และKEY_AAC_DRC_EFFECT_TYPE
ตัวถอดรหัสโปรไฟล์ MPEG-4 AAC, HE AAC และ HE AACv2:
- อาจรองรับความดังและการควบคุมช่วงไดนามิกโดยใช้โปรไฟล์การควบคุมช่วงไดนามิกแบบ ISO/IEC 23003-4
หากระบบรองรับ ISO/IEC 23003-4 และหากมีทั้งข้อมูลเมตา ISO/IEC 23003-4 และข้อมูลเมตา ISO/IEC 14496-3 ในบิตสตรีมที่ถอดรหัสแล้ว ให้ทำดังนี้
- ข้อมูลเมตา ISO/IEC 23003-4 จะมีความสำคัญเหนือกว่า
ตัวถอดรหัสเสียงทั้งหมดต้องรองรับเอาต์พุต:
- [C-6-1] เฟรมเสียงสำหรับสั่งซื้อไบต์ดั้งเดิมของ PCM 16 บิตผ่าน
android.media.MediaCodec
API
5.1.3 รายละเอียดตัวแปลงสัญญาณเสียง
รูปแบบ/ตัวแปลงรหัส | รายละเอียด | ประเภทไฟล์/รูปแบบคอนเทนเนอร์ที่จะรองรับ |
---|---|---|
โปรไฟล์ MPEG-4 AAC (AAC LC) |
รองรับเนื้อหาโมโน/สเตอริโอ/5.0/5.1 ที่มีอัตราการสุ่มตัวอย่างมาตรฐานตั้งแต่ 8 ถึง 48 kHz |
|
โปรไฟล์ MPEG-4 HE AAC (AAC+) | รองรับเนื้อหาโมโน/สเตอริโอ/5.0/5.1 ที่มีอัตราการสุ่มตัวอย่างมาตรฐานตั้งแต่ 16 ถึง 48 kHz |
|
MPEG-4 HE AACv2 โปรไฟล์ (AAC+ ที่ปรับปรุงแล้ว) |
รองรับเนื้อหาโมโน/สเตอริโอ/5.0/5.1 ที่มีอัตราการสุ่มตัวอย่างมาตรฐานตั้งแต่ 16 ถึง 48 kHz |
|
AAC ELD (ปรับปรุงความหน่วงต่ำของ AAC) | รองรับเนื้อหาโมโน/สเตอริโอที่มีอัตราการสุ่มตัวอย่างมาตรฐานตั้งแต่ 16 ถึง 48 kHz |
|
ฐานความรู้ด้านสิ่งแวดล้อม (USAC) | รองรับเนื้อหาโมโน/สเตอริโอที่มีอัตราการสุ่มตัวอย่างมาตรฐานตั้งแต่ 7.35 ถึง 48 kHz | MPEG-4 (.mp4, .m4a) |
AMR-NB | สุ่มตัวอย่าง 4.75 ถึง 12.2 kbps @ 8 kHz | 3GPP (.3gp) |
AMR-WB | 9 อัตราจาก 6.60 kbit/s ถึง 23.85 kbit/s ได้รับการสุ่มตัวอย่างที่ 16 kHz ตามที่กําหนดไว้ที่ AMR-WB, Adaptive Multi-Rate - Wide Band Speech Codec | 3GPP (.3gp) |
FLAC | สำหรับทั้งโปรแกรมเปลี่ยนไฟล์และโปรแกรมถอดรหัส: ต้องมีการรองรับโหมดโมโนและสเตอริโอเป็นอย่างน้อย รองรับอัตราการสุ่มตัวอย่างสูงสุด 192 kHz ต้องรองรับความละเอียด 16 บิตและ 24 บิต การจัดการข้อมูลเสียง 24 บิตของ FLAC ต้องใช้งานได้กับการกำหนดค่าเสียงแบบลอย |
|
MP3 | ค่าคงที่แบบโมโน/สเตอริโอ 8-320 Kbps (CBR) หรืออัตราบิตแปรผัน (VBR) |
|
MIDI | MIDI ประเภท 0 และ 1 DLS เวอร์ชัน 1 และ 2 XMF และ XMF สำหรับอุปกรณ์เคลื่อนที่ รองรับรูปแบบเสียงเรียกเข้า RTTTL/RTX, OTA และ iMelody |
|
Vorbis |
|
|
PCM/WAVE | ตัวแปลงรหัส PCM ต้องรองรับ PCM เชิงเส้น 16 บิตและแบบลอย 16 บิต เครื่องมือแยก WAVE ต้องรองรับ PCM เชิงเส้น 16 บิต, 24 บิต, 32 บิต และลอยตัว 32 บิต (อัตราสูงสุดถึงขีดจำกัดของฮาร์ดแวร์) อัตราการสุ่มตัวอย่างต้องรองรับตั้งแต่ 8 kHz ถึง 192 kHz | WAVE (.wav) |
Opus |
การถอดรหัส: รองรับเนื้อหาแบบโมโน, สเตอริโอ, 5.0 และ 5.1 ที่มีอัตราการสุ่มตัวอย่างที่ 8000, 12000, 16000, 24000 และ 48000 Hz การเข้ารหัส: สนับสนุนเนื้อหาโมโนและสเตอริโอที่มีอัตราการสุ่มตัวอย่าง 8000, 12000, 16000, 24000 และ 48000 Hz |
|
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
- GIF [C-0-2]
- [C-0-3] PNG
- [C-0-4] BMP
- [C-0-5] WebP
- [C-0-6] ดิบ
หากอุปกรณ์รองรับการถอดรหัสวิดีโอ HEVC อุปกรณ์เหล่านั้น * [C-1-1] ต้องรองรับการถอดรหัสรูปภาพ HEIF (HEIC)
ตัวถอดรหัสรูปภาพที่รองรับรูปแบบที่มีความลึกของบิตสูง (9 บิตขึ้นไปต่อช่อง):
- [C-2-1] ต้องรองรับเอาต์พุตรูปแบบเทียบเท่า 8 บิตหากแอปพลิเคชันขอ เช่น ผ่านการกำหนดค่า
ARGB_8888
ของandroid.graphics.Bitmap
5.1.6 รายละเอียดตัวแปลงรหัสภาพ
รูปแบบ/ตัวแปลงรหัส | รายละเอียด | รูปแบบไฟล์/รูปแบบคอนเทนเนอร์ที่รองรับ |
---|---|---|
JPEG | ฐาน +โพรเกรสซีฟ | JPEG (.jpg) |
GIF | GIF (.gif) | |
PNG | PNG (.png) | |
BMP | BMP (.bmp) | |
WebP | WebP (.webp) | |
แบบข้อมูลดิบ | ARW (.arw), CR2 (.cr2), DNG (.dng), NEF (.nef), NRW (.nrw), ORF (.orf), PEF (.pef), RAF (.raf), RW2 (.rw2), SRW (.srw) | |
HEIF | รูปภาพ คอลเล็กชันรูปภาพ ลำดับรูปภาพ | HEIF (.heif), HEIC (.heic) |
โปรแกรมเปลี่ยนไฟล์และตัวถอดรหัสรูปภาพที่แสดงผ่าน MediaCodec API
-
[C-1-1] ต้องรองรับรูปแบบสีที่ปรับเปลี่ยนได้ YUV420 8:8:8 (
COLOR_FormatYUV420Flexible
) ถึงCodecCapabilities
-
[SR] แนะนำอย่างยิ่งให้รองรับรูปแบบสี RGB888 สำหรับโหมดพื้นผิวของอินพุต
-
[C-1-3] ต้องรองรับรูปแบบสี YUV420 8:8:8 แบบระนาบหรือแบบกึ่งระนาบอย่างน้อย 1 รูปแบบ:
COLOR_FormatYUV420PackedPlanar
(เทียบเท่ากับCOLOR_FormatYUV420Planar
) หรือCOLOR_FormatYUV420PackedSemiPlanar
(เทียบเท่ากับCOLOR_FormatYUV420SemiPlanar
) เราขอแนะนำเป็นอย่างยิ่งให้สนับสนุนทั้ง 2 อย่างนี้
5.1.7 ตัวแปลงรหัสวิดีโอ
- เพื่อคุณภาพที่ยอมรับได้ของบริการสตรีมวิดีโอบนเว็บและบริการประชุมทางวิดีโอ การใช้งานอุปกรณ์ควรใช้ตัวแปลงรหัส VP8 สำหรับฮาร์ดแวร์ที่เป็นไปตามข้อกำหนด
หากการใช้งานอุปกรณ์มีตัวถอดรหัสวิดีโอหรือโปรแกรมเปลี่ยนไฟล์
-
[C-1-1] ตัวแปลงรหัสวิดีโอต้องรองรับขนาดเอาต์พุตและไบต์บัฟเฟอร์อินพุตที่รองรับเฟรมที่บีบอัดและไม่บีบอัดขนาดใหญ่ที่สุดตามที่มาตรฐานและการกำหนดค่ากำหนดไว้ แต่ต้องไม่ครอบคลุมโดยรวม
-
[C-1-2] โปรแกรมเปลี่ยนไฟล์และตัวถอดรหัสวิดีโอต้องรองรับรูปแบบสีที่ยืดหยุ่น YUV420 8:8:8 (
COLOR_FormatYUV420Flexible
) ถึงCodecCapabilities
-
[C-1-3] โปรแกรมเปลี่ยนไฟล์และตัวถอดรหัสวิดีโอต้องรองรับรูปแบบสี YUV420 8:8:8 แบบระนาบหรือกึ่งระนาบอย่างน้อย 1 รูปแบบ:
COLOR_FormatYUV420PackedPlanar
(เทียบเท่ากับCOLOR_FormatYUV420Planar
) หรือCOLOR_FormatYUV420PackedSemiPlanar
(เทียบเท่ากับCOLOR_FormatYUV420SemiPlanar
) เราขอแนะนำเป็นอย่างยิ่งให้สนับสนุนทั้ง 2 อย่างนี้ -
[SR] เราแนะนําอย่างยิ่งให้ใช้โปรแกรมเปลี่ยนไฟล์และตัวถอดรหัสวิดีโอเพื่อรองรับรูปแบบสี YUV420 8:8:8 แบบ YUV420 8:8:8 ที่มีการเพิ่มประสิทธิภาพฮาร์ดแวร์อย่างน้อย 1 รายการ (รูปแบบสี YV12, NV12, NV21 หรือรูปแบบที่เพิ่มประสิทธิภาพสำหรับผู้ให้บริการที่เทียบเท่า)
-
[C-1-5] ตัวถอดรหัสวิดีโอที่รองรับรูปแบบความลึกบิตสูง (9 บิตขึ้นไปต่อช่อง) ต้องรองรับเอาต์พุตรูปแบบ 8 บิตที่เทียบเท่ากันหากแอปพลิเคชันร้องขอ ค่านี้ต้องแสดงโดยการรองรับรูปแบบสี YUV420 8:8:8 ผ่าน
android.media.MediaCodecInfo
การติดตั้งใช้งานอุปกรณ์ที่โฆษณาการรองรับโปรไฟล์ HDR ผ่าน Display.HdrCapabilities
จะมีผลดังนี้
- [C-2-1] ต้องรองรับการแยกวิเคราะห์และการจัดการข้อมูลเมตาแบบคงที่ HDR
หากการติดตั้งใช้งานอุปกรณ์โฆษณาการรองรับการรีเฟรชภายในผ่าน FEATURE_IntraRefresh
ในชั้นเรียน MediaCodecInfo.CodecCapabilities
การดำเนินการต่อไปนี้จะเกิดขึ้น
- [C-3-1] ต้องรองรับระยะเวลารีเฟรชในช่วง 10 - 60 เฟรมและทำงานอย่างถูกต้องภายใน 20% ของระยะเวลารีเฟรชที่กำหนดค่าไว้
การติดตั้งใช้งานตัวถอดรหัสวิดีโอ เว้นแต่แอปพลิเคชันจะระบุไว้เป็นอย่างอื่นโดยใช้คีย์รูปแบบ KEY_COLOR_FORMAT
- [C-4-1] ต้องใช้ค่าเริ่มต้นเป็นรูปแบบสีที่ปรับให้เหมาะสำหรับแสดงผลของฮาร์ดแวร์หากกำหนดค่าโดยใช้เอาต์พุต Surface
- [C-4-2] ต้องกำหนดค่าเริ่มต้นเป็นรูปแบบสี YUV420 8:8:8 ที่เหมาะสำหรับการอ่านของ CPU หากกำหนดค่าไม่ให้ใช้เอาต์พุต Surface
5.1.8 รายการตัวแปลงรหัสวิดีโอ
รูปแบบ/ตัวแปลงรหัส | รายละเอียด | ประเภทไฟล์/รูปแบบคอนเทนเนอร์ที่จะรองรับ |
---|---|---|
H.263 |
|
|
H.264 AVC | ดูรายละเอียดได้ในส่วนที่ 5.2 และ 5.3 |
|
HEVC ของ H.265 | ดูรายละเอียดในส่วนที่ 5.3 |
|
MPEG-2 | โปรไฟล์หลัก |
|
MPEG-4 SP |
|
|
VP8 | ดูรายละเอียดได้ในส่วนที่ 5.2 และ 5.3 |
|
VP9 | ดูรายละเอียดในส่วนที่ 5.3 |
|
5.1.9 ความปลอดภัยของตัวแปลงรหัสสื่อ
การใช้งานอุปกรณ์ต้องตรวจสอบการปฏิบัติตามข้อกำหนดของฟีเจอร์ความปลอดภัยของตัวแปลงรหัสสื่อดังที่อธิบายไว้ด้านล่าง
Android รองรับ OMX, API การเร่งมัลติมีเดียข้ามแพลตฟอร์ม และตัวแปลงรหัส 2.0 ซึ่งเป็น API การเร่งมัลติมีเดียต่ำแบบโอเวอร์เฮด
หากการใช้งานอุปกรณ์รองรับมัลติมีเดีย จะมีผลดังนี้
- [C-1-1] ต้องให้การสนับสนุนตัวแปลงรหัสสื่อผ่าน API ของ OMX หรือตัวแปลงรหัส 2.0 (หรือทั้งคู่) เช่นเดียวกับในโปรเจ็กต์โอเพนซอร์สของ Android และต้องไม่ปิดใช้หรือหลบเลี่ยงการรักษาความปลอดภัย ซึ่งไม่ได้หมายความว่าตัวแปลงรหัสทุกตัวต้องใช้ OMX หรือ Codec 2.0 API ต้องรองรับ API เหล่านี้อย่างน้อย 1 ตัวเท่านั้น และการรองรับ API ที่ใช้ได้ต้องมีการป้องกันความปลอดภัยด้วย
- [C-SR] แนะนำอย่างยิ่งให้รวมการสนับสนุนสำหรับ Codec 2.0 API
หากการใช้งานอุปกรณ์ไม่รองรับตัวแปลงรหัส 2.0 API อุปกรณ์จะทำงานดังนี้
- [C-2-1] ต้องรวมตัวแปลงรหัสซอฟต์แวร์ OMX ที่เกี่ยวข้องจากโครงการโอเพนซอร์ส Android (หากมี) สำหรับรูปแบบและสื่อแต่ละประเภท (โปรแกรมเปลี่ยนไฟล์หรือตัวถอดรหัส) ที่อุปกรณ์รองรับ
- [C-2-2] ตัวแปลงรหัสที่มีชื่อขึ้นต้นด้วย "OMX.google" ต้องใช้ซอร์สโค้ดของโครงการโอเพนซอร์ส Android
- [C-SR] ขอแนะนำเป็นอย่างยิ่งว่าตัวแปลงรหัสซอฟต์แวร์ OMX จะทำงานในกระบวนการของตัวแปลงรหัสที่ไม่มีสิทธิ์เข้าถึงไดรเวอร์ฮาร์ดแวร์นอกเหนือจากโปรแกรมแมปหน่วยความจำ
หากอุปกรณ์รองรับตัวแปลงรหัสตัวแปลงรหัส 2.0 API อุปกรณ์จะทำงานดังนี้
- [C-3-1] ต้องรวมตัวแปลงรหัสของซอฟต์แวร์ Codec 2.0 ที่เกี่ยวข้องจากโครงการโอเพนซอร์ส Android (หากมี) สำหรับรูปแบบและสื่อแต่ละประเภท (โปรแกรมเปลี่ยนไฟล์หรือตัวถอดรหัส) ที่อุปกรณ์รองรับ
- [C-3-2] ต้องจัดเก็บตัวแปลงรหัสซอฟต์แวร์ Codec 2.0 ในกระบวนการของตัวแปลงสัญญาณซอฟต์แวร์ตามที่ระบุไว้ในโครงการโอเพนซอร์ส Android เพื่อให้สามารถให้สิทธิ์เข้าถึงตัวแปลงรหัสซอฟต์แวร์ได้อย่างแคบลง
- [C-3-3] ตัวแปลงรหัสที่มีชื่อขึ้นต้นด้วย "c2.android" ต้องใช้ซอร์สโค้ดของโครงการโอเพนซอร์ส Android
5.1.10 การจำแนกลักษณะของตัวแปลงรหัสสื่อ
หากการติดตั้งใช้งานอุปกรณ์รองรับตัวแปลงรหัสสื่อ ตัวแปลงสัญญาณต่อไปนี้
- [C-1-1] ต้องแสดงผลค่าที่ถูกต้องของการกำหนดลักษณะของตัวแปลงรหัสสื่อผ่าน
MediaCodecInfo
API
โดยเฉพาะอย่างยิ่ง:
- [C-1-2] ตัวแปลงรหัสที่มีชื่อขึ้นต้นด้วย "OMX" ต้องใช้ OMX API และมีชื่อที่สอดคล้องกับหลักเกณฑ์การตั้งชื่อ OMX IL
- [C-1-3] ตัวแปลงรหัสที่มีชื่อขึ้นต้นด้วย "c2" ต้องใช้ API ของตัวแปลงรหัส 2.0 และมีชื่อที่สอดคล้องกับหลักเกณฑ์การตั้งชื่อของตัวแปลงรหัส 2.0 สำหรับ Android
- [C-1-4] ตัวแปลงรหัสที่มีชื่อขึ้นต้นด้วย "OMX.google" หรือ "c2.android" ต้องไม่มีลักษณะเป็นผู้ให้บริการหรือเป็นการเร่งฮาร์ดแวร์
- [C-1-5] ตัวแปลงรหัสที่ทำงานในกระบวนการของตัวแปลงรหัส (ผู้ให้บริการหรือระบบ) ที่สามารถเข้าถึงไดรเวอร์ฮาร์ดแวร์นอกเหนือจากผู้จัดสรรหน่วยความจำและผู้ทำแผนที่ จะต้องไม่มีลักษณะเป็นซอฟต์แวร์เท่านั้น
- [C-1-6] ตัวแปลงรหัสที่ไม่มีอยู่ในโครงการโอเพนซอร์สของ Android หรือไม่ได้อิงตามซอร์สโค้ดในโปรเจ็กต์นั้นจะต้องมีลักษณะเป็นผู้ให้บริการ
- [C-1-7] ตัวแปลงรหัสที่ใช้การเร่งฮาร์ดแวร์จะต้องมีลักษณะเป็นการเร่งฮาร์ดแวร์
- [C-1-8] ชื่อตัวแปลงรหัสต้องไม่ทำให้เข้าใจผิด เช่น ตัวแปลงรหัสที่ชื่อ "ตัวถอดรหัส" ต้องรองรับการถอดรหัส และโปรแกรมที่ชื่อ "โปรแกรมเปลี่ยนไฟล์" ต้องรองรับการเข้ารหัส ตัวแปลงรหัสที่มีชื่อที่มีรูปแบบสื่อต้องรองรับรูปแบบดังกล่าว
หากการติดตั้งใช้งานอุปกรณ์รองรับตัวแปลงรหัสวิดีโอ ให้ทำดังนี้
- [C-2-1] ตัวแปลงรหัสวิดีโอทั้งหมดต้องเผยแพร่ข้อมูลอัตราเฟรมที่ทำได้สำหรับขนาดต่อไปนี้ หากตัวแปลงรหัสรองรับ
SD (คุณภาพต่ำ) | SD (คุณภาพสูง) | HD 720p | HD 1080p | UHD | |
---|---|---|---|---|---|
ความละเอียดของวิดีโอ |
|
|
|
1920 x 1080 พิกเซล (นอกเหนือจาก MPEG4) | 3840 x 2160 พิกเซล (HEVC, VP9) |
- [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 (แบบยืดหยุ่น Macroblock Ordering) และ RS (Slice ที่ซ้ำซ้อน) จะไม่บังคับ นอกจากนี้ เราขอแนะนำให้โปรแกรมเปลี่ยนไฟล์ไม่ใช้ ASO, FMO และ RS กับโปรไฟล์พื้นฐานเพื่อรักษาความเข้ากันได้กับอุปกรณ์ Android อื่นๆ
- [C-1-2] ต้องรองรับโปรไฟล์การเข้ารหัสวิดีโอ SD (ความละเอียดมาตรฐาน) ในตารางต่อไปนี้
- ควรรองรับโปรไฟล์หลักระดับ 4
- ควรสนับสนุนโปรไฟล์การเข้ารหัสวิดีโอ HD (ความละเอียดสูง) ตามที่ระบุไว้ในตารางต่อไปนี้
หากการใช้งานอุปกรณ์รายงานการรองรับการเข้ารหัส H.264 สำหรับวิดีโอความละเอียด 720p หรือ 1080p ผ่าน API ของสื่อ การดำเนินการต่อไปนี้
- [C-2-1] ต้องรองรับโปรไฟล์การเข้ารหัสในตารางต่อไปนี้
SD (คุณภาพต่ำ) | SD (คุณภาพสูง) | HD 720p | HD 1080p | |
---|---|---|---|---|
ความละเอียดของวิดีโอ | 320 x 240 พิกเซล | 720 x 480 พิกเซล | 1280 x 720 พิกเซล | 1920 x 1080 พิกเซล |
อัตราเฟรมของวิดีโอ | 20 FPS | 30 fps | 30 fps | 30 fps |
อัตราบิตของวิดีโอ | 384 Kbps | 2 Mbps | 4 Mbps | 10 Mbps |
5.2.3 VP8
หากอุปกรณ์รองรับตัวแปลงรหัส VP8 อุปกรณ์ดังกล่าวจะมีลักษณะดังนี้
- [C-1-1] ต้องรองรับโปรไฟล์การเข้ารหัสวิดีโอ SD
- ควรสนับสนุนโปรไฟล์การเข้ารหัสวิดีโอความละเอียดสูง (ความละเอียดสูง) ต่อไปนี้
- [C-1-2] ต้องรองรับการเขียนไฟล์ Matroska WebM
- ควรมีตัวแปลงรหัส VP8 สำหรับฮาร์ดแวร์ที่เป็นไปตามข้อกำหนดในการเขียนโค้ดฮาร์ดแวร์ RTC ของโปรเจ็กต์ WebM เพื่อให้บริการสตรีมมิงวิดีโอบนเว็บและบริการประชุมทางวิดีโอที่มีคุณภาพที่ยอมรับได้
หากการใช้งานอุปกรณ์รายงานการรองรับการเข้ารหัส VP8 สำหรับวิดีโอความละเอียด 720p หรือ 1080p ผ่าน API ของสื่อ การดำเนินการต่อไปนี้จะเกิดขึ้น
- [C-2-1] ต้องรองรับโปรไฟล์การเข้ารหัสในตารางต่อไปนี้
SD (คุณภาพต่ำ) | SD (คุณภาพสูง) | HD 720p | HD 1080p | |
---|---|---|---|---|
ความละเอียดของวิดีโอ | 320 x 180 พิกเซล | 640 x 360 พิกเซล | 1280 x 720 พิกเซล | 1920 x 1080 พิกเซล |
อัตราเฟรมของวิดีโอ | 30 fps | 30 fps | 30 fps | 30 fps |
อัตราบิตของวิดีโอ | 800 Kbps | 2 Mbps | 4 Mbps | 10 Mbps |
5.2.4 VP9
หากอุปกรณ์รองรับตัวแปลงรหัส VP9 อุปกรณ์จะทำงานดังนี้
- [C-1-2] ต้องรองรับโปรไฟล์ 0 ระดับ 3
- [C-1-1] ต้องรองรับการเขียนไฟล์ Matroska WebM
- [C-1-3] ต้องสร้างข้อมูล CodecPrivate
- ควรสนับสนุนโปรไฟล์การถอดรหัส HD ตามที่ระบุในตารางต่อไปนี้
- [SR] ขอแนะนำอย่างยิ่งให้รองรับโปรไฟล์การถอดรหัส HD ตามที่ระบุไว้ในตารางต่อไปนี้หากมีฮาร์ดแวร์เปลี่ยนไฟล์
SD | HD 720p | HD 1080p | UHD | |
---|---|---|---|---|
ความละเอียดของวิดีโอ | 720 x 480 พิกเซล | 1280 x 720 พิกเซล | 1920 x 1080 พิกเซล | 3840 x 2160 พิกเซล |
อัตราเฟรมของวิดีโอ | 30 fps | 30 fps | 30 fps | 30 fps |
อัตราบิตของวิดีโอ | 1.6 Mbps | 4 Mbps | 5 Mbps | 20 Mbps |
หากการใช้งานอุปกรณ์อ้างว่ารองรับโปรไฟล์ 2 หรือโปรไฟล์ 3 ผ่าน Media API
- การรองรับรูปแบบ 12 บิตเป็นตัวเลือกที่ไม่บังคับ
5.2.5 H.265
หากอุปกรณ์รองรับตัวแปลงรหัส H.265 อุปกรณ์จะทำงานดังนี้
- [C-1-1] ต้องรองรับโปรไฟล์หลักระดับ 3
- ควรรองรับโปรไฟล์การเข้ารหัส HD ตามที่ระบุไว้ในตารางต่อไปนี้
- [SR] ขอแนะนำอย่างยิ่งให้รองรับโปรไฟล์การเข้ารหัส HD ตามที่ระบุไว้ในตารางต่อไปนี้หากมีฮาร์ดแวร์เปลี่ยนไฟล์
SD | HD 720p | HD 1080p | UHD | |
---|---|---|---|---|
ความละเอียดของวิดีโอ | 720 x 480 พิกเซล | 1280 x 720 พิกเซล | 1920 x 1080 พิกเซล | 3840 x 2160 พิกเซล |
อัตราเฟรมของวิดีโอ | 30 fps | 30 fps | 30 fps | 30 fps |
อัตราบิตของวิดีโอ | 1.6 Mbps | 4 Mbps | 5 Mbps | 20 Mbps |
5.3 การถอดรหัสวิดีโอ
หากการติดตั้งใช้งานอุปกรณ์รองรับตัวแปลงรหัส VP8, VP9, H.264 หรือ H.265 ระบบจะดำเนินการดังต่อไปนี้
- [C-1-1] ต้องรองรับความละเอียดของวิดีโอแบบไดนามิกและอัตราเฟรมที่สลับผ่าน Android API มาตรฐานภายในสตรีมเดียวกันสำหรับตัวแปลงรหัส VP8, VP9, H.264 และ H.265 ทั้งหมดในแบบเรียลไทม์และสูงสุดถึงความละเอียดสูงสุดที่ตัวแปลงรหัสแต่ละตัวบนอุปกรณ์รองรับ
5.3.1 MPEG-2
หากการติดตั้งอุปกรณ์รองรับตัวถอดรหัส MPEG-2 การดำเนินการต่อไปนี้
- [C-1-1] ต้องสนับสนุนระดับสูงของโปรไฟล์หลัก
5.3.2 H.263
หากการติดตั้งใช้งานอุปกรณ์รองรับตัวถอดรหัส H.263 สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-1-1] ต้องรองรับโปรไฟล์พื้นฐานระดับ 30 และระดับ 45
5.3.3 MPEG-4
หากอุปกรณ์มีตัวถอดรหัส MPEG-4 สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-1-1] ต้องรองรับ Simple Profile ระดับ 3
5.3.4 H.264
หากการติดตั้งใช้งานอุปกรณ์รองรับตัวถอดรหัส H.264 ระบบจะดำเนินการต่อไปนี้
- [C-1-1] ต้องรองรับโปรไฟล์หลักระดับ 3.1 และโปรไฟล์พื้นฐาน ระบบรองรับ ASO (Arbitrary Slice Ordering), FMO (แบบยืดหยุ่น Macroblock Ordering) และ RS (Slice ที่ซ้ำซ้อน) ไม่บังคับ
- [C-1-2] ต้องสามารถถอดรหัสวิดีโอที่มีโปรไฟล์ SD (ความละเอียดมาตรฐาน) ที่แสดงอยู่ในตารางต่อไปนี้และเข้ารหัสด้วยโปรไฟล์พื้นฐานและโปรไฟล์หลักระดับ 3.1 (รวมถึง 720p30)
- ควรสามารถถอดรหัสวิดีโอที่มีโปรไฟล์ HD (ความละเอียดสูง) ตามที่ระบุไว้ในตารางต่อไปนี้
หากความสูงที่เมธอด Display.getSupportedModes()
รายงานเท่ากับหรือมากกว่าความละเอียดของวิดีโอ การใช้งานอุปกรณ์จะมีลักษณะดังนี้
- [C-2-1] ต้องรองรับโปรไฟล์การถอดรหัสวิดีโอ HD 720p ในตารางต่อไปนี้
- [C-2-2] ต้องรองรับโปรไฟล์การถอดรหัสวิดีโอ HD 1080p ในตารางต่อไปนี้
SD (คุณภาพต่ำ) | SD (คุณภาพสูง) | HD 720p | HD 1080p | |
---|---|---|---|---|
ความละเอียดของวิดีโอ | 320 x 240 พิกเซล | 720 x 480 พิกเซล | 1280 x 720 พิกเซล | 1920 x 1080 พิกเซล |
อัตราเฟรมของวิดีโอ | 30 fps | 30 fps | 60 FPS | 30 FPS (60 FPS ทีวี) |
อัตราบิตของวิดีโอ | 800 Kbps | 2 Mbps | 8 Mbps | 20 Mbps |
5.3.5 H.265 (HEVC)
หากอุปกรณ์รองรับตัวแปลงรหัส H.265 อุปกรณ์จะทำงานดังนี้
- [C-1-1] ต้องสนับสนุนระดับหลักของโปรไฟล์หลักระดับ 3 และโปรไฟล์การถอดรหัสวิดีโอ SD ตามที่ระบุไว้ในตารางต่อไปนี้
- ควรสนับสนุนโปรไฟล์การถอดรหัส HD ตามที่ระบุในตารางต่อไปนี้
- [C-1-2] ต้องรองรับโปรไฟล์การถอดรหัส HD ตามที่ระบุไว้ในตารางต่อไปนี้ หากมีตัวถอดรหัสฮาร์ดแวร์
หากความสูงที่เมธอด Display.getSupportedModes()
รายงานเท่ากับหรือมากกว่าความละเอียดของวิดีโอ ให้ทำดังนี้
- [C-2-1] การใช้งานอุปกรณ์ต้องรองรับการถอดรหัส H.265 หรือ VP9 ของโปรไฟล์ 720, 1080 และ UHD อย่างน้อย 1 รายการ
SD (คุณภาพต่ำ) | SD (คุณภาพสูง) | HD 720p | HD 1080p | UHD | |
---|---|---|---|---|---|
ความละเอียดของวิดีโอ | 352 x 288 พิกเซล | 720 x 480 พิกเซล | 1280 x 720 พิกเซล | 1920 x 1080 พิกเซล | 3840 x 2160 พิกเซล |
อัตราเฟรมของวิดีโอ | 30 fps | 30 fps | 30 fps | 30/60 FPS (60 fps ทีวีที่มีการถอดรหัสฮาร์ดแวร์ H.265) | 60 FPS |
อัตราบิตของวิดีโอ | 600 Kbps | 1.6 Mbps | 4 Mbps | 5 Mbps | 20 Mbps |
หากการใช้งานอุปกรณ์อ้างว่ารองรับโปรไฟล์ HDR ผ่าน Media API
- [C-3-1] การใช้งานอุปกรณ์ต้องยอมรับข้อมูลเมตา HDR ที่จำเป็นจากแอปพลิเคชัน รวมถึงรองรับการดึงและเอาต์พุตข้อมูลเมตา HDR ที่จำเป็นจากบิตสตรีมและ/หรือคอนเทนเนอร์
- [C-3-2] การใช้งานอุปกรณ์ต้องแสดงเนื้อหา HDR อย่างถูกต้องในหน้าจอของอุปกรณ์หรือบนพอร์ตเอาต์พุตวิดีโอมาตรฐาน (เช่น HDMI)
5.3.6 VP8
หากอุปกรณ์รองรับตัวแปลงรหัส VP8 อุปกรณ์ดังกล่าวจะมีลักษณะดังนี้
- [C-1-1] ต้องรองรับโปรไฟล์การถอดรหัส SD ในตารางต่อไปนี้
- ควรใช้ตัวแปลงรหัส VP8 สำหรับฮาร์ดแวร์ที่ตรงตามข้อกำหนด
- ควรสนับสนุนโปรไฟล์การถอดรหัส HD ในตารางต่อไปนี้
หากความสูงตามที่รายงานโดยเมธอด Display.getSupportedModes()
เท่ากับหรือมากกว่าความละเอียดของวิดีโอแล้ว ให้ทำดังนี้
- [C-2-1] การใช้งานอุปกรณ์ต้องรองรับโปรไฟล์ 720p ในตารางต่อไปนี้
- [C-2-2] การใช้งานอุปกรณ์ต้องรองรับโปรไฟล์ 1080p ในตารางต่อไปนี้
SD (คุณภาพต่ำ) | SD (คุณภาพสูง) | HD 720p | HD 1080p | |
---|---|---|---|---|
ความละเอียดของวิดีโอ | 320 x 180 พิกเซล | 640 x 360 พิกเซล | 1280 x 720 พิกเซล | 1920 x 1080 พิกเซล |
อัตราเฟรมของวิดีโอ | 30 fps | 30 fps | 30 FPS (60 FPS ทีวี) | 30 (60 FPSทีวี) |
อัตราบิตของวิดีโอ | 800 Kbps | 2 Mbps | 8 Mbps | 20 Mbps |
5.3.7 VP9
หากอุปกรณ์รองรับตัวแปลงรหัส VP9 อุปกรณ์จะทำงานดังนี้
- [C-1-1] ต้องรองรับโปรไฟล์การถอดรหัสวิดีโอ SD ตามที่ระบุไว้ในตารางต่อไปนี้
- ควรสนับสนุนโปรไฟล์การถอดรหัส HD ตามที่ระบุในตารางต่อไปนี้
หากการใช้งานอุปกรณ์รองรับตัวแปลงรหัส VP9 และตัวถอดรหัสฮาร์ดแวร์
- [C-2-1] ต้องสนับสนุนโปรไฟล์การถอดรหัส HD ที่ระบุในตารางต่อไปนี้
หากความสูงที่เมธอด Display.getSupportedModes()
รายงานเท่ากับหรือมากกว่าความละเอียดของวิดีโอ ให้ทำดังนี้
- [C-3-1] การใช้งานอุปกรณ์ต้องรองรับการถอดรหัส VP9 หรือ H.265 อย่างน้อย 1 รายการของโปรไฟล์ 720, 1080 และ UHD
SD (คุณภาพต่ำ) | SD (คุณภาพสูง) | HD 720p | HD 1080p | UHD | |
---|---|---|---|---|---|
ความละเอียดของวิดีโอ | 320 x 180 พิกเซล | 640 x 360 พิกเซล | 1280 x 720 พิกเซล | 1920 x 1080 พิกเซล | 3840 x 2160 พิกเซล |
อัตราเฟรมของวิดีโอ | 30 fps | 30 fps | 30 fps | 30 fps (60 fpsทีวีที่มีการถอดรหัสฮาร์ดแวร์ VP9) | 60 FPS |
อัตราบิตของวิดีโอ | 600 Kbps | 1.6 Mbps | 4 Mbps | 5 Mbps | 20 Mbps |
หากการติดตั้งใช้งานอุปกรณ์อ้างว่ารองรับ VP9Profile2
หรือ VP9Profile3
ผ่าน API สื่อ "CodecProfileLevel"
- การรองรับรูปแบบ 12 บิตเป็นตัวเลือกที่ไม่บังคับ
หากการใช้งานอุปกรณ์อ้างว่ารองรับโปรไฟล์ HDR (VP9Profile2HDR
, VP9Profile2HDR10Plus
, VP9Profile3HDR
, VP9Profile3HDR10Plus
) ผ่าน API ของสื่อ ให้ทำดังนี้
- [C-4-1] การใช้งานอุปกรณ์ต้องยอมรับข้อมูลเมตา HDR ที่จำเป็น (
KEY_HDR_STATIC_INFO
สำหรับโปรไฟล์ HDR ทั้งหมดและ "KEY_HDR10_PLUS_INFO" สำหรับโปรไฟล์ HDR10Plus) จากแอปพลิเคชัน นอกจากนี้ยังต้องรองรับการดึงและเอาต์พุตข้อมูลเมตา HDR ที่จำเป็นจากบิตสตรีมและ/หรือคอนเทนเนอร์ - [C-4-2] การใช้งานอุปกรณ์ต้องแสดงเนื้อหา HDR อย่างถูกต้องในหน้าจอของอุปกรณ์หรือบนพอร์ตเอาต์พุตวิดีโอมาตรฐาน (เช่น HDMI)
5.3.8 Dolby Vision
หากการใช้งานอุปกรณ์ประกาศการรองรับตัวถอดรหัส Dolby Vision ผ่าน HDR_TYPE_DOLBY_VISION
ระบบจะดำเนินการดังต่อไปนี้
- [C-1-1] ต้องมีอุปกรณ์แยกที่รองรับ Dolby Vision
- [C-1-2] ต้องแสดงเนื้อหา Dolby Vision อย่างถูกต้องในหน้าจอของอุปกรณ์หรือบนพอร์ตเอาต์พุตวิดีโอมาตรฐาน (เช่น HDMI)
- [C-1-3] ต้องตั้งค่าดัชนีแทร็กของเลเยอร์ฐานที่เข้ากันได้แบบย้อนหลัง (หากมี) ให้เหมือนกับดัชนีแทร็กของเลเยอร์ Dolby Vision แบบรวม
5.3.9 AV1
หากอุปกรณ์รองรับตัวแปลงรหัส AV1 อุปกรณ์จะทำงานดังนี้
- [C-1-1] ต้องรองรับโปรไฟล์ 0 ที่รวมเนื้อหาแบบ 10 บิต
5.4 การบันทึกเสียง
แม้ว่าข้อกำหนดบางส่วนที่ระบุไว้ในส่วนนี้จะแสดงเป็น "ควร" นับตั้งแต่ Android 4.3 แต่เราวางแผนที่จะเปลี่ยนคำจำกัดความความเข้ากันได้สำหรับเวอร์ชันในอนาคตเป็น "ต้อง" เราแนะนำอุปกรณ์ Android ที่มีอยู่และอุปกรณ์ใหม่ให้ปฏิบัติตามข้อกำหนดเหล่านี้ที่ระบุว่า "ควร" หรือจะไม่สามารถใช้กับ Android เมื่ออัปเกรดเป็นเวอร์ชันอนาคต
5.4.1 การบันทึกเสียงและข้อมูลไมโครโฟนแบบข้อมูลดิบ
การใช้งานอุปกรณ์จะประกาศ android.hardware.microphone
ดังต่อไปนี้
-
[C-1-1] ต้องอนุญาตให้มีการบันทึกเนื้อหาเสียงดิบที่มีคุณลักษณะต่อไปนี้
- รูปแบบ: PCM เชิงเส้น 16 บิต
- อัตราการสุ่มตัวอย่าง: 8000, 11025, 16000, 44100, 48000 Hz
- ช่องสัญญาณ: โมโน
-
ควรอนุญาตให้บันทึกเนื้อหาเสียงดิบที่มีลักษณะเฉพาะต่อไปนี้
- รูปแบบ: PCM เชิงเส้น 16 บิต และ 24 บิต
- อัตราการสุ่มตัวอย่าง: 8000, 11025, 16000, 22050, 24000, 32000, 44100, 48000 Hz
- ช่องสัญญาณ: กี่ช่องเท่ากับจำนวนไมโครโฟนบนอุปกรณ์
-
[C-1-2] ต้องจับอัตราการสุ่มตัวอย่างสูงกว่าโดยไม่มีการสุ่มตัวอย่าง
- [C-1-3] ต้องระบุตัวกรองการลดรอยหยักที่เหมาะสมเมื่ออัตราการสุ่มตัวอย่างที่ระบุข้างต้นได้รับการบันทึกในการสุ่มตัวอย่าง
-
ควรอนุญาตให้มีการบันทึกคุณภาพวิทยุและดีวีดี AM ของเนื้อหาเสียงดิบ ซึ่งหมายความว่ามีคุณลักษณะดังต่อไปนี้
- รูปแบบ: PCM เชิงเส้น 16 บิต
- อัตราการสุ่มตัวอย่าง: 22050, 48000 Hz
- ช่องสัญญาณ: สเตอริโอ
- [C-1-4] ต้องใช้
MicrophoneInfo
API และกรอกข้อมูลอย่างเหมาะสมสำหรับไมโครโฟนที่ใช้งานได้ในอุปกรณ์ที่แอปพลิเคชันของบุคคลที่สามเข้าถึงได้ผ่านAudioManager.getMicrophones()
API และไมโครโฟนที่ใช้งานอยู่ในปัจจุบันซึ่งแอปพลิเคชันของบุคคลที่สามเข้าถึงได้ผ่านทาง APIAudioRecord.getActiveMicrophones()
และMediaRecorder.getActiveMicrophones()
หากการติดตั้งอุปกรณ์อนุญาตให้บันทึกคุณภาพวิทยุและดีวีดี AM ของเนื้อหาเสียงดิบ จะมีผลดังนี้
-
[C-2-1] ต้องจับภาพโดยไม่มีการสุ่มตัวอย่างในอัตราส่วนที่สูงกว่า 16000:22050 หรือ 44100:48000
- [C-2-2] ต้องมีตัวกรองขจัดรอยหยักที่เหมาะสมสำหรับการเพิ่มหรือการสุ่มตัวอย่าง
5.4.2 จับภาพสำหรับการจดจำเสียง
การใช้งานอุปกรณ์จะประกาศ android.hardware.microphone
ดังต่อไปนี้
- [C-1-1] ต้องบันทึกแหล่งที่มาของเสียง
android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION
ที่อัตราการสุ่มตัวอย่างแบบใดแบบหนึ่ง ได้แก่ 44100 และ 48000 - [C-1-2] โดยค่าเริ่มต้น ต้องปิดใช้การประมวลผลเสียงที่มีการลดเสียงรบกวนเมื่อบันทึกสตรีมเสียงจากแหล่งที่มาเสียง
AudioSource.VOICE_RECOGNITION
- [C-1-3] โดยค่าเริ่มต้น ต้องปิดใช้การควบคุมค่าเกนอัตโนมัติเมื่อบันทึกสตรีมเสียงจากแหล่งที่มาเสียง
AudioSource.VOICE_RECOGNITION
- ควรบันทึกสตรีมเสียงสำหรับการจดจำเสียงที่มีคุณลักษณะแอมพลิจูดแบบราบเรียบโดยประมาณเมื่อเทียบกับความถี่ ±3 dB ตั้งแต่ 100 Hz ถึง 4000 Hz
- ควรบันทึกสตรีมเสียงสำหรับการจดจำเสียงด้วยการตั้งค่าความไวต่ออินพุตที่แหล่งพลังงานเสียง (SPL) 90 dB ที่ 1000 Hz จะให้ค่า RMS 2500 สำหรับตัวอย่าง 16 บิต
- ควรบันทึกสตรีมเสียงของการจดจำเสียงเพื่อให้ระดับแอมพลิจูด PCM ติดตามการเปลี่ยนแปลง SPL ของอินพุตแบบเชิงเส้นที่ช่วง -18 dB ถึง -18 dB ถึง +12 dB re 90 dB SPL ที่ไมโครโฟน
- ควรบันทึกสตรีมเสียงสำหรับการจดจำเสียงที่มีความผิดเพี้ยนแบบฮาร์มอนิก (THD) น้อยกว่า 1% สำหรับ 1 kHz ที่ระดับอินพุต SPL 90 dB ที่ไมโครโฟน
หากการติดตั้งใช้งานอุปกรณ์ประกาศ android.hardware.microphone
และเทคโนโลยีการตัดเสียงรบกวน (การลด) ที่ปรับแต่งสำหรับการจดจำคำพูด เทคโนโลยีดังกล่าวจะดำเนินการดังนี้
- [C-2-1] ต้องอนุญาตให้ควบคุมเอฟเฟกต์เสียงนี้ด้วย
android.media.audiofx.NoiseSuppressor
API ได้ - [C-2-2] ต้องระบุการใช้งานเทคโนโลยีการตัดเสียงรบกวนแต่ละรายการที่ไม่ซ้ำกันผ่านฟิลด์
AudioEffect.Descriptor.uuid
5.4.3 จับภาพเพื่อเปลี่ยนเส้นทางการเล่น
ชั้นเรียน android.media.MediaRecorder.AudioSource
มีแหล่งที่มาของเสียง REMOTE_SUBMIX
หากการใช้งานอุปกรณ์ประกาศทั้ง android.hardware.audio.output
และ android.hardware.microphone
ระบบจะดำเนินการต่อไปนี้
-
[C-1-1] ต้องใช้แหล่งที่มาของเสียง
REMOTE_SUBMIX
อย่างถูกต้องเพื่อที่ว่าเมื่อแอปพลิเคชันใช้android.media.AudioRecord
API ในการบันทึกจากแหล่งที่มาเสียงนี้ แอปจะบันทึกการรวมสตรีมเสียงทั้งหมด ยกเว้นรายการต่อไปนี้-
AudioManager.STREAM_RING
-
AudioManager.STREAM_ALARM
-
AudioManager.STREAM_NOTIFICATION
-
5.4.4 อุปกรณ์ตัดเสียงก้อง
การใช้งานอุปกรณ์จะประกาศ android.hardware.microphone
ดังต่อไปนี้
- ควรใช้เทคโนโลยี Acomatic EchoCanceler (AEC) ที่ปรับแต่งสำหรับการสื่อสารด้วยเสียงและใช้กับเส้นทางการจับภาพเมื่อจับภาพโดยใช้
AudioSource.VOICE_COMMUNICATION
หากการใช้อุปกรณ์มีตัวยกเลิกเสียงสะท้อน (Acomatic EchoCanceler) ซึ่งจะแทรกอยู่ในเส้นทางเสียงเมื่อเลือก AudioSource.VOICE_COMMUNICATION
อุปกรณ์เหล่านั้นจะมีลักษณะดังนี้
- [C-SR] เป็น STRONGLY_RECOMMENDED เพื่อประกาศสิ่งนี้ผ่านเมธอด Acoแสดงความคิดเห็นEchoCanceler AcoชำระเงินEchoCanceler.isavailable()
- [C-SR] มีค่า STRONGLY_RECOMMENDED เพื่อให้สามารถควบคุมเอฟเฟกต์เสียงนี้ได้ด้วย AcouralEchoCanceler API
- [C-SR] คือ STRONGLY_RECOMMENDED เพื่อระบุการใช้งานเทคโนโลยี 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] ต้องอนุญาตการเล่นเนื้อหาเสียงดิบที่มีคุณลักษณะต่อไปนี้
- รูปแบบต้นฉบับ: PCM เชิงเส้น 16 บิต 8 บิต ทศนิยม
- ช่องสัญญาณ: โมโน สเตอริโอ การกำหนดค่าแบบหลายช่องทางที่ถูกต้องสูงสุด 8 ช่อง
-
อัตราการสุ่มตัวอย่าง (ในรูปแบบ Hz):
- 8000, 11025, 16000, 22050, 32000, 44100, 48000 ที่การกำหนดค่าแชแนลที่ระบุไว้ข้างต้น
- 96000 ในแบบโมโนและสเตอริโอ
-
ควรอนุญาตการเล่นเนื้อหาเสียงดิบที่มีลักษณะเฉพาะต่อไปนี้
- อัตราการสุ่มตัวอย่าง: 24,000, 48,000
5.5.2 เอฟเฟกต์เสียง
Android มี API สำหรับเอฟเฟกต์เสียงสำหรับการใช้งานในอุปกรณ์
หากการใช้งานอุปกรณ์ประกาศฟีเจอร์ android.hardware.audio.output
ระบบจะดำเนินการดังต่อไปนี้
- [C-1-1] ต้องรองรับการใช้งาน
EFFECT_TYPE_EQUALIZER
และEFFECT_TYPE_LOUDNESS_ENHANCER
ที่ควบคุมได้ผ่านคลาสย่อย AudioEffectEqualizer
และLoudnessEnhancer
- [C-1-2] ต้องรองรับการใช้งาน Visualizer API ซึ่งควบคุมได้ผ่านคลาส
Visualizer
- [C-1-3] ต้องรองรับการใช้งาน
EFFECT_TYPE_DYNAMICS_PROCESSING
ที่ควบคุมได้ผ่านคลาสย่อย AudioEffectDynamicsProcessing
- ควรรองรับการใช้งาน
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 และเมื่อเสียงที่เกี่ยวข้องแสดงต่อสภาพแวดล้อมที่ตัวแปลงสัญญาณหรือสัญญาณในอุปกรณ์ออกจากอุปกรณ์ผ่านพอร์ตและสังเกตได้จากภายนอก
- เวลาในการตอบสนองเอาต์พุตแบบ Cold เวลาในการตอบสนองของเอาต์พุตสำหรับเฟรมแรก เมื่อระบบเอาต์พุตเสียงไม่มีการใช้งานและปิดเครื่องก่อนส่งคำขอ
- เวลาในการตอบสนองของเอาต์พุตต่อเนื่อง เวลาในการตอบสนองของเอาต์พุตสำหรับเฟรมที่ตามมาหลังจากที่อุปกรณ์เล่นเสียง
- เวลาในการตอบสนองของอินพุต ช่วงเวลาระหว่างที่สภาพแวดล้อมส่งเสียงไปยังอุปกรณ์ที่ตัวแปลงสัญญาณในอุปกรณ์หรือสัญญาณเข้ามาในอุปกรณ์ผ่านพอร์ต และเมื่อแอปพลิเคชันอ่านเฟรมของข้อมูลที่เข้ารหัส PCM ที่สอดคล้องกัน
- อินพุตสูญหาย ส่วนแรกของสัญญาณอินพุตที่ใช้ไม่ได้หรือไม่พร้อมใช้งาน
- เวลาในการตอบสนองแบบ Cold input ผลรวมของเวลาอินพุตที่เสียไปและเวลาในการตอบสนองของอินพุตสำหรับเฟรมแรก เมื่อระบบอินพุตเสียงไม่มีการใช้งานและปิดเครื่องก่อนส่งคำขอ
- เวลาในการตอบสนองของอินพุตต่อเนื่อง เวลาในการตอบสนองของอินพุตสำหรับเฟรมที่ตามมาขณะที่อุปกรณ์บันทึกเสียง
- Jitter เอาต์พุต Cold ความแปรปรวนของการวัดที่แยกกันของค่าเวลาในการตอบสนองของเอาต์พุตเย็น
- ความแปรปรวนของเวลาในการตอบสนองแบบ Cold Input ความแปรปรวนของการวัดที่แยกกันของค่าเวลาในการตอบสนองของอินพุตเย็น
- เวลาในการตอบสนองไป-กลับอย่างต่อเนื่อง ผลรวมของเวลาในการตอบสนองของอินพุตอย่างต่อเนื่อง เวลาในการตอบสนองเอาต์พุตอย่างต่อเนื่อง บวกกับช่วงเวลาบัฟเฟอร์ 1 ช่วง ระยะเวลาบัฟเฟอร์จะช่วยให้แอปมีเวลาประมวลผลสัญญาณและเวลาสําหรับแอปเพื่อลดความแตกต่างของเฟสระหว่างสตรีมอินพุตและเอาต์พุต
- API คิวบัฟเฟอร์ OpenSL ES PCM ชุด API ของ OpenSL ES ที่เกี่ยวข้องกับ PCM ภายใน Android NDK
- API เสียงดั้งเดิมของเสียง ชุด API ของ AAudio ภายใน Android NDK
- การประทับเวลา คู่ที่ประกอบด้วยตำแหน่งเฟรมสัมพัทธ์ภายในสตรีมและเวลาโดยประมาณเมื่อเฟรมนั้นเข้าสู่หรือออกจากไปป์ไลน์การประมวลผลเสียงบนปลายทางที่เชื่อมโยง โปรดดูเพิ่มเติมที่ AudioTimestamp
- glitch มีการรบกวนชั่วคราวหรือค่าตัวอย่างที่ไม่ถูกต้องในสัญญาณเสียง โดยทั่วไปจะเกิดจากการบัฟเฟอร์น้อยของเอาต์พุต การบัฟเฟอร์มากเกินไปสำหรับอินพุต หรือแหล่งที่มาอื่นๆ ของสัญญาณรบกวนดิจิทัลหรือแอนะล็อก
หากการใช้งานอุปกรณ์ประกาศ android.hardware.audio.output
อุปกรณ์จะต้องเป็นไปตามข้อกําหนดหรือเกินข้อกําหนดต่อไปนี้
- [C-1-1] การประทับเวลาเอาต์พุตที่ได้จาก AudioTrack.getTimestamp และ
AAudioStream_getTimestamp
มีความแม่นยำเท่ากับ +/- 2 มิลลิวินาที - [C-1-2] เวลาในการตอบสนองแบบ Cold Output ไม่เกิน 500 มิลลิวินาที
หากการใช้งานอุปกรณ์ประกาศว่า android.hardware.audio.output
เราขอแนะนำอย่างยิ่งให้ปฏิบัติตามหรือเกินข้อกำหนดต่อไปนี้
- [C-SR] เวลาในการตอบสนองแบบ Coldเอาต์พุต 100 มิลลิวินาทีหรือน้อยกว่า เราขอแนะนำเป็นอย่างยิ่งสำหรับอุปกรณ์ที่มีอยู่และอุปกรณ์ใหม่ที่ใช้ Android เวอร์ชันนี้เพื่อให้เป็นไปตามข้อกำหนดเหล่านี้ในขณะนี้ สำหรับแพลตฟอร์มรุ่นที่จะออกในอนาคตในปี 2021 เราจะกำหนดให้เวลาในการตอบสนองของเอาต์พุตแบบ Cold 200 มิลลิวินาทีหรือน้อยกว่านั้น "ต้อง"
- [C-SR] เวลาในการตอบสนองเอาต์พุตอย่างต่อเนื่องไม่เกิน 45 มิลลิวินาที
- [C-SR] ลด Jitter เอาต์พุต Cold
- [C-SR] การประทับเวลาเอาต์พุตที่แสดงผลโดย AudioTrack.getTimestamp และ
AAudioStream_getTimestamp
ถูกต้องเป็น +/- 1 มิลลิวินาที
หากการใช้งานอุปกรณ์เป็นไปตามข้อกำหนดข้างต้น หลังการปรับเทียบเริ่มต้น เมื่อใช้ทั้งคิวบัฟเฟอร์ OpenSL ES PCM และ API เสียงแบบ AAudio สำหรับเวลาในการตอบสนองของเอาต์พุตอย่างต่อเนื่องและเวลาในการตอบสนองของเอาต์พุตแบบ Cold ส่งออกข้อมูลดังกล่าวในอุปกรณ์เอาต์พุตเสียงอย่างน้อย 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
หากการใช้อุปกรณ์ไม่เป็นไปตามข้อกำหนดสำหรับเสียงที่มีเวลาในการตอบสนองต่ำผ่านทั้งคิวบัฟเฟอร์ OpenSL ES PCM และ API เสียงแบบ AAudio แบบเนทีฟ สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-2-1] ต้องไม่รายงานการรองรับเสียงที่มีเวลาในการตอบสนองต่ำ
หากใช้อุปกรณ์รวมถึง android.hardware.microphone
อุปกรณ์จะต้องเป็นไปตามข้อกำหนดเกี่ยวกับเสียงสำหรับอินพุตต่อไปนี้
- [C-3-1] จำกัดข้อผิดพลาดในการประทับเวลาอินพุต ตามที่ AudioRecord.getTimestamp หรือ
AAudioStream_getTimestamp
แสดงผลให้เป็น +/- 2 มิลลิวินาที "ข้อผิดพลาด" หมายถึงส่วนเบี่ยงเบนไปจากค่าที่ถูกต้อง - [C-3-2] เวลาในการตอบสนองแบบ Cold input ไม่เกิน 500 มิลลิวินาที
หากการใช้งานอุปกรณ์รวม android.hardware.microphone
ด้วย เราขอแนะนำเป็นอย่างยิ่งให้ตรงตามข้อกำหนดด้านเสียงสำหรับอินพุตต่อไปนี้
- [C-SR] เวลาในการตอบสนองแบบ Cold input ไม่เกิน 100 มิลลิวินาที เราขอแนะนำเป็นอย่างยิ่งสำหรับอุปกรณ์ที่มีอยู่และอุปกรณ์ใหม่ที่ใช้ Android เวอร์ชันนี้เพื่อให้เป็นไปตามข้อกำหนดเหล่านี้ในขณะนี้ สำหรับแพลตฟอร์มรุ่นที่จะออกในอนาคตในปี 2021 เราจะกำหนดเวลาในการตอบสนองของอินพุต Cold ไม่เกิน 200 มิลลิวินาที โดย "ต้อง"
- [C-SR] เวลาในการตอบสนองต่ออินพุตต่อเนื่องไม่เกิน 30 มิลลิวินาที
- [C-SR] เวลาในการตอบสนองไป-กลับอย่างต่อเนื่องไม่เกิน 50 มิลลิวินาที
- [C-SR] ลดเสียงรบกวนของอินพุต Cold
- [C-SR] จำกัดข้อผิดพลาดในการประทับเวลาอินพุต ตามที่ AudioRecord.getTimestamp หรือ
AAudioStream_getTimestamp
แสดงผลให้เป็น +/- 1 มิลลิวินาที
5.7 โปรโตคอลเครือข่าย
การใช้งานอุปกรณ์ต้องรองรับโปรโตคอลเครือข่ายสื่อสำหรับการเล่นเสียงและวิดีโอตามที่ระบุในเอกสารประกอบของ Android SDK
หากการใช้งานอุปกรณ์มีเสียงหรือตัวถอดรหัสวิดีโอ ระบบจะดำเนินการดังต่อไปนี้
-
[C-1-1] ต้องรองรับตัวแปลงรหัสและรูปแบบคอนเทนเนอร์ที่จำเป็นทั้งหมดในส่วนที่ 5.1 ผ่าน HTTP(S)
-
[C-1-2] ต้องรองรับรูปแบบกลุ่มสื่อที่แสดงในตารางรูปแบบกลุ่มสื่อด้านล่างผ่านโปรโตคอลฉบับร่างของ HTTP Live Streaming เวอร์ชัน 7
-
[C-1-3] ต้องรองรับโปรไฟล์เสียง RTP ต่อไปนี้และตัวแปลงรหัสที่เกี่ยวข้องในตาราง RTSP ด้านล่าง สำหรับข้อยกเว้น โปรดดูเชิงอรรถของตารางในส่วนที่ 5.1
รูปแบบกลุ่มสื่อ
รูปแบบกลุ่ม | ข้อมูลอ้างอิง | การรองรับตัวแปลงรหัสที่จำเป็น |
---|---|---|
สตรีมส่ง MPEG-2 | ISO 13818 |
ตัวแปลงรหัสวิดีโอ:
ในหัวข้อ 5.1.3 และ MPEG-2 ตัวแปลงสัญญาณเสียง:
|
AAC ที่มีการจัดเฟรม ADTS และแท็ก ID3 | ISO 13818-7 | ดูรายละเอียดเกี่ยวกับ AAC และตัวแปรในหัวข้อ 5.1.1 |
WebVTT | WebVTT |
RTSP (RTP, SDP)
ชื่อโปรไฟล์ | ข้อมูลอ้างอิง | การรองรับตัวแปลงรหัสที่จำเป็น |
---|---|---|
H264 AVC | RFC 6184 | ดูรายละเอียดเกี่ยวกับ H264 AVC ในหัวข้อ 5.1.3 |
MP4A-ลาตินอเมริกา | RFC 6416 | ดูรายละเอียดเกี่ยวกับ AAC และตัวแปรในหัวข้อ 5.1.1 |
H263-1998 |
RFC 3551 RFC 4629 RFC 2190 |
ดูรายละเอียดเกี่ยวกับ H263 ได้ในหัวข้อ 5.1.3 |
H263-2000 | RFC 4629 | ดูรายละเอียดเกี่ยวกับ H263 ได้ในหัวข้อ 5.1.3 |
AMR | RFC 4867 | ดูรายละเอียดเกี่ยวกับ AMR-NB ในหัวข้อ 5.1.1 |
AMR-WB | RFC 4867 | ดูรายละเอียดเกี่ยวกับ AMR-WB ในหัวข้อ 5.1.1 |
MP4V-ES | RFC 6416 | ดูรายละเอียดเกี่ยวกับ MPEG-4 SP ในหัวข้อ 5.1.3 |
Mpeg4-generic | RFC 3640 | ดูรายละเอียดเกี่ยวกับ AAC และตัวแปรในหัวข้อ 5.1.1 |
MP2T | RFC 2250 | ดูรายละเอียดใน MPEG-2 Transport Stream ใต้ HTTP Live Streaming |
5.8 สื่อที่ปลอดภัย
หากการติดตั้งใช้งานอุปกรณ์รองรับเอาต์พุตวิดีโอที่ปลอดภัยและรองรับแพลตฟอร์มที่ปลอดภัยได้ สิ่งต่อไปนี้จะเกิดขึ้น
- [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 ผ่าน Bluetooth 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 และเส้นทางของ API เสียงดั้งเดิมของ AAudio อย่างน้อย 1 เส้นทาง
- [SR] ขอแนะนำอย่างยิ่งให้ทำตามเวลาในการตอบสนองและข้อกำหนดเกี่ยวกับเสียงแบบ USB โดยใช้ API เสียงแบบเสียงเนทีฟผ่านเส้นทาง MMAP
- [C-1-6] ต้องมีเวลาในการตอบสนองของเอาต์พุตแบบ Cold 200 มิลลิวินาทีหรือน้อยกว่า
- [C-1-7] ต้องมีเวลาในการตอบสนองของอินพุต Cold 200 มิลลิวินาทีหรือน้อยกว่า
- [SR] แนะนําอย่างยิ่งให้มอบประสิทธิภาพของ CPU ในระดับที่สม่ำเสมอขณะที่เสียงทำงานและโหลดของ CPU แตกต่างกันไป ควรทดสอบโดยใช้รหัสคอมมิต SynthMark 09b13c6f49ea089f8c31e5d035f912cc405b7ab8 ในเวอร์ชันแอป Android SynthMark ใช้ซอฟต์แวร์สังเคราะห์ที่ทำงานบนเฟรมเวิร์กเสียงจำลองที่ช่วยวัดประสิทธิภาพของระบบ แอป SynthMark จำเป็นต้องเรียกใช้โดยใช้ตัวเลือก "การทดสอบอัตโนมัติ" และได้ผลลัพธ์ต่อไปนี้
- Voicemark.90 >= 32 เสียง
- เวลาในการตอบสนองmark.fixed.little <= 15 มิลลิวินาที
- เวลาในการตอบสนองmark.dynamic.little <= 50 มิลลิวินาที
ดูคำอธิบายการเปรียบเทียบได้ในเอกสารประกอบของ SynthMark
- ควรลดความไม่ถูกต้องของนาฬิกาเสียงและความคลาดเคลื่อนตามเวลามาตรฐาน
- ควรลดการลอยของนาฬิกาเสียงที่สัมพันธ์กับ CPU
CLOCK_MONOTONIC
เมื่อใช้งานทั้งคู่ - ควรลดเวลาในการตอบสนองของเสียงผ่านตัวแปลงสัญญาณในอุปกรณ์
- ควรลดเวลาในการตอบสนองของเสียงผ่านเสียงดิจิทัล USB
- ควรบันทึกการวัดเวลาในการตอบสนองของเสียงในทุกเส้นทาง
- ควรลด Jitter ในเวลาป้อน Callback ให้เสร็จสิ้นของบัฟเฟอร์เสียง เนื่องจากส่งผลต่อเปอร์เซ็นต์การใช้งานของแบนด์วิดท์ CPU เต็มที่ได้จาก Callback
- ไม่ควรมีข้อบกพร่องของเสียงใดๆ ภายใต้การใช้งานปกติเมื่อมีเวลาในการตอบสนองที่รายงาน
- ควรระบุความแตกต่างของเวลาในการตอบสนองระหว่างช่องเป็น 0
- ควรลดเวลาในการตอบสนองเฉลี่ย MIDI ในการรับส่งข้อมูลทั้งหมด
- ควรลดความแปรปรวนของเวลาในการตอบสนอง MIDI ภายใต้โหลด (Jitter) ในการรับส่งข้อมูลทั้งหมด
- ควรระบุการประทับเวลา MIDI ที่ถูกต้องในการรับส่งข้อมูลทั้งหมด
- ควรลดเสียงรบกวนของสัญญาณเสียงที่ตัวแปลงสัญญาณในอุปกรณ์ รวมถึงระยะเวลาทันทีหลังจาก Cold Start
- ควรระบุความแตกต่างของสัญญาณเสียงเป็น 0 ระหว่างด้านอินพุตและเอาต์พุตของจุดสิ้นสุดที่เกี่ยวข้อง เมื่อทั้ง 2 ด้านทำงานอยู่ ตัวอย่างของจุดสิ้นสุดที่เกี่ยวข้อง ได้แก่ ไมโครโฟนและลำโพงในอุปกรณ์ หรืออินพุตและเอาต์พุตช่องเสียบหูฟัง
- ควรจัดการ Callback ที่เสร็จสมบูรณ์ของบัฟเฟอร์เสียงสำหรับด้านอินพุตและเอาต์พุตของจุดสิ้นสุดที่เกี่ยวข้องในเทรดเดียวกันเมื่อใช้งานทั้ง 2 ฝั่ง และป้อนเอาต์พุต Callback ทันทีหลังจาก Callback อินพุต หรือหากจัดการ Callback ในเทรดเดียวกันไม่ได้ ให้ป้อนเอาต์พุต Callback หลังจากป้อน Callback ของอินพุตเพื่อให้แอปพลิเคชันกำหนดเวลาด้านอินพุตและเอาต์พุตที่สอดคล้องกัน
- ควรลดความแตกต่างของเฟสระหว่างการบัฟเฟอร์เสียง HAL สำหรับด้านอินพุตและเอาต์พุตของจุดสิ้นสุดที่เกี่ยวข้อง
- ควรลดเวลาในการตอบสนองของการแตะ
- ควรลดความแปรปรวนของเวลาในการตอบสนองการสัมผัสภายใต้ภาระงาน (Jitter)
- ควรมีเวลาในการตอบสนองจากการป้อนข้อมูลด้วยการสัมผัสไปยังเอาต์พุตเสียงน้อยกว่าหรือเท่ากับ 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 สำหรับเสียงที่ประมวลผลแบบจุดลอยตัว/คู่ที่ขาดความแม่นยำทุกตัว)
-
[C-1-6] ต้องมีอัตราส่วนสัญญาณต่อสัญญาณรบกวน (SNR) ที่ 60 dB ขึ้นไปสำหรับไมโครโฟนทุกตัวที่ใช้บันทึกแหล่งที่มาของเสียงที่ไม่ได้ประมวลผล (ในขณะที่ SNR จะวัดความแตกต่างระหว่าง 94 dB SPL และ SPL เทียบเท่ากันของสัญญาณรบกวนตนเอง ถ่วงน้ำหนัก A)
-
[C-1-7] ต้องมีความผิดเพี้ยนแบบฮาร์มอนิก (THD) รวมน้อยกว่า 1% สำหรับ 1 kHZ ที่ระดับอินพุต SPL 90 dB ที่ไมโครโฟนทุกตัวที่ใช้บันทึกแหล่งที่มาของเสียงที่ไม่ได้ประมวลผล
-
ต้องไม่มีการประมวลผลสัญญาณอื่นๆ (เช่น การควบคุมค่าเกนอัตโนมัติ ตัวกรอง 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
-
- [C-0-2] ต้องรองรับ adb ตามที่ระบุไว้ใน Android SDK และคำสั่ง Shell ที่มีอยู่ใน AOSP ซึ่งนักพัฒนาแอปสามารถใช้ได้ รวมถึง
dumpsys
cmd stats
- [C-0-11] ต้องรองรับคำสั่ง Shell
cmd testharness
การอัปเกรดการใช้งานอุปกรณ์จาก Android เวอร์ชันก่อนหน้าโดยไม่มีการบล็อกข้อมูลแบบถาวรอาจได้รับการยกเว้น C-0-11 - [C-0-3] ต้องไม่เปลี่ยนแปลงรูปแบบหรือเนื้อหาของเหตุการณ์ในระบบอุปกรณ์ (batterystats , Diskstats, Fingerprint, graphicstats, netstats, notifications, procstats) ที่บันทึกผ่านคำสั่ง dumpsys
- [C-0-10] ต้องบันทึกโดยไม่มีการละเว้น และทำให้เหตุการณ์ต่อไปนี้เข้าถึงได้และพร้อมใช้งานสำหรับคำสั่ง Shell
cmd stats
และคลาส System APIStatsManager
- เปลี่ยนสถานะกิจกรรมเบื้องหน้าแล้ว
- ตรวจพบความผิดปกติ
- รายงานเบรดครัมบ์ของแอปแล้ว
- แอปขัดข้อง
- เกิดแอป
- เปลี่ยนระดับแบตเตอรี่แล้ว
- เปลี่ยนสถานะโหมดประหยัดแบตเตอรี่แล้ว
- BleScanผลลัพธ์ได้รับ
- เปลี่ยนสถานะ BleScan แล้ว
- เปลี่ยนสถานะการชาร์จแล้ว
- เปลี่ยนสถานะโหมดอุปกรณ์ชั่วคราวแล้ว
- เปลี่ยนสถานะของบริการที่ทำงานอยู่เบื้องหน้าแล้ว
- เปลี่ยนสถานะการสแกน GPS แล้ว
- เปลี่ยนสถานะของงานแล้ว
- สถานะเสียบปลั๊กเปลี่ยน
- เปลี่ยนสถานะงานที่กำหนดเวลาไว้แล้ว
- สถานะหน้าจอเปลี่ยน
- สถานะการซิงค์เปลี่ยนแปลง
- แบบเรียลไทม์โดยระบบ
- เปลี่ยนสถานะ UidProcess แล้ว
- เปลี่ยนสถานะ Wake Lock แล้ว
- ตั้งปลุกแล้ว
- เปลี่ยนสถานะ WifiLock
- เปลี่ยนสถานะ Wifiมัลติแคสต์ล็อกแล้ว
- เปลี่ยนสถานะการสแกน Wi-Fi แล้ว
- [C-0-4] ต้องมี adb daemon ฝั่งอุปกรณ์ไม่ทำงานโดยค่าเริ่มต้น และต้องมีกลไกที่ผู้ใช้เข้าถึงได้เพื่อเปิด Android Debug Bridge
- [C-0-5] ต้องรองรับ adb ที่ปลอดภัย Android มีการสนับสนุนสำหรับ adb ที่ปลอดภัย Secure adb จะเปิดใช้ adb ในโฮสต์ที่ตรวจสอบสิทธิ์แล้วที่รู้จัก
- [C-0-6] ต้องมีกลไกที่ทำให้สามารถเชื่อมต่อ adb จากเครื่องโฮสต์ได้ ดังนี้
หากอุปกรณ์ติดตั้งใช้งานโดยไม่มีพอร์ต USB รองรับโหมดอุปกรณ์ต่อพ่วง อุปกรณ์จะมีผลดังนี้
- [C-3-1] ต้องใช้ adb ผ่านเครือข่ายท้องถิ่น (เช่น อีเทอร์เน็ตหรือ Wi-Fi)
- [C-3-2] ต้องระบุไดรเวอร์สำหรับ Windows 7, 8 และ 10 เพื่อให้นักพัฒนาซอฟต์แวร์เชื่อมต่อกับอุปกรณ์โดยใช้โปรโตคอล adb ได้
หากการติดตั้งใช้งานอุปกรณ์รองรับการเชื่อมต่อ adb กับเครื่องโฮสต์ผ่าน Wi-Fi ระบบจะดำเนินการต่อไปนี้
- [C-4-1] ต้องมีเมธอด
AdbManager#isAdbWifiSupported()
ที่แสดงผลtrue
หากการใช้งานอุปกรณ์รองรับการเชื่อมต่อ adb กับเครื่องโฮสต์ผ่าน Wi-Fi และมีกล้องอย่างน้อย 1 ตัว อุปกรณ์จะ
- [C-5-1] ต้องมีเมธอด
AdbManager#isAdbWifiQrSupported()
ที่แสดงผลtrue
- [C-0-2] ต้องรองรับ adb ตามที่ระบุไว้ใน Android SDK และคำสั่ง Shell ที่มีอยู่ใน AOSP ซึ่งนักพัฒนาแอปสามารถใช้ได้ รวมถึง
-
บริการตรวจสอบแก้ไขข้อบกพร่องของ Daalvik (ddms)
- [C-0-7] ต้องรองรับฟีเจอร์ ddms ทั้งหมดตามที่ระบุไว้ใน Android SDK เนื่องจาก ddms ใช้ adb การสนับสนุนสำหรับ ddms ควรไม่ทำงานโดยค่าเริ่มต้น แต่ต้องมีการสนับสนุนทุกครั้งที่ผู้ใช้เปิดใช้งาน Android Debug Bridge ตามด้านบน
-
ลิง
- [C-0-8] ต้องรวมเฟรมเวิร์ก Monkey และทำให้แอปพลิเคชันสามารถใช้งานได้
-
SysTrace
- [C-0-9] ต้องรองรับเครื่องมือ systrace ตามที่ระบุไว้ใน Android SDK Systrace ต้องไม่มีการใช้งานโดยค่าเริ่มต้น และต้องมีกลไกที่ผู้ใช้เข้าถึงได้ในการเปิด Systrace
-
Perfetto
- [C-SR] ขอแนะนำอย่างยิ่งให้แสดงไบนารี
/system/bin/perfetto
ต่อผู้ใช้ Shell ซึ่ง cmdline เป็นไปตามเอกสารประกอบที่เกี่ยวข้อง - [C-SR] ขอแนะนําอย่างยิ่งให้ยอมรับไบนารี Perfetto เป็นอินพุตของการกำหนดค่า Protobuf ที่สอดคล้องกับสคีมาที่ระบุไว้ในเอกสารประกอบ Perfetto
- [C-SR] ขอแนะนําอย่างยิ่งให้ใช้ไบนารี Perfetto เพื่อเขียนเป็นเอาต์พุตการติดตาม Protobuf ที่สอดคล้องกับสคีมาที่ระบุไว้ในเอกสารประกอบ Perfetto
- [C-SR] ขอแนะนำอย่างยิ่งให้ระบุแหล่งข้อมูลที่อธิบายไว้ในเอกสาร Perfetto ผ่านทางไบนารี Perfetto
- [C-SR] ขอแนะนำอย่างยิ่งให้แสดงไบนารี
-
ประหยัดหน่วยความจำต่ำ
- [C-0-10] ต้องเขียน
LMK_KILL_OCCURRED_FIELD_NUMBER
Atom ลงในบันทึกที่มีสถิติเมื่อ Low Memory Killer สิ้นสุดการทำงานของแอป
- [C-0-10] ต้องเขียน
-
โหมดโปรแกรมทดสอบอัตโนมัติ หากการติดตั้งใช้งานอุปกรณ์รองรับคำสั่ง Shell
cmd testharness
และเรียกใช้cmd testharness enable
ระบบจะดำเนินการดังต่อไปนี้- [C-2-1] ต้องส่งคืน
true
ในราคาActivityManager.isRunningInUserTestHarness()
- [C-2-2] ต้องใช้งานโหมดโปรแกรมทดสอบอัตโนมัติตามที่อธิบายไว้ในเอกสารประกอบของโหมดโปรแกรมทดสอบ
- [C-2-1] ต้องส่งคืน
หากการติดตั้งใช้งานอุปกรณ์รายงานการรองรับ Vulkan 1.0 ขึ้นไปผ่านแฟล็กฟีเจอร์ android.hardware.vulkan.version
ระบบจะดำเนินการต่อไปนี้
- [C-1-1] ต้องจ่ายเงินให้นักพัฒนาแอปเปิด/ปิดใช้เลเยอร์แก้ไขข้อบกพร่องของ GPU
- [C-1-2] ต้องแจกแจงเลเยอร์ในไลบรารีที่เครื่องมือภายนอกมีให้ (เช่น ไม่ใช่เป็นส่วนหนึ่งของแพ็กเกจแพลตฟอร์มหรือแพ็กเกจแอปพลิเคชัน) ที่พบในแอปพลิเคชันที่สามารถแก้ไขข้อบกพร่องได้เมื่อเปิดใช้งานเลเยอร์ดีบัก GPU ไดเรกทอรีฐานเพื่อรองรับเมธอด API vkEnumerateInstanceLayerProperties() และ vkCreateInstance()
6.2 ตัวเลือกสำหรับนักพัฒนาแอป
Android มีการสนับสนุนสำหรับนักพัฒนาซอฟต์แวร์ในการกำหนดการตั้งค่าที่เกี่ยวข้องกับการพัฒนาแอปพลิเคชัน
การใช้งานอุปกรณ์ต้องมอบประสบการณ์การใช้งานที่สอดคล้องกันสำหรับตัวเลือกสำหรับนักพัฒนาซอฟต์แวร์
- [C-0-1] ต้องปฏิบัติตาม Intent android.settings.APPLICATION_DEVELOPMENT_SETTINGS เพื่อแสดงการตั้งค่าที่เกี่ยวข้องกับการพัฒนาแอปพลิเคชัน การใช้งานอัปสตรีมของ Android จะซ่อนเมนูตัวเลือกสำหรับนักพัฒนาซอฟต์แวร์โดยค่าเริ่มต้น และช่วยให้ผู้ใช้เปิดตัวเลือกสำหรับนักพัฒนาซอฟต์แวร์หลังจากกดเจ็ด (7) ครั้งในการตั้งค่า > เกี่ยวกับอุปกรณ์ > รายการในเมนูหมายเลขบิลด์
- [C-0-2] ต้องซ่อนตัวเลือกของนักพัฒนาซอฟต์แวร์โดยค่าเริ่มต้น
- [C-0-3] ต้องระบุกลไกที่ชัดเจนว่าจะไม่ให้การจัดการเป็นพิเศษแก่แอปบุคคลที่สามแอปหนึ่ง แทนที่จะเป็นอีกแอปหนึ่งเพื่อเปิดใช้ตัวเลือกสำหรับนักพัฒนาซอฟต์แวร์ ต้องระบุเอกสารหรือเว็บไซต์ที่เปิดเป็นสาธารณะซึ่งอธิบายวิธีเปิดใช้ตัวเลือกสำหรับนักพัฒนาซอฟต์แวร์ เอกสารหรือเว็บไซต์นี้ต้องลิงก์ได้จากเอกสาร Android SDK
- ควรมีการแจ้งเตือนผู้ใช้ด้วยภาพอย่างต่อเนื่องเมื่อเปิดใช้ตัวเลือกสำหรับนักพัฒนาซอฟต์แวร์และความปลอดภัยของผู้ใช้เป็นข้อกังวลใจในความปลอดภัยของผู้ใช้
- อาจจำกัดการเข้าถึงเมนูตัวเลือกสำหรับนักพัฒนาซอฟต์แวร์ชั่วคราวด้วยการซ่อนหรือปิดใช้เมนูเพื่อไม่ให้เสียสมาธิในกรณีที่เกิดข้อกังวลด้านความปลอดภัยของผู้ใช้
7. ความเข้ากันได้ของฮาร์ดแวร์
หากอุปกรณ์มีส่วนประกอบฮาร์ดแวร์ที่เจาะจงซึ่งมี API ที่สอดคล้องกันสำหรับนักพัฒนาแอปบุคคลที่สาม
- [C-0-1] การติดตั้งใช้งานอุปกรณ์ต้องใช้ API นั้นตามที่อธิบายไว้ในเอกสาร SDK ของ Android
หาก API ใน SDK โต้ตอบกับคอมโพเนนต์ฮาร์ดแวร์ที่มีการระบุว่าไม่บังคับและการใช้งานอุปกรณ์ไม่มีคอมโพเนนต์ดังกล่าว
- [C-0-2] ยังต้องแสดงคำนิยามของคลาสที่ครบถ้วน (ตามที่ SDK บันทึกไว้) สำหรับ API ของคอมโพเนนต์
- [C-0-3] ต้องมีการนำลักษณะการทำงานของ API มาใช้เป็น "ไม่ดำเนินการ" ด้วยวิธีการที่สมเหตุสมผล
- [C-0-4] เมธอด API ต้องแสดงค่า Null ตามที่ได้รับอนุญาตโดยเอกสาร SDK
- [C-0-5] เมธอด API ต้องแสดงผลการใช้งานที่ไม่มีการดำเนินการของคลาสที่เอกสาร SDK ไม่อนุญาตค่า Null
- [C-0-6] เมธอด API ต้องไม่ส่งข้อยกเว้นที่ไม่ได้ระบุไว้ในเอกสารประกอบของ SDK
- [C-0-7] การใช้งานอุปกรณ์ต้องรายงานข้อมูลการกำหนดค่าฮาร์ดแวร์ที่ถูกต้องอย่างสม่ำเสมอผ่านเมธอด
getSystemAvailableFeatures()
และhasSystemFeature(String)
ในคลาส android.content.pm.PackageManager สำหรับลายนิ้วมือของบิลด์เดียวกัน
ตัวอย่างทั่วไปของสถานการณ์ที่ข้อกำหนดเหล่านี้มีผลบังคับใช้คือ API โทรศัพท์ ซึ่งแม้แต่ในอุปกรณ์ที่ไม่ใช่โทรศัพท์ ก็จะต้องติดตั้งใช้งาน API เป็นการดำเนินการที่สมเหตุสมผล
7.1 การแสดงผลและกราฟิก
Android มีหน่วยงานที่ปรับเนื้อหาของแอปพลิเคชันและเลย์เอาต์ UI ให้เหมาะสมกับอุปกรณ์โดยอัตโนมัติ เพื่อให้มั่นใจว่าแอปพลิเคชันของบุคคลที่สามจะทำงานได้ดีบนการกำหนดค่าฮาร์ดแวร์ที่หลากหลาย ในจอแสดงผลที่รองรับ Android ซึ่งแอปพลิเคชันที่รองรับ Android ของบุคคลที่สามทั้งหมดสามารถทำงานได้ การติดตั้งใช้งานอุปกรณ์ต้องติดตั้งใช้งาน API และลักษณะการทำงานเหล่านี้อย่างถูกต้องตามรายละเอียดในส่วนนี้
หน่วยที่อ้างอิงตามข้อกำหนดในส่วนนี้มีการกำหนดไว้ดังนี้
- ขนาดแนวทแยงมุมจริง ระยะห่างเป็นนิ้วระหว่างมุม 2 มุมที่ตรงข้ามกันของส่วนที่สว่างของจอแสดงผล
- จุดต่อนิ้ว (dpi) จำนวนพิกเซลที่ครอบคลุมโดยช่วงแนวนอนหรือแนวตั้งแบบเชิงเส้นที่ 1" เมื่อมีการแสดงค่า dpi ทั้ง dpi แนวนอนและแนวตั้งต้องอยู่ในช่วงค่า
- อัตราส่วน อัตราส่วนของพิกเซลด้านยาวกับด้านที่สั้นกว่าของหน้าจอ เช่น การแสดงผลขนาด 480x854 พิกเซลจะเท่ากับ 854/480 = 1.779 หรือโดยประมาณคือ "16:9"
- ความหนาแน่นของพิกเซลอิสระ (dp) หน่วยพิกเซลเสมือนที่ได้รับการปรับมาตรฐานให้เป็นหน้าจอ 160 dpi ที่คำนวณเป็นพิกเซล = dps * (ความหนาแน่น/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_Wwatch และรายงานขนาดsmall
สําหรับConfiguration.screenLayout
ต้องมีค่าอย่างน้อย 426 dp x 320 dp - อุปกรณ์ที่รายงานขนาด
normal
สำหรับConfiguration.screenLayout
ต้องมีอย่างน้อย 480 dp x 320 dp - อุปกรณ์ที่รายงานขนาด
large
สำหรับConfiguration.screenLayout
ต้องมีอย่างน้อย 640 dp x 480 dp - อุปกรณ์ที่รายงานขนาด
xlarge
สำหรับConfiguration.screenLayout
ต้องมีอย่างน้อย 960 dp x 720 dp
- อุปกรณ์ที่ตั้งค่า
-
[C-0-2] ต้องปฏิบัติตาม ระบุการสนับสนุนขนาดหน้าจอผ่านแอตทริบิวต์ <
supports-screens
> ใน AndroidManifest.xml ตามที่อธิบายไว้ในเอกสารประกอบของ Android SDK -
อาจมีจอแสดงผลที่ใช้งานได้กับ Android ซึ่งมีมุมโค้งมน
หากอุปกรณ์รองรับ UI_MODE_TYPE_NORMAL
และมีจอแสดงผลที่ใช้ได้กับ Android ซึ่งมีมุมโค้งมน ระบบจะดำเนินการต่อไปนี้
- [C-1-1] ต้องตรวจสอบว่าตรงตามข้อกำหนดต่อไปนี้อย่างน้อย 1 ข้อ
- รัศมีของมุมโค้งน้อยกว่าหรือเท่ากับ 38 dp
-
เมื่อกล่องขนาด 15 dp x 15 dp วางอยู่บนแต่ละมุมของจอแสดงผลเชิงตรรกะ อย่างน้อย 1 พิกเซลของแต่ละกล่องจะปรากฏบนหน้าจอ
-
ควรรวมทางเลือกของผู้ใช้ในการเปลี่ยนไปใช้โหมดการแสดงผลด้วยมุมสี่เหลี่ยมผืนผ้า
หากการใช้งานอุปกรณ์รวมถึงจอแสดงผลที่ใช้งานได้กับ Android ซึ่งพับได้หรือมีบานพับแบบพับได้ระหว่างแผงจอแสดงผลหลายแผงและทำให้จอแสดงผลดังกล่าวพร้อมแสดงผลแอปของบุคคลที่สาม อุปกรณ์ดังกล่าวจะต้องมีคุณสมบัติดังนี้
- [C-2-1] ต้องใช้ extensions API เวอร์ชันเสถียรล่าสุดที่มีให้ใช้งาน หรือ sidecar API เวอร์ชันเสถียรที่ไลบรารี Window Manager Jetpack ใช้งาน
หากการใช้งานอุปกรณ์รวมถึงจอแสดงผลที่ใช้งานได้กับ Android ซึ่งพับได้หรือมีบานพับแบบพับได้ระหว่างแผงจอแสดงผลหลายแผง และหากบานพับหรือพับตัดผ่านหน้าต่างแอปพลิเคชันแบบเต็มหน้าจอ อุปกรณ์เหล่านั้นจะมีลักษณะดังนี้
- [C-3-1] ต้องรายงานตำแหน่ง ขอบเขต และสถานะของบานพับหรือพับส่วนต่อท้ายหรือ API ช่วยเหลือไปยังแอปพลิเคชัน
หากต้องการรายละเอียดเกี่ยวกับการใช้ API ไฟล์ช่วยเหลือหรือส่วนขยายอย่างถูกต้อง โปรดดูเอกสารสาธารณะของ Window Manager Jetpack
7.1.1.2 สัดส่วนภาพหน้าจอ
แม้จะไม่มีข้อจำกัดใดๆ เกี่ยวกับสัดส่วนภาพจริงของจอแสดงผลที่ใช้งานร่วมกับ Android ได้ แต่สัดส่วนภาพของจอลอจิคัลที่มีการแสดงผลแอปของบุคคลที่สาม ซึ่งอาจมาจากค่าความสูงและความกว้างที่รายงานผ่าน API ของ view.Display
และ API ของการกำหนดค่า แต่ต้องเป็นไปตามข้อกำหนดต่อไปนี้
-
[C-0-1] การใช้งานอุปกรณ์ที่ตั้งค่า
Configuration.uiMode
เป็นUI_MODE_TYPE_NORMAL
ต้องมีค่าสัดส่วนภาพน้อยกว่าหรือเท่ากับ 1.86 (ประมาณ 16:9) เว้นแต่แอปจะเป็นไปตามเงื่อนไขข้อใดข้อหนึ่งต่อไปนี้- แอปประกาศว่ารองรับสัดส่วนภาพหน้าจอขนาดใหญ่ขึ้นผ่านค่าข้อมูลเมตา
android.max_aspect
- แอปประกาศว่าปรับขนาดได้ผ่านแอตทริบิวต์ android:resizeableActivity
- แอปกำหนดเป้าหมายเป็น API ระดับ 24 ขึ้นไป และไม่ได้ประกาศ
android:maxAspectRatio
ที่จะจำกัดสัดส่วนภาพที่อนุญาต
- แอปประกาศว่ารองรับสัดส่วนภาพหน้าจอขนาดใหญ่ขึ้นผ่านค่าข้อมูลเมตา
-
[C-0-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 เท่าของความหนาแน่นดั้งเดิม
- เราแนะนำให้กำหนดการปรับขนาดของตัวเลือกการแสดงเนทีฟต่อไปนี้ (ขณะเดียวกันก็ปฏิบัติตามขีดจำกัดที่ระบุไว้ด้านบน) เพื่อให้สามารถใช้งานได้อย่างเหมาะสมและมีขนาดแบบอักษรที่สอดคล้องกัน
- เล็ก: 0.85 เท่า
- ค่าเริ่มต้น: 1 เท่า (ขนาดโฆษณาแบบดิสเพลย์เนทีฟ)
- ใหญ่: 1.15 เท่า
- ใหญ่กว่า: 1.3 เท่า
- ใหญ่ที่สุด 1.45 เท่า
7.1.2 แสดงเมตริก
หากอุปกรณ์มีจอแสดงผลหรือเอาต์พุตวิดีโอที่ใช้งานร่วมกับ Android ได้ไปยังหน้าจอแสดงผลที่รองรับการใช้งาน Android ระบบจะดำเนินการดังต่อไปนี้
- [C-1-1] ต้องรายงานค่าที่ถูกต้องสำหรับเมตริกการแสดงผลทั้งหมดที่ใช้ร่วมกับ Android ได้ที่กำหนดไว้ใน
android.util.DisplayMetrics
API
หากอุปกรณ์ไม่มีการแสดงผลหรือหน้าจอแบบฝัง ระบบจะดำเนินการต่อไปนี้
- [C-2-1] ต้องรายงานค่าที่ถูกต้องของจอแสดงผลที่รองรับ Android ตามที่กำหนดไว้ใน
android.util.DisplayMetrics
API สำหรับview.Display
เริ่มต้นที่เลียนแบบ
7.1.3 การวางแนวหน้าจอ
การติดตั้งใช้งานอุปกรณ์
- [C-0-1] ต้องรายงานการวางแนวหน้าจอที่รองรับ (
android.hardware.screen.portrait
และ/หรือandroid.hardware.screen.landscape
) และต้องรายงานการวางแนวที่รองรับอย่างน้อย 1 แนว ตัวอย่างเช่น อุปกรณ์ที่มีหน้าจอแนวนอนตามการวางแนวที่คงที่ เช่น ทีวีหรือแล็ปท็อป ควรรายงานเฉพาะandroid.hardware.screen.landscape
- [C-0-2] ต้องรายงานค่าที่ถูกต้องสำหรับการวางแนวปัจจุบันของอุปกรณ์ เมื่อใดก็ตามที่ค้นหาผ่าน
android.content.res.Configuration.orientation
,android.view.Display.getOrientation()
หรือ API อื่นๆ
หากการใช้งานอุปกรณ์รองรับการวางแนวหน้าจอทั้ง 2 แบบ จะมีผลดังนี้
- [C-1-1] ต้องรองรับการวางแนวแบบไดนามิกโดยแอปพลิเคชันสำหรับการวางแนวหน้าจอแนวตั้งหรือแนวนอน กล่าวคือ อุปกรณ์ต้องเป็นไปตามคำขอของแอปพลิเคชันสำหรับการวางแนวหน้าจอที่เฉพาะเจาะจง
- [C-1-2] ต้องไม่เปลี่ยนขนาดหน้าจอหรือความหนาแน่นที่รายงานเมื่อเปลี่ยนการวางแนว
- อาจเลือกการวางแนวตั้งหรือแนวนอนเป็นค่าเริ่มต้น
7.1.4 การเร่งกราฟิก 2 มิติและ 3 มิติ
7.1.4.1 OpenGL ES
การติดตั้งใช้งานอุปกรณ์
- [C-0-1] ต้องระบุเวอร์ชัน OpenGL ES ที่รองรับ (1.1, 2.0, 3.0, 3.1, 3.2) ผ่าน API ที่มีการจัดการ (เช่น ผ่านเมธอด
GLES10.getString()
) และ API แบบเนทีฟอย่างถูกต้อง - [C-0-2] ต้องมีการรองรับสำหรับ API ที่มีการจัดการและ API แบบเนทีฟทั้งหมดที่เกี่ยวข้องสำหรับ OpenGL ES ทุกเวอร์ชันที่ระบุให้รองรับ
หากการใช้งานอุปกรณ์มีหน้าจอหรือเอาต์พุตวิดีโอ ระบบจะดำเนินการดังต่อไปนี้
- [C-1-1] ต้องรองรับทั้ง OpenGL ES 1.1 และ 2.0 ตามที่อธิบายไว้และระบุไว้ในเอกสารประกอบ Android SDK
- [C-SR] ขอแนะนำอย่างยิ่งให้รองรับ 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] ต้องรองรับแพ็กส่วนขยาย Android ของ OpenGL ES ทั้งหมด
หากการติดตั้งใช้งานอุปกรณ์รองรับแพ็กส่วนขยาย Android ของ 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
การทดสอบ Vulkan dEQP ได้รับการแบ่งพาร์ติชันออกเป็นรายการทดสอบจำนวนหนึ่ง โดยแต่ละรายการมีวันที่/เวอร์ชันที่เชื่อมโยงกัน รายการเหล่านี้อยู่ในแผนผังแหล่งที่มาของ 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 APIvkEnumeratePhysicalDevices()
- [C-1-3] ต้องใช้ Vulkan 1.0 API อย่างเต็มรูปแบบสำหรับ
VkPhysicalDevice
แต่ละรายการที่แจกแจง - [C-1-4] ต้องแจกแจงเลเยอร์ซึ่งอยู่ในไลบรารีแบบเนทีฟที่ชื่อ
libVkLayer*.so
ในไดเรกทอรีไลบรารีดั้งเดิมของแพ็กเกจแอปพลิเคชันผ่าน API แบบเนทีฟของ VulkanvkEnumerateInstanceLayerProperties()
และvkEnumerateDeviceLayerProperties()
- [C-1-5] ต้องไม่แจกแจงเลเยอร์ที่มาจากไลบรารีนอกแพ็กเกจแอปพลิเคชัน หรือให้วิธีอื่นๆ ในการติดตามหรือสกัดกั้น Vulkan API เว้นแต่แอปพลิเคชันจะตั้งค่าแอตทริบิวต์
android:debuggable
เป็นtrue
- [C-1-6] ต้องรายงานสตริงส่วนขยายทั้งหมดที่ส่วนขยายเหล่านั้นสนับสนุนผ่าน API แบบเนทีฟของ Vulkan และในทางกลับกัน ต้องไม่รายงานสตริงส่วนขยายที่ไม่รองรับอย่างถูกต้อง
- [C-1-7] ต้องรองรับส่วนขยาย VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain และ VK_KHR_incremental_present
- [C-1-8] ต้องรายงานเวอร์ชันสูงสุดของการทดสอบ Vulkan dEQP ที่รองรับผ่านแฟล็กฟีเจอร์
android.software.vulkan.deqp.level
- [C-1-9] ต้องรองรับเวอร์ชัน
132317953
เป็นอย่างน้อย (ตั้งแต่วันที่ 1 มีนาคม 2019) ตามที่รายงานในแฟล็กฟีเจอร์android.software.vulkan.deqp.level
- [C-1-10] ต้องผ่านการทดสอบ Vulkan dEQP ทั้งหมดในรายการทดสอบระหว่างเวอร์ชัน
132317953
กับเวอร์ชันที่ระบุในแฟล็กฟีเจอร์android.software.vulkan.deqp.level
- [C-SR] แนะนำอย่างยิ่งให้รองรับ VK_KHR_driver_properties และส่วนขยาย VK_GOOGLE_display_timing
หากการติดตั้งใช้งานอุปกรณ์ไม่รองรับ Vulkan 1.0 ระบบจะดำเนินการต่อไปนี้
- [C-2-1] ต้องไม่ประกาศ Flag ฟีเจอร์ Vulkan ใดๆ (เช่น
android.hardware.vulkan.level
,android.hardware.vulkan.version
) - [C-2-2] ต้องไม่แจกแจง
VkPhysicalDevice
สำหรับ Vulkan Native APIvkEnumeratePhysicalDevices()
หากการติดตั้งใช้งานอุปกรณ์รวมการรองรับ Vulkan 1.1 และประกาศ Flag ฟีเจอร์ Vulkan จะมีผลดังนี้
- [C-3-1] ต้องแสดงการสนับสนุนสำหรับ
SYNC_FD
ประเภทเครื่องหมายและแฮนเดิลภายนอก รวมถึงส่วนขยาย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:hardware Accelerated หรือการเรียก API โดยตรง
การติดตั้งใช้งานอุปกรณ์
- [C-0-1] ต้องเปิดใช้การเร่งฮาร์ดแวร์โดยค่าเริ่มต้น และต้องปิดใช้การเร่งฮาร์ดแวร์หากนักพัฒนาซอฟต์แวร์ขอโดยการตั้งค่า android:hardwareAccelerated="false" หรือปิดใช้การเร่งฮาร์ดแวร์โดยตรงผ่าน Android View API
- [C-0-2] ต้องแสดงลักษณะการทำงานที่สอดคล้องกับเอกสารประกอบของ Android SDK เกี่ยวกับการเร่งฮาร์ดแวร์
Android มีออบเจ็กต์ TextureView ที่ช่วยให้นักพัฒนาซอฟต์แวร์ผสานรวมพื้นผิว OpenGL ES ที่เร่งฮาร์ดแวร์ได้โดยตรงเป็นเป้าหมายการแสดงผลในลำดับชั้น UI
การติดตั้งใช้งานอุปกรณ์
- [C-0-3] ต้องรองรับ TextureView API และต้องแสดงลักษณะการทำงานที่สอดคล้องกับการติดตั้งใช้งานอัปสตรีม Android
7.1.4.5 จอแสดงผลขอบเขตกว้าง
หากการติดตั้งใช้งานอุปกรณ์อ้างว่ารองรับการแสดงผลแบบกว้างผ่าน Configuration.isScreenWideColorGamut()
ระบบจะดำเนินการต่อไปนี้
- [C-1-1] ต้องมีจอแสดงผลที่ปรับเทียบสี
- [C-1-2] ต้องมีจอแสดงผลที่มีขอบเขตครอบคลุมขอบเขตสี sRGB ทั้งหมดในพื้นที่ CIE 1931 xyY
- [C-1-3] ต้องมีจอแสดงผลที่มีขอบเขตพื้นที่อย่างน้อย 90% ของ DCI-P3 ในพื้นที่ CIE 1931 xyY
- [C-1-4] ต้องรองรับ OpenGL ES 3.1 หรือ 3.2 และรายงานอย่างถูกต้อง
- [C-1-5] ต้องโฆษณาการรองรับส่วนขยาย
EGL_KHR_no_config_context
,EGL_EXT_pixel_format_float
,EGL_KHR_gl_colorspace
,EGL_EXT_gl_colorspace_scrgb
,EGL_EXT_gl_colorspace_scrgb_linear
,EGL_EXT_gl_colorspace_display_p3
,EGL_EXT_gl_colorspace_display_p3_linear
และEGL_EXT_gl_colorspace_display_p3_passthrough
- [C-SR] ขอแนะนำอย่างยิ่งให้สนับสนุน
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 แป้นพิมพ์
หากการใช้งานในอุปกรณ์รองรับแอปพลิเคชัน Input Method Editor (IME) ของบุคคลที่สาม ก็จะมีผลดังนี้
- [C-1-1] ต้องประกาศ Flag ฟีเจอร์
android.software.input_methods
- [C-1-2] ต้องติดตั้งใช้งาน
Input Management Framework
อย่างเต็มรูปแบบ - [C-1-3] ต้องมีซอฟต์แวร์แป้นพิมพ์ที่ติดตั้งไว้ล่วงหน้า
การใช้งานอุปกรณ์: * [C-0-1] ต้องไม่มีแป้นพิมพ์ฮาร์ดแวร์ที่ไม่ตรงกับรูปแบบที่ระบุไว้ใน android.content.res.Configuration.keyboard (QWERTY หรือ 12 คีย์) * ควรมีการใช้งานแป้นพิมพ์เสมือนเพิ่มเติม * อาจรวมแป้นพิมพ์ที่เป็นฮาร์ดแวร์
7.2.2 การนำทางแบบไม่สัมผัส
Android มีการสนับสนุนสำหรับ d-pad, แทร็กบอล และล้อเลื่อนเป็นกลไกสำหรับการนำทางแบบไม่สัมผัส
การติดตั้งใช้งานอุปกรณ์
- [C-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
สำหรับการใช้งานอุปกรณ์ทีวี ฟังก์ชัน Home ควรเป็นกลไกสำหรับค่าใช้จ่ายของผู้ใช้รายนี้ - ควรมีปุ่มสำหรับฟังก์ชัน "ล่าสุด" และ "ย้อนกลับ"
หากมีฟังก์ชัน "หน้าแรก" "ล่าสุด" หรือ "ย้อนกลับ" อยู่ ฟังก์ชันดังกล่าวจะส่งผลดังนี้
- [C-1-1] ต้องเข้าถึงได้ด้วยการดำเนินการเพียงครั้งเดียว (เช่น การแตะ ดับเบิลคลิก หรือท่าทางสัมผัส) เมื่อเข้าถึงรายการใดก็ได้
- [C-1-2] ต้องระบุตัวบ่งชี้ที่ชัดเจนว่าการดำเนินการใดจะทริกเกอร์แต่ละฟังก์ชัน การมีไอคอนที่มองเห็นได้พิมพ์อยู่บนปุ่ม การแสดงไอคอนซอฟต์แวร์ในส่วนแถบนำทางของหน้าจอ หรือการแนะนำผู้ใช้ผ่านขั้นตอนการสาธิตแบบทีละขั้นตอนระหว่างการตั้งค่าตั้งแต่แกะกล่องคือตัวอย่างของตัวบ่งชี้ดังกล่าว
การติดตั้งใช้งานอุปกรณ์
- [SR] ขอแนะนำเป็นอย่างยิ่งว่าไม่มีกลไกการป้อนข้อมูลสำหรับฟังก์ชันเมนู เนื่องจากเลิกใช้งานเพื่อใช้แถบการทำงานตั้งแต่ Android 4.0 แล้ว
หากการติดตั้งใช้งานอุปกรณ์มีฟังก์ชัน "เมนู" สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-2-1] ต้องแสดงปุ่มการทำงานเพิ่มเติมทุกครั้งที่ป๊อปอัปเมนูการดำเนินการเพิ่มเติมไม่ว่างเปล่าและแถบการทำงานปรากฏขึ้น
- [C-2-2] ต้องไม่แก้ไขตำแหน่งของป๊อปอัปการดำเนินการเพิ่มเติมที่แสดงโดยการเลือกปุ่มรายการเพิ่มเติมในแถบการทำงาน แต่อาจแสดงผลป๊อปอัปการดำเนินการเพิ่มเติมในตำแหน่งที่แก้ไขแล้วบนหน้าจอเมื่อแสดงด้วยการเลือกฟังก์ชันเมนู
หากอุปกรณ์ไม่มีฟังก์ชัน "เมนู" สำหรับความเข้ากันได้แบบย้อนหลัง จะมีการดำเนินการดังนี้
- [C-3-1] ต้องทำให้แอปพลิเคชันใช้งานฟังก์ชันเมนูได้เมื่อ
targetSdkVersion
ต่ำกว่า 10 ไม่ว่าจะด้วยปุ่มบนปุ่ม แป้นซอฟต์แวร์ หรือท่าทางสัมผัส ฟังก์ชันเมนูนี้ควรเข้าถึงได้ เว้นแต่จะซ่อนไว้ร่วมกับฟังก์ชันการนำทางอื่นๆ
หากการติดตั้งใช้งานอุปกรณ์มีฟังก์ชันผู้ช่วย สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-4-1] ต้องทำให้ฟังก์ชัน Assist สามารถเข้าถึงได้ด้วยการทำงานเพียงครั้งเดียว (เช่น การแตะ ดับเบิลคลิก หรือท่าทางสัมผัส) เมื่อเข้าถึงปุ่มนำทางอื่นๆ ได้
- [SR] แนะนำอย่างยิ่งให้ใช้การกดค้างที่ฟังก์ชัน HOME เพื่อเป็นการโต้ตอบที่กำหนดนี้
หากการนำอุปกรณ์ไปใช้งานใช้ส่วนที่ต่างกันของหน้าจอเพื่อแสดงแป้นการนำทาง แป้นจะทำงานดังนี้
- [C-5-1] แป้นนำทางต้องใช้ส่วนอื่นของหน้าจอ ไม่พร้อมใช้งานกับแอปพลิเคชันต่างๆ และต้องไม่ปิดบังหรือรบกวนส่วนของหน้าจอที่ใช้งานได้ของแอปพลิเคชัน
- [C-5-2] ต้องทำให้หน้าจอบางส่วนพร้อมใช้งานสำหรับแอปพลิเคชันที่เป็นไปตามข้อกำหนดที่ระบุไว้ในหัวข้อ 7.1.1
- [C-5-3] ต้องยึดตามแฟล็กที่แอปตั้งค่าผ่านเมธอด
View.setSystemUiVisibility()
API เพื่อให้ส่วนเฉพาะของหน้าจอ (หรือที่เรียกว่าแถบนำทาง) ถูกซ่อนอย่างเหมาะสมตามที่ระบุไว้ใน SDK
หากฟังก์ชันการนำทางมีให้ใช้งานเป็นการทำงานตามท่าทางสัมผัสบนหน้าจอ ให้ทำดังนี้
- [C-6-1]
WindowInsets#getMandatorySystemGestureInsets()
ต้องใช้เพื่อรายงานพื้นที่การจดจำท่าทางสัมผัสในหน้าแรกเท่านั้น - [C-6-2] ท่าทางสัมผัสที่เริ่มต้นภายในการยกเว้นที่ยกเว้นตามที่แอปพลิเคชันที่ทำงานอยู่เบื้องหน้าผ่าน
View#setSystemGestureExclusionRects()
แต่อยู่นอกWindowInsets#getMandatorySystemGestureInsets()
ต้องไม่ถูกดักฟังสำหรับฟังก์ชันการนำทาง ตราบใดที่อนุญาตให้ใช้ URL การยกเว้นภายในขีดจำกัดการยกเว้นสูงสุดตามที่ระบุไว้ในเอกสารสำหรับ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 มีการสนับสนุนระบบอินพุต Point หลากหลายประเภท เช่น หน้าจอสัมผัส ทัชแพด และอุปกรณ์ป้อนข้อมูลด้วยการสัมผัสปลอม การใช้งานอุปกรณ์แบบหน้าจอสัมผัสจะเชื่อมโยงกับจอแสดงผลที่ทำให้ผู้ใช้รู้สึกว่ามีการควบคุมสิ่งต่างๆ บนหน้าจอโดยตรง เนื่องจากผู้ใช้กำลังแตะหน้าจอโดยตรง ระบบจึงไม่ต้องใช้เงินช่วยเหลือเพิ่มเติมในการระบุวัตถุที่กำลังถูกดัดแปลง
การติดตั้งใช้งานอุปกรณ์
- ควรมีระบบป้อนข้อมูลตัวชี้บางประเภท (แบบเมาส์หรือการแตะ)
- ควรรองรับเคอร์เซอร์ที่ติดตามแบบอิสระโดยสมบูรณ์
หากอุปกรณ์มีหน้าจอสัมผัส (แบบแตะครั้งเดียวหรือดีกว่า) บนจอแสดงผลหลักที่เข้ากันได้กับ 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 มีระบบป้อนข้อมูลของผู้ใช้ที่ใกล้เคียงกับความสามารถของหน้าจอสัมผัสบางส่วน ตัวอย่างเช่น เมาส์หรือรีโมตคอนโทรลที่บังคับเคอร์เซอร์บนหน้าจอให้อยู่ใกล้การแตะ แต่ผู้ใช้ต้องชี้หรือโฟกัสก่อนแล้วค่อยคลิก อุปกรณ์อินพุตจํานวนมาก เช่น เมาส์ แทร็กแพด เมาส์แบบลมแบบ Gyro ตัวชี้ ไจโร จอยสติ๊ก และแทร็กแพดแบบมัลติทัชรองรับการโต้ตอบด้วยการสัมผัสปลอมได้ Android มีฟีเจอร์ android.hardware.faketouch อย่างต่อเนื่อง ซึ่งสอดคล้องกับอุปกรณ์อินพุตแบบไม่ใช่ระบบสัมผัส (ใช้ตัวชี้) ความแม่นยำสูง เช่น เมาส์หรือแทร็กแพดที่สามารถจำลองการป้อนข้อมูลด้วยการแตะได้อย่างเพียงพอ (รวมถึงการสนับสนุนท่าทางสัมผัสพื้นฐาน) และบ่งชี้ว่าอุปกรณ์รองรับฟังก์ชันของหน้าจอสัมผัสที่จำลองขึ้นมา
หากการใช้งานอุปกรณ์ไม่มีหน้าจอสัมผัส แต่รวมระบบอินพุตตัวชี้อื่นๆ ที่ต้องการใช้ อุปกรณ์ดังกล่าวจะดำเนินการดังต่อไปนี้
- ควรประกาศการรองรับ Flag ฟีเจอร์
android.hardware.faketouch
หากการติดตั้งใช้งานอุปกรณ์ประกาศการรองรับ android.hardware.faketouch
ระบบจะดำเนินการต่อไปนี้
- [C-1-1] ต้องรายงานตำแหน่งหน้าจอ X และ Y แบบสัมบูรณ์ของตำแหน่งตัวชี้ และแสดงตัวชี้แบบภาพบนหน้าจอ
- [C-1-2] ต้องรายงานเหตุการณ์การแตะที่มีโค้ดการดำเนินการซึ่งระบุการเปลี่ยนแปลงสถานะที่เกิดขึ้นในตัวชี้ขึ้นหรือลงบนหน้าจอ
- [C-1-3] ต้องรองรับการชี้ลงและขึ้นบนวัตถุบนหน้าจอ ซึ่งช่วยให้ผู้ใช้จำลองการแตะบนวัตถุบนหน้าจอได้
- [C-1-4] ต้องรองรับเคอร์เซอร์ลง ชี้ขึ้น ชี้ลง แล้วชี้ขึ้นที่ตำแหน่งเดียวกันบนวัตถุบนหน้าจอภายในเกณฑ์เวลา ซึ่งช่วยให้ผู้ใช้จำลองการแตะสองครั้งบนวัตถุบนหน้าจอได้
- [C-1-5] ต้องรองรับการชี้ลงที่จุดที่กำหนดเองบนหน้าจอ ตัวชี้จะย้ายไปยังจุดใดก็ได้ที่กำหนดเองบนหน้าจอ ตามด้วยตัวชี้ขึ้น ซึ่งช่วยให้ผู้ใช้เลียนแบบการลากด้วยการแตะได้
- [C-1-6] ต้องรองรับการชี้ลง จากนั้นอนุญาตให้ผู้ใช้ย้ายวัตถุไปยังตำแหน่งอื่นบนหน้าจอได้อย่างรวดเร็ว จากนั้นตัวชี้ขึ้นบนหน้าจอซึ่งทำให้ผู้ใช้สามารถขว้างวัตถุบนหน้าจอได้
หากการติดตั้งใช้งานอุปกรณ์ประกาศการรองรับ android.hardware.faketouch.multitouch.distinct
ระบบจะดำเนินการต่อไปนี้
- [C-2-1] ต้องประกาศการรองรับ
android.hardware.faketouch
- [C-2-2] ต้องรองรับการติดตามที่ไม่ซ้ำกันของอินพุตตัวชี้อิสระตั้งแต่ 2 รายการขึ้นไป
หากการติดตั้งใช้งานอุปกรณ์ประกาศการรองรับ android.hardware.faketouch.multitouch.jazzhand
ระบบจะดำเนินการต่อไปนี้
- [C-3-1] ต้องประกาศการรองรับ
android.hardware.faketouch
- [C-3-2] ต้องรองรับการติดตามที่ไม่ซ้ำกัน 5 (การติดตามการใช้นิ้วมือ) หรือมากกว่านั้นอินพุตของตัวชี้แบบแยกกันโดยสมบูรณ์
7.2.6 รองรับเกมคอนโทรลเลอร์
7.2.6.1 การแมปปุ่ม
การติดตั้งใช้งานอุปกรณ์
- [C-1-1] ต้องมีความสามารถในการจับคู่เหตุการณ์ HID กับค่าคงที่
InputEvent
ที่สอดคล้องกันตามที่ระบุไว้ในตารางด้านล่าง การติดตั้งใช้งานอัปสตรีม Android เป็นไปตามข้อกำหนดนี้
หากการใช้อุปกรณ์ฝังตัวควบคุมหรือเรือไว้กับตัวควบคุมแยกต่างหากในช่อง ซึ่งจะให้วิธีการในการป้อนข้อมูลเหตุการณ์ทั้งหมดที่แสดงในตารางด้านล่างนี้
- [C-2-1] ต้องประกาศแฟล็กฟีเจอร์
android.hardware.gamepad
ปุ่ม | การใช้งาน HID2 | ปุ่ม Android |
---|---|---|
A1 | 0x09 0x0001 | KEYCODE_BUTTON_A (96) |
ข1 | 0x09 0x0002 | KEYCODE_BUTTON_B (97) |
x1 | 0x09 0x0004 | KEYCODE_BUTTON_X (99) |
ปี1 | 0x09 0x0005 | KEYCODE_BUTTON_Y (100) |
D-pad1 D-pad ลง1 |
0x01 0x00393 | AXIS_HAT_Y4 |
D-pad ซ้าย1 D-pad ด้านขวา1 |
0x01 0x00393 | AXIS_HAT_X4 |
ปุ่มไหล่ซ้าย1 | 0x09 0x0007 | KEYCODE_BUTTON_L1 (102) |
ปุ่มไหล่ขวา1 | 0x09 0x0008 | KEYCODE_BUTTON_R1 (103) |
คลิกสติ๊กซ้าย1 | 0x09 0x000E | KEYCODE_BUTTON_THUMBL (106) |
คลิกสติ๊กขวา1 | 0x09 0x000f | KEYCODE_BUTTON_THUMBR (107) |
หน้าแรก1 | 0x0c 0x0223 | KEYCODE_หน้าแรก (3) |
กลับ1 | 0x0c 0x0224 | KEYCODE_BACK (4) |
KeyEvent 1 รายการ
2 การใช้งาน HID ข้างต้นจะต้องประกาศภายใน Game pad CA (0x01 0x0005)
3 การใช้งานนี้ต้องมีตรรกะขั้นต่ำเป็น 0, ค่าสูงสุดเชิงตรรกะอยู่ที่ 7, ค่าต่ำสุดทางกายภาพเป็น 0, สูงสุดทางกายภาพเป็น 315, หน่วยเป็นองศา และขนาดรายงานเป็น 4 ค่าตรรกะได้รับการกำหนดให้หมุนตามเข็มนาฬิกาออกจากแกนแนวตั้ง ตัวอย่างเช่น ค่าตรรกะ 0 หมายถึงไม่มีการหมุนและปุ่มขึ้น ขณะที่ค่าตรรกะ 1 แทนการหมุน 45 องศา และทั้งแป้นขึ้นและแป้นซ้ายที่กดอยู่
การควบคุมแบบแอนะล็อก1 | การใช้ HID | ปุ่ม Android |
---|---|---|
ทริกเกอร์ซ้าย | 0x02 0x00C5 | AXIS_LTRIGGER |
ทริกเกอร์ด้านขวา | 0x02 0x00C4 | AXIS_RTRIGGER |
จอยสติ๊กด้านซ้าย |
0x01 0x0030 0x01 0x0031 |
AXIS_X AXIS_Y |
จอยสติ๊กด้านขวา |
0x01 0x0032 0x01 0x0035 |
AXIS_Z AXIS_RZ |
เหตุการณ์การเคลื่อนไหว 1 รายการ
7.2.7 การควบคุมระยะไกล
โปรดดูส่วนที่ 2.3.1 สำหรับข้อกำหนดเฉพาะอุปกรณ์
7.3 เซ็นเซอร์
หากการใช้งานอุปกรณ์มีประเภทเซ็นเซอร์ที่เฉพาะเจาะจงซึ่งมี API ที่สอดคล้องกันสำหรับนักพัฒนาแอปบุคคลที่สาม การติดตั้งใช้งานอุปกรณ์ต้องใช้ API นั้นตามที่อธิบายไว้ในเอกสารประกอบ Android SDK และเอกสารประกอบเกี่ยวกับโอเพนซอร์สของ Android เกี่ยวกับเซ็นเซอร์
การติดตั้งใช้งานอุปกรณ์
- [C-0-1] ต้องรายงานการมีหรือไม่มีเซ็นเซอร์อย่างถูกต้องตามคลาส
android.content.pm.PackageManager
- [C-0-2] ต้องส่งรายการเซ็นเซอร์ที่รองรับที่แม่นยำผ่าน
SensorManager.getSensorList()
และใช้วิธีการที่คล้ายกัน - [C-0-3] ต้องทำงานอย่างสมเหตุสมผลสำหรับ API เซ็นเซอร์อื่นๆ ทั้งหมด (เช่น การส่งคืน
true
หรือfalse
ตามความเหมาะสมเมื่อแอปพลิเคชันพยายามลงทะเบียน Listener ไม่เรียกใช้ Listener เซ็นเซอร์เมื่อไม่มีเซ็นเซอร์ที่เกี่ยวข้อง ฯลฯ)
หากการใช้งานอุปกรณ์มีเซ็นเซอร์ประเภทเฉพาะที่มี API ที่สอดคล้องกันสำหรับนักพัฒนาซอฟต์แวร์ที่เป็นบุคคลที่สาม การติดตั้งอุปกรณ์เหล่านั้นจะดำเนินการดังต่อไปนี้
- [C-1-1] ต้องรายงานการวัดค่าเซ็นเซอร์ทั้งหมดโดยใช้ค่าหน่วยเมตริกสากล (เมตริก) ที่เกี่ยวข้องสำหรับเซ็นเซอร์แต่ละประเภทตามที่ระบุไว้ในเอกสาร Android SDK
- [C-1-2] ต้องรายงานข้อมูลเซ็นเซอร์ที่มีเวลาในการตอบสนองสูงสุด 100 มิลลิวินาที + 2 * sample_time สำหรับสตรีมเซ็นเซอร์ที่มีเวลาในการตอบสนองที่ร้องขอสูงสุดเท่ากับ 0 มิลลิวินาที เมื่อตัวประมวลผลแอปพลิเคชันทำงานอยู่ การหน่วงเวลานี้ไม่รวมการหน่วงเวลาการกรอง
- [C-1-3] ต้องรายงานตัวอย่างเซ็นเซอร์รายการแรกภายใน 400 มิลลิวินาที + 2 * ตัวอย่าง_time ของเซ็นเซอร์ที่เปิดใช้งาน ตัวอย่างนี้มีความแม่นยำเป็น 0 ได้
- [C-1-4] สำหรับ API ที่ระบุโดยเอกสาร Android SDK ให้เป็นเซ็นเซอร์แบบต่อเนื่อง การใช้งานอุปกรณ์ต้องให้ตัวอย่างข้อมูลเป็นระยะอย่างต่อเนื่องซึ่งควรมี Jitter ต่ำกว่า 3% โดย Jitter เป็นค่าเบี่ยงเบนมาตรฐานของผลต่างของค่าการประทับเวลาที่รายงานระหว่างเหตุการณ์ที่เกิดต่อเนื่องกัน
- [C-1-5] ต้องตรวจสอบว่าสตรีมเหตุการณ์เซ็นเซอร์ต้องไม่ป้องกันไม่ให้ CPU ของอุปกรณ์เข้าสู่สถานะระงับหรือเริ่มทำงานจากสถานะระงับ
- [C-1-6] ต้องรายงานเวลาของเหตุการณ์ในหน่วยนาโนวินาทีตามที่กำหนดไว้ในเอกสาร Android SDK ซึ่งแสดงเวลาที่เหตุการณ์เกิดขึ้นและซิงค์กับนาฬิกา SystemClock.elapsedRealtimeNano()
- [C-SR] ขอแนะนำเป็นอย่างยิ่งให้มีข้อผิดพลาดในการซิงค์การประทับเวลาต่ำกว่า 100 มิลลิวินาที และควรมีข้อผิดพลาดในการซิงค์การประทับเวลาต่ำกว่า 1 มิลลิวินาที
- เมื่อเปิดใช้งานเซ็นเซอร์หลายตัว การใช้พลังงานไม่ควรเกินกว่าผลรวมของการใช้พลังงานที่รายงานของเซ็นเซอร์แต่ละตัว
รายการข้างต้นเป็นเพียงตัวอย่างบางส่วนเท่านั้น ลักษณะการทำงานที่มีการบันทึกไว้ของ Android SDK และเอกสารโอเพนซอร์สของ Android บนเซ็นเซอร์จะถือว่าเชื่อถือได้
หากการใช้งานอุปกรณ์มีเซ็นเซอร์ประเภทเฉพาะที่มี API ที่สอดคล้องกันสำหรับนักพัฒนาซอฟต์แวร์ที่เป็นบุคคลที่สาม การติดตั้งอุปกรณ์เหล่านั้นจะดำเนินการดังต่อไปนี้
- [C-1-6] ต้องตั้งค่าความละเอียดที่ไม่ใช่ 0 สำหรับเซ็นเซอร์ทั้งหมด และรายงานค่าผ่านเมธอด
Sensor.getResolution()
API
เซ็นเซอร์บางประเภทเป็นวัสดุผสม ซึ่งหมายความว่าข้อมูลเหล่านั้นอาจมาจากข้อมูลที่เซ็นเซอร์อื่นอย่างน้อย 1 รายการให้ไว้ (ตัวอย่างเช่น เซ็นเซอร์การวางแนวและเซ็นเซอร์การเร่งความเร็วเชิงเส้น)
การติดตั้งใช้งานอุปกรณ์
- ควรใช้เซ็นเซอร์ประเภทเหล่านี้ เมื่อมีเซ็นเซอร์ตรวจจับทางกายภาพที่จำเป็นเบื้องต้นตามที่อธิบายไว้ในประเภทเซ็นเซอร์
หากการใช้งานอุปกรณ์มีเซ็นเซอร์คอมโพสิต อุปกรณ์เหล่านั้นจะมีลักษณะดังนี้
- [C-2-1] ต้องใช้เซ็นเซอร์ตามที่อธิบายไว้ในเอกสารประกอบเกี่ยวกับโอเพนซอร์สของ Android เกี่ยวกับเซ็นเซอร์แบบผสม
หากการใช้งานอุปกรณ์มีเซ็นเซอร์ประเภทหนึ่งๆ ซึ่งมี API ที่สอดคล้องกันสำหรับนักพัฒนาซอฟต์แวร์บุคคลที่สาม และเซ็นเซอร์รายงานเพียงค่าเดียว ระบบจะดำเนินการดังต่อไปนี้กับอุปกรณ์
- [C-3-1] ต้องตั้งค่าความละเอียดเป็น 1 สำหรับเซ็นเซอร์และรายงานค่าผ่านเมธอด
Sensor.getResolution()
API
หากการใช้งานอุปกรณ์มีเซ็นเซอร์ประเภทใดประเภทหนึ่งที่รองรับ SensorAdditionalInfo#TYPE_VEC3_CALIBRATION และเซ็นเซอร์แสดงต่อนักพัฒนาซอฟต์แวร์บุคคลที่สาม การตั้งค่าดังกล่าวจะดำเนินการดังต่อไปนี้
- [C-4-1] ต้องไม่มีพารามิเตอร์การปรับเทียบแบบคงที่ที่กำหนดโดยโรงงานในข้อมูลที่ให้ไว้
หากการใช้งานอุปกรณ์รวมตัวตรวจวัดความเร่งแบบ 3 แกน เซ็นเซอร์วัดการหมุน 3 แกน หรือเซ็นเซอร์แมกนิโตมิเตอร์ สิ่งเหล่านี้จะมีลักษณะดังต่อไปนี้
- [C-SR] แนะนำอย่างเข้มงวดเพื่อให้แน่ใจว่าตัวตรวจวัดความเร่ง เครื่องวัดการหมุน และเครื่องวัดค่าความเข้มข้นของสนามแม่เหล็กมีตำแหน่งสัมพัทธ์คงที่ ซึ่งหมายความว่าหากเปลี่ยนรูปอุปกรณ์ได้ (เช่น พับได้) แกนเซ็นเซอร์จะยังคงอยู่ในแนวเดียวกันและสอดคล้องกับระบบพิกัดเซ็นเซอร์ในสถานะการแปลงอุปกรณ์ที่เป็นไปได้ทั้งหมด
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] ต้องสามารถวัดจากการตกอย่างอิสระได้ถึงสี่เท่าของแรงโน้มถ่วง(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 mW และ 0.5 mW เมื่ออุปกรณ์อยู่ในสถานะแบบไดนามิกหรือคงที่
หากอุปกรณ์มีตัวตรวจวัดความเร่งแบบ 3 แกนและเซ็นเซอร์เครื่องวัดการหมุน 3 แกน สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-3-1] ต้องใช้เซ็นเซอร์คอมโพสิต
TYPE_GRAVITY
และTYPE_LINEAR_ACCELERATION
- [C-SR] ขอแนะนำอย่างยิ่งให้ใช้เซ็นเซอร์คอมโพสิต
TYPE_GAME_ROTATION_VECTOR
หากอุปกรณ์มีตัวตรวจวัดความเร่งแบบ 3 แกน เซ็นเซอร์เครื่องวัดการหมุน 3 แกน และเซ็นเซอร์แมกนิโตมิเตอร์ อุปกรณ์เหล่านี้จะทำงานดังนี้
- [C-4-1] ต้องใช้เซ็นเซอร์คอมโพสิต
TYPE_ROTATION_VECTOR
7.3.2 เครื่องวัดค่าความเข้มข้นของสนามแม่เหล็ก
การติดตั้งใช้งานอุปกรณ์
- [C-SR] ขอแนะนำอย่างยิ่งให้รวมเครื่องวัดค่าความเข้มข้นของสนามแม่เหล็ก (เข็มทิศ) แบบ 3 แกน
หากอุปกรณ์มีเครื่องวัดค่าความเข้มข้นของสนามแม่เหล็ก 3 แกน การทำงานดังกล่าวจะส่งผลดังนี้
- [C-1-1] ต้องใช้เซ็นเซอร์
TYPE_MAGNETIC_FIELD
- [C-1-2] ต้องรายงานเหตุการณ์ที่มีความถี่อย่างน้อย 10 Hz และควรรายงานเหตุการณ์สูงสุด 50 Hz เป็นอย่างน้อย
- [C-1-3] ต้องเป็นไปตามระบบพิกัดเซ็นเซอร์ของ Android ตามที่อธิบายไว้ใน Android API
- [C-1-4] ต้องวัดค่าระหว่าง -900 μT ถึง +900 μT บนแกนแต่ละแกนได้ก่อนความอิ่มตัว
- [C-1-5] ต้องมีค่าออฟเซ็ตเหล็กแข็งต่ำกว่า 700 μT และควรมีค่าต่ำกว่า 200 μT โดยวางเครื่องวัดค่าความเข้มข้นจากสนามแม่เหล็กแบบไดนามิก (กระแสไฟฟ้าเหนี่ยวนำ) และคงที่ (เหนี่ยวนำแม่เหล็ก)
- [C-1-6] ต้องมีความละเอียดเท่ากับหรือหนาแน่นกว่า 0.6 μT
- [C-1-7] ต้องรองรับการปรับเทียบออนไลน์และการชดเชยอคติจากเหล็กแข็ง และเก็บพารามิเตอร์การชดเชยไว้ระหว่างรีบูตอุปกรณ์
- [C-1-8] ต้องใช้การชดเชยเหล็กอ่อน ปรับเทียบได้ขณะใช้งานหรือขณะผลิตอุปกรณ์
- [C-1-9] ต้องมีค่าเบี่ยงเบนมาตรฐาน โดยคำนวณตามแกนต่อแกนจากตัวอย่างที่เก็บรวบรวมในช่วงระยะเวลาอย่างน้อย 3 วินาทีที่อัตราการสุ่มตัวอย่างเร็วที่สุด และไม่เกิน 1.5 μT ควรมีค่าเบี่ยงเบนมาตรฐานไม่เกิน 0.5 μT
- [C-SR] ขอแนะนำอย่างยิ่งให้ใช้เซ็นเซอร์
TYPE_MAGNETIC_FIELD_UNCALIBRATED
หากอุปกรณ์มีเครื่องวัดค่าความเข้มข้นของสนามแม่เหล็ก 3 แกน เซ็นเซอร์ตัวตรวจวัดความเร่ง และเซ็นเซอร์เครื่องวัดการหมุน 3 แกน สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-2-1] ต้องใช้เซ็นเซอร์คอมโพสิต
TYPE_ROTATION_VECTOR
หากอุปกรณ์มีเครื่องวัดค่าความเข้มข้นของสนามแม่เหล็ก 3 แกน ตัวตรวจวัดความเร่ง ระบบจะดำเนินการต่อไปนี้
- อาจใช้เซ็นเซอร์
TYPE_GEOMAGNETIC_ROTATION_VECTOR
หากอุปกรณ์มีเครื่องวัดค่าความเข้มข้นของสนามแม่เหล็ก 3 แกน ตัวตรวจวัดความเร่ง และเซ็นเซอร์ TYPE_GEOMAGNETIC_ROTATION_VECTOR
ระบบจะดำเนินการต่อไปนี้
- [C-3-1] ต้องใช้พลังงานน้อยกว่า 10 mW
- ควรสิ้นเปลืองพลังงานไม่เกิน 3 mW เมื่อลงทะเบียนเซ็นเซอร์สำหรับโหมดแบบกลุ่มที่ 10 Hz
7.3.3 GPS
การติดตั้งใช้งานอุปกรณ์
- [C-SR] ขอแนะนำอย่างยิ่งให้รวมเครื่องรับ GPS/GNSS
หากอุปกรณ์มีตัวรับสัญญาณ GPS/GNSS และรายงานความสามารถของแอปพลิเคชันผ่านแฟล็กฟีเจอร์ android.hardware.location.gps
อุปกรณ์เหล่านั้นจะมีลักษณะดังนี้
- [C-1-1] ต้องรองรับเอาต์พุตตำแหน่งในอัตราอย่างน้อย 1 Hz เมื่อขอผ่าน
LocationManager#requestLocationUpdate
- [C-1-2] ต้องสามารถระบุตำแหน่งในสภาพโล่ง (สัญญาณแรง, เส้นทางหลายทางที่ไม่มีประโยชน์, HDOP < 2) ภายใน 10 วินาที (เวลาที่รวดเร็วในการแก้ไขครั้งแรก) เมื่อเชื่อมต่อกับอินเทอร์เน็ตที่มีความเร็วอินเทอร์เน็ต 0.5 Mbps ขึ้นไป โดยทั่วไปข้อกำหนดนี้จะเป็นไปตามการใช้เทคนิค GPS/GNSS แบบมีการสนับสนุนหรือที่คาดการณ์ไว้เพื่อลดเวลาล็อกของ GPS/GNSS ให้เหลือน้อยที่สุด (ข้อมูลความช่วยเหลือประกอบด้วยเวลาอ้างอิง ตำแหน่งอ้างอิง และ Ephemeris/Clock ดาวเทียม)
- [C-1-6] หลังจากคำนวณตำแหน่งแล้ว การใช้งานอุปกรณ์ต้องกำหนดตำแหน่งอุปกรณ์ในที่โล่งภายใน 5 วินาที เมื่อรีสตาร์ทคำขอตำแหน่ง และใช้เวลาไม่เกิน 1 ชั่วโมงหลังจากการคำนวณตำแหน่งครั้งแรก แม้ว่าจะมีการส่งคำขอหลังจากนั้นโดยไม่มีการเชื่อมต่ออินเทอร์เน็ต และ/หรือหลังจากการเปิดเครื่องใหม่ก็ตาม
-
ในสภาพท้องฟ้าเปิดหลังจากระบุตำแหน่ง ขณะอยู่กับที่หรือเคลื่อนที่ด้วยความเร็วน้อยกว่า 1 เมตรต่อวินาทีของความเร่งยกกำลังสอง
- [C-1-3] ต้องสามารถระบุตำแหน่งได้ภายใน 20 เมตร และความเร็วไม่เกิน 0.5 เมตรต่อวินาที หรืออย่างน้อย 95% ของเวลาทั้งหมด
- [C-1-4] ต้องติดตามและรายงานในเวลาเดียวกันผ่าน
GnssStatus.Callback
ดาวเทียมอย่างน้อย 8 ดวงจากกลุ่มดาวเดียว - ควรจะสามารถติดตามดาวเทียมอย่างน้อย 24 ดวง จากกลุ่มดาวหลายกลุ่มดาวได้พร้อมกัน (เช่น GPS + กลอนนาส เป่ยตู กาลิเลโอ อย่างน้อยหนึ่งดาว)
- [C-SR] ขอแนะนำเป็นอย่างยิ่งให้ส่งเอาต์พุตตำแหน่ง GPS/GNSS ตามปกติผ่าน GNSS Location Provider API ในระหว่างการโทรฉุกเฉิน
- [C-SR] ขอแนะนำอย่างยิ่งให้รายงานการวัดของ GNSS จากกลุ่มดาวทั้งหมดที่ติดตาม (ดังที่รายงานในข้อความ GnssStatus) ยกเว้น SBAS
- [C-SR] แนะนําอย่างยิ่งให้รายงาน AGC และความถี่ของการวัด GNSS
- [C-SR] ขอแนะนำอย่างยิ่งให้รายงานค่าประมาณความแม่นยำทั้งหมด (รวมถึงทิศทาง ความเร็ว และแนวดิ่ง) เป็นส่วนหนึ่งของตำแหน่ง GPS/GNSS แต่ละตำแหน่ง
- [C-SR] ขอแนะนำอย่างยิ่งให้รายงานการวัด GNSS ทันทีที่พบ แม้ว่าจะไม่มีการรายงานตำแหน่งที่คำนวณจาก GPS/GNSS ก็ตาม
- [C-SR] ขอแนะนำเป็นอย่างยิ่งให้รายงานช่วง Pseudoranges และอัตราเทียมของ 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] แนะนําอย่างยิ่งให้สามารถรายงานการวัดความดันในช่วง 300 hPa ถึง 1100 hPa
- ควรมีความแม่นยำสัมบูรณ์ที่ 1hPa
- ควรมีความแม่นยำสัมพัทธ์ที่ 0.12hPa ในช่วง 20hPa (เทียบเท่ากับ ความแม่นยำประมาณ 1m มากกว่า ~200m การเปลี่ยนแปลงที่ระดับน้ำทะเล)
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
ซึ่ง- ต้องมีช่วงการวัดระหว่าง -8 ก. ถึง +8 ก. เป็นอย่างน้อย และเราขอแนะนำอย่างยิ่งให้มีช่วงการวัดระหว่าง -16 ก. ถึง +16 ก. เป็นอย่างน้อย
- ต้องมีความละเอียดในการวัดอย่างน้อย 2048 LSB/g
- ต้องมีความถี่การวัดขั้นต่ำที่ 12.5 Hz หรือต่ำกว่า
- ต้องมีความถี่ในการวัดสูงสุด 400 Hz หรือสูงกว่า ควรรองรับ SensorDirectChannel
RATE_VERY_FAST
- ต้องมีสัญญาณรบกวนวัดที่ไม่สูงกว่า 400 μg/ทั้งหมดใน{/9}
- ต้องใช้รูปแบบที่ไม่ใช่การปลุกระบบของเซ็นเซอร์นี้ที่มีความสามารถในการบัฟเฟอร์อย่างน้อย 3,000 เหตุการณ์เซ็นเซอร์
- ต้องใช้พลังงานแบบกลุ่มไม่เกิน 3 mW
- [C-SR] ขอแนะนำอย่างยิ่งให้ใช้แบนด์วิดท์การวัดค่า 3dB อย่างน้อย 80% ของความถี่ Nyquist และสเปกตรัมไวท์นอยส์ภายในแบนด์วิดท์นี้
- ควรทดสอบการเร่งความเร็วแบบสุ่มน้อยกว่า 30 μg ¡Hz ทดสอบที่อุณหภูมิห้อง
- ควรมีการเปลี่ยนแปลงอคติเมื่อเทียบกับอุณหภูมิ ≤ +/- 1 มก./°C
- ควรมีระดับความไม่เป็นเชิงเส้นที่พอดีที่สุด ≤ 0.5% และการเปลี่ยนแปลงความไวต่ออุณหภูมิสูงสุด ≤ 0.03%/C°
- ควรมีความไวข้ามแกนของ < 2.5 % และความไวข้ามแกนที่แปรปรวน < 0.2% ในช่วงอุณหภูมิการทำงานของอุปกรณ์
-
[C-2-2] ต้องมี
TYPE_ACCELEROMETER_UNCALIBRATED
ที่มีข้อกำหนดด้านคุณภาพเหมือนกับTYPE_ACCELEROMETER
-
[C-2-3] ต้องมีเซ็นเซอร์
TYPE_GYROSCOPE
ซึ่ง- ต้องมีช่วงการวัดระหว่าง -1,000 ถึง +1,000 dps เป็นอย่างน้อย
- ต้องมีความละเอียดในการวัดอย่างน้อย 16 LSB/dps
- ต้องมีความถี่การวัดขั้นต่ำที่ 12.5 Hz หรือต่ำกว่า
- ต้องมีความถี่ในการวัดสูงสุด 400 Hz หรือสูงกว่า ควรรองรับ SensorDirectChannel
RATE_VERY_FAST
- ต้องมีสัญญาณรบกวนการวัดที่ไม่สูงเกิน 0.014°/s/Hz
- [C-SR] ขอแนะนำอย่างยิ่งให้ใช้แบนด์วิดท์การวัดค่า 3dB อย่างน้อย 80% ของความถี่ Nyquist และสเปกตรัมไวท์นอยส์ภายในแบนด์วิดท์นี้
- ควรมีอัตราการเดินแบบสุ่มน้อยกว่า 0.001 °/s CMP อัตราการเดินที่ทดสอบที่อุณหภูมิห้อง
- ควรมีการเปลี่ยนแปลงอคติเมื่อเทียบกับอุณหภูมิ ≤ +/- 0.05 °/ s / °C
- ควรมีการเปลี่ยนแปลงความไวเมื่อเทียบกับอุณหภูมิ ≤ 0.02% / °C
- ควรมีเส้นตรงที่ไม่เป็นเส้นตรงที่สุด ≤ 0.2%
- ควรมีความหนาแน่นของสัญญาณเสียง ≤ 0.007 °/s/เครื่องหมาย {/9}C
- ควรมีข้อผิดพลาดในการปรับเทียบน้อยกว่า 0.002 เรเดียน/วินาที ในช่วงอุณหภูมิ 10 ~ 40 °C เมื่ออุปกรณ์อยู่กับที่
- ควรมีความไวต่อ g น้อยกว่า 0.1°/s/g
- ควรมีความไวข้ามแกนของ < 4.0 % และความแปรปรวนของความไวข้ามแกน < 0.3% ในช่วงอุณหภูมิการทำงานของอุปกรณ์
-
[C-2-4] ต้องมี
TYPE_GYROSCOPE_UNCALIBRATED
ที่มีข้อกำหนดด้านคุณภาพเหมือนกับTYPE_GYROSCOPE
-
[C-2-5] ต้องมีเซ็นเซอร์
TYPE_GEOMAGNETIC_FIELD
ซึ่ง- ต้องมีช่วงการวัดระหว่าง -900 ถึง +900 μT เป็นอย่างน้อย
- ต้องมีความละเอียดในการวัดอย่างน้อย 5 LSB/uT
- ต้องมีความถี่การวัดขั้นต่ำที่ 5 Hz หรือต่ำกว่า
- ต้องมีความถี่ในการวัดสูงสุด 50 Hz หรือสูงกว่า
- ต้องมีสัญญาณรบกวนการวัดที่ไม่มากกว่า 0.5 uT
-
[C-2-6] ต้องมี
TYPE_MAGNETIC_FIELD_UNCALIBRATED
ที่มีข้อกำหนดด้านคุณภาพเหมือนกับTYPE_GEOMAGNETIC_FIELD
และมีคุณสมบัติดังต่อไปนี้- ต้องใช้รูปแบบที่ไม่ใช่การปลุกระบบของเซ็นเซอร์นี้ที่มีความสามารถในการบัฟเฟอร์อย่างน้อย 600 เหตุการณ์เซ็นเซอร์
- [C-SR] ขอแนะนำอย่างยิ่งให้ใช้สเปกตรัมไวท์นอยส์ตั้งแต่ 1 Hz ถึงอย่างน้อย 10 Hz เมื่ออัตราการรายงานเป็น 50 Hz หรือสูงกว่า
-
[C-2-7] ต้องมีเซ็นเซอร์
TYPE_PRESSURE
ซึ่ง- ต้องมีช่วงการวัดระหว่าง 300 ถึง 1100 hPa เป็นอย่างน้อย
- ต้องมีความละเอียดในการวัดอย่างน้อย 80 LSB/hPa
- ต้องมีความถี่การวัดขั้นต่ำที่ 1 Hz หรือต่ำกว่า
- ต้องมีความถี่ในการวัดสูงสุด 10 Hz หรือสูงกว่า
- ต้องมีสัญญาณรบกวนวัดที่ไม่สูงกว่า 2 Pa/คําสั่งซื้อ
- ต้องใช้รูปแบบที่ไม่ใช่การปลุกระบบของเซ็นเซอร์นี้ที่มีความสามารถในการบัฟเฟอร์อย่างน้อย 300 เหตุการณ์เซ็นเซอร์
- ต้องมีปริมาณการใช้พลังงานแบบกลุ่มไม่เกิน 2 mW
- [C-2-8] ต้องมีเซ็นเซอร์
TYPE_GAME_ROTATION_VECTOR
- [C-2-9] ต้องมีเซ็นเซอร์
TYPE_SIGNIFICANT_MOTION
ซึ่ง- จะต้องมีการใช้พลังงานไม่แย่กว่า 0.5 mW เมื่ออุปกรณ์อยู่นิ่ง และ 1.5 mW เมื่ออุปกรณ์กำลังเคลื่อนที่
- [C-2-10] ต้องมีเซ็นเซอร์
TYPE_STEP_DETECTOR
ซึ่ง- ต้องใช้รูปแบบที่ไม่ใช่การปลุกระบบของเซ็นเซอร์นี้ที่มีความสามารถในการบัฟเฟอร์อย่างน้อย 100 เหตุการณ์เซ็นเซอร์
- จะต้องมีการใช้พลังงานไม่แย่กว่า 0.5 mW เมื่ออุปกรณ์อยู่นิ่ง และ 1.5 mW เมื่ออุปกรณ์กำลังเคลื่อนที่
- ต้องใช้พลังงานแบบกลุ่มไม่เกิน 4 mW
- [C-2-11] ต้องมีเซ็นเซอร์
TYPE_STEP_COUNTER
ซึ่ง- จะต้องมีการใช้พลังงานไม่แย่กว่า 0.5 mW เมื่ออุปกรณ์อยู่นิ่ง และ 1.5 mW เมื่ออุปกรณ์กำลังเคลื่อนที่
- [C-2-12] ต้องมีเซ็นเซอร์
TILT_DETECTOR
ซึ่ง- จะต้องมีการใช้พลังงานไม่แย่กว่า 0.5 mW เมื่ออุปกรณ์อยู่นิ่ง และ 1.5 mW เมื่ออุปกรณ์กำลังเคลื่อนที่
- [C-2-13] การประทับเวลาเหตุการณ์ของเหตุการณ์ทางกายภาพเดียวกันที่รายงานโดยตัวตรวจวัดความเร่ง เครื่องวัดการหมุน และเครื่องวัดค่าความเข้มข้นของสนามแม่เหล็กต้องอยู่ห่างจากกันไม่เกิน 2.5 มิลลิวินาที การประทับเวลาเหตุการณ์ของเหตุการณ์ทางกายภาพเดียวกันที่รายงานโดยตัวตรวจวัดความเร่งและเครื่องวัดการหมุนควรอยู่ห่างกันไม่เกิน 0.25 มิลลิวินาที
- [C-2-14] ต้องมีการประทับเวลาเหตุการณ์เซ็นเซอร์เครื่องวัดการหมุนอยู่ในเวลาเดียวกันกับระบบย่อยของกล้องและมีข้อผิดพลาดภายใน 1 มิลลิวินาที
- [C-2-15] ต้องส่งตัวอย่างไปยังแอปพลิเคชันภายใน 5 มิลลิวินาทีนับจากเวลาที่ข้อมูลพร้อมใช้งานในเซ็นเซอร์ทางกายภาพใดๆ ข้างต้นไปยังแอปพลิเคชัน
- [C-2-16] ต้องไม่มีปริมาณการใช้พลังงานสูงกว่า 0.5 mW เมื่ออุปกรณ์อยู่นิ่งและ 2.0 mW เมื่ออุปกรณ์มีการเคลื่อนไหวเมื่อเปิดใช้เซ็นเซอร์ใดๆ ต่อไปนี้ร่วมกัน
-
SENSOR_TYPE_SIGNIFICANT_MOTION
-
SENSOR_TYPE_STEP_DETECTOR
-
SENSOR_TYPE_STEP_COUNTER
-
SENSOR_TILT_DETECTORS
-
- [C-2-17] อาจมีเซ็นเซอร์
TYPE_PROXIMITY
แต่หากมี ต้องมีความสามารถในการบัฟเฟอร์ขั้นต่ำที่ 100 เหตุการณ์เซ็นเซอร์
โปรดทราบว่าข้อกำหนดด้านการใช้พลังงานทั้งหมดในส่วนนี้ไม่รวมถึงการใช้พลังงานของตัวประมวลผลแอปพลิเคชัน โดยรวมถึงกำลังไฟฟ้าที่โซ่เซ็นเซอร์ทั้งโซ่ใช้ ได้แก่ เซ็นเซอร์ วงจรสนับสนุน ระบบประมวลผลเซ็นเซอร์เฉพาะใดๆ เป็นต้น
หากการติดตั้งใช้งานอุปกรณ์มีการรองรับเซ็นเซอร์โดยตรง สิ่งที่จะเกิดขึ้นมีดังนี้
- [C-3-1] ต้องประกาศการรองรับประเภทแชแนลโดยตรงและระดับอัตราในรายงานโดยตรงอย่างถูกต้องผ่าน API ของ
isDirectChannelTypeSupported
และgetHighestDirectReportRateLevel
- [C-3-2] ต้องรองรับช่องสัญญาณโดยตรงของเซ็นเซอร์อย่างน้อย 1 จาก 2 ประเภทสำหรับเซ็นเซอร์ทั้งหมดที่ประกาศการรองรับช่องสัญญาณโดยตรงของเซ็นเซอร์
- ควรรองรับการรายงานเหตุการณ์ผ่านช่องทางโดยตรงของเซ็นเซอร์สำหรับเซ็นเซอร์หลัก (ตัวแปรที่ไม่ใช่การปลุกระบบ) ในประเภทต่อไปนี้
-
TYPE_ACCELEROMETER
-
TYPE_ACCELEROMETER_UNCALIBRATED
-
TYPE_GYROSCOPE
-
TYPE_GYROSCOPE_UNCALIBRATED
-
TYPE_MAGNETIC_FIELD
-
TYPE_MAGNETIC_FIELD_UNCALIBRATED
-
7.3.10 เซ็นเซอร์ไบโอเมตริก
หากต้องการทราบข้อมูลพื้นฐานเพิ่มเติมเกี่ยวกับการวัดความปลอดภัยในการปลดล็อกไบโอเมตริก โปรดดูเอกสารการวัดความปลอดภัยของข้อมูลไบโอเมตริก
หากการใช้งานอุปกรณ์มีหน้าจอล็อกที่ปลอดภัย สิ่งที่จะเกิดขึ้นมีดังนี้
- ควรมีเซ็นเซอร์ไบโอเมตริก
เซ็นเซอร์ไบโอเมตริกสามารถจัดประเภทเป็นคลาส 3 (เดิมชื่อรัดกุม), คลาส 2 (เดิมชื่อต่ำ) หรือคลาส 1 (เดิมเรียกว่าความสะดวกสบาย) โดยอิงตามอัตราการยอมรับที่ปลอมแปลงและปลอม รวมถึงความปลอดภัยของไปป์ไลน์ข้อมูลไบโอเมตริก การแยกประเภทนี้จะพิจารณาความสามารถที่เซ็นเซอร์ไบโอเมตริกมีในการเชื่อมต่อกับแพลตฟอร์มและกับแอปพลิเคชันของบุคคลที่สาม เซ็นเซอร์จะได้รับการจัดประเภทเป็นคลาส 1 โดยค่าเริ่มต้น และต้องปฏิบัติตามข้อกำหนดเพิ่มเติมตามรายละเอียดด้านล่างหากต้องการจัดประเภทเป็นคลาส 2 หรือคลาส 3 ข้อมูลไบโอเมตริกทั้งคลาส 2 และคลาส 3 มีความสามารถเพิ่มเติมตามรายละเอียดด้านล่าง
หากการใช้งานอุปกรณ์ทำให้เซ็นเซอร์ข้อมูลไบโอเมตริกพร้อมใช้งานสำหรับแอปพลิเคชันของบุคคลที่สามผ่าน android.hardware.biometrics.BiometricManager, android.hardware.biometrics.BiometricPrompt และ android.provider.Settings.ACTION_BIOMETRIC_ENROLL
- [C-4-1] ต้องเป็นไปตามข้อกำหนดสำหรับข้อมูลไบโอเมตริกคลาส 3 หรือคลาส 2 ตามที่ระบุไว้ในเอกสารนี้
- [C-4-2] ต้อง