1. ข้อมูลเบื้องต้น
เอกสารนี้จะระบุข้อกำหนดที่อุปกรณ์ต้องปฏิบัติตามเพื่อให้ใช้งานร่วมกับ Android 12 ได้
การใช้คําว่า "ต้อง" "ต้องไม่" "ต้องระบุ" "ต้อง" "ต้องไม่" "ควร" "ไม่ควร" "แนะนํา" "อาจ" และ "ไม่บังคับ" เป็นไปตามมาตรฐาน IETF ที่ระบุไว้ใน RFC2119
"ผู้ติดตั้งใช้งานอุปกรณ์" หรือ "ผู้ติดตั้งใช้งาน" ตามที่ใช้ในเอกสารนี้หมายถึงบุคคลหรือองค์กรที่พัฒนาโซลูชันฮาร์ดแวร์/ซอฟต์แวร์ที่ใช้ Android 12 "การติดตั้งใช้งานอุปกรณ์" หรือ "การติดตั้งใช้งาน" คือโซลูชันฮาร์ดแวร์/ซอฟต์แวร์ที่พัฒนาขึ้น
การติดตั้งใช้งานอุปกรณ์ต้องเป็นไปตามข้อกำหนดที่ระบุไว้ในคำจำกัดความของความเข้ากันได้นี้ รวมถึงเอกสารที่รวมไว้ผ่านการอ้างอิง จึงจะถือว่าเข้ากันได้กับ Android 12
ในกรณีที่คำจำกัดความนี้หรือการทดสอบซอฟต์แวร์ที่อธิบายไว้ในส่วนที่ 10 ไม่ได้กล่าวถึง ไม่ชัดเจน หรือไม่สมบูรณ์ ผู้ติดตั้งใช้งานอุปกรณ์มีหน้าที่รับผิดชอบในการตรวจสอบความเข้ากันได้กับการติดตั้งใช้งานที่มีอยู่
ด้วยเหตุนี้ โครงการโอเพนซอร์ส Android จึงถือเป็นทั้งข้อมูลอ้างอิงและการใช้งาน Android ที่แนะนำ เราขอแนะนำอย่างยิ่งให้ผู้ติดตั้งใช้งานอุปกรณ์อิงตามการติดตั้งใช้งานซอร์สโค้ด "ต้นทาง" ให้ได้มากที่สุดจากโปรเจ็กต์โอเพนซอร์ส Android แม้ว่าในทางทฤษฎีแล้ว คอมโพเนนต์บางรายการอาจแทนที่ด้วยการติดตั้งใช้งานทางเลือกได้ แต่เราขอแนะนำอย่างยิ่งว่าอย่าทำเช่นนั้น เนื่องจากจะทำให้การทดสอบซอฟต์แวร์ผ่านเกณฑ์ได้ยากขึ้นอย่างมาก ผู้ติดตั้งใช้งานมีหน้าที่รับผิดชอบในการตรวจสอบความเข้ากันได้ของลักษณะการทำงานอย่างเต็มรูปแบบกับการติดตั้งใช้งาน Android มาตรฐาน ซึ่งรวมถึงและนอกเหนือจากชุดเครื่องมือทดสอบความเข้ากันได้ สุดท้าย โปรดทราบว่าเอกสารนี้ห้ามไม่ให้ใช้ชิ้นส่วนทดแทนและการแก้ไขบางอย่างอย่างชัดเจน
แหล่งข้อมูลที่ลิงก์ในเอกสารนี้ส่วนใหญ่มาจาก Android SDK โดยตรงหรือโดยอ้อม และจะทํางานเหมือนกับข้อมูลในเอกสารประกอบของ SDK นั้น ในกรณีที่คำจำกัดความความเข้ากันได้นี้หรือชุดเครื่องมือทดสอบความเข้ากันได้ขัดแย้งกับเอกสารประกอบ SDK ระบบจะถือว่าเอกสารประกอบ SDK ถูกต้อง รายละเอียดทางเทคนิคที่ระบุไว้ในแหล่งข้อมูลที่ลิงก์ตลอดทั้งเอกสารนี้ถือว่าเป็นส่วนหนึ่งของคำจำกัดความความเข้ากันได้นี้
1.1 โครงสร้างเอกสาร
1.1.1. ข้อกำหนดตามประเภทอุปกรณ์
ส่วนที่ 2 มีข้อกำหนดทั้งหมดที่ใช้กับอุปกรณ์ประเภทหนึ่งๆ ส่วนย่อยแต่ละส่วนในส่วนที่ 2 จะใช้สำหรับอุปกรณ์ประเภทหนึ่งๆ โดยเฉพาะ
ข้อกำหนดอื่นๆ ทั้งหมดที่ใช้กับการติดตั้งใช้งานอุปกรณ์ Android ทุกรุ่นจะแสดงอยู่ในส่วนหลังส่วนที่ 2 ข้อกำหนดเหล่านี้จะเรียกว่า "ข้อกำหนดหลัก" ในเอกสารนี้
1.1.2. รหัสข้อกำหนด
รหัสข้อกำหนดจะกำหนดไว้สำหรับข้อกำหนดที่ต้องปฏิบัติตาม
- ระบบจะกำหนดรหัสสำหรับข้อกำหนดที่ต้องปฏิบัติตามเท่านั้น
- ข้อกำหนดที่ "แนะนำอย่างยิ่ง" จะมีเครื่องหมายเป็น [SR] แต่จะไม่มีการกำหนดรหัส
- รหัสประกอบด้วย รหัสประเภทอุปกรณ์ - รหัสเงื่อนไข - รหัสข้อกำหนด (เช่น C-0-1)
รหัสแต่ละรายการมีคำจำกัดความดังนี้
- รหัสประเภทอุปกรณ์ (ดูข้อมูลเพิ่มเติมใน2. ประเภทอุปกรณ์)
- ค: หลัก (ข้อกำหนดที่ใช้กับการติดตั้งใช้งานอุปกรณ์ Android ทั้งหมด)
- H: อุปกรณ์พกพา Android
- T: อุปกรณ์ Android TV
- ตอบ: การติดตั้งใช้งาน Android Automotive
- W: การติดตั้งใช้งาน Android Watch
- แท็บ: การติดตั้งใช้งานแท็บเล็ต Android
- รหัสเงื่อนไข
- เมื่อข้อกำหนดเป็นแบบไม่มีเงื่อนไข ระบบจะตั้งค่ารหัสนี้เป็น 0
- เมื่อข้อกำหนดเป็นแบบมีเงื่อนไข ระบบจะกำหนดค่า 1 สำหรับเงื่อนไขที่ 1 และเพิ่มค่า 1 ภายในส่วนเดียวกันและประเภทอุปกรณ์เดียวกัน
- รหัสข้อกำหนด
- รหัสนี้จะเริ่มต้นที่ 1 และเพิ่มขึ้นทีละ 1 ภายในส่วนเดียวกันและเงื่อนไขเดียวกัน
1.1.3. รหัสข้อกำหนดในส่วนที่ 2
รหัสข้อกำหนดในส่วนที่ 2 มี 2 ส่วน รายการแรกตรงกับรหัสส่วนตามที่อธิบายไว้ข้างต้น ส่วนที่ 2 จะระบุรูปแบบของอุปกรณ์และข้อกำหนดเฉพาะของรูปแบบของอุปกรณ์
รหัสส่วนตามด้วยรหัสข้อกำหนดที่อธิบายไว้ข้างต้น
- รหัสในส่วนที่ 2 ประกอบด้วย รหัสส่วน / รหัสประเภทอุปกรณ์ - รหัสเงื่อนไข - รหัสข้อกำหนด (เช่น 7.4.3/A-0-1)
2. ประเภทอุปกรณ์
โครงการโอเพนซอร์ส Android มีสแต็กซอฟต์แวร์ที่ใช้ได้กับอุปกรณ์ประเภทต่างๆ และรูปแบบของอุปกรณ์ที่หลากหลาย กองซ้อนซอฟต์แวร์ ซึ่งรวมถึงระบบปฏิบัติการที่ใช้แทนหรือการติดตั้งใช้งานเคอร์เนลอื่น ควรทำงานในสภาพแวดล้อมที่ปลอดภัยตามที่อธิบายไว้ในส่วนที่ 9 และส่วนอื่นๆ ภายใน CDD นี้ เพื่อรองรับความปลอดภัยในอุปกรณ์ มีอุปกรณ์บางประเภทที่มีระบบนิเวศการจัดจำหน่ายแอปพลิเคชันซึ่งค่อนข้างได้รับการยอมรับมากกว่า
ส่วนนี้จะอธิบายประเภทอุปกรณ์เหล่านั้น รวมถึงข้อกำหนดและคำแนะนำเพิ่มเติมที่ใช้ได้กับอุปกรณ์แต่ละประเภท
การติดตั้งใช้งานอุปกรณ์ Android ทั้งหมดที่ไม่ตรงกับประเภทอุปกรณ์ที่อธิบายไว้ต้องเป็นไปตามข้อกำหนดทั้งหมดในส่วนอื่นๆ ของคำจำกัดความความเข้ากันได้นี้
2.1 การกําหนดค่าอุปกรณ์
ดูความแตกต่างที่สำคัญในการกำหนดค่าฮาร์ดแวร์ตามประเภทอุปกรณ์ได้ที่ข้อกำหนดเฉพาะอุปกรณ์ที่แสดงในส่วนนี้
2.2 ข้อกำหนดสำหรับอุปกรณ์แบบพกพา
อุปกรณ์มือถือ Android หมายถึงการใช้งานอุปกรณ์ Android ที่มักใช้โดยถือไว้ในมือ เช่น เครื่องเล่น MP3, โทรศัพท์ หรือแท็บเล็ต
การติดตั้งใช้งานอุปกรณ์ Android จะจัดอยู่ในประเภทอุปกรณ์พกพาหากเป็นไปตามเกณฑ์ต่อไปนี้ทั้งหมด
- มีแหล่งจ่ายไฟที่ให้ความคล่องตัว เช่น แบตเตอรี่
- มีขนาดหน้าจอแนวทแยงจริงในช่วง 3.3 นิ้ว (หรือ 2.5 นิ้วสําหรับการติดตั้งใช้งานอุปกรณ์ที่มาพร้อมกับ API ระดับ 29 หรือต่ำกว่า) ถึง 8 นิ้ว
ข้อกำหนดเพิ่มเติมในส่วนที่เหลือของส่วนนี้เกี่ยวข้องกับการติดตั้งใช้งานบนอุปกรณ์ Android แบบพกพาโดยเฉพาะ
2.2.1. ฮาร์ดแวร์
การติดตั้งใช้งานในอุปกรณ์แบบพกพา
- [7.1.1.1/H-0-1] ต้องมีจอแสดงผลที่เข้ากันได้กับ Android อย่างน้อย 1 จอที่เป็นไปตามข้อกำหนดทั้งหมดที่อธิบายไว้ในเอกสารนี้
[7.1.1.3/H-SR-1] ขอแนะนำอย่างยิ่งให้ผู้ใช้สามารถเปลี่ยนขนาดการแสดงผล (ความหนาแน่นของหน้าจอ) ได้
[7.1.1.1/H-0-2] ต้องรองรับการคอมโพสิชัน GPU ของบัฟเฟอร์กราฟิกที่มีขนาดใหญ่อย่างน้อยเท่ากับความละเอียดสูงสุดของจอแสดงผลในตัว
หากการติดตั้งใช้งานอุปกรณ์แบบใช้มือถือรองรับการหมุนหน้าจอด้วยซอฟต์แวร์ อุปกรณ์ดังกล่าวจะมีลักษณะดังนี้
- [7.1.1.1/H-1-1]* ต้องทำให้หน้าจอเชิงตรรกะที่มีให้สำหรับแอปพลิเคชันของบุคคลที่สามมีขนาดอย่างน้อย 2 นิ้วที่ขอบด้านสั้นและ 2.7 นิ้วที่ขอบด้านยาว อุปกรณ์ที่มาพร้อมกับ Android API ระดับ 29 หรือต่ำกว่าอาจได้รับการยกเว้นจากข้อกำหนดนี้
หากการติดตั้งใช้งานอุปกรณ์แบบใช้มือถือไม่รองรับการหมุนหน้าจอด้วยซอฟต์แวร์ อุปกรณ์จะมีลักษณะดังนี้
- [7.1.1.1/H-2-1]* หน้าจอเชิงตรรกะที่มีให้ใช้งานสำหรับแอปพลิเคชันของบุคคลที่สามต้องมีขนาดอย่างน้อย 2.7 นิ้วที่ขอบด้านสั้น อุปกรณ์ที่มาพร้อมกับ Android API ระดับ 29 หรือต่ำกว่าอาจได้รับการยกเว้นจากข้อกำหนดนี้
หากการติดตั้งใช้งานอุปกรณ์แบบใช้มือถืออ้างว่ารองรับจอแสดงผลแบบ High Dynamic Range ผ่าน Configuration.isScreenHdr()
อุปกรณ์ดังกล่าวจะต้องมีคุณสมบัติดังนี้
- [7.1.4.5/H-1-1] ต้องโฆษณาการรองรับส่วนขยาย
EGL_EXT_gl_colorspace_bt2020_pq
,EGL_EXT_surface_SMPTE2086_metadata
,EGL_EXT_surface_CTA861_3_metadata
,VK_EXT_swapchain_colorspace
และVK_EXT_hdr_metadata
การติดตั้งใช้งานในอุปกรณ์แบบพกพา
- [7.1.4.6/H-0-1] ต้องรายงานว่าอุปกรณ์รองรับความสามารถในการสร้างโปรไฟล์ GPU หรือไม่ผ่านพร็อพเพอร์ตี้ของระบบ
graphics.gpu.profiler.support
หากการติดตั้งใช้งานอุปกรณ์แบบใช้มือถือประกาศการรองรับผ่านพร็อพเพอร์ตี้ของระบบ
graphics.gpu.profiler.support
การดำเนินการต่อไปนี้จะเกิดขึ้น
- [7.1.4.6/H-1-1] ต้องรายงานเป็นเอาต์พุตการติดตาม protobuf ที่เป็นไปตามสคีมาของตัวนับ GPU และสถานะการแสดงผลของ GPU ที่ระบุไว้ในเอกสารประกอบของ Perfetto
- [7.1.4.6/H-1-2] ต้องรายงานค่าที่เป็นไปตามข้อกำหนดสำหรับเคาน์เตอร์ GPU ของอุปกรณ์ตามโปรโตคอลการติดตามแพ็กเก็ตเคาน์เตอร์ GPU
- [7.1.4.6/H-1-3] ต้องรายงานค่าที่เป็นไปตามข้อกำหนดสำหรับ GPU RenderStages ของอุปกรณ์ตามโปรโตคอลการติดตามแพ็กเก็ตระยะการแสดงผล
- [7.1.4.6/H-1-4] ต้องรายงานความถี่ของ GPU แทร็กพอยต์ตามที่ระบุโดยรูปแบบ power/gpu_frequency
การติดตั้งใช้งานในอุปกรณ์แบบพกพา
- [7.1.5/H-0-1] ต้องรองรับโหมดความเข้ากันได้ของแอปรุ่นเดิมตามที่โค้ดโอเพนซอร์สของ Android ต้นทางนำมาใช้ กล่าวคือ การติดตั้งใช้งานอุปกรณ์ต้องไม่เปลี่ยนแปลงทริกเกอร์หรือเกณฑ์ที่เปิดใช้งานโหมดความเข้ากันได้ และต้องไม่เปลี่ยนแปลงลักษณะการทํางานของโหมดความเข้ากันได้
- [7.2.1/H-0-1] ต้องรองรับแอปพลิเคชันตัวแก้ไขวิธีการป้อนข้อมูล (IME) ของบุคคลที่สาม
- [7.2.3/H-0-3] ต้องมีฟังก์ชันหน้าแรกในจอแสดงผลทั้งหมดที่เข้ากันได้กับ Android ซึ่งมีหน้าจอหลัก
- [7.2.3/H-0-4] ต้องมีฟังก์ชัน "กลับ" บนจอแสดงผลที่เข้ากันได้กับ Android ทั้งหมด และฟังก์ชัน "ล่าสุด" บนจอแสดงผลที่เข้ากันได้กับ Android อย่างน้อย 1 จอ
- [7.2.3/H-0-2] ต้องส่งทั้งเหตุการณ์การกดแป้น Back (
KEYCODE_BACK
) แบบปกติและแบบกดค้างไว้ไปยังแอปพลิเคชันที่ทำงานอยู่เบื้องหน้า ระบบต้องไม่ใช้เหตุการณ์เหล่านี้ และสามารถทริกเกอร์จากภายนอกอุปกรณ์ Android ได้ (เช่น ฮาร์ดแวร์ภายนอกหรือแป้นพิมพ์ที่เชื่อมต่อกับอุปกรณ์ Android) - [7.2.4/H-0-1] ต้องรองรับอินพุตหน้าจอสัมผัส
- [7.2.4/H-SR-1] ขอแนะนำอย่างยิ่งให้เปิดแอปผู้ช่วยที่ผู้ใช้เลือก กล่าวคือแอปที่ใช้ VoiceInteractionService หรือกิจกรรมที่จัดการ
ACTION_ASSIST
เมื่อกดKEYCODE_MEDIA_PLAY_PAUSE
หรือKEYCODE_HEADSETHOOK
ค้างไว้ หากกิจกรรมที่ทำงานอยู่เบื้องหน้าไม่ได้จัดการเหตุการณ์การกดค้างไว้เหล่านั้น - [7.3.1/H-SR-1] ขอแนะนำอย่างยิ่งให้ใส่ตัววัดความเร่งแบบ 3 แกน
หากการติดตั้งใช้งานอุปกรณ์พกพามีตัววัดความเร่งแบบ 3 แกน อุปกรณ์จะมีลักษณะดังนี้
- [7.3.1/H-1-1] ต้องรายงานเหตุการณ์ได้สูงสุดที่ความถี่อย่างน้อย 100 Hz
หากการติดตั้งใช้งานอุปกรณ์มือถือมีเครื่องรับ GPS/GNSS และรายงานความสามารถไปยังแอปพลิเคชันผ่าน Flag ฟีเจอร์ android.hardware.location.gps
อุปกรณ์ดังกล่าวจะมีลักษณะดังนี้
- [7.3.3/H-2-1] ต้องรายงานการวัด GNSS ทันทีที่พบ แม้ว่าจะยังไม่ได้รายงานตำแหน่งที่คำนวณจาก GPS/GNSS
- [7.3.3/H-2-2] ต้องรายงานอัตราความแม่นยำของตำแหน่งเสมือนและอัตราความแม่นยำของตำแหน่งเสมือนของ GNSS ซึ่งเพียงพอที่จะคำนวณตำแหน่งภายใน 20 เมตรและความเร็วภายใน 0.2 เมตรต่อวินาทีภายใต้สภาพท้องฟ้าเปิดหลังจากระบุตำแหน่งแล้ว ขณะหยุดนิ่งหรือเคลื่อนที่ด้วยความเร่งน้อยกว่า 0.2 เมตรต่อวินาทียกกำลัง 2 อย่างน้อย 95% ของเวลา
หากการติดตั้งใช้งานอุปกรณ์มือถือมีไจโรสโคป 3 แกน อุปกรณ์จะมีลักษณะดังนี้
- [7.3.4/H-3-1] ต้องรายงานเหตุการณ์ได้สูงสุดที่ความถี่อย่างน้อย 100 Hz
- [7.3.4/H-3-2] ต้องสามารถวัดการเปลี่ยนแปลงการวางแนวได้สูงสุด 1,000 องศาต่อวินาที
การติดตั้งใช้งานอุปกรณ์มือถือที่โทรออกด้วยเสียงได้และระบุค่าอื่นที่ไม่ใช่ PHONE_TYPE_NONE
ใน getPhoneType
- [7.3.8/H] ควรมีเซ็นเซอร์ตรวจหาบุคคลในบริเวณ
การติดตั้งใช้งานในอุปกรณ์แบบพกพา
- [7.3.11/H-SR-1] แนะนำให้รองรับเซ็นเซอร์ท่าทางที่มีอิสระ 6 องศา
- [7.4.3/H] ควรรองรับบลูทูธและบลูทูธ LE
หากการติดตั้งใช้งานอุปกรณ์แบบใช้มือถือมีอุปกรณ์กล้องแบบตรรกะที่แสดงรายการความสามารถโดยใช้ CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA
อุปกรณ์เหล่านั้นจะมีลักษณะดังนี้
- [7.5.4/H-1-1] ต้องมีขอบเขตการมองเห็น (FOV) ปกติโดยค่าเริ่มต้น และจะต้องอยู่ในช่วง 50 ถึง 95 องศา
การติดตั้งใช้งานในอุปกรณ์แบบพกพา
- [7.6.1/H-0-1] ต้องมีพื้นที่เก็บข้อมูลแบบคงที่อย่างน้อย 4 GB สำหรับเก็บข้อมูลส่วนตัวของแอปพลิเคชัน (หรือที่เรียกว่าพาร์ติชัน "/data")
- [7.6.1/H-0-2] ต้องแสดงผลเป็น "จริง" สำหรับ
ActivityManager.isLowRamDevice()
เมื่อหน่วยความจำที่ใช้ได้สำหรับเคอร์เนลและพื้นที่ผู้ใช้น้อยกว่า 1 GB
หากการติดตั้งใช้งานอุปกรณ์พกพาประกาศว่ารองรับ ABI 32 บิตเท่านั้น ให้ทำดังนี้
[7.6.1/H-1-1] หน่วยความจำที่ใช้ได้กับเคอร์เนลและพื้นที่ผู้ใช้ต้องมีขนาดอย่างน้อย 416 MB หากจอแสดงผลเริ่มต้นใช้ความละเอียดเฟรมบัฟเฟอร์สูงสุด qHD (เช่น FWVGA)
[7.6.1/H-2-1] หน่วยความจำที่ใช้ได้กับเคอร์เนลและพื้นที่ผู้ใช้ต้องมีขนาดอย่างน้อย 592 MB หากจอแสดงผลเริ่มต้นใช้ความละเอียดของเฟรมบัฟเฟอร์สูงสุด HD+ (เช่น HD, WSVGA)
[7.6.1/H-3-1] หน่วยความจำที่ใช้ได้กับเคอร์เนลและพื้นที่ผู้ใช้ต้องมีขนาดอย่างน้อย 896 MB หากจอแสดงผลเริ่มต้นใช้ความละเอียดของเฟรมบัฟเฟอร์สูงสุด FHD (เช่น WSXGA+)
[7.6.1/H-4-1] หน่วยความจำที่ใช้ได้กับเคอร์เนลและพื้นที่ผู้ใช้ต้องมีขนาดอย่างน้อย 1344 MB หากจอแสดงผลเริ่มต้นใช้ความละเอียดของเฟรมบัฟเฟอร์สูงสุด QHD (เช่น QWXGA)
หากการติดตั้งใช้งานอุปกรณ์แบบใช้มือถือประกาศการรองรับ ABI 64 บิต (มีหรือไม่มี ABI 32 บิตก็ตาม) ให้ทำดังนี้
[7.6.1/H-5-1] หน่วยความจำที่ใช้ได้กับเคอร์เนลและพื้นที่ผู้ใช้ต้องมีขนาดอย่างน้อย 816 MB หากจอแสดงผลเริ่มต้นใช้ความละเอียดเฟรมบัฟเฟอร์สูงสุดถึง qHD (เช่น FWVGA)
[7.6.1/H-6-1] หน่วยความจำที่ใช้ได้กับเคอร์เนลและพื้นที่ผู้ใช้ต้องมีอย่างน้อย 944 MB หากจอแสดงผลเริ่มต้นใช้ความละเอียดของเฟรมบัฟเฟอร์สูงสุด HD+ (เช่น HD, WSVGA)
[7.6.1/H-7-1] หน่วยความจำที่ใช้ได้กับเคอร์เนลและพื้นที่ผู้ใช้ต้องมีขนาดอย่างน้อย 1280 MB หากจอแสดงผลเริ่มต้นใช้ความละเอียดของเฟรมบัฟเฟอร์สูงสุด FHD (เช่น WSXGA+)
[7.6.1/H-8-1] หน่วยความจำที่ใช้ได้กับเคอร์เนลและพื้นที่ผู้ใช้ต้องมีขนาดอย่างน้อย 1824 MB หากจอแสดงผลเริ่มต้นใช้ความละเอียดของเฟรมบัฟเฟอร์สูงสุด QHD (เช่น QWXGA)
โปรดทราบว่า "หน่วยความจำที่พร้อมใช้งานสำหรับเคอร์เนลและพื้นที่ผู้ใช้" ด้านบนหมายถึงพื้นที่หน่วยความจำที่ให้มาเพิ่มเติมจากหน่วยความจำที่กําหนดไว้สําหรับคอมโพเนนต์ฮาร์ดแวร์ เช่น วิทยุ วิดีโอ และอื่นๆ อยู่แล้ว ซึ่งไม่อยู่ภายใต้การควบคุมของเคิร์นัลในการใช้งานอุปกรณ์
หากการติดตั้งใช้งานอุปกรณ์พกพามีหน่วยความจำน้อยกว่าหรือเท่ากับ 1 GB ที่พร้อมใช้งานสำหรับเคอร์เนลและพื้นที่ผู้ใช้ อุปกรณ์จะมีลักษณะดังนี้
- [7.6.1/H-9-1] ต้องประกาศ Flag ฟีเจอร์
android.hardware.ram.low
- [7.6.1/H-9-2] ต้องมีพื้นที่เก็บข้อมูลแบบไม่ผันผวนอย่างน้อย 1.1 GB สำหรับข้อมูลส่วนตัวของแอปพลิเคชัน (หรือที่เรียกว่าพาร์ติชัน "/data")
หากการติดตั้งใช้งานอุปกรณ์แบบใช้มือถือมีหน่วยความจํามากกว่า 1 GB ที่พร้อมใช้งานสําหรับเคอร์เนลและพื้นที่ผู้ใช้ อุปกรณ์ดังกล่าวจะมีลักษณะดังนี้
- [7.6.1/H-10-1] ต้องมีพื้นที่เก็บข้อมูลแบบคงที่อย่างน้อย 4 GB สำหรับข้อมูลส่วนตัวของแอปพลิเคชัน (หรือที่เรียกว่าพาร์ติชัน "/data")
- ควรประกาศ Flag ฟีเจอร์
android.hardware.ram.normal
หากการติดตั้งใช้งานอุปกรณ์แบบพกพามีหน่วยความจํามากกว่าหรือเท่ากับ 2 GB และน้อยกว่า 4 GB ที่พร้อมใช้งานสําหรับเคอร์เนลและพื้นที่ผู้ใช้ อุปกรณ์ดังกล่าวจะมีลักษณะดังนี้
- [7.6.1/H-SR-1] ขอแนะนำอย่างยิ่งให้รองรับเฉพาะพื้นที่ผู้ใช้ 32 บิต (ทั้งแอปและโค้ดระบบ)
หากการติดตั้งใช้งานอุปกรณ์แบบพกพามีหน่วยความจำน้อยกว่า 2 GB ที่ใช้กับเคอร์เนลและพื้นที่ผู้ใช้ได้ อุปกรณ์จะมีลักษณะดังนี้
- [7.6.1/H-1-1] ต้องรองรับ ABI เพียงรายการเดียว (64 บิตเท่านั้นหรือ 32 บิตเท่านั้น)
การติดตั้งใช้งานในอุปกรณ์แบบพกพา
- [7.6.2/H-0-1] ต้องไม่ให้พื้นที่เก็บข้อมูลที่ใช้ร่วมกันของแอปพลิเคชันน้อยกว่า 1 GiB
- [7.7.1/H] ควรมีพอร์ต USB ที่รองรับโหมดอุปกรณ์ต่อพ่วง
หากการติดตั้งใช้งานอุปกรณ์พกพามีพอร์ต USB ที่รองรับโหมดอุปกรณ์ต่อพ่วง อุปกรณ์ดังกล่าวจะมีลักษณะดังนี้
- [7.7.1/H-1-1] ต้องติดตั้งใช้งาน Android Open Accessory (AOA) API
หากการติดตั้งใช้งานอุปกรณ์พกพามีพอร์ต USB ที่รองรับโหมดโฮสต์ อุปกรณ์ดังกล่าวจะมีลักษณะดังนี้
- [7.7.2/H-1-1] ต้องใช้คลาสเสียง USB ตามเอกสารประกอบของ Android SDK
การติดตั้งใช้งานในอุปกรณ์แบบพกพา
- [7.8.1/H-0-1] ต้องมีไมโครโฟน
- [7.8.2/H-0-1] ต้องมีเอาต์พุตเสียงและประกาศ
android.hardware.audio.output
หากการติดตั้งใช้งานอุปกรณ์แบบใช้มือถือสามารถปฏิบัติตามข้อกำหนดด้านประสิทธิภาพทั้งหมดเพื่อรองรับโหมด VR และรองรับโหมดดังกล่าว อุปกรณ์ดังกล่าวจะมีคุณสมบัติดังนี้
- [7.9.1/H-1-1] ต้องประกาศตัวแปรทางการตลาดสำหรับฟีเจอร์
android.hardware.vr.high_performance
- [7.9.1/H-1-2] ต้องมีแอปพลิเคชันที่ใช้
android.service.vr.VrListenerService
ซึ่งแอปพลิเคชัน VR เปิดใช้ได้ผ่านandroid.app.Activity#setVrModeEnabled
หากการติดตั้งใช้งานอุปกรณ์แบบใช้มือถือมีพอร์ต USB-C อย่างน้อย 1 พอร์ตในโหมดโฮสต์และใช้ (คลาสเสียง USB) นอกเหนือจากข้อกำหนดในส่วนที่ 7.7.2 อุปกรณ์ดังกล่าวต้องมีคุณสมบัติดังนี้
- [7.8.2.2/H-1-1] ต้องระบุการแมปซอฟต์แวร์ต่อไปนี้สำหรับรหัส HID
การทำงาน | การแมป | บริบท | ลักษณะการทำงาน |
---|---|---|---|
ก | หน้าการใช้งาน HID: 0x0C การใช้งาน HID: 0x0CD คีย์เคอร์เนล: KEY_PLAYPAUSE คีย์ Android: KEYCODE_MEDIA_PLAY_PAUSE |
การเล่นสื่อ | อินพุต: กดสั้นๆ เอาต์พุต: เล่นหรือหยุดชั่วคราว |
อินพุต: กดค้าง เอาต์พุต: เปิดคำสั่งเสียง ส่ง: android.speech.action.VOICE_SEARCH_HANDS_FREE หากอุปกรณ์ล็อกอยู่หรือหน้าจอปิดอยู่ ส่งandroid.speech.RecognizerIntent.ACTION_WEB_SEARCH |
|||
สายเรียกเข้า | อินพุต: กดสั้นๆ เอาต์พุต: ยอมรับสายเรียกเข้า |
||
อินพุต: กด ค้างไว้ เอาต์พุต: ปฏิเสธสายเรียกเข้า |
|||
สายที่สนทนาอยู่ | อินพุต: กดสั้นๆ เอาต์พุต: วางสาย |
||
อินพุต: กด ค้างไว้ เอาต์พุต: ปิดหรือเปิดเสียงไมโครโฟน |
|||
B | หน้าการใช้งาน HID: 0x0C การใช้งาน HID: 0x0E9 คีย์เคอร์เนล: KEY_VOLUMEUP คีย์ Android: VOLUME_UP |
การเล่นสื่อ สายที่โทรอยู่ | อินพุต: กดสั้นๆ หรือกดค้าง เอาต์พุต: เพิ่มระดับเสียงของระบบหรือหูฟัง |
C | หน้าการใช้งาน HID: 0x0C การใช้งาน HID: 0x0EA คีย์เคอร์เนล: KEY_VOLUMEDOWN คีย์ Android: VOLUME_DOWN |
การเล่นสื่อ สายที่โทรอยู่ | อินพุต: กดสั้นๆ หรือกดค้าง เอาต์พุต: ลดระดับเสียงของระบบหรือหูฟัง |
D | หน้าการใช้งาน HID: 0x0C การใช้งาน HID: 0x0CF คีย์เคอร์เนล: KEY_VOICECOMMAND คีย์ Android: KEYCODE_VOICE_ASSIST |
ทั้งหมด ทริกเกอร์ได้ในอินสแตนซ์ใดก็ได้ | อินพุต: กดสั้นๆ หรือกดค้าง เอาต์พุต: เปิดคำสั่งเสียง |
- [7.8.2.2/H-1-2] ต้องทริกเกอร์ ACTION_HEADSET_PLUG เมื่อเสียบปลั๊ก แต่ต้องหลังจากที่อินเทอร์เฟซเสียงและปลายทาง USB ได้รับการระบุอย่างถูกต้องแล้วเพื่อระบุประเภทของขั้วต่อที่เชื่อมต่อ
เมื่อตรวจพบขั้วต่อเสียง USB ประเภท 0x0302 ระบบจะดำเนินการดังนี้
- [7.8.2.2/H-2-1] ต้องออกอากาศ Intent ACTION_HEADSET_PLUG โดยตั้งค่าข้อมูลเพิ่มเติม "microphone" เป็น 0
เมื่อตรวจพบขั้วต่อเสียง USB ประเภท 0x0402 ระบบจะดำเนินการต่อไปนี้
- [7.8.2.2/H-3-1] ต้องออกอากาศ Intent ACTION_HEADSET_PLUG โดยตั้งค่าเพิ่มเติม "microphone" เป็น 1
เมื่อเรียก API AudioManager.getDevices() ขณะที่อุปกรณ์ต่อพ่วง USB เชื่อมต่ออยู่ ระบบจะดำเนินการดังนี้
[7.8.2.2/H-4-1] ต้องระบุอุปกรณ์ประเภท AudioDeviceInfo.TYPE_USB_HEADSET และบทบาท isSink() หากช่องประเภทขั้วต่อเสียง USB เป็น 0x0302
[7.8.2.2/H-4-2] ต้องแสดงรายการอุปกรณ์ประเภท AudioDeviceInfo.TYPE_USB_HEADSET และบทบาท isSink() หากช่องประเภทขั้วต่อเสียง USB เป็น 0x0402
[7.8.2.2/H-4-3] ต้องแสดงรายการอุปกรณ์ประเภท AudioDeviceInfo.TYPE_USB_HEADSET และบทบาท isSource() หากช่องประเภทขั้วต่อเสียง USB เป็น 0x0402
[7.8.2.2/H-4-4] ต้องแสดงรายการอุปกรณ์ประเภท AudioDeviceInfo.TYPE_USB_DEVICE และบทบาท isSink() หากช่องประเภทขั้วต่อเสียง USB เป็น 0x603
[7.8.2.2/H-4-5] ต้องแสดงรายการอุปกรณ์ประเภท AudioDeviceInfo.TYPE_USB_DEVICE และบทบาท isSource() หากช่องประเภทขั้วต่อเสียง USB เป็น 0x604
[7.8.2.2/H-4-6] ต้องแสดงรายการอุปกรณ์ประเภท AudioDeviceInfo.TYPE_USB_DEVICE และบทบาท isSink() หากช่องประเภทขั้วต่อเสียง USB เป็น 0x400
[7.8.2.2/H-4-7] ต้องแสดงรายการอุปกรณ์ประเภท AudioDeviceInfo.TYPE_USB_DEVICE และบทบาท isSource() หากช่องประเภทขั้วต่อเสียง USB เป็น 0x400
[7.8.2.2/H-SR-1] ขอแนะนำอย่างยิ่งเมื่อเชื่อมต่ออุปกรณ์ต่อพ่วงเสียง USB-C ให้ดำเนินการแจกแจงตัวระบุ USB, ระบุประเภทขั้วต่อ และออกอากาศ Intent ACTION_HEADSET_PLUG ในเวลาน้อยกว่า 1, 000 มิลลิวินาที
หากการติดตั้งใช้งานอุปกรณ์มือถือประกาศ android.hardware.audio.output
และ
android.hardware.microphone
อุปกรณ์จะมีลักษณะดังนี้
- [5.6(#56_audio-latency)/H-1-1] ต้องมีเวลาในการตอบสนองไป-กลับแบบต่อเนื่องโดยเฉลี่ยไม่เกิน 800 มิลลิวินาทีในการวัด 5 ครั้ง โดยมีค่าความเบี่ยงเบนสัมบูรณ์โดยเฉลี่ยน้อยกว่า 100 มิลลิวินาทีในเส้นทางที่รองรับอย่างน้อย 1 เส้นทาง
หากการติดตั้งใช้งานอุปกรณ์แบบใช้มือถือมีตัวกระตุ้นการสัมผัสอย่างน้อย 1 ตัว อุปกรณ์จะต้องมีคุณสมบัติดังนี้
- [7.10/H]* ไม่ควรใช้มวลหมุนแบบเยื้องศูนย์ (ERM) ตัวกระตุ้นการสัมผัส (เครื่องสั่น)
- [7.10/H]* ควรวางตัวกระตุ้นไว้ใกล้กับตำแหน่งที่ผู้ใช้มักจะจับหรือสัมผัสอุปกรณ์ด้วยมือ
- [7.10/H]* ควรใช้ค่าคงที่สาธารณะทั้งหมดสําหรับการสัมผัสที่ชัดเจนใน android.view.HapticFeedbackConstants ซึ่งได้แก่ (CLOCK_TICK, CONTEXT_CLICK, KEYBOARD_PRESS, KEYBOARD_RELEASE, KEYBOARD_TAP, LONG_PRESS, TEXT_HANDLE_MOVE, VIRTUAL_KEY, VIRTUAL_KEY_RELEASE, CONFIRM, REJECT, GESTURE_START และ GESTURE_END)
- [7.10/H]* ควรใช้ค่าคงที่สาธารณะทั้งหมดสําหรับการสัมผัสที่ชัดเจนใน android.os.VibrationEffect นั่นคือ (EFFECT_TICK, EFFECT_CLICK, EFFECT_HEAVY_CLICK และ EFFECT_DOUBLE_CLICK) และค่าคงที่สาธารณะทั้งหมดสําหรับการสัมผัสที่หลากหลายใน android.os.VibrationEffect.Composition นั่นคือ (PRIMITIVE_CLICK และ PRIMITIVE_TICK)
- [7.10/H]* ควรใช้การแมปเหล่านี้สำหรับค่าคงที่ของการสัมผัสที่ลิงก์ไว้
- [7.10/H]* ควรปฏิบัติตามการประเมินคุณภาพสำหรับ
createOneShot()
และcreateWaveform()
API - [7.10/H]* ควรยืนยันความสามารถของการปรับขนาดความกว้างของพัลส์โดยเรียกใช้
android.os.Vibrator.hasAmplitudeControl()
ตัวกระตุ้นแบบเรโซแนนซ์เชิงเส้น (LRA) คือระบบสปริงมวลเดียวที่มีความถี่เรโซแนนซ์หลักซึ่งมวลจะแปลเป็นทิศทางของการเคลื่อนไหวที่ต้องการ
หากการติดตั้งใช้งานอุปกรณ์แบบใช้มือถือมีตัวกระตุ้นแบบเรโซแนนซ์เชิงเส้นอย่างน้อย 1 ตัว อุปกรณ์ดังกล่าวจะมีลักษณะดังนี้
- [7.10/H]* ควรย้ายตัวกระตุ้นการสัมผัสในแกน X ของการวางแนวแนวตั้ง
หากการติดตั้งใช้งานอุปกรณ์แบบใช้มือถือมีตัวกระตุ้นการสัมผัสซึ่งเป็นตัวกระตุ้นแบบเรโซแนนซ์เชิงเส้น (LRA) ในแนวแกน X อุปกรณ์จะมีลักษณะดังนี้
- [7.10/H]* ควรมีความถี่เรโซแนนซ์ของ LRA ในแนวแกน X ต่ำกว่า 200 Hz
หากการใช้งานอุปกรณ์แบบใช้มือถือเป็นไปตามการแมปค่าคงที่ของการสัมผัส อุปกรณ์จะมีลักษณะดังนี้
- [7.10/H]* ควรยืนยันสถานะการติดตั้งใช้งานโดยเรียกใช้ API ของ android.os.Vibrator.areAllEffectsSupported() และ android.os.Vibrator.arePrimitvesSupported()
- [7.10/H]* ควรทำการประเมินคุณภาพสำหรับค่าคงที่ของการสัมผัส
- [7.10/H]* ควรให้การสนับสนุนทางเลือกเพื่อลดความเสี่ยงที่จะเกิดความผิดพลาดตามที่อธิบายไว้ที่นี่
2.2.2. มัลติมีเดีย
การติดตั้งใช้งานอุปกรณ์พกพาต้องรองรับรูปแบบการเข้ารหัสและการถอดรหัสเสียงต่อไปนี้ และทำให้แอปพลิเคชันของบุคคลที่สามใช้งานได้
- [5.1/H-0-1] AMR-NB
- [5.1/H-0-2] AMR-WB
- [5.1/H-0-3] โปรไฟล์ MPEG-4 AAC (AAC LC)
- [5.1/H-0-4] โปรไฟล์ MPEG-4 HE AAC (AAC+)
- [5.1/H-0-5] AAC ELD (AAC แบบลดเวลาหน่วงที่ปรับปรุงแล้ว)
การติดตั้งใช้งานอุปกรณ์พกพาต้องรองรับรูปแบบการเข้ารหัสวิดีโอต่อไปนี้และทำให้แอปพลิเคชันของบุคคลที่สามใช้งานได้
การติดตั้งใช้งานในอุปกรณ์พกพาต้องรองรับรูปแบบการถอดรหัสวิดีโอต่อไปนี้และทำให้แอปพลิเคชันของบุคคลที่สามใช้งานได้
2.2.3. ซอฟต์แวร์
การติดตั้งใช้งานในอุปกรณ์แบบพกพา
- [3.2.3.1/H-0-1] ต้องมีแอปพลิเคชันที่จัดการ Intent
ACTION_GET_CONTENT
,ACTION_OPEN_DOCUMENT
,ACTION_OPEN_DOCUMENT_TREE
และACTION_CREATE_DOCUMENT
ตามที่อธิบายไว้ในเอกสาร SDK และให้ความสามารถแก่ผู้ใช้ในการเข้าถึงข้อมูลของผู้ให้บริการเอกสารโดยใช้DocumentsProvider
API - [3.2.3.1/H-0-2]* ต้องโหลดแอปพลิเคชันหรือคอมโพเนนต์บริการอย่างน้อย 1 รายการล่วงหน้าด้วยตัวแฮนเดิล Intent สำหรับรูปแบบตัวกรอง Intent สาธารณะทั้งหมดที่กําหนดโดย Intent ของแอปพลิเคชันต่อไปนี้ที่แสดงไว้ที่นี่
- [3.2.3.1/H-SR-1] ขอแนะนำอย่างยิ่งให้โหลดแอปพลิเคชันอีเมลล่วงหน้าซึ่งสามารถจัดการความตั้งใจที่จะส่งอีเมลผ่าน ACTION_SENDTO หรือ ACTION_SEND หรือ ACTION_SEND_MULTIPLE
- [3.4.1/H-0-1] ต้องใช้งาน
android.webkit.Webview
API อย่างสมบูรณ์ - [3.4.2/H-0-1] ต้องมีแอปพลิเคชันเบราว์เซอร์สแตนด์อโลนสำหรับการท่องเว็บของผู้ใช้ทั่วไป
- [3.8.1/H-SR-1] ขอแนะนำอย่างยิ่งให้ใช้ Launcher เริ่มต้นที่รองรับการปักหมุดทางลัด วิดเจ็ต และ widgetFeatures ในแอป
- [3.8.1/H-SR-2] ขอแนะนำอย่างยิ่งให้ใช้ตัวเปิดแอปเริ่มต้นที่ให้สิทธิ์เข้าถึงทางลัดเพิ่มเติมได้อย่างรวดเร็ว ซึ่งแอปของบุคคลที่สามมีให้ผ่าน ShortcutManager API
- [3.8.1/H-SR-3] ขอแนะนำอย่างยิ่งให้ใส่แอป Launcher เริ่มต้นที่แสดงป้ายสำหรับไอคอนแอป
- [3.8.2/H-SR-1] ขอแนะนำอย่างยิ่งให้รองรับวิดเจ็ตแอปของบุคคลที่สาม
- [3.8.3/H-0-1] ต้องอนุญาตให้แอปของบุคคลที่สามแจ้งผู้ใช้เกี่ยวกับเหตุการณ์สำคัญผ่านคลาส API ของ
Notification
และNotificationManager
- [3.8.3/H-0-2] ต้องรองรับการแจ้งเตือนแบบริชมีเดีย
- [3.8.3/H-0-3] ต้องรองรับการแจ้งเตือนแบบแจ้งเตือน
- [3.8.3/H-0-4] ต้องมีแถบการแจ้งเตือนเพื่อให้ผู้ใช้ควบคุมการแจ้งเตือนได้โดยตรง (เช่น ตอบ เลื่อนการปลุก ปิด บล็อก) ผ่านสิ่งที่ผู้ใช้สามารถโต้ตอบได้ เช่น ปุ่มดำเนินการหรือแผงควบคุมตามที่ติดตั้งใช้งานใน AOSP
- [3.8.3/H-0-5] ต้องแสดงตัวเลือกที่ระบุผ่าน
RemoteInput.Builder setChoices()
ในหน้าต่างแจ้งเตือน - [3.8.3/H-SR-1] ขอแนะนำอย่างยิ่งให้แสดงตัวเลือกแรกที่มีให้ผ่าน
RemoteInput.Builder setChoices()
ในหน้าต่างแจ้งเตือนโดยไม่ต้องมีการโต้ตอบเพิ่มเติมจากผู้ใช้ - [3.8.3/H-SR-2] ขอแนะนำอย่างยิ่งให้แสดงตัวเลือกทั้งหมดที่ระบุผ่าน
RemoteInput.Builder setChoices()
ในหน้าต่างแจ้งเตือนเมื่อผู้ใช้ขยายการแจ้งเตือนทั้งหมดในหน้าต่างแจ้งเตือน - [3.8.3.1/H-SR-1] ขอแนะนําอย่างยิ่งให้แสดงการดําเนินการที่มีการตั้งค่า
Notification.Action.Builder.setContextual
เป็นtrue
สอดคล้องกับคําตอบที่แสดงโดยNotification.Remoteinput.Builder.setChoices
- [3.8.4/H-SR-1] ขอแนะนำอย่างยิ่งให้ใช้ผู้ช่วยในอุปกรณ์เพื่อจัดการการดำเนินการ Assist
หากการติดตั้งใช้งานอุปกรณ์แบบใช้มือถือรองรับการดำเนินการ Assist อุปกรณ์จะมีลักษณะดังนี้
- [3.8.4/H-SR-2] ขอแนะนำอย่างยิ่งให้ใช้การกดแป้น
HOME
ค้างไว้เป็นการโต้ตอบที่กำหนดเพื่อเปิดแอปผู้ช่วยตามที่อธิบายไว้ในส่วนที่ 7.2.3 ต้องเปิดแอปความช่วยเหลือที่ผู้ใช้เลือก กล่าวคือแอปที่ใช้VoiceInteractionService
หรือกิจกรรมที่จัดการ IntentACTION_ASSIST
หากการติดตั้งใช้งานอุปกรณ์มือถือรองรับ conversation notifications
และจัดกลุ่มเป็นส่วนแยกต่างหากจากการแจ้งเตือนแบบแจ้งเตือนและการแจ้งเตือนแบบไม่มีเสียงที่ไม่ใช่การสนทนา อุปกรณ์มือถือจะดำเนินการดังนี้
- [3.8.4/H-1-1]* ต้องแสดงการแจ้งเตือนการสนทนาก่อนการแจ้งเตือนที่ไม่ใช่การสนทนา ยกเว้นการแจ้งเตือนบริการที่ทำงานอยู่เบื้องหน้าและการแจ้งเตือนimportance:high
หากการใช้งานอุปกรณ์ Android แบบใช้มือถือรองรับหน้าจอล็อก อุปกรณ์จะมีลักษณะดังนี้
- [3.8.10/H-1-1] ต้องแสดงการแจ้งเตือนบนหน้าจอล็อก รวมถึงเทมเพลตการแจ้งเตือนด้วยสื่อ
หากการติดตั้งใช้งานอุปกรณ์แบบใช้มือถือรองรับหน้าจอล็อกที่ปลอดภัย อุปกรณ์ดังกล่าวจะมีลักษณะดังนี้
- [3.9/H-1-1] ต้องปฏิบัติตามนโยบายการดูแลระบบอุปกรณ์ทั้งหมดที่ระบุไว้ในเอกสารประกอบของ Android SDK
หากการติดตั้งใช้งานอุปกรณ์แบบใช้มือถือรองรับ API ของ ControlsProviderService
และ Control
และอนุญาตให้แอปพลิเคชันของบุคคลที่สามเผยแพร่การควบคุมอุปกรณ์ อุปกรณ์ดังกล่าวจะต้องมีคุณสมบัติดังนี้
- [3.8.16/H-1-1] ต้องประกาศ Flag
android.software.controls
ของฟีเจอร์ และตั้งค่าเป็นtrue
- [3.8.16/H-1-2] ต้องให้ผู้ใช้สามารถเพิ่ม แก้ไข เลือก และใช้งานการควบคุมอุปกรณ์ที่ชื่นชอบจากการควบคุมที่แอปพลิเคชันของบุคคลที่สามลงทะเบียนไว้ผ่าน
ControlsProviderService
และControl
API - [3.8.16/H-1-3] ต้องให้สิทธิ์เข้าถึงการอำนวยความสะดวกนี้แก่ผู้ใช้ภายใน 3 การโต้ตอบจาก Launcher เริ่มต้น
- [3.8.16/H-1-4] ต้องแสดงผลชื่อและไอคอนของแอปของบุคคลที่สามแต่ละแอปที่ให้บริการควบคุมผ่าน
ControlsProviderService
API รวมถึงช่องที่ระบุซึ่งControl
API ระบุไว้อย่างถูกต้องในการแสดงผลที่ผู้ใช้เห็น
ในทางกลับกัน หากการติดตั้งใช้งานอุปกรณ์พกพาไม่ได้ใช้การควบคุมดังกล่าว ระบบจะดำเนินการดังนี้
- [3.8.16/H-2-1] ต้องรายงาน
null
สำหรับControlsProviderService
และControl
API - [3.8.16/H-2-2] ต้องประกาศ Flag
android.software.controls
ของฟีเจอร์ และตั้งค่าเป็นfalse
การติดตั้งใช้งานในอุปกรณ์แบบพกพา
- [3.10/H-0-1] ต้องรองรับบริการการช่วยเหลือพิเศษของบุคคลที่สาม
- [3.10/H-SR-1] ขอแนะนำอย่างยิ่ง-1 ให้โหลดบริการการช่วยเหลือพิเศษล่วงหน้าในอุปกรณ์ที่เทียบเท่ากับหรือมีประสิทธิภาพมากกว่าบริการการช่วยเหลือพิเศษของการเข้าถึงด้วยสวิตช์และ TalkBack (สำหรับภาษาที่รองรับโดยเครื่องมือการอ่านออกเสียงข้อความที่ติดตั้งไว้ล่วงหน้า) ตามที่ระบุไว้ในโปรเจ็กต์โอเพนซอร์สของ Talkback
- [3.11/H-0-1] ต้องรองรับการติดตั้งเครื่องมือ TTS ของบุคคลที่สาม
- [3.11/H-SR-1] ขอแนะนำอย่างยิ่งให้ใส่โปรแกรม TTS ที่รองรับภาษาที่มีในอุปกรณ์
- [3.13/H-SR-1] ขอแนะนำอย่างยิ่งให้ใส่คอมโพเนนต์ UI การตั้งค่าด่วน
หากการติดตั้งใช้งานอุปกรณ์พกพา Android ประกาศว่ารองรับ FEATURE_BLUETOOTH
หรือ FEATURE_WIFI
อุปกรณ์ดังกล่าวจะมีลักษณะดังนี้
- [3.16/H-1-1] ต้องรองรับฟีเจอร์การจับคู่อุปกรณ์เสริม
หากฟังก์ชันการนําทางมีให้ใช้งานเป็นการกระทําบนหน้าจอโดยอิงตามท่าทางสัมผัส ให้ทําดังนี้
- [7.2.3/H] โซนการจดจำท่าทางสัมผัสสำหรับฟังก์ชัน Home ควรมีความสูงไม่เกิน 32 dp จากด้านล่างของหน้าจอ
หากการติดตั้งใช้งานอุปกรณ์แบบใช้มือถือมีฟังก์ชันการไปยังส่วนต่างๆ เป็นท่าทางสัมผัสจากทุกที่บนขอบด้านซ้ายและขวาของหน้าจอ ให้ทำดังนี้
- [7.2.3/H-0-1] พื้นที่ท่าทางสัมผัสของฟังก์ชันการนำทางต้องมีความกว้างไม่เกิน 40 dp ในแต่ละด้าน พื้นที่ท่าทางสัมผัสควรมีความกว้าง 24 dp โดยค่าเริ่มต้น
หากการติดตั้งใช้งานอุปกรณ์แบบพกพารองรับหน้าจอล็อกที่ปลอดภัยและมีหน่วยความจำมากกว่าหรือเท่ากับ 2 GB สำหรับเคอร์เนลและพื้นที่ผู้ใช้ อุปกรณ์ดังกล่าวจะทำสิ่งต่อไปนี้ได้
- [3.9/H-1-2] ต้องประกาศการรองรับโปรไฟล์ที่จัดการผ่าน
android.software.managed_users
ฟีเจอร์ Flag
หากการติดตั้งใช้งานอุปกรณ์มือถือ Android ประกาศรองรับกล้องผ่าน android.hardware.camera.any
อุปกรณ์ดังกล่าวจะต้องมีคุณสมบัติดังนี้
- [7.5.4/H-1-1] ต้องปฏิบัติตาม Intent ของ
android.media.action.STILL_IMAGE_CAMERA
และandroid.media.action.STILL_IMAGE_CAMERA_SECURE
และเปิดกล้องในโหมดภาพนิ่งตามที่อธิบายไว้ใน SDK - [7.5.4/H-1-2] ต้องปฏิบัติตาม
android.media.action.VIDEO_CAMERA
ความตั้งใจที่จะเปิดกล้องในโหมดวิดีโอตามที่อธิบายไว้ใน SDK
2.2.4. ประสิทธิภาพและกำลังไฟ
- [8.1/H-0-1] เวลาในการตอบสนองของเฟรมที่สอดคล้องกัน เวลาในการตอบสนองของเฟรมที่ไม่สอดคล้องกันหรือการเลื่อนเวลาแสดงผลเฟรมต้องไม่เกิดขึ้นบ่อยกว่า 5 เฟรมใน 1 วินาที และควรน้อยกว่า 1 เฟรมใน 1 วินาที
- [8.1/H-0-2] เวลาในการตอบสนองของอินเทอร์เฟซผู้ใช้ การติดตั้งใช้งานอุปกรณ์ต้องช่วยให้ผู้ใช้ได้รับประสบการณ์การใช้งานที่เวลาในการตอบสนองต่ำโดยการเลื่อนรายการรายการ 10,000 รายการตามที่ชุดเครื่องมือทดสอบความเข้ากันได้ของ Android (CTS) กำหนดภายในเวลาไม่ถึง 36 วินาที
- [8.1/H-0-3] การสลับงาน เมื่อเปิดแอปพลิเคชันหลายรายการแล้ว การเปิดตัวแอปพลิเคชันที่ทำงานอยู่แล้วอีกครั้งหลังจากเปิดตัวแล้วต้องใช้เวลาไม่ถึง 1 วินาที
การติดตั้งใช้งานในอุปกรณ์แบบพกพา
- [8.2/H-0-1] ต้องมีประสิทธิภาพการเขียนแบบตามลำดับอย่างน้อย 5 MB/วินาที
- [8.2/H-0-2] ต้องมีประสิทธิภาพการเขียนแบบสุ่มอย่างน้อย 0.5 MB/s
- [8.2/H-0-3] ประสิทธิภาพการอ่านแบบตามลำดับต้องอย่างน้อย 15 MB/วินาที
- [8.2/H-0-4] ต้องมีประสิทธิภาพการอ่านแบบสุ่มอย่างน้อย 3.5 MB/s
หากการใช้งานอุปกรณ์แบบพกพามีฟีเจอร์เพื่อปรับปรุงการจัดการพลังงานของอุปกรณ์ที่รวมอยู่ใน AOSP หรือขยายฟีเจอร์ที่รวมอยู่ใน AOSP อุปกรณ์ดังกล่าวต้องมีคุณสมบัติดังนี้
- [8.3/H-1-1] ต้องให้ผู้ใช้เปิดใช้และปิดใช้ฟีเจอร์ประหยัดแบตเตอรี่ได้
- [8.3/H-1-2] ต้องให้ทางเลือกแก่ผู้ใช้ในการแสดงแอปทั้งหมดที่ได้รับการยกเว้นจากโหมดประหยัดพลังงานของโหมดแอปรอและโหมดสลีป
การติดตั้งใช้งานในอุปกรณ์แบบพกพา
- [8.4/H-0-1] ต้องมีโปรไฟล์พลังงานต่อคอมโพเนนต์ที่กำหนดค่าการบริโภคปัจจุบันสำหรับคอมโพเนนต์ฮาร์ดแวร์แต่ละรายการและการสิ้นเปลืองแบตเตอรี่โดยประมาณที่เกิดจากคอมโพเนนต์เมื่อเวลาผ่านไปตามที่ระบุไว้ในเว็บไซต์โปรเจ็กต์โอเพนซอร์ส Android
- [8.4/H-0-2] ต้องรายงานค่าการสิ้นเปลืองพลังงานทั้งหมดเป็นมิลลิแอมแปร์ชั่วโมง (mAh)
- [8.4/H-0-3] ต้องรายงานการใช้พลังงานของ CPU ตาม UID ของแต่ละกระบวนการ โครงการโอเพนซอร์ส Android เป็นไปตามข้อกำหนดผ่านการใช้งานโมดูลเคอร์เนล
uid_cputime
- [8.4/H-0-4] ต้องทำให้นักพัฒนาแอปสามารถดูปริมาณการใช้พลังงานนี้ได้ผ่านคำสั่งเชลล์
adb shell dumpsys batterystats
- [8.4/H] ควรระบุแหล่งที่มาเป็นคอมโพเนนต์ฮาร์ดแวร์เอง หากไม่สามารถระบุแหล่งที่มาเป็นการใช้พลังงานของคอมโพเนนต์ฮาร์ดแวร์ในแอปพลิเคชัน
หากการติดตั้งใช้งานอุปกรณ์แบบใช้มือถือมีเอาต์พุตหน้าจอหรือวิดีโอ อุปกรณ์ดังกล่าวต้องมีลักษณะดังนี้
- [8.4/H-1-1] ต้องปฏิบัติตามความตั้งใจของ
android.intent.action.POWER_USAGE_SUMMARY
และแสดงเมนูการตั้งค่าที่แสดงการใช้พลังงานนี้
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 เพื่อรองรับอัลกอริทึมที่ระบบ Keystore ของ Android รองรับอย่างเหมาะสมในพื้นที่ที่แยกออกจากโค้ดที่ทำงานบนเคอร์เนลและที่สูงกว่าอย่างปลอดภัย การแยกที่ปลอดภัยต้องบล็อกกลไกที่เป็นไปได้ทั้งหมดซึ่งโค้ดเคอร์เนลหรือพื้นที่ผู้ใช้อาจเข้าถึงสถานะภายในของสภาพแวดล้อมที่แยกไว้ รวมถึง DMA โปรเจ็กต์โอเพนซอร์ส Android (AOSP) ต้นทางเป็นไปตามข้อกำหนดนี้โดยใช้การติดตั้งใช้งาน Trusty แต่โซลูชันอื่นๆ ที่ใช้ ARM TrustZone หรือการติดตั้งใช้งานการแยกส่วนบนไฮเปอร์วิซอร์ที่เหมาะสมซึ่งผ่านการตรวจสอบโดยบุคคลที่สามก็เป็นตัวเลือกทางเลือกได้
- [9.11/H-0-4] ต้องทำการตรวจสอบสิทธิ์หน้าจอล็อกในสภาพแวดล้อมการเรียกใช้แบบแยกและอนุญาตให้ใช้คีย์ที่เชื่อมโยงกับการตรวจสอบสิทธิ์ก็ต่อเมื่อการตรวจสอบสิทธิ์สำเร็จเท่านั้น ข้อมูลเข้าสู่ระบบของหน้าจอล็อกต้องจัดเก็บในลักษณะที่อนุญาตให้เฉพาะสภาพแวดล้อมการเรียกใช้แบบแยกส่วนเท่านั้นที่ดำเนินการตรวจสอบสิทธิ์หน้าจอล็อกได้ โปรเจ็กต์โอเพนซอร์สของ Android เวอร์ชันอัปสตรีมมี Gatekeeper Hardware Abstraction Layer (HAL) และ Trusty ซึ่งสามารถใช้เพื่อปฏิบัติตามข้อกำหนดนี้ได้
- [9.11/H-0-5] ต้องรองรับการรับรองคีย์ในกรณีที่คีย์การลงชื่อรับรองได้รับการปกป้องโดยฮาร์ดแวร์ที่มีความปลอดภัย และการลงชื่อดำเนินการในฮาร์ดแวร์ที่มีความปลอดภัย คุณต้องแชร์คีย์การรับรองเพื่อลงนามในอุปกรณ์จํานวนมากพอเพื่อป้องกันไม่ให้มีการใช้คีย์เป็นตัวระบุอุปกรณ์ วิธีหนึ่งในการปฏิบัติตามข้อกำหนดนี้คือการแชร์คีย์การรับรองเดียวกัน เว้นแต่จะมีการผลิต SKU หนึ่งๆ อย่างน้อย 100,000 หน่วย หากผลิต SKU มากกว่า 100,000 หน่วย คุณอาจใช้คีย์อื่นสำหรับ 100,000 หน่วยแต่ละหน่วย
- [9/H-0-1] ต้องประกาศฟีเจอร์ "android.hardware.security.model.compatible"
โปรดทราบว่าหากมีการใช้งานอุปกรณ์ใน Android เวอร์ชันเก่าอยู่แล้ว อุปกรณ์ดังกล่าวจะได้รับการยกเว้นจากข้อกำหนดในการมีคีย์สโตร์ที่รองรับสภาพแวดล้อมการเรียกใช้แบบแยกและรองรับการรับรองคีย์ เว้นแต่จะมีการประกาศใช้ฟีเจอร์ android.hardware.fingerprint
ซึ่งต้องใช้คีย์สโตร์ที่รองรับสภาพแวดล้อมการเรียกใช้แบบแยก
เมื่อการติดตั้งใช้งานอุปกรณ์แบบใช้มือถือรองรับหน้าจอล็อกที่ปลอดภัย อุปกรณ์จะมีลักษณะดังนี้
- [9.11/H-1-1] ต้องอนุญาตให้ผู้ใช้เลือกระยะหมดเวลาการเข้าสู่โหมดสลีปที่สั้นที่สุด ซึ่งเป็นเวลาที่เปลี่ยนจากสถานะปลดล็อกเป็นล็อกที่ 15 วินาทีหรือน้อยกว่า
- [9.11/H-1-2] ต้องให้ผู้ใช้ซ่อนการแจ้งเตือนและปิดใช้การตรวจสอบสิทธิ์ทุกรูปแบบได้ ยกเว้นการตรวจสอบสิทธิ์หลักที่อธิบายไว้ใน9.11.1 หน้าจอล็อกที่ปลอดภัย AOSP เป็นไปตามข้อกำหนดสำหรับโหมดล็อกขณะคุมสอบ
หากการใช้งานอุปกรณ์มือถือมีผู้ใช้หลายคนและไม่ประกาศ Flag ฟีเจอร์ android.hardware.telephony
ผู้ใช้เหล่านั้นจะทำสิ่งต่อไปนี้ได้
- [9.5/H-2-1] ต้องรองรับโปรไฟล์ที่ถูกจำกัด ซึ่งเป็นฟีเจอร์ที่ช่วยให้เจ้าของอุปกรณ์จัดการผู้ใช้เพิ่มเติมและความสามารถของผู้ใช้เหล่านั้นในอุปกรณ์ได้ เมื่อใช้โปรไฟล์ที่จํากัด เจ้าของอุปกรณ์จะตั้งค่าสภาพแวดล้อมแยกต่างหากสําหรับผู้ใช้คนอื่นๆ ได้อย่างรวดเร็ว พร้อมทั้งจัดการข้อจํากัดที่ละเอียดยิ่งขึ้นในแอปที่ใช้ได้ภายในสภาพแวดล้อมเหล่านั้น
หากการติดตั้งใช้งานอุปกรณ์พกพามีผู้ใช้หลายคนและประกาศ Flag ฟีเจอร์ android.hardware.telephony
ผู้ใช้เหล่านั้นจะทำสิ่งต่อไปนี้ได้
- [9.5/H-3-1] ต้องไม่รองรับโปรไฟล์ที่จํากัด แต่ต้องสอดคล้องกับการใช้งานการควบคุมของ AOSP เพื่อเปิด /ปิดใช้ไม่ให้ผู้ใช้รายอื่นเข้าถึงการโทรด้วยเสียงและ SMS
Android ผ่าน System API VoiceInteractionService รองรับกลไกการตรวจหาคําพูดคํานิยมที่เปิดอยู่เสมออย่างปลอดภัยโดยไม่ต้องมีตัวบ่งชี้การเข้าถึงไมโครโฟน
หากการติดตั้งใช้งานอุปกรณ์แบบใช้มือถือรองรับ System API
HotwordDetectionService
หรือกลไกอื่นสำหรับการตรวจหาคําสั่งให้ดำเนินการโดยไม่มีการแสดงการเข้าถึงด้วยเสียง อุปกรณ์ดังกล่าวจะมีลักษณะดังนี้
- [9.8/H-1-1] ต้องตรวจสอบว่าบริการตรวจจับคําสั่งให้ดำเนินการสามารถส่งข้อมูลไปยังระบบหรือ ContentCaptureService เท่านั้น
- [9.8/H-1-2] ต้องตรวจสอบว่าบริการตรวจจับคําสั่งให้ดำเนินการสามารถส่งข้อมูลเสียงจากไมโครโฟนหรือข้อมูลที่มาจากไมโครโฟนไปยังเซิร์ฟเวอร์ระบบผ่าน
HotwordDetectionService
API หรือไปยังContentCaptureService
ผ่านContentCaptureManager
API เท่านั้น - [9.8/H-1-3] ต้องไม่ส่งเสียงจากไมโครโฟนที่มีความยาวเกิน 30 วินาทีสำหรับคำขอที่เรียกให้บริการตรวจจับคีย์เวิร์ดแต่ละรายการจากฮาร์ดแวร์
- [9.8/H-1-4] ต้องไม่ส่งเสียงจากไมโครโฟนที่บัฟเฟอร์ไว้นานกว่า 8 วินาทีสำหรับคำขอแต่ละรายการไปยังบริการตรวจจับคําพูดคํานิยม
- [9.8/H-1-5] ต้องไม่ส่งเสียงจากไมโครโฟนที่บัฟเฟอร์ไว้นานกว่า 30 วินาทีไปยังบริการโต้ตอบด้วยเสียงหรือนิติบุคคลที่คล้ายกัน
- [9.8/H-1-6] ต้องไม่อนุญาตให้ส่งข้อมูลมากกว่า 100 ไบต์จากบริการตรวจจับคำที่พบบ่อยสำหรับผลการค้นหาคำที่พบบ่อยแต่ละรายการที่สำเร็จ
- [9.8/H-1-7] ต้องไม่อนุญาตให้ส่งข้อมูลมากกว่า 5 บิตจากบริการตรวจจับคําพูดที่กระตุ้นให้ดำเนินการ (Hotword) ไปยังผลลัพธ์ของคําพูดที่กระตุ้นให้ดำเนินการ (Hotword) เชิงลบแต่ละรายการ
- [9.8/H-1-8] ต้องอนุญาตให้ส่งข้อมูลจากบริการตรวจจับคําสั่งให้ดำเนินการเฉพาะในคำขอตรวจสอบคําสั่งให้ดำเนินการจากเซิร์ฟเวอร์ระบบ
- [9.8/H-1-9] ต้องไม่อนุญาตให้แอปพลิเคชันที่ผู้ใช้ติดตั้งได้ให้บริการตรวจหาคําสั่งให้ดำเนินการ
- [9.8/H-1-10] ต้องไม่แสดงข้อมูลเชิงปริมาณเกี่ยวกับการใช้ไมโครโฟนโดยบริการตรวจจับคําสั่งให้ดำเนินการใน UI
- [9.8/H-1-11] ต้องบันทึกจำนวนไบต์ที่รวมอยู่ในการส่งทุกครั้งจากบริการตรวจจับคําพูดให้ตรวจสอบได้สําหรับนักวิจัยด้านความปลอดภัย
- [9.8/H-1-12] ต้องรองรับโหมดแก้ไขข้อบกพร่องที่บันทึกเนื้อหาดิบของการส่งทุกรายการจากบริการตรวจจับคําสั่งให้ดำเนินการเพื่อให้นักวิจัยด้านความปลอดภัยตรวจสอบได้
- [9.8/H-1-13] ต้องรีสตาร์ทกระบวนการโฮสต์บริการตรวจจับคําสั่งให้ดำเนินการอย่างน้อย 1 ครั้งทุกชั่วโมง หรือทุก 30 เหตุการณ์ที่ทริกเกอร์ฮาร์ดแวร์ แล้วแต่ว่าเหตุการณ์ใดจะเกิดขึ้นก่อน
- [9.8/H-1-14] ต้องแสดงตัวบ่งชี้ไมโครโฟนตามที่อธิบายไว้ในส่วนที่ 9.8.2 เมื่อส่งผลการค้นหาคีย์เวิร์ดสำเร็จไปยังบริการโต้ตอบด้วยเสียงหรือนิติบุคคลที่คล้ายกัน
- [9.8/H-SR-1] ขอแนะนำอย่างยิ่งให้แจ้งให้ผู้ใช้ทราบก่อนตั้งค่าแอปพลิเคชันเป็นผู้ให้บริการของบริการตรวจจับคําสั่งให้ดำเนินการ
- [9.8/H-SR-2] ขอแนะนำอย่างยิ่งว่าอย่าอนุญาตให้ส่งข้อมูลที่ไม่มีโครงสร้างออกจากบริการตรวจจับคําพูดที่เจาะจง
หากการติดตั้งใช้งานอุปกรณ์มีแอปพลิเคชันที่ใช้ System API
HotwordDetectionService
หรือกลไกที่คล้ายกันสำหรับการตรวจหาคําสั่งให้ดำเนินการโดยไม่มีบ่งชี้การใช้งานแบบเป็นส่วนตัว แอปพลิเคชันจะมีลักษณะดังนี้
- [9.8/H-2-1] ต้องแจ้งให้ผู้ใช้ทราบอย่างชัดเจนเกี่ยวกับวลีคำสั่งให้ดำเนินการแต่ละรายการที่รองรับ
- [9.8/H-2-2] ต้องไม่เก็บรักษาข้อมูลเสียงดิบหรือข้อมูลที่มาจากบริการดังกล่าวผ่านบริการตรวจจับคําสั่งให้ดำเนินการ
- [9.8/H-2-3] ต้องไม่ส่งจากบริการตรวจจับคําสั่งให้ดำเนินการ ข้อมูลเสียง ข้อมูลที่สามารถใช้ในการสร้างเสียงขึ้นมาใหม่ (ทั้งหมดหรือบางส่วน) หรือเนื้อหาเสียงที่ไม่เกี่ยวข้องกับคําสั่งให้ดำเนินการ ยกเว้นการส่งไปยัง
ContentCaptureService
หากการติดตั้งใช้งานอุปกรณ์พกพาประกาศ android.hardware.microphone
อุปกรณ์จะมีลักษณะดังนี้
- [9.8.2/H-4-1] ต้องแสดงตัวบ่งชี้ไมโครโฟนเมื่อแอปเข้าถึงข้อมูลเสียงจากไมโครโฟน แต่ไม่ต้องแสดงเมื่อมีเพียง
HotwordDetectionService
,SOURCE_HOTWORD
,ContentCaptureService
หรือแอปที่มีบทบาทตามที่ระบุไว้ในส่วนที่ 9.1 ที่มีตัวระบุ CDD [C-4-X] เท่านั้นที่เข้าถึงไมโครโฟน - [9.8.2/H-4-2] ต้องแสดงรายการแอปล่าสุดและแอปที่ใช้งานอยู่ซึ่งใช้ไมโครโฟนตามที่ได้จาก
PermissionManager.getIndicatorAppOpUsageData()
พร้อมกับข้อความระบุแหล่งที่มาที่เชื่อมโยงกับแอปเหล่านั้น - [9.8.2/H-4-3] ต้องไม่ซ่อนตัวบ่งชี้ไมโครโฟนสำหรับแอประบบที่มีอินเทอร์เฟซผู้ใช้ที่มองเห็นได้หรือการโต้ตอบโดยตรงกับผู้ใช้
- [9.8.2/H-4-4] ต้องแสดงรายการแอปล่าสุดและแอปที่ใช้งานอยู่โดยใช้ไมโครโฟนตามที่แสดงผลจาก
PermissionManager.getIndicatorAppOpUsageData()
พร้อมด้วยข้อความระบุแหล่งที่มาที่เชื่อมโยงกับแอปเหล่านั้น
หากการติดตั้งใช้งานอุปกรณ์พกพาประกาศ android.hardware.camera.any
อุปกรณ์จะมีลักษณะดังนี้
- [9.8.2/H-5-1] ต้องแสดงตัวบ่งชี้กล้องเมื่อแอปเข้าถึงข้อมูลกล้องสด แต่ไม่ต้องแสดงเมื่อแอปที่มีบทบาทตามที่ระบุไว้ในส่วนที่ 9.1 ที่มีตัวระบุ CDD [C-4-X] เท่านั้นที่เข้าถึงกล้อง
- [9.8.2/H-5-2] ต้องแสดงแอปล่าสุดและแอปที่ใช้งานอยู่โดยใช้กล้องตามที่แสดงผลจาก
PermissionManager.getIndicatorAppOpUsageData()
พร้อมข้อความระบุแหล่งที่มาที่เชื่อมโยงกับแอปเหล่านั้น - [9.8.2/H-5-3] ต้องไม่ซ่อนไฟสัญญาณกล้องสำหรับแอประบบที่มีอินเทอร์เฟซผู้ใช้ที่มองเห็นได้หรือการโต้ตอบโดยตรงกับผู้ใช้
2.2.6. ความเข้ากันได้ของเครื่องมือและตัวเลือกสำหรับนักพัฒนาแอป
การติดตั้งใช้งานในอุปกรณ์พกพา (* ไม่เกี่ยวข้องกับแท็บเล็ต)
- [6.1/H-0-1]* ต้องรองรับคำสั่งเชลล์
cmd testharness
การติดตั้งใช้งานในอุปกรณ์พกพา (* ไม่ใช้กับแท็บเล็ต)
- Perfetto
- [6.1/H-0-2]* ต้องแสดง
/system/bin/perfetto
ไบนารีต่อผู้ใช้เชลล์ ซึ่ง cmdline เป็นไปตามเอกสารประกอบของ Perfetto - [6.1/H-0-3]* ไฟล์ไบนารีของ Perfetto ต้องยอมรับการกำหนดค่า protobuf เป็นอินพุตที่เป็นไปตามสคีมาที่กำหนดไว้ในเอกสารประกอบของ Perfetto
- [6.1/H-0-4]* ไฟล์ไบนารีของ Perfetto ต้องเขียนร่องรอย protobuf เป็นเอาต์พุตที่เป็นไปตามสคีมาที่กำหนดไว้ในเอกสารประกอบของ Perfetto
- [6.1/H-0-5]* ต้องระบุแหล่งข้อมูลอย่างน้อยตามที่อธิบายไว้ในเอกสารประกอบของ Perfetto ผ่านไฟล์ไบนารีของ Perfetto
- [6.1/H-0-6]* ต้องมีการเปิดใช้ daemon ติดตามของ Perfetto โดยค่าเริ่มต้น (พร็อพเพอร์ตี้ของระบบ
persist.traced.enable
)
- [6.1/H-0-2]* ต้องแสดง
2.2.7. คลาสประสิทธิภาพสื่อในอุปกรณ์เคลื่อนที่
ดูคำจำกัดความของคลาสประสิทธิภาพสื่อได้ที่ส่วนที่ 7.11
2.2.7.1. สื่อ
หากการติดตั้งใช้งานอุปกรณ์มือถือแสดงผลเป็น android.os.Build.VERSION_CODES.R
สำหรับ
android.os.Build.VERSION.MEDIA_PERFORMANCE_CLASS
แสดงว่าอุปกรณ์มีลักษณะดังนี้
- ต้องเป็นไปตามข้อกำหนดด้านสื่อที่ระบุไว้ใน CDD ของ Android 11 ส่วนที่ 2.2.7.1
หากการติดตั้งใช้งานอุปกรณ์พกพาแสดงผลเป็น android.os.Build.VERSION_CODES.S
สําหรับ android.os.Build.VERSION.MEDIA_PERFORMANCE_CLASS
แสดงว่าอุปกรณ์มีลักษณะดังนี้
- [5.1/H-1-1] ต้องโฆษณาจำนวนเซสชันโปรแกรมถอดรหัสวิดีโอฮาร์ดแวร์สูงสุดที่สามารถทำงานพร้อมกันในชุดค่าผสมโค้ดใดก็ได้ผ่านวิธีการ
CodecCapabilities.getMaxSupportedInstances()
และVideoCapabilities.getSupportedPerformancePoints()
- [5.1/H-1-2] ต้องรองรับเซสชันตัวถอดรหัสวิดีโอฮาร์ดแวร์ 6 อินสแตนซ์ (AVC, HEVC, VP9* ขึ้นไป) ในชุดค่าผสมตัวแปลงรหัสใดก็ได้ที่ทำงานพร้อมกันที่ความละเอียด 720p@30 fps *ต้องใช้เพียง 2 อินสแตนซ์หากมีตัวแปลงรหัส VP9
- [5.1/H-1-3] ต้องโฆษณาจำนวนเซสชันสูงสุดของโปรแกรมเปลี่ยนไฟล์วิดีโอแบบฮาร์ดแวร์ที่สามารถทำงานพร้อมกันในชุดค่าผสมของโค้ดใดก็ได้ผ่านวิธีการ
CodecCapabilities.getMaxSupportedInstances()
และVideoCapabilities.getSupportedPerformancePoints()
- [5.1/H-1-4] ต้องรองรับเซสชันโปรแกรมเข้ารหัสวิดีโอฮาร์ดแวร์ 6 อินสแตนซ์ (AVC, HEVC, VP9* ขึ้นไป) ในชุดค่าผสมตัวแปลงรหัสใดก็ได้ที่ทำงานพร้อมกันที่ความละเอียด 720p@30fps *ต้องใช้เพียง 2 อินสแตนซ์เท่านั้นหากมีตัวแปลงรหัส VP9
- [5.1/H-1-5] ต้องโฆษณาจำนวนเซสชันสูงสุดของโปรแกรมเข้ารหัสและโปรแกรมถอดรหัสวิดีโอฮาร์ดแวร์ที่ทำงานพร้อมกันได้ในการผสมผสานโค้ดใดก็ได้ผ่านวิธีการ
CodecCapabilities.getMaxSupportedInstances()
และVideoCapabilities.getSupportedPerformancePoints()
- [5.1/H-1-6] ต้องรองรับอินสแตนซ์ตัวถอดรหัสวิดีโอฮาร์ดแวร์และเซสชันโปรแกรมเข้ารหัสวิดีโอฮาร์ดแวร์ 6 รายการ (AVC, HEVC, VP9* ขึ้นไป) ในชุดค่าผสมตัวแปลงรหัสใดก็ได้ที่ทำงานพร้อมกันที่ความละเอียด 720p@30fps *ต้องใช้เพียง 2 อินสแตนซ์หากมีตัวแปลงรหัส VP9
- [5.1/H-1-7] ต้องมีเวลาในการตอบสนองในการเริ่มต้นโค้ดไม่เกิน 50 มิลลิวินาทีสำหรับเซสชันการเข้ารหัสวิดีโอ 1080p หรือต่ำกว่าสำหรับโปรแกรมเข้ารหัสวิดีโอฮาร์ดแวร์ทั้งหมด (นอกเหนือจากโค้ด Dolby Vision) เมื่ออยู่ภายใต้ภาระงาน การโหลดในที่นี้หมายถึงเซสชันการแปลงรหัสวิดีโอเท่านั้นจาก 1080p เป็น 720p พร้อมกันโดยใช้ตัวแปลงรหัสวิดีโอฮาร์ดแวร์ควบคู่ไปกับการเตรียมการบันทึกเสียงและวิดีโอ 1080p
- [5.1/H-1-8] ต้องมีเวลาในการตอบสนองในการเริ่มต้นโค้ดของโปรแกรมเปลี่ยนไฟล์ไม่เกิน 40 มิลลิวินาทีสำหรับเซสชันการเข้ารหัสเสียงอัตราบิต 128 Kbps หรือต่ำกว่าสำหรับโปรแกรมเปลี่ยนไฟล์เสียงทั้งหมดเมื่ออยู่ภายใต้ภาระงาน การโหลดในที่นี้หมายถึงเซสชันการแปลงรหัสวิดีโอ 1080p เป็น 720p เท่านั้นที่เกิดขึ้นพร้อมกันโดยใช้ตัวแปลงรหัสวิดีโอฮาร์ดแวร์ควบคู่ไปกับการเปิดใช้งานการบันทึกเสียงและวิดีโอ 1080p
- [5.3/H-1-1] ต้องไม่มีการหยุดทำงานของเฟรมเกิน 2 เฟรมใน 10 วินาที (นั่นคือน้อยกว่า 0.333 เปอร์เซ็นต์ของการหยุดทำงานของเฟรม) สำหรับเซสชันวิดีโอ 1080p 60 fps ภายใต้ภาระงาน ภาระงานหมายถึงเซสชันการแปลงรหัสวิดีโอ 1080p เป็น 720p พร้อมกันโดยใช้ตัวแปลงรหัสวิดีโอฮาร์ดแวร์ รวมถึงการเล่นเสียง AAC 128 kbps
- [5.3/H-1-2] ต้องไม่ตัดเฟรมออกเกิน 2 เฟรมใน 10 วินาทีระหว่างที่มีการเปลี่ยนแปลงความละเอียดของวิดีโอในเซสชันวิดีโอ 60 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.MEDIA_PERFORMANCE_CLASS
แสดงว่าอุปกรณ์มีลักษณะดังนี้
- ต้องเป็นไปตามข้อกำหนดของกล้องที่ระบุไว้ใน CDD ของ Android 11 ส่วนที่ 2.2.7.2
หากการติดตั้งใช้งานอุปกรณ์พกพาแสดงผลเป็น android.os.Build.VERSION_CODES.S
สําหรับ android.os.Build.VERSION.MEDIA_PERFORMANCE_CLASS
แสดงว่าอุปกรณ์มีลักษณะดังนี้
- [7.5/H-1-1] ต้องมีกล้องหลังหลักที่มีความละเอียดอย่างน้อย 12 ล้านพิกเซล ซึ่งรองรับการบันทึกวิดีโอที่ 4K@30fps กล้องหลังหลักคือกล้องหลังที่มีรหัสกล้องต่ำที่สุด
- [7.5/H-1-2] ต้องมีกล้องหน้าหลักที่มีความละเอียดอย่างน้อย 5 ล้านพิกเซลและรองรับการบันทึกวิดีโอที่ 1080p@30fps กล้องหน้าหลักคือกล้องหน้าที่มีรหัสกล้องต่ำที่สุด
- [7.5/H-1-3] ต้องรองรับพร็อพเพอร์ตี้
android.info.supportedHardwareLevel
เป็นFULL
ขึ้นไปสำหรับกล้องหลังหลักและLIMITED
ขึ้นไปสำหรับกล้องหน้าหลัก - [7.5/H-1-4] ต้องรองรับ
CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME
สำหรับกล้องหลักทั้ง 2 ตัว - [7.5/H-1-5] ต้องมีเวลาในการตอบสนองในการจับภาพ JPEG ของ camera2 น้อยกว่า 1,000 ms สำหรับความละเอียด 1080p ตามที่วัดโดย PerformanceTest ของกล้อง CTS ภายใต้สภาพแสง ITS (3000K) สำหรับกล้องหลักทั้ง 2 ตัว
- [7.5/H-1-6] ต้องมีเวลาในการตอบสนองในการเริ่มต้นของ camera2 (เปิดกล้องเพื่อแสดงตัวอย่างเฟรมแรก) < 600 ms โดยวัดจาก PerformanceTest ของกล้อง CTS ภายใต้สภาพแสง ITS (3000K) สำหรับกล้องหลักทั้ง 2 ตัว
- [7.5/H-1-8] ต้องรองรับ
CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_RAW
และandroid.graphics.ImageFormat.RAW_SENSOR
สำหรับกล้องหลังหลัก
2.2.7.3. ฮาร์ดแวร์
หากการติดตั้งใช้งานอุปกรณ์พกพาแสดงผลเป็น android.os.Build.VERSION_CODES.R
สําหรับ android.os.Build.VERSION.MEDIA_PERFORMANCE_CLASS
แสดงว่าอุปกรณ์มีลักษณะดังนี้
- ต้องเป็นไปตามข้อกำหนดด้านฮาร์ดแวร์ที่ระบุไว้ใน CDD ของ Android 11 ส่วนที่ 2.2.7.3
หากการติดตั้งใช้งานอุปกรณ์มือถือแสดงผลเป็น android.os.Build.VERSION_CODES.S
สำหรับ
android.os.Build.VERSION.MEDIA_PERFORMANCE_CLASS
แสดงว่าอุปกรณ์มีลักษณะดังนี้
- [7.1.1.1/H-2-1] ต้องมีความละเอียดหน้าจออย่างน้อย 1080p
- [7.1.1.3/H-2-1] ต้องมีความละเอียดของหน้าจออย่างน้อย 400 dpi
- [7.6.1/H-2-1] ต้องมีหน่วยความจําจริงอย่างน้อย 6 GB
2.2.7.4. ประสิทธิภาพ
หากการติดตั้งใช้งานอุปกรณ์มือถือแสดงผลเป็น android.os.Build.VERSION_CODES.R
สำหรับ
android.os.Build.VERSION.MEDIA_PERFORMANCE_CLASS
แสดงว่าอุปกรณ์มีลักษณะดังนี้
- ต้องเป็นไปตามข้อกำหนดด้านประสิทธิภาพที่ระบุไว้ใน CDD ของ Android 11 ส่วนที่ 2.2.7.4
หากการติดตั้งใช้งานอุปกรณ์มือถือแสดงผลเป็น android.os.Build.VERSION_CODES.S
สำหรับ
android.os.Build.VERSION.MEDIA_PERFORMANCE_CLASS
แสดงว่าอุปกรณ์มีลักษณะดังนี้
- [8.2/H-2-1] ต้องมีประสิทธิภาพการเขียนแบบตามลำดับอย่างน้อย 125 MB/วินาที
- [8.2/H-2-2] ต้องมีประสิทธิภาพการเขียนแบบสุ่มอย่างน้อย 10 MB/วินาที
- [8.2/H-2-3] ต้องมีประสิทธิภาพการอ่านตามลำดับอย่างน้อย 250 MB/วินาที
- [8.2/H-2-4] ต้องตรวจสอบประสิทธิภาพการอ่านแบบสุ่มอย่างน้อย 40 MB/วินาที
2.3 ข้อกำหนดของโทรทัศน์
อุปกรณ์ทีวี Android หมายถึงการใช้งานอุปกรณ์ Android ที่เป็นอินเทอร์เฟซความบันเทิงสําหรับรับชมสื่อดิจิทัล ภาพยนตร์ เกม แอป และ/หรือทีวีสดสําหรับผู้ใช้ที่อยู่ห่างออกไปประมาณ 10 ฟุต ("Lean Back" หรือ "อินเทอร์เฟซผู้ใช้ระยะ 10 ฟุต")
การใช้งานอุปกรณ์ Android จะจัดอยู่ในประเภทโทรทัศน์หากเป็นไปตามเกณฑ์ต่อไปนี้ทั้งหมด
- มีกลไกในการควบคุมอินเทอร์เฟซผู้ใช้ที่แสดงผลจากระยะไกลบนจอแสดงผลซึ่งอาจอยู่ห่างจากผู้ใช้ 10 ฟุต
- มีจอแสดงผลแบบฝังที่มีเส้นทแยงมุมยาวกว่า 24 นิ้ว หรือมีพอร์ตเอาต์พุตวิดีโอ เช่น VGA, HDMI, DisplayPort หรือพอร์ตไร้สายสำหรับแสดงผล
ข้อกำหนดเพิ่มเติมในส่วนที่เหลือของส่วนนี้เกี่ยวข้องกับการติดตั้งใช้งานอุปกรณ์ทีวี Android โดยเฉพาะ
2.3.1. ฮาร์ดแวร์
การติดตั้งใช้งานอุปกรณ์ทีวี
- [7.2.2/T-0-1] ต้องรองรับปุ่มบังคับทิศทาง
- [7.2.3/T-0-1] ต้องมีฟังก์ชันหน้าแรกและย้อนกลับ
- [7.2.3/T-0-2] ต้องส่งทั้งเหตุการณ์การกดแป้น Back แบบปกติและแบบกดค้าง (
KEYCODE_BACK
) ไปยังแอปพลิเคชันที่ทำงานอยู่เบื้องหน้า - [7.2.6.1/T-0-1] ต้องมีการสนับสนุนตัวควบคุมเกมและประกาศ Flag ฟีเจอร์
android.hardware.gamepad
- [7.2.7/T] ควรมีรีโมตคอนโทรลที่ผู้ใช้สามารถเข้าถึงการไปยังส่วนต่างๆ โดยไม่ต้องสัมผัสและปุ่มการไปยังส่วนต่างๆ หลัก
หากการติดตั้งใช้งานอุปกรณ์ทีวีมีไจโรสโคปแบบ 3 แกน อุปกรณ์จะมีลักษณะดังนี้
- [7.3.4/T-1-1] ต้องรายงานเหตุการณ์ได้สูงสุดที่ความถี่อย่างน้อย 100 Hz
- [7.3.4/T-1-2] ต้องสามารถวัดการเปลี่ยนแปลงการวางแนวได้สูงสุด 1,000 องศาต่อวินาที
การติดตั้งใช้งานอุปกรณ์ทีวี
- [7.4.3/T-0-1] ต้องรองรับบลูทูธและบลูทูธ LE
- [7.6.1/T-0-1] ต้องมีพื้นที่เก็บข้อมูลแบบคงที่อย่างน้อย 4 GB สำหรับเก็บข้อมูลส่วนตัวของแอปพลิเคชัน (หรือที่เรียกว่าพาร์ติชัน "/data")
หากการติดตั้งใช้งานอุปกรณ์ทีวีมีพอร์ต USB ที่รองรับโหมดโฮสต์ อุปกรณ์จะมีลักษณะดังนี้
- [7.5.3/T-1-1] ต้องรองรับกล้องภายนอกที่เชื่อมต่อผ่านพอร์ต USB นี้ แต่ไม่จำเป็นต้องเชื่อมต่ออยู่เสมอ
หากการติดตั้งใช้งานอุปกรณ์ทีวีเป็น 32 บิต ให้ทำดังนี้
[7.6.1/T-1-1] หน่วยความจําที่พร้อมใช้งานสําหรับเคอร์เนลและพื้นที่ผู้ใช้ต้องมีขนาดอย่างน้อย 896 MB หากใช้ความหนาแน่นต่อไปนี้
- 400 dpi ขึ้นไปบนหน้าจอขนาดเล็ก/ปกติ
- xhdpi ขึ้นไปบนหน้าจอขนาดใหญ่
- tvdpi ขึ้นไปในหน้าจอขนาดใหญ่พิเศษ
หากการติดตั้งใช้งานอุปกรณ์ทีวีเป็นแบบ 64 บิต ให้ทำดังนี้
[7.6.1/T-2-1] หน่วยความจำที่ใช้ได้กับเคอร์เนลและพื้นที่ผู้ใช้ต้องมีขนาดอย่างน้อย 1280 MB หากใช้ความหนาแน่นต่อไปนี้
- 400 dpi ขึ้นไปบนหน้าจอขนาดเล็ก/ปกติ
- 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-1] ขอแนะนำอย่างยิ่งให้รองรับการเข้ารหัส H.264 ของวิดีโอความละเอียด 720p และ 1080p ที่ 30 เฟรมต่อวินาที
การติดตั้งใช้งานอุปกรณ์โทรทัศน์ต้องรองรับรูปแบบการถอดรหัสวิดีโอต่อไปนี้และทำให้พร้อมใช้งานสำหรับแอปพลิเคชันของบุคคลที่สาม
- [5.3.3/T-0-1] MPEG-4 SP
- [5.3.4/T-0-2] H.264 AVC
- [5.3.5/T-0-3] H.265 HEVC
- [5.3.6/T-0-4] VP8
- [5.3.7/T-0-5] VP9
- [5.3.1/T-0-6] MPEG-2
การติดตั้งใช้งานอุปกรณ์ทีวีต้องรองรับการถอดรหัส MPEG-2 ตามที่ระบุไว้อย่างละเอียดในส่วน 5.3.1 ที่อัตราเฟรมและความละเอียดวิดีโอมาตรฐานสูงสุดไม่เกิน
- [5.3.1/T-1-1] HD 1080p ที่ 29.97 เฟรมต่อวินาที ด้วยโปรไฟล์หลักระดับสูง
- [5.3.1/T-1-2] HD 1080i ที่ 59.94 เฟรมต่อวินาที ด้วยระดับ High ของโปรไฟล์หลัก โดยต้องแยกเส้นวิดีโอ MPEG-2 แบบอินเตอร์เลซออกและทำให้พร้อมใช้งานสำหรับแอปพลิเคชันของบุคคลที่สาม
การติดตั้งใช้งานอุปกรณ์ทีวีต้องรองรับการถอดรหัส H.264 ตามที่ระบุไว้ในส่วนที่ 5.3.4 ที่อัตราเฟรมและความละเอียดวิดีโอมาตรฐานสูงสุดไม่เกิน
- [5.3.4/T-1-1] HD 1080p ที่ 60 เฟรมต่อวินาทีด้วย Profile พื้นฐาน
- [5.3.4/T-1-2] HD 1080p ที่ 60 เฟรมต่อวินาทีด้วย Profile หลัก
- [5.3.4/T-1-3] HD 1080p ที่ 60 เฟรมต่อวินาทีด้วย Profile ระดับสูง 4.2
การใช้งานอุปกรณ์โทรทัศน์ที่มีตัวถอดรหัสฮาร์ดแวร์ H.265 จะต้องรองรับการถอดรหัส H.265 ตามที่ระบุไว้ในส่วนที่ 5.3.5 ที่อัตราเฟรมวิดีโอมาตรฐานและความละเอียดสูงสุดไม่เกิน
- [5.3.5/T-1-1] HD 1080p ที่ 60 เฟรมต่อวินาทีด้วย Profile หลักระดับ 4.1
หากการติดตั้งใช้งานอุปกรณ์ทีวีที่มีตัวถอดรหัสฮาร์ดแวร์ H.265 รองรับการถอดรหัส H.265 และโปรไฟล์การถอดรหัส UHD อุปกรณ์ดังกล่าวจะทำสิ่งต่อไปนี้
- [5.3.5/T-2-1] ต้องรองรับโปรไฟล์การถอดรหัส UHD ที่ 60 เฟรมต่อวินาทีด้วยโปรไฟล์ Main10 ระดับ 5 ระดับหลัก
การติดตั้งใช้งานอุปกรณ์โทรทัศน์ต้องรองรับการถอดรหัส VP8 ตามที่ระบุไว้อย่างละเอียดในส่วน 5.3.6 ที่อัตราเฟรมและความละเอียดวิดีโอมาตรฐานสูงสุดต่อไปนี้
- [5.3.6/T-1-1] โปรไฟล์การถอดรหัส HD 1080p ที่ 60 เฟรมต่อวินาที
การใช้งานอุปกรณ์โทรทัศน์ที่มีตัวถอดรหัสฮาร์ดแวร์ VP9 จะต้องรองรับการถอดรหัส VP9 ตามที่ระบุไว้ในส่วนที่ 5.3.7 ที่อัตราเฟรมและความละเอียดวิดีโอมาตรฐานสูงสุดไม่เกิน
- [5.3.7/T-1-1] HD 1080p ที่ 60 เฟรมต่อวินาทีพร้อมโปรไฟล์ 0 (ความลึกของสี 8 บิต)
หากการติดตั้งใช้งานอุปกรณ์ทีวีที่มีโปรแกรมเปลี่ยนไฟล์ฮาร์ดแวร์ VP9 รองรับการถอดรหัส VP9 และโปรไฟล์การถอดรหัส UHD อุปกรณ์เหล่านั้นจะทำสิ่งต่อไปนี้
- [5.3.7/T-2-1] ต้องรองรับโปรไฟล์การถอดรหัส UHD ที่ 60 เฟรมต่อวินาทีด้วยโปรไฟล์ 0 (ความลึกของสี 8 บิต)
- [5.3.7/T-2-1] ขอแนะนำอย่างยิ่งให้รองรับโปรไฟล์การถอดรหัส UHD ที่ 60 เฟรมต่อวินาทีด้วยโปรไฟล์ 2 (ความลึกของสี 10 บิต)
การติดตั้งใช้งานอุปกรณ์ทีวี
- [5.5/T-0-1] ต้องมีระบบที่รองรับระดับเสียงหลักของระบบและระดับเสียงที่ลดลงของเอาต์พุตเสียงดิจิทัลในเอาต์พุตที่รองรับ ยกเว้นเอาต์พุตการส่งผ่านเสียงแบบบีบอัด (ซึ่งไม่มีการถอดรหัสเสียงในอุปกรณ์)
หากการติดตั้งใช้งานอุปกรณ์ทีวีไม่มีจอแสดงผลในตัว แต่รองรับจอแสดงผลภายนอกที่เชื่อมต่อผ่าน HDMI อุปกรณ์จะมีลักษณะดังนี้
- [5.8/T-0-1] ต้องตั้งค่าโหมดเอาต์พุต HDMI เพื่อเลือกความละเอียดสูงสุดที่รองรับอัตราการรีเฟรช 50 Hz หรือ 60 Hz
- [5.8/T-SR-1] ขอแนะนำอย่างยิ่งให้ระบุตัวเลือกอัตราการรีเฟรช HDMI ที่ผู้ใช้กำหนดค่าได้
- [5.8] ควรตั้งค่าอัตราการรีเฟรชของโหมดเอาต์พุต HDMI เป็น 50 Hz หรือ 60 Hz โดยขึ้นอยู่กับอัตราการรีเฟรชวิดีโอของภูมิภาคที่จำหน่ายอุปกรณ์
หากการติดตั้งใช้งานอุปกรณ์ทีวีไม่มีจอแสดงผลในตัว แต่รองรับจอแสดงผลภายนอกที่เชื่อมต่อผ่าน HDMI อุปกรณ์จะมีลักษณะดังนี้
- [5.8/T-1-1] ต้องรองรับ HDCP 2.2
หากการติดตั้งใช้งานอุปกรณ์ทีวีไม่รองรับการถอดรหัส UHD แต่รองรับจอแสดงผลภายนอกที่เชื่อมต่อผ่าน HDMI แทน อุปกรณ์จะมีลักษณะดังนี้
- [5.8/T-2-1] ต้องรองรับ HDCP 1.4
2.3.3. ซอฟต์แวร์
การติดตั้งใช้งานอุปกรณ์ทีวี
- [3/T-0-1] ต้องประกาศฟีเจอร์
android.software.leanback
และandroid.hardware.type.television
- [3.2.3.1/T-0-1] ต้องโหลดแอปพลิเคชันหรือคอมโพเนนต์บริการอย่างน้อย 1 รายการล่วงหน้าด้วยตัวแฮนเดิล Intent สำหรับรูปแบบตัวกรอง Intent สาธารณะทั้งหมดที่กําหนดโดย Intent ของแอปพลิเคชันต่อไปนี้ที่แสดงอยู่ที่นี่
- [3.4.1/T-0-1] ต้องระบุการใช้งาน
android.webkit.Webview
API ที่สมบูรณ์
หากการติดตั้งใช้งานอุปกรณ์ Android TV รองรับหน้าจอล็อก อุปกรณ์จะมีลักษณะดังนี้
- [3.8.10/T-1-1] ต้องแสดงการแจ้งเตือนบนหน้าจอล็อก รวมถึงเทมเพลตการแจ้งเตือนด้วยสื่อ
การติดตั้งใช้งานอุปกรณ์ทีวี
- [3.8.14/T-SR-1] ขอแนะนำอย่างยิ่งให้รองรับโหมดภาพซ้อนภาพ (PIP) แบบหลายหน้าต่าง
- [3.10/T-0-1] ต้องรองรับบริการการช่วยเหลือพิเศษของบุคคลที่สาม
- [3.10/T-SR-1] ขอแนะนำอย่างยิ่งให้โหลดบริการการช่วยเหลือพิเศษล่วงหน้าในอุปกรณ์ที่เทียบเท่ากับหรือมีประสิทธิภาพมากกว่าบริการการช่วยเหลือพิเศษของการเข้าถึงด้วยสวิตช์และ TalkBack (สำหรับภาษาที่รองรับโดยเครื่องมือการอ่านออกเสียงข้อความที่ติดตั้งไว้ล่วงหน้า) ตามที่ระบุไว้ในโปรเจ็กต์โอเพนซอร์สของ TalkBack
หากการติดตั้งใช้งานอุปกรณ์ทีวีรายงานฟีเจอร์นี้
android.hardware.audio.output
อุปกรณ์จะมีลักษณะดังนี้
- [3.11/T-SR-1] ขอแนะนำอย่างยิ่งให้ใส่เครื่องมือ TTS ที่รองรับภาษาที่มีในอุปกรณ์
- [3.11/T-1-1] ต้องรองรับการติดตั้งเครื่องมือ TTS ของบุคคลที่สาม
การติดตั้งใช้งานอุปกรณ์ทีวี
- [3.12/T-0-1] ต้องรองรับเฟรมเวิร์กอินพุตทีวี
2.3.4. ประสิทธิภาพและกำลังไฟ
- [8.1/T-0-1] เวลาในการตอบสนองของเฟรมที่สอดคล้องกัน เวลาในการตอบสนองของเฟรมที่ไม่สอดคล้องกันหรือการเลื่อนเวลาแสดงผลเฟรมต้องไม่เกิดขึ้นบ่อยกว่า 5 เฟรมใน 1 วินาที และควรน้อยกว่า 1 เฟรมใน 1 วินาที
- [8.2/T-0-1] ต้องมีประสิทธิภาพการเขียนแบบตามลำดับอย่างน้อย 5 MB/วินาที
- [8.2/T-0-2] ต้องตรวจสอบประสิทธิภาพการเขียนแบบสุ่มอย่างน้อย 0.5 MB/วินาที
- [8.2/T-0-3] ต้องมีประสิทธิภาพการอ่านแบบตามลำดับอย่างน้อย 15 MB/วินาที
- [8.2/T-0-4] ต้องมีประสิทธิภาพการอ่านแบบสุ่มอย่างน้อย 3.5 MB/วินาที
หากการติดตั้งใช้งานอุปกรณ์ทีวีมีฟีเจอร์เพื่อปรับปรุงการจัดการพลังงานของอุปกรณ์ที่รวมอยู่ใน AOSP หรือขยายฟีเจอร์ที่รวมอยู่ใน AOSP อุปกรณ์ดังกล่าวจะต้องมีคุณสมบัติดังนี้
- [8.3/T-1-1] ต้องให้ผู้ใช้เปิดใช้และปิดใช้ฟีเจอร์ประหยัดแบตเตอรี่ได้
หากการติดตั้งใช้งานอุปกรณ์ทีวีไม่มีแบตเตอรี่ อุปกรณ์จะมีลักษณะดังนี้
- [8.3/T-1-2] ต้องลงทะเบียนอุปกรณ์เป็นอุปกรณ์แบบไม่มีแบตเตอรี่ตามที่อธิบายไว้ในการรองรับอุปกรณ์แบบไม่มีแบตเตอรี่
หากการติดตั้งใช้งานอุปกรณ์ทีวีมีแบตเตอรี่ อุปกรณ์จะมีลักษณะดังนี้
- [8.3/T-1-3] ต้องให้ทางเลือกแก่ผู้ใช้ในการแสดงแอปทั้งหมดที่ได้รับการยกเว้นจากโหมดประหยัดพลังงานสแตนด์บายแอปและโหมด Doze
การติดตั้งใช้งานอุปกรณ์ทีวี
- [8.4/T-0-1] ต้องมีโปรไฟล์พลังงานต่อคอมโพเนนต์ที่กำหนดค่าการบริโภคปัจจุบันสำหรับคอมโพเนนต์ฮาร์ดแวร์แต่ละรายการและการสิ้นเปลืองแบตเตอรี่โดยประมาณที่เกิดจากคอมโพเนนต์เมื่อเวลาผ่านไปตามที่ระบุไว้ในเว็บไซต์โปรเจ็กต์โอเพนซอร์ส Android
- [8.4/T-0-2] ต้องรายงานค่าการบริโภคพลังงานทั้งหมดเป็นมิลลิแอมแปร์ชั่วโมง (mAh)
- [8.4/T-0-3] ต้องรายงานปริมาณการใช้พลังงานของ CPU ตาม UID ของแต่ละกระบวนการ โครงการโอเพนซอร์ส Android เป็นไปตามข้อกำหนดผ่านการใช้งานโมดูลเคอร์เนล
uid_cputime
- [8.4/T] ควรระบุแหล่งที่มาเป็นคอมโพเนนต์ฮาร์ดแวร์เอง หากไม่สามารถระบุแหล่งที่มาเป็นการใช้พลังงานของคอมโพเนนต์ฮาร์ดแวร์ในแอปพลิเคชัน
- [8.4/T-0-4] ต้องทำให้นักพัฒนาแอปสามารถดูปริมาณการใช้พลังงานนี้ผ่านคำสั่งเชลล์
adb shell dumpsys batterystats
ได้
2.3.5. รูปแบบการรักษาความปลอดภัย
การติดตั้งใช้งานอุปกรณ์ทีวี
- [9.11/T-0-1] ต้องสำรองข้อมูลการติดตั้งใช้งานคีย์สโตร์ด้วยสภาพแวดล้อมการดำเนินการแบบแยกส่วน
- [9.11/T-0-2] ต้องมีการใช้งานอัลกอริทึมการเข้ารหัส RSA, AES, ECDSA และ HMAC รวมถึงฟังก์ชันการแฮชของกลุ่ม MD5, SHA1 และ SHA-2 เพื่อรองรับอัลกอริทึมที่ระบบ Keystore ของ Android รองรับอย่างถูกต้องในพื้นที่ที่แยกออกจากโค้ดที่ทำงานบนเคอร์เนลและที่สูงกว่าอย่างปลอดภัย การแยกที่ปลอดภัยต้องบล็อกกลไกที่เป็นไปได้ทั้งหมดซึ่งโค้ดเคอร์เนลหรือพื้นที่ผู้ใช้อาจเข้าถึงสถานะภายในของสภาพแวดล้อมที่แยกไว้ รวมถึง DMA โปรเจ็กต์โอเพนซอร์ส Android (AOSP) ต้นทางเป็นไปตามข้อกำหนดนี้โดยใช้การติดตั้งใช้งาน Trusty แต่โซลูชันอื่นๆ ที่ใช้ ARM TrustZone หรือการติดตั้งใช้งานการแยกส่วนบนไฮเปอร์วิซอร์ที่เหมาะสมซึ่งผ่านการตรวจสอบโดยบุคคลที่สามก็เป็นตัวเลือกทางเลือกได้
- [9.11/T-0-3] ต้องดำเนินการตรวจสอบสิทธิ์หน้าจอล็อกในสภาพแวดล้อมการเรียกใช้แบบแยกและอนุญาตให้ใช้คีย์ที่เชื่อมโยงกับการตรวจสอบสิทธิ์ก็ต่อเมื่อตรวจสอบสิทธิ์สำเร็จเท่านั้น ข้อมูลเข้าสู่ระบบของหน้าจอล็อกต้องจัดเก็บในลักษณะที่อนุญาตให้เฉพาะสภาพแวดล้อมการเรียกใช้แบบแยกส่วนเท่านั้นที่ดำเนินการตรวจสอบสิทธิ์หน้าจอล็อกได้ โปรเจ็กต์โอเพนซอร์สของ Android เวอร์ชันอัปสตรีมมี Gatekeeper Hardware Abstraction Layer (HAL) และ Trusty ซึ่งสามารถใช้เพื่อปฏิบัติตามข้อกำหนดนี้ได้
- [9.11/T-0-4] ต้องรองรับการรับรองคีย์ในกรณีที่คีย์การลงนามในการรับรองได้รับการปกป้องโดยฮาร์ดแวร์ที่มีความปลอดภัย และการลงนามจะดำเนินการในฮาร์ดแวร์ที่มีความปลอดภัย คุณต้องแชร์คีย์การรับรองเพื่อลงนามในอุปกรณ์จํานวนมากพอเพื่อป้องกันไม่ให้มีการใช้คีย์เป็นตัวระบุอุปกรณ์ วิธีหนึ่งในการปฏิบัติตามข้อกำหนดนี้คือการแชร์คีย์การรับรองเดียวกัน เว้นแต่จะมีการผลิต SKU หนึ่งๆ อย่างน้อย 100,000 หน่วย หากผลิต SKU มากกว่า 100,000 หน่วย คุณอาจใช้คีย์อื่นสำหรับ 100,000 หน่วยแต่ละหน่วย
- [9/T-0-1] MUST declare the ‘android.hardware.security.model.compatible’ feature.
โปรดทราบว่าหากมีการใช้งานอุปกรณ์ใน Android เวอร์ชันเก่าอยู่แล้ว อุปกรณ์ดังกล่าวจะได้รับการยกเว้นจากข้อกำหนดในการมีคีย์สโตร์ที่รองรับสภาพแวดล้อมการเรียกใช้แบบแยกและรองรับการรับรองคีย์ เว้นแต่จะมีการประกาศใช้ฟีเจอร์ android.hardware.fingerprint
ซึ่งต้องใช้คีย์สโตร์ที่รองรับสภาพแวดล้อมการเรียกใช้แบบแยก
หากการติดตั้งใช้งานอุปกรณ์ทีวีรองรับหน้าจอล็อกที่ปลอดภัย อุปกรณ์จะมีลักษณะดังนี้
- [9.11/T-1-1] ต้องอนุญาตให้ผู้ใช้เลือกระยะหมดเวลาของโหมดสลีปสำหรับการเปลี่ยนจากสถานะปลดล็อกเป็นล็อก โดยมีระยะหมดเวลาที่อนุญาตขั้นต่ำไม่เกิน 15 วินาที
หากการติดตั้งใช้งานอุปกรณ์ทีวีมีผู้ใช้หลายคนและไม่ประกาศ Flag ฟีเจอร์ android.hardware.telephony
ผู้ใช้จะดำเนินการต่อไปนี้
- [9.5/T-2-1] ต้องรองรับโปรไฟล์ที่ถูกจำกัด ซึ่งเป็นฟีเจอร์ที่ช่วยให้เจ้าของอุปกรณ์จัดการผู้ใช้เพิ่มเติมและความสามารถของผู้ใช้เหล่านั้นในอุปกรณ์ได้ เมื่อใช้โปรไฟล์ที่จํากัด เจ้าของอุปกรณ์จะตั้งค่าสภาพแวดล้อมแยกต่างหากสําหรับผู้ใช้คนอื่นๆ ได้อย่างรวดเร็ว พร้อมทั้งจัดการข้อจํากัดที่ละเอียดยิ่งขึ้นในแอปที่ใช้ได้ภายในสภาพแวดล้อมเหล่านั้น
หากการติดตั้งใช้งานอุปกรณ์ทีวีมีผู้ใช้หลายคนและประกาศ Flag ฟีเจอร์ android.hardware.telephony
ผู้ใช้เหล่านั้นจะทำสิ่งต่อไปนี้ได้
- [9.5/T-3-1] ต้องไม่รองรับโปรไฟล์ที่จํากัด แต่ต้องสอดคล้องกับการใช้งานการควบคุมของ AOSP เพื่อเปิด /ปิดใช้ไม่ให้ผู้ใช้รายอื่นเข้าถึงการโทรด้วยเสียงและ SMS
หากการติดตั้งใช้งานอุปกรณ์โทรทัศน์ประกาศ android.hardware.microphone
อุปกรณ์จะมีลักษณะดังนี้
- [9.8.2/T-4-1] ต้องแสดงตัวบ่งชี้ไมโครโฟนเมื่อแอปเข้าถึงข้อมูลเสียงจากไมโครโฟน แต่ไม่ต้องแสดงเมื่อมีเพียง HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService หรือแอปที่มีบทบาทตามที่ระบุไว้ในส่วนที่ 9.1 เท่านั้นที่เข้าถึงไมโครโฟน สิทธิ์ที่มีตัวระบุ CDD C-3-X]
- [9.8.2/T-4-2] ต้องไม่ซ่อนตัวบ่งชี้ไมโครโฟนสำหรับแอประบบที่มีอินเทอร์เฟซผู้ใช้ที่มองเห็นได้หรือการโต้ตอบโดยตรงกับผู้ใช้
หากการติดตั้งใช้งานอุปกรณ์โทรทัศน์ประกาศ android.hardware.camera.any
อุปกรณ์จะมีลักษณะดังนี้
- [9.8.2/T-5-1] ต้องแสดงตัวบ่งชี้กล้องเมื่อแอปเข้าถึงข้อมูลกล้องสด แต่ไม่ต้องแสดงเมื่อแอปที่มีบทบาทตามที่ระบุไว้ในส่วนที่ 9.1 เข้าถึงกล้องเท่านั้น สิทธิ์ที่มีตัวระบุ CDD [C-3-X]
- [9.8.2/T-5-2] ต้องไม่ซ่อนไฟสัญญาณกล้องสำหรับแอประบบที่มีอินเทอร์เฟซผู้ใช้ที่มองเห็นได้หรือการโต้ตอบโดยตรงกับผู้ใช้
2.3.6. ความเข้ากันได้ของเครื่องมือและตัวเลือกสำหรับนักพัฒนาแอป
การติดตั้งใช้งานอุปกรณ์ทีวี
- Perfetto
- [6.1/T-0-1] ต้องแสดง
/system/bin/perfetto
ไบนารีต่อผู้ใช้เชลล์ ซึ่ง cmdline เป็นไปตามเอกสารประกอบของ Perfetto - [6.1/T-0-2] ไฟล์ไบนารีของ Perfetto ต้องยอมรับการกำหนดค่า protobuf เป็นอินพุตที่เป็นไปตามสคีมาที่กำหนดไว้ในเอกสารประกอบของ Perfetto
- [6.1/T-0-3] ไฟล์ไบนารีของ Perfetto ต้องเขียนร่องรอย protobuf เป็นเอาต์พุตที่เป็นไปตามสคีมาที่กำหนดไว้ในเอกสารประกอบของ Perfetto
- [6.1/T-0-4] ต้องมีแหล่งข้อมูลอย่างน้อยตามที่อธิบายไว้ในเอกสารประกอบของ Perfetto ผ่านไฟล์ไบนารีของ Perfetto
- [6.1/T-0-1] ต้องแสดง
2.4 ข้อกำหนดของนาฬิกา
อุปกรณ์นาฬิกา Android หมายถึงการใช้งานอุปกรณ์ Android ที่มีไว้สวมใส่บนร่างกาย เช่น ที่ข้อมือ
การติดตั้งใช้งานอุปกรณ์ Android จะจัดอยู่ในประเภทนาฬิกาหากมีคุณสมบัติตรงตามเกณฑ์ต่อไปนี้ทั้งหมด
- มีหน้าจอที่มีความยาวตามแนวทแยงมุมจริงอยู่ในช่วง 1.1 ถึง 2.5 นิ้ว
- มีกลไกสำหรับสวมใส่บนร่างกาย
ข้อกำหนดเพิ่มเติมในส่วนที่เหลือของส่วนนี้เกี่ยวข้องกับการติดตั้งใช้งานอุปกรณ์ Android Watch โดยเฉพาะ
2.4.1. ฮาร์ดแวร์
ดูการติดตั้งใช้งานอุปกรณ์
[7.1.1.1/W-0-1] ต้องมีหน้าจอที่มีขนาดเส้นทแยงมุมจริงอยู่ในช่วง 1.1 ถึง 2.5 นิ้ว
[7.2.3/W-0-1] ต้องมีฟังก์ชันหน้าแรกสำหรับผู้ใช้และฟังก์ชันกลับ ยกเว้นในกรณีที่อยู่ใน
UI_MODE_TYPE_WATCH
[7.2.4/W-0-1] ต้องรองรับอินพุตหน้าจอสัมผัส
[7.3.1/W-SR-1] ขอแนะนำอย่างยิ่งให้ใส่เครื่องวัดความเร่ง 3 แกน
หากการติดตั้งใช้งานอุปกรณ์นาฬิกามีเครื่องรับ GPS/GNSS และรายงานความสามารถไปยังแอปพลิเคชันผ่าน Flag ฟีเจอร์ android.hardware.location.gps
อุปกรณ์จะมีลักษณะดังนี้
- [7.3.3/W-1-1] ต้องรายงานการวัดผล GNSS ทันทีที่พบ แม้ว่าจะยังไม่ได้รายงานตำแหน่งที่คำนวณจาก GPS/GNSS
- [7.3.3/W-1-2] ต้องรายงานอัตราความแม่นยำของสัญญาณจำลองและสัญญาณจำลองของ GNSS ซึ่งเพียงพอที่จะคำนวณตำแหน่งภายใน 20 เมตรและความเร็วภายใน 0.2 เมตรต่อวินาทีภายใต้สภาพท้องฟ้าเปิดหลังจากระบุตำแหน่งแล้ว ขณะหยุดนิ่งหรือเคลื่อนที่ด้วยความเร่งน้อยกว่า 0.2 เมตรต่อวินาทียกกำลัง 2 อย่างน้อย 95% ของเวลา
หากการติดตั้งใช้งานอุปกรณ์ Watch มีไจโรสโคปแบบ 3 แกน อุปกรณ์จะมีลักษณะดังนี้
- [7.3.4/W-2-1] ต้องสามารถวัดการเปลี่ยนแปลงการวางแนวได้สูงสุด 1,000 องศาต่อวินาที
ดูการติดตั้งใช้งานอุปกรณ์
[7.4.3/W-0-1] ต้องรองรับบลูทูธ
[7.6.1/W-0-1] ต้องมีพื้นที่เก็บข้อมูลแบบไม่ผันผวนอย่างน้อย 1 GB สำหรับข้อมูลส่วนตัวของแอปพลิเคชัน (หรือที่เรียกว่าพาร์ติชัน "/data")
[7.6.1/W-0-2] ต้องมีหน่วยความจำอย่างน้อย 416 MB ที่พร้อมใช้งานสำหรับเคอร์เนลและพื้นที่ผู้ใช้
[7.8.1/W-0-1] ต้องมีไมโครโฟน
[7.8.2/W] อาจมีพอร์ตเอาต์พุตเสียง
2.4.2. มัลติมีเดีย
ไม่มีข้อกำหนดเพิ่มเติม
2.4.3. ซอฟต์แวร์
ดูการติดตั้งใช้งานอุปกรณ์
- [3/W-0-1] MUST declare the feature
android.hardware.type.watch
- [3/W-0-2] ต้องรองรับ uiMode = UI_MODE_TYPE_WATCH
- [3.2.3.1/W-0-1] ต้องโหลดแอปพลิเคชันหรือคอมโพเนนต์บริการอย่างน้อย 1 รายการล่วงหน้าด้วยตัวแฮนเดิล Intent สำหรับรูปแบบตัวกรอง Intent สาธารณะทั้งหมดที่กําหนดโดย Intent ของแอปพลิเคชันต่อไปนี้ที่แสดงไว้ที่นี่
ดูการติดตั้งใช้งานอุปกรณ์
- [3.8.4/W-SR-1] ขอแนะนําอย่างยิ่งให้ใช้ผู้ช่วยในอุปกรณ์เพื่อจัดการการดำเนินการ Assist
ดูการติดตั้งใช้งานอุปกรณ์ที่ประกาศandroid.hardware.audio.output
Flag ฟีเจอร์
- [3.10/W-1-1] ต้องรองรับบริการการช่วยเหลือพิเศษของบุคคลที่สาม
- [3.10/W-SR-1] ขอแนะนำอย่างยิ่งให้โหลดบริการการช่วยเหลือพิเศษล่วงหน้าในอุปกรณ์ที่เทียบเท่ากับหรือมีประสิทธิภาพมากกว่าบริการการช่วยเหลือพิเศษของการเข้าถึงด้วยสวิตช์และ TalkBack (สำหรับภาษาที่รองรับโดยเครื่องมืออ่านออกเสียงข้อความที่ติดตั้งไว้ล่วงหน้า) ตามที่ระบุไว้ในโปรเจ็กต์โอเพนซอร์สของ TalkBack
หากการติดตั้งใช้งานอุปกรณ์นาฬิการายงานฟีเจอร์ android.hardware.audio.output อุปกรณ์จะมีลักษณะดังนี้
[3.11/W-SR-1] ขอแนะนำอย่างยิ่งให้ใส่เครื่องมือ TTS ที่รองรับภาษาที่มีในอุปกรณ์
[3.11/W-0-1] ต้องรองรับการติดตั้งโปรแกรม TTS ของบุคคลที่สาม
2.4.4. ประสิทธิภาพและกำลังไฟ
หากการติดตั้งใช้งานอุปกรณ์นาฬิกามีฟีเจอร์เพื่อปรับปรุงการจัดการพลังงานของอุปกรณ์ที่รวมอยู่ใน AOSP หรือขยายฟีเจอร์ที่รวมอยู่ใน AOSP อุปกรณ์ดังกล่าวจะต้องมีคุณสมบัติดังนี้
- [8.3/W-SR-1] ขอแนะนำอย่างยิ่งให้ระบุตัวเลือกให้ผู้ใช้แสดงแอปทั้งหมดที่ได้รับการยกเว้นจากโหมดประหยัดพลังงาน "แอปรอดำเนินการ" และ "โหมดสลีป"
- [8.3/W-SR-2] ขอแนะนำอย่างยิ่งให้ระบุตัวเลือกให้ผู้ใช้เปิดและปิดใช้ฟีเจอร์ประหยัดแบตเตอรี่
ดูการติดตั้งใช้งานอุปกรณ์
- [8.4/W-0-1] ต้องมีโปรไฟล์พลังงานต่อคอมโพเนนต์ที่ระบุค่าการบริโภคปัจจุบันสำหรับคอมโพเนนต์ฮาร์ดแวร์แต่ละรายการและการสิ้นเปลืองแบตเตอรี่โดยประมาณที่เกิดจากคอมโพเนนต์เมื่อเวลาผ่านไปตามที่ระบุไว้ในเว็บไซต์โปรเจ็กต์โอเพนซอร์ส Android
- [8.4/W-0-2] ต้องรายงานค่าการสิ้นเปลืองพลังงานทั้งหมดเป็นมิลลิแอมแปร์ชั่วโมง (mAh)
- [8.4/W-0-3] ต้องรายงานปริมาณการใช้พลังงานของ CPU ตาม UID ของแต่ละกระบวนการ โครงการโอเพนซอร์ส Android เป็นไปตามข้อกำหนดผ่านการใช้งานโมดูลเคอร์เนล
uid_cputime
- [8.4/W-0-4] ต้องทำให้นักพัฒนาแอปสามารถดูปริมาณการใช้พลังงานนี้ผ่านคำสั่งเชลล์
adb shell dumpsys batterystats
ได้ - [8.4/W] ควรระบุแหล่งที่มาเป็นคอมโพเนนต์ฮาร์ดแวร์เอง หากไม่สามารถระบุแหล่งที่มาเป็นการใช้พลังงานของคอมโพเนนต์ฮาร์ดแวร์ในแอปพลิเคชันได้
2.4.5. รูปแบบการรักษาความปลอดภัย
ดูการติดตั้งใช้งานอุปกรณ์
- [9/W-0-1] MUST declare the
android.hardware.security.model.compatible
feature.
หากการใช้งานอุปกรณ์ Watch มีผู้ใช้หลายคนและไม่ประกาศ Flag ฟีเจอร์ android.hardware.telephony
ผู้ใช้เหล่านั้นจะทำสิ่งต่อไปนี้
- [9.5/W-1-1] ต้องรองรับโปรไฟล์ที่ถูกจำกัด ซึ่งเป็นฟีเจอร์ที่ช่วยให้เจ้าของอุปกรณ์จัดการผู้ใช้เพิ่มเติมและความสามารถของผู้ใช้เหล่านั้นในอุปกรณ์ได้ เมื่อใช้โปรไฟล์ที่จํากัด เจ้าของอุปกรณ์จะตั้งค่าสภาพแวดล้อมแยกต่างหากสําหรับผู้ใช้คนอื่นๆ ได้อย่างรวดเร็ว พร้อมทั้งจัดการข้อจํากัดที่ละเอียดยิ่งขึ้นในแอปที่ใช้ได้ภายในสภาพแวดล้อมเหล่านั้น
หากการติดตั้งใช้งานอุปกรณ์ Watch มีผู้ใช้หลายคนและประกาศ Flag ฟีเจอร์ android.hardware.telephony
ผู้ใช้เหล่านั้นจะทำสิ่งต่อไปนี้ได้
- [9.5/W-2-1] ต้องไม่รองรับโปรไฟล์ที่จํากัด แต่ต้องสอดคล้องกับการใช้งานการควบคุมของ AOSP เพื่อเปิด /ปิดใช้ไม่ให้ผู้ใช้รายอื่นเข้าถึงการโทรด้วยเสียงและ SMS
2.5 ข้อกำหนดเกี่ยวกับยานยนต์
การติดตั้งใช้งาน Android Automotive หมายถึงเครื่องเสียงรถยนต์ที่ใช้ Android เป็นระบบปฏิบัติการสำหรับฟังก์ชันการทำงานบางส่วนหรือทั้งหมดของระบบและ/หรือระบบสาระบันเทิง
การติดตั้งใช้งานอุปกรณ์ Android จะจัดอยู่ในประเภทยานยนต์หากมีการประกาศฟีเจอร์ android.hardware.type.automotive
หรือมีคุณสมบัติตรงตามเกณฑ์ต่อไปนี้ทั้งหมด
- ฝังอยู่เป็นส่วนหนึ่งของหรือเสียบเข้ากับยานพาหนะ
- ใช้หน้าจอในแถวที่นั่งคนขับเป็นจอแสดงผลหลัก
ข้อกำหนดเพิ่มเติมในส่วนที่เหลือของส่วนนี้เกี่ยวข้องกับการติดตั้งใช้งานอุปกรณ์ Android Auto โดยเฉพาะ
2.5.1. ฮาร์ดแวร์
การติดตั้งใช้งานอุปกรณ์ยานยนต์
- [7.1.1.1/A-0-1] ต้องมีหน้าจอขนาดเส้นทแยงมุมอย่างน้อย 6 นิ้ว
[7.1.1.1/A-0-2] ต้องมีเลย์เอาต์ขนาดหน้าจออย่างน้อย 750 dp x 480 dp
[7.2.3/A-0-1] ต้องมีฟังก์ชันหน้าแรกและอาจมีฟังก์ชันย้อนกลับและล่าสุด
[7.2.3/A-0-2] ต้องส่งทั้งเหตุการณ์การกดปกติและการกดค้างไว้ของฟังก์ชัน Back (
KEYCODE_BACK
) ไปยังแอปพลิเคชันที่ทำงานอยู่เบื้องหน้า[7.3/A-0-1] ต้องติดตั้งใช้งานและรายงาน
GEAR_SELECTION
,NIGHT_MODE
,PERF_VEHICLE_SPEED
และPARKING_BRAKE_ON
[7.3/A-0-2] ค่าของ Flag
NIGHT_MODE
ต้องสอดคล้องกับโหมดกลางวัน/กลางคืนของหน้าแดชบอร์ด และควรอิงตามอินพุตจากเซ็นเซอร์แสงรอบข้าง เซ็นเซอร์แสงแวดล้อมที่เกี่ยวข้องอาจเหมือนกับโฟโตมิเตอร์[7.3/A-0-3] ต้องมีช่องข้อมูลเพิ่มเติมของเซ็นเซอร์
TYPE_SENSOR_PLACEMENT
เป็นส่วนหนึ่งของ SensorAdditionalInfo สำหรับเซ็นเซอร์ทุกตัวที่ระบุ[7.3/A-0-1] อาจประมาณตำแหน่งโดยรวม GPS/GNSS เข้ากับเซ็นเซอร์เพิ่มเติม หากตำแหน่งเป็นการประมาณ เราขอแนะนำอย่างยิ่งให้ติดตั้งใช้งานและรายงานประเภทเซ็นเซอร์และ/หรือรหัสพร็อพเพอร์ตี้ยานพาหนะที่เกี่ยวข้อง
[7.3/A-0-2] ตำแหน่งที่ขอผ่าน LocationManager#requestLocationUpdates() ต้องไม่จับคู่กับแผนที่
หากการติดตั้งใช้งานอุปกรณ์ยานยนต์รองรับ OpenGL ES 3.1 อุปกรณ์จะมีลักษณะดังนี้
- [7.1.4.1/A-0-1] ต้องประกาศ OpenGL ES 3.1 ขึ้นไป
- [7.1.4.1/A-0-2] ต้องรองรับ Vulkan 1.1
- [7.1.4.1/A-0-3] ต้องมีโปรแกรมโหลด Vulkan และส่งออกสัญลักษณ์ทั้งหมด
หากการติดตั้งใช้งานอุปกรณ์ยานยนต์มีเครื่องวัดความเร่งแบบ 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-3] ต้องสามารถวัดการเปลี่ยนแปลงการวางแนวได้สูงสุด 250 องศาต่อวินาที
- [7.3.4/A-SR-1] ขอแนะนำอย่างยิ่งให้กําหนดค่าช่วงการวัดของgyroscope เป็น +/-250dps เพื่อเพิ่มความละเอียดสูงสุด
หากการติดตั้งใช้งานอุปกรณ์ยานยนต์มีเครื่องรับ GPS/GNSS แต่ไม่มีการเชื่อมต่อข้อมูลแบบเครือข่ายมือถือ อุปกรณ์ดังกล่าวจะมีลักษณะดังนี้
- [7.3.3/A-3-1] ต้องระบุตำแหน่งในครั้งแรกที่เปิดเครื่องรับ GPS/GNSS หรือหลังจากผ่านไป 4 วันขึ้นไปภายใน 60 วินาที
- [7.3.3/A-3-2] ต้องเป็นไปตามเกณฑ์เวลาในการแก้ไขครั้งแรกตามที่อธิบายไว้ใน 7.3.3/C-1-2 และ 7.3.3/C-1-6 สำหรับคำขอตำแหน่งอื่นๆ ทั้งหมด (นั่นคือคำขอที่ไม่ใช่ครั้งแรกหรือหลังจากผ่านไป 4 วันขึ้นไป) ข้อกำหนด 7.3.3/C-1-2 มักจะเป็นไปตามข้อกำหนดในยานพาหนะที่ไม่มีการเชื่อมต่อข้อมูลผ่านเครือข่ายมือถือ โดยใช้การคาดการณ์วงโคจร GNSS ที่คำนวณในเครื่องรับ หรือใช้ตำแหน่งยานพาหนะที่ทราบล่าสุดพร้อมกับความสามารถในการหาตำแหน่งโดยประมาณเป็นเวลาอย่างน้อย 60 วินาทีโดยมีความแม่นยำของตำแหน่งที่เป็นไปตามข้อกำหนด 7.3.3/C-1-3 หรือใช้ทั้ง 2 อย่างร่วมกัน
การติดตั้งใช้งานอุปกรณ์ยานยนต์
- [7.4.3/A-0-1] ต้องรองรับบลูทูธและควรรองรับบลูทูธ LE
- [7.4.3/A-0-2] การติดตั้งใช้งาน Android Automotive ต้องรองรับโปรไฟล์บลูทูธต่อไปนี้
- การโทรผ่านโปรไฟล์แฮนด์ฟรี (HFP)
- การเล่นสื่อผ่านโปรไฟล์การกระจายเสียง (A2DP)
- การควบคุมการเล่นสื่อผ่านโปรไฟล์การควบคุมระยะไกล (AVRCP)
- การแชร์รายชื่อติดต่อโดยใช้โปรไฟล์การเข้าถึงสมุดโทรศัพท์ (PBAP)
[7.4.3/A-SR-1] ขอแนะนำอย่างยิ่งให้รองรับ Profile การเข้าถึงข้อความ (MAP)
[7.4.5/ก] ควรรองรับการเชื่อมต่อข้อมูลผ่านเครือข่ายมือถือ
[7.4.5/A] อาจใช้ API ของระบบ
NetworkCapabilities#NET_CAPABILITY_OEM_PAID
แบบคงที่สำหรับเครือข่ายที่ควรพร้อมให้บริการแก่แอประบบ
กล้องมองภาพภายนอกคือกล้องที่ถ่ายภาพฉากนอกการติดตั้งอุปกรณ์ เช่น กล้องติดรถยนต์
การติดตั้งใช้งานอุปกรณ์ยานยนต์
- ควรมีกล้องมองภาพภายนอกอย่างน้อย 1 ตัว
หากการติดตั้งใช้งานอุปกรณ์ยานยนต์มีกล้องมองภาพภายนอก กล้องดังกล่าวจะต้องมีคุณสมบัติดังนี้
- [7.5/A-1-1] กล้องมองภาพด้านนอกต้องเข้าถึงไม่ได้ผ่าน Android Camera API เว้นแต่ว่ากล้องจะเป็นไปตามข้อกำหนดหลักของกล้อง
- [7.5/A-SR-1] ขอแนะนำอย่างยิ่งว่าอย่าหมุนหรือมิเรอร์การแสดงตัวอย่างจากกล้องในแนวนอน
- [7.5.5/A-SR-1] ขอแนะนำอย่างยิ่งให้ปรับแนวเพื่อให้มิติข้อมูลแนวยาวของกล้องสอดคล้องกับเส้นขอบฟ้า
- [7.5/A-SR-2] ขอแนะนำอย่างยิ่งให้ใช้ความละเอียดอย่างน้อย 1.3 ล้านพิกเซล
- ควรมีฮาร์ดแวร์แบบโฟกัสคงที่หรือ EDOF (ระยะชัดลึกแบบขยาย)
- ควรรองรับเฟรมเวิร์กการซิงค์ของ Android
- อาจใช้โฟกัสอัตโนมัติของฮาร์ดแวร์หรือโฟกัสอัตโนมัติของซอฟต์แวร์ในโปรแกรมควบคุมกล้อง
การติดตั้งใช้งานอุปกรณ์ยานยนต์
[7.6.1/A-0-1] ต้องมีพื้นที่เก็บข้อมูลแบบคงที่อย่างน้อย 4 GB สำหรับเก็บข้อมูลส่วนตัวของแอปพลิเคชัน (หรือที่เรียกว่าพาร์ติชัน "/data")
[7.6.1/A] ควรจัดรูปแบบพาร์ติชันข้อมูลเพื่อปรับปรุงประสิทธิภาพและอายุการใช้งานของพื้นที่เก็บข้อมูลแฟลช เช่น ใช้ระบบไฟล์
f2fs
หากการติดตั้งใช้งานอุปกรณ์ยานยนต์มีพื้นที่เก็บข้อมูลภายนอกที่แชร์ผ่านพื้นที่เก็บข้อมูลภายในแบบถอดออกไม่ได้ อุปกรณ์ดังกล่าวจะมีลักษณะดังนี้
- [7.6.1/A-SR-1] ขอแนะนำอย่างยิ่งให้ลดค่าใช้จ่ายด้าน I/O ในการดำเนินการที่ดำเนินการกับพื้นที่เก็บข้อมูลภายนอก เช่น โดยใช้
SDCardFS
หากการติดตั้งใช้งานอุปกรณ์ยานยนต์เป็น 32 บิต ให้ทำดังนี้
[7.6.1/A-1-1] หน่วยความจำที่ใช้ได้กับเคอร์เนลและพื้นที่ผู้ใช้ต้องมีขนาดอย่างน้อย 512 MB หากใช้ความหนาแน่นต่อไปนี้
- 280 dpi หรือต่ำกว่าบนหน้าจอขนาดเล็ก/ปกติ
- ldpi หรือต่ำกว่าในหน้าจอขนาดใหญ่พิเศษ
- mdpi หรือต่ำกว่าบนหน้าจอขนาดใหญ่
[7.6.1/A-1-2] หน่วยความจำที่ใช้ได้กับเคอร์เนลและพื้นที่ผู้ใช้ต้องมีขนาดอย่างน้อย 608 MB หากใช้ความหนาแน่นต่อไปนี้
- xhdpi ขึ้นไปในหน้าจอขนาดเล็ก/ปกติ
- hdpi ขึ้นไปบนหน้าจอขนาดใหญ่
- mdpi ขึ้นไปบนหน้าจอขนาดใหญ่พิเศษ
[7.6.1/A-1-3] หน่วยความจำที่ใช้ได้กับเคอร์เนลและพื้นที่ผู้ใช้ต้องมีขนาดอย่างน้อย 896 MB หากใช้ความหนาแน่นต่อไปนี้
- 400 dpi ขึ้นไปบนหน้าจอขนาดเล็ก/ปกติ
- xhdpi ขึ้นไปบนหน้าจอขนาดใหญ่
- tvdpi ขึ้นไปในหน้าจอขนาดใหญ่พิเศษ
[7.6.1/A-1-4] หน่วยความจำที่ใช้ได้กับเคอร์เนลและพื้นที่ผู้ใช้ต้องมีขนาดอย่างน้อย 1344 MB หากใช้ความหนาแน่นต่อไปนี้
- 560 dpi ขึ้นไปบนหน้าจอขนาดเล็ก/ปกติ
- 400dpi ขึ้นไปบนหน้าจอขนาดใหญ่
- xhdpi ขึ้นไปบนหน้าจอขนาดใหญ่พิเศษ
หากการติดตั้งใช้งานอุปกรณ์ยานยนต์เป็น 64 บิต ให้ทำดังนี้
[7.6.1/A-2-1] หน่วยความจำที่ใช้ได้กับเคอร์เนลและพื้นที่ผู้ใช้ต้องมีขนาดอย่างน้อย 816 MB หากใช้ความหนาแน่นต่อไปนี้
- 280 dpi หรือต่ำกว่าบนหน้าจอขนาดเล็ก/ปกติ
- ldpi หรือต่ำกว่าในหน้าจอขนาดใหญ่พิเศษ
- mdpi หรือต่ำกว่าบนหน้าจอขนาดใหญ่
[7.6.1/A-2-2] หน่วยความจำที่ใช้ได้กับเคอร์เนลและพื้นที่ผู้ใช้ต้องมีขนาดอย่างน้อย 944 MB หากใช้ความหนาแน่นต่อไปนี้
- xhdpi ขึ้นไปในหน้าจอขนาดเล็ก/ปกติ
- hdpi ขึ้นไปบนหน้าจอขนาดใหญ่
- mdpi ขึ้นไปบนหน้าจอขนาดใหญ่พิเศษ
[7.6.1/A-2-3] หน่วยความจำที่ใช้ได้กับเคอร์เนลและพื้นที่ผู้ใช้ต้องมีขนาดอย่างน้อย 1280 MB หากใช้ความหนาแน่นต่อไปนี้
- 400dpi ขึ้นไปบนหน้าจอขนาดเล็ก/ปกติ
- xhdpi ขึ้นไปบนหน้าจอขนาดใหญ่
- tvdpi ขึ้นไปในหน้าจอขนาดใหญ่พิเศษ
[7.6.1/A-2-4] หน่วยความจำที่ใช้ได้กับเคอร์เนลและพื้นที่ผู้ใช้ต้องมีขนาดอย่างน้อย 1824 MB หากใช้ความหนาแน่นต่อไปนี้
- 560 dpi ขึ้นไปบนหน้าจอขนาดเล็ก/ปกติ
- 400dpi ขึ้นไปบนหน้าจอขนาดใหญ่
- xhdpi ขึ้นไปบนหน้าจอขนาดใหญ่พิเศษ
โปรดทราบว่า "หน่วยความจำที่พร้อมใช้งานสำหรับเคอร์เนลและพื้นที่ผู้ใช้" ด้านบนหมายถึงพื้นที่หน่วยความจำที่ให้มาเพิ่มเติมจากหน่วยความจำที่กําหนดไว้สําหรับคอมโพเนนต์ฮาร์ดแวร์ เช่น วิทยุ วิดีโอ และอื่นๆ อยู่แล้ว ซึ่งไม่อยู่ภายใต้การควบคุมของเคิร์นัลในการใช้งานอุปกรณ์
การติดตั้งใช้งานอุปกรณ์ยานยนต์
- [7.7.1/A] ควรมีพอร์ต USB ที่รองรับโหมดอุปกรณ์ต่อพ่วง
การติดตั้งใช้งานอุปกรณ์ยานยนต์
- [7.8.1/A-0-1] ต้องมีไมโครโฟน
การติดตั้งใช้งานอุปกรณ์ยานยนต์
- [7.8.2/A-0-1] ต้องมีเอาต์พุตเสียงและประกาศ
android.hardware.audio.output
2.5.2. มัลติมีเดีย
การติดตั้งใช้งานอุปกรณ์ยานยนต์ต้องรองรับรูปแบบการเข้ารหัสและการถอดรหัสเสียงต่อไปนี้ และทำให้แอปพลิเคชันของบุคคลที่สามใช้งานได้
- [5.1/A-0-1] โปรไฟล์ MPEG-4 AAC (AAC LC)
- [5.1/A-0-2] โปรไฟล์ MPEG-4 HE AAC (AAC+)
- [5.1/A-0-3] AAC ELD (AAC แบบลดเวลาหน่วงที่มีประสิทธิภาพมากขึ้น)
การติดตั้งใช้งานอุปกรณ์ยานยนต์ต้องรองรับรูปแบบการเข้ารหัสวิดีโอต่อไปนี้และทำให้แอปพลิเคชันของบุคคลที่สามใช้งานได้
การติดตั้งใช้งานอุปกรณ์ยานยนต์ต้องรองรับรูปแบบการถอดรหัสวิดีโอต่อไปนี้และทำให้พร้อมใช้งานสำหรับแอปพลิเคชันของบุคคลที่สาม
เราขอแนะนำอย่างยิ่งให้การติดตั้งใช้งานอุปกรณ์ยานยนต์รองรับการถอดรหัสวิดีโอต่อไปนี้
- [5.3/A-SR-1] H.265 HEVC
2.5.3. ซอฟต์แวร์
การติดตั้งใช้งานอุปกรณ์ยานยนต์
[3/A-0-1] ต้องประกาศฟีเจอร์
android.hardware.type.automotive
[3/A-0-2] ต้องรองรับ uiMode =
UI_MODE_TYPE_CAR
[3/A-0-3] ต้องรองรับ API สาธารณะทั้งหมดในเนมสเปซ
android.car.*
หากการติดตั้งใช้งานอุปกรณ์ยานยนต์มี API ที่เป็นกรรมสิทธิ์โดยใช้ android.car.CarPropertyManager
กับ android.car.VehiclePropertyIds
อุปกรณ์ดังกล่าวจะมีลักษณะดังนี้
- [3/A-1-1] ต้องไม่แนบสิทธิ์พิเศษไว้กับการใช้พร็อพเพอร์ตี้เหล่านี้ของแอปพลิเคชันระบบ หรือป้องกันไม่ให้แอปพลิเคชันของบุคคลที่สามใช้พร็อพเพอร์ตี้เหล่านี้
- [3/A-1-2] ต้องไม่ทำซ้ำพร็อพเพอร์ตี้ยานพาหนะที่อยู่แล้วใน SDK
การติดตั้งใช้งานอุปกรณ์ยานยนต์
[3.2.1/A-0-1] ต้องรองรับและบังคับใช้ค่าคงที่สิทธิ์ทั้งหมดตามที่ระบุไว้ในหน้าอ้างอิงสิทธิ์ยานยนต์
[3.2.3.1/A-0-1] ต้องโหลดแอปพลิเคชันหรือคอมโพเนนต์บริการอย่างน้อย 1 รายการล่วงหน้าด้วยตัวแฮนเดิล Intent สำหรับรูปแบบตัวกรอง Intent สาธารณะทั้งหมดที่กําหนดโดย Intent ของแอปพลิเคชันต่อไปนี้ที่ระบุไว้ที่นี่
[3.4.1/A-0-1] ต้องติดตั้งใช้งาน
android.webkit.Webview
API อย่างสมบูรณ์[3.8.3/A-0-1] ต้องแสดงการแจ้งเตือนที่ใช้
Notification.CarExtender
API เมื่อแอปพลิเคชันของบุคคลที่สามขอ[3.8.4/A-SR-1] ขอแนะนำอย่างยิ่งให้ใช้ผู้ช่วยในอุปกรณ์เพื่อจัดการการดำเนินการ Assist
หากการติดตั้งใช้งานอุปกรณ์ยานยนต์มีปุ่มกดเพื่อพูด อุปกรณ์จะต้องมีลักษณะดังนี้
- [3.8.4/A-1-1] ต้องกดปุ่ม Push-To-Talk สั้นๆ เป็นอินเทอร์แอกชันที่กำหนดไว้เพื่อเปิดแอปความช่วยเหลือที่ผู้ใช้เลือก กล่าวคือแอปที่ใช้
VoiceInteractionService
การติดตั้งใช้งานอุปกรณ์ยานยนต์
- [3.8.3.1/A-0-1] ต้องแสดงผลทรัพยากรอย่างถูกต้องตามที่อธิบายไว้ในเอกสารประกอบ
Notifications on Automotive OS
ของ SDK - [3.8.3.1/A-0-2] ต้องแสดงปุ่มเล่นและปิดเสียงสําหรับการดําเนินการการแจ้งเตือนแทนปุ่มที่ระบุผ่าน
Notification.Builder.addAction()
- [3.8.3.1/ก] ควรจำกัดการใช้งานการจัดการแบบริชมีเดีย เช่น การควบคุมช่องทางการแจ้งเตือน ใช้การอำนวยความสะดวกของ UI ต่อแอปพลิเคชันเพื่อลดการควบคุมได้
หากการติดตั้งใช้งานอุปกรณ์ยานยนต์รองรับพร็อพเพอร์ตี้ HAL ของผู้ใช้ อุปกรณ์จะมีลักษณะดังนี้
- [3.9.3/A-1-1] ต้องติดตั้งใช้งานพร็อพเพอร์ตี้วงจรของลูกค้าทั้งหมด
INITIAL_USER_INFO
,SWITCH_USER
,CREATE_USER
,REMOVE_USER
การติดตั้งใช้งานอุปกรณ์ยานยนต์
- [3.14/A-0-1] ต้องมีเฟรมเวิร์ก UI เพื่อรองรับแอปของบุคคลที่สามที่ใช้ Media API ตามที่อธิบายไว้ในส่วน3.14
- [3.14/A-0-2] ต้องอนุญาตให้ผู้ใช้โต้ตอบกับแอปพลิเคชันสื่อขณะขับรถได้อย่างปลอดภัย
- [3.14/A-0-3] ต้องรองรับการดำเนินการ Intent ที่ไม่ชัดซึ่งใช้แอตทริบิวต์
CAR_EXTRA_MEDIA_PACKAGE
เพิ่มเติมCAR_INTENT_ACTION_MEDIA_TEMPLATE
- [3.14/A-0-4] ต้องมีความสามารถในการไปยังส่วนต่างๆ ของกิจกรรมการตั้งค่าแอปพลิเคชันสื่อ แต่ต้องเปิดใช้เฉพาะเมื่อข้อจำกัด UX ของรถยนต์ไม่มีผล
- [3.14/A-0-5] ต้องแสดงข้อความแสดงข้อผิดพลาดที่ตั้งค่าโดย Media Applications และต้องรองรับส่วนเสริมที่ไม่บังคับ
ERROR_RESOLUTION_ACTION_LABEL
และERROR_RESOLUTION_ACTION_INTENT
- [3.14/A-0-6] ต้องรองรับการอำนวยความสะดวกในการค้นหาในแอปสําหรับแอปที่รองรับการค้นหา
- [3.14/A-0-7] ต้องเป็นไปตามคำจำกัดความของ
CONTENT_STYLE_BROWSABLE_HINT
และCONTENT_STYLE_PLAYABLE_HINT
เมื่อแสดงลําดับชั้น MediaBrowser
หากการติดตั้งใช้งานอุปกรณ์ยานยนต์มีแอปตัวเปิดแอปเริ่มต้น แอปดังกล่าวจะมีลักษณะดังนี้
- [3.14/A-1-1] ต้องมีบริการสื่อและเปิดบริการเหล่านั้น
ด้วย Intent
CAR_INTENT_ACTION_MEDIA_TEMPLATE
การติดตั้งใช้งานอุปกรณ์ยานยนต์
- [3.8/ก] อาจจํากัดคําขอของโปรแกรมที่จะเข้าสู่โหมดเต็มหน้าจอตามที่อธิบายไว้ใน
immersive documentation
- [3.8/ก] อาจแสดงแถบสถานะและแถบนําทางตลอดเวลา
- [3.8/ก] อาจจำกัดคำขอของแอปพลิเคชันเพื่อเปลี่ยนสีที่อยู่หลังองค์ประกอบ UI ของระบบ เพื่อให้แน่ใจว่าองค์ประกอบเหล่านั้นจะมองเห็นได้ชัดเจนตลอดเวลา
2.5.4. ประสิทธิภาพและกำลังไฟ
การติดตั้งใช้งานอุปกรณ์ยานยนต์
- [8.2/A-0-1] ต้องรายงานจํานวนไบต์ที่อ่านและเขียนลงในพื้นที่เก็บข้อมูลแบบไม่ผันผวนตาม UID ของแต่ละกระบวนการเพื่อให้นักพัฒนาแอปมีสถิติผ่าน System API
android.car.storagemonitoring.CarStorageMonitoringManager
โครงการโอเพนซอร์ส Android เป็นไปตามข้อกำหนดผ่านโมดูลเคอร์เนลuid_sys_stats
- [8.3/A-1-3] ต้องรองรับโหมดโรงรถ
- [8.3/ก] ควรอยู่ในโหมดโรงรถอย่างน้อย 15 นาทีหลังจากขับรถทุกครั้ง เว้นแต่ในกรณีต่อไปนี้
- แบตเตอรี่หมด
- ไม่มีการกำหนดเวลางานที่ไม่ได้ใช้งาน
- คนขับออกจากโหมดโรงรถ
- [8.4/A-0-1] ต้องมีโปรไฟล์พลังงานต่อคอมโพเนนต์ที่กำหนดค่าการบริโภคปัจจุบันสำหรับคอมโพเนนต์ฮาร์ดแวร์แต่ละรายการและการสิ้นเปลืองแบตเตอรี่โดยประมาณที่เกิดจากคอมโพเนนต์เมื่อเวลาผ่านไปตามที่ระบุไว้ในเว็บไซต์โปรเจ็กต์โอเพนซอร์ส Android
- [8.4/A-0-2] ต้องรายงานค่าการสิ้นเปลืองพลังงานทั้งหมดเป็นมิลลิแอมแปร์ชั่วโมง (mAh)
- [8.4/A-0-3] ต้องรายงานปริมาณการใช้พลังงานของ CPU ตาม UID ของแต่ละกระบวนการ โครงการโอเพนซอร์ส Android เป็นไปตามข้อกำหนดผ่านการใช้งานโมดูลเคอร์เนล
uid_cputime
- [8.4/ก] ควรระบุแหล่งที่มาเป็นคอมโพเนนต์ฮาร์ดแวร์เอง หากไม่สามารถระบุแหล่งที่มาเป็นการใช้พลังงานของคอมโพเนนต์ฮาร์ดแวร์ในแอปพลิเคชัน
- [8.4/A-0-4] ต้องทำให้นักพัฒนาแอปสามารถดูปริมาณการใช้พลังงานนี้ได้ผ่านคำสั่งเชลล์
adb shell dumpsys batterystats
2.5.5. รูปแบบการรักษาความปลอดภัย
หากการติดตั้งใช้งานอุปกรณ์ยานยนต์รองรับผู้ใช้หลายคน ผู้ใช้จะทำสิ่งต่อไปนี้ได้
- [9.5/A-1-1] ต้องไม่อนุญาตให้ผู้ใช้โต้ตอบกับระบบหรือเปลี่ยนไปใช้ผู้ใช้ระบบแบบ Headless ยกเว้นการจัดสรรอุปกรณ์
- [9.5/A-1-2] ต้องเปลี่ยนไปเป็นผู้ใช้รองก่อน
BOOT_COMPLETED
- [9.5/A-1-3] ต้องรองรับการสร้างผู้ใช้ชั่วคราวแม้ว่าจะมีผู้ใช้ในอุปกรณ์ถึงจำนวนสูงสุดแล้วก็ตาม
การติดตั้งใช้งานอุปกรณ์ยานยนต์
- [9.11/A-0-1] ต้องสํารองข้อมูลการติดตั้งใช้งานคีย์สโตร์ด้วยสภาพแวดล้อมการดําเนินการแบบแยก
- [9.11/A-0-2] ต้องมีการใช้งานอัลกอริทึมการเข้ารหัส RSA, AES, ECDSA และ HMAC รวมถึงฟังก์ชันการแฮชของกลุ่ม MD5, SHA1 และ SHA-2 เพื่อรองรับอัลกอริทึมที่ระบบ Android Keystore รองรับอย่างเหมาะสมในพื้นที่ที่แยกออกจากโค้ดที่ทำงานบนเคอร์เนลและที่สูงกว่าอย่างปลอดภัย การแยกที่ปลอดภัยต้องบล็อกกลไกที่เป็นไปได้ทั้งหมดซึ่งโค้ดเคอร์เนลหรือพื้นที่ผู้ใช้อาจเข้าถึงสถานะภายในของสภาพแวดล้อมที่แยกไว้ รวมถึง DMA โปรเจ็กต์โอเพนซอร์ส Android (AOSP) ต้นทางเป็นไปตามข้อกำหนดนี้โดยใช้การติดตั้งใช้งาน Trusty แต่โซลูชันอื่นๆ ที่ใช้ ARM TrustZone หรือการติดตั้งใช้งานการแยกส่วนบนไฮเปอร์วิซอร์ที่เหมาะสมซึ่งผ่านการตรวจสอบโดยบุคคลที่สามก็เป็นตัวเลือกทางเลือกได้
- [9.11/A-0-3] ต้องทำการตรวจสอบสิทธิ์หน้าจอล็อกในสภาพแวดล้อมการเรียกใช้แบบแยกและอนุญาตให้ใช้คีย์ที่เชื่อมโยงกับการตรวจสอบสิทธิ์ก็ต่อเมื่อการตรวจสอบสิทธิ์สำเร็จเท่านั้น ข้อมูลเข้าสู่ระบบของหน้าจอล็อกต้องจัดเก็บในลักษณะที่อนุญาตให้เฉพาะสภาพแวดล้อมการเรียกใช้แบบแยกส่วนเท่านั้นที่ดำเนินการตรวจสอบสิทธิ์หน้าจอล็อกได้ โปรเจ็กต์โอเพนซอร์สของ Android เวอร์ชันอัปสตรีมมี Gatekeeper Hardware Abstraction Layer (HAL) และ Trusty ซึ่งสามารถใช้เพื่อปฏิบัติตามข้อกำหนดนี้ได้
- [9.11/A-0-4] ต้องรองรับเอกสารรับรองคีย์ในกรณีที่คีย์การลงนามเพื่อรับรองได้รับการปกป้องโดยฮาร์ดแวร์ที่มีความปลอดภัย และการลงนามจะดำเนินการในฮาร์ดแวร์ที่มีความปลอดภัย คุณต้องแชร์คีย์การรับรองเพื่อลงนามในอุปกรณ์จํานวนมากพอเพื่อป้องกันไม่ให้มีการใช้คีย์เป็นตัวระบุอุปกรณ์ วิธีหนึ่งในการปฏิบัติตามข้อกำหนดนี้คือการแชร์คีย์การรับรองเดียวกัน เว้นแต่จะมีการผลิต SKU หนึ่งๆ อย่างน้อย 100,000 หน่วย หากผลิต SKU มากกว่า 100,000 หน่วย คุณอาจใช้คีย์อื่นสำหรับ 100,000 หน่วยแต่ละหน่วย
- [9/A-0-1] ต้องประกาศฟีเจอร์ "android.hardware.security.model.compatible"
โปรดทราบว่าหากมีการใช้งานอุปกรณ์ใน Android เวอร์ชันเก่าอยู่แล้ว อุปกรณ์ดังกล่าวจะได้รับการยกเว้นจากข้อกำหนดในการมีคีย์สโตร์ที่รองรับสภาพแวดล้อมการเรียกใช้แบบแยกและรองรับการรับรองคีย์ เว้นแต่จะมีการประกาศใช้ฟีเจอร์ android.hardware.fingerprint
ซึ่งต้องใช้คีย์สโตร์ที่รองรับสภาพแวดล้อมการเรียกใช้แบบแยก
การติดตั้งใช้งานอุปกรณ์ยานยนต์
- [9.14/A-0-1] ต้องควบคุมข้อความจากระบบย่อยของยานพาหนะเฟรมเวิร์ก Android เช่น รายการที่อนุญาตสำหรับประเภทข้อความและแหล่งที่มาของข้อความที่อนุญาต
- [9.14/A-0-2] ต้องเฝ้าระวังการโจมตีแบบการปฏิเสธการให้บริการจากเฟรมเวิร์ก Android หรือแอปของบุคคลที่สาม ซึ่งจะช่วยป้องกันซอฟต์แวร์ที่เป็นอันตรายจากการส่งข้อมูลจำนวนมากไปยังเครือข่ายของยานพาหนะ ซึ่งอาจทําให้ระบบย่อยของยานพาหนะทํางานผิดปกติ
2.5.6. ความเข้ากันได้ของเครื่องมือและตัวเลือกสำหรับนักพัฒนาแอป
การติดตั้งใช้งานอุปกรณ์ยานยนต์
- Perfetto
- [6.1/A-0-1] ต้องแสดง
/system/bin/perfetto
ไบนารีต่อผู้ใช้เชลล์ ซึ่ง cmdline เป็นไปตามเอกสารประกอบของ Perfetto - [6.1/A-0-2] ไฟล์ไบนารีของ Perfetto ต้องยอมรับการกำหนดค่า protobuf เป็นอินพุตที่เป็นไปตามสคีมาที่กำหนดไว้ในเอกสารประกอบของ Perfetto
- [6.1/A-0-3] ไฟล์ไบนารีของ Perfetto ต้องเขียนร่องรอย protobuf เป็นเอาต์พุตที่เป็นไปตามสคีมาที่กำหนดไว้ในเอกสารประกอบของ Perfetto
- [6.1/A-0-4] ต้องมีแหล่งข้อมูลอย่างน้อยตามที่อธิบายไว้ในเอกสารประกอบของ Perfetto ผ่านไฟล์ไบนารีของ Perfetto
- [6.1/A-0-1] ต้องแสดง
2.6 ข้อกำหนดสำหรับแท็บเล็ต
อุปกรณ์แท็บเล็ต Android หมายถึงการใช้งานอุปกรณ์ Android ที่โดยทั่วไปจะเป็นไปตามเกณฑ์ต่อไปนี้ทั้งหมด
- ใช้โดยจับด้วยมือทั้ง 2 ข้าง
- ไม่มีการกำหนดค่าแบบฝาพับหรือแบบแปลงร่าง
- การติดตั้งใช้งานแป้นพิมพ์จริงที่ใช้กับอุปกรณ์ที่เชื่อมต่อผ่านการเชื่อมต่อมาตรฐาน (เช่น USB, บลูทูธ)
- มีแหล่งจ่ายไฟที่ช่วยให้อุปกรณ์เคลื่อนที่ได้ เช่น แบตเตอรี่
- มีขนาดหน้าจอที่แสดงผลมากกว่า 7 นิ้วแต่น้อยกว่า 18 นิ้ว โดยวัดจากเส้นทแยงมุม
การติดตั้งใช้งานอุปกรณ์แท็บเล็ตมีข้อกำหนดคล้ายกับการติดตั้งใช้งานอุปกรณ์พกพา ข้อยกเว้นจะระบุด้วยเครื่องหมาย * ในส่วนนั้น และมีการบันทึกไว้เพื่อใช้อ้างอิงในส่วนนี้
2.6.1. ฮาร์ดแวร์
ไจโรสโคป
หากการติดตั้งใช้งานอุปกรณ์แท็บเล็ตมีไจโรสโคปแบบ 3 แกน อุปกรณ์จะมีลักษณะดังนี้
- [7.3.4/Tab-1-1] ต้องสามารถวัดการเปลี่ยนแปลงการวางแนวได้สูงสุด 1,000 องศาต่อวินาที
หน่วยความจำและพื้นที่เก็บข้อมูลขั้นต่ำ (ส่วนที่ 7.6.1)
ความหนาแน่นของหน้าจอที่ระบุไว้สำหรับหน้าจอขนาดเล็ก/ปกติในข้อกำหนดของอุปกรณ์พกพาจะไม่มีผลกับแท็บเล็ต
โหมดอุปกรณ์ต่อพ่วง USB (ส่วนที่ 7.7.1)
หากการติดตั้งใช้งานอุปกรณ์แท็บเล็ตมีพอร์ต USB ที่รองรับโหมดอุปกรณ์ต่อพ่วง อุปกรณ์จะมีลักษณะดังนี้
- [7.7.1/แท็บ] อาจใช้ API ของอุปกรณ์เสริมแบบเปิดของ Android (AOA)
โหมด Virtual Reality (ส่วนที่ 7.9.1)
ประสิทธิภาพสูงของ Virtual Reality (ส่วนที่ 7.9.2)
ข้อกำหนดของ Virtual Reality ไม่มีผลกับแท็บเล็ต
2.6.2. รูปแบบการรักษาความปลอดภัย
คีย์และข้อมูลเข้าสู่ระบบ (ส่วนที่ 9.11)
โปรดดูส่วนที่ [9.11]
หากการใช้งานอุปกรณ์แท็บเล็ตมีผู้ใช้หลายคนและไม่ประกาศ Flag ฟีเจอร์ android.hardware.telephony
ผู้ใช้เหล่านั้นจะทำสิ่งต่อไปนี้
- [9.5/T-1-1] ต้องรองรับโปรไฟล์ที่ถูกจำกัด ซึ่งเป็นฟีเจอร์ที่ช่วยให้เจ้าของอุปกรณ์จัดการผู้ใช้เพิ่มเติมและความสามารถของผู้ใช้เหล่านั้นในอุปกรณ์ได้ เมื่อใช้โปรไฟล์ที่จํากัด เจ้าของอุปกรณ์จะตั้งค่าสภาพแวดล้อมแยกต่างหากสําหรับผู้ใช้คนอื่นๆ ได้อย่างรวดเร็ว พร้อมทั้งจัดการข้อจํากัดที่ละเอียดยิ่งขึ้นในแอปที่ใช้ได้ภายในสภาพแวดล้อมเหล่านั้น
หากการติดตั้งใช้งานอุปกรณ์แท็บเล็ตมีผู้ใช้หลายคนและประกาศ Flag ฟีเจอร์ android.hardware.telephony
ผู้ใช้เหล่านั้นจะทำสิ่งต่อไปนี้ได้
- [9.5/T-2-1] ต้องไม่รองรับโปรไฟล์ที่จํากัด แต่ต้องสอดคล้องกับการใช้งานการควบคุมของ AOSP เพื่อเปิด /ปิดใช้ไม่ให้ผู้ใช้รายอื่นเข้าถึงการโทรด้วยเสียงและ SMS
2.6.2. ซอฟต์แวร์
- [3.2.3.1/Tab-0-1] ต้องโหลดแอปพลิเคชันหรือคอมโพเนนต์บริการอย่างน้อย 1 รายการล่วงหน้าด้วยตัวแฮนเดิล Intent สำหรับรูปแบบตัวกรอง Intent สาธารณะทั้งหมดที่กําหนดโดย Intent ของแอปพลิเคชันต่อไปนี้ที่แสดงไว้ที่นี่
3. ซอฟต์แวร์
3.1 ความเข้ากันได้ของ Managed API
สภาพแวดล้อมการเรียกใช้ไบต์โค้ด Dalvik ที่มีการจัดการเป็นแพลตฟอร์มหลักสําหรับแอปพลิเคชัน Android Application Programming Interface (API) ของ Android คือชุดอินเทอร์เฟซแพลตฟอร์ม Android ที่แสดงต่อแอปพลิเคชันที่ทำงานในสภาพแวดล้อมรันไทม์ที่มีการจัดการ
การติดตั้งใช้งานอุปกรณ์
[C-0-1] ต้องระบุการใช้งานที่สมบูรณ์ รวมถึงลักษณะการทำงานที่ระบุไว้ในเอกสารทั้งหมดของ API ที่ระบุไว้ในเอกสารซึ่ง Android SDK แสดง หรือ API ที่มีเครื่องหมาย "@SystemApi" ในซอร์สโค้ด Android ต้นทาง
[C-0-2] ต้องรองรับ/เก็บรักษาคลาส เมธอด และองค์ประกอบที่เกี่ยวข้องทั้งหมด ที่มีการทำเครื่องหมายโดยการกำกับเนื้อหา TestApi (@TestApi)
[C-0-3] ต้องไม่ละเว้น API ที่มีการจัดการ เปลี่ยนแปลงอินเทอร์เฟซหรือลายเซ็น API เบี่ยงเบนจากลักษณะการทำงานที่ระบุไว้ หรือรวมการดำเนินการที่ไม่มีผล เว้นแต่จะได้รับอนุญาตโดยเจาะจงจากคำจำกัดความความเข้ากันได้นี้
[C-0-4] ยังคงต้องแสดง API และทํางานอย่างสมเหตุสมผล แม้ว่าจะไม่ได้รวมฟีเจอร์ฮาร์ดแวร์บางอย่างที่ Android มี API ไว้ก็ตาม โปรดดูข้อกำหนดเฉพาะสำหรับสถานการณ์นี้ในส่วนที่ 7
[C-0-5] ต้องไม่อนุญาตให้แอปของบุคคลที่สามใช้อินเทอร์เฟซที่ไม่ใช่ SDK ซึ่งหมายถึงเมธอดและฟิลด์ในแพ็กเกจภาษา Java ที่อยู่ในเส้นทางการค้นหาของบูตใน AOSP และไม่เป็นส่วนหนึ่งของ SDK สาธารณะ ซึ่งรวมถึง API ที่มีคําอธิบายประกอบ
@hide
แต่ไม่มี@SystemAPI
ตามที่อธิบายไว้ในเอกสารประกอบ SDK และสมาชิกคลาสแบบส่วนตัวและแบบแพ็กเกจส่วนตัว[C-0-6] ต้องมาพร้อมกับอินเทอร์เฟซที่ไม่ใช่ SDK ทั้งหมดในรายการที่จำกัดเดียวกันกับที่ระบุผ่าน Flag ชั่วคราวและ Denylist ในเส้นทาง
prebuilts/runtime/appcompat/hiddenapi-flags.csv
สำหรับสาขาระดับ API ที่เหมาะสมใน AOSP[C-0-7] ต้องรองรับการกำหนดค่าที่ลงชื่อ กลไกการอัปเดตแบบไดนามิกเพื่อนำอินเทอร์เฟซที่ไม่ใช่ SDK ออกจากรายการที่จำกัด โดยการฝังการกำหนดค่าที่ลงชื่อใน APK โดยใช้คีย์สาธารณะที่มีอยู่ ใน AOSP
อย่างไรก็ตาม
- อาจเป็นไปได้ หากไม่มี API ที่ซ่อนอยู่หรือมีการใช้งาน API ที่ซ่อนอยู่แตกต่างกันในการติดตั้งใช้งานบนอุปกรณ์ ให้ย้าย API ที่ซ่อนอยู่ในรายการที่ปฏิเสธหรือยกเว้น API นั้นจากรายการที่จำกัดทั้งหมด
- พฤษภาคม หากไม่มี API ที่ซ่อนอยู่ใน AOSP ให้เพิ่ม API ที่ซ่อนลงในรายการที่จำกัด
3.1.1. ส่วนขยาย Android
Android รองรับการขยายแพลตฟอร์ม API ที่มีการจัดการของ API ระดับหนึ่งๆ ด้วยการอัปเดตเวอร์ชันส่วนขยายสำหรับ API ระดับนั้น android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel)
API จะแสดงเวอร์ชันส่วนขยายของ apiLevel
ที่ระบุ หากมีส่วนขยายสําหรับระดับ API นั้น
การติดตั้งใช้งานอุปกรณ์ Android
[C-0-1] ต้องโหลดใช้งาน AOSP ล่วงหน้าสำหรับทั้งไลบรารีที่แชร์
ExtShared
และบริการExtServices
ที่มีเวอร์ชันมากกว่าหรือเท่ากับเวอร์ชันขั้นต่ำที่อนุญาตในแต่ละระดับ API เช่น การใช้งานอุปกรณ์ Android 7.0 ที่ใช้ API ระดับ 24 ต้องมีเวอร์ชัน 1 เป็นอย่างน้อย[C-0-2] แสดงเฉพาะหมายเลขเวอร์ชันของส่วนขยายที่ถูกต้องซึ่ง AOSP กำหนดไว้
[C-0-3] ต้องรองรับ API ทั้งหมดที่กําหนดโดยเวอร์ชันส่วนขยายที่
android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel)
แสดงผลในลักษณะเดียวกับที่รองรับ API ที่มีการจัดการอื่นๆ โดยเป็นไปตามข้อกําหนดในส่วนที่ 3.1
3.1.2. ไลบรารี Android
เนื่องจากการเลิกใช้งานไคลเอ็นต์ Apache HTTP การติดตั้งใช้งานอุปกรณ์จึงมีการเปลี่ยนแปลงดังนี้
- [C-0-1] ต้องไม่วางไลบรารี
org.apache.http.legacy
ในไฟล์ BOOTCLASSPATH - [C-0-2] ต้องเพิ่มไลบรารี
org.apache.http.legacy
ลงในแอปพลิเคชัน เส้นทางเท่านั้นเมื่อแอปเป็นไปตามเงื่อนไขข้อใดข้อหนึ่งต่อไปนี้- กำหนดเป้าหมายเป็น API ระดับ 28 หรือต่ำกว่า
- ประกาศในไฟล์ Manifest ว่าต้องใช้ไลบรารีโดยการตั้งค่าแอตทริบิวต์
android:name
ของ<uses-library>
เป็นorg.apache.http.legacy
การติดตั้งใช้งาน AOSP เป็นไปตามข้อกำหนดเหล่านี้
3.2 ความเข้ากันได้แบบ Soft API
นอกจาก API ที่มีการจัดการจากส่วนที่ 3.1 แล้ว Android ยังมี API "แบบไม่บังคับ" ที่สำคัญซึ่งทำงานเฉพาะรันไทม์ในรูปแบบของสิ่งต่างๆ เช่น Intent, สิทธิ์ และลักษณะที่คล้ายกันของแอปพลิเคชัน Android ซึ่งไม่สามารถบังคับใช้ขณะคอมไพล์แอปพลิเคชันได้
3.2.1. สิทธิ์
- [C-0-1] ผู้ติดตั้งใช้งานอุปกรณ์ต้องรองรับและบังคับใช้ค่าคงที่ของสิทธิ์ทั้งหมดตามที่ระบุไว้ในหน้าอ้างอิงสิทธิ์ โปรดทราบว่าส่วนที่ 9 แสดงข้อกำหนดเพิ่มเติมที่เกี่ยวข้องกับรูปแบบความปลอดภัยของ Android
3.2.2. พารามิเตอร์การสร้าง
API ของ Android มีค่าคงที่หลายรายการในคลาส android.os.Build ที่มีไว้เพื่ออธิบายอุปกรณ์ปัจจุบัน
- [C-0-1] ตารางด้านล่างมีข้อจำกัดเพิ่มเติมเกี่ยวกับรูปแบบของค่าเหล่านี้ที่การติดตั้งใช้งานอุปกรณ์ต้องเป็นไปตามข้อกำหนด เพื่อให้ค่าต่างๆ ที่สอดคล้องกันและสื่อความหมายได้เหมือนกันในการติดตั้งใช้งานอุปกรณ์
พารามิเตอร์ | รายละเอียด |
---|---|
VERSION.RELEASE | เวอร์ชันของระบบ Android ที่ใช้งานอยู่ในปัจจุบันในรูปแบบที่มนุษย์อ่านได้ ช่องนี้ต้องมีค่าสตริงอย่างใดอย่างหนึ่งที่ระบุไว้ในสตริงเวอร์ชันที่อนุญาตสำหรับ Android 12 |
VERSION.SDK | เวอร์ชันของระบบ Android ที่ใช้งานอยู่ในปัจจุบันในรูปแบบที่โค้ดแอปพลิเคชันของบุคคลที่สามเข้าถึงได้ สำหรับ Android 12 ช่องนี้ต้องมีค่าจำนวนเต็ม 12_INT |
VERSION.SDK_INT | เวอร์ชันของระบบ Android ที่ใช้งานอยู่ในปัจจุบันในรูปแบบที่โค้ดแอปพลิเคชันของบุคคลที่สามเข้าถึงได้ สำหรับ Android 12 ช่องนี้ต้องมีค่าจำนวนเต็ม 12_INT |
VERSION.INCREMENTAL | ค่าที่ผู้ติดตั้งใช้งานอุปกรณ์เลือกเพื่อระบุบิลด์ที่เฉพาะเจาะจงของระบบ Android ที่ใช้งานอยู่ในปัจจุบันในรูปแบบที่มนุษย์อ่านได้ ห้ามนำค่านี้ไปใช้กับบิลด์อื่นที่พร้อมให้บริการแก่ผู้ใช้ปลายทาง การใช้งานทั่วไปของช่องนี้คือเพื่อระบุหมายเลขบิลด์หรือตัวระบุการเปลี่ยนแปลงในระบบควบคุมแหล่งที่มาที่ใช้สร้างบิลด์ ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII 7 บิตที่พิมพ์ได้และตรงกับนิพจน์ทั่วไป "^[^ :\/~]+$" |
กระดาน | ค่าที่นักติดตั้งใช้งานอุปกรณ์เลือกเพื่อระบุฮาร์ดแวร์ภายในที่เฉพาะเจาะจงซึ่งอุปกรณ์ใช้ในรูปแบบที่มนุษย์อ่านได้ การใช้ช่องนี้ที่เป็นไปได้คือการระบุการแก้ไขที่เฉพาะเจาะจงของแผงวงจรที่จ่ายไฟให้กับอุปกรณ์ ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII 7 บิตได้ และตรงกับนิพจน์ทั่วไป "^[a-zA-Z0-9_-]+$" |
แบรนด์ | ค่าที่แสดงถึงชื่อแบรนด์ที่เชื่อมโยงกับอุปกรณ์ตามที่ผู้ใช้ปลายทางทราบ ต้องอยู่ในรูปแบบที่มนุษย์อ่านได้ และควรแสดงถึงผู้ผลิตอุปกรณ์หรือแบรนด์ของบริษัทที่จำหน่ายอุปกรณ์ ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII 7 บิตได้และตรงกับนิพจน์ทั่วไป "^[a-zA-Z0-9_-]+$" |
SUPPORTED_ABIS | ชื่อชุดคำสั่ง (ประเภท CPU + รูปแบบ ABI) ของโค้ดเนทีฟ โปรดดูส่วนที่ 3.3 ความเข้ากันได้ของ Native API |
SUPPORTED_32_BIT_ABIS | ชื่อชุดคำสั่ง (ประเภท CPU + รูปแบบ ABI) ของโค้ดเนทีฟ โปรดดูส่วนที่ 3.3 ความเข้ากันได้ของ Native API |
SUPPORTED_64_BIT_ABIS | ชื่อชุดคำสั่งที่ 2 (ประเภท CPU + รูปแบบ ABI) ของโค้ดเนทีฟ โปรดดูส่วนที่ 3.3 ความเข้ากันได้ของ API เดิม |
CPU_ABI | ชื่อชุดคำสั่ง (ประเภท CPU + รูปแบบ ABI) ของโค้ดเนทีฟ โปรดดูส่วนที่ 3.3 ความเข้ากันได้ของ Native API |
CPU_ABI2 | ชื่อชุดคำสั่งที่ 2 (ประเภท CPU + รูปแบบ ABI) ของโค้ดเนทีฟ โปรดดูส่วนที่ 3.3 ความเข้ากันได้ของ API เดิม |
อุปกรณ์ | ค่าที่ผู้ติดตั้งใช้งานอุปกรณ์เลือกซึ่งมีชื่อการพัฒนาหรือชื่อโค้ดที่ระบุการกำหนดค่าของฟีเจอร์ฮาร์ดแวร์และการออกแบบอุตสาหกรรมของอุปกรณ์ ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII 7 บิตได้และตรงกับนิพจน์ทั่วไป "^[a-zA-Z0-9_-]+$" ชื่ออุปกรณ์นี้ต้องไม่เปลี่ยนแปลงตลอดอายุการใช้งานของผลิตภัณฑ์ |
FINGERPRINT | สตริงที่ระบุบิลด์นี้โดยไม่ซ้ำกัน ควรเป็นชื่อที่มนุษย์อ่านได้ โดยต้องเป็นไปตามเทมเพลตนี้
$(BRAND)/$(PRODUCT)/ เช่น 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 หรือสตริงว่าง ("") ช่องนี้ต้องไม่เปลี่ยนแปลงตลอดอายุการใช้งานของผลิตภัณฑ์ |
SOC_MANUFACTURER | ชื่อทางการค้าของผู้ผลิตระบบวงจรรวมบนชิป (SoC) หลักที่ใช้ในผลิตภัณฑ์ อุปกรณ์ที่มีผู้ผลิต SoC เดียวกันควรใช้ค่าคงที่เดียวกัน โปรดสอบถามผู้ผลิต SOC เพื่อขอค่าคงที่ที่ถูกต้อง ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII 7 บิตได้ ต้องตรงกับนิพจน์ทั่วไป "^([0-9A-Za-z ]+)" ต้องไม่ขึ้นต้นหรือลงท้ายด้วยเว้นวรรค และต้องไม่เท่ากับ "unknown" ช่องนี้ต้องไม่เปลี่ยนแปลงตลอดอายุการใช้งานของผลิตภัณฑ์ |
SOC_MODEL | ชื่อรุ่นของระบบวงจรรวมบนชิป (SoC) หลักที่ใช้ในผลิตภัณฑ์ อุปกรณ์ที่มีรุ่น SOC เดียวกันควรใช้ค่าคงที่เดียวกัน โปรดสอบถามผู้ผลิต SOC เพื่อขอค่าคงที่ที่ถูกต้อง ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII 7 บิตและตรงกับนิพจน์ทั่วไป "^([0-9A-Za-z ._/+-]+)$" ต้องไม่ขึ้นต้นหรือลงท้ายด้วยเว้นวรรค และต้องไม่เท่ากับ "unknown" ช่องนี้ต้องไม่เปลี่ยนแปลงตลอดอายุการใช้งานของผลิตภัณฑ์ |
MODEL | ค่าที่นักติดตั้งใช้งานอุปกรณ์เลือกซึ่งมีชื่อของอุปกรณ์ตามที่ผู้ใช้ปลายทางทราบ ซึ่งควรเป็นชื่อเดียวกับที่ใช้ในการทําการตลาดและขายอุปกรณ์แก่ผู้ใช้ ไม่มีข้อกำหนดเกี่ยวกับรูปแบบที่เจาะจงของช่องนี้ ยกเว้นว่าต้องไม่มีค่า Null หรือสตริงว่าง ("") ช่องนี้ต้องไม่เปลี่ยนแปลงตลอดอายุการใช้งานของผลิตภัณฑ์ |
ผลิตภัณฑ์ | ค่าที่ผู้ติดตั้งใช้งานอุปกรณ์เลือกซึ่งมีชื่อการพัฒนาหรือชื่อโค้ดของผลิตภัณฑ์ที่เฉพาะเจาะจง (SKU) และต้องไม่ซ้ำกันภายในแบรนด์เดียวกัน ต้องอ่านออกได้ แต่ไม่จำเป็นต้องมีไว้ให้ผู้ใช้ปลายทางดู ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII 7 บิตและตรงกับนิพจน์ทั่วไป "^[a-zA-Z0-9_-]+$" ชื่อผลิตภัณฑ์นี้ต้องไม่เปลี่ยนแปลงตลอดอายุการใช้งานของผลิตภัณฑ์ |
ODM_SKU | ค่าที่ไม่บังคับซึ่งผู้ติดตั้งใช้งานอุปกรณ์เลือก โดยมี SKU (Stock Keeping Unit) ที่ใช้ติดตามการกำหนดค่าที่เฉพาะเจาะจงของอุปกรณ์ เช่น อุปกรณ์ต่อพ่วงที่รวมอยู่กับอุปกรณ์เมื่อขาย
ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII 7 บิตและตรงกับนิพจน์ทั่วไป ^([0-9A-Za-z.,_-]+)$ |
SERIAL | ต้องแสดงผลเป็น "UNKNOWN" |
แท็ก | รายการแท็กที่คั่นด้วยคอมมาซึ่งผู้ติดตั้งใช้งานอุปกรณ์เลือกไว้เพื่อแยกความแตกต่างของบิลด์เพิ่มเติม แท็กต้องเข้ารหัสเป็น ASCII 7 บิตได้ และตรงกับนิพจน์ทั่วไป "^[a-zA-Z0-9._-]+" และต้องมีค่าใดค่าหนึ่งซึ่งสอดคล้องกับการกำหนดค่าการรับรองแพลตฟอร์ม Android ทั่วไป 3 รายการ ได้แก่ release-keys, dev-keys และ test-keys |
เวลา | ค่าที่แสดงการประทับเวลาที่บิลด์เกิดขึ้น |
ประเภท | ค่าที่ผู้ติดตั้งใช้งานอุปกรณ์เลือกซึ่งระบุการกำหนดค่ารันไทม์ของบิลด์ ช่องนี้ต้องมีค่าอย่างใดอย่างหนึ่งซึ่งสอดคล้องกับการกำหนดค่ารันไทม์ Android ทั่วไป 3 รายการ ได้แก่ user, userdebug หรือ eng |
ผู้ใช้ | ชื่อหรือรหัสผู้ใช้ของผู้ใช้ (หรือผู้ใช้อัตโนมัติ) ที่สร้างบิลด์ ไม่มีข้อกำหนดเกี่ยวกับรูปแบบที่เจาะจงของฟิลด์นี้ ยกเว้นว่าต้องไม่มีค่า Null หรือสตริงว่าง ("") |
SECURITY_PATCH | ค่าที่ระบุระดับแพตช์ความปลอดภัยของบิลด์ และต้องระบุว่าบิลด์ไม่มีช่องโหว่ใดๆ เกี่ยวกับปัญหาที่อธิบายไว้ในประกาศข่าวสารด้านความปลอดภัยของ Android สำหรับสาธารณะ โดยต้องอยู่ในรูปแบบ [YYYY-MM-DD] ซึ่งตรงกับสตริงที่กําหนดไว้ในประกาศข่าวสารด้านความปลอดภัยของ Android สําหรับสาธารณะหรือใน คําแนะนําด้านความปลอดภัยของ Android เช่น "2015-11-01" |
BASE_OS | ค่าที่แสดงพารามิเตอร์ FINGERPRINT ของบิวด์ที่เหมือนกันกับบิวด์นี้ ยกเว้นแพตช์ที่ระบุไว้ในกระดานข่าวสารความปลอดภัยสาธารณะของ Android และต้องรายงานค่าที่ถูกต้อง และหากไม่มีบิลด์ดังกล่าว ให้รายงานสตริงว่าง ("") |
BOOTLOADER | ค่าที่นักติดตั้งใช้งานอุปกรณ์เลือกเพื่อระบุเวอร์ชัน Bootloader ภายในที่เฉพาะเจาะจงซึ่งใช้ในอุปกรณ์ในรูปแบบที่มนุษย์อ่านได้ ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII 7 บิตได้และตรงกับนิพจน์ทั่วไป "^[a-zA-Z0-9._-]+$" |
getRadioVersion() | ต้อง (เป็นหรือแสดงผล) ค่าที่นักติดตั้งใช้งานอุปกรณ์เลือกไว้ ซึ่งระบุเวอร์ชันวิทยุ/โมเด็มภายในที่เฉพาะเจาะจงซึ่งใช้ในอุปกรณ์ในรูปแบบที่มนุษย์อ่านได้ หากอุปกรณ์ไม่มีวิทยุ/โมเด็มภายใน จะต้องแสดงผลเป็น NULL ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII 7 บิตและตรงกับนิพจน์ทั่วไป "^[a-zA-Z0-9._-,]+$" |
getSerial() | ต้องเป็น (หรือแสดง) หมายเลขซีเรียลของฮาร์ดแวร์ ซึ่งต้องพร้อมใช้งานและไม่ซ้ำกันในอุปกรณ์ที่มีรุ่นและผู้ผลิตเดียวกัน ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII 7 บิตได้และตรงกับนิพจน์ทั่วไป "^[a-zA-Z0-9._-,]+$" |
3.2.3. ความเข้ากันได้ของ Intent
3.2.3.1. Intent ทั่วไปของแอปพลิเคชัน
Intent ของ Android ช่วยให้คอมโพเนนต์แอปพลิเคชันขอฟังก์ชันการทำงานจากคอมโพเนนต์ Android อื่นๆ ได้ โปรเจ็กต์ Upstream ของ Android มีรายการแอปพลิเคชันที่ใช้รูปแบบ Intent หลายรูปแบบเพื่อดำเนินการทั่วไป
การติดตั้งใช้งานอุปกรณ์
- [C-SR-1] ขอแนะนำอย่างยิ่งให้โหลดแอปพลิเคชันหรือคอมโพเนนต์บริการอย่างน้อย 1 รายการล่วงหน้าด้วยตัวแฮนเดิล Intent สำหรับรูปแบบตัวกรอง Intent สาธารณะทั้งหมดที่กําหนดโดย Intent ของแอปพลิเคชันต่อไปนี้ที่แสดงอยู่ที่นี่ และให้บริการตามคําเรียกร้องของนักพัฒนาแอปสําหรับ Intent ของแอปพลิเคชันทั่วไปเหล่านี้ตามที่อธิบายไว้ใน SDK
โปรดดูส่วนที่ 2 สำหรับ Intent ของแอปพลิเคชันที่จำเป็นสำหรับอุปกรณ์แต่ละประเภท
3.2.3.2. การแก้ไข Intent
[C-0-1] เนื่องจาก Android เป็นแพลตฟอร์มที่ขยายได้ การติดตั้งใช้งานอุปกรณ์ต้องอนุญาตให้แอปพลิเคชันของบุคคลที่สามลบล้างรูปแบบ Intent แต่ละรูปแบบที่อ้างอิงในส่วนที่ 3.2.3.1 ยกเว้นการตั้งค่า การใช้งานโอเพนซอร์สของ Android เวอร์ชันที่พัฒนาขึ้นต้นอนุญาตให้ดำเนินการนี้โดยค่าเริ่มต้น
[C-0-2] ผู้ติดตั้งใช้งานอุปกรณ์ต้องไม่แนบสิทธิ์พิเศษไว้กับการใช้รูปแบบ Intent เหล่านี้ของแอปพลิเคชันระบบ หรือป้องกันไม่ให้แอปพลิเคชันของบุคคลที่สามเชื่อมโยงและควบคุมรูปแบบเหล่านี้ ข้อห้ามนี้รวมถึงแต่ไม่จำกัดเพียงการปิดใช้อินเทอร์เฟซผู้ใช้ "เครื่องมือเลือก" ที่อนุญาตให้ผู้ใช้เลือกระหว่างแอปพลิเคชันหลายรายการที่จัดการรูปแบบ Intent เดียวกันทั้งหมด
[C-0-3] การติดตั้งใช้งานอุปกรณ์ต้องมีอินเทอร์เฟซผู้ใช้เพื่อให้ผู้ใช้แก้ไขกิจกรรมเริ่มต้นสำหรับ Intent ได้
อย่างไรก็ตาม การติดตั้งใช้งานอุปกรณ์อาจระบุกิจกรรมเริ่มต้นสำหรับรูปแบบ URI ที่เฉพาะเจาะจง (เช่น http://play.google.com) เมื่อกิจกรรมเริ่มต้นระบุแอตทริบิวต์ที่เฉพาะเจาะจงมากขึ้นสำหรับ URI ของข้อมูล ตัวอย่างเช่น รูปแบบตัวกรอง Intent ที่ระบุ URI ข้อมูล "http://www.android.com" จะเฉพาะเจาะจงกว่ารูปแบบ Intent หลักของเบราว์เซอร์สําหรับ "http://"
นอกจากนี้ Android ยังมีกลไกสำหรับแอปของบุคคลที่สามในการประกาศลักษณะการลิงก์แอปเริ่มต้นที่เชื่อถือได้สำหรับ Intent ของ URI ของเว็บบางประเภท เมื่อมีการกําหนดประกาศที่เชื่อถือได้ดังกล่าวในรูปแบบตัวกรอง Intent ของแอป การใช้งานอุปกรณ์จะมีลักษณะดังนี้
- [C-0-4] ต้องพยายามตรวจสอบตัวกรอง Intent โดยทำตามขั้นตอนการตรวจสอบที่ระบุไว้ในข้อกำหนดของลิงก์เนื้อหาดิจิทัลตามที่ Package Manager นำมาใช้ในโปรเจ็กต์โอเพนซอร์ส Android ต้นทาง
- [C-0-5] ต้องพยายามตรวจสอบตัวกรอง Intent ในระหว่างการติดตั้งแอปพลิเคชันและตั้งค่าตัวกรอง Intent ของ URI ที่ตรวจสอบเรียบร้อยแล้วทั้งหมดเป็นตัวจัดการแอปเริ่มต้นสำหรับ URI ของแอป
- อาจตั้งค่าตัวกรอง Intent ของ URI ที่เฉพาะเจาะจงเป็นตัวจัดการแอปเริ่มต้นสำหรับ URI ของแอปนั้นๆ หากได้รับการยืนยันเรียบร้อยแล้ว แต่ตัวกรอง URI อื่นๆ ที่เป็นไปได้ไม่ได้รับการยืนยัน หากการใช้งานอุปกรณ์ทําเช่นนี้ อุปกรณ์ต้องระบุการลบล้างรูปแบบต่อ URI ที่เหมาะสมสําหรับผู้ใช้ในเมนูการตั้งค่า
- ต้องให้การควบคุม App Link ต่อแอปแก่ผู้ใช้ในการตั้งค่า ดังนี้
- [C-0-6] ผู้ใช้ต้องสามารถลบล้างลักษณะการทํางานของลิงก์แอปเริ่มต้นโดยรวมเพื่อให้แอปเปิดเสมอ ถามเสมอ หรือไม่เคยเปิด ซึ่งมีผลกับตัวกรอง Intent ของ URI ทั้งหมดที่เป็นไปได้อย่างเท่าเทียมกัน
- [C-0-7] ผู้ใช้ต้องดูรายการตัวกรองความตั้งใจของ URI ที่เป็นไปได้ได้
- การติดตั้งใช้งานอุปกรณ์อาจช่วยให้ผู้ใช้สามารถลบล้างตัวกรอง Intent ของ URI ที่เป็นไปได้ซึ่งได้รับการยืนยันเรียบร้อยแล้ว โดยอิงตามตัวกรอง Intent แต่ละรายการ
- [C-0-8] การติดตั้งใช้งานอุปกรณ์ต้องให้สิทธิ์ผู้ใช้ในการดูและลบล้างตัวกรอง Intent ของ URI ที่เป็นผู้สมัครบางรายการ หากการติดตั้งใช้งานอุปกรณ์ทําให้ตัวกรอง Intent ของ URI ที่เป็นผู้สมัครบางรายการยืนยันสําเร็จ ขณะที่ตัวกรองอื่นๆ ยืนยันไม่สําเร็จ
3.2.3.3. เนมสเปซของ Intent
- [C-0-1] การติดตั้งใช้งานอุปกรณ์ต้องไม่มีคอมโพเนนต์ Android ใดๆ ที่รองรับรูปแบบ Intent ใหม่หรือ Intent แบบออกอากาศโดยใช้สตริงคีย์ ACTION, CATEGORY หรืออื่นๆ ในเนมสเปซ android.* หรือ com.android.*
- [C-0-2] ผู้ติดตั้งใช้งานอุปกรณ์ต้องไม่รวมคอมโพเนนต์ Android ใดๆ ที่รองรับรูปแบบ Intent ใหม่หรือ Intent แบบออกอากาศโดยใช้สตริงคีย์ ACTION, CATEGORY หรืออื่นๆ ในพื้นที่แพ็กเกจขององค์กรอื่น
- [C-0-3] ผู้ติดตั้งใช้งานอุปกรณ์ต้องไม่แก้ไขหรือขยายรูปแบบ Intent ที่ระบุไว้ในส่วนที่ 3.2.3.1
- การติดตั้งใช้งานอุปกรณ์อาจรวมถึงรูปแบบ Intent โดยใช้เนมสเปซที่เชื่อมโยงกับองค์กรของตนเองอย่างชัดเจน ข้อห้ามนี้คล้ายกับข้อห้ามที่ระบุไว้สำหรับชั้นเรียนภาษา Java ในส่วนที่ 3.6
3.2.3.4. เจตนาการออกอากาศ
แอปพลิเคชันของบุคคลที่สามอาศัยแพลตฟอร์มนี้เพื่อเผยแพร่ Intent บางรายการเพื่อแจ้งให้ทราบถึงการเปลี่ยนแปลงในสภาพแวดล้อมของฮาร์ดแวร์หรือซอฟต์แวร์
การติดตั้งใช้งานอุปกรณ์
- [C-0-1] ต้องออกอากาศ Intent การออกอากาศสาธารณะที่ระบุไว้ที่นี่เพื่อตอบสนองต่อเหตุการณ์ของระบบที่เหมาะสมตามที่อธิบายไว้ในเอกสารประกอบ SDK โปรดทราบว่าข้อกำหนดนี้ไม่ได้ขัดแย้งกับส่วนที่ 3.5 เนื่องจากข้อจำกัดสำหรับแอปพลิเคชันเบื้องหลังมีอธิบายไว้ในเอกสารประกอบของ SDK ด้วย นอกจากนี้ เจตนาการออกอากาศบางอย่างยังขึ้นอยู่กับการรองรับฮาร์ดแวร์ด้วย หากอุปกรณ์รองรับฮาร์ดแวร์ที่จำเป็น อุปกรณ์จะต้องออกอากาศเจตนาและแสดงลักษณะการทำงานให้สอดคล้องกับเอกสารประกอบ SDK
3.2.3.5. Intent ของแอปพลิเคชันแบบมีเงื่อนไข
Android มีการตั้งค่าที่ช่วยให้ผู้ใช้เลือกแอปพลิเคชันเริ่มต้นได้ง่ายๆ เช่น สําหรับหน้าจอหลักหรือ SMS
การติดตั้งใช้งานอุปกรณ์ต้องระบุเมนูการตั้งค่าที่คล้ายกันและเข้ากันได้กับรูปแบบตัวกรอง Intent และเมธอด API ที่อธิบายไว้ในเอกสารประกอบ SDK ดังต่อไปนี้
หากการติดตั้งใช้งานอุปกรณ์รายงาน android.software.home_screen
อุปกรณ์จะมีลักษณะดังนี้
- [C-1-1] ต้องปฏิบัติตามความตั้งใจของ
android.settings.HOME_SETTINGS
ที่แสดงเมนูการตั้งค่าแอปเริ่มต้นสำหรับหน้าจอหลัก
หากการติดตั้งใช้งานอุปกรณ์รายงาน android.hardware.telephony
อุปกรณ์จะมีลักษณะดังนี้
[C-2-1] ต้องมีเมนูการตั้งค่าที่จะเรียกใช้ Intent
android.provider.Telephony.ACTION_CHANGE_DEFAULT
เพื่อแสดงกล่องโต้ตอบเพื่อเปลี่ยนแอปพลิเคชัน SMS เริ่มต้น[C-2-2] ต้องปฏิบัติตามความตั้งใจของ
android.telecom.action.CHANGE_DEFAULT_DIALER
ที่แสดงกล่องโต้ตอบเพื่อให้ผู้ใช้เปลี่ยนแอปพลิเคชันโทรศัพท์เริ่มต้นได้- ต้องใช้ UI ของแอปโทรศัพท์เริ่มต้นที่ผู้ใช้เลือกสำหรับการโทรเข้าและโทรออก ยกเว้นการโทรฉุกเฉินซึ่งจะใช้แอปโทรศัพท์ที่ติดตั้งมาล่วงหน้า
[C-2-3] ต้องปฏิบัติตามเจตนาของ android.telecom.action.CHANGE_PHONE_ACCOUNTS เพื่อมอบโอกาสให้ผู้ใช้กำหนดค่า
ConnectionServices
ที่เชื่อมโยงกับPhoneAccounts
รวมถึง PhoneAccount เริ่มต้นที่ผู้ให้บริการโทรคมนาคมจะใช้โทรออก การติดตั้งใช้งาน AOSP เป็นไปตามข้อกำหนดนี้ด้วยการแสดงเมนู "ตัวเลือกบัญชีการโทร" ในเมนูการตั้งค่า "การโทร"[C-2-4] ต้องอนุญาต
android.telecom.CallRedirectionService
สําหรับแอปที่มีบทบาทandroid.app.role.CALL_REDIRECTION
[C-2-5] ต้องให้ทางเลือกแก่ผู้ใช้ในการเลือกแอปที่มีบทบาท
android.app.role.CALL_REDIRECTION
[C-2-6] ต้องปฏิบัติตาม Intent android.intent.action.SENDTO และ android.intent.action.VIEW รวมถึงระบุกิจกรรมเพื่อส่ง/แสดงข้อความ SMS
[C-SR-1] ขอแนะนำอย่างยิ่งให้รองรับ Intent android.intent.action.ANSWER, android.intent.action.CALL, android.intent.action.CALL_BUTTON, android.intent.action.VIEW & android.intent.action.DIAL ด้วยแอปพลิเคชันโทรศัพท์ที่โหลดไว้ล่วงหน้าซึ่งจัดการ Intent เหล่านี้ได้ และให้บริการตามที่อธิบายไว้ใน SDK
หากการติดตั้งใช้งานอุปกรณ์รายงาน android.hardware.nfc.hce
อุปกรณ์จะมีลักษณะดังนี้
- [C-3-1] ต้องปฏิบัติตามความตั้งใจของ android.settings.NFC_PAYMENT_SETTINGS เพื่อแสดงเมนูการตั้งค่าแอปเริ่มต้นสำหรับการชำระเงินแบบไม่ต้องสัมผัส
- [C-3-2] ต้องปฏิบัติตาม Intent android.nfc.cardemulation.action.ACTION_CHANGE_DEFAULT เพื่อแสดงกิจกรรมที่เปิดกล่องโต้ตอบเพื่อขอให้ผู้ใช้เปลี่ยนบริการจำลองบัตรเริ่มต้นสำหรับบางหมวดหมู่ตามที่อธิบายไว้ใน SDK
หากการติดตั้งใช้งานอุปกรณ์รายงาน android.hardware.nfc
อุปกรณ์จะมีลักษณะดังนี้
- [C-4-1] ต้องปฏิบัติตาม Intent เหล่านี้ android.nfc.action.NDEF_DISCOVERED, android.nfc.action.TAG_DISCOVERED & android.nfc.action.TECH_DISCOVERED เพื่อแสดงกิจกรรมที่ตรงกับความต้องการของนักพัฒนาแอปสำหรับ Intent เหล่านี้ตามที่อธิบายไว้ใน SDK
หากการติดตั้งใช้งานอุปกรณ์รายงาน android.hardware.bluetooth
อุปกรณ์จะมีลักษณะดังนี้
- [C-5-1] ต้องปฏิบัติตาม Intent ‘android.bluetooth.adapter.action.REQUEST_ENABLE’ และแสดงกิจกรรมของระบบเพื่อให้ผู้ใช้เปิดบลูทูธได้
- [C-5-2] ต้องปฏิบัติตาม Intent "android.bluetooth.adapter.action.REQUEST_DISCOVERABLE" และแสดงกิจกรรมของระบบที่ขอโหมดที่ค้นพบได้
หากการติดตั้งใช้งานอุปกรณ์รองรับฟีเจอร์ DND อุปกรณ์จะดำเนินการต่อไปนี้
- [C-6-1] ต้องใช้กิจกรรมที่จะตอบสนองต่อ Intent
ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS
ซึ่งสําหรับการใช้งานที่มี UI_MODE_TYPE_NORMAL ต้องเป็นกิจกรรมที่ผู้ใช้สามารถให้สิทธิ์หรือปฏิเสธการเข้าถึงการกําหนดค่านโยบาย DND แก่แอปได้
หากการติดตั้งใช้งานอุปกรณ์อนุญาตให้ผู้ใช้ใช้วิธีการป้อนข้อมูลของบุคคลที่สามในอุปกรณ์ ผู้ใช้จะทำสิ่งต่อไปนี้ได้
- [C-7-1] ต้องจัดให้มีกลไกที่ผู้ใช้เข้าถึงได้เพื่อเพิ่มและกําหนดค่าวิธีการป้อนข้อมูลของบุคคลที่สามเพื่อตอบสนอง
android.settings.INPUT_METHOD_SETTINGS
ความตั้งใจ
หากการติดตั้งใช้งานอุปกรณ์รองรับบริการการช่วยเหลือพิเศษของบุคคลที่สาม อุปกรณ์จะมีลักษณะดังนี้
- [C-8-1] ต้องปฏิบัติตามความตั้งใจของ
android.settings.ACCESSIBILITY_SETTINGS
ที่จะมีกลไกที่ผู้ใช้เข้าถึงได้เพื่อเปิดและปิดใช้บริการการช่วยเหลือพิเศษของบุคคลที่สามควบคู่ไปกับบริการการช่วยเหลือพิเศษที่โหลดไว้ล่วงหน้า
หากการติดตั้งใช้งานอุปกรณ์รองรับ Wi-Fi Easy Connect และแสดงฟังก์ชันการทำงานแก่แอปของบุคคลที่สาม อุปกรณ์จะต้องมีคุณสมบัติดังนี้
- [C-9-1] ต้องใช้ Settings#ACTION_PROCESS_WIFI_EASY_CONNECT_URI Intent API ตามที่อธิบายไว้ในเอกสารประกอบ SDK
หากการติดตั้งใช้งานอุปกรณ์มีโหมดประหยัดอินเทอร์เน็ต อุปกรณ์จะดำเนินการต่อไปนี้
- [C-10-1] ต้องมีอินเทอร์เฟซผู้ใช้ในการตั้งค่าที่จัดการความตั้งใจ
Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS
ซึ่งช่วยให้ผู้ใช้เพิ่มหรือนำแอปพลิเคชันออกจากรายการที่อนุญาตได้
หากการติดตั้งใช้งานอุปกรณ์ไม่มีโหมดประหยัดอินเทอร์เน็ต อุปกรณ์จะดำเนินการดังนี้
- [C-11-1] ต้องมีกิจกรรมที่จัดการกับ Intent
Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS
แต่อาจใช้แบบไม่ดำเนินการก็ได้
หากการติดตั้งใช้งานอุปกรณ์ประกาศว่ารองรับกล้องผ่าน android.hardware.camera.any
อุปกรณ์เหล่านั้นจะมีลักษณะดังนี้
- [C-12-3] ต้องปฏิบัติตามข้อกำหนดในการอนุญาตให้แอปพลิเคชัน Android ที่ติดตั้งไว้ล่วงหน้าเท่านั้นที่จัดการ Intent ต่อไปนี้ได้
MediaStore.ACTION_IMAGE_CAPTURE
,MediaStore.ACTION_IMAGE_CAPTURE_SECURE
และMediaStore.ACTION_VIDEO_CAPTURE
ตามที่อธิบายไว้ในเอกสาร SDK
หากการติดตั้งใช้งานอุปกรณ์รายงาน android.software.device_admin
อุปกรณ์จะมีลักษณะดังนี้
[C-13-1] ต้องเป็นไปตามความตั้งใจ
android.app.action.ADD_DEVICE_ADMIN
ในการเรียกใช้ UI เพื่อนำผู้ใช้ไปยังการเพิ่มผู้ดูแลระบบอุปกรณ์ในระบบ (หรืออนุญาตให้ผู้ใช้ปฏิเสธ)[C-13-2] ต้องปฏิบัติตาม Intent android.app.action.PROVISION_MANAGED_PROFILE, android.app.action.SET_NEW_PARENT_PROFILE_PASSWORD, android.app.action.SET_NEW_PASSWORD & android.app.action.START_ENCRYPTION และมีกิจกรรมเพื่อดำเนินการตาม Intent เหล่านี้ตามที่อธิบายไว้ใน SDK ที่นี่
หากการติดตั้งใช้งานอุปกรณ์ประกาศ Flag ฟีเจอร์ android.software.autofill
ระบบจะดำเนินการดังนี้
- [C-14-1] ต้องใช้งาน API ของ
AutofillService
และAutofillManager
อย่างเต็มรูปแบบ รวมถึงปฏิบัติตาม Intent ของ android.settings.REQUEST_SET_AUTOFILL_SERVICE เพื่อแสดงเมนูการตั้งค่าแอปเริ่มต้นเพื่อเปิดและปิดใช้การป้อนข้อความอัตโนมัติ รวมถึงเปลี่ยนบริการป้อนข้อความอัตโนมัติเริ่มต้นให้กับผู้ใช้
หากการติดตั้งใช้งานอุปกรณ์มีแอปที่ติดตั้งไว้ล่วงหน้าหรือต้องการอนุญาตให้แอปของบุคคลที่สามเข้าถึงสถิติการใช้งาน ผู้ใช้จะต้องดำเนินการดังนี้
- [C-SR-2] ขอแนะนำอย่างยิ่งให้ระบุกลไกที่ผู้ใช้เข้าถึงได้เพื่อมอบหรือเพิกถอนสิทธิ์เข้าถึงสถิติการใช้งานตามIntent android.settings.ACTION_USAGE_ACCESS_SETTINGS สำหรับแอปที่ประกาศสิทธิ์
android.permission.PACKAGE_USAGE_STATS
หากการติดตั้งใช้งานอุปกรณ์ตั้งใจที่จะไม่อนุญาตให้แอปใดๆ รวมถึงแอปที่ติดตั้งไว้ล่วงหน้าเข้าถึงสถิติการใช้งาน การดำเนินการต่อไปนี้จะเกิดขึ้น
- [C-15-1] ต้องมีกิจกรรมที่จัดการรูปแบบ Intent android.settings.ACTION_USAGE_ACCESS_SETTINGS อยู่เสมอ แต่ต้องใช้รูปแบบดังกล่าวแบบไม่มีการดำเนินการใดๆ กล่าวคือมีพฤติกรรมเทียบเท่ากับเมื่อผู้ใช้ถูกปฏิเสธการเข้าถึง
หากการติดตั้งใช้งานอุปกรณ์แสดงลิงก์ไปยังกิจกรรมที่ระบุโดย AutofillService_passwordsActivity ในการตั้งค่า หรือลิงก์ไปยังรหัสผ่านของผู้ใช้ผ่านกลไกที่คล้ายกัน การดำเนินการต่อไปนี้จะเกิดขึ้น
- [C-16-1] ต้องแสดงลิงก์ดังกล่าวสำหรับบริการป้อนข้อความอัตโนมัติที่ติดตั้งไว้ทั้งหมด
หากการติดตั้งใช้งานอุปกรณ์รองรับ VoiceInteractionService
และมีการติดตั้งแอปพลิเคชันที่ใช้ API นี้มากกว่า 1 แอปพร้อมกัน อุปกรณ์จะดำเนินการดังนี้
- [C-18-1] ต้องปฏิบัติตามความตั้งใจของ
android.settings.ACTION_VOICE_INPUT_SETTINGS
ที่แสดงเมนูการตั้งค่าแอปเริ่มต้นสำหรับการป้อนข้อมูลด้วยเสียงและความช่วยเหลือ
หากการติดตั้งใช้งานอุปกรณ์รายงานฟีเจอร์ android.hardware.audio.output
อุปกรณ์จะมีลักษณะดังนี้
- [C-SR-3] ขอแนะนำอย่างยิ่งให้ปฏิบัติตาม Intent android.intent.action.TTS_SERVICE, android.speech.tts.engine.INSTALL_TTS_DATA และ android.speech.tts.engine.GET_SAMPLE_TEXT โดยให้มี Activity เพื่อดำเนินการตาม Intent เหล่านี้ตามที่อธิบายไว้ใน SDK ที่นี่
Android รองรับโปรแกรมรักษาหน้าจอแบบอินเทอร์แอกทีฟ ซึ่งก่อนหน้านี้เรียกว่า "ภาพพักหน้าจอ" โปรแกรมรักษาหน้าจอช่วยให้ผู้ใช้โต้ตอบกับแอปพลิเคชันได้เมื่ออุปกรณ์ที่เชื่อมต่อกับแหล่งจ่ายไฟไม่มีการใช้งานหรือวางอยู่ในแท่นชาร์จบนโต๊ะ การติดตั้งใช้งานอุปกรณ์
- ควรรองรับโปรแกรมรักษาหน้าจอและระบุตัวเลือกการตั้งค่าเพื่อให้ผู้ใช้กำหนดค่าโปรแกรมรักษาหน้าจอเพื่อตอบสนองต่อ
android.settings.DREAM_SETTINGS
Intent
3.2.4. กิจกรรมบนจอแสดงผลรอง/หลายจอ
หากการติดตั้งใช้งานอุปกรณ์อนุญาตให้เปิดกิจกรรม Android ปกติในจอแสดงผลมากกว่า 1 จอ อุปกรณ์จะมีลักษณะดังนี้
- [C-1-1] ต้องตั้งค่า
android.software.activities_on_secondary_displays
Flag ฟีเจอร์ - [C-1-2] ต้องรับประกันความเข้ากันได้ของ API คล้ายกับกิจกรรมที่ทำงานบนจอแสดงผลหลัก
- [C-1-3] ต้องแสดงกิจกรรมใหม่ในจอแสดงผลเดียวกับกิจกรรมที่เปิดใช้งาน เมื่อเปิดใช้งานกิจกรรมใหม่โดยไม่ระบุจอแสดงผลเป้าหมายผ่าน
ActivityOptions.setLaunchDisplayId()
API - [C-1-4] MUST destroy all activities, when a display with the
Display.FLAG_PRIVATE
flag is removed. - [C-1-5] ต้องซ่อนเนื้อหาบนหน้าจอทั้งหมดอย่างปลอดภัยเมื่ออุปกรณ์ล็อกอยู่ด้วยหน้าจอล็อกที่ปลอดภัย เว้นแต่แอปจะเลือกใช้การแสดงที่ด้านบนของหน้าจอล็อกโดยใช้
Activity#setShowWhenLocked()
API - ควรมี
android.content.res.Configuration
ที่สอดคล้องกับจอแสดงผลนั้นเพื่อให้แสดง ทำงานอย่างถูกต้อง และรักษาความเข้ากันได้หากมีการเปิดใช้งานกิจกรรมในจอแสดงผลรอง
หากการติดตั้งใช้งานอุปกรณ์อนุญาตให้เปิดกิจกรรม Android ปกติในจอแสดงผลรอง และจอแสดงผลรองมี Flag android.view.Display.FLAG_PRIVATE ให้ทำดังนี้
- [C-3-1] เฉพาะเจ้าของจอแสดงผล ระบบ และกิจกรรมที่แสดงอยู่ในจอแสดงผลนั้นเท่านั้นที่เปิดใช้งานจอแสดงผลได้ ทุกคนสามารถเปิดใช้จอแสดงผลที่มี Flag android.view.Display.FLAG_PUBLIC ได้
3.3 ความเข้ากันได้ของ API เดิม
ความเข้ากันได้ของโค้ดที่มาพร้อมเครื่องเป็นเรื่องยาก ด้วยเหตุนี้ ผู้ติดตั้งใช้งานอุปกรณ์จึงต้องมีคุณสมบัติดังนี้
- [C-SR-1] ขอแนะนําอย่างยิ่งให้ใช้การติดตั้งใช้งานไลบรารีที่ระบุไว้ด้านล่างจากโปรเจ็กต์โอเพนซอร์ส Android ต้นทาง
3.3.1. อินเทอร์เฟซแบบไบนารีของแอปพลิเคชัน
บิตโค้ด Dalvik ที่มีการจัดการสามารถเรียกใช้โค้ดเนทีฟที่ระบุไว้ในไฟล์.apk
ของแอปพลิเคชันเป็นไฟล์ ELF .so
ที่คอมไพล์มาสำหรับสถาปัตยกรรมฮาร์ดแวร์ของอุปกรณ์ที่เหมาะสม เนื่องจากโค้ดเนทีฟมีความเกี่ยวข้องกับเทคโนโลยีโปรเซสเซอร์พื้นฐานเป็นอย่างมาก Android จึงกำหนด Application Binary Interface (ABI) หลายรายการใน Android NDK
การติดตั้งใช้งานอุปกรณ์
- [C-0-1] ต้องเข้ากันได้กับ Android NDK ABI ที่ระบุไว้อย่างน้อย 1 รายการ
- [C-0-2] ต้องรองรับโค้ดที่ทำงานในสภาพแวดล้อมที่มีการจัดการเพื่อเรียกใช้โค้ดเนทีฟโดยใช้นิพจน์ทางความหมายของ Java Native Interface (JNI) มาตรฐาน
- [C-0-3] ต้องเข้ากันได้กับซอร์สโค้ด (กล่าวคือ เข้ากันได้กับส่วนหัว) และเข้ากันได้กับไบนารี (สำหรับ ABI) กับไลบรารีที่จำเป็นแต่ละรายการในรายการด้านล่าง
- [C-0-5] ต้องรายงาน Application Binary Interface (ABI) เดิมที่อุปกรณ์รองรับอย่างถูกต้องผ่านพารามิเตอร์
android.os.Build.SUPPORTED_ABIS
,android.os.Build.SUPPORTED_32_BIT_ABIS
และandroid.os.Build.SUPPORTED_64_BIT_ABIS
โดยแต่ละพารามิเตอร์จะเป็นรายการ ABI ที่แยกด้วยคอมมา โดยเรียงจาก ABI ที่แนะนำมากที่สุดไปจนถึงน้อยที่สุด [C-0-6] ต้องรายงานชุดย่อยของ ABI ต่อไปนี้ผ่านพารามิเตอร์ข้างต้น และต้องไม่รายงาน ABI ที่ไม่ได้อยู่ในรายการ
armeabi
(NDK ไม่รองรับเป็นเป้าหมายอีกต่อไป)armeabi-v7a
arm64-v8a
x86
x86-64
[C-0-7] ต้องทำให้ไลบรารีต่อไปนี้ทั้งหมดพร้อมใช้งานสำหรับแอปที่มีโค้ดเนทีฟ โดยไลบรารีเหล่านี้ต้องให้บริการ API เนทีฟ
- libaaudio.so (การรองรับเสียงแบบเนทีฟของ AAudio)
- libamidi.so (การรองรับ MIDI ในตัว หากมีการอ้างสิทธิ์ฟีเจอร์
android.software.midi
ตามที่อธิบายไว้ในส่วนที่ 5.9) - libandroid.so (การรองรับกิจกรรม Android ดั้งเดิม)
- libc (คลัง C)
- libcamera2ndk.so
- libdl (ตัวลิงก์แบบไดนามิก)
- libEGL.so (การจัดการพื้นผิว OpenGL ดั้งเดิม)
- libGLESv1_CM.so (OpenGL ES 1.x)
- libGLESv2.so (OpenGL ES 2.0)
- libGLESv3.so (OpenGL ES 3.x)
- libicui18n.so
- libicuuc.so
- libjnigraphics.so
- liblog (การบันทึกของ Android)
- libmediandk.so (รองรับ API สื่อแบบเนทีฟ)
- libm (คลังคณิตศาสตร์)
- libneuralnetworks.so (Neural Networks API)
- libOpenMAXAL.so (รองรับ OpenMAX AL 1.0.1)
- libOpenSLES.so (การรองรับเสียง OpenSL ES 1.0.1)
- libRS.so
- libstdc++ (รองรับ C++ ขั้นต่ำ)
- libvulkan.so (Vulkan)
- libz (การบีบอัด Zlib)
- อินเทอร์เฟซ JNI
[C-0-8] ต้องไม่เพิ่มหรือนําฟังก์ชันสาธารณะสําหรับไลบรารีแบบเนทีฟที่ระบุไว้ข้างต้นออก
[C-0-9] ต้องระบุไลบรารีที่ไม่ใช่ AOSP เพิ่มเติมที่แสดงต่อแอปของบุคคลที่สามโดยตรงใน
/vendor/etc/public.libraries.txt
[C-0-10] ต้องไม่แสดงไลบรารีเนทีฟอื่นๆ ที่ติดตั้งใช้งานและระบุไว้ใน AOSP เป็นไลบรารีระบบแก่แอปของบุคคลที่สามที่กำหนดเป้าหมาย API ระดับ 24 ขึ้นไป เนื่องจากมีการสงวนไว้
[C-0-11] ต้องส่งออกสัญลักษณ์ฟังก์ชัน OpenGL ES 3.1 และ Android Extension Pack ทั้งหมดตามที่ระบุไว้ใน NDK ผ่านไลบรารี
libGLESv3.so
โปรดทราบว่าแม้ว่าจะต้องมีสัญลักษณ์ทั้งหมด แต่ส่วนที่ 7.1.4.1 จะอธิบายข้อกำหนดโดยละเอียดเพิ่มเติมสำหรับกรณีที่คาดว่าจะมีการใช้งานฟังก์ชันที่เกี่ยวข้องแต่ละรายการอย่างเต็มรูปแบบ[C-0-12] ต้องส่งออกสัญลักษณ์ฟังก์ชันสำหรับสัญลักษณ์ฟังก์ชันหลักของ Vulkan 1.0 รวมถึงส่วนขยาย
VK_KHR_surface
,VK_KHR_android_surface
,VK_KHR_swapchain
,VK_KHR_maintenance1
และVK_KHR_get_physical_device_properties2
ผ่านไลบรารีlibvulkan.so
โปรดทราบว่าแม้ว่าสัญลักษณ์ทั้งหมดจะต้องมีอยู่ แต่ส่วนที่ 7.1.4.2 จะอธิบายข้อกำหนดโดยละเอียดเพิ่มเติมสำหรับกรณีที่คาดว่าจะมีการใช้งานฟังก์ชันที่เกี่ยวข้องแต่ละรายการอย่างเต็มรูปแบบควรสร้างโดยใช้ซอร์สโค้ดและไฟล์ส่วนหัวที่มีอยู่ในโครงการโอเพนซอร์ส Android ต้นทาง
โปรดทราบว่า Android รุ่นต่อๆ ไปอาจรองรับ ABI เพิ่มเติม
3.3.2. ความเข้ากันได้ของโค้ดเนทีฟ ARM แบบ 32 บิต
หากการติดตั้งใช้งานอุปกรณ์รายงานการรองรับ armeabi
ABI อุปกรณ์จะดำเนินการต่อไปนี้
- [C-3-1] และต้องรองรับ
armeabi-v7a
และรายงานการรองรับด้วย เนื่องจากarmeabi
มีไว้เพื่อการทำงานร่วมกันแบบย้อนหลังกับแอปรุ่นเก่าเท่านั้น
หากการติดตั้งใช้งานอุปกรณ์รายงานการรองรับ armeabi-v7a
ABI สําหรับแอปที่ใช้ ABI นี้ แอปจะมีลักษณะดังนี้
[C-2-1] ต้องใส่บรรทัดต่อไปนี้ใน
/proc/cpuinfo
และไม่ควรเปลี่ยนแปลงค่าในอุปกรณ์เครื่องเดียวกัน แม้ว่า ABI อื่นๆ จะอ่านค่าเหล่านั้นก็ตามFeatures:
ตามด้วยรายการฟีเจอร์ CPU ARMv7 ที่ไม่บังคับซึ่งอุปกรณ์รองรับCPU architecture:
ตามด้วยจำนวนเต็มซึ่งอธิบายสถาปัตยกรรม ARM ที่รองรับสูงสุดของอุปกรณ์ (เช่น "8" สำหรับอุปกรณ์ ARMv8)
[C-2-2] ต้องทำให้การดำเนินการต่อไปนี้พร้อมใช้งานเสมอ แม้ในกรณีที่มีการใช้ ABI ในสถาปัตยกรรม ARMv8 ผ่านการสนับสนุน CPU ดั้งเดิมหรือผ่านการจําลองซอฟต์แวร์ก็ตาม
- วิธีการ SWP และ SWPB
- การดำเนินการกับสิ่งกีดขวาง CP15ISB, CP15DSB และ CP15DMB
[C-2-3] ต้องรองรับส่วนขยาย Advanced SIMD (หรือที่เรียกว่า NEON)
3.4. ความเข้ากันได้ของเว็บ
3.4.1. ความเข้ากันได้ของ WebView
หากการติดตั้งใช้งานอุปกรณ์มีการติดตั้งใช้งาน android.webkit.Webview
API อย่างสมบูรณ์ อุปกรณ์จะทําสิ่งต่อไปนี้
- [C-1-1] MUST report
android.software.webview
. - [C-1-2] ต้องใช้บิลด์โปรเจ็กต์ Chromium จากโปรเจ็กต์โอเพนซอร์ส Android ต้นทางในสาขา Android 12 เพื่อติดตั้งใช้งาน
android.webkit.WebView
API [C-1-3] สตริง User Agent ที่ WebView รายงานต้องเป็นรูปแบบนี้
Mozilla/5.0 (Linux; Android $(VERSION); [$(MODEL)] [Build/$(BUILD)]; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 $(CHROMIUM_VER) Mobile Safari/537.36
- ค่าของสตริง $(VERSION) ต้องเป็นค่าเดียวกับค่าสำหรับ android.os.Build.VERSION.RELEASE
- สตริง $(MODEL) อาจว่างเปล่าได้ แต่หากไม่ได้ว่างเปล่า สตริงดังกล่าวต้องมีค่าเดียวกับ android.os.Build.MODEL
- คุณอาจละเว้น "Build/$(BUILD)" ได้ แต่หากมีสตริง $(BUILD) จะต้องเหมือนกับค่าสำหรับ android.os.Build.ID
- ค่าของสตริง $(CHROMIUM_VER) ต้องเป็นเวอร์ชัน Chromium ในโปรเจ็กต์โอเพนซอร์ส Android ต้นทาง
- การติดตั้งใช้งานอุปกรณ์อาจไม่ใส่ Mobile ในสตริง User Agent
คอมโพเนนต์ WebView ควรรองรับฟีเจอร์ HTML5 ให้ได้มากที่สุด และหากรองรับฟีเจอร์ดังกล่าว ก็ควรเป็นไปตามข้อกำหนด HTML5
[C-1-4] ต้องแสดงผลเนื้อหาที่ระบุหรือเนื้อหา URL ระยะไกลในกระบวนการที่แตกต่างกันจากแอปพลิเคชันที่สร้างอินสแตนซ์ WebView กล่าวโดยละเอียดคือ กระบวนการแสดงผลที่แยกต่างหากต้องมีสิทธิ์ในระดับต่ำกว่า ทำงานเป็น User-ID ที่แยกต่างหาก ไม่มีสิทธิ์เข้าถึงไดเรกทอรีข้อมูลของแอป ไม่มีสิทธิ์เข้าถึงเครือข่ายโดยตรง และมีสิทธิ์เข้าถึงบริการระบบที่จําเป็นขั้นต่ำผ่าน Binder เท่านั้น การใช้งาน WebView ของ AOSP เป็นไปตามข้อกำหนดนี้
โปรดทราบว่าหากการติดตั้งใช้งานอุปกรณ์เป็นแบบ 32 บิตหรือประกาศ Flag ฟีเจอร์
android.hardware.ram.low
ระบบจะยกเว้น C-1-3
3.4.2. ความเข้ากันได้กับเบราว์เซอร์
หากการติดตั้งใช้งานอุปกรณ์มีแอปพลิเคชันเบราว์เซอร์แบบสแตนด์อโลนสำหรับการท่องเว็บทั่วไป แอปพลิเคชันดังกล่าวจะมีลักษณะดังนี้
- [C-1-1] ต้องรองรับ API แต่ละรายการต่อไปนี้ซึ่งเชื่อมโยงกับ HTML5
- [C-1-2] ต้องรองรับ webstorage API ของ HTML5/W3C และควรรองรับ IndexedDB API ของ HTML5/W3C โปรดทราบว่าเนื่องจากองค์กรมาตรฐานการพัฒนาเว็บกําลังเปลี่ยนไปใช้ IndexedDB แทน Web Storage จึงคาดว่า IndexedDB จะกลายเป็นคอมโพเนนต์ที่จําเป็นใน Android เวอร์ชันในอนาคต
- อาจจัดส่งสตริง User Agent ที่กําหนดเองในแอปพลิเคชันเบราว์เซอร์แบบสแตนด์อโลน
- ควรรองรับ HTML5 ให้ได้มากที่สุดในแอปพลิเคชันเบราว์เซอร์แบบสแตนด์อโลน (ไม่ว่าจะอิงตามแอปพลิเคชันเบราว์เซอร์ WebKit เวอร์ชันอัปสตรีมหรือแอปพลิเคชันทดแทนของบุคคลที่สาม)
อย่างไรก็ตาม หากการติดตั้งใช้งานอุปกรณ์ไม่มีแอปพลิเคชันเบราว์เซอร์แบบสแตนด์อโลน อุปกรณ์จะมีลักษณะดังนี้
- [C-2-1] ยังคงต้องรองรับรูปแบบ Intent สาธารณะตามที่อธิบายไว้ในส่วนที่ 3.2.3.1
3.5 ความเข้ากันได้ของลักษณะการทํางานของ API
การติดตั้งใช้งานอุปกรณ์
- [C-0-9] ต้องตรวจสอบว่าใช้ความเข้ากันได้ของลักษณะการทํางานของ API สําหรับแอปที่ติดตั้งทั้งหมด เว้นแต่จะมีการจํากัดตามที่อธิบายไว้ในส่วนที่ 3.5.1
- [C-0-10] ต้องไม่ใช้แนวทางรายการที่อนุญาตซึ่งช่วยให้มั่นใจว่า API เข้ากันได้กับลักษณะการทํางานสําหรับแอปที่ผู้ติดตั้งใช้งานอุปกรณ์เลือกเท่านั้น
ลักษณะการทํางานของ API แต่ละประเภท (ที่มีการจัดการ ซอฟต์ เนทีฟ และเว็บ) ต้องสอดคล้องกับการใช้งานที่แนะนำของ Android Open Source Project ต้นทาง ตัวอย่างด้านความเข้ากันได้ที่เฉพาะเจาะจง ได้แก่
- [C-0-1] อุปกรณ์ต้องไม่เปลี่ยนแปลงลักษณะการทํางานหรือความหมายของ Intent มาตรฐาน
- [C-0-2] อุปกรณ์ต้องไม่เปลี่ยนแปลงวงจรหรือความหมายของวงจรของคอมโพเนนต์ระบบบางประเภท (เช่น Service, Activity, ContentProvider ฯลฯ)
- [C-0-3] อุปกรณ์ต้องไม่เปลี่ยนความหมายของสิทธิ์มาตรฐาน
- อุปกรณ์ต้องไม่เปลี่ยนแปลงข้อจำกัดที่บังคับใช้กับแอปพลิเคชันที่ทำงานอยู่เบื้องหลัง
โดยเฉพาะอย่างยิ่งสำหรับแอปที่ทำงานอยู่เบื้องหลัง จะมีการเปลี่ยนแปลงดังนี้
- [C-0-4] และต้องหยุดการเรียกใช้การเรียกกลับที่แอปลงทะเบียนไว้เพื่อรับเอาต์พุตจาก
GnssMeasurement
และGnssNavigationMessage
- [C-0-5] และต้องจำกัดอัตราการอัปเดตที่ส่งไปยังแอปผ่านคลาส
LocationManager
API หรือเมธอดWifiManager.startScan()
- [C-0-6] หากแอปกำหนดเป้าหมายเป็น API ระดับ 25 ขึ้นไป แอปต้องไม่อนุญาตให้ลงทะเบียนตัวรับการออกอากาศสำหรับการออกอากาศโดยนัยของ Intent มาตรฐาน Android ในไฟล์ Manifest ของแอป เว้นแต่ Intent การออกอากาศดังกล่าวจะต้องได้รับสิทธิ์
"signature"
หรือ"signatureOrSystem"
protectionLevel
หรืออยู่ในรายการข้อยกเว้น - [C-0-7] หากแอปกำหนดเป้าหมายเป็น API ระดับ 25 ขึ้นไป แอปต้องหยุดบริการที่ทำงานอยู่เบื้องหลังของแอป เหมือนกับว่าแอปเรียกใช้เมธอด
stopSelf()
ของบริการ เว้นแต่ว่าแอปจะอยู่ในรายการที่อนุญาตชั่วคราวเพื่อจัดการงานที่แสดงต่อผู้ใช้ - [C-0-8] หากแอปกำหนดเป้าหมายเป็น API ระดับ 25 ขึ้นไป แอปจะต้องปล่อย Wakelock ที่แอปถือครอง
- [C-0-4] และต้องหยุดการเรียกใช้การเรียกกลับที่แอปลงทะเบียนไว้เพื่อรับเอาต์พุตจาก
- [C-0-11] อุปกรณ์ต้องแสดงผู้ให้บริการด้านความปลอดภัยต่อไปนี้เป็นค่าอาร์เรย์ 7 รายการแรกจากเมธอด
Security.getProviders()
ในลําดับที่ระบุและที่มีชื่อที่ระบุ (ตามที่แสดงโดยProvider.getName()
) และคลาส เว้นแต่แอปจะแก้ไขรายการผ่านinsertProviderAt()
หรือremoveProvider()
อุปกรณ์อาจแสดงผู้ให้บริการเพิ่มเติมหลังจากรายชื่อผู้ให้บริการที่ระบุไว้ด้านล่าง- AndroidNSSP -
android.security.net.config.NetworkSecurityConfigProvider
- AndroidOpenSSL -
com.android.org.conscrypt.OpenSSLProvider
- CertPathProvider -
sun.security.provider.CertPathProvider
- AndroidKeyStoreBCWorkaround -
android.security.keystore.AndroidKeyStoreBCWorkaroundProvider
- BC -
com.android.org.bouncycastle.jce.provider.BouncyCastleProvider
- HarmonyJSSE -
com.android.org.conscrypt.JSSEProvider
- AndroidKeyStore -
android.security.keystore.AndroidKeyStoreProvider
- AndroidNSSP -
โปรดทราบว่ารายการข้างต้นเป็นเพียงตัวอย่างบางส่วนเท่านั้น ชุดเครื่องมือทดสอบความเข้ากันได้ (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] ต้องระงับข้อจำกัดในแอปที่กลายเป็นแอปพลิเคชันเบื้องหน้าระดับบนสุดเมื่อผู้ใช้เริ่มใช้แอปที่เคยถูกจํากัดอย่างชัดแจ้ง
- [C-1-10] ต้องไม่อนุญาตให้ระบบจัดแอปไว้ในที่เก็บข้อมูล "ถูกจำกัด" โดยอัตโนมัติภายใน 2 ชั่วโมงหลังจากผู้ใช้ใช้งานครั้งล่าสุด
หากการติดตั้งใช้งานอุปกรณ์ขยายข้อจำกัดของแอปที่ใช้ใน AOSP การดำเนินการต่อไปนี้จะเกิดขึ้น
- [C-2-1] ต้องปฏิบัติตามการติดตั้งใช้งานที่อธิบายไว้ในเอกสารนี้
3.5.2. การพักใช้งานแอปพลิเคชัน
หากการติดตั้งใช้งานอุปกรณ์มีโหมดพักแอปที่รวมอยู่ใน AOSP หรือขยายฟีเจอร์ที่รวมอยู่ใน AOSP อุปกรณ์จะต้องมีคุณสมบัติดังนี้
- [C-1-1] ต้องปฏิบัติตามข้อกําหนดทั้งหมดในส่วนที่ 3.5.1 ยกเว้น [C-1-6] และ [C-1-3]
- [C-1-2] ต้องจำกัดแอปสำหรับผู้ใช้ก็ต่อเมื่อมีหลักฐานว่าผู้ใช้ไม่ได้ใช้แอปเป็นระยะเวลาหนึ่ง เราขอแนะนำอย่างยิ่งให้ระยะเวลานี้อย่างน้อย 1 เดือน การใช้งานต้องกำหนดโดยการโต้ตอบของผู้ใช้อย่างชัดเจนผ่าน API UsageStats#getLastTimeVisible() หรือสิ่งใดก็ตามที่จะทำให้แอปออกจากสถานะ "หยุดทำงานโดยบังคับ" ซึ่งรวมถึงการเชื่อมโยงบริการ การเชื่อมโยงผู้ให้บริการเนื้อหา การออกอากาศอย่างชัดแจ้ง ฯลฯ ซึ่งจะติดตามโดย API ใหม่อย่าง UsageStats#getLastTimeAnyComponentUsed()
- [C-1-3] ต้องใช้ข้อจำกัดที่ส่งผลต่อผู้ใช้อุปกรณ์ทุกรายเฉพาะในกรณีที่มีหลักฐานว่าไม่มีผู้ใช้รายใดใช้แพ็กเกจเป็นระยะเวลาหนึ่ง เราขอแนะนำอย่างยิ่งให้ระยะเวลานี้อย่างน้อย 1 เดือน
- [C-1-4] ต้องไม่ทําให้แอปไม่สามารถตอบสนองต่อ Intent ของกิจกรรม การเชื่อมโยงบริการ คําขอของผู้ให้บริการเนื้อหา หรือการออกอากาศที่ชัดเจน
การทำให้เป็นโหมดพักของแอปใน AOSP เป็นไปตามข้อกำหนดข้างต้น
3.6 เนมสเปซของ API
Android เป็นไปตามรูปแบบเนมสเปซของแพ็กเกจและคลาสที่ภาษาโปรแกรม Java กำหนด ผู้ติดตั้งใช้งานอุปกรณ์ต้องไม่ทำการแก้ไขที่ไม่ได้รับอนุญาต (ดูด้านล่าง) ในเนมสเปซของแพ็กเกจต่อไปนี้เพื่อให้มั่นใจว่าแอปพลิเคชันของบุคคลที่สามจะใช้งานร่วมกันได้
java.*
javax.*
sun.*
android.*
androidx.*
com.android.*
กล่าวคือ
- [C-0-1] ต้องไม่แก้ไข API ที่เปิดเผยต่อสาธารณะบนแพลตฟอร์ม Android โดยการเปลี่ยนลายเซ็นเมธอดหรือคลาส หรือนําคลาสหรือช่องคลาสออก
- [C-0-2] ต้องไม่เพิ่มองค์ประกอบที่เปิดเผยต่อสาธารณะ (เช่น คลาสหรืออินเทอร์เฟซ หรือฟิลด์หรือเมธอดในคลาสหรืออินเทอร์เฟซที่มีอยู่) หรือ API การทดสอบหรือ API ของระบบลงใน API ในเนมสเปซข้างต้น "องค์ประกอบที่เปิดเผยต่อสาธารณะ" คือองค์ประกอบที่ไม่ได้ตกแต่งด้วยเครื่องหมาย "@hide" ตามที่ใช้ในซอร์สโค้ด Android ต้นทาง
ผู้ติดตั้งใช้งานอุปกรณ์อาจแก้ไขการใช้งาน API พื้นฐานได้ แต่การแก้ไขดังกล่าวต้องมีลักษณะดังนี้
- [C-0-3] ต้องไม่ส่งผลต่อลักษณะการทำงานที่ระบุและลายเซ็นภาษา Java ของ API ที่เผยแพร่ต่อสาธารณะ
- [C-0-4] ต้องไม่มีการโฆษณาหรือแสดงต่อนักพัฒนาแอป
อย่างไรก็ตาม ผู้ติดตั้งใช้งานอุปกรณ์อาจเพิ่ม API ที่กำหนดเองนอกเนมสเปซ Android มาตรฐานได้ แต่ API ที่กําหนดเองต้องมีลักษณะดังนี้
- [C-0-5] ต้องไม่อยู่ในเนมสเปซที่องค์กรอื่นเป็นเจ้าของหรืออ้างอิงถึง ตัวอย่างเช่น ผู้ติดตั้งใช้งานอุปกรณ์ต้องไม่เพิ่ม API ลงในเนมสเปซ
com.google.*
หรือเนมสเปซที่คล้ายกัน เฉพาะ Google เท่านั้นที่เพิ่ม API ได้ ในทำนองเดียวกัน Google ต้องไม่เพิ่ม API ลงในเนมสเปซของบริษัทอื่นๆ - [C-0-6] ต้องจัดแพ็กเกจในไลบรารีที่ใช้ร่วมกันของ Android เพื่อให้มีเพียงแอปที่ใช้ API ดังกล่าวอย่างชัดเจน (ผ่านกลไก <uses-library>) เท่านั้นที่ได้รับผลกระทบจากการใช้หน่วยความจำที่เพิ่มขึ้นของ API ดังกล่าว
ผู้ติดตั้งใช้งานอุปกรณ์อาจเพิ่ม API ที่กําหนดเองในภาษาท้องถิ่นนอก NDK API ได้ แต่ API ที่กําหนดเองต้องมีลักษณะดังนี้
- [C-1-1] ต้องไม่อยู่ในไลบรารี NDK หรือไลบรารีที่เป็นขององค์กรอื่นตามที่อธิบายไว้ที่นี่
หากผู้ติดตั้งใช้งานอุปกรณ์เสนอที่จะปรับปรุงเนมสเปซแพ็กเกจใดแพ็กเกจหนึ่งข้างต้น (เช่น การเพิ่มฟังก์ชันการทำงานใหม่ที่มีประโยชน์ลงใน API ที่มีอยู่ หรือการเพิ่ม API ใหม่) ผู้ติดตั้งใช้งานควรไปที่ source.android.com และเริ่มกระบวนการมีส่วนร่วมในการเปลี่ยนแปลงและโค้ดตามข้อมูลในเว็บไซต์ดังกล่าว
โปรดทราบว่าข้อจำกัดข้างต้นสอดคล้องกับแบบแผนมาตรฐานในการตั้งชื่อ API ในภาษาโปรแกรม Java ส่วนนี้มีจุดประสงค์เพียงเพื่อเสริมแบบแผนเหล่านั้นและทำให้แบบแผนเหล่านั้นมีผลบังคับใช้ผ่านการรวมไว้ในคำจำกัดความความเข้ากันได้นี้
3.7. ความเข้ากันได้ของรันไทม์
การติดตั้งใช้งานอุปกรณ์
[C-0-1] ต้องรองรับรูปแบบ Dalvik Executable (DEX) แบบเต็ม และข้อกำหนดและความหมายของไบต์โค้ด Dalvik
[C-0-2] ต้องกำหนดค่ารันไทม์ Dalvik เพื่อจัดสรรหน่วยความจำตามแพลตฟอร์ม Android ต้นทาง และตามที่ระบุไว้ในตารางต่อไปนี้ (ดูคำจำกัดความของขนาดหน้าจอและความหนาแน่นของหน้าจอในส่วนที่ 7.1.1)
ควรใช้ Android Runtime (ART), การใช้งานรูปแบบ Dalvik Executable เวอร์ชันที่อ้างอิงจาก upstream และระบบการจัดการแพ็กเกจของการใช้งานเวอร์ชันที่อ้างอิง
ควรทำการทดสอบ Fuzz ภายใต้โหมดการดำเนินการและสถาปัตยกรรมเป้าหมายต่างๆ เพื่อให้แน่ใจว่ารันไทม์มีความเสถียร โปรดดูข้อมูลเกี่ยวกับ JFuzz และ DexFuzz ในเว็บไซต์โครงการโอเพนซอร์ส Android
โปรดทราบว่าค่าหน่วยความจําที่ระบุไว้ด้านล่างถือเป็นค่าขั้นต่ำ และการติดตั้งใช้งานอุปกรณ์อาจจัดสรรหน่วยความจําเพิ่มเติมต่อแอปพลิเคชัน
เลย์เอาต์หน้าจอ | ความหนาแน่นของหน้าจอ | หน่วยความจําของแอปพลิเคชันขั้นต่ำ |
---|---|---|
Android Watch | 120 dpi (ldpi) | 32MB |
140 dpi (140dpi) | ||
160 dpi (mdpi) | ||
180 dpi (180dpi) | ||
200 dpi (200dpi) | ||
213 dpi (tvdpi) | ||
220 dpi (220dpi) | 36MB | |
240 dpi (hdpi) | ||
280 dpi (280dpi) | ||
320 dpi (xhdpi) | 48MB | |
360 dpi (360dpi) | ||
400 dpi (400dpi) | 56MB | |
420 dpi (420dpi) | 64MB | |
480 dpi (xxhdpi) | 88MB | |
560 dpi (560dpi) | 112MB | |
640 dpi (xxxhdpi) | 154MB | |
เล็ก/ปกติ | 120 dpi (ldpi) | 32MB |
140 dpi (140dpi) | ||
160 dpi (mdpi) | ||
180 dpi (180dpi) | 48MB | |
200 dpi (200dpi) | ||
213 dpi (tvdpi) | ||
220 dpi (220dpi) | ||
240 dpi (hdpi) | ||
280 dpi (280dpi) | ||
320 dpi (xhdpi) | 80MB | |
360 dpi (360dpi) | ||
400 dpi (400dpi) | 96MB | |
420 dpi (420dpi) | 112MB | |
480 dpi (xxhdpi) | 128MB | |
560 dpi (560dpi) | 192MB | |
640 dpi (xxxhdpi) | 256MB | |
ใหญ่ | 120 dpi (ldpi) | 32MB |
140 dpi (140dpi) | 48MB | |
160 dpi (mdpi) | ||
180 dpi (180dpi) | 80MB | |
200 dpi (200dpi) | ||
213 dpi (tvdpi) | ||
220 dpi (220dpi) | ||
240 dpi (hdpi) | ||
280 dpi (280dpi) | 96MB | |
320 dpi (xhdpi) | 128MB | |
360 dpi (360dpi) | 160MB | |
400 dpi (400dpi) | 192MB | |
420 dpi (420dpi) | 228MB | |
480 dpi (xxhdpi) | 256MB | |
560 dpi (560dpi) | 384MB | |
640 dpi (xxxhdpi) | 512MB | |
xlarge | 120 dpi (ldpi) | 48MB |
140 dpi (140dpi) | 80MB | |
160 dpi (mdpi) | ||
180 dpi (180dpi) | 96MB | |
200 dpi (200dpi) | ||
213 dpi (tvdpi) | ||
220 dpi (220dpi) | ||
240 dpi (hdpi) | ||
280 dpi (280dpi) | 144MB | |
320 dpi (xhdpi) | 192MB | |
360 dpi (360dpi) | 240MB | |
400 dpi (400dpi) | 288MB | |
420 dpi (420dpi) | 336MB | |
480 dpi (xxhdpi) | 384MB | |
560 dpi (560dpi) | 576MB | |
640 dpi (xxxhdpi) | 768MB |
3.8. ความเข้ากันได้ของอินเทอร์เฟซผู้ใช้
3.8.1. Launcher (หน้าจอหลัก)
Android มีแอปพลิเคชัน Launcher (หน้าจอหลัก) และรองรับแอปพลิเคชันของบุคคลที่สามเพื่อแทนที่ Launcher ของอุปกรณ์ (หน้าจอหลัก)
หากการติดตั้งใช้งานอุปกรณ์อนุญาตให้แอปพลิเคชันของบุคคลที่สามแทนที่หน้าจอหลักของอุปกรณ์ แอปพลิเคชันดังกล่าวจะทำสิ่งต่อไปนี้
- [C-1-1] ต้องประกาศฟีเจอร์แพลตฟอร์ม
android.software.home_screen
- [C-1-2] ต้องแสดงผลออบเจ็กต์
AdaptiveIconDrawable
เมื่อแอปพลิเคชันของบุคคลที่สามใช้แท็ก<adaptive-icon>
เพื่อแสดงไอคอน และเรียกใช้เมธอดPackageManager
เพื่อเรียกข้อมูลไอคอน
หากการติดตั้งใช้งานอุปกรณ์มี Launcher เริ่มต้นที่รองรับการปักหมุดทางลัดในแอป อุปกรณ์จะดำเนินการต่อไปนี้
- [C-2-1] ต้องรายงาน
true
สำหรับShortcutManager.isRequestPinShortcutSupported()
- [C-2-2] ต้องมีการแสดงข้อมูลให้ผู้ใช้ทราบเพื่อขออนุญาตจากผู้ใช้ก่อนเพิ่มทางลัดที่แอปขอผ่านเมธอด
ShortcutManager.requestPinShortcut()
API - [C-2-3] ต้องรองรับทางลัดที่ปักหมุดไว้ รวมถึงทางลัดแบบไดนามิกและแบบคงที่ตามที่ระบุไว้ในหน้าทางลัดของแอป
ในทางกลับกัน หากการติดตั้งใช้งานอุปกรณ์ไม่รองรับการปักหมุดทางลัดในแอป ทางลัดจะมีลักษณะดังนี้
- [C-3-1] ต้องรายงาน
false
สำหรับShortcutManager.isRequestPinShortcutSupported()
หากการติดตั้งใช้งานอุปกรณ์ใช้ Launcher เริ่มต้นที่ให้สิทธิ์เข้าถึงทางลัดเพิ่มเติมที่แอปของบุคคลที่สามระบุไว้อย่างรวดเร็วผ่าน ShortcutManager API อุปกรณ์จะดำเนินการต่อไปนี้
- [C-4-1] ต้องรองรับฟีเจอร์แป้นพิมพ์ลัดที่ระบุไว้ในเอกสารทั้งหมด (เช่น แป้นพิมพ์ลัดแบบคงที่และแบบไดนามิก การปักหมุดแป้นพิมพ์ลัด) และใช้ API ของคลาส
ShortcutManager
API อย่างเต็มรูปแบบ
หากการติดตั้งใช้งานอุปกรณ์มีแอป Launcher เริ่มต้นที่แสดงป้ายสำหรับไอคอนแอป ป้ายดังกล่าวจะมีลักษณะดังนี้
- [C-5-1] ต้องเป็นไปตามเมธอด API ของ
NotificationChannel.setShowBadge()
กล่าวคือ แสดงสิ่งต่างๆ ที่มองเห็นได้ซึ่งเชื่อมโยงกับไอคอนแอปหากตั้งค่าเป็นtrue
และอย่าแสดงรูปแบบป้ายไอคอนแอปเมื่อช่องทางการแจ้งเตือนทั้งหมดของแอปตั้งค่าเป็นfalse
- อาจลบล้างป้ายไอคอนแอปด้วยรูปแบบป้ายที่เป็นกรรมสิทธิ์เมื่อแอปพลิเคชันของบุคคลที่สามระบุว่ารองรับรูปแบบป้ายที่เป็นกรรมสิทธิ์ผ่านการใช้ API ที่เป็นกรรมสิทธิ์ แต่ควรใช้ทรัพยากรและค่าที่ระบุผ่าน API ป้ายการแจ้งเตือนที่อธิบายไว้ใน SDK เช่น
Notification.Builder.setNumber()
และNotification.Builder.setBadgeIconType()
API
3.8.2. วิดเจ็ต
Android รองรับวิดเจ็ตแอปของบุคคลที่สามโดยกำหนดประเภทคอมโพเนนต์ รวมถึง API และวงจรที่เกี่ยวข้องซึ่งช่วยให้แอปพลิเคชันแสดง "AppWidget" ต่อผู้ใช้ปลายทางได้
หากการติดตั้งใช้งานอุปกรณ์รองรับวิดเจ็ตแอปของบุคคลที่สาม วิดเจ็ตจะมีลักษณะดังนี้
- [C-1-1] ต้องประกาศการรองรับฟีเจอร์แพลตฟอร์ม
android.software.app_widgets
- [C-1-2] ต้องมีการสนับสนุน App Widgets ในตัวและแสดงความสามารถในการใช้งานอินเทอร์เฟซผู้ใช้เพื่อเพิ่ม กำหนดค่า ดู และนำ App Widgets ออกได้โดยตรงใน 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 มี Notification
และ NotificationManager
API ซึ่งช่วยให้นักพัฒนาแอปบุคคลที่สามสามารถแจ้งเตือนผู้ใช้เกี่ยวกับเหตุการณ์สำคัญและดึงดูดความสนใจของผู้ใช้โดยใช้คอมโพเนนต์ฮาร์ดแวร์ (เช่น เสียง การสั่น และแสง) และฟีเจอร์ซอฟต์แวร์ (เช่น หน้าต่างแจ้งเตือน แถบระบบ) ของอุปกรณ์
3.8.3.1. การแสดงการแจ้งเตือน
หากการติดตั้งใช้งานอุปกรณ์อนุญาตให้แอปของบุคคลที่สามแจ้งเตือนผู้ใช้เกี่ยวกับเหตุการณ์สำคัญ แอปดังกล่าวจะทำสิ่งต่อไปนี้
- [C-1-1] ต้องรองรับการแจ้งเตือนที่ใช้ฟีเจอร์ฮาร์ดแวร์ตามที่อธิบายไว้ในเอกสารประกอบ SDK และรองรับการใช้งานฮาร์ดแวร์ของอุปกรณ์เท่าที่จะทำได้ ตัวอย่างเช่น หากการติดตั้งใช้งานอุปกรณ์มีเครื่องสั่น การติดตั้งใช้งานนั้นต้องใช้ API การสั่นอย่างถูกต้อง หากการติดตั้งใช้งานอุปกรณ์ไม่มีฮาร์ดแวร์ จะต้องติดตั้งใช้งาน API ที่เกี่ยวข้องแบบไม่ดำเนินการ ลักษณะการทํางานนี้มีรายละเอียดเพิ่มเติมในส่วนที่ 7
- [C-1-2] ต้องแสดงผลทรัพยากรทั้งหมด (ไอคอน ไฟล์ภาพเคลื่อนไหว ฯลฯ) ที่ระบุไว้ใน API หรือในคู่มือสไตล์ไอคอนแถบสถานะ/แถบระบบอย่างถูกต้อง แม้ว่าอาจให้ประสบการณ์การใช้งานการแจ้งเตือนที่แตกต่างไปจากการใช้งานตามข้อมูลอ้างอิงสำหรับ Android Open Source
- [C-1-3] ต้องปฏิบัติตามและใช้งานลักษณะการทำงานที่อธิบายไว้สำหรับAPI อย่างถูกต้องเพื่ออัปเดต นําออก และจัดกลุ่มการแจ้งเตือน
- [C-1-4] ต้องระบุลักษณะการทํางานทั้งหมดของ NotificationChannel API ที่บันทึกไว้ใน SDK
- [C-1-5] ต้องให้ผู้ใช้สามารถบล็อกและแก้ไขการแจ้งเตือนของแอปของบุคคลที่สามบางแอปในแต่ละช่องทางและระดับแพ็กเกจแอป
- [C-1-6] ต้องมีทางเลือกให้ผู้ใช้แสดงแชแนลการแจ้งเตือนที่ลบไปแล้ว
- [C-1-7] ต้องแสดงผลทรัพยากรทั้งหมด (รูปภาพ สติกเกอร์ ไอคอน ฯลฯ) ที่ระบุผ่าน Notification.MessagingStyle อย่างถูกต้องควบคู่ไปกับข้อความการแจ้งเตือนโดยที่ผู้ใช้ไม่ต้องโต้ตอบเพิ่มเติม เช่น ต้องแสดงทรัพยากรทั้งหมด รวมถึงไอคอนที่ระบุผ่าน android.app.Person ในการสนทนากลุ่มที่ตั้งค่าผ่าน setGroupConversation
- [C-SR-1] ขอแนะนำอย่างยิ่งให้แสดงทางเลือกให้ผู้ใช้โดยอัตโนมัติเพื่อบล็อกการแจ้งเตือนของแอปของบุคคลที่สามบางแอปในแต่ละช่องทางและระดับแพ็กเกจแอปหลังจากที่ผู้ใช้ปิดการแจ้งเตือนนั้นหลายครั้ง
- [C-SR-2] ขอแนะนำอย่างยิ่งให้ระบุตัวเลือกให้ผู้ใช้ควบคุมการแจ้งเตือนที่แสดงต่อแอปที่ได้รับสิทธิ์ Notification Listener ความละเอียดต้องเป็นแบบที่ผู้ใช้สามารถควบคุมประเภทการแจ้งเตือนที่เชื่อมโยงกับ Listener แต่ละรายการดังกล่าวได้ ประเภทต้องรวมถึงการแจ้งเตือน "การสนทนา" "การแจ้งเตือน" "ไม่มีเสียง" และ "ต่อเนื่องที่สำคัญ"
- [C-SR-3] ขอแนะนำอย่างยิ่งให้ระบุทางเลือกให้ผู้ใช้ระบุแอปที่จะยกเว้นไม่ให้แจ้งเตือนไปยังโปรแกรมรับฟังการแจ้งเตือนที่เฉพาะเจาะจง
- ควรรองรับการแจ้งเตือนแบบริชมีเดีย
- ควรแสดงการแจ้งเตือนที่มีลำดับความสำคัญสูงกว่าเป็นการแจ้งเตือนล่วงหน้า
- ควรมีสิ่งอํานวยความสะดวกสําหรับผู้ใช้ในการเลื่อนการแจ้งเตือน
- จัดการได้เฉพาะระดับการเข้าถึงและเวลาที่แอปของบุคคลที่สามจะแจ้งเตือนผู้ใช้เกี่ยวกับเหตุการณ์สำคัญเพื่อลดปัญหาด้านความปลอดภัย เช่น การที่ผู้ขับขี่เสียสมาธิ
Android 11 รองรับการแจ้งเตือนการสนทนา ซึ่งเป็นการแจ้งเตือนที่ใช้ MessagingStyle และระบุรหัสทางลัด People ที่เผยแพร่
การติดตั้งใช้งานอุปกรณ์
- [C-SR-4] ขอแนะนำอย่างยิ่งให้จัดกลุ่มและแสดง
conversation notifications
ไว้ก่อนการแจ้งเตือนที่ไม่ใช่การสนทนา ยกเว้นการแจ้งเตือนบริการที่ทำงานอยู่เบื้องหน้าและการแจ้งเตือนimportance:high
หากการติดตั้งใช้งานอุปกรณ์รองรับ conversation notifications
และแอปให้ข้อมูลที่จําเป็นสําหรับ bubbles
อุปกรณ์จะทําสิ่งต่อไปนี้
- [C-SR-5] ขอแนะนำอย่างยิ่งให้แสดงการสนทนานี้เป็นบับเบิล การติดตั้งใช้งาน AOSP เป็นไปตามข้อกำหนดเหล่านี้ด้วย UI ระบบ การตั้งค่า และ Launcher เริ่มต้น
หากการติดตั้งใช้งานอุปกรณ์รองรับการแจ้งเตือนแบบริชมีเดีย อุปกรณ์จะดำเนินการต่อไปนี้
- [C-2-1] ต้องใช้ทรัพยากรที่ตรงกันทุกประการกับที่ระบุผ่านคลาส
Notification.Style
API และคลาสย่อยของคลาสดังกล่าวสำหรับองค์ประกอบทรัพยากรที่แสดง - ควรแสดงองค์ประกอบทรัพยากรแต่ละรายการ (เช่น ไอคอน ชื่อ และข้อความสรุป) ที่กําหนดไว้ในคลาส
Notification.Style
API และคลาสย่อยของคลาสนั้น
หากการติดตั้งใช้งานอุปกรณ์รองรับการแจ้งเตือนแบบ Heads-Up อุปกรณ์จะดำเนินการต่อไปนี้
- [C-3-1] ต้องใช้มุมมองและการแจ้งเตือนแบบ Heads-Up และทรัพยากรตามที่อธิบายไว้ในคลาส
Notification.Builder
API เมื่อแสดงการแจ้งเตือนแบบ Heads-Up - [C-3-2] ต้องแสดงการดำเนินการที่ระบุผ่าน
Notification.Builder.addAction()
พร้อมเนื้อหาการแจ้งเตือนโดยที่ผู้ใช้ไม่ต้องโต้ตอบเพิ่มเติม ตามที่อธิบายไว้ใน SDK
3.8.3.2. บริการฟังการแจ้งเตือน
Android มี NotificationListenerService
API ที่อนุญาตให้แอป (เมื่อผู้ใช้เปิดใช้อย่างชัดเจน) ได้รับสำเนาของการแจ้งเตือนทั้งหมดเมื่อมีการโพสต์หรืออัปเดต
การติดตั้งใช้งานอุปกรณ์
- [C-0-1] ต้องอัปเดตการแจ้งเตือนทั้งหมดอย่างถูกต้องและทันทีให้กับบริการผู้ฟังที่ติดตั้งและเปิดใช้โดยผู้ใช้ทั้งหมด รวมถึงข้อมูลเมตาทั้งหมดที่แนบมากับออบเจ็กต์การแจ้งเตือน
- [C-0-2] ต้องเป็นไปตามการเรียก
snoozeNotification()
API และปิดการแจ้งเตือนและโทรกลับหลังจากระยะเวลาเลื่อนการปลุกที่ตั้งไว้ในการเรียก API
หากการใช้งานอุปกรณ์ช่วยให้ผู้ใช้เลื่อนการแจ้งเตือนได้ ผู้ใช้จะทำสิ่งต่อไปนี้ได้
- [C-1-1] ต้องแสดงสถานะการแจ้งเตือนที่เลื่อนไปอย่างถูกต้องผ่าน API มาตรฐาน เช่น
NotificationListenerService.getSnoozedNotifications()
- [C-1-2] ต้องทำให้ผู้ใช้สามารถเลื่อนการแจ้งเตือนจากแอปของบุคคลที่สามที่ติดตั้งไว้แต่ละแอปได้ เว้นแต่ว่าจะเป็นการแจ้งเตือนจากบริการที่ทำงานอยู่เบื้องหน้า/แบบถาวร
3.8.3.3. DND (ห้ามรบกวน)
หากการติดตั้งใช้งานอุปกรณ์รองรับฟีเจอร์ DND อุปกรณ์จะดำเนินการต่อไปนี้
- [C-1-1] ต้องแสดงกฎ DND อัตโนมัติที่สร้างขึ้นโดยแอปพลิเคชันควบคู่ไปกับกฎที่ผู้ใช้สร้างขึ้นและกฎที่กำหนดไว้ล่วงหน้า เมื่อการติดตั้งใช้งานอุปกรณ์มีวิธีการให้ผู้ใช้อนุญาตให้หรือปฏิเสธไม่ให้แอปของบุคคลที่สามเข้าถึงการกำหนดค่านโยบาย DND
- [C-1-3] ต้องเป็นไปตามค่า
suppressedVisualEffects
ที่ส่งผ่านNotificationManager.Policy
และหากแอปตั้งค่า Flag SUPPRESSED_EFFECT_SCREEN_OFF หรือ SUPPRESSED_EFFECT_SCREEN_ON แอปควรแจ้งให้ผู้ใช้ทราบว่าระบบระงับเอฟเฟกต์ภาพในเมนูการตั้งค่า DND
3.8.4. Assist API
Android มี Assist API เพื่ออนุญาตให้แอปพลิเคชันเลือกปริมาณข้อมูลของบริบทปัจจุบันที่จะแชร์กับผู้ช่วยในอุปกรณ์
หากการติดตั้งใช้งานอุปกรณ์รองรับการดำเนินการ Assist อุปกรณ์จะดำเนินการต่อไปนี้
- [C-2-1] ต้องระบุให้ผู้ใช้ปลายทางทราบอย่างชัดเจนเมื่อมีการแชร์บริบท โดยทำอย่างใดอย่างหนึ่งต่อไปนี้
- ทุกครั้งที่แอปผู้ช่วยเข้าถึงบริบท ระบบจะแสดงแสงสีขาวรอบขอบของหน้าจอที่ตรงกับหรือนานกว่าระยะเวลาและความสว่างของการใช้งานโปรเจ็กต์โอเพนซอร์ส Android
- สําหรับแอปผู้ช่วยที่ติดตั้งไว้ล่วงหน้า ให้มอบโอกาสแก่ผู้ใช้ในการไปยังเมนูการตั้งค่าแอปผู้ช่วยและอินพุตเสียงเริ่มต้นได้ภายในการไปยังส่วนต่างๆ ไม่เกิน 2 ครั้ง และแชร์บริบทเฉพาะเมื่อผู้ใช้เรียกใช้แอปผู้ช่วยอย่างชัดเจนผ่านคีย์ลัดหรือคีย์การไปยังส่วนต่างๆ ของแอปผู้ช่วย
- [C-2-2] การโต้ตอบที่กําหนดไว้เพื่อเปิดแอปผู้ช่วยตามที่อธิบายไว้ในส่วนที่ 7.2.3 ต้องเปิดแอปผู้ช่วยที่ผู้ใช้เลือก กล่าวคือ แอปที่ใช้
VoiceInteractionService
หรือกิจกรรมที่จัดการ IntentACTION_ASSIST
3.8.5. การแจ้งเตือนและข้อความแจ้ง
แอปพลิเคชันสามารถใช้ Toast
API เพื่อแสดงสตริงแบบไม่โมดัลสั้นๆ ต่อผู้ใช้ปลายทาง ซึ่งจะหายไปหลังจากผ่านไประยะเวลาสั้นๆ และใช้ TYPE_APPLICATION_OVERLAY
API ประเภทหน้าต่างเพื่อแสดงหน้าต่างแจ้งเตือนเป็นการวางซ้อนเหนือแอปอื่นๆ
หากการติดตั้งใช้งานอุปกรณ์มีเอาต์พุตหน้าจอหรือวิดีโอ อุปกรณ์จะต้องมีลักษณะดังนี้
[C-1-1] ต้องให้ทางเลือกแก่ผู้ใช้ในการบล็อกแอปไม่ให้แสดงหน้าต่างการแจ้งเตือนที่ใช้
TYPE_APPLICATION_OVERLAY
การใช้งาน AOSP เป็นไปตามข้อกำหนดนี้โดยมีการควบคุมในแผงการแจ้งเตือน[C-1-2] ต้องปฏิบัติตาม Toast API และแสดง Toast จากแอปพลิเคชันต่อผู้ใช้ปลายทางในลักษณะที่มองเห็นได้ชัดเจน
3.8.6. ธีม
Android มี "ธีม" เป็นกลไกสำหรับแอปพลิเคชันที่จะใช้สไตล์ในทั้งกิจกรรมหรือแอปพลิเคชัน
Android มีชุดธีม "Holo" และ "Material" เป็นชุดสไตล์ที่กําหนดไว้สําหรับนักพัฒนาแอปพลิเคชันเพื่อใช้หากต้องการจับคู่รูปลักษณ์และความรู้สึกของธีม Holo ตามที่ Android SDK กําหนด
หากการติดตั้งใช้งานอุปกรณ์มีเอาต์พุตหน้าจอหรือวิดีโอ อุปกรณ์จะต้องมีลักษณะดังนี้
- [C-1-1] ต้องไม่เปลี่ยนแปลงแอตทริบิวต์ธีม Holo ที่แสดงต่อแอปพลิเคชัน
- [C-1-2] ต้องรองรับตระกูลธีม "Material" และห้ามแก้ไขแอตทริบิวต์ธีม Material หรือชิ้นงานที่แสดงต่อแอปพลิเคชัน
- [C-1-3] ต้องตั้งค่าแบบอักษร "แบบไม่มีส่วนหัว" เป็น Roboto เวอร์ชัน 2.x สำหรับภาษาที่ Roboto รองรับ หรือให้ทางเลือกแก่ผู้ใช้ในการเปลี่ยนแบบอักษรที่ใช้สำหรับแบบอักษร "แบบไม่มีส่วนหัว" เป็น Roboto เวอร์ชัน 2.x สำหรับภาษาที่ Roboto รองรับ
นอกจากนี้ Android ยังมีตระกูลธีม "ค่าเริ่มต้นของอุปกรณ์" เป็นชุดสไตล์ที่กําหนดไว้สําหรับนักพัฒนาแอปพลิเคชันเพื่อใช้หากต้องการจับคู่รูปลักษณ์ของธีมอุปกรณ์ตามที่ผู้ติดตั้งใช้งานอุปกรณ์กําหนด
- การติดตั้งใช้งานอุปกรณ์อาจแก้ไขแอตทริบิวต์ธีมเริ่มต้นของอุปกรณ์ที่แสดงต่อแอปพลิเคชัน
Android รองรับธีมรูปแบบต่างๆ ที่มีแถบระบบแบบโปร่งแสง ซึ่งช่วยให้นักพัฒนาแอปพลิเคชันเติมเนื้อหาแอปลงในบริเวณด้านหลังแถบสถานะและแถบนําทางได้ สิ่งสำคัญคือต้องคงสไตล์ไอคอนแถบสถานะไว้สำหรับการใช้งานในอุปกรณ์ต่างๆ เพื่อให้นักพัฒนาแอปได้รับประสบการณ์การใช้งานที่สอดคล้องกันในการกำหนดค่านี้
หากการติดตั้งใช้งานอุปกรณ์มีแถบสถานะของระบบ อุปกรณ์จะมีลักษณะดังนี้
- [C-2-1] ต้องใช้สีขาวสำหรับไอคอนสถานะของระบบ (เช่น ระดับสัญญาณและระดับแบตเตอรี่) และการแจ้งเตือนที่ระบบสร้างขึ้น เว้นแต่ว่าไอคอนจะบ่งบอกถึงสถานะที่เป็นปัญหาหรือแอปขอแถบสถานะแบบสว่างโดยใช้ Flag WindowInsetsController#APPEARANCE_LIGHT_STATUS_BARS
- [C-2-2] การติดตั้งใช้งานอุปกรณ์ Android จะต้องเปลี่ยนสีไอคอนสถานะของระบบเป็นสีดํา (ดูรายละเอียดที่ R.style) เมื่อแอปขอแถบสถานะแบบสว่าง
3.8.7. วอลเปเปอร์เคลื่อนไหว
Android กําหนดประเภทคอมโพเนนต์และ API รวมถึงวงจรที่เกี่ยวข้องซึ่งช่วยให้แอปพลิเคชันแสดง"วอลเปเปอร์เคลื่อนไหว" อย่างน้อย 1 รายการต่อผู้ใช้ปลายทาง วอลเปเปอร์เคลื่อนไหวคือภาพเคลื่อนไหว ลาย หรือรูปภาพที่คล้ายกันซึ่งมีความสามารถในการป้อนข้อมูลแบบจำกัดซึ่งแสดงเป็นวอลเปเปอร์อยู่หลังแอปพลิเคชันอื่นๆ
ระบบจะถือว่าฮาร์ดแวร์สามารถใช้งานวอลเปเปอร์ภาพเคลื่อนไหวได้อย่างเสถียรหากสามารถใช้งานวอลเปเปอร์ภาพเคลื่อนไหวทั้งหมดได้โดยไม่มีข้อจำกัดด้านฟังก์ชันการทำงานที่อัตราเฟรมที่เหมาะสมโดยไม่ส่งผลเสียต่อแอปพลิเคชันอื่นๆ หากข้อจำกัดของฮาร์ดแวร์ทําให้วอลเปเปอร์และ/หรือแอปพลิเคชันขัดข้อง ทำงานผิดปกติ ใช้พลังงาน CPU หรือแบตเตอรี่มากเกินไป หรือทํางานด้วยอัตราเฟรมที่ต่ำจนยอมรับไม่ได้ ระบบจะถือว่าฮาร์ดแวร์ดังกล่าวไม่สามารถใช้งานวอลเปเปอร์แบบเคลื่อนไหวได้ ตัวอย่างเช่น วอลเปเปอร์เคลื่อนไหวบางรายการอาจใช้บริบท OpenGL 2.0 หรือ 3.x เพื่อแสดงผลเนื้อหา วอลเปเปอร์สดจะไม่ทำงานอย่างเสถียรในฮาร์ดแวร์ที่ไม่รองรับบริบท OpenGL หลายรายการ เนื่องจากการใช้บริบท OpenGL ของวอลเปเปอร์สดอาจขัดแย้งกับแอปพลิเคชันอื่นๆ ที่ใช้บริบท OpenGL ด้วย
- การติดตั้งใช้งานอุปกรณ์ที่เรียกใช้วอลเปเปอร์เคลื่อนไหวได้อย่างเสถียรตามที่อธิบายไว้ข้างต้นควรใช้วอลเปเปอร์เคลื่อนไหว
หากการติดตั้งใช้งานอุปกรณ์ใช้วอลเปเปอร์เคลื่อนไหว อุปกรณ์จะมีลักษณะดังนี้
- [C-1-1] ต้องรายงาน Flag ฟีเจอร์แพลตฟอร์ม android.software.live_wallpaper
3.8.8. การเปลี่ยนกิจกรรม
แหล่งที่มาของโค้ด Android เวอร์ชันอัปสตรีมประกอบด้วยหน้าจอภาพรวม ซึ่งเป็นอินเทอร์เฟซผู้ใช้ระดับระบบสำหรับการสลับงานและแสดงกิจกรรมและงานที่เข้าถึงล่าสุดโดยใช้ภาพขนาดย่อของสถานะแบบกราฟิกของแอปพลิเคชัน ณ เวลาที่ผู้ใช้ออกจากแอปพลิเคชันครั้งล่าสุด
การติดตั้งใช้งานอุปกรณ์ รวมถึงแป้นการไปยังส่วนต่างๆ ของฟังก์ชันล่าสุดตามที่ระบุไว้ในส่วนที่ 7.2.3 อาจทำให้อินเทอร์เฟซมีการเปลี่ยนแปลง
หากการใช้งานอุปกรณ์รวมถึงปุ่มการไปยังส่วนต่างๆ ของฟังก์ชันล่าสุดตามที่ระบุไว้ในรายละเอียดของส่วนที่ 7.2.3 เปลี่ยนแปลงอินเทอร์เฟซ อุปกรณ์จะต้องมีลักษณะดังนี้
- [C-1-1] ต้องรองรับกิจกรรมที่แสดงอย่างน้อย 7 รายการ
- ควรแสดงชื่อกิจกรรมอย่างน้อย 4 รายการพร้อมกัน
- [C-1-2] ต้องใช้ลักษณะการปักหมุดหน้าจอและจัดให้มีเมนูการตั้งค่าให้ผู้ใช้เพื่อเปิด/ปิดฟีเจอร์
- ควรแสดงสีไฮไลต์ ไอคอน ชื่อหน้าจอในส่วนล่าสุด
- ควรแสดงการอำนวยความสะดวกในการปิด ("x") แต่อาจเลื่อนการแสดงออกจนกว่าผู้ใช้จะโต้ตอบกับหน้าจอ
- ควรใช้แป้นพิมพ์ลัดเพื่อเปลี่ยนไปใช้กิจกรรมก่อนหน้าได้อย่างง่ายดาย
- ควรทริกเกอร์การดำเนินการสลับอย่างรวดเร็วระหว่างแอป 2 รายการที่ใช้ล่าสุด เมื่อแตะแป้นฟังก์ชัน "ล่าสุด" 2 ครั้ง
- ควรทริกเกอร์โหมดหลายหน้าต่างแบบแยกหน้าจอ (หากรองรับ) เมื่อกดแป้นฟังก์ชัน "ล่าสุด" ค้างไว้
- อาจแสดงรายการล่าสุดที่เกี่ยวข้องเป็นกลุ่มที่เลื่อนไปด้วยกัน
- [SR-1] ขอแนะนำอย่างยิ่งให้ใช้อินเทอร์เฟซผู้ใช้ Android ต้นทาง (หรืออินเทอร์เฟซที่คล้ายกันซึ่งใช้ภาพขนาดย่อ) สำหรับหน้าจอภาพรวม
3.8.9. การจัดการอินพุต
Android รองรับการจัดการอินพุตและรองรับเครื่องมือแก้ไขวิธีการป้อนข้อมูลของบุคคลที่สาม
หากการติดตั้งใช้งานอุปกรณ์อนุญาตให้ผู้ใช้ใช้วิธีการป้อนข้อมูลของบุคคลที่สามในอุปกรณ์ ผู้ใช้จะทำสิ่งต่อไปนี้ได้
- [C-1-1] ต้องประกาศฟีเจอร์แพลตฟอร์ม android.software.input_methods และรองรับ IME API ตามที่ระบุไว้ในเอกสารประกอบ Android SDK
3.8.10. การควบคุมสื่อบนหน้าจอล็อก
ระบบเลิกใช้งาน Remote Control Client API ตั้งแต่ Android 5.0 เป็นต้นไปเพื่อหันมาใช้เทมเพลตการแจ้งเตือนสื่อซึ่งช่วยให้แอปพลิเคชันสื่อผสานรวมกับตัวควบคุมการเล่นที่แสดงบนหน้าจอล็อกได้
3.8.11. ภาพพักหน้าจอ (ก่อนหน้านี้เรียกว่า "ความฝัน")
ดูการตั้งค่าส่วนที่ 3.2.3.5 เพื่อกำหนดค่าการแสดงภาพพักหน้าจอ
3.8.12. ตำแหน่ง
หากการติดตั้งใช้งานอุปกรณ์มีเซ็นเซอร์ฮาร์ดแวร์ (เช่น GPS) ที่สามารถระบุพิกัดตำแหน่งได้
- [C-1-2] ต้องแสดงสถานะปัจจุบันของตำแหน่งในเมนูตำแหน่งภายในการตั้งค่า
- [C-1-3] ต้องไม่แสดงโหมดตำแหน่งในเมนูตำแหน่งภายในการตั้งค่า
3.8.13. Unicode และแบบอักษร
Android รองรับอักขระอีโมจิที่ระบุไว้ใน Unicode 10.0
หากการติดตั้งใช้งานอุปกรณ์มีเอาต์พุตหน้าจอหรือวิดีโอ อุปกรณ์จะต้องมีลักษณะดังนี้
- [C-1-1] ต้องแสดงผลอักขระอีโมจิเหล่านี้เป็นสัญลักษณ์สีได้
- [C-1-2] ต้องรองรับสิ่งต่อไปนี้
- แบบอักษร Roboto 2 ที่มีน้ำหนักต่างกัน ได้แก่ sans-serif-thin, sans-serif-light, sans-serif-medium, sans-serif-black, sans-serif-condensed, sans-serif-condensed-light สำหรับภาษาที่มีในอุปกรณ์
- ครอบคลุมอักขระละติน กรีก และซีริลลิกทั้งหมดของ Unicode 7.0 รวมถึงช่วงอักขระละตินแบบขยาย A, B, C และ D และสัญลักษณ์ทั้งหมดในบล็อกสัญลักษณ์สกุลเงินของ Unicode 7.0
- [C-1-3] ต้องไม่นำออกหรือแก้ไข NotoColorEmoji.tff ในภาพระบบ (คุณสามารถเพิ่มแบบอักษรอีโมจิใหม่เพื่อลบล้างอีโมจิในไฟล์ NotoColorEmoji.tff ได้)
- ควรรองรับอีโมจิสีผิวและครอบครัวที่หลากหลายตามที่ระบุไว้ในรายงานทางเทคนิคของ Unicode #51
หากการติดตั้งใช้งานอุปกรณ์มี IME อุปกรณ์จะมีลักษณะดังนี้
- ควรระบุวิธีการป้อนข้อมูลสำหรับอักขระอีโมจิเหล่านี้ให้แก่ผู้ใช้
Android รองรับการแสดงผลแบบอักษรเมียนมา เมียนมามีแบบอักษรที่ไม่เป็นไปตามมาตรฐาน Unicode หลายแบบ ซึ่งมักเรียกว่า "ซอคยี" สำหรับการแสดงผลภาษาเมียนมา
หากการติดตั้งใช้งานอุปกรณ์รองรับภาษาพม่า อุปกรณ์จะมีลักษณะดังนี้
- [C-2-1] ต้องแสดงผลข้อความด้วยแบบอักษรที่เป็นไปตาม Unicode เป็นค่าเริ่มต้น ต้องไม่ตั้งค่าแบบอักษรที่ไม่เป็นไปตาม Unicode เป็นแบบอักษรเริ่มต้น เว้นแต่ว่าผู้ใช้จะเลือกแบบอักษรนั้นในเครื่องมือเลือกภาษา
- [C-2-2] ต้องรองรับแบบอักษร Unicode และแบบอักษรที่ไม่เป็นไปตามข้อกำหนด Unicode หากอุปกรณ์รองรับแบบอักษรที่ไม่เป็นไปตามข้อกำหนด Unicode แบบอักษรที่ไม่เป็นไปตามข้อกำหนดของ Unicode ต้องไม่นำออกหรือเขียนทับแบบอักษร Unicode
- [C-2-3] ต้องแสดงผลข้อความด้วยแบบอักษรที่ไม่เป็นไปตามมาตรฐาน Unicode เฉพาะในกรณีที่มีการระบุ รหัสภาษาที่มีรหัสสคริปต์ Qaag (เช่น my-Qaag) คุณไม่สามารถใช้รหัสภาษาหรือรหัสภูมิภาค ISO อื่นๆ (ไม่ว่าจะกำหนดหรือไม่กำหนดหรือสงวนไว้) เพื่ออ้างอิงแบบอักษรที่ไม่เป็นไปตามมาตรฐาน Unicode สำหรับเมียนมาร์ นักพัฒนาแอปและผู้เขียนหน้าเว็บสามารถระบุ my-Qaag เป็นรหัสภาษาที่กำหนดได้เช่นเดียวกับภาษาอื่นๆ
3.8.14. หลายหน้าต่าง
หากการติดตั้งใช้งานอุปกรณ์มีความสามารถในการแสดงกิจกรรมหลายรายการพร้อมกัน อุปกรณ์จะทําสิ่งต่อไปนี้
- [C-1-1] ต้องใช้งานโหมดหลายหน้าต่างดังกล่าวตามลักษณะการทํางานของแอปพลิเคชันและ API ที่อธิบายไว้ในเอกสารประกอบการสนับสนุนโหมดหลายหน้าต่างของ Android SDK และเป็นไปตามข้อกําหนดต่อไปนี้
- [C-1-2] ต้องปฏิบัติตาม
android:resizeableActivity
ที่แอปตั้งค่าไว้ในไฟล์AndroidManifest.xml
ตามที่อธิบายไว้ในSDK นี้ - [C-1-3] ต้องไม่มีโหมดแยกหน้าจอหรือโหมดอิสระหากความสูงของหน้าจอน้อยกว่า 440 dp และความกว้างของหน้าจอน้อยกว่า 440 dp
- [C-1-4] กิจกรรมต้องไม่ปรับขนาดให้เล็กกว่า 220dp ในโหมดหลายหน้าต่างที่ไม่ใช่โหมดภาพในภาพ
- การใช้งานอุปกรณ์ที่มีขนาดหน้าจอ
xlarge
ควรรองรับโหมดรูปแบบอิสระ
หากการติดตั้งใช้งานอุปกรณ์รองรับโหมดหลายหน้าต่างและโหมดแยกหน้าจอ อุปกรณ์จะมีลักษณะดังนี้
- [C-2-2] ต้องครอบตัดกิจกรรมที่เชื่อมต่อกับแท่นชาร์จของหลายหน้าต่างแบบแยกหน้าจอ แต่ควรแสดงเนื้อหาบางส่วนของกิจกรรมนั้น หากแอป Launcher เป็นหน้าต่างที่มีโฟกัส
- [C-2-3] ต้องปฏิบัติตามค่า
AndroidManifestLayout_minWidth
และAndroidManifestLayout_minHeight
ที่ประกาศไว้ของแอปพลิเคชัน Launcher ของบุคคลที่สาม และไม่ลบล้างค่าเหล่านี้ในระหว่างการแสดงเนื้อหาบางอย่างของกิจกรรมที่เชื่อมต่อ
หากการติดตั้งใช้งานอุปกรณ์รองรับโหมดหลายหน้าต่างและโหมดภาพในภาพ อุปกรณ์จะมีลักษณะดังนี้
[C-3-1] ต้องเปิดกิจกรรมในโหมดหลายหน้าต่างของการแสดงภาพซ้อนภาพ เมื่อแอปมีลักษณะดังนี้
- กําหนดเป้าหมายเป็น API ระดับ 26 ขึ้นไปและประกาศ
android:supportsPictureInPicture
- กําหนดเป้าหมายเป็น API ระดับ 25 หรือต่ำกว่า และประกาศทั้ง
android:resizeableActivity
และandroid:supportsPictureInPicture
- กําหนดเป้าหมายเป็น API ระดับ 26 ขึ้นไปและประกาศ
[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 มี ControlsProviderService
และ Control
API เพื่ออนุญาตให้แอปพลิเคชันของบุคคลที่สามเผยแพร่การควบคุมอุปกรณ์เพื่อแสดงสถานะและการดำเนินการอย่างรวดเร็วสำหรับผู้ใช้
ดูข้อกำหนดเฉพาะของอุปกรณ์ได้ที่ส่วน 2_2_3
3.9. การดูแลระบบของอุปกรณ์
Android มีฟีเจอร์ที่ช่วยให้แอปพลิเคชันที่คำนึงถึงความปลอดภัยสามารถดำเนินการด้านการดูแลระบบอุปกรณ์ที่ระดับระบบ เช่น การบังคับใช้นโยบายรหัสผ่านหรือการดำเนินการล้างข้อมูลระยะไกล ผ่าน Android Device Administration API
หากการติดตั้งใช้งานอุปกรณ์ใช้นโยบายการดูแลระบบอุปกรณ์ทั้งหมดที่ระบุไว้ในเอกสารประกอบ Android SDK การดำเนินการต่อไปนี้จะเกิดขึ้น
- [C-1-1] ต้องประกาศ
android.software.device_admin
- [C-1-2] ต้องรองรับการจัดสรรอุปกรณ์สำหรับเจ้าของอุปกรณ์ตามที่อธิบายไว้ในส่วนที่ 3.9.1 และส่วนที่ 3.9.1.1
3.9.1 การจัดสรรอุปกรณ์
3.9.1.1 การจัดเตรียมเจ้าของอุปกรณ์
หากการติดตั้งใช้งานอุปกรณ์ประกาศ android.software.device_admin
อุปกรณ์จะมีลักษณะดังนี้
- [C-1-1] ต้องรองรับการลงทะเบียนไคลเอ็นต์นโยบายอุปกรณ์ (DPC) เป็นแอปเจ้าของอุปกรณ์ตามที่อธิบายไว้ด้านล่าง
- เมื่อการติดตั้งใช้งานอุปกรณ์ยังไม่ได้กําหนดค่าข้อมูลผู้ใช้ ระบบจะดำเนินการดังนี้
- [C-1-5] ต้องลงทะเบียนแอปพลิเคชัน DPC เป็นแอปเจ้าของอุปกรณ์หากอุปกรณ์ประกาศการรองรับ Near Field Communication (NFC) ผ่าน Flag ฟีเจอร์
android.hardware.nfc
และได้รับข้อความ NFC ที่มีระเบียนประเภท MIMEMIME_TYPE_PROVISIONING_NFC
- [C-1-8] ต้องส่ง Intent ACTION_GET_PROVISIONING_MODE หลังจากที่มีการทริกเกอร์การจัดเตรียมอุปกรณ์เจ้าของเพื่อให้แอป DPC เลือกได้ว่าจะเป็นผู้ดูแลอุปกรณ์หรือเจ้าของโปรไฟล์ เว้นแต่ว่าจะสามารถระบุจากบริบทได้ว่ามีตัวเลือกที่ถูกต้องเพียงตัวเลือกเดียว (เช่น สำหรับการมอบสิทธิ์ตาม NFC ที่ไม่รองรับการจัดเตรียมเจ้าของโปรไฟล์)
- [C-1-9] ต้องส่งความตั้งใจ ACTION_ADMIN_POLICY_COMPLIANCE ไปยังแอปเจ้าของอุปกรณ์หากมีการตั้งค่าเจ้าของอุปกรณ์ในระหว่างการจัดสรร ไม่ว่าจะใช้วิธีการจัดสรรใดก็ตาม ผู้ใช้ต้องดำเนินการในวิซาร์ดการตั้งค่าไม่ได้จนกว่าแอปเจ้าของอุปกรณ์จะเสร็จสิ้น
- [C-1-5] ต้องลงทะเบียนแอปพลิเคชัน DPC เป็นแอปเจ้าของอุปกรณ์หากอุปกรณ์ประกาศการรองรับ Near Field Communication (NFC) ผ่าน Flag ฟีเจอร์
- เมื่อการติดตั้งใช้งานอุปกรณ์มีข้อมูลผู้ใช้ ระบบจะดำเนินการดังนี้
- [C-1-7] ต้องไม่ลงทะเบียนแอปพลิเคชัน DPC เป็นแอปเจ้าของอุปกรณ์อีกต่อไป
- เมื่อการติดตั้งใช้งานอุปกรณ์ยังไม่ได้กําหนดค่าข้อมูลผู้ใช้ ระบบจะดำเนินการดังนี้
- [C-1-2] ต้องกำหนดให้มีการดำเนินการบางอย่างที่แสดงการยอมรับก่อนหรือระหว่างกระบวนการจัดสรรเพื่อยินยอมให้ตั้งค่าแอปเป็นเจ้าของอุปกรณ์ ความยินยอมอาจมาจากการกระทำของผู้ใช้หรือจากวิธีการแบบเป็นโปรแกรม แต่ต้องแสดงประกาศการเปิดเผยข้อมูลที่เหมาะสม (ตามที่อ้างอิงใน AOSP) ก่อนเริ่มการจัดสรรอุปกรณ์ให้แก่เจ้าของอุปกรณ์ นอกจากนี้ กลไกความยินยอมของเจ้าของอุปกรณ์แบบเป็นโปรแกรมที่ใช้ (โดยองค์กร) สำหรับการมอบสิทธิ์เจ้าของอุปกรณ์ต้องไม่รบกวนประสบการณ์การใช้งานทันทีสําหรับการใช้งานที่ไม่ใช่องค์กร
- [C-1-3] ต้องไม่เขียนโค้ดความยินยอมแบบฮาร์ดโค้ดหรือป้องกันไม่ให้ใช้แอปอื่นๆ ของเจ้าของเครื่อง
หากการติดตั้งใช้งานอุปกรณ์ประกาศ android.software.device_admin
แต่ยังมีโซลูชันการจัดการเจ้าของอุปกรณ์ที่เป็นกรรมสิทธิ์และระบุกลไกในการโปรโมตแอปพลิเคชันที่กําหนดค่าไว้ในโซลูชันของตนเป็น "เจ้าของอุปกรณ์ที่เทียบเท่า" กับ "เจ้าของอุปกรณ์" มาตรฐานตามที่ Android DevicePolicyManager API มาตรฐานยอมรับ การดำเนินการดังกล่าวจะต้องมีลักษณะดังนี้
- [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] กระบวนการจัดสรรโปรไฟล์ที่จัดการ (ขั้นตอนที่ DPC เริ่มต้นโดยใช้ android.app.action.PROVISION_MANAGED_PROFILE) หรือโดยแพลตฟอร์ม) หน้าจอขอความยินยอม และประสบการณ์ของผู้ใช้ต้องสอดคล้องกับการใช้งาน AOSP
[C-1-3] ต้องระบุสิ่งต่างๆ ต่อไปนี้ใน "การตั้งค่า" เพื่อบ่งบอกให้ผู้ใช้ทราบเมื่อตัวควบคุมนโยบายอุปกรณ์ (DPC) ปิดใช้ฟังก์ชันของระบบบางอย่าง
- ไอคอนหรือสิ่งอำนวยความสะดวกอื่นๆ ที่สอดคล้องกันสำหรับผู้ใช้ (เช่น ไอคอนข้อมูล AOSP ต้นทาง) เพื่อแสดงเมื่อผู้ดูแลอุปกรณ์จํากัดการตั้งค่าบางอย่าง
- ข้อความอธิบายสั้นๆ ตามที่ระบุโดยผู้ดูแลระบบอุปกรณ์ผ่าน
setShortSupportMessage
- ไอคอนแอปพลิเคชัน DPC
[C-1-4] ต้องเปิดใช้งานตัวแฮนเดิลสำหรับ Intent ACTION_PROVISIONING_SUCCESSFUL ในโปรไฟล์งานหากมีการสร้างเจ้าของโปรไฟล์เมื่อเริ่มการกําหนดค่าโดย Intent android.app.action.PROVISION_MANAGED_PROFILE และ DPC ได้ใช้ตัวแฮนเดิล
[C-1-5] ต้องส่งการออกอากาศ ACTION_PROFILE_PROVISIONING_COMPLETE ไปยัง DPC ของโปรไฟล์งานเมื่อมีการเริ่มการจัดเตรียมโดย Intent android.app.action.PROVISION_MANAGED_PROFILE
[C-1-6] ต้องส่ง Intent ACTION_GET_PROVISIONING_MODE หลังจากที่มีการเรียกให้แสดงการจัดสรรเจ้าของโปรไฟล์เพื่อให้แอป DPC เลือกได้ว่าจะเป็นเจ้าของอุปกรณ์หรือเจ้าของโปรไฟล์ ยกเว้นในกรณีที่มีการเรียกให้แสดงการจัดสรรโดย Intent android.app.action.PROVISION_MANAGED_PROFILE
[C-1-7] ต้องส่ง Intent ACTION_ADMIN_POLICY_COMPLIANCE ไปยังโปรไฟล์งานเมื่อมีการสร้างเจ้าของโปรไฟล์ระหว่างการจัดเตรียม ไม่ว่าจะใช้วิธีการจัดเตรียมใดก็ตาม ยกเว้นในกรณีที่ Intent android.app.action.PROVISION_MANAGED_PROFILE ทริกเกอร์การจัดเตรียม ผู้ใช้ต้องดำเนินการในวิซาร์ดการตั้งค่าไม่ได้จนกว่าแอป Profile Admin จะเสร็จสิ้น
[C-1-8] ต้องส่ง ACTION_MANAGED_PROFILE_PROVISIONED ที่ออกอากาศไปยัง DPC ของโปรไฟล์ส่วนบุคคลเมื่อสร้างเจ้าของโปรไฟล์แล้ว ไม่ว่าจะใช้วิธีการจัดสรรใดก็ตาม
3.9.2 การรองรับโปรไฟล์ที่มีการจัดการ
หากการติดตั้งใช้งานอุปกรณ์ประกาศ android.software.managed_users
อุปกรณ์จะมีลักษณะดังนี้
- [C-1-1] ต้องรองรับโปรไฟล์ที่มีการจัดการผ่าน
android.app.admin.DevicePolicyManager
API - [C-1-2] ต้องอนุญาตให้สร้างโปรไฟล์ที่จัดการได้เพียงโปรไฟล์เดียว
- [C-1-3] ต้องใช้ป้ายไอคอน (คล้ายกับป้ายงานเวอร์ชันต้นทางของ AOSP) เพื่อแสดงแอปพลิเคชันและวิดเจ็ตที่มีการจัดการ รวมถึงองค์ประกอบ UI อื่นๆ ที่มีป้าย เช่น ล่าสุดและการแจ้งเตือน
- [C-1-4] ต้องแสดงไอคอนการแจ้งเตือน (คล้ายกับป้ายเวอร์ชันที่พัฒนาขึ้นต้นของ AOSP) เพื่อระบุว่าผู้ใช้อยู่ในแอปพลิเคชันโปรไฟล์ที่จัดการ
- [C-1-6] หากมีโปรไฟล์ที่มีการจัดการ จะต้องแสดงสิ่งอำนวยความสะดวกที่มองเห็นได้ใน "เครื่องมือเลือก" Intent เพื่ออนุญาตให้ผู้ใช้ส่งต่อ Intent จากโปรไฟล์ที่มีการจัดการไปยังผู้ใช้หลักหรือในทางกลับกัน หาก Device Policy Controller เปิดใช้
- [C-1-7] ในกรณีที่มีโปรไฟล์ที่มีการจัดการ จะต้องแสดงสิ่งต่างๆ ต่อไปนี้สำหรับผู้ใช้ทั้งผู้ใช้หลักและโปรไฟล์ที่มีการจัดการ
- แยกการนับแบตเตอรี่ ตำแหน่ง อินเทอร์เน็ตมือถือ และพื้นที่เก็บข้อมูลสำหรับผู้ใช้หลักและโปรไฟล์ที่มีการจัดการ
- การจัดการแอปพลิเคชัน VPN ที่ติดตั้งภายในโปรไฟล์ผู้ใช้หลักหรือโปรไฟล์ที่มีการจัดการอย่างอิสระ
- การจัดการแอปพลิเคชันที่ติดตั้งภายในโปรไฟล์ผู้ใช้หลักหรือโปรไฟล์ที่มีการจัดการอย่างอิสระ
- การจัดการบัญชีภายในผู้ใช้หลักหรือโปรไฟล์ที่มีการจัดการอย่างอิสระ
- [C-1-8] ต้องตรวจสอบว่าแอปพลิเคชันโทรศัพท์ รายชื่อติดต่อ และการรับส่งข้อความที่ติดตั้งไว้ล่วงหน้าสามารถค้นหาและดูข้อมูลผู้โทรจากโปรไฟล์ที่จัดการ (หากมี) ควบคู่ไปกับข้อมูลจากโปรไฟล์หลักได้ หากเครื่องมือควบคุมนโยบายอุปกรณ์อนุญาต
- [C-1-9] ต้องตรวจสอบว่าโปรไฟล์เป็นไปตามข้อกำหนดด้านความปลอดภัยทั้งหมดที่ใช้ได้กับอุปกรณ์ที่เปิดใช้ผู้ใช้หลายคน (ดูส่วนที่ 9.5) แม้ว่าโปรไฟล์ที่มีการจัดการจะไม่นับเป็นผู้ใช้รายอื่นนอกเหนือจากผู้ใช้หลัก
หากการติดตั้งใช้งานอุปกรณ์ประกาศ android.software.managed_users
และ
android.software.secure_lock_screen
อุปกรณ์จะมีลักษณะดังนี้
- [C-2-1] ต้องรองรับการกำหนดหน้าจอล็อกแยกต่างหากที่เป็นไปตามข้อกำหนดต่อไปนี้เพื่อให้สิทธิ์เข้าถึงแอปที่ทำงานในโปรไฟล์ที่มีการจัดการเท่านั้น
- การติดตั้งใช้งานอุปกรณ์ต้องเป็นไปตามความตั้งใจของ
DevicePolicyManager.ACTION_SET_NEW_PASSWORD
และแสดงอินเทอร์เฟซเพื่อกำหนดค่าข้อมูลเข้าสู่ระบบหน้าจอล็อกแยกต่างหากสำหรับโปรไฟล์ที่จัดการ - ข้อมูลเข้าสู่ระบบของหน้าจอล็อกของโปรไฟล์ที่จัดการต้องใช้กลไกการจัดเก็บและการจัดการข้อมูลเข้าสู่ระบบเดียวกับโปรไฟล์หลัก ตามที่ระบุไว้ในเว็บไซต์โปรเจ็กต์โอเพนซอร์ส Android
- นโยบายรหัสผ่านของ DPC ต้องใช้กับข้อมูลเข้าสู่ระบบหน้าจอล็อกของโปรไฟล์ที่มีการจัดการเท่านั้น เว้นแต่จะมีการเรียกใช้อินสแตนซ์
DevicePolicyManager
ที่แสดงผลโดย getParentProfileInstance
- การติดตั้งใช้งานอุปกรณ์ต้องเป็นไปตามความตั้งใจของ
- เมื่อรายชื่อติดต่อจากโปรไฟล์ที่มีการจัดการแสดงในบันทึกการโทรที่ติดตั้งไว้ล่วงหน้า, UI ขณะโทร, การแจ้งเตือนสายเรียกเข้าและสายที่ไม่ได้รับ, แอปรายชื่อติดต่อและการรับส่งข้อความ แอปเหล่านั้นควรมีป้ายเดียวกันกับที่ใช้ระบุแอปพลิเคชันโปรไฟล์ที่มีการจัดการ
3.9.3 การสนับสนุนผู้ใช้ที่มีการจัดการ
หากการติดตั้งใช้งานอุปกรณ์ประกาศ android.software.managed_users
อุปกรณ์จะมีลักษณะดังนี้
- [C-1-1] ต้องให้ทางเลือกแก่ผู้ใช้ในการออกจากระบบของผู้ใช้ปัจจุบันและเปลี่ยนไปใช้ผู้ใช้หลักในเซสชันผู้ใช้หลายคนเมื่อ
isLogoutEnabled
แสดงผลtrue
ผู้ใช้ต้องเข้าถึงสิ่งอำนวยความสะดวกจากหน้าจอล็อกได้โดยไม่ต้องปลดล็อกอุปกรณ์
หากการติดตั้งใช้งานอุปกรณ์ประกาศ android.software.device_admin
และระบุสิ่งที่ผู้ใช้สามารถทำได้ในอุปกรณ์เพื่อเพิ่มผู้ใช้รอง ผู้ใช้จะทำสิ่งต่อไปนี้ได้
- [C-SR-1] ขอแนะนำอย่างยิ่งให้แสดงการเปิดเผยความยินยอมของเจ้าของอุปกรณ์ AOSP เดียวกันกับที่แสดงในขั้นตอนที่เริ่มต้นโดย android.app.action.PROVISION_MANAGED_DEVICE ก่อนที่จะอนุญาตให้เพิ่มบัญชีในผู้ใช้รองรายใหม่ เพื่อให้ผู้ใช้ทราบว่าอุปกรณ์มีการจัดการ
3.10. การช่วยเหลือพิเศษ
Android มีเลเยอร์การช่วยเหลือพิเศษที่ช่วยให้ผู้ใช้ที่พิการไปยังส่วนต่างๆ ของอุปกรณ์ได้ง่ายขึ้น นอกจากนี้ Android ยังมี API แพลตฟอร์มที่ช่วยให้การติดตั้งใช้งานบริการการช่วยเหลือพิเศษสามารถรับการเรียกกลับสำหรับเหตุการณ์ของผู้ใช้และระบบ รวมถึงสร้างกลไกการแสดงผลผลป้อนกลับทางเลือก เช่น การอ่านออกเสียงข้อความ การสั่นเพื่อแจ้งผลป้อนกลับ และการไปยังส่วนต่างๆ ด้วยแทร็กบอล/ปุ่มบังคับทิศทาง
หากการติดตั้งใช้งานอุปกรณ์รองรับบริการการช่วยเหลือพิเศษของบุคคลที่สาม อุปกรณ์จะมีลักษณะดังนี้
- [C-1-1] ต้องใช้งานเฟรมเวิร์กการช่วยเหลือพิเศษของ Android ตามที่อธิบายไว้ในเอกสารประกอบของ Accessibility API SDK
- [C-1-2] ต้องสร้างเหตุการณ์การช่วยเหลือพิเศษและส่ง
AccessibilityEvent
ที่เหมาะสมไปยังการติดตั้งใช้งานAccessibilityService
ทั้งหมดที่ลงทะเบียนไว้ตามที่ระบุไว้ใน SDK - [C-1-4] ต้องให้สิ่งอํานวยความสะดวกแก่ผู้ใช้ในการควบคุมบริการการช่วยเหลือพิเศษที่ประกาศ AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_BUTTON โปรดทราบว่าสำหรับการติดตั้งใช้งานอุปกรณ์ที่มีแถบนําทางของระบบ อุปกรณ์ควรอนุญาตให้ผู้ใช้มีตัวเลือกปุ่มในแถบนําทางของระบบเพื่อควบคุมบริการเหล่านี้
หากการติดตั้งใช้งานอุปกรณ์มีบริการการช่วยเหลือพิเศษที่ติดตั้งไว้ล่วงหน้า อุปกรณ์จะมีลักษณะดังนี้
- [C-2-1] ต้องติดตั้งบริการการช่วยเหลือพิเศษที่ติดตั้งไว้ล่วงหน้าเหล่านี้เป็นแอปDirect Boot Aware เมื่อพื้นที่เก็บข้อมูลได้รับการเข้ารหัสด้วยการเข้ารหัสตามไฟล์ (FBE)
- ควรมีกลไกในขั้นตอนการตั้งค่าแบบพร้อมใช้งานทันทีเพื่อให้ผู้ใช้เปิดใช้บริการการช่วยเหลือพิเศษที่เกี่ยวข้อง รวมถึงตัวเลือกในการปรับขนาดแบบอักษร ขนาดการแสดงผล และท่าทางสัมผัสสำหรับการขยาย
3.11. การอ่านออกเสียงข้อความ
Android มี API ที่อนุญาตให้แอปพลิเคชันใช้บริการการอ่านออกเสียงข้อความ (TTS) และอนุญาตให้ผู้ให้บริการติดตั้งใช้งานบริการ TTS
หากการติดตั้งใช้งานอุปกรณ์รายงานฟีเจอร์ android.hardware.audio.output อุปกรณ์จะมีลักษณะดังนี้
- [C-1-1] ต้องรองรับ API ของเฟรมเวิร์ก TTS ของ Android
หากการติดตั้งใช้งานอุปกรณ์รองรับการติดตั้งเครื่องมือ TTS ของบุคคลที่สาม อุปกรณ์จะดำเนินการต่อไปนี้
- [C-2-1] ต้องให้สิ่งอํานวยความสะดวกแก่ผู้ใช้เพื่อให้ผู้ใช้เลือกเครื่องมือ TTS ที่จะใช้ในระบบได้
3.12. เฟรมเวิร์กอินพุตทีวี
Android Television Input Framework (TIF) ช่วยให้การส่งเนื้อหาสดไปยังอุปกรณ์ Android Television ง่ายขึ้น TIF มี API มาตรฐานสำหรับสร้างข้อบังคับของอินพุตที่ควบคุมอุปกรณ์ Android Television
หากการติดตั้งใช้งานอุปกรณ์รองรับ TIF อุปกรณ์จะดำเนินการต่อไปนี้
- [C-1-1] ต้องประกาศฟีเจอร์แพลตฟอร์ม
android.software.live_tv
- [C-1-2] ต้องรองรับ TIF API ทั้งหมดเพื่อให้ติดตั้งและใช้บริการอินพุต TIF ของบุคคลที่สามในแอปพลิเคชันที่ใช้ API เหล่านี้ได้
3.13. การตั้งค่าด่วน
Android มีคอมโพเนนต์ UI การตั้งค่าด่วนที่ช่วยให้เข้าถึงการดำเนินการที่ใช้บ่อยหรือจําเป็นเร่งด่วนได้อย่างรวดเร็ว
หากการติดตั้งใช้งานอุปกรณ์มีคอมโพเนนต์ UI การตั้งค่าด่วนและรองรับการตั้งค่าด่วนของบุคคลที่สาม อุปกรณ์จะมีลักษณะดังนี้
- [C-1-1] ต้องอนุญาตให้ผู้ใช้เพิ่มหรือนำการ์ดที่ระบุผ่าน
quicksettings
API ออกจากแอปของบุคคลที่สาม - [C-1-2] ต้องไม่เพิ่มการ์ดจากแอปของบุคคลที่สามลงในการตั้งค่าด่วนโดยตรงโดยอัตโนมัติ
- [C-1-3] ต้องแสดงการ์ดทั้งหมดที่ผู้ใช้เพิ่มจากแอปของบุคคลที่สามควบคู่ไปกับการ์ดการตั้งค่าด่วนที่ระบบมีให้
3.14. UI ของสื่อ
หากการติดตั้งใช้งานอุปกรณ์มีแอปพลิเคชันที่ไม่เปิดใช้งานด้วยเสียง (แอป) ที่โต้ตอบกับแอปพลิเคชันของบุคคลที่สามผ่าน MediaBrowser
หรือ MediaSession
แอปจะต้องมีลักษณะดังนี้
[C-1-2] ต้องแสดงไอคอนที่รับผ่าน
getIconBitmap()
หรือgetIconUri()
และชื่อที่รับผ่านgetTitle()
อย่างชัดเจนตามที่อธิบายไว้ในMediaDescription
อาจตัดชื่อให้สั้นลงเพื่อให้เป็นไปตามกฎระเบียบด้านความปลอดภัย (เช่น สิ่งรบกวนคนขับ)[C-1-3] ต้องแสดงไอคอนแอปพลิเคชันของบุคคลที่สามทุกครั้งที่แสดงเนื้อหาที่มาจากแอปพลิเคชันของบุคคลที่สามนี้
[C-1-4] ต้องอนุญาตให้ผู้ใช้โต้ตอบกับลําดับชั้น
MediaBrowser
ทั้งหมด อาจจำกัดการเข้าถึงส่วนหนึ่งของลําดับชั้นเพื่อให้เป็นไปตามกฎระเบียบด้านความปลอดภัย (เช่น สิ่งรบกวนสมาธิของผู้ขับขี่) แต่ต้องไม่แสดง favoritism ตามเนื้อหาหรือผู้ให้บริการเนื้อหา[C-1-5] MUST consider double tap of
KEYCODE_HEADSETHOOK
orKEYCODE_MEDIA_PLAY_PAUSE
asKEYCODE_MEDIA_NEXT
forMediaSession.Callback#onMediaButtonEvent
.
3.15. Instant Apps
หากการติดตั้งใช้งานอุปกรณ์รองรับ Instant App อุปกรณ์ต้องเป็นไปตามข้อกําหนดต่อไปนี้
- [C-1-1] Instant App ต้องได้รับสิทธิ์ที่มีการตั้งค่า
android:protectionLevel
เป็น"instant"
เท่านั้น - [C-1-2] Instant App ต้องไม่โต้ตอบกับแอปที่ติดตั้งไว้ผ่าน Intent ที่ไม่ชัดแจ้ง
เว้นแต่ข้อใดข้อหนึ่งต่อไปนี้จะตรงกับความจริง
- ตัวกรองรูปแบบ Intent ของคอมโพเนนต์แสดงอยู่และมี CATEGORY_BROWSABLE
- การดำเนินการคือ ACTION_SEND, ACTION_SENDTO, ACTION_SEND_MULTIPLE
- เป้าหมายจะแสดงอย่างชัดแจ้งด้วย android:visibleToInstantApps
- [C-1-3] Instant App ต้องไม่โต้ตอบกับแอปที่ติดตั้งไว้อย่างโจ่งแจ้ง เว้นแต่ว่าคอมโพเนนต์จะแสดงผ่าน android:visibleToInstantApps
- [C-1-4] แอปที่ติดตั้งต้องไม่เห็นรายละเอียดเกี่ยวกับ Instant App ในอุปกรณ์ เว้นแต่ว่า Instant App จะเชื่อมต่อกับแอปพลิเคชันที่ติดตั้งไว้อย่างชัดเจน
การติดตั้งใช้งานอุปกรณ์ต้องให้สิ่งต่อไปนี้แก่ผู้ใช้สำหรับการโต้ตอบกับ Instant App AOSP เป็นไปตามข้อกำหนดด้วย UI ระบบ การตั้งค่า และ Launcher เริ่มต้น การติดตั้งใช้งานอุปกรณ์
- [C-1-5] ต้องให้ผู้ใช้ดูและลบ Instant App ที่แคชไว้ในพื้นที่สำหรับแต่ละแพ็กเกจแอป
- [C-1-6] ต้องแสดงการแจ้งเตือนผู้ใช้แบบถาวรที่ยุบได้ขณะที่ Instant App ทำงานอยู่เบื้องหน้า การแจ้งเตือนผู้ใช้นี้ต้องระบุว่า Instant App ไม่ต้องมีการติดตั้ง และระบุสิ่งที่ผู้ใช้ทำได้ซึ่งจะนำผู้ใช้ไปยังหน้าจอข้อมูลแอปพลิเคชันในการตั้งค่า สําหรับ Instant App ที่เปิดใช้งานผ่าน Intent ของเว็บตามที่กําหนดโดยใช้ Intent ที่มีการตั้งค่าการดําเนินการเป็น
Intent.ACTION_VIEW
และรูปแบบเป็น "http" หรือ "https" ความสามารถในการใช้งานเพิ่มเติมของผู้ใช้ควรอนุญาตให้ผู้ใช้ไม่เปิด Instant App และเปิดลิงก์ที่เชื่อมโยงกับเว็บเบราว์เซอร์ที่กําหนดค่าไว้ หากมีเบราว์เซอร์ในอุปกรณ์ - [C-1-7] ต้องอนุญาตให้เข้าถึง Instant App ที่ใช้งานอยู่จากฟังก์ชัน "ล่าสุด" หากฟังก์ชัน "ล่าสุด" พร้อมใช้งานในอุปกรณ์
[C-1-8] ต้องโหลดแอปพลิเคชันหรือคอมโพเนนต์บริการอย่างน้อย 1 รายการไว้ล่วงหน้า พร้อมกับตัวแฮนเดิล Intent สำหรับ Intent ที่แสดงอยู่ใน SDK ที่นี่ และทำให้ Intent แสดงสำหรับ Instant App
3.16. การจับคู่อุปกรณ์ที่ใช้ร่วมกัน
Android รองรับการจับคู่อุปกรณ์เสริมเพื่อจัดการการเชื่อมโยงกับอุปกรณ์เสริมได้อย่างมีประสิทธิภาพมากขึ้น และมี CompanionDeviceManager
API ที่ให้แอปเข้าถึงฟีเจอร์นี้ได้
หากการติดตั้งใช้งานอุปกรณ์รองรับฟีเจอร์การจับคู่อุปกรณ์เสริม อุปกรณ์จะดำเนินการต่อไปนี้
- [C-1-1] ต้องประกาศ Flag ฟีเจอร์
FEATURE_COMPANION_DEVICE_SETUP
- [C-1-2] ต้องตรวจสอบว่ามีการใช้ API ในแพ็กเกจ
android.companion
อย่างเต็มรูปแบบ - [C-1-3] ต้องให้สิ่งอํานวยความสะดวกแก่ผู้ใช้เพื่อให้ผู้ใช้เลือก/ยืนยันว่าอุปกรณ์ที่ใช้งานร่วมกันพร้อมใช้งาน
3.17. แอปขนาดใหญ่
หากการติดตั้งใช้งานอุปกรณ์ประกาศฟีเจอร์ FEATURE_CANT_SAVE_STATE
ระบบจะดำเนินการดังนี้
- [C-1-1] ต้องมีแอปที่ติดตั้งไว้เพียงแอปเดียวที่ระบุ
cantSaveState
ทำงานอยู่ในระบบในแต่ละครั้ง หากผู้ใช้ออกจากแอปดังกล่าวโดยไม่ออกจากแอปอย่างชัดเจน (เช่น กดปุ่มหน้าแรกขณะออกจากกิจกรรมที่ใช้งานอยู่ในระบบแทนการกดปุ่มย้อนกลับโดยไม่มีกิจกรรมที่ใช้งานอยู่ในระบบ) การติดตั้งใช้งานอุปกรณ์จะต้องจัดลำดับความสำคัญของแอปนั้นใน RAM เช่นเดียวกับสิ่งอื่นๆ ที่คาดว่าจะยังคงทำงานอยู่ เช่น บริการที่ทำงานอยู่เบื้องหน้า ขณะที่แอปดังกล่าวทำงานอยู่เบื้องหลัง ระบบจะยังคงใช้ฟีเจอร์การจัดการพลังงานกับแอปได้ เช่น จำกัดการเข้าถึง CPU และเครือข่าย - [C-1-2] ต้องระบุ UI ที่ช่วยให้ผู้ใช้เลือกแอปที่จะไม่เข้าร่วมในกลไกการบันทึก/กู้คืนสถานะปกติเมื่อผู้ใช้เปิดแอปที่ 2 ที่ประกาศด้วยแอตทริบิวต์
cantSaveState
- [C-1-3] ต้องไม่ใช้การเปลี่ยนแปลงอื่นๆ ในนโยบายกับแอปที่ระบุ
cantSaveState
เช่น การเปลี่ยนแปลงประสิทธิภาพของ CPU หรือการเปลี่ยนแปลงลำดับความสำคัญของการกำหนดเวลา
หากการติดตั้งใช้งานอุปกรณ์ไม่ได้ประกาศฟีเจอร์ FEATURE_CANT_SAVE_STATE
อุปกรณ์จะมีลักษณะดังนี้
- [C-1-1] ต้องละเว้นแอตทริบิวต์
cantSaveState
ที่แอปตั้งค่าไว้ และต้องไม่เปลี่ยนลักษณะการทํางานของแอปตามแอตทริบิวต์นั้น
3.18. รายชื่อติดต่อ
Android มี Contacts
Provider
API เพื่ออนุญาตให้แอปพลิเคชันจัดการข้อมูลติดต่อที่จัดเก็บไว้ในอุปกรณ์
โดยปกติแล้ว ข้อมูลติดต่อที่ป้อนลงในอุปกรณ์โดยตรงจะซิงค์กับเว็บเซอร์วิส แต่ข้อมูลดังกล่าวอาจอยู่ในอุปกรณ์เท่านั้น
รายชื่อติดต่อที่จัดเก็บไว้ในอุปกรณ์เท่านั้นเรียกว่ารายชื่อติดต่อในเครื่อง
RawContacts จะ "เชื่อมโยงกับ" หรือ "จัดเก็บใน" Account เมื่อคอลัมน์ ACCOUNT_NAME
และ ACCOUNT_TYPE
ของ RawContacts ตรงกับช่อง Account.name และ Account.type ของบัญชี
บัญชีในเครื่องเริ่มต้น: บัญชีสำหรับรายชื่อติดต่อดิบที่จัดเก็บไว้ในอุปกรณ์เท่านั้น และไม่ได้เชื่อมโยงกับบัญชีใน AccountManager ซึ่งสร้างขึ้นด้วยค่า null สำหรับคอลัมน์ ACCOUNT_NAME
และ ACCOUNT_TYPE
บัญชีในเครื่องที่กำหนดเอง: บัญชีสำหรับรายชื่อติดต่อดิบที่จัดเก็บไว้ในอุปกรณ์เท่านั้น และไม่ได้เชื่อมโยงกับบัญชีใน AccountManager ซึ่งสร้างขึ้นด้วยค่าที่ไม่ใช่ Null อย่างน้อย 1 ค่าสำหรับคอลัมน์ ACCOUNT_NAME
และ ACCOUNT_TYPE
การติดตั้งใช้งานอุปกรณ์
- [C-SR-1] ขอแนะนำอย่างยิ่งว่าอย่าสร้างบัญชีในเครื่องที่กำหนดเอง
หากการติดตั้งใช้งานอุปกรณ์ใช้บัญชีในเครื่องที่กำหนดเอง ให้ทำดังนี้
- [C-1-1]
ACCOUNT_NAME
จากบัญชีในเครื่องที่กำหนดเองต้องส่งคืนโดยContactsContract.RawContacts.getLocalAccountName
- [C-1-2]
ACCOUNT_TYPE
จากบัญชีในเครื่องที่กำหนดเองต้องส่งคืนภายในContactsContract.RawContacts.getLocalAccountType
- [C-1-3] ต้องแทรกรายชื่อติดต่อดิบที่แอปพลิเคชันของบุคคลที่สามแทรกลงในบัญชีในเครื่องเริ่มต้น (นั่นคือ การตั้งค่าค่า Null สำหรับ
ACCOUNT_NAME
และACCOUNT_TYPE
) ลงในบัญชีในเครื่องที่กำหนดเอง - [C-1-4] รายชื่อติดต่อดิบซึ่งแทรกลงในบัญชีในเครื่องที่กำหนดเองต้องไม่ถูกนำออกเมื่อมีการเพิ่มหรือนำบัญชีออก
- [C-1-5] การดำเนินการลบในบัญชีในเครื่องที่กำหนดเองต้องส่งผลให้ระบบล้างข้อมูลติดต่อดิบทันที (เหมือนกับมีการตั้งค่าพารามิเตอร์
CALLER_IS_SYNCADAPTER
เป็น true) แม้ว่าจะมีการตั้งค่าพารามิเตอร์CALLER\_IS\_SYNCADAPTER
เป็น false หรือไม่ระบุก็ตาม
4. ความเข้ากันได้ของแพ็กเกจแอปพลิเคชัน
การติดตั้งใช้งานอุปกรณ์
- [C-0-1] ต้องสามารถติดตั้งและเรียกใช้ไฟล์ ".apk" ของ Android ตามที่เครื่องมือ "aapt" ที่รวมอยู่ใน Android SDK อย่างเป็นทางการสร้างขึ้น
- เนื่องจากข้อกำหนดข้างต้นอาจเป็นเรื่องยาก เราจึงขอแนะนำให้ใช้ระบบการจัดการแพ็กเกจของการติดตั้งใช้งานอ้างอิง AOSP ในการติดตั้งใช้งานอุปกรณ์
การติดตั้งใช้งานอุปกรณ์
- [C-0-2] ต้องรองรับการยืนยันไฟล์ ".apk" โดยใช้ APK Signature Scheme v3, APK Signature Scheme v2 และการรับรอง JAR
- [C-0-3] ต้องไม่ขยายรูปแบบ .apk, Android Manifest, Dalvik Bytecode หรือ RenderScript Bytecode ในลักษณะที่ทําให้ไฟล์เหล่านั้นติดตั้งและทํางานอย่างถูกต้องในอุปกรณ์อื่นๆ ที่เข้ากันได้
[C-0-4] ต้องไม่อนุญาตให้แอปอื่นที่ไม่ใช่ "ผู้ติดตั้งที่บันทึกไว้" ในปัจจุบันสำหรับแพ็กเกจถอนการติดตั้งแอปโดยอัตโนมัติโดยไม่ได้รับการยืนยันจากผู้ใช้ ตามที่ระบุไว้ใน SDK สำหรับสิทธิ์
DELETE_PACKAGE
ข้อยกเว้นเพียงอย่างเดียวคือการจัดการแอปโปรแกรมตรวจสอบแพ็กเกจของระบบที่มีPACKAGE_NEEDS_VERIFICATION Intent และการจัดการแอปเครื่องมือจัดการพื้นที่เก็บข้อมูลที่มี ACTION_MANAGE_STORAGE Intent[C-0-5] ต้องมีกิจกรรมที่จัดการกับ
android.settings.MANAGE_UNKNOWN_APP_SOURCES
Intent[C-0-6] ต้องไม่ติดตั้งแพ็กเกจแอปพลิเคชันจากแหล่งที่มาที่ไม่รู้จัก เว้นแต่แอปที่ขอการติดตั้งจะเป็นไปตามข้อกำหนดต่อไปนี้ทั้งหมด
- โดยจะต้องประกาศสิทธิ์
REQUEST_INSTALL_PACKAGES
หรือตั้งค่าandroid:targetSdkVersion
เป็น 24 หรือต่ำกว่า - ผู้ใช้ต้องให้สิทธิ์ในการติดตั้งแอปจากแหล่งที่มาที่ไม่รู้จัก
- โดยจะต้องประกาศสิทธิ์
ควรให้ผู้ใช้สามารถให้/เพิกถอนสิทธิ์ในการติดตั้งแอปจากแหล่งที่มาที่ไม่รู้จักต่อแอปพลิเคชัน แต่อาจเลือกที่จะไม่ใช้งานและแสดงผล
RESULT_CANCELED
สำหรับstartActivityForResult()
หากการใช้งานอุปกรณ์ไม่ต้องการให้ผู้ใช้มีตัวเลือกนี้ อย่างไรก็ตาม ในกรณีเช่นนี้ พาร์ทเนอร์ควรแจ้งให้ผู้ใช้ทราบถึงสาเหตุที่ตัวเลือกดังกล่าวไม่แสดง[C-0-7] ต้องแสดงกล่องโต้ตอบคำเตือนพร้อมสตริงคำเตือนที่ระบุผ่าน API ของระบบ
PackageManager.setHarmfulAppWarning
ให้กับผู้ใช้ก่อนเปิดใช้งานแอปพลิเคชันที่มีการทำเครื่องหมายโดย API ของระบบเดียวกันPackageManager.setHarmfulAppWarning
ว่าอาจเป็นอันตรายควรให้ผู้ใช้เลือกถอนการติดตั้งหรือเปิดแอปพลิเคชันในกล่องโต้ตอบคำเตือน
[C-0-8] ต้องรองรับระบบไฟล์แบบเพิ่มข้อมูลตามที่ระบุไว้ที่นี่
[C-0-9] ต้องรองรับการยืนยันไฟล์ .apk โดยใช้ APK Signature Scheme v4
5. ความเข้ากันได้ของมัลติมีเดีย
การติดตั้งใช้งานอุปกรณ์
- [C-0-1] ต้องรองรับรูปแบบสื่อ โปรแกรมเข้ารหัส โปรแกรมถอดรหัส ประเภทไฟล์ และรูปแบบคอนเทนเนอร์ที่ระบุไว้ในส่วนที่ 5.1 สำหรับตัวแปลงสัญญาณแต่ละรายการที่
MediaCodecList
ประกาศ - [C-0-2] ต้องประกาศและรายงานการรองรับโปรแกรมเข้ารหัส โปรแกรมถอดรหัสที่มีให้สำหรับแอปพลิเคชันของบุคคลที่สามผ่าน
MediaCodecList
- [C-0-3] ต้องสามารถถอดรหัสอย่างถูกต้องและทำให้แอปของบุคคลที่สามใช้งานได้กับรูปแบบทั้งหมดที่โค้ดได้ ซึ่งรวมถึงบิตสตรีมทั้งหมดที่โปรแกรมเปลี่ยนไฟล์สร้างและโปรไฟล์ที่รายงานใน
CamcorderProfile
การติดตั้งใช้งานอุปกรณ์
- ควรมุ่งเน้นที่เวลาในการตอบสนองของโค้ดที่ต่ำที่สุด กล่าวคือ
- ไม่ควรใช้และจัดเก็บบัฟเฟอร์อินพุต รวมถึงส่งคืนบัฟเฟอร์อินพุตเมื่อประมวลผลแล้วเท่านั้น
- ไม่ควรเก็บบัฟเฟอร์ที่ถอดรหัสไว้นานกว่าที่มาตรฐานระบุไว้ (เช่น SPS)
- ไม่ควรเก็บบัฟเฟอร์ที่เข้ารหัสไว้นานกว่าที่โครงสร้าง GOP กำหนด
ตัวแปลงรหัสทั้งหมดที่แสดงอยู่ในส่วนด้านล่างมีไว้สำหรับการใช้งานซอฟต์แวร์ในการใช้งาน Android ที่ต้องการจากโปรเจ็กต์โอเพนซอร์ส Android
โปรดทราบว่าทั้ง Google และ Open Handset Alliance ไม่ได้รับรองว่าตัวแปลงรหัสเหล่านี้ปราศจากสิทธิบัตรของบุคคลที่สาม เราขอแนะนำให้ผู้ที่ตั้งใจจะใช้ซอร์สโค้ดนี้ในผลิตภัณฑ์ฮาร์ดแวร์หรือซอฟต์แวร์ทราบว่าการใช้งานโค้ดนี้ ซึ่งรวมถึงในซอฟต์แวร์โอเพนซอร์สหรือแชร์แวร์ อาจต้องใช้ใบอนุญาตสิทธิบัตรจากผู้ถือครองสิทธิบัตรที่เกี่ยวข้อง
5.1 ตัวแปลงรหัสสื่อ
5.1.1. การเข้ารหัสเสียง
ดูรายละเอียดเพิ่มเติมใน 5.1.3 รายละเอียดตัวแปลงรหัสเสียง
หากการติดตั้งใช้งานอุปกรณ์ประกาศ android.hardware.microphone
อุปกรณ์จะต้องรองรับการเข้ารหัสรูปแบบเสียงต่อไปนี้และทำให้พร้อมใช้งานสำหรับแอปของบุคคลที่สาม
- [C-1-1] PCM/WAVE
- [C-1-2] FLAC
- [C-1-3] Opus
โปรแกรมเปลี่ยนไฟล์เสียงทั้งหมดต้องรองรับรายการต่อไปนี้
- [C-3-1] เฟรมเสียง PCM 16 บิตตามลำดับไบต์เนทีฟผ่าน
android.media.MediaCodec
API
5.1.2. การถอดรหัสเสียง
ดูรายละเอียดเพิ่มเติมใน 5.1.3 รายละเอียดตัวแปลงรหัสเสียง
หากการติดตั้งใช้งานอุปกรณ์ประกาศว่ารองรับฟีเจอร์ android.hardware.audio.output
อุปกรณ์นั้นต้องรองรับการถอดรหัสรูปแบบเสียงต่อไปนี้
- [C-1-1] โปรไฟล์ MPEG-4 AAC (AAC LC)
- [C-1-2] โปรไฟล์ MPEG-4 HE AAC (AAC+)
- [C-1-3] โปรไฟล์ MPEG-4 HE AACv2 (AAC+ ที่ปรับปรุงแล้ว)
- [C-1-4] AAC ELD (AAC แบบลดเวลาหน่วงที่ปรับปรุงแล้ว)
- [C-1-11] xHE-AAC (ISO/IEC 23003-3 Extended HE AAC Profile ซึ่งรวมถึง USAC Baseline Profile และ ISO/IEC 23003-4 Dynamic Range Control Profile)
- [C-1-5] FLAC
- [C-1-6] MP3
- [C-1-7] MIDI
- [C-1-8] Vorbis
- [C-1-9] PCM/WAVE รวมถึงรูปแบบเสียงความละเอียดสูงสูงสุด 24 บิต อัตราการสุ่มตัวอย่าง 192 kHz และ 8 แชนแนล โปรดทราบว่าข้อกำหนดนี้ใช้กับการถอดรหัสเท่านั้น และอุปกรณ์ได้รับอนุญาตให้ลดขนาดและลดคุณภาพเสียงในระหว่างการเล่น
- [C-1-10] Opus
หากการติดตั้งใช้งานอุปกรณ์รองรับการถอดรหัสบัฟเฟอร์อินพุต AAC ของสตรีมหลายช่อง (นั่นคือมากกว่า 2 ช่อง) เป็น PCM ผ่านโปรแกรมถอดรหัสเสียง AAC เริ่มต้นใน android.media.MediaCodec
API อุปกรณ์จะต้องรองรับสิ่งต่อไปนี้
- [C-2-1] ต้องมีการถอดรหัสโดยไม่ลดขนาด (เช่น สตรีม AAC 5.0 ต้องถอดรหัสเป็น PCM 5 แชนแนล สตรีม AAC 5.1 ต้องถอดรหัสเป็น PCM 6 แชนแนล)
- [C-2-2] ข้อมูลเมตาช่วงไดนามิกต้องเป็นไปตามที่ระบุไว้ใน "การควบคุมช่วงไดนามิก (DRC)" ใน ISO/IEC 14496-3 และคีย์
android.media.MediaFormat
DRC เพื่อกำหนดค่าลักษณะการทำงานที่เกี่ยวข้องกับช่วงไดนามิกของตัวถอดรหัสเสียง คีย์ DRC ของ AAC เปิดตัวใน API 21 โดยมีคีย์ดังนี้KEY_AAC_DRC_ATTENUATION_FACTOR
,KEY_AAC_DRC_BOOST_FACTOR
,KEY_AAC_DRC_HEAVY_COMPRESSION
,KEY_AAC_DRC_TARGET_REFERENCE_LEVEL
และKEY_AAC_ENCODED_TARGET_LEVEL
- [SR-1] ขอแนะนำอย่างยิ่งว่าโปรแกรมถอดรหัสเสียง AAC ทั้งหมดต้องเป็นไปตามข้อกำหนด C-2-1 และ C-2-2 ข้างต้น
เมื่อถอดรหัสเสียง USAC, MPEG-D (ISO/IEC 23003-4)
- [C-3-1] ข้อมูลเมตาระดับเสียงและ DRC ต้องได้รับการตีความและนำไปใช้ตามโปรไฟล์การควบคุมช่วงไดนามิกแบบไดนามิก (DRC) ระดับ 1 ของ MPEG-D
- [C-3-2] ตัวถอดรหัสต้องทํางานตามการกําหนดค่าที่ระบุด้วย
android.media.MediaFormat
คีย์ต่อไปนี้KEY_AAC_DRC_TARGET_REFERENCE_LEVEL
และKEY_AAC_DRC_EFFECT_TYPE
ตัวถอดรหัสโปรไฟล์ MPEG-4 AAC, HE AAC และ HE AACv2
- อาจรองรับการควบคุมระดับเสียงและช่วงไดนามิกโดยใช้โปรไฟล์การควบคุมช่วงไดนามิก ISO/IEC 23003-4
หากระบบรองรับ ISO/IEC 23003-4 และมีข้อมูลเมตาทั้ง ISO/IEC 23003-4 และ ISO/IEC 14496-3 ในบิตสตรีมที่ถอดรหัสแล้ว ระบบจะดำเนินการดังนี้
- ข้อมูลเมตา ISO/IEC 23003-4 จะมีความสําคัญเหนือกว่า
ตัวถอดรหัสเสียงทั้งหมดต้องรองรับเอาต์พุตต่อไปนี้
- [C-6-1] เฟรมเสียง PCM 16 บิตตามลำดับไบต์เนทีฟผ่าน
android.media.MediaCodec
API
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 - Wideband Speech Codec | 3GPP (.3gp) |
FLAC | สำหรับทั้งโปรแกรมเข้ารหัสและโปรแกรมถอดรหัส: ต้องรองรับโหมดโมโนและสเตอริโอเป็นอย่างน้อย ต้องรองรับอัตราการสุ่มตัวอย่างสูงสุด 192 kHz ต้องรองรับความละเอียด 16 บิตและ 24 บิต การจัดการข้อมูลเสียง FLAC 24 บิตต้องพร้อมใช้งานด้วยการกําหนดค่าเสียงแบบจุดลอย |
|
MP3 | โมโน/สเตอริโอ 8-320 Kbps แบบคงที่ (CBR) หรืออัตราบิตผันแปร (VBR) |
|
MIDI | MIDI ประเภท 0 และ 1 DLS เวอร์ชัน 1 และ 2 XMF และ Mobile 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
- [C-0-2] GIF
- [C-0-3] PNG
- [C-0-4] BMP
- [C-0-5] WebP
- [C-0-6] ดิบ
หากการติดตั้งใช้งานอุปกรณ์รองรับการถอดรหัสวิดีโอ HEVC อุปกรณ์จะมีลักษณะดังนี้
- [C-1-1] ต้องรองรับการถอดรหัสรูปภาพ HEIF (HEIC)
ตัวถอดรหัสรูปภาพที่รองรับรูปแบบความลึกของบิตสูง (9 บิตขึ้นไปต่อช่อง)
- [C-2-1] ต้องรองรับการแสดงผลรูปแบบที่เทียบเท่า 8 บิตหากแอปพลิเคชันขอ เช่น ผ่านการกำหนดค่า
ARGB_8888
ของandroid.graphics.Bitmap
5.1.6. รายละเอียดตัวแปลงรหัสรูปภาพ
รูปแบบ/ตัวแปลงรหัส | รายละเอียด | ประเภทไฟล์/รูปแบบคอนเทนเนอร์ที่รองรับ |
---|---|---|
JPEG | Base+progressive | JPEG (.jpg) |
GIF | GIF (.gif) | |
PNG | PNG (.png) | |
BMP | BMP (.bmp) | |
WebP | WebP (.webp) | |
แบบข้อมูลดิบ | ARW (.arw), CR2 (.cr2), DNG (.dng), NEF (.nef), NRW (.nrw), ORF (.orf), PEF (.pef), RAF (.raf), RW2 (.rw2), SRW (.srw) | |
HEIF | รูปภาพ คอลเล็กชันรูปภาพ ลำดับรูปภาพ | HEIF (.heif), HEIC (.heic) |
ตัวเข้ารหัสและตัวถอดรหัสรูปภาพที่แสดงผ่าน MediaCodec API
[C-1-1] ต้องรองรับรูปแบบสี YUV420 8:8:8 แบบยืดหยุ่น (
COLOR_FormatYUV420Flexible
) ถึงCodecCapabilities
[SR-1] ขอแนะนำอย่างยิ่งให้รองรับรูปแบบสี RGB888 สำหรับโหมดพื้นผิวอินพุต
[C-1-3] ต้องรองรับรูปแบบสี YUV420 8:8:8 แบบแพลแนร์หรือแบบแพลแนร์ครึ่งอย่างน้อย 1 รูปแบบ ได้แก่
COLOR_FormatYUV420PackedPlanar
(เทียบเท่าCOLOR_FormatYUV420Planar
) หรือCOLOR_FormatYUV420PackedSemiPlanar
(เทียบเท่าCOLOR_FormatYUV420SemiPlanar
) ขอแนะนำอย่างยิ่งให้รองรับทั้ง 2 รูปแบบ
5.1.7. ตัวแปลงรหัสวิดีโอ
- การติดตั้งใช้งานอุปกรณ์ควรใช้ตัวแปลงรหัส VP8 ของฮาร์ดแวร์ที่เป็นไปตามข้อกำหนดเพื่อให้ได้คุณภาพที่ยอมรับได้สำหรับบริการสตรีมมิงวิดีโอบนเว็บและการประชุมทางวิดีโอ
หากการติดตั้งใช้งานอุปกรณ์มีโปรแกรมถอดรหัสหรือโปรแกรมเปลี่ยนไฟล์วิดีโอ ให้ทำดังนี้
[C-1-1] ตัวแปลงรหัสวิดีโอต้องรองรับขนาดบัยบ์บัฟเฟอร์เอาต์พุตและอินพุตที่รองรับเฟรมที่บีบอัดและไม่บีบอัดได้ใหญ่ที่สุดตามมาตรฐานและการกําหนดค่า แต่ต้องไม่จัดสรรเกินขนาด
[C-1-2] ตัวเข้ารหัสและตัวถอดรหัสวิดีโอต้องรองรับรูปแบบสีแบบยืดหยุ่น YUV420 8:8:8 (
COLOR_FormatYUV420Flexible
) ถึงCodecCapabilities
[C-1-3] โปรแกรมเปลี่ยนไฟล์วิดีโอและโปรแกรมถอดรหัสวิดีโอต้องรองรับรูปแบบสี YUV420 8:8:8 แบบแพลแนร์หรือแบบเซมิแพลแนร์อย่างน้อย 1 รูปแบบ ได้แก่
COLOR_FormatYUV420PackedPlanar
(เทียบเท่ากับCOLOR_FormatYUV420Planar
) หรือCOLOR_FormatYUV420PackedSemiPlanar
(เทียบเท่ากับCOLOR_FormatYUV420SemiPlanar
) เราขอแนะนำอย่างยิ่งให้รองรับทั้ง 2 รูปแบบ[SR-1] ขอแนะนำอย่างยิ่งให้โปรแกรมเข้ารหัสและโปรแกรมถอดรหัสวิดีโอรองรับรูปแบบสี YUV420 8:8:8 แบบแพลแนร์หรือแบบแพลแนร์ครึ่งที่ฮาร์ดแวร์เพิ่มประสิทธิภาพอย่างน้อย 1 รูปแบบ (YV12, NV12, NV21 หรือรูปแบบที่เพิ่มประสิทธิภาพโดยผู้ให้บริการที่เทียบเท่า)
[C-1-5] ตัวถอดรหัสวิดีโอที่รองรับรูปแบบความลึกของบิตสูง (9 บิตขึ้นไปต่อช่อง) จะต้องรองรับการแสดงผลรูปแบบเทียบเท่า 8 บิตหากแอปพลิเคชันขอ ซึ่งต้องแสดงโดยรองรับรูปแบบสี YUV420 8:8:8 ผ่าน
android.media.MediaCodecInfo
หากการติดตั้งใช้งานอุปกรณ์โฆษณาการรองรับโปรไฟล์ HDR ผ่าน Display.HdrCapabilities
อุปกรณ์ดังกล่าวจะต้องมีคุณสมบัติดังนี้
- [C-2-1] ต้องรองรับการแยกวิเคราะห์และการจัดการข้อมูลเมตา HDR แบบคงที่
หากการติดตั้งใช้งานอุปกรณ์โฆษณาการรองรับการรีเฟรชภายในผ่าน FEATURE_IntraRefresh
ในคลาส MediaCodecInfo.CodecCapabilities
ระบบจะดำเนินการดังนี้
- [C-3-1] ต้องรองรับระยะเวลารีเฟรชในช่วง 10-60 เฟรม และทำงานได้อย่างถูกต้องภายใน 20% ของระยะเวลารีเฟรชที่กำหนดค่าไว้
การใช้งานโปรแกรมถอดรหัสวิดีโอจะมีลักษณะดังนี้ เว้นแต่แอปพลิเคชันจะระบุไว้เป็นอย่างอื่นโดยใช้คีย์รูปแบบ KEY_COLOR_FORMAT
- [C-4-1] ต้องตั้งค่าเริ่มต้นเป็นรูปแบบสีที่เพิ่มประสิทธิภาพสำหรับจอแสดงผลฮาร์ดแวร์หากกําหนดค่าโดยใช้เอาต์พุต Surface
- [C-4-2] ต้องตั้งค่าเริ่มต้นเป็นรูปแบบสี YUV420 8:8:8 ที่เพิ่มประสิทธิภาพสำหรับการอ่าน CPU หากกำหนดค่าให้ไม่ใช้เอาต์พุต Surface
5.1.8. รายการตัวแปลงรหัสวิดีโอ
รูปแบบ/ตัวแปลงรหัส | รายละเอียด | ประเภทไฟล์/รูปแบบคอนเทนเนอร์ที่รองรับ |
---|---|---|
H.263 |
|
|
H.264 AVC | ดูรายละเอียดได้ที่ส่วนที่ 5.2 และ 5.3 |
|
H.265 HEVC | ดูรายละเอียดได้ที่ส่วนที่ 5.3 |
|
MPEG-2 | โปรไฟล์หลัก |
|
MPEG-4 SP |
|
|
VP8 | ดูรายละเอียดได้ที่ส่วนที่ 5.2 และ 5.3 |
|
VP9 | ดูรายละเอียดได้ที่ส่วนที่ 5.3 |
|
5.1.9. ความปลอดภัยของตัวแปลงรหัสสื่อ
การติดตั้งใช้งานอุปกรณ์ต้องเป็นไปตามฟีเจอร์ด้านความปลอดภัยของโค้ดคิวเอดสื่อตามที่อธิบายไว้ด้านล่าง
Android รองรับ OMX ซึ่งเป็น API การเร่งความเร็วมัลติมีเดียข้ามแพลตฟอร์ม รวมถึง Codec 2.0 ซึ่งเป็น API การเร่งความเร็วมัลติมีเดียที่มีค่าใช้จ่ายต่ำ
หากการติดตั้งใช้งานอุปกรณ์รองรับมัลติมีเดีย อุปกรณ์จะดำเนินการต่อไปนี้
- [C-1-1] ต้องรองรับตัวแปลงรหัสสื่อผ่าน OMX หรือ Codec 2.0 API (หรือทั้ง 2 อย่าง) ตามที่ระบุไว้ในโปรเจ็กต์โอเพนซอร์ส Android และไม่ปิดใช้หรือหลบเลี่ยงการป้องกันความปลอดภัย ข้อความนี้ไม่ได้หมายความว่าตัวแปลงรหัสทุกตัวต้องใช้ OMX หรือ Codec 2.0 API แต่หมายความว่าต้องรองรับ API เหล่านี้อย่างน้อย 1 รายการ และการสนับสนุน API ที่พร้อมใช้งานต้องรวมการป้องกันความปลอดภัยไว้ด้วย
- [C-SR-1] ขอแนะนำอย่างยิ่งให้รองรับ Codec 2.0 API
หากการติดตั้งใช้งานอุปกรณ์ไม่รองรับ Codec 2.0 API อุปกรณ์จะมีลักษณะดังนี้
- [C-2-1] ต้องใส่โปรแกรมเปลี่ยนรหัสซอฟต์แวร์ OMX ที่เกี่ยวข้องจากโปรเจ็กต์โอเพนซอร์สของ Android (หากมี) สำหรับรูปแบบและประเภทสื่อแต่ละประเภท (โปรแกรมเข้ารหัสหรือโปรแกรมถอดรหัส) ที่อุปกรณ์รองรับ
- [C-2-2] ตัวแปลงรหัสที่มีชื่อขึ้นต้นด้วย "OMX.google" ต้องอิงตามซอร์สโค้ดของโครงการโอเพนซอร์ส Android
- [C-SR-2] ขอแนะนำอย่างยิ่งให้โปรแกรมเปลี่ยนไฟล์ซอฟต์แวร์ OMX ทำงานในกระบวนการเปลี่ยนไฟล์ที่ไม่มีสิทธิ์เข้าถึงไดรเวอร์ฮาร์ดแวร์นอกเหนือจากโปรแกรมแมปหน่วยความจำ
หากการติดตั้งใช้งานอุปกรณ์รองรับ Codec 2.0 API อุปกรณ์จะดำเนินการต่อไปนี้
- [C-3-1] ต้องมีตัวแปลงรหัสซอฟต์แวร์ Codec 2.0 ที่เกี่ยวข้องจากโครงการโอเพนซอร์ส Android (หากมี) สำหรับรูปแบบและประเภทสื่อแต่ละประเภท (โปรแกรมเข้ารหัสหรือโปรแกรมถอดรหัส) ที่อุปกรณ์รองรับ
- [C-3-2] ต้องจัดเก็บโปรแกรมเปลี่ยนรหัสซอฟต์แวร์ Codec 2.0 ในกระบวนการของโปรแกรมเปลี่ยนรหัสซอฟต์แวร์ตามที่ระบุไว้ในโปรเจ็กต์โอเพนซอร์ส Android เพื่อให้สามารถให้สิทธิ์เข้าถึงโปรแกรมเปลี่ยนรหัสซอฟต์แวร์ได้แคบลง
- [C-3-3] ตัวแปลงรหัสที่มีชื่อขึ้นต้นด้วย "c2.android." ต้องอิงตามซอร์สโค้ดของโครงการโอเพนซอร์ส Android
5.1.10. ลักษณะของตัวแปลงรหัสสื่อ
หากการติดตั้งใช้งานอุปกรณ์รองรับตัวแปลงรหัสสื่อ อุปกรณ์จะดำเนินการต่อไปนี้
- [C-1-1] ต้องแสดงค่าที่ถูกต้องของลักษณะเฉพาะของโค้ดคิวสื่อผ่าน
MediaCodecInfo
API
โดยเฉพาะอย่างยิ่งในเรื่องต่อไปนี้
- [C-1-2] ตัวแปลงรหัสที่มีชื่อขึ้นต้นด้วย "OMX" ต้องใช้ OMX API และต้องมีชื่อที่เป็นไปตามหลักเกณฑ์การตั้งชื่อ OMX IL
- [C-1-3] ตัวแปลงรหัสที่มีชื่อขึ้นต้นด้วย "c2" ต้องใช้ Codec 2.0 API และมีชื่อที่เป็นไปตามหลักเกณฑ์การตั้งชื่อ Codec 2.0 สำหรับ Android
- [C-1-4] ตัวแปลงรหัสที่มีชื่อขึ้นต้นด้วย "OMX.google." หรือ "c2.android." ต้องไม่มีลักษณะเป็นผู้ให้บริการหรือเป็นฮาร์ดแวร์ที่เร่งความเร็ว
- [C-1-5] โค้ดที่ทำงานในกระบวนการโค้ด (ผู้ให้บริการหรือระบบ) ที่มีสิทธิ์เข้าถึงไดรเวอร์ฮาร์ดแวร์นอกเหนือจากตัวจัดสรรและโปรแกรมแมปหน่วยความจำต้องไม่มีลักษณะเป็นซอฟต์แวร์เท่านั้น
- [C-1-6] โปรแกรมเปลี่ยนรหัสที่ไม่ได้อยู่ในโปรเจ็กต์โอเพนซอร์ส Android หรือไม่อิงตามซอร์สโค้ดในโปรเจ็กต์นั้นต้องระบุว่าเป็น Vendor
- [C-1-7] โปรแกรมเปลี่ยนรหัสที่ใช้การเร่งฮาร์ดแวร์ต้องระบุว่าใช้การเร่งฮาร์ดแวร์
- [C-1-8] ชื่อตัวแปลงรหัสต้องไม่ทำให้เข้าใจผิด ตัวอย่างเช่น ตัวแปลงรหัสที่มีชื่อว่า "ตัวถอดรหัส" จะต้องรองรับการถอดรหัส และตัวแปลงรหัสที่มีชื่อว่า "ตัวเข้ารหัส" จะต้องรองรับการเข้ารหัส ตัวแปลงรหัสที่มีชื่อซึ่งมีรูปแบบสื่อต้องรองรับรูปแบบเหล่านั้น
หากการติดตั้งใช้งานอุปกรณ์รองรับตัวแปลงรหัสวิดีโอ ให้ทำดังนี้
- [C-2-1] ตัวแปลงรหัสวิดีโอทั้งหมดต้องเผยแพร่ข้อมูลอัตราเฟรมที่ทำได้สำหรับขนาดต่อไปนี้ หากตัวแปลงรหัสรองรับ
SD (คุณภาพต่ำ) | SD (คุณภาพสูง) | HD 720p | HD 1080p | UHD | |
---|---|---|---|---|---|
ความละเอียดของวิดีโอ |
|
|
|
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
ฟีเจอร์ Flag อุปกรณ์ดังกล่าวจะต้องมีคุณสมบัติดังนี้
- [C-1-1] ต้องรองรับโปรแกรมเปลี่ยนไฟล์วิดีโอ VP8 หรือ H.264 อย่างน้อย 1 รายการ และทำให้พร้อมใช้งานสำหรับแอปพลิเคชันของบุคคลที่สาม
- ควรรองรับทั้งโปรแกรมเปลี่ยนไฟล์วิดีโอ VP8 และ H.264 รวมถึงทำให้พร้อมใช้งานสำหรับแอปพลิเคชันของบุคคลที่สาม
หากการติดตั้งใช้งานอุปกรณ์รองรับโปรแกรมเปลี่ยนไฟล์วิดีโอ H.264, VP8, VP9 หรือ HEVC และทำให้แอปพลิเคชันของบุคคลที่สามใช้งานได้ แอปพลิเคชันเหล่านั้นจะทำสิ่งต่อไปนี้
- [C-2-1] ต้องรองรับบิตเรตที่กำหนดค่าแบบไดนามิกได้
- ควรรองรับอัตราเฟรมที่เปลี่ยนแปลงได้ โดยโปรแกรมเปลี่ยนไฟล์วิดีโอควรกำหนดระยะเวลาเฟรมทันทีตามการประทับเวลาของบัฟเฟอร์อินพุต และจัดสรรที่เก็บบิตตามระยะเวลาเฟรมนั้น
หากการติดตั้งใช้งานอุปกรณ์รองรับโปรแกรมเปลี่ยนไฟล์วิดีโอ MPEG-4 SP และทำให้แอปของบุคคลที่สามใช้งานได้ แอปเหล่านั้นจะทำสิ่งต่อไปนี้
- ควรรองรับอัตราบิตที่กำหนดค่าแบบไดนามิกได้สำหรับโปรแกรมเปลี่ยนไฟล์ที่รองรับ
หากการติดตั้งใช้งานอุปกรณ์มีโปรแกรมเปลี่ยนไฟล์วิดีโอหรือรูปภาพที่เร่งด้วยฮาร์ดแวร์ และรองรับกล้องฮาร์ดแวร์ที่ต่ออยู่หรือเสียบได้อย่างน้อย 1 ตัวที่แสดงผ่านandroid.camera
API ให้ทำดังนี้
- [C-4-1] ตัวแปลงรหัสวิดีโอและรูปภาพที่เร่งด้วยฮาร์ดแวร์ทั้งหมดต้องรองรับการเข้ารหัสเฟรมจากกล้องฮาร์ดแวร์
- ควรรองรับการเข้ารหัสเฟรมจากกล้องฮาร์ดแวร์ผ่านโปรแกรมเปลี่ยนไฟล์วิดีโอหรือโปรแกรมเปลี่ยนไฟล์รูปภาพทั้งหมด
หากการใช้งานอุปกรณ์มีการเข้ารหัส HDR อุปกรณ์จะมีลักษณะดังนี้
- [C-SR-1] ขอแนะนำอย่างยิ่งให้จัดเตรียมปลั๊กอินสำหรับ API การแปลงรหัสแบบราบรื่นเพื่อแปลงจากรูปแบบ HDR เป็นรูปแบบ SDR
5.2.1. H.263
หากการติดตั้งใช้งานอุปกรณ์รองรับโปรแกรมเปลี่ยนไฟล์ H.263 และทำให้พร้อมใช้งานสำหรับแอปของบุคคลที่สาม แอปเหล่านั้นจะทำสิ่งต่อไปนี้ได้
- [C-1-1] ต้องรองรับโปรไฟล์พื้นฐานระดับ 45
- ควรรองรับอัตราบิตที่กำหนดค่าแบบไดนามิกได้สำหรับโปรแกรมเปลี่ยนไฟล์ที่รองรับ
5.2.2. H.264
หากการติดตั้งใช้งานอุปกรณ์รองรับตัวแปลงรหัส H.264 อุปกรณ์จะดำเนินการต่อไปนี้
- [C-1-1] ต้องรองรับโปรไฟล์พื้นฐานระดับ 3 อย่างไรก็ตาม การสนับสนุน ASO (การจัดเรียงข้อมูลเป็นชิ้นแบบไม่เจาะจง), FMO (การจัดเรียง Macroblock แบบยืดหยุ่น) และ RS (ข้อมูลเป็นชิ้นที่ซ้ำกัน) นั้นไม่บังคับ นอกจากนี้ เราขอแนะนำให้โปรแกรมเปลี่ยนไฟล์ไม่ใช้ ASO, FMO และ RS สำหรับโปรไฟล์ Baseline เพื่อรักษาความเข้ากันได้กับอุปกรณ์ Android เครื่องอื่นๆ
- [C-1-2] ต้องรองรับโปรไฟล์การเข้ารหัสวิดีโอ SD (ความละเอียดมาตรฐาน) ในตารางต่อไปนี้
- ควรรองรับโปรไฟล์หลักระดับ 4
- ควรรองรับโปรไฟล์การเข้ารหัสวิดีโอ HD (ความละเอียดสูง) ตามที่ระบุไว้ในตารางต่อไปนี้
หากการติดตั้งใช้งานอุปกรณ์รายงานการรองรับการเข้ารหัส H.264 สำหรับวิดีโอความละเอียด 720p หรือ 1080p ผ่าน Media API อุปกรณ์เหล่านั้นจะทำสิ่งต่อไปนี้
- [C-2-1] ต้องรองรับโปรไฟล์การเข้ารหัสในตารางต่อไปนี้
SD (คุณภาพต่ำ) | SD (คุณภาพสูง) | HD 720p | HD 1080p | |
---|---|---|---|---|
ความละเอียดของวิดีโอ | 320 x 240 พิกเซล | 720 x 480 พิกเซล | 1280 x 720 พิกเซล | 1920 x 1080 พิกเซล |
อัตราเฟรมของวิดีโอ | 20 FPS | 30 fps | 30 fps | 30 fps |
อัตราบิตของวิดีโอ | 384 Kbps | 2 Mbps | 4 Mbps | 10 Mbps |
5.2.3. VP8
หากการติดตั้งใช้งานอุปกรณ์รองรับตัวแปลงรหัส VP8 อุปกรณ์จะมีลักษณะดังนี้
- [C-1-1] ต้องรองรับโปรไฟล์การเข้ารหัสวิดีโอ SD
- ควรรองรับโปรไฟล์การเข้ารหัสวิดีโอ HD (ความละเอียดสูง) ต่อไปนี้
- [C-1-2] ต้องรองรับการเขียนไฟล์ Matroska WebM
- ควรจัดหาตัวแปลงรหัส VP8 ของฮาร์ดแวร์ที่เป็นไปตามข้อกำหนดการโค้ดฮาร์ดแวร์ RTC ของโปรเจ็กต์ WebM เพื่อให้มั่นใจว่าบริการสตรีมมิงวิดีโอบนเว็บและการประชุมทางวิดีโอมีคุณภาพที่ยอมรับได้
หากการติดตั้งใช้งานอุปกรณ์รายงานการรองรับการเข้ารหัส VP8 สำหรับวิดีโอความละเอียด 720p หรือ 1080p ผ่าน Media API อุปกรณ์ดังกล่าวจะมีลักษณะดังนี้
- [C-2-1] ต้องรองรับโปรไฟล์การเข้ารหัสในตารางต่อไปนี้
SD (คุณภาพต่ำ) | SD (คุณภาพสูง) | HD 720p | HD 1080p | |
---|---|---|---|---|
ความละเอียดของวิดีโอ | 320 x 180 พิกเซล | 640 x 360 พิกเซล | 1280 x 720 พิกเซล | 1920 x 1080 พิกเซล |
อัตราเฟรมของวิดีโอ | 30 fps | 30 fps | 30 fps | 30 fps |
อัตราบิตของวิดีโอ | 800 Kbps | 2 Mbps | 4 Mbps | 10 Mbps |
5.2.4. VP9
หากการติดตั้งใช้งานอุปกรณ์รองรับตัวแปลงรหัส VP9 อุปกรณ์จะมีลักษณะดังนี้
- [C-1-2] ต้องรองรับโปรไฟล์ 0 ระดับ 3
- [C-1-1] ต้องรองรับการเขียนไฟล์ Matroska WebM
- [C-1-3] ต้องสร้างข้อมูล CodecPrivate
- ควรรองรับโปรไฟล์การถอดรหัส HD ตามที่ระบุไว้ในตารางต่อไปนี้
- [C-SR-1] ขอแนะนำอย่างยิ่งให้รองรับโปรไฟล์การถอดรหัส HD ตามที่ระบุไว้ในตารางต่อไปนี้ หากมีโปรแกรมเปลี่ยนไฟล์ฮาร์ดแวร์
SD | HD 720p | HD 1080p | UHD | |
---|---|---|---|---|
ความละเอียดของวิดีโอ | 720 x 480 พิกเซล | 1280 x 720 พิกเซล | 1920 x 1080 พิกเซล | 3840 x 2160 พิกเซล |
อัตราเฟรมของวิดีโอ | 30 fps | 30 fps | 30 fps | 30 fps |
อัตราบิตของวิดีโอ | 1.6 Mbps | 4 Mbps | 5 Mbps | 20 Mbps |
หากการติดตั้งใช้งานอุปกรณ์อ้างว่ารองรับโปรไฟล์ 2 หรือโปรไฟล์ 3 ผ่าน Media API ให้ทำดังนี้
- การรองรับรูปแบบ 12 บิตเป็นตัวเลือก
5.2.5. H.265
หากการติดตั้งใช้งานอุปกรณ์รองรับตัวแปลงรหัส H.265 อุปกรณ์จะดำเนินการต่อไปนี้
- [C-1-1] ต้องรองรับโปรไฟล์หลักระดับ 3
- ควรรองรับโปรไฟล์การเข้ารหัส HD ตามที่ระบุไว้ในตารางต่อไปนี้
- [C-SR-1] ขอแนะนำอย่างยิ่งให้รองรับโปรไฟล์การเข้ารหัส HD ตามที่ระบุไว้ในตารางต่อไปนี้ หากมีโปรแกรมเปลี่ยนไฟล์ฮาร์ดแวร์
SD | HD 720p | HD 1080p | UHD | |
---|---|---|---|---|
ความละเอียดของวิดีโอ | 720 x 480 พิกเซล | 1280 x 720 พิกเซล | 1920 x 1080 พิกเซล | 3840 x 2160 พิกเซล |
อัตราเฟรมของวิดีโอ | 30 fps | 30 fps | 30 fps | 30 fps |
อัตราบิตของวิดีโอ | 1.6 Mbps | 4 Mbps | 5 Mbps | 20 Mbps |
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] ต้องรองรับโปรไฟล์แบบง่ายระดับ 3
5.3.4. H.264
หากการติดตั้งใช้งานอุปกรณ์รองรับโปรแกรมถอดรหัส H.264 อุปกรณ์จะดำเนินการต่อไปนี้
- [C-1-1] ต้องรองรับโปรไฟล์หลักระดับ 3.1 และโปรไฟล์พื้นฐาน การรองรับ ASO (การจัดเรียงสไลซ์แบบกำหนดเอง), FMO (การจัดเรียง Macroblock แบบยืดหยุ่น) และ RS (สไลซ์ที่ซ้ำกัน) นั้นไม่บังคับ
- [C-1-2] ต้องสามารถถอดรหัสวิดีโอที่มีโปรไฟล์ SD (ความละเอียดมาตรฐาน) ที่แสดงในตารางต่อไปนี้ และเข้ารหัสด้วยโปรไฟล์ Baseline และโปรไฟล์หลักระดับ 3.1 (รวมถึง 720p30)
- ควรถอดรหัสวิดีโอที่มีโปรไฟล์ HD (ความละเอียดสูง) ได้ตามที่ระบุไว้ในตารางต่อไปนี้
หากความสูงที่รายงานโดยเมธอด Display.getSupportedModes()
เท่ากับหรือมากกว่าความละเอียดของวิดีโอ การติดตั้งใช้งานอุปกรณ์จะมีลักษณะดังนี้
- [C-2-1] ต้องรองรับโปรไฟล์การถอดรหัสวิดีโอ HD 720p ในตารางต่อไปนี้
- [C-2-2] ต้องรองรับโปรไฟล์การถอดรหัสวิดีโอ HD 1080p ในตารางต่อไปนี้
SD (คุณภาพต่ำ) | SD (คุณภาพสูง) | HD 720p | HD 1080p | |
---|---|---|---|---|
ความละเอียดของวิดีโอ | 320 x 240 พิกเซล | 720 x 480 พิกเซล | 1280 x 720 พิกเซล | 1920 x 1080 พิกเซล |
อัตราเฟรมของวิดีโอ | 30 fps | 30 fps | 60 FPS | 30 FPS (60 FPSโทรทัศน์) |
อัตราบิตของวิดีโอ | 800 Kbps | 2 Mbps | 8 Mbps | 20 Mbps |
5.3.5. H.265 (HEVC)
หากการติดตั้งใช้งานอุปกรณ์รองรับตัวแปลงรหัส H.265 อุปกรณ์จะดำเนินการต่อไปนี้
- [C-1-1] ต้องรองรับโปรไฟล์ Main ระดับ 3 ระดับหลักและโปรไฟล์การถอดรหัสวิดีโอ SD ตามที่ระบุไว้ในตารางต่อไปนี้
- ควรรองรับโปรไฟล์การถอดรหัส HD ตามที่ระบุไว้ในตารางต่อไปนี้
- [C-1-2] ต้องรองรับโปรไฟล์การถอดรหัส HD ตามที่ระบุไว้ในตารางต่อไปนี้ หากมีโปรแกรมถอดรหัสฮาร์ดแวร์
หากความสูงที่รายงานโดยวิธีการ Display.getSupportedModes()
เท่ากับหรือมากกว่าความละเอียดของวิดีโอ ให้ทำดังนี้
- [C-2-1] การติดตั้งใช้งานอุปกรณ์ต้องรองรับ H.265 หรือ VP9 อย่างน้อย 1 รายการสำหรับการถอดรหัสโปรไฟล์ 720, 1080 และ UHD
SD (คุณภาพต่ำ) | SD (คุณภาพสูง) | HD 720p | HD 1080p | UHD | |
---|---|---|---|---|---|
ความละเอียดของวิดีโอ | 352 x 288 พิกเซล | 720 x 480 พิกเซล | 1280 x 720 พิกเซล | 1920 x 1080 พิกเซล | 3840 x 2160 พิกเซล |
อัตราเฟรมของวิดีโอ | 30 fps | 30 fps | 30 fps | 30/60 FPS (60 FPSทีวีที่มีการถอดรหัสด้วยฮาร์ดแวร์ H.265) | 60 FPS |
อัตราบิตของวิดีโอ | 600 Kbps | 1.6 Mbps | 4 Mbps | 5 Mbps | 20 Mbps |
หากการติดตั้งใช้งานอุปกรณ์อ้างว่ารองรับโปรไฟล์ HDR ผ่าน Media API ให้ทำดังนี้
- [C-3-1] การติดตั้งใช้งานอุปกรณ์ต้องยอมรับข้อมูลเมตา HDR ที่จำเป็นจากแอปพลิเคชัน รวมถึงรองรับการดึงข้อมูลและแสดงข้อมูลเมตา HDR ที่จำเป็นจากบิตสตรีมและ/หรือคอนเทนเนอร์
- [C-3-2] การติดตั้งใช้งานอุปกรณ์ต้องแสดงเนื้อหา HDR บนหน้าจออุปกรณ์หรือพอร์ตเอาต์พุตวิดีโอมาตรฐานอย่างเหมาะสม (เช่น HDMI)
5.3.6. VP8
หากการติดตั้งใช้งานอุปกรณ์รองรับตัวแปลงรหัส VP8 อุปกรณ์จะมีลักษณะดังนี้
- [C-1-1] ต้องรองรับโปรไฟล์การถอดรหัส SD ในตารางต่อไปนี้
- ควรใช้ตัวแปลงรหัส VP8 ของฮาร์ดแวร์ที่เป็นไปตามข้อกำหนด
- ควรรองรับโปรไฟล์การถอดรหัส HD ในตารางต่อไปนี้
หากความสูงที่รายงานโดยเมธอด Display.getSupportedModes()
เท่ากับหรือมากกว่าความละเอียดของวิดีโอ ให้ทำดังนี้
- [C-2-1] การติดตั้งใช้งานอุปกรณ์ต้องรองรับโปรไฟล์ 720p ในตารางต่อไปนี้
- [C-2-2] การติดตั้งใช้งานอุปกรณ์ต้องรองรับโปรไฟล์ 1080p ในตารางต่อไปนี้
SD (คุณภาพต่ำ) | SD (คุณภาพสูง) | HD 720p | HD 1080p | |
---|---|---|---|---|
ความละเอียดของวิดีโอ | 320 x 180 พิกเซล | 640 x 360 พิกเซล | 1280 x 720 พิกเซล | 1920 x 1080 พิกเซล |
อัตราเฟรมของวิดีโอ | 30 fps | 30 fps | 30 FPS (60 FPSโทรทัศน์) | 30 (60 FPSโทรทัศน์) |
อัตราบิตของวิดีโอ | 800 Kbps | 2 Mbps | 8 Mbps | 20 Mbps |
5.3.7. VP9
หากการติดตั้งใช้งานอุปกรณ์รองรับตัวแปลงรหัส VP9 อุปกรณ์จะมีลักษณะดังนี้
- [C-1-1] ต้องรองรับโปรไฟล์การถอดรหัสวิดีโอ SD ตามที่ระบุไว้ในตารางต่อไปนี้
- ควรรองรับโปรไฟล์การถอดรหัส HD ตามที่ระบุไว้ในตารางต่อไปนี้
หากการติดตั้งใช้งานอุปกรณ์รองรับตัวแปลงรหัส VP9 และตัวถอดรหัสฮาร์ดแวร์ ให้ทำดังนี้
- [C-2-1] ต้องรองรับโปรไฟล์การถอดรหัส HD ตามที่ระบุไว้ในตารางต่อไปนี้
หากความสูงที่รายงานโดยวิธีการ Display.getSupportedModes()
เท่ากับหรือมากกว่าความละเอียดของวิดีโอ ให้ทำดังนี้
- [C-3-1] การติดตั้งใช้งานอุปกรณ์ต้องรองรับการถอดรหัส VP9 หรือ H.265 อย่างน้อย 1 รูปแบบสำหรับโปรไฟล์ 720, 1080 และ UHD
SD (คุณภาพต่ำ) | SD (คุณภาพสูง) | HD 720p | HD 1080p | UHD | |
---|---|---|---|---|---|
ความละเอียดของวิดีโอ | 320 x 180 พิกเซล | 640 x 360 พิกเซล | 1280 x 720 พิกเซล | 1920 x 1080 พิกเซล | 3840 x 2160 พิกเซล |
อัตราเฟรมของวิดีโอ | 30 fps | 30 fps | 30 fps | 30 fps (60 fpsทีวีที่มีการถอดรหัสฮาร์ดแวร์ VP9) | 60 FPS |
อัตราบิตของวิดีโอ | 600 Kbps | 1.6 Mbps | 4 Mbps | 5 Mbps | 20 Mbps |
หากการติดตั้งใช้งานอุปกรณ์อ้างว่ารองรับ VP9Profile2
หรือ VP9Profile3
ผ่าน 'CodecProfileLevel'
media API ให้ทำดังนี้
- การรองรับรูปแบบ 12 บิตเป็นตัวเลือก
หากการติดตั้งใช้งานอุปกรณ์อ้างว่ารองรับโปรไฟล์ HDR (VP9Profile2HDR
,
VP9Profile2HDR10Plus
, VP9Profile3HDR
, VP9Profile3HDR10Plus
) ผ่าน Media API ให้ทำดังนี้
- [C-4-1] การติดตั้งใช้งานอุปกรณ์ต้องยอมรับข้อมูลเมตา HDR ที่จำเป็น (
KEY_HDR_STATIC_INFO
สำหรับโปรไฟล์ HDR ทั้งหมด รวมถึง 'KEY_HDR10_PLUS_INFO' สำหรับโปรไฟล์ HDR10Plus) จากแอปพลิเคชัน นอกจากนี้ เครื่องมือยังต้องรองรับการดึงข้อมูลและแสดงข้อมูลเมตา HDR ที่จำเป็นจากบิตสตรีมและ/หรือคอนเทนเนอร์ - [C-4-2] การติดตั้งใช้งานอุปกรณ์ต้องแสดงเนื้อหา HDR บนหน้าจออุปกรณ์หรือบนพอร์ตเอาต์พุตวิดีโอมาตรฐานอย่างเหมาะสม (เช่น HDMI)
5.3.8. Dolby Vision
หากการติดตั้งใช้งานอุปกรณ์ประกาศว่ารองรับโปรแกรมถอดรหัส Dolby Vision ผ่าน
HDR_TYPE_DOLBY_VISION
อุปกรณ์ดังกล่าวจะมีคุณสมบัติดังนี้
- [C-1-1] ต้องมีโปรแกรมแยกที่สามารถแยก Dolby Vision
- [C-1-2] ต้องแสดงเนื้อหา Dolby Vision บนหน้าจออุปกรณ์หรือพอร์ตเอาต์พุตวิดีโอมาตรฐานอย่างถูกต้อง (เช่น HDMI)
- [C-1-3] ต้องตั้งค่าดัชนีแทร็กของเเลเยอร์ฐานที่เข้ากันได้แบบย้อนหลัง (หากมี) ให้เหมือนกับดัชนีแทร็กของเเลเยอร์ Dolby Vision ที่รวม
5.3.9. AV1
หากการใช้งานอุปกรณ์รองรับตัวแปลงรหัส AV1 อุปกรณ์จะดำเนินการต่อไปนี้
- [C-1-1] ต้องรองรับโปรไฟล์ 0 รวมถึงเนื้อหา 10 บิต
5.4. การบันทึกเสียง
แม้ว่าข้อกำหนดบางประการที่ระบุไว้ในส่วนนี้จะแสดงเป็น "ควร" มาตั้งแต่ Android 4.3 แต่เราวางแผนที่จะเปลี่ยนคำจำกัดความความเข้ากันได้สำหรับเวอร์ชันในอนาคตเป็น "ต้อง" เราขอแนะนำอย่างยิ่งให้อุปกรณ์ Android ที่มีอยู่และอุปกรณ์ใหม่เป็นไปตามข้อกำหนดเหล่านี้ที่ระบุว่า "ควร" ไม่เช่นนั้นอุปกรณ์จะใช้งานร่วมกับ Android ไม่ได้เมื่ออัปเกรดเป็นเวอร์ชันในอนาคต
5.4.1. การบันทึกเสียงดิบและข้อมูลไมโครโฟน
หากการติดตั้งใช้งานอุปกรณ์ประกาศ android.hardware.microphone
อุปกรณ์จะมีลักษณะดังนี้
[C-1-1] ต้องอนุญาตให้บันทึกเนื้อหาเสียงดิบที่มีคุณลักษณะต่อไปนี้
- รูปแบบ: Linear PCM, 16 บิต
- อัตราการสุ่มตัวอย่าง: 8000, 11025, 16000, 44100, 48000 Hz
- แชแนล: โมโน
ควรอนุญาตให้บันทึกเนื้อหาเสียงดิบที่มีลักษณะต่อไปนี้
- รูปแบบ: Linear PCM, 16 บิต และ 24 บิต
- อัตราการสุ่มตัวอย่าง: 8000, 11025, 16000, 22050, 24000, 32000, 44100, 48000 Hz
- ช่อง: ช่องเท่ากับจำนวนไมโครโฟนในอุปกรณ์
[C-1-2] ต้องบันทึกที่อัตราการสุ่มตัวอย่างข้างต้นโดยไม่ต้องอัปสเกล
[C-1-3] ต้องมีตัวกรองการลบรอยหยักที่เหมาะสมเมื่อบันทึกอัตราตัวอย่างที่ระบุไว้ข้างต้นด้วยการลดขนาดการสุ่มตัวอย่าง
ควรอนุญาตให้บันทึกเนื้อหาเสียงดิบคุณภาพระดับวิทยุ AM และ DVD ซึ่งหมายความว่ามีลักษณะต่อไปนี้
- รูปแบบ: Linear PCM, 16 บิต
- อัตราการสุ่มตัวอย่าง: 22050, 48000 Hz
- ช่อง: สเตอริโอ
[C-1-4] ต้องปฏิบัติตาม
MicrophoneInfo
API และป้อนข้อมูลไมโครโฟนที่มีอยู่ในอุปกรณ์อย่างถูกต้อง ซึ่งแอปพลิเคชันของบุคคลที่สามเข้าถึงได้ผ่านAudioManager.getMicrophones()
API และไมโครโฟนที่ใช้งานอยู่ในปัจจุบันซึ่งแอปพลิเคชันของบุคคลที่สามเข้าถึงได้ผ่านAudioRecord.getActiveMicrophones()
และMediaRecorder.getActiveMicrophones()
API หากการติดตั้งใช้งานอุปกรณ์อนุญาตให้บันทึกเนื้อหาเสียงดิบคุณภาพระดับวิทยุ AM และ DVD อุปกรณ์จะดำเนินการดังนี้[C-2-1] ต้องบันทึกโดยไม่มีการอัปแซมเปิลในสัดส่วนสูงกว่า 16000:22050 หรือ 44100:48000
[C-2-2] ต้องมีตัวกรองการลบรอยหยักที่เหมาะสมสำหรับการเพิ่มหรือลดขนาด
5.4.2. บันทึกเสียงเพื่อใช้การจดจำเสียง
หากการติดตั้งใช้งานอุปกรณ์ประกาศ android.hardware.microphone
อุปกรณ์จะมีลักษณะดังนี้
- [C-1-1] ต้องบันทึกแหล่งที่มาของเสียง
android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION
ที่อัตราการสุ่มตัวอย่างอย่างใดอย่างหนึ่งต่อไปนี้ 44100 และ 48000 - [C-1-2] ต้องปิดใช้การประมวลผลเสียงแบบลดเสียงรบกวนโดยค่าเริ่มต้นเมื่อบันทึกสตรีมเสียงจากแหล่งที่มาของเสียง
AudioSource.VOICE_RECOGNITION
- [C-1-3] ต้องปิดใช้การควบคุมอัตราขยายเสียงอัตโนมัติโดยค่าเริ่มต้นเมื่อบันทึกสตรีมเสียงจากแหล่งที่มาของเสียง
AudioSource.VOICE_RECOGNITION
- ควรบันทึกสตรีมเสียงสำหรับการจดจำเสียงโดยมีลักษณะเป็นแอมพลิจูดที่ราบเรียบเทียบกับลักษณะความถี่โดยประมาณ กล่าวคือ ±3 dB จาก 100 Hz ถึง 4000 Hz
- ควรบันทึกสตรีมเสียงสำหรับการจดจำเสียงโดยตั้งค่าความไวอินพุตเพื่อให้แหล่งที่มาของระดับกำลังเสียง (SPL) 90 dB ที่ 1,000 Hz ให้ค่า RMS เท่ากับ 2,500 สำหรับตัวอย่าง 16 บิต
- ควรบันทึกสตรีมเสียงสำหรับการจดจำเสียงเพื่อให้ระดับแอมพลิจูด PCM ติดตามการเปลี่ยนแปลง SPL อินพุตแบบเชิงเส้นในช่วงอย่างน้อย 30 dB จาก -18 dB ถึง +12 dB เทียบกับ SPL 90 dB ที่ไมโครโฟน
- ควรบันทึกสตรีมเสียงสำหรับการจดจำเสียงโดยมีความเพี้ยนตามฮาร์โมนิกทั้งหมด (THD) น้อยกว่า 1% สำหรับ 1 kHz ที่ระดับอินพุต 90 dB SPL ที่ไมโครโฟน
หากการติดตั้งใช้งานอุปกรณ์ประกาศว่า android.hardware.microphone
และเทคโนโลยีการลดเสียงรบกวน (การลด) ได้รับการปรับแต่งสำหรับการจดจำคำพูด อุปกรณ์จะดำเนินการต่อไปนี้
- [C-2-1] ต้องอนุญาตให้ควบคุมเอฟเฟกต์เสียงนี้ได้ด้วย
android.media.audiofx.NoiseSuppressor
API - [C-2-2] ต้องระบุการใช้งานเทคโนโลยีลดเสียงรบกวนแต่ละรายการโดยไม่ซ้ำกันผ่านฟิลด์
AudioEffect.Descriptor.uuid
5.4.3. บันทึกเพื่อเปลี่ยนเส้นทางการเล่น
คลาส android.media.MediaRecorder.AudioSource
มีREMOTE_SUBMIX
แหล่งที่มาของเสียง
หากการติดตั้งใช้งานอุปกรณ์ประกาศทั้ง android.hardware.audio.output
และ
android.hardware.microphone
อุปกรณ์จะมีลักษณะดังนี้
[C-1-1] ต้องติดตั้งใช้งานแหล่งที่มาของเสียง
REMOTE_SUBMIX
อย่างถูกต้องเพื่อให้แอปพลิเคชันใช้android.media.AudioRecord
API เพื่อบันทึกจากแหล่งที่มาของเสียงนี้ โดยบันทึกสตรีมเสียงทั้งหมดยกเว้นสตรีมต่อไปนี้AudioManager.STREAM_RING
AudioManager.STREAM_ALARM
AudioManager.STREAM_NOTIFICATION
5.4.4. การตัดเสียงก้อง
หากการติดตั้งใช้งานอุปกรณ์ประกาศ android.hardware.microphone
อุปกรณ์จะมีลักษณะดังนี้
- ควรใช้เทคโนโลยีตัวตัดเสียงก้อง (AEC) ที่ปรับแต่งมาเพื่อการสื่อสารด้วยเสียงและใช้กับเส้นทางการบันทึกเมื่อบันทึกโดยใช้
AudioSource.VOICE_COMMUNICATION
หากการติดตั้งใช้งานอุปกรณ์มีการตัดเสียงสะท้อนแบบอะคูสติกซึ่งแทรกอยู่ในเส้นทางเสียงที่บันทึกเมื่อเลือก AudioSource.VOICE_COMMUNICATION
ระบบจะดำเนินการต่อไปนี้
- [C-SR-1] เราขอแนะนำอย่างยิ่งให้ประกาศผ่านเมธอด AcousticEchoCanceler ของ AcousticEchoCanceler.isAvailable() ใน API
- [C-SR-2] ขอแนะนำอย่างยิ่งให้ควบคุมเอฟเฟกต์เสียงนี้ได้ด้วย AcousticEchoCanceler API
- [C-SR-3] ขอแนะนำอย่างยิ่งให้ระบุการใช้งานเทคโนโลยี AEC แต่ละรายการโดยไม่ซ้ำกันผ่านช่อง AudioEffect.Descriptor.uuid
5.4.5. การจับภาพพร้อมกัน
หากการติดตั้งใช้งานอุปกรณ์ประกาศเป็น android.hardware.microphone
การติดตั้งใช้งานจะต้องใช้การบันทึกพร้อมกันตามที่อธิบายไว้ในเอกสารนี้ ดังนี้
- [C-1-1] ต้องอนุญาตให้เข้าถึงไมโครโฟนพร้อมกันโดยบริการการช่วยเหลือพิเศษที่บันทึกด้วย
AudioSource.VOICE_RECOGNITION
และแอปพลิเคชันที่บันทึกด้วยAudioSource
อย่างน้อย 1 แอป - [C-1-2] ต้องอนุญาตให้แอปพลิเคชันที่ติดตั้งไว้ล่วงหน้าซึ่งมีบทบาท Assistant และแอปพลิเคชันอย่างน้อย 1 แอปที่บันทึกด้วย
AudioSource
ยกเว้นAudioSource.VOICE_COMMUNICATION
หรือAudioSource.CAMCORDER
เข้าถึงไมโครโฟนพร้อมกัน - [C-1-3] ต้องปิดเสียงการบันทึกเสียงสำหรับแอปพลิเคชันอื่นๆ ทั้งหมด ยกเว้นบริการการช่วยเหลือพิเศษ ขณะที่แอปพลิเคชันกำลังบันทึกด้วย
AudioSource.VOICE_COMMUNICATION
หรือAudioSource.CAMCORDER
อย่างไรก็ตาม เมื่อแอปหนึ่งบันทึกผ่านAudioSource.VOICE_COMMUNICATION
แอปอื่นจะบันทึกเสียงการโทรได้หากเป็นแอปที่มีสิทธิ์ (ติดตั้งไว้ล่วงหน้า) ที่มีสิทธิ์CAPTURE_AUDIO_OUTPUT
- [C-1-4] หากแอปพลิเคชัน 2 แอปขึ้นไปกำลังบันทึกพร้อมกันและหากแอปไม่มี UI แสดงอยู่ด้านบน แอปที่เริ่มบันทึกล่าสุดจะได้รับเสียง
5.4.6. ระดับการขยายเสียงของไมโครโฟน
หากการติดตั้งใช้งานอุปกรณ์ประกาศ android.hardware.microphone
อุปกรณ์จะมีลักษณะดังนี้
- ควรแสดงลักษณะความดังเทียบกับความถี่ที่ราบเรียบโดยประมาณในช่วงความถี่กลาง โดยเฉพาะอย่างยิ่ง ±3dB จาก 100 Hz ถึง 4000 Hz สำหรับไมโครโฟนแต่ละตัวที่ใช้บันทึกแหล่งที่มาของเสียงสำหรับการจดจำเสียง
- ควรตั้งค่าความไวอินพุตเสียงเพื่อให้แหล่งที่มาของเสียงไซน์ 1,000 Hz ที่เล่นที่ระดับความดันเสียง (SPL) 90 dB ให้การตอบสนองที่มี RMS 2500 สำหรับตัวอย่าง 16 บิต (หรือ -22.35 dB Full Scale สำหรับตัวอย่างแบบทศนิยม/ความแม่นยำแบบ Double) สำหรับไมโครโฟนแต่ละตัวที่ใช้บันทึกแหล่งที่มาของเสียงสำหรับการจดจำเสียง
- [C-SR-1] ขอแนะนำอย่างยิ่งให้แสดงระดับแอมพลิจูดในช่วงความถี่ต่ำ โดยเฉพาะอย่างยิ่งจาก ±20 dB จาก 5 Hz ถึง 100 Hz เมื่อเทียบกับช่วงความถี่กลางสำหรับไมโครโฟนแต่ละตัวที่ใช้บันทึกแหล่งที่มาของเสียงที่ระบบจดจำเสียง
- [C-SR-2] ขอแนะนำอย่างยิ่งให้แสดงระดับแอมพลิจูดในช่วงความถี่สูง โดยเฉพาะอย่างยิ่งจาก ±30 dB จาก 4000 Hz ถึง 22 KHz เมื่อเทียบกับช่วงความถี่กลางสำหรับไมโครโฟนแต่ละตัวที่ใช้บันทึกแหล่งที่มาของเสียงสำหรับการจดจำเสียง
5.5. การเล่นเสียง
Android รองรับการอนุญาตให้แอปเล่นเสียงผ่านอุปกรณ์ต่อพ่วงเอาต์พุตเสียงตามที่ระบุไว้ในส่วนที่ 7.8.2
5.5.1. การเล่นเสียงดิบ
หากการติดตั้งใช้งานอุปกรณ์ประกาศ android.hardware.audio.output
อุปกรณ์จะมีลักษณะดังนี้
[C-1-1] ต้องอนุญาตให้เล่นเนื้อหาเสียงดิบที่มีคุณลักษณะต่อไปนี้
- รูปแบบต้นฉบับ: Linear PCM, 16 บิต, 8 บิต, ฟลอยท์
- ช่อง: โมโน สเตอริโอ การกำหนดค่าแบบหลายช่องที่ถูกต้องซึ่งมีได้สูงสุด 8 ช่อง
- อัตราการสุ่มตัวอย่าง (เป็น Hz)
- 8000, 11025, 16000, 22050, 24000, 32000, 44100, 48000 ที่การกำหนดค่าแชแนลที่ระบุไว้ข้างต้น
- 96000 แบบโมโนและสเตอริโอ
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-1] ขอแนะนำอย่างยิ่งให้รองรับเอฟเฟกต์แบบทศนิยมและแบบหลายช่อง
5.5.3. ระดับเสียงเอาต์พุตเสียง
การติดตั้งใช้งานอุปกรณ์ยานยนต์
- ควรอนุญาตให้ปรับระดับเสียงแยกกันสำหรับสตรีมเสียงแต่ละรายการโดยใช้ประเภทเนื้อหาหรือการใช้งานตามที่ระบุโดย AudioAttributes และการใช้งานระบบเสียงรถยนต์ตามที่ระบุแบบสาธารณะใน
android.car.CarAudioManager
5.5.4. การโอนข้อมูลเสียง
หากการติดตั้งใช้งานอุปกรณ์รองรับการเล่นที่ส่งผ่านข้อมูลเสียง อุปกรณ์จะดำเนินการต่อไปนี้
- [C-SR-1] ขอแนะนำอย่างยิ่งให้ตัดเนื้อหาเสียงแบบเล่นต่อเนื่องที่เล่นอยู่เมื่อระบุโดย AudioTrack gapless API และคอนเทนเนอร์สื่อสำหรับ MediaPlayer
5.6. เวลาในการตอบสนองของเสียง
เวลาในการตอบสนองของเสียงคือความล่าช้าของเวลาเมื่อสัญญาณเสียงผ่านระบบ แอปพลิเคชันหลายคลาสอาศัยเวลาในการตอบสนองที่สั้นเพื่อให้ได้เสียงเอฟเฟกต์แบบเรียลไทม์
ในส่วนนี้จะใช้คําจํากัดความต่อไปนี้
- เวลาในการตอบสนองของเอาต์พุต ช่วงเวลาระหว่างที่แอปพลิเคชันเขียนเฟรมข้อมูลที่เข้ารหัส PCM และเวลาที่เสียงที่เกี่ยวข้องแสดงต่อสภาพแวดล้อมที่ทรานสดิวเซอร์ในอุปกรณ์หรือสัญญาณออกจากอุปกรณ์ผ่านพอร์ตและสามารถสังเกตได้ภายนอก
- เวลาในการตอบสนองของเอาต์พุตแบบไม่อุ่นเครื่อง เวลาที่ผ่านไประหว่างการเริ่มสตรีมเอาต์พุตกับเวลาแสดงเฟรมแรกตามการประทับเวลา เมื่อระบบเอาต์พุตเสียงไม่ได้ใช้งานและปิดอยู่ก่อนคำขอ
- เวลาในการตอบสนองของเอาต์พุตอย่างต่อเนื่อง เวลาในการตอบสนองของเอาต์พุตสำหรับเฟรมต่อๆ ไปหลังจากอุปกรณ์เล่นเสียง
- เวลาในการตอบสนองต่อการป้อนข้อมูล ช่วงเวลาระหว่างที่เสียงจากสภาพแวดล้อมส่งไปยังอุปกรณ์ที่ทรานสดิวเซอร์ในอุปกรณ์หรือสัญญาณเข้าสู่อุปกรณ์ผ่านพอร์ต และแอปพลิเคชันอ่านเฟรมข้อมูลที่เข้ารหัส PCM ที่เกี่ยวข้อง
- ข้อมูลเข้าสูญหาย ส่วนเริ่มต้นของสัญญาณอินพุตที่ใช้งานไม่ได้หรือใช้งานไม่ได้
- เวลาในการตอบสนองของอินพุตแบบ Cold เวลาที่ผ่านไประหว่างที่เริ่มสตรีมกับเวลาที่ระบบได้รับเฟรมแรกที่ถูกต้อง เมื่อระบบอินพุตเสียงไม่ได้ทำงานและปิดอยู่ก่อนคำขอ
- เวลาในการตอบสนองของการป้อนข้อมูลอย่างต่อเนื่อง เวลาในการตอบสนองของอินพุตสำหรับเฟรมต่อๆ ไปขณะที่อุปกรณ์บันทึกเสียง
- การกระวนของเอาต์พุตแบบ Cold ความแปรปรวนในการวัดค่าเวลาในการตอบสนองของเอาต์พุตแบบ Cold ที่แยกกัน
- ความผันผวนของอินพุตแบบเย็น ความแปรปรวนในการวัดค่าเวลาในการตอบสนองของอินพุตแบบ Cold ที่แยกกัน
- เวลาในการตอบสนองแบบไปกลับอย่างต่อเนื่อง ผลรวมของเวลาในการตอบสนองของอินพุตแบบต่อเนื่องบวกเวลาในการตอบสนองของเอาต์พุตแบบต่อเนื่องบวกระยะเวลาบัฟเฟอร์ 1 รายการ ระยะเวลาบัฟเฟอร์ช่วยให้แอปมีเวลาประมวลผลสัญญาณและเวลาในการลดความแตกต่างของเฟสระหว่างสตรีมอินพุตและเอาต์พุต
- OpenSL ES PCM buffer queue API ชุด API OpenSL ES ที่เกี่ยวข้องกับ PCM ภายใน Android NDK
- AAudio Native Audio API ชุด AAudio API ภายใน Android NDK
- การประทับเวลา คู่ที่ประกอบด้วยตําแหน่งเฟรมแบบสัมพัทธ์ภายในสตรีม และเวลาโดยประมาณเมื่อเฟรมนั้นเข้าสู่หรือออกจากไปป์ไลน์การประมวลผลเสียงในอุปกรณ์ปลายทางที่เกี่ยวข้อง ดูข้อมูลเพิ่มเติมได้ที่ AudioTimestamp
- ข้อบกพร่อง การหยุดชะงักชั่วคราวหรือค่าตัวอย่างที่ไม่ถูกต้องในสัญญาณเสียง ซึ่งมักเกิดจากบัฟเฟอร์ไม่เพียงพอสำหรับเอาต์พุต บัฟเฟอร์เกินสำหรับอินพุต หรือแหล่งที่มาอื่นๆ ของสัญญาณรบกวนแบบดิจิทัลหรือแบบอนาล็อก
- ความเบี่ยงเบนสัมบูรณ์เฉลี่ย ค่าเฉลี่ยของค่าสัมบูรณ์ของค่าเบี่ยงเบนจากค่าเฉลี่ยสำหรับชุดค่า
- เวลาในการตอบสนองของฟีเจอร์แตะเพื่อเปิดเสียง เวลาที่ผ่านไประหว่างที่มีการแตะหน้าจอกับเวลาที่ได้ยินเสียงที่เกิดจากเสียงที่เกิดจากการแตะนั้นในลำโพง
หากการติดตั้งใช้งานอุปกรณ์ประกาศเป็น android.hardware.audio.output
อุปกรณ์นั้นต้องเป็นไปตามข้อกำหนดต่อไปนี้เป็นอย่างน้อย
- [C-1-1] การประทับเวลาเอาต์พุตที่ AudioTrack.getTimestamp และ
AAudioStream_getTimestamp
แสดงผลจะมีความแม่นยำ +/- 2 มิลลิวินาที - [C-1-2] เวลาในการตอบสนองของเอาต์พุตแบบ Cold Start ไม่เกิน 500 มิลลิวินาที
หากการติดตั้งใช้งานอุปกรณ์ประกาศเป็น android.hardware.audio.output
เราขอแนะนำอย่างยิ่งให้เป็นไปตามข้อกำหนดต่อไปนี้หรือมากกว่า
- [C-SR-1] เวลาในการตอบสนองของเอาต์พุตแบบ Cold ไม่เกิน 100 มิลลิวินาทีผ่านเส้นทางข้อมูลของลำโพง เราขอแนะนำอย่างยิ่งให้อุปกรณ์ที่มีอยู่และอุปกรณ์ใหม่ที่ใช้ Android เวอร์ชันนี้ปฏิบัติตามข้อกำหนดเหล่านี้ในตอนนี้ ในการเปิดตัวแพลตฟอร์มในอนาคต เราจะกำหนดให้เวลาในการตอบสนองของเอาต์พุตแบบ Cold ต้องเป็น 200 มิลลิวินาทีหรือน้อยกว่า
- [C-SR-2] เวลาในการตอบสนองของฟีเจอร์แตะเพื่อเปิดเสียงไม่เกิน 80 มิลลิวินาที
- [C-SR-3] ลดการกระวนกระวายของเอาต์พุตที่เย็น
- [C-SR-4] การประทับเวลาเอาต์พุตที่ AudioTrack.getTimestamp และ
AAudioStream_getTimestamp
แสดงผลจะมีความแม่นยำ +/- 1 มิลลิวินาที
หากการติดตั้งใช้งานอุปกรณ์เป็นไปตามข้อกำหนดข้างต้น หลังจากการปรับเทียบครั้งแรก เมื่อใช้ AAudio Native Audio API สำหรับเวลาในการตอบสนองของเอาต์พุตแบบต่อเนื่องและเวลาในการตอบสนองของเอาต์พุตแบบ Cold บนอุปกรณ์เอาต์พุตเสียงที่รองรับอย่างน้อย 1 เครื่อง ข้อมูลต่อไปนี้จะแสดง
- [C-SR-5] ขอแนะนำอย่างยิ่งให้รายงานเสียงที่มีเวลาในการตอบสนองต่ำด้วยการประกาศใช้
android.hardware.audio.low_latency
Flag ฟีเจอร์ - [C-SR-6] ขอแนะนำอย่างยิ่งให้ปฏิบัติตามข้อกำหนดสำหรับเสียงที่มีเวลาในการตอบสนองต่ำผ่าน AAudio API
- [C-SR-7] ขอแนะนําอย่างยิ่งให้ตรวจสอบว่าสตรีมที่แสดงผล
AAUDIO_PERFORMANCE_MODE_LOW_LATENCY
จากAAudioStream_getPerformanceMode()
มีค่าที่แสดงผลโดยAAudioStream_getFramesPerBurst()
น้อยกว่าหรือเท่ากับค่าที่แสดงผลโดยandroid.media.AudioManager.getProperty(String)
สําหรับคีย์พร็อพเพอร์ตี้AudioManager.PROPERTY_OUTPUT_FRAMES_PER_BUFFER
หากการติดตั้งใช้งานอุปกรณ์ไม่เป็นไปตามข้อกำหนดสำหรับเสียงที่มีเวลาในการตอบสนองต่ำผ่าน API เสียงแบบเนทีฟของ AAudio อุปกรณ์จะมีลักษณะดังนี้
- [C-2-1] ต้องไม่รายงานการรองรับเสียงที่มีเวลาในการตอบสนองต่ำ
หากการติดตั้งใช้งานอุปกรณ์มี android.hardware.microphone
อุปกรณ์นั้นต้องเป็นไปตามข้อกำหนดด้านเสียงอินพุตต่อไปนี้
- [C-3-1] จำกัดข้อผิดพลาดในการประทับเวลาอินพุตตามที่ AudioRecord.getTimestamp หรือ
AAudioStream_getTimestamp
แสดงผลเป็น +/- 2 มิลลิวินาที "ข้อผิดพลาด" ในที่นี้หมายถึงความคลาดเคลื่อนจากค่าที่ถูกต้อง - [C-3-2] เวลาในการตอบสนองของอินพุตแบบ Cold ไม่เกิน 500 มิลลิวินาที
หากการติดตั้งใช้งานอุปกรณ์มี android.hardware.microphone
เราขอแนะนำอย่างยิ่งให้อุปกรณ์ดังกล่าวเป็นไปตามข้อกำหนดด้านเสียงอินพุตต่อไปนี้
- [C-SR-8] เวลาในการตอบสนองของอินพุตแบบ Cold ไม่เกิน 100 มิลลิวินาทีผ่านเส้นทางข้อมูลของไมโครโฟน เราขอแนะนำอย่างยิ่งให้อุปกรณ์ที่มีอยู่และอุปกรณ์ใหม่ที่ใช้ Android เวอร์ชันนี้ปฏิบัติตามข้อกำหนดเหล่านี้ในตอนนี้ ในรุ่นแพลตฟอร์มในอนาคต เราจะกำหนดให้เวลาในการตอบสนองของอินพุตแบบ Cold ต้องเป็น 200 มิลลิวินาทีหรือน้อยกว่า
- [C-SR-9] เวลาในการตอบสนองของอินพุตแบบต่อเนื่องไม่เกิน 30 มิลลิวินาที
- [C-SR-10] ลดการกระวนกระวายของอินพุตที่เย็น
- [C-SR-11] จำกัดข้อผิดพลาดในการประทับเวลาของอินพุตตามที่แสดงผลโดย AudioRecord.getTimestamp หรือ
AAudioStream_getTimestamp
เป็น +/- 1 มิลลิวินาที
หากการติดตั้งใช้งานอุปกรณ์ประกาศ android.hardware.audio.output
และ
android.hardware.microphone
อุปกรณ์จะมีลักษณะดังนี้
- [C-SR-12] ขอแนะนำอย่างยิ่งให้มีเวลาในการตอบสนองไป-กลับแบบต่อเนื่องเฉลี่ยไม่เกิน 50 มิลลิวินาทีในการวัด 5 ครั้ง โดยมีค่าความเบี่ยงเบนสัมบูรณ์เฉลี่ยน้อยกว่า 10 มิลลิวินาทีในเส้นทางที่รองรับอย่างน้อย 1 เส้นทาง
5.7. โปรโตคอลเครือข่าย
การติดตั้งใช้งานอุปกรณ์ต้องรองรับโปรโตคอลเครือข่ายสื่อสำหรับการเล่นเสียงและวิดีโอตามที่ระบุไว้ในเอกสารประกอบของ Android SDK
สำหรับแต่ละรูปแบบโค้ดและคอนเทนเนอร์ที่การติดตั้งใช้งานอุปกรณ์ต้องรองรับ การติดตั้งใช้งานอุปกรณ์จะต้องมีคุณสมบัติดังนี้
[C-1-1] ต้องรองรับตัวแปลงสัญญาณหรือคอนเทนเนอร์นั้นผ่าน HTTP และ HTTPS
[C-1-2] ต้องรองรับรูปแบบกลุ่มสื่อที่เกี่ยวข้องตามที่แสดงในตารางรูปแบบกลุ่มสื่อด้านล่างในโปรโตคอลฉบับร่าง HTTP Live Streaming เวอร์ชัน 7
[C-1-3] ต้องรองรับรูปแบบเพย์โหลด RTSP ที่เกี่ยวข้องตามที่แสดงในตาราง RTSP ด้านล่าง ดูข้อยกเว้นได้ที่เชิงอรรถของตารางในส่วนที่ 5.1
รูปแบบกลุ่มสื่อ
รูปแบบกลุ่ม | ข้อมูลอ้างอิง | การรองรับตัวแปลงรหัสที่จำเป็น |
---|---|---|
MPEG-2 Transport Stream | ISO 13818 |
ตัวแปลงรหัสวิดีโอ:
และ MPEG-2 ได้ที่ส่วนที่ 5.1.8 ตัวแปลงรหัสเสียง
|
AAC ที่มีการจัดเฟรม ADTS และแท็ก ID3 | ISO 13818-7 | ดูรายละเอียดเกี่ยวกับ AAC และรูปแบบต่างๆ ได้ที่ส่วนที่ 5.1.1 |
WebVTT | WebVTT |
RTSP (RTP, SDP)
ชื่อโปรไฟล์ | ข้อมูลอ้างอิง | การรองรับตัวแปลงรหัสที่จำเป็น |
---|---|---|
H264 AVC | RFC 6184 | ดูรายละเอียดเกี่ยวกับ H264 AVC ได้ที่ส่วนที่ 5.1.8 |
MP4A-LATM | RFC 6416 | ดูรายละเอียดเกี่ยวกับ AAC และรูปแบบต่างๆ ได้ที่ส่วนที่ 5.1.3 |
H263-1998 |
RFC 3551 RFC 4629 RFC 2190 |
ดูรายละเอียดเกี่ยวกับ H263 ได้ที่ส่วนที่ 5.1.8 |
H263-2000 | RFC 4629 | ดูรายละเอียดเกี่ยวกับ H263 ได้ที่ส่วนที่ 5.1.8 |
AMR | RFC 4867 | ดูรายละเอียดเกี่ยวกับ AMR-NB ได้ที่ส่วนที่ 5.1.3 |
AMR-WB | RFC 4867 | ดูรายละเอียดเกี่ยวกับ AMR-WB ได้ที่ส่วนที่ 5.1.3 |
MP4V-ES | RFC 6416 | ดูรายละเอียดเกี่ยวกับ MPEG-4 SP ได้ที่ส่วนที่ 5.1.8 |
mpeg4-generic | RFC 3640 | ดูรายละเอียดเกี่ยวกับ AAC และรูปแบบต่างๆ ได้ที่ส่วนที่ 5.1.3 |
MP2T | RFC 2250 | ดูรายละเอียดได้ที่ MPEG-2 Transport Stream ในส่วน HTTP Live Streaming |
5.8 Secure Media
หากการติดตั้งใช้งานอุปกรณ์รองรับเอาต์พุตวิดีโอที่ปลอดภัยและรองรับแพลตฟอร์มที่ปลอดภัย อุปกรณ์จะมีลักษณะดังนี้
- [C-1-1] ต้องประกาศรองรับ
Display.FLAG_SECURE
หากการติดตั้งใช้งานอุปกรณ์ประกาศว่ารองรับ Display.FLAG_SECURE
และรองรับโปรโตคอลจอแสดงผลไร้สาย อุปกรณ์จะมีลักษณะดังนี้
- [C-2-1] ต้องรักษาความปลอดภัยของลิงก์ด้วยกลไกการเข้ารหัสที่มีประสิทธิภาพ เช่น HDCP 2.x ขึ้นไปสำหรับจอภาพที่เชื่อมต่อผ่านโปรโตคอลไร้สาย เช่น Miracast
หากการติดตั้งใช้งานอุปกรณ์ประกาศว่ารองรับ Display.FLAG_SECURE
และรองรับจอแสดงผลภายนอกแบบใช้สาย อุปกรณ์จะมีลักษณะดังนี้
- [C-3-1] ต้องรองรับ HDCP 1.2 ขึ้นไปสำหรับจอแสดงผลภายนอกทั้งหมดที่เชื่อมต่อผ่านพอร์ตแบบใช้สายที่ผู้ใช้เข้าถึงได้
5.9. Musical Instrument Digital Interface (MIDI)
หากการติดตั้งใช้งานอุปกรณ์รายงานการรองรับฟีเจอร์ android.software.midi
ผ่านคลาส android.content.pm.PackageManager
ระบบจะดำเนินการดังนี้
[C-1-1] ต้องรองรับ MIDI ผ่านการรับส่งฮาร์ดแวร์ที่รองรับ MIDI ทั้งหมดสำหรับการเชื่อมต่อที่ไม่ใช่ MIDI ทั่วไป ซึ่งการรับส่งดังกล่าว ได้แก่
- โหมดโฮสต์ USB, ส่วนที่ 7.7
- MIDI ผ่านบลูทูธ LE ที่ทำหน้าที่เป็นบทบาทกลาง ส่วน 7.4.3
[C-1-2] ต้องรองรับการรับส่งซอฟต์แวร์ MIDI ระหว่างแอป (อุปกรณ์ MIDI เสมือนจริง)
[C-1-3] ต้องมี libamidi.so (การรองรับ MIDI ดั้งเดิม)
ควรรองรับโหมดอุปกรณ์ต่อพ่วง MIDI ผ่าน USB, ส่วน 7.7
5.10. เสียงระดับมืออาชีพ
หากการติดตั้งใช้งานอุปกรณ์รายงานการรองรับฟีเจอร์ android.hardware.audio.pro
ผ่านคลาส android.content.pm.PackageManager ระบบจะดำเนินการดังนี้
- [C-1-1] ต้องรายงานการรองรับฟีเจอร์
android.hardware.audio.low_latency
- [C-1-2] ต้องมีเวลาในการตอบสนองไป-กลับของเสียงแบบต่อเนื่องตามที่ระบุไว้ในส่วน5.6 เวลาในการตอบสนองของเสียง โดยต้องไม่เกิน 20 มิลลิวินาทีและควรไม่เกิน 10 มิลลิวินาทีในเส้นทางที่รองรับอย่างน้อย 1 เส้นทาง
- [C-1-3] ต้องมีพอร์ต USB ที่รองรับโหมดโฮสต์ USB และโหมดอุปกรณ์ต่อพ่วง USB
- [C-1-4] ต้องรายงานการรองรับฟีเจอร์
android.software.midi
- [C-1-5] ต้องเป็นไปตามข้อกำหนดด้านเวลาในการตอบสนองและเสียง USB โดยใช้ API เสียงแบบเนทีฟของ AAudio
- [C-1-6] ต้องมีเวลาในการตอบสนองของเอาต์พุตแบบ Cold ไม่เกิน 200 มิลลิวินาที
- [C-1-7] ต้องมีเวลาในการตอบสนองของอินพุตแบบ Cold ไม่เกิน 200 มิลลิวินาที
- [C-SR-1] ขอแนะนำอย่างยิ่งให้มีค่าเวลาในการตอบสนองตามที่ระบุไว้ในส่วนที่ 5.6 เวลาในการตอบสนองของเสียง ซึ่งมีค่าไม่เกิน 20 มิลลิวินาทีจากการวัด 5 ครั้ง โดยค่าความเบี่ยงเบนสัมบูรณ์เฉลี่ยน้อยกว่า 5 มิลลิวินาทีในเส้นทางจากลำโพงไปยังไมโครโฟน
- [C-SR-2] ขอแนะนำอย่างยิ่งให้ปฏิบัติตามข้อกำหนดของเสียงระดับมือโปรสำหรับเวลาในการตอบสนองของเสียงแบบไปกลับอย่างต่อเนื่อง เวลาในการตอบสนองของอินพุตแบบ Cold และเวลาในการตอบสนองของเอาต์พุตแบบ Cold รวมถึงข้อกำหนดของเสียง USB โดยใช้ API เสียงแบบเนทีฟของ AAudio ในเส้นทาง MMAP
- [C-SR-3] ขอแนะนำอย่างยิ่งให้รักษาระดับประสิทธิภาพของ CPU ให้สม่ำเสมอขณะที่เสียงทำงานอยู่และภาระงานของ CPU แตกต่างกันไป คุณควรทดสอบโดยใช้แอป Android SynthMark
SynthMark ใช้โปรแกรมสังเคราะห์เสียงซอฟต์แวร์ที่ทำงานบนเฟรมเวิร์กเสียงจำลองซึ่งวัดประสิทธิภาพของระบบ แอป SynthMark ต้องทำงานโดยใช้ตัวเลือก "การทดสอบอัตโนมัติ" และได้ผลลัพธ์ต่อไปนี้
- voicemark.90 >= 32 voices
- latencymark.fixed.little <= 15 msec
- latencymark.dynamic.little <= 50 msec
ดูคำอธิบายการเปรียบเทียบได้จากเอกสารประกอบของ SynthMark
- ควรลดความคลาดเคลื่อนและการเลื่อนเวลาของนาฬิกาเสียงเมื่อเทียบกับเวลามาตรฐาน
- ควรลดการเลื่อนเวลาของนาฬิกาเสียงเมื่อเทียบกับ CPU
CLOCK_MONOTONIC
เมื่อทั้ง 2 อย่างทำงานอยู่ - ควรลดเวลาในการตอบสนองของเสียงผ่านทรานสดิวเซอร์ในอุปกรณ์
- ควรลดเวลาในการตอบสนองของเสียงผ่านเสียงดิจิทัล USB
- ควรบันทึกการวัดเวลาในการตอบสนองของเสียงในเส้นทางทั้งหมด
- ควรลดการกระตุกของเวลาในการป้อนข้อมูล Callback เมื่อบัฟเฟอร์เสียงเล่นจนจบ เนื่องจากเวลานี้ส่งผลต่อเปอร์เซ็นต์แบนด์วิดท์ของ CPU ทั้งหมดที่ Callback ใช้งานได้
- ควรไม่มีข้อบกพร่องของเสียงเมื่อใช้งานตามปกติโดยมีเวลาในการตอบสนองตามที่รายงาน
- ควรให้เวลาในการตอบสนองระหว่างแชแนลเป็น 0
- ควรลดเวลาในการตอบสนองเฉลี่ยของ MIDI ในการขนส่งทั้งหมด
- ควรลดความแปรปรวนของเวลาในการตอบสนองของ MIDI เมื่อโหลด (การกระตุก) บนทรานสปอร์ตทั้งหมด
- ควรระบุการประทับเวลา MIDI ที่ถูกต้องในการขนส่งทั้งหมด
- ควรลดสัญญาณรบกวนทางเสียงจากทรานสดิวเซอร์ในอุปกรณ์ รวมถึงระยะเวลาทันทีหลังจากการเริ่มต้นระบบเย็น
- ควรระบุความแตกต่างของนาฬิกาเสียงเป็น 0 ระหว่างฝั่งอินพุตและเอาต์พุตของปลายทางที่เกี่ยวข้อง เมื่อทั้ง 2 ฝั่งทำงานอยู่ ตัวอย่างอุปกรณ์ปลายทางที่เกี่ยวข้อง ได้แก่ ไมโครโฟนและลำโพงในอุปกรณ์ หรืออินพุตและเอาต์พุตของช่องเสียบเสียง
- ควรจัดการการเรียกกลับเมื่อบัฟเฟอร์เสียงเสร็จสมบูรณ์สำหรับฝั่งอินพุตและเอาต์พุตของปลายทางที่เกี่ยวข้องในเธรดเดียวกันเมื่อทั้ง 2 ฝั่งทำงานอยู่ และเข้าสู่การเรียกกลับเอาต์พุตทันทีหลังจากการกลับมาจากการเรียกกลับอินพุต หรือหากจัดการกับคอลแบ็กในเธรดเดียวกันไม่ได้ ให้ป้อนคอลแบ็กเอาต์พุตหลังจากป้อนคอลแบ็กอินพุตไม่นานเพื่ออนุญาตให้แอปพลิเคชันมีการกำหนดเวลาของฝั่งอินพุตและเอาต์พุตที่สอดคล้องกัน
- ควรลดความแตกต่างของเฟสระหว่างบัฟเฟอร์เสียง HAL สำหรับอินพุตและเอาต์พุตของปลายทางที่เกี่ยวข้อง
- ควรลดเวลาในการตอบสนองต่อการสัมผัส
- ควรลดความแปรปรวนของเวลาในการตอบสนองต่อการสัมผัสภายใต้ภาระ (การกระตุก)
- ควรมีค่าเวลาในการตอบสนองจากอินพุตการสัมผัสไปยังเอาต์พุตเสียงน้อยกว่าหรือเท่ากับ 40 มิลลิวินาที
หากการติดตั้งใช้งานอุปกรณ์เป็นไปตามข้อกำหนดข้างต้นทั้งหมด อุปกรณ์จะมีคุณสมบัติดังนี้
- [C-SR-4] ขอแนะนําอย่างยิ่งให้รายงานการรองรับฟีเจอร์
android.hardware.audio.pro
ผ่านคลาสandroid.content.pm.PackageManager
หากการติดตั้งใช้งานอุปกรณ์มีช่องเสียบเสียง 3.5 มม. แบบ 4 สาย อุปกรณ์จะต้องมีลักษณะดังนี้
- [C-2-1] ต้องมีเวลาในการตอบสนองไป-กลับของเสียงแบบต่อเนื่องโดยเฉลี่ยตามที่ระบุไว้ในส่วนที่ 5.6 เวลาในการตอบสนองของเสียงไม่เกิน 20 มิลลิวินาทีจากการวัด 5 ครั้งขึ้นไป โดยมีค่าความเบี่ยงเบนสัมบูรณ์เฉลี่ยน้อยกว่า 5 มิลลิวินาทีในเส้นทางของช่องเสียบเสียง
- [C-SR-5] ขอแนะนำอย่างยิ่งให้ปฏิบัติตามส่วนข้อกำหนดเฉพาะของอุปกรณ์เคลื่อนที่ (แจ็ค) ของข้อกำหนดเฉพาะของหูฟังแบบมีสาย (v1.1)
หากการติดตั้งใช้งานอุปกรณ์ไม่มีช่องเสียบเสียง 3.5 มม. แบบ 4 สาย และมีพอร์ต USB ที่รองรับโหมดโฮสต์ USB อุปกรณ์ดังกล่าวต้องมีคุณสมบัติดังนี้
- [C-3-1] ต้องติดตั้งใช้งานคลาสเสียง USB
- [C-3-2] ต้องมีเวลาในการตอบสนองของเสียงแบบไปกลับต่อเนื่องโดยเฉลี่ยไม่เกิน 25 มิลลิวินาทีจากการวัด 5 ครั้งขึ้นไป โดยมีค่าความเบี่ยงเบนสัมบูรณ์เฉลี่ยน้อยกว่า 5 มิลลิวินาทีผ่านพอร์ตโหมดโฮสต์ USB โดยใช้คลาสเสียง USB (สามารถวัดโดยใช้อะแดปเตอร์ USB-3.5 มม. และดองเกิล Audio Loopback หรือใช้อินเทอร์เฟซเสียง USB ที่มีสายแพตช์เชื่อมต่ออินพุตกับเอาต์พุต)
- [C-SR-6] ขอแนะนำอย่างยิ่งให้รองรับ I/O พร้อมกันสูงสุด 8 แชนแนลในแต่ละทิศทาง, อัตราตัวอย่าง 96 kHz และความละเอียด 24 บิตหรือ 32 บิต เมื่อใช้กับอุปกรณ์ต่อพ่วงเสียง USB ที่รองรับข้อกำหนดเหล่านี้ด้วย
- [C-SR-7] ขอแนะนำอย่างยิ่งให้ปฏิบัติตามข้อกำหนดกลุ่มนี้โดยใช้ API เสียงแบบเนทีฟของ AAudio ในเส้นทาง MMAP
หากการติดตั้งใช้งานอุปกรณ์มีพอร์ต HDMI อุปกรณ์จะมีลักษณะดังนี้
- ควรรองรับเอาต์พุตแบบสเตอริโอและ 8 แชนแนลที่ความลึก 20 หรือ 24 บิตและ 192 kHz โดยไม่มีการสูญเสียความลึกของบิตหรือการสุ่มตัวอย่างอีกครั้งในการกำหนดค่าอย่างน้อย 1 รายการ
5.11. จับภาพสำหรับ "ไม่ได้ประมวลผล"
Android รองรับการบันทึกเสียงที่ไม่ได้ผ่านกระบวนการผ่านแหล่งที่มาของเสียง android.media.MediaRecorder.AudioSource.UNPROCESSED
ใน
OpenSL ES คุณจะเข้าถึงการตั้งค่าล่วงหน้าการบันทึกได้โดยใช้ SL_ANDROID_RECORDING_PRESET_UNPROCESSED
หากการติดตั้งใช้งานอุปกรณ์มีจุดประสงค์เพื่อรองรับแหล่งที่มาของเสียงที่ยังไม่ได้ประมวลผลและทำให้พร้อมใช้งานสำหรับแอปของบุคคลที่สาม อุปกรณ์จะต้องมีคุณสมบัติดังนี้
[C-1-1] ต้องรายงานการรองรับผ่าน
android.media.AudioManager
พร็อพเพอร์ตี้ PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED[C-1-2] ต้องมีแอมพลิจูดเทียบกับลักษณะความถี่ที่ราบเรียบโดยประมาณในช่วงความถี่กลาง กล่าวคือ ±10 dB จาก 100 Hz ถึง 7000 Hz สำหรับไมโครโฟนแต่ละตัวที่ใช้บันทึกแหล่งที่มาของเสียงที่ไม่ได้ประมวลผล
[C-1-3] ต้องมีระดับแอมพลิจูดในช่วงความถี่ต่ำ โดยเฉพาะอย่างยิ่งจาก ±20 dB จาก 5 z ถึง 100 Hz เมื่อเทียบกับช่วงความถี่กลางสำหรับไมโครโฟนแต่ละตัวที่ใช้บันทึกแหล่งที่มาของเสียงที่ยังไม่ได้ประมวลผล
[C-1-4] ต้องมีระดับแอมพลิจูดในช่วงความถี่สูง โดยเฉพาะอย่างยิ่งจาก ±30 dB จาก 7000 Hz ถึง 22 KHz เมื่อเทียบกับช่วงความถี่กลางสำหรับไมโครโฟนแต่ละตัวที่ใช้บันทึกแหล่งที่มาของเสียงที่ยังไม่ได้ประมวลผล
[C-1-5] ต้องตั้งค่าความไวอินพุตเสียงเพื่อให้แหล่งที่มาของเสียงไซน์ 1,000 Hz ที่เล่นที่ระดับความดันเสียง (SPL) 94 dB ให้ค่าตอบสนอง RMS 520 สำหรับตัวอย่าง 16 บิต (หรือ -36 dB Full Scale สำหรับตัวอย่างแบบทศนิยม/ความแม่นยำแบบ Double) สำหรับไมโครโฟนแต่ละตัวที่ใช้บันทึกแหล่งที่มาของเสียงที่ไม่ได้ประมวลผล
[C-1-6] ต้องมีอัตราส่วนสัญญาณต่อสัญญาณรบกวน (SNR) ที่ 60 dB ขึ้นไปสำหรับไมโครโฟนทุกตัวที่ใช้บันทึกแหล่งที่มาของเสียงที่ไม่ได้ประมวลผล (ในขณะที่ SNR จะวัดเป็นความแตกต่างระหว่าง 94 dB SPL กับ SPL ที่เทียบเท่าของสัญญาณรบกวนจากตัวอุปกรณ์เอง โดยปรับตามการถ่วงน้ำหนัก A)
[C-1-7] ต้องมีความผิดเพี้ยนตามฮาร์โมนิก (THD) น้อยกว่า 1% สำหรับ 1 kHz ที่ระดับอินพุต SPL 90 dB ที่ไมโครโฟนแต่ละตัวที่ใช้บันทึกแหล่งที่มาของเสียงที่ไม่ได้ประมวลผล
[C-1-8] ต้องไม่มีระบบประมวลผลสัญญาณอื่นๆ (เช่น การควบคุมระดับสัญญาณอัตโนมัติ ตัวกรอง High Pass หรือการตัดเสียงสะท้อน) ในเส้นทาง ยกเว้นตัวคูณระดับเพื่อปรับระดับให้อยู่ในช่วงที่ต้องการให้ได้ กล่าวคือ
- [C-1-9] หากมีระบบประมวลผลสัญญาณในสถาปัตยกรรมไม่ว่าด้วยเหตุผลใดก็ตาม จะต้องปิดใช้ระบบดังกล่าวและเพิ่มเวลาในการตอบสนองเป็น 0 หรือเพิ่มเวลาในการตอบสนองเพิ่มเติมในเส้นทางสัญญาณ
- [C-1-10] ตัวคูณระดับแม้จะอยู่ในเส้นทางได้ แต่ต้องไม่ทำให้เกิดความล่าช้าหรือเวลาในการตอบสนองในเส้นทางสัญญาณ
การวัด SPL ทั้งหมดจะดำเนินการข้างไมโครโฟนทดสอบโดยตรง สำหรับการกำหนดค่าไมโครโฟนหลายตัว ข้อกำหนดเหล่านี้จะมีผลกับไมโครโฟนแต่ละตัว
หากการติดตั้งใช้งานอุปกรณ์ประกาศ android.hardware.microphone
แต่ไม่รองรับแหล่งที่มาของเสียงที่ยังไม่ได้ประมวลผล อุปกรณ์จะมีลักษณะดังนี้
- [C-2-1] ต้องแสดงผล
null
สำหรับเมธอดAudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED)
API เพื่อบ่งชี้ว่าไม่รองรับอย่างถูกต้อง - [C-SR-1] เรายังคงขอแนะนำอย่างยิ่งให้ปฏิบัติตามข้อกำหนดมากที่สุดสำหรับเส้นทางสัญญาณของแหล่งที่มาของการบันทึกที่ยังไม่ได้ประมวลผล
6. ความเข้ากันได้ของเครื่องมือและตัวเลือกสำหรับนักพัฒนาแอป
6.1 เครื่องมือสำหรับนักพัฒนาซอฟต์แวร์
การติดตั้งใช้งานอุปกรณ์
- [C-0-1] ต้องรองรับเครื่องมือสําหรับนักพัฒนาแอป Android ที่ระบุไว้ใน Android SDK
-
- [C-0-2] ต้องรองรับ adb ตามที่ระบุไว้ใน Android SDK และคำสั่งเชลล์ที่ระบุไว้ใน AOSP ซึ่งนักพัฒนาแอปสามารถใช้ได้ ซึ่งรวมถึง
dumpsys
cmd stats
- [C-0-11] ต้องรองรับคำสั่งเชลล์
cmd testharness
การอัปเกรดการใช้งานอุปกรณ์จาก Android เวอร์ชันเก่าที่ไม่มีบล็อกข้อมูลที่ถาวรอาจได้รับการยกเว้นจาก C-0-11 - [C-0-3] ต้องไม่เปลี่ยนแปลงรูปแบบหรือเนื้อหาของเหตุการณ์ของระบบอุปกรณ์ (batterystats , diskstats, fingerprint, graphicsstats, netstats, notification, procstats) ที่บันทึกผ่านคำสั่ง dumpsys
- [C-0-10] ต้องบันทึกโดยไม่ละเว้น และทำให้เหตุการณ์ต่อไปนี้เข้าถึงได้และพร้อมใช้งานสำหรับ
cmd stats
คำสั่งเชลล์และStatsManager
คลาส System API- ActivityForegroundStateChanged
- AnomalyDetected
- AppBreadcrumbReported
- AppCrashOccurred
- AppStartOccurred
- BatteryLevelChanged
- BatterySaverModeStateChanged
- BleScanResultReceived
- BleScanStateChanged
- ChargingStateChanged
- DeviceIdleModeStateChanged
- ForegroundServiceStateChanged
- GpsScanStateChanged
- JobStateChanged
- PluggedStateChanged
- ScheduledJobStateChanged
- ScreenStateChanged
- SyncStateChanged
- SystemElapsedRealtime
- UidProcessStateChanged
- WakelockStateChanged
- WakeupAlarmOccurred
- WifiLockStateChanged
- WifiMulticastLockStateChanged
- WifiScanStateChanged
- [C-0-4] ต้องมี Daemon ของ adb ฝั่งอุปกรณ์ที่ไม่ทำงานโดยค่าเริ่มต้น และต้องมีกลไกที่ผู้ใช้เข้าถึงได้เพื่อเปิด Android Debug Bridge
- [C-0-5] MUST support secure adb. Android รองรับ adb ที่ปลอดภัย adb ที่ปลอดภัยจะเปิดใช้ adb ในโฮสต์ที่รู้จักซึ่งผ่านการตรวจสอบสิทธิ์
- [C-0-6] ต้องระบุกลไกที่อนุญาตให้เชื่อมต่อ adb จากเครื่องโฮสต์ ดังนี้
หากการติดตั้งใช้งานอุปกรณ์ที่ไม่มีพอร์ต USB รองรับโหมดอุปกรณ์ต่อพ่วง อุปกรณ์จะมีลักษณะดังนี้
- [C-3-1] ต้องใช้ adb ผ่านเครือข่าย LAN (เช่น อีเทอร์เน็ตหรือ Wi-Fi)
- [C-3-2] ต้องมีไดรเวอร์สำหรับ Windows 7, 8 และ 10 ซึ่งช่วยให้นักพัฒนาแอปเชื่อมต่อกับอุปกรณ์โดยใช้โปรโตคอล ADB ได้
หากการติดตั้งใช้งานอุปกรณ์รองรับการเชื่อมต่อ adb กับเครื่องโฮสต์ผ่าน Wi-Fi อุปกรณ์จะดำเนินการต่อไปนี้
- [C-4-1] ต้องมีเมธอด
AdbManager#isAdbWifiSupported()
ที่แสดงผลtrue
หากการติดตั้งใช้งานอุปกรณ์รองรับการเชื่อมต่อ adb กับเครื่องโฮสต์ผ่าน Wi-Fi และมีกล้องอย่างน้อย 1 ตัว อุปกรณ์จะมีลักษณะดังนี้
- [C-5-1] ต้องมีเมธอด
AdbManager#isAdbWifiQrSupported()
returntrue
- [C-0-2] ต้องรองรับ adb ตามที่ระบุไว้ใน Android SDK และคำสั่งเชลล์ที่ระบุไว้ใน AOSP ซึ่งนักพัฒนาแอปสามารถใช้ได้ ซึ่งรวมถึง
Dalvik Debug Monitor Service (ddms)
- [C-0-7] ต้องรองรับฟีเจอร์ ddms ทั้งหมดตามที่ระบุไว้ใน Android SDK เนื่องจาก ddms ใช้ adb การสนับสนุน ddms จึงควรปิดอยู่โดยค่าเริ่มต้น แต่จะต้องรองรับเมื่อใดก็ตามที่ผู้ใช้เปิดใช้งาน Android Debug Bridge ตามที่ระบุไว้ข้างต้น
-
- [C-0-8] ต้องมีเฟรมเวิร์ก Monkey และทำให้แอปพลิเคชันใช้งานได้
-
- [C-0-9] ต้องรองรับเครื่องมือ systrace ตามที่ระบุไว้ใน Android SDK Systrace ต้องปิดอยู่โดยค่าเริ่มต้น และต้องมีข้อบังคับให้ผู้ใช้เข้าถึงได้เพื่อเปิด Systrace
-
- [C-SR-1] ขอแนะนำอย่างยิ่งให้แสดง
/system/bin/perfetto
ไบนารีต่อผู้ใช้เชลล์ ซึ่ง cmdline เป็นไปตามเอกสารประกอบของ Perfetto - [C-SR-2] เราขอแนะนำอย่างยิ่งให้ใช้ไฟล์ไบนารีของ Perfetto เป็นอินพุตสำหรับการกําหนดค่า protobuf ที่เป็นไปตามสคีมาที่ระบุไว้ในเอกสารประกอบของ Perfetto
- [C-SR-3] เราขอแนะนำอย่างยิ่งให้ใช้ไฟล์ไบนารีของ Perfetto เพื่อเขียนร่องรอย protobuf ที่เป็นเอาต์พุต ซึ่งเป็นไปตามสคีมาที่กำหนดไว้ในเอกสารประกอบของ Perfetto
- [C-SR-4] ขอแนะนําอย่างยิ่งให้ระบุแหล่งข้อมูลอย่างน้อยตามที่อธิบายไว้ในเอกสารประกอบของ Perfetto ผ่านไฟล์ไบนารีของ Perfetto
- [C-SR-1] ขอแนะนำอย่างยิ่งให้แสดง
-
- [C-0-10] ต้องเขียน
LMK_KILL_OCCURRED_FIELD_NUMBER
Atom ลงในบันทึก statsd เมื่อแอปถูกสิ้นสุดโดย Low Memory Killer
- [C-0-10] ต้องเขียน
โหมดโปรแกรมทดสอบอัตโนมัติ หากการติดตั้งใช้งานอุปกรณ์รองรับคําสั่งเชลล์
cmd testharness
และcmd testharness enable
อุปกรณ์จะทําสิ่งต่อไปนี้- [C-2-1] MUST return
true
forActivityManager.isRunningInUserTestHarness()
- [C-2-2] ต้องใช้งานโหมดโปรแกรมทดสอบอัตโนมัติตามที่อธิบายไว้ในเอกสารประกอบโหมดโปรแกรมทดสอบอัตโนมัติ
- [C-2-1] MUST return
หากการติดตั้งใช้งานอุปกรณ์รายงานการรองรับ Vulkan 1.0 ขึ้นไปผ่านฟีเจอร์ Flag ของ android.hardware.vulkan.version
อุปกรณ์เหล่านั้นจะมีลักษณะดังนี้
- [C-1-1] ต้องระบุทางเลือกให้นักพัฒนาแอปเปิด/ปิดใช้เลเยอร์การแก้ไขข้อบกพร่อง GPU
- [C-1-2] ต้องระบุเลเยอร์ในไลบรารีที่ได้จากเครื่องมือภายนอก (ไม่ใช่แพ็กเกจแพลตฟอร์มหรือแอปพลิเคชัน) ซึ่งพบในไดเรกทอรีฐานของแอปพลิเคชันที่แก้ไขข้อบกพร่องได้เพื่อรองรับเมธอด vkEnumerateInstanceLayerProperties() และ vkCreateInstance() เมื่อเปิดใช้เลเยอร์การแก้ไขข้อบกพร่องของ GPU
6.2 ตัวเลือกสำหรับนักพัฒนาแอป
Android รองรับให้นักพัฒนาแอปกำหนดการตั้งค่าที่เกี่ยวข้องกับการพัฒนาแอป
การติดตั้งใช้งานอุปกรณ์ต้องมอบประสบการณ์การใช้งานที่สอดคล้องกันสำหรับตัวเลือกของนักพัฒนาแอป โดยตัวเลือกดังกล่าวต้องมีลักษณะดังนี้
- [C-0-1] MUST honor the android.settings.APPLICATION_DEVELOPMENT_SETTINGS intent to show application development-related settings. การใช้งาน Android เวอร์ชันอัปสตรีมจะซ่อนเมนูตัวเลือกสำหรับนักพัฒนาแอปไว้โดยค่าเริ่มต้น และเปิดใช้ตัวเลือกสำหรับนักพัฒนาแอปหลังจากที่กดรายการเมนูการตั้งค่า > เกี่ยวกับอุปกรณ์ > หมายเลขบิลด์ 7 ครั้ง
- [C-0-2] ต้องซ่อนตัวเลือกสำหรับนักพัฒนาแอปโดยค่าเริ่มต้น
- [C-0-3] ต้องระบุกลไกที่ชัดเจนซึ่งไม่แสดง favoritism ต่อแอปของบุคคลที่สามแอปหนึ่งเมื่อเทียบกับแอปอื่นเพื่อเปิดใช้ตัวเลือกสำหรับนักพัฒนาแอป ต้องแสดงเอกสารหรือเว็บไซต์ที่เข้าถึงได้แบบสาธารณะซึ่งอธิบายวิธีเปิดใช้ตัวเลือกสำหรับนักพัฒนาแอป เอกสารหรือเว็บไซต์นี้ต้องลิงก์ได้จากเอกสาร Android SDK
- ควรมีการแจ้งเตือนด้วยภาพอย่างต่อเนื่องแก่ผู้ใช้เมื่อเปิดใช้ตัวเลือกสำหรับนักพัฒนาแอปและมีความกังวลเกี่ยวกับความปลอดภัยของผู้ใช้
- อาจจำกัดการเข้าถึงเมนูตัวเลือกสำหรับนักพัฒนาแอปชั่วคราว โดยซ่อนหรือปิดใช้เมนูเพื่อไม่ให้ผู้ใช้เสียสมาธิในสถานการณ์ที่ผู้ใช้อาจไม่ปลอดภัย
7. ความเข้ากันได้ของฮาร์ดแวร์
หากอุปกรณ์มีส่วนประกอบฮาร์ดแวร์บางอย่างที่มี API ที่เกี่ยวข้องสําหรับนักพัฒนาแอปบุคคลที่สาม ให้ทำดังนี้
- [C-0-1] การติดตั้งใช้งานอุปกรณ์ต้องใช้ API ดังกล่าวตามที่อธิบายไว้ในเอกสารประกอบ Android SDK
หาก API ใน SDK โต้ตอบกับคอมโพเนนต์ฮาร์ดแวร์ที่ระบุว่าไม่บังคับ และการใช้งานอุปกรณ์ไม่มีคอมโพเนนต์ดังกล่าว ให้ทำดังนี้
- [C-0-2] คุณต้องยังแสดงคำจำกัดความของคลาสที่สมบูรณ์ (ตามที่ SDK ระบุไว้) สำหรับคอมโพเนนต์ API
- [C-0-3] ลักษณะการทํางานของ API ต้องติดตั้งใช้งานแบบ No-Ops ในลักษณะที่เหมาะสม
- [C-0-4] เมธอด API ต้องแสดงผลค่า Null ในกรณีที่เอกสารประกอบ SDK อนุญาต
- [C-0-5] เมธอด API ต้องแสดงผลการใช้งานคลาสแบบไม่มีการดำเนินการในกรณีที่เอกสารประกอบของ SDK ไม่อนุญาตให้ใช้ค่า Null
- [C-0-6] เมธอด API ต้องไม่แสดงข้อยกเว้นที่ไม่ได้ระบุไว้ในเอกสารประกอบของ SDK
- [C-0-7] การติดตั้งใช้งานอุปกรณ์ต้องรายงานข้อมูลการกำหนดค่าฮาร์ดแวร์ที่ถูกต้องอย่างสม่ำเสมอผ่านเมธอด
getSystemAvailableFeatures()
และhasSystemFeature(String)
ในคลาส android.content.pm.PackageManager สำหรับลายนิ้วมือของบิลด์เดียวกัน
ตัวอย่างทั่วไปของสถานการณ์ที่มีการใช้ข้อกำหนดเหล่านี้คือ API โทรศัพท์: แม้ในอุปกรณ์ที่ไม่ใช่โทรศัพท์ ก็ต้องติดตั้งใช้งาน API เหล่านี้แบบไม่มีการดำเนินการใดๆ ที่สมเหตุสมผล
7.1. การแสดงผลและกราฟิก
Android มีเครื่องมือที่ปรับชิ้นงานแอปพลิเคชันและเลย์เอาต์ UI โดยอัตโนมัติให้เหมาะสมกับอุปกรณ์ เพื่อให้แอปพลิเคชันของบุคคลที่สามทำงานได้อย่างราบรื่นในการกำหนดค่าฮาร์ดแวร์ต่างๆ ในจอแสดงผลที่ใช้ได้กับ Android ซึ่งแอปพลิเคชันของบุคคลที่สามทั้งหมดที่ใช้ได้กับ Android สามารถทำงานได้ การติดตั้งใช้งานอุปกรณ์ต้องนำ API และลักษณะการทำงานเหล่านี้ไปใช้อย่างถูกต้องตามที่ระบุไว้ในส่วนนี้
หน่วยที่อ้างอิงโดยข้อกำหนดในส่วนนี้จะกำหนดไว้ดังนี้
- ขนาดเส้นทแยงมุมจริง ระยะห่างเป็นนิ้วระหว่างมุมตรงข้ามกัน 2 มุมของส่วนที่สว่างของจอแสดงผล
- จุดต่อนิ้ว (dpi) จํานวนพิกเซลที่ครอบคลุมโดยช่วงแนวนอนหรือแนวตั้ง 1 นิ้ว เมื่อระบุค่า dpi ทั้ง dpi แนวนอนและแนวตั้งต้องอยู่ในช่วง
- สัดส่วนภาพ อัตราส่วนของพิกเซลของขนาดที่ยาวกว่าต่อขนาดที่สั้นกว่าของหน้าจอ เช่น จอแสดงผลขนาด 480x854 พิกเซลจะเท่ากับ 854/480 = 1.779 หรือประมาณ "16:9"
- ความหนาแน่นของพิกเซลอิสระ (dp) หน่วยพิกเซลเสมือนที่ปรับให้เป็นมาตรฐานของหน้าจอ 160 dpi ซึ่งคำนวณโดยสูตร pixels = dps * (density/160)
7.1.1. การกำหนดค่าหน้าจอ
7.1.1.1. ขนาดและรูปร่างของหน้าจอ
เฟรมเวิร์ก UI ของ Android รองรับขนาดเลย์เอาต์หน้าจอเชิงตรรกะที่แตกต่างกันหลายขนาด และอนุญาตให้แอปพลิเคชันค้นหาขนาดเลย์เอาต์หน้าจอของการกำหนดค่าปัจจุบันผ่าน Configuration.screenLayout
ด้วย SCREENLAYOUT_SIZE_MASK
และ Configuration.smallestScreenWidthDp
การติดตั้งใช้งานอุปกรณ์
[C-0-1] ต้องรายงานขนาดเลย์เอาต์ที่ถูกต้องสำหรับ
Configuration.screenLayout
ตามที่ระบุไว้ในเอกสารประกอบของ Android SDK กล่าวโดยละเอียดคือ การติดตั้งใช้งานอุปกรณ์ต้องรายงานขนาดหน้าจอพิกเซลอิสระจากความหนาแน่น (dp) เชิงตรรกะที่ถูกต้องดังต่อไปนี้- อุปกรณ์ที่มีการตั้งค่า
Configuration.uiMode
เป็นค่าอื่นที่ไม่ใช่ UI_MODE_TYPE_WATCH และรายงานขนาดsmall
สำหรับConfiguration.screenLayout
ต้องมีขนาดอย่างน้อย 426 dp x 320 dp - อุปกรณ์ที่รายงานขนาด
normal
สำหรับConfiguration.screenLayout
ต้องมีขนาดอย่างน้อย 480 dp x 320 dp - อุปกรณ์ที่รายงานขนาด
large
สำหรับConfiguration.screenLayout
ต้องมีขนาดอย่างน้อย 640 dp x 480 dp - อุปกรณ์ที่รายงานขนาด
xlarge
สำหรับConfiguration.screenLayout
ต้องมีขนาดอย่างน้อย 960 dp x 720 dp
- อุปกรณ์ที่มีการตั้งค่า
[C-0-2] ต้องรองรับขนาดหน้าจอตามที่แอปพลิเคชันระบุไว้อย่างถูกต้องผ่านแอตทริบิวต์ <
supports-screens
> ใน AndroidManifest.xml ตามที่อธิบายไว้ในเอกสารประกอบของ Android SDKอาจมีจอแสดงผลที่ใช้งานร่วมกับ Android ได้โดยมีมุมโค้งมน
หากการติดตั้งใช้งานอุปกรณ์รองรับ UI_MODE_TYPE_NORMAL
และมีจอแสดงผลที่เข้ากันได้กับ Android ที่มีมุมมน อุปกรณ์จะมีลักษณะดังนี้
[C-1-1] ต้องปฏิบัติตามข้อกำหนดข้อใดข้อหนึ่งต่อไปนี้เป็นอย่างน้อย
- รัศมีของมุมมนน้อยกว่าหรือเท่ากับ 38 dp
- เมื่อวางกล่องขนาด 15 dp x 15 dp ที่มุมแต่ละมุมของการแสดงผลเชิงตรรกะ แต่ละกล่องจะปรากฏบนหน้าจออย่างน้อย 1 พิกเซล
ควรมีสิ่งต่างๆ ที่ผู้ใช้สามารถโต้ตอบด้วยเพื่อเปลี่ยนไปใช้โหมดการแสดงผลที่มีมุมสี่เหลี่ยมผืนผ้า
หากการติดตั้งใช้งานอุปกรณ์มีจอแสดงผลที่เข้ากันได้กับ Android ซึ่งพับได้ หรือมีบานพับแบบพับระหว่างแผงจอแสดงผลหลายแผง และทำให้จอแสดงผลดังกล่าวพร้อมใช้งานเพื่อแสดงผลแอปของบุคคลที่สาม อุปกรณ์จะต้องมีคุณสมบัติดังนี้
- [C-2-1] ต้องติดตั้งใช้งาน extensions API เวอร์ชันล่าสุดที่มีให้บริการหรือ sidecar API เวอร์ชันที่เสถียรเพื่อให้ไลบรารี Window Manager Jetpack ใช้งานได้
หากการติดตั้งใช้งานอุปกรณ์มีจอแสดงผลที่เข้ากันได้กับ Android ซึ่งพับได้ หรือมีส่วนบานพับระหว่างแผงจอแสดงผลหลายแผง และหากบานพับหรือรอยพับตัดผ่านหน้าต่างแอปพลิเคชันแบบเต็มหน้าจอ อุปกรณ์จะต้องมีลักษณะดังนี้
- [C-3-1] ต้องรายงานตําแหน่ง ขอบเขต และสถานะของการพับหรือบานพับผ่านส่วนขยายหรือ Sidecar API ไปยังแอปพลิเคชัน
ดูรายละเอียดเกี่ยวกับการใช้ Sidecar หรือ Extension API อย่างถูกต้องได้จากเอกสารประกอบสาธารณะของ Window Manager Jetpack
7.1.1.2. สัดส่วนภาพหน้าจอ
แม้ว่าจะไม่มีข้อจำกัดเกี่ยวกับสัดส่วนภาพของจอแสดงผลจริงสำหรับจอแสดงผลที่เข้ากันได้กับ Android แต่สัดส่วนภาพของจอแสดงผลเชิงตรรกะซึ่งแสดงผลแอปของบุคคลที่สาม ซึ่งสามารถอนุมานได้จากค่าความสูงและความกว้างที่รายงานผ่าน view.Display
API และ Configuration API จะต้องเป็นไปตามข้อกำหนดต่อไปนี้
[C-0-1] การติดตั้งใช้งานอุปกรณ์ที่มีการตั้งค่า
Configuration.uiMode
เป็นUI_MODE_TYPE_NORMAL
ต้องมีค่าสัดส่วนภาพน้อยกว่าหรือเท่ากับ 1.86 (ประมาณ 16:9) เว้นแต่แอปจะเป็นไปตามเงื่อนไขข้อใดข้อหนึ่งต่อไปนี้- แอปได้ประกาศว่ารองรับสัดส่วนภาพหน้าจอที่ใหญ่ขึ้นผ่านค่าข้อมูลเมตา
android.max_aspect
- แอปประกาศว่าปรับขนาดได้ผ่านแอตทริบิวต์ android:resizeableActivity
- แอปกำหนดเป้าหมายเป็น API ระดับ 24 ขึ้นไปและไม่ได้ประกาศ
android:maxAspectRatio
ที่จำกัดสัดส่วนภาพที่อนุญาต
- แอปได้ประกาศว่ารองรับสัดส่วนภาพหน้าจอที่ใหญ่ขึ้นผ่านค่าข้อมูลเมตา
[C-0-3] การติดตั้งใช้งานอุปกรณ์ที่มีการตั้งค่า
Configuration.uiMode
เป็นUI_MODE_TYPE_WATCH
จะต้องมีการตั้งค่าสัดส่วนภาพเป็น 1.0 (1:1)
7.1.1.3. ความหนาแน่นของหน้าจอ
เฟรมเวิร์ก UI ของ Android จะกำหนดชุดความหนาแน่นเชิงตรรกะมาตรฐานเพื่อช่วยนักพัฒนาแอปกำหนดเป้าหมายทรัพยากรแอป
[C-0-1] โดยค่าเริ่มต้น การติดตั้งใช้งานอุปกรณ์ต้องรายงานความหนาแน่นเฟรมเวิร์ก Android เพียงค่าเดียวที่แสดงใน
DisplayMetrics
ผ่านDENSITY_DEVICE_STABLE
API และค่านี้ต้องไม่เปลี่ยนแปลงไม่ว่าเมื่อใดก็ตาม อย่างไรก็ตาม อุปกรณ์อาจรายงานความหนาแน่นที่ต่างกันตามการเปลี่ยนแปลงการกำหนดค่าการแสดงผลที่ผู้ใช้ทำ (เช่น ขนาดการแสดงผล) ซึ่งตั้งค่าไว้หลังจากการบูตครั้งแรกการใช้งานอุปกรณ์ควรกำหนดความหนาแน่นของเฟรมเวิร์ก Android มาตรฐานที่ใกล้เคียงกับค่าความหนาแน่นจริงของหน้าจอมากที่สุด เว้นแต่ความหนาแน่นเชิงตรรกะดังกล่าวจะทำให้ขนาดหน้าจอที่รายงานต่ำกว่าค่าต่ำสุดที่รองรับ หากความหนาแน่นของเฟรมเวิร์ก Android มาตรฐานที่ใกล้เคียงกับค่าความหนาแน่นของอุปกรณ์มากที่สุดส่งผลให้ขนาดหน้าจอเล็กกว่าขนาดหน้าจอที่เล็กที่สุดที่เข้ากันได้ (ความกว้าง 320 dp) การใช้งานอุปกรณ์ควรรายงานความหนาแน่นของเฟรมเวิร์ก Android มาตรฐานที่ต่ำที่สุดถัดไป
หากมีการแสดงผลเพื่อเปลี่ยนขนาดการแสดงผลของอุปกรณ์ ให้ทำดังนี้
- [C-1-1] ขนาดการแสดงผลต้องไม่ปรับขนาดให้ใหญ่กว่าความหนาแน่นดั้งเดิม 1.5 เท่า หรือสร้างขนาดหน้าจอขั้นต่ำที่มีประสิทธิภาพเล็กกว่า 320dp (เทียบเท่ากับตัวระบุทรัพยากร sw320dp) แล้วแต่ว่าเงื่อนไขใดจะเกิดขึ้นก่อน
- [C-1-2] ขนาดการแสดงผลต้องไม่ปรับขนาดให้เล็กกว่า 0.85 เท่าของความละเอียดดั้งเดิม
- เราขอแนะนำให้ใช้การปรับขนาดตัวเลือกการแสดงโฆษณาเนทีฟต่อไปนี้ (โดยเป็นไปตามขีดจำกัดที่ระบุไว้ข้างต้น) เพื่อให้ใช้งานได้ดีและมีขนาดแบบอักษรที่สอดคล้องกัน (
- เล็ก: 0.85x
- ค่าเริ่มต้น: 1x (ขนาดการแสดงผลเนทีฟ)
- ใหญ่: 1.15 เท่า
- ใหญ่ขึ้น: 1.3 เท่า
- ใหญ่ที่สุด 1.45x
7.1.2. เมตริก Display
หากการติดตั้งใช้งานอุปกรณ์มีจอแสดงผลที่รองรับ Android หรือเอาต์พุตวิดีโอไปยังหน้าจอแสดงผลที่รองรับ Android อุปกรณ์ดังกล่าวจะต้องมีคุณสมบัติดังนี้
- [C-1-1] ต้องรายงานค่าที่ถูกต้องสำหรับเมตริก Display ทั้งหมดที่เข้ากันได้กับ Android ซึ่งกำหนดไว้ใน
android.util.DisplayMetrics
API
หากการติดตั้งใช้งานอุปกรณ์ไม่มีหน้าจอที่ฝังหรือเอาต์พุตวิดีโอ อุปกรณ์จะมีลักษณะดังนี้
- [C-2-1] ต้องรายงานค่าที่ถูกต้องของจอแสดงผลที่เข้ากันได้กับ Android ตามที่ระบุไว้ใน
android.util.DisplayMetrics
API สำหรับview.Display
เริ่มต้นที่จำลอง
7.1.3. การวางแนวหน้าจอ
การติดตั้งใช้งานอุปกรณ์
- [C-0-1] ต้องรายงานการวางแนวหน้าจอที่รองรับ (
android.hardware.screen.portrait
และ/หรือandroid.hardware.screen.landscape
) และต้องรายงานการวางแนวที่รองรับอย่างน้อย 1 รายการ เช่น อุปกรณ์ที่มีหน้าจอแนวนอนแบบคงที่ เช่น ทีวีหรือแล็ปท็อป ควรรายงานเฉพาะandroid.hardware.screen.landscape
- [C-0-2] ต้องรายงานค่าที่ถูกต้องสำหรับการวางแนวปัจจุบันของอุปกรณ์ทุกครั้งที่มีการค้นหาผ่าน
android.content.res.Configuration.orientation
,android.view.Display.getOrientation()
หรือ API อื่นๆ
หากการติดตั้งใช้งานอุปกรณ์รองรับการวางแนวหน้าจอทั้ง 2 แบบ อุปกรณ์จะมีลักษณะดังนี้
- [C-1-1] ต้องรองรับการวางแนวแบบไดนามิกตามแอปพลิเคชันเพื่อการวางแนวหน้าจอเป็นแนวตั้งหรือแนวนอน กล่าวคือ อุปกรณ์ต้องปฏิบัติตามคําขอของแอปพลิเคชันเกี่ยวกับการวางแนวหน้าจอที่เฉพาะเจาะจง
- [C-1-2] ต้องไม่เปลี่ยนขนาดหรือความหนาแน่นของหน้าจอที่รายงานเมื่อเปลี่ยนการวางแนว
- อาจเลือกการวางแนวเป็นแนวตั้งหรือแนวนอนเป็นค่าเริ่มต้น
7.1.4. การเร่งกราฟิก 2 มิติและ 3 มิติ
7.1.4.1 OpenGL ES
การติดตั้งใช้งานอุปกรณ์
- [C-0-1] ต้องระบุเวอร์ชัน OpenGL ES ที่รองรับ (1.1, 2.0, 3.0, 3.1, 3.2) อย่างถูกต้องผ่าน API ที่มีการจัดการ (เช่น ผ่านเมธอด
GLES10.getString()
) และ API เดิม - [C-0-2] ต้องรองรับ API ที่มีการจัดการและ API เดิมที่เกี่ยวข้องทั้งหมดสำหรับ OpenGL ES ทุกเวอร์ชันที่ระบุไว้ว่ารองรับ
หากการติดตั้งใช้งานอุปกรณ์มีเอาต์พุตหน้าจอหรือวิดีโอ อุปกรณ์จะต้องมีลักษณะดังนี้
- [C-1-1] ต้องรองรับทั้ง OpenGL ES 1.1 และ 2.0 ตามที่ระบุและอธิบายไว้ในเอกสารประกอบ Android SDK
- [C-SR-1] ขอแนะนำอย่างยิ่งให้รองรับ OpenGL ES 3.1
- ควรรองรับ OpenGL ES 3.2
การทดสอบ OpenGL ES dEQP จะแบ่งออกเป็นรายการทดสอบหลายรายการ โดยแต่ละรายการจะมีวันที่/หมายเลขเวอร์ชันที่เชื่อมโยงกัน ซึ่งอยู่ในซอร์สโค้ดของ Android ที่
external/deqp/android/cts/main/glesXX-master-YYYY-MM-DD.txt
อุปกรณ์ที่รองรับ OpenGL ES ที่ระดับที่รายงานด้วยตนเองบ่งบอกว่าอุปกรณ์สามารถผ่านข้อทดสอบ dEQP ในรายการทดสอบทั้งหมดตั้งแต่ระดับนี้และต่ำกว่า
หากการติดตั้งใช้งานอุปกรณ์รองรับ OpenGL ES เวอร์ชันใดเวอร์ชันหนึ่ง อุปกรณ์จะมีลักษณะดังนี้
- [C-2-1] ต้องรายงานผ่าน API ที่จัดการของ OpenGL ES และ API เดิมเกี่ยวกับส่วนขยาย OpenGL ES อื่นๆ ที่ใช้ และในทางกลับกัน ต้องไม่รายงานสตริงส่วนขยายที่ไม่รองรับ
- [C-2-2] ต้องรองรับส่วนขยาย
EGL_KHR_image
,EGL_KHR_image_base
,EGL_ANDROID_image_native_buffer
,EGL_ANDROID_get_native_client_buffer
,EGL_KHR_wait_sync
,EGL_KHR_get_all_proc_addresses
,EGL_ANDROID_presentation_time
,EGL_KHR_swap_buffers_with_damage
,EGL_ANDROID_recordable
และEGL_ANDROID_GLES_layers
- [C-2-3] ต้องรายงานเวอร์ชันสูงสุดของการทดสอบ dEQP ของ OpenGL ES ที่รองรับผ่าน Flag ฟีเจอร์
android.software.opengles.deqp.level
- [C-2-4] ต้องรองรับเวอร์ชัน 132383489 เป็นอย่างน้อย (ตั้งแต่วันที่ 1 มีนาคม 2020) ตามที่รายงานใน Flag ฟีเจอร์
android.software.opengles.deqp.level
- [C-2-5] ต้องผ่านการทดสอบ dEQP ของ OpenGL ES ทั้งหมดในรายการทดสอบระหว่างเวอร์ชัน 132383489 กับเวอร์ชันที่ระบุในฟีเจอร์ Flag
android.software.opengles.deqp.level
สำหรับ OpenGL ES แต่ละเวอร์ชันที่รองรับ - [C-SR-2] ขอแนะนำอย่างยิ่งให้รองรับส่วนขยาย
EGL_KHR_partial_update
และOES_EGL_image_external
- ควรรายงานอย่างถูกต้องผ่านเมธอด
getString()
เกี่ยวกับรูปแบบการบีบอัดพื้นผิวที่รองรับ ซึ่งโดยทั่วไปจะเจาะจงตามผู้ให้บริการ
หากการติดตั้งใช้งานอุปกรณ์ประกาศว่ารองรับ OpenGL ES 3.0, 3.1 หรือ 3.2 อุปกรณ์จะต้องมีคุณสมบัติดังนี้
- [C-3-1] ต้องส่งออกสัญลักษณ์ฟังก์ชันที่สอดคล้องกันสำหรับเวอร์ชันเหล่านี้นอกเหนือจากสัญลักษณ์ฟังก์ชัน OpenGL ES 2.0 ในไลบรารี libGLESv2.so
- [C-SR-3] ขอแนะนําอย่างยิ่งให้รองรับส่วนขยาย
OES_EGL_image_external_essl3
หากการติดตั้งใช้งานอุปกรณ์รองรับ OpenGL ES 3.2 อุปกรณ์จะมีลักษณะดังนี้
- [C-4-1] ต้องรองรับ OpenGL ES Android Extension Pack โดยสมบูรณ์
หากการติดตั้งใช้งานอุปกรณ์รองรับ Android Extension Pack ของ OpenGL ES โดยสมบูรณ์ อุปกรณ์จะมีลักษณะดังนี้
- [C-5-1] ต้องระบุการรองรับผ่าน
android.hardware.opengles.aep
Flag ฟีเจอร์
หากการติดตั้งใช้งานอุปกรณ์รองรับEGL_KHR_mutable_render_buffer
ส่วนขยาย อุปกรณ์จะมีลักษณะดังนี้
- [C-6-1] ต้องรองรับส่วนขยาย
EGL_ANDROID_front_buffer_auto_refresh
ด้วย
7.1.4.2 Vulkan
Android รองรับ Vulkan ซึ่งเป็น API แบบข้ามแพลตฟอร์มที่มีค่าใช้จ่ายต่ำสำหรับกราฟิก 3 มิติที่มีประสิทธิภาพสูง
หากการติดตั้งใช้งานอุปกรณ์รองรับ OpenGL ES 3.1 อุปกรณ์จะมีลักษณะดังนี้
- [C-SR-1] ขอแนะนำอย่างยิ่งให้รองรับ Vulkan 1.1
หากการติดตั้งใช้งานอุปกรณ์มีเอาต์พุตหน้าจอหรือวิดีโอ อุปกรณ์จะต้องมีลักษณะดังนี้
- ควรรองรับ Vulkan 1.1
การทดสอบ dEQP ของ Vulkan จะแบ่งออกเป็นรายการทดสอบหลายรายการ โดยแต่ละรายการจะมีวันที่/เวอร์ชันที่เกี่ยวข้อง ซึ่งอยู่ในซอร์สโค้ดของ Android ที่
external/deqp/android/cts/main/vk-master-YYYY-MM-DD.txt
อุปกรณ์ที่รองรับ Vulkan ที่ระดับที่รายงานด้วยตนเองบ่งบอกว่าอุปกรณ์สามารถผ่านข้อทดสอบ dEQP ในรายการทดสอบทั้งหมดตั้งแต่ระดับนี้และต่ำกว่า
หากการติดตั้งใช้งานอุปกรณ์รองรับ Vulkan 1.0 ขึ้นไป อุปกรณ์จะมีลักษณะดังนี้
- [C-1-1] ต้องรายงานค่าจำนวนเต็มที่ถูกต้องด้วย Flag ฟีเจอร์
android.hardware.vulkan.level
และandroid.hardware.vulkan.version
- [C-1-2] ต้องระบุ
VkPhysicalDevice
อย่างน้อย 1 รายการสำหรับ Vulkan API เดิมvkEnumeratePhysicalDevices()
- [C-1-3] ต้องติดตั้งใช้งาน Vulkan 1.0 API อย่างเต็มรูปแบบสำหรับแต่ละรายการที่ระบุไว้
VkPhysicalDevice
- [C-1-4] MUST enumerate layers, contained in native libraries named as
libVkLayer*.so
in the application package’s native library directory, ผ่าน Vulkan Native APIvkEnumerateInstanceLayerProperties()
และ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] ต้องรายงานเวอร์ชันสูงสุดของการทดสอบ dEQP ของ Vulkan ที่รองรับผ่าน Flag ฟีเจอร์
android.software.vulkan.deqp.level
- [C-1-9] ต้องรองรับเวอร์ชัน
132317953
เป็นอย่างน้อย (ตั้งแต่วันที่ 1 มีนาคม 2019) ตามที่รายงานใน Flag ฟีเจอร์android.software.vulkan.deqp.level
- [C-1-10] ต้องผ่านการทดสอบ dEQP ของ Vulkan ทั้งหมดในรายการทดสอบระหว่างเวอร์ชัน
132317953
กับเวอร์ชันที่ระบุไว้ใน Flag ฟีเจอร์android.software.vulkan.deqp.level
- [C-1-11] ต้องไม่แสดงรายการการรองรับส่วนขยาย VK_KHR_video_queue, VK_KHR_video_decode_queue หรือ VK_KHR_video_encode_queue
- [C-SR-2] ขอแนะนำอย่างยิ่งให้รองรับส่วนขยาย 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
สำหรับ API เนทีฟของ VulkanvkEnumeratePhysicalDevices()
หากการติดตั้งใช้งานอุปกรณ์รองรับ 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:hardwareAccelerated หรือการเรียก API โดยตรง
การติดตั้งใช้งานอุปกรณ์
- [C-0-1] ต้องเปิดใช้การเร่งฮาร์ดแวร์โดยค่าเริ่มต้น และต้องปิดใช้การเร่งฮาร์ดแวร์หากนักพัฒนาแอปร้องขอโดยการตั้งค่า android:hardwareAccelerated="false" หรือปิดใช้การเร่งฮาร์ดแวร์โดยตรงผ่าน Android View API
- [C-0-2] ต้องแสดงลักษณะการทำงานที่สอดคล้องกับเอกสารประกอบของ Android SDK เกี่ยวกับการเร่งด้วยฮาร์ดแวร์
Android มีออบเจ็กต์ TextureView ที่ช่วยนักพัฒนาแอปผสานรวมพื้นผิว OpenGL ES ที่เร่งด้วยฮาร์ดแวร์โดยตรงเป็นเป้าหมายการแสดงผลในลําดับชั้น UI
การติดตั้งใช้งานอุปกรณ์
- [C-0-3] ต้องรองรับ TextureView API และต้องแสดงลักษณะการทำงานที่สอดคล้องกันกับการใช้งาน Android เวอร์ชันที่อัปเดต
7.1.4.5 จอแสดงผลแบบช่วงสีกว้าง
หากการติดตั้งใช้งานอุปกรณ์อ้างว่ารองรับจอแสดงผลแบบช่วงสีกว้างผ่าน Configuration.isScreenWideColorGamut()
อุปกรณ์ดังกล่าวจะมีลักษณะดังนี้
- [C-1-1] ต้องมีจอแสดงผลที่ปรับเทียบสี
- [C-1-2] ต้องมีจอแสดงผลที่ช่วงสีครอบคลุมช่วงสี sRGB ทั้งหมดในพื้นที่สี CIE 1931 xyY
- [C-1-3] ต้องมีจอแสดงผลที่ช่วงสีมีพื้นที่อย่างน้อย 90% ของ DCI-P3 ในเชิงพื้นที่ xyY ของ CIE 1931
- [C-1-4] ต้องรองรับ OpenGL ES 3.1 หรือ 3.2 และรายงานอย่างถูกต้อง
- [C-1-5] ต้องโฆษณาการรองรับส่วนขยาย
EGL_KHR_no_config_context
,EGL_EXT_pixel_format_float
,EGL_KHR_gl_colorspace
,EGL_EXT_gl_colorspace_scrgb
,EGL_EXT_gl_colorspace_scrgb_linear
,EGL_EXT_gl_colorspace_display_p3
,EGL_EXT_gl_colorspace_display_p3_linear
และEGL_EXT_gl_colorspace_display_p3_passthrough
- [C-SR-1] ขอแนะนำอย่างยิ่งให้รองรับ
GL_EXT_sRGB
ในทางกลับกัน หากการติดตั้งใช้งานอุปกรณ์ไม่รองรับจอแสดงผลแบบช่วงสีกว้าง อุปกรณ์จะมีลักษณะดังนี้
- [C-2-1] ควรครอบคลุม sRGB อย่างน้อย 100% ในพื้นที่สี xyY ของ CIE 1931 แม้ว่า gamut สีของหน้าจอจะไม่มีการระบุ
7.1.5. โหมดความเข้ากันได้ของแอปพลิเคชันเดิม
Android จะระบุ "โหมดความเข้ากันได้" ซึ่งเฟรมเวิร์กจะทํางานในโหมดขนาดหน้าจอ "ปกติ" (ความกว้าง 320dp) เพื่อประโยชน์ของแอปพลิเคชันเดิมที่ไม่ได้พัฒนาขึ้นสําหรับ Android เวอร์ชันเก่าซึ่งอยู่ก่อนยุคที่รองรับทุกขนาดหน้าจอ
7.1.6. เทคโนโลยีหน้าจอ
แพลตฟอร์ม Android มี API ที่ช่วยให้แอปพลิเคชันแสดงผลกราฟิกแบบริชมีเดียไปยังจอแสดงผลที่รองรับ Android ได้ อุปกรณ์ต้องรองรับ API ทั้งหมดเหล่านี้ตามที่ Android SDK กำหนด เว้นแต่จะได้รับอนุญาตอย่างเจาะจงในเอกสารนี้
จอแสดงผลทั้งหมดที่เข้ากันได้กับ Android ของการติดตั้งใช้งานอุปกรณ์
- [C-0-1] ต้องแสดงผลกราฟิกสี 16 บิตได้
- ควรรองรับจอแสดงผลที่แสดงกราฟิกสี 24 บิตได้
- [C-0-2] ต้องแสดงภาพเคลื่อนไหวได้
- [C-0-3] ต้องมีสัดส่วนพิกเซล (PAR) อยู่ระหว่าง 0.9 ถึง 1.15 กล่าวคือ อัตราส่วนพิกเซลต้องใกล้เคียงกับสี่เหลี่ยมจัตุรัส (1.0) โดยมีความคลาดเคลื่อน 10-15%
7.1.7. จอแสดงผลสำรอง
Android รองรับจอแสดงผลรองที่เข้ากันได้กับ Android เพื่อเปิดใช้ความสามารถในการแชร์สื่อและ API ของนักพัฒนาแอปสำหรับการเข้าถึงจอแสดงผลภายนอก
หากการติดตั้งใช้งานอุปกรณ์รองรับจอแสดงผลภายนอกผ่านการเชื่อมต่อแบบใช้สาย ไร้สาย หรือการเชื่อมต่อจอแสดงผลเพิ่มเติมแบบฝัง อุปกรณ์จะต้องมีคุณสมบัติดังนี้
- [C-1-1] ต้องใช้บริการระบบและ API ของ
DisplayManager
ตามที่อธิบายไว้ในเอกสารประกอบของ Android SDK
7.2. อุปกรณ์อินพุต
การติดตั้งใช้งานอุปกรณ์
- [C-0-1] ต้องมีกลไกอินพุต เช่น หน้าจอสัมผัสหรือการไปยังส่วนต่างๆ โดยไม่สัมผัส เพื่อไปยังส่วนต่างๆ ขององค์ประกอบ UI
7.2.1. แป้นพิมพ์
หากการติดตั้งใช้งานอุปกรณ์รองรับแอปพลิเคชันตัวแก้ไขวิธีการป้อนข้อมูล (IME) ของบุคคลที่สาม อุปกรณ์จะมีลักษณะดังนี้
- [C-1-1] ต้องประกาศ 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 เวอร์ชัน upstream มีกลไกการเลือกที่เหมาะสมสำหรับใช้กับอุปกรณ์ที่ไม่มีอินพุตการไปยังส่วนต่างๆ ที่ไม่ต้องใช้การสัมผัส
7.2.3. ปุ่มนำทาง
ฟังก์ชันหน้าแรก ล่าสุด และย้อนกลับ ซึ่งมักจะมีให้ใช้งานผ่านการโต้ตอบกับปุ่มบนตัวเครื่องโดยเฉพาะหรือส่วนต่างๆ ของหน้าจอสัมผัส มีความสำคัญต่อรูปแบบการนำทางของ Android และการใช้งานอุปกรณ์
- [C-0-1] ต้องให้ทางเลือกแก่ผู้ใช้ในการเปิดแอปพลิเคชันที่ติดตั้งไว้ซึ่งมีกิจกรรมที่มี
<intent-filter>
ตั้งค่าเป็นACTION=MAIN
และCATEGORY=LAUNCHER
หรือCATEGORY=LEANBACK_LAUNCHER
สําหรับการติดตั้งใช้งานในอุปกรณ์ทีวี ฟังก์ชันหน้าแรกควรเป็นกลไกสําหรับความสามารถของผู้ใช้นี้ - ควรมีปุ่มสำหรับฟังก์ชัน "ล่าสุด" และ "ย้อนกลับ"
หากมีฟังก์ชันหน้าแรก ล่าสุด หรือย้อนกลับ ฟังก์ชันเหล่านี้จะทําดังนี้
- [C-1-1] ต้องเข้าถึงได้ด้วยการดำเนินการเดียว (เช่น แตะ ดับเบิลคลิก หรือท่าทางสัมผัส) เมื่อเข้าถึงการดำเนินการใดก็ได้
- [C-1-2] ต้องระบุการดำเนินการเดียวที่ชัดเจนซึ่งจะทริกเกอร์แต่ละฟังก์ชัน ตัวอย่างของการแสดงข้อมูลดังกล่าว ได้แก่ การมีไอคอนที่มองเห็นได้บนปุ่ม การแสดงไอคอนซอฟต์แวร์ในส่วนแถบนำทางของหน้าจอ หรือแนะนำผู้ใช้ผ่านขั้นตอนการสาธิตแบบทีละขั้นตอนพร้อมคำแนะนำระหว่างการตั้งค่าแบบพร้อมใช้งานทันที
การติดตั้งใช้งานอุปกรณ์
- [C-SR-1] ขอแนะนำอย่างยิ่งว่าอย่าระบุกลไกการป้อนข้อมูลสำหรับฟังก์ชันเมนูเนื่องจากมีการเลิกใช้งานแล้วเพื่อสนับสนุนแถบการดำเนินการตั้งแต่ Android 4.0
หากการติดตั้งใช้งานอุปกรณ์มีฟังก์ชันเมนู อุปกรณ์จะมีลักษณะดังนี้
- [C-2-1] ต้องแสดงปุ่มรายการเพิ่มเติมของการดำเนินการทุกครั้งที่ป๊อปอัปเมนูรายการเพิ่มเติมของการดำเนินการไม่ว่างเปล่าและแถบการดำเนินการแสดงอยู่
- [C-2-2] ต้องไม่แก้ไขตําแหน่งของป๊อปอัปรายการเพิ่มเติมของการดำเนินการที่แสดงโดยการเลือกปุ่มรายการเพิ่มเติมในแถบการดำเนินการ แต่อาจแสดงผลป๊อปอัปรายการเพิ่มเติมของการดำเนินการในตําแหน่งที่แก้ไขแล้วบนหน้าจอเมื่อแสดงโดยการเลือกฟังก์ชันเมนู
หากการติดตั้งใช้งานอุปกรณ์ไม่มีฟังก์ชันเมนู อุปกรณ์จะดำเนินการต่อไปนี้เพื่อใช้งานร่วมกันได้
- [C-3-1] ต้องทำให้แอปพลิเคชันใช้งานฟังก์ชันเมนูได้เมื่อ
targetSdkVersion
น้อยกว่า 10 โดยใช้ปุ่มบนอุปกรณ์ แป้นบนซอฟต์แวร์ หรือท่าทางสัมผัส ฟังก์ชันเมนูนี้ควรเข้าถึงได้ เว้นแต่ว่าจะถูกซ่อนไว้พร้อมกับฟังก์ชันการไปยังส่วนต่างๆ อื่นๆ
หากการติดตั้งใช้งานอุปกรณ์มีฟังก์ชัน Assist อุปกรณ์จะดำเนินการต่อไปนี้
- [C-4-1] ต้องทำให้เข้าถึงฟังก์ชัน Assist ได้ด้วยการดําเนินการเพียงครั้งเดียว (เช่น แตะ ดับเบิลคลิก หรือท่าทางสัมผัส) เมื่อเข้าถึงแป้นการนําทางอื่นๆ ได้
- [C-SR-2] ขอแนะนำอย่างยิ่งให้ใช้การกดฟังก์ชัน HOME ค้างไว้เป็นการโต้ตอบที่กำหนด
หากการติดตั้งใช้งานอุปกรณ์ใช้ส่วนที่แตกต่างกันของหน้าจอเพื่อแสดงปุ่มการนําทาง ปุ่มดังกล่าวจะมีลักษณะดังนี้
- [C-5-1] ปุ่มการไปยังส่วนต่างๆ ของหน้าจอต้องใช้พื้นที่บนหน้าจอที่แยกต่างหาก ไม่ได้ใช้ได้กับแอปพลิเคชัน และต้องไม่บดบังหรือรบกวนส่วนบนหน้าจอที่ใช้งานได้กับแอปพลิเคชัน
- [C-5-2] ต้องจัดสรรพื้นที่ส่วนหนึ่งของจอแสดงผลให้กับแอปพลิเคชันที่เป็นไปตามข้อกำหนดที่ระบุไว้ในส่วนที่ 7.1.1
- [C-5-3] ต้องปฏิบัติตาม Flag ที่แอปตั้งค่าไว้ผ่านเมธอด
View.setSystemUiVisibility()
API เพื่อให้ส่วนที่แตกต่างกันนี้ของหน้าจอ (หรือที่เรียกว่าแถบนําทาง) ซ่อนอยู่อย่างถูกต้องตามที่ระบุไว้ใน SDK
หากฟังก์ชันการนําทางมีให้ใช้งานเป็นการกระทําบนหน้าจอโดยอิงตามท่าทางสัมผัส ให้ทําดังนี้
- [C-6-1]
WindowInsets#getMandatorySystemGestureInsets()
ต้องใช้เพื่อรายงานพื้นที่การจดจำท่าทางสัมผัสของ Home เท่านั้น - [C-6-2] ท่าทางสัมผัสที่เริ่มต้นภายในสี่เหลี่ยมผืนผ้าการยกเว้นตามที่แอปพลิเคชันที่ทำงานอยู่เบื้องหน้าระบุผ่าน
View#setSystemGestureExclusionRects()
แต่อยู่นอกWindowInsets#getMandatorySystemGestureInsets()
ต้องไม่ถูกขัดจังหวะสำหรับฟังก์ชันการไปยังส่วนต่างๆ ตราบใดที่สี่เหลี่ยมผืนผ้าการยกเว้นได้รับอนุญาตภายในขีดจำกัดการยกเว้นสูงสุดตามที่ระบุไว้ในเอกสารประกอบสำหรับView#setSystemGestureExclusionRects()
- [C-6-3] ต้องส่งเหตุการณ์
MotionEvent.ACTION_CANCEL
ไปยังแอปที่ทำงานอยู่เบื้องหน้าเมื่อเริ่มมีการสกัดกั้นการแตะเพื่อใช้ท่าทางสัมผัสของระบบ หากก่อนหน้านี้แอปที่ทำงานอยู่เบื้องหน้าได้รับเหตุการณ์MotionEvent.ACTION_DOWN
- [C-6-4] ต้องให้ผู้ใช้สามารถเปลี่ยนไปใช้การไปยังส่วนต่างๆ บนหน้าจอโดยอิงตามปุ่ม (เช่น ในการตั้งค่า)
- ควรมีฟังก์ชันหน้าแรกด้วยการปัดขึ้นจากขอบด้านล่างของการวางแนวปัจจุบันของหน้าจอ
- ควรมีฟังก์ชันรายการล่าสุดด้วยการปัดขึ้นแล้วกดค้างไว้ก่อนปล่อยจากบริเวณเดียวกับท่าทางสัมผัสสำหรับหน้าแรก
- ท่าทางสัมผัสที่เริ่มต้นภายใน
WindowInsets#getMandatorySystemGestureInsets()
seharusnya ไม่ได้รับผลกระทบจากสี่เหลี่ยมผืนผ้าการยกเว้นที่แอปพลิเคชันเบื้องหน้าระบุผ่านView#setSystemGestureExclusionRects()
หากมีฟังก์ชันการนำทางจากขอบด้านซ้ายและขวาของการวางแนวหน้าจอปัจจุบัน ให้ทำดังนี้
- [C-7-1] ฟังก์ชันการนําทางต้องเป็น "กลับ" และให้บริการด้วยการปัดจากทั้งขอบด้านซ้ายและขวาของการวางแนวปัจจุบันของหน้าจอ
- [C-7-2] หากมีแผงระบบที่ปัดได้ซึ่งกำหนดเองที่ขอบซ้ายหรือขวา แผงดังกล่าวต้องอยู่ใน 1/3 ด้านบนของหน้าจอพร้อมด้วยตัวบ่งชี้ที่ชัดเจนและแสดงอยู่ตลอดเวลาว่าการลากเข้าจะเป็นการเรียกแผงดังกล่าวขึ้นมา และไม่ใช่ปุ่มย้อนกลับ ผู้ใช้อาจกำหนดค่าแผงระบบให้อยู่ด้านล่าง 1/3 ของขอบด้านบนของหน้าจอ แต่แผงระบบต้องไม่ยาวเกิน 1/3 ของขอบ
- [C-7-3] เมื่อแอปที่ทำงานอยู่เบื้องหน้ามีการตั้งค่า Flag ใด Flag หนึ่งต่อไปนี้ View.SYSTEM_UI_FLAG_IMMERSIVE, View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT หรือ WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE การปัดจากขอบจะต้องทํางานตามที่ติดตั้งใช้งานใน AOSP ซึ่งมีเอกสารประกอบใน SDK
- [C-7-4] เมื่อแอปที่ทำงานอยู่เบื้องหน้ามีการตั้งค่า Flag ใด Flag หนึ่งต่อไปนี้ View.SYSTEM_UI_FLAG_IMMERSIVE, View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT หรือ WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE ระบบจะต้องซ่อนแผงระบบที่ปัดได้ที่กำหนดเองจนกว่าผู้ใช้จะแสดงหรือทำให้แถบระบบ (หรือที่เรียกว่าแถบนําทางและแถบสถานะ) สว่างขึ้นตามที่ติดตั้งใช้งานใน AOSP
7.2.4. การป้อนข้อมูลด้วยหน้าจอสัมผัส
Android รองรับระบบอินพุตด้วยเคอร์เซอร์ที่หลากหลาย เช่น หน้าจอสัมผัส แท็บเล็ตสัมผัส และอุปกรณ์อินพุตการสัมผัสจำลอง การใช้งานอุปกรณ์แบบหน้าจอสัมผัสจะเชื่อมโยงกับจอแสดงผลเพื่อให้ผู้ใช้รู้สึกว่าได้ควบคุมรายการบนหน้าจอโดยตรง เนื่องจากผู้ใช้สัมผัสหน้าจอโดยตรง ระบบจึงไม่จำเป็นต้องมีสิ่งอำนวยความสะดวกเพิ่มเติมเพื่อบ่งชี้วัตถุที่กำลังมีการจัดการ
การติดตั้งใช้งานอุปกรณ์
- ควรมีระบบการป้อนข้อมูลด้วยเคอร์เซอร์ประเภทใดประเภทหนึ่ง (แบบเมาส์หรือแบบสัมผัส)
- ควรรองรับเคอร์เซอร์ที่มีการติดตามอย่างอิสระโดยสมบูรณ์
หากการติดตั้งใช้งานอุปกรณ์มีหน้าจอสัมผัส (แบบสัมผัสเดียวหรือดีกว่า) ในจอแสดงผลหลักที่เข้ากันได้กับ Android อุปกรณ์จะต้องมีคุณสมบัติดังนี้
- [C-1-1] ต้องรายงาน
TOUCHSCREEN_FINGER
สำหรับช่องConfiguration.touchscreen
API - [C-1-2] ต้องรายงาน Flag ฟีเจอร์
android.hardware.touchscreen
และandroid.hardware.faketouch
หากการติดตั้งใช้งานอุปกรณ์มีหน้าจอสัมผัสที่สามารถติดตามการแตะมากกว่า 1 ครั้งบนจอแสดงผลหลักที่เข้ากันได้กับ Android อุปกรณ์จะมีลักษณะดังนี้
- [C-2-1] ต้องรายงาน Flag ฟีเจอร์ที่เหมาะสม
android.hardware.touchscreen.multitouch
,android.hardware.touchscreen.multitouch.distinct
,android.hardware.touchscreen.multitouch.jazzhand
ซึ่งสอดคล้องกับประเภทของหน้าจอสัมผัสที่เฉพาะเจาะจงในอุปกรณ์
หากการติดตั้งใช้งานอุปกรณ์ต้องใช้อุปกรณ์อินพุตภายนอก เช่น เมาส์หรือแทร็กบอล (ไม่ได้สัมผัสหน้าจอโดยตรง) สำหรับอินพุตในจอแสดงผลหลักที่เข้ากันได้กับ Android และเป็นไปตามข้อกำหนดการแตะจำลองในส่วนที่ 7.2.5 อุปกรณ์จะต้องมีลักษณะดังนี้
- [C-3-1] ต้องไม่รายงาน Flag ฟีเจอร์ที่ขึ้นต้นด้วย
android.hardware.touchscreen
- [C-3-2] ต้องรายงานเฉพาะ
android.hardware.faketouch
- [C-3-3] ต้องรายงาน
TOUCHSCREEN_NOTOUCH
สำหรับช่องConfiguration.touchscreen
API
7.2.5. การป้อนข้อมูลด้วยการสัมผัสจำลอง
อินเทอร์เฟซการแตะจำลองเป็นระบบการป้อนข้อมูลของผู้ใช้ที่ใกล้เคียงกับความสามารถของหน้าจอสัมผัสเพียงบางส่วน เช่น เมาส์หรือรีโมตคอนโทรลที่ควบคุมเคอร์เซอร์บนหน้าจอจะคล้ายกับการสัมผัส แต่ผู้ใช้ต้องชี้หรือโฟกัสก่อนแล้วจึงคลิก อุปกรณ์อินพุตจำนวนมาก เช่น เมาส์ แทร็กแพด เมาส์ไร้สายที่ใช้เซ็นเซอร์การหมุน ชี้เมาส์ที่ใช้เซ็นเซอร์การหมุน จอยสติ๊ก และแทร็กแพดแบบมัลติทัช รองรับการโต้ตอบแบบการแตะจำลอง Android มีค่าคงที่ของฟีเจอร์ android.hardware.faketouch ซึ่งสอดคล้องกับอุปกรณ์อินพุตแบบไม่สัมผัส (อิงตามเคอร์เซอร์) ที่มีความเที่ยงตรงสูง เช่น เมาส์หรือแทร็กแพดที่สามารถจําลองอินพุตแบบสัมผัสได้อย่างเพียงพอ (รวมถึงการรองรับท่าทางสัมผัสพื้นฐาน) และระบุว่าอุปกรณ์รองรับฟังก์ชันการทำงานของหน้าจอสัมผัสชุดย่อยที่จำลอง
หากการติดตั้งใช้งานอุปกรณ์ไม่มีหน้าจอสัมผัส แต่มีระบบอินพุตด้วยเคอร์เซอร์อื่นที่ต้องการให้บริการ ผู้ผลิตจะต้องดำเนินการดังนี้
- ควรประกาศการรองรับ Flag ฟีเจอร์
android.hardware.faketouch
หากการติดตั้งใช้งานอุปกรณ์ประกาศว่ารองรับ android.hardware.faketouch
อุปกรณ์ดังกล่าวจะมีลักษณะดังนี้
- [C-1-1] ต้องรายงานตำแหน่งสัมบูรณ์บนหน้าจอ X และ Y ของตำแหน่งเคอร์เซอร์ และแสดงเคอร์เซอร์ที่มองเห็นได้บนหน้าจอ
- [C-1-2] ต้องรายงานเหตุการณ์การสัมผัสด้วยโค้ดการดำเนินการที่ระบุการเปลี่ยนแปลงสถานะที่เกิดขึ้นกับเคอร์เซอร์ที่เลื่อนขึ้นหรือลงบนหน้าจอ
- [C-1-3] ต้องรองรับเคอร์เซอร์ที่กดลงและขึ้นบนวัตถุบนหน้าจอ ซึ่งช่วยให้ผู้ใช้จําลองการแตะวัตถุบนหน้าจอได้
- [C-1-4] ต้องรองรับการกดเคอร์เซอร์ลง การกดเคอร์เซอร์ขึ้น การกดเคอร์เซอร์ลงแล้วกดขึ้นอีกครั้งในตำแหน่งเดียวกันบนวัตถุบนหน้าจอภายในเกณฑ์เวลา ซึ่งจะช่วยให้ผู้ใช้จําลองการแตะ 2 ครั้งบนวัตถุบนหน้าจอได้
- [C-1-5] ต้องรองรับการกดแป้นเคอร์เซอร์ลง ณ จุดใดก็ได้บนหน้าจอ การเลื่อนเคอร์เซอร์ไปยังจุดใดก็ได้บนหน้าจอตามด้วยการปัดเคอร์เซอร์ขึ้น ซึ่งช่วยให้ผู้ใช้จําลองการลากด้วยการแตะได้
- [C-1-6] ต้องรองรับการกดแป้นลูกศรลงแล้วอนุญาตให้ผู้ใช้ย้ายวัตถุไปยังตำแหน่งอื่นบนหน้าจออย่างรวดเร็ว จากนั้นกดแป้นลูกศรขึ้นบนหน้าจอ ซึ่งจะช่วยให้ผู้ใช้เหวี่ยงวัตถุบนหน้าจอได้
หากการติดตั้งใช้งานอุปกรณ์ประกาศว่ารองรับ android.hardware.faketouch.multitouch.distinct
อุปกรณ์ดังกล่าวจะมีลักษณะดังนี้
- [C-2-1] ต้องประกาศรองรับ
android.hardware.faketouch
- [C-2-2] ต้องรองรับการติดตามอินพุตเคอร์เซอร์อิสระอย่างน้อย 2 รายการแยกกัน
หากการติดตั้งใช้งานอุปกรณ์ประกาศว่ารองรับ android.hardware.faketouch.multitouch.jazzhand
อุปกรณ์ดังกล่าวจะมีลักษณะดังนี้
- [C-3-1] ต้องประกาศรองรับ
android.hardware.faketouch
- [C-3-2] ต้องรองรับการติดตามอินพุตเคอร์เซอร์ที่แยกกันอย่างน้อย 5 (การติดตามมือของนิ้ว) รายการอย่างอิสระ
7.2.6. การรองรับเกมคอนโทรลเลอร์
7.2.6.1. การแมปปุ่ม
การติดตั้งใช้งานอุปกรณ์
- [C-1-1] ต้องสามารถแมปเหตุการณ์ HID กับค่าคงที่
InputEvent
ที่เกี่ยวข้องตามที่ระบุไว้ในตารางด้านล่าง การติดตั้งใช้งาน Android เวอร์ชัน upstream เป็นไปตามข้อกำหนดนี้
หากการติดตั้งใช้งานอุปกรณ์ฝังตัวควบคุมไว้หรือจัดส่งพร้อมตัวควบคุมแยกต่างหากในกล่องที่จะมีวิธีป้อนเหตุการณ์ทั้งหมดที่แสดงในตารางด้านล่าง อุปกรณ์ดังกล่าวจะต้องมีคุณสมบัติดังนี้
- [C-2-1] ต้องประกาศ Flag ฟีเจอร์
android.hardware.gamepad
ปุ่ม | การใช้งาน HID2 | ปุ่ม Android |
---|---|---|
ก1 | 0x09 0x0001 | KEYCODE_BUTTON_A (96) |
B1 | 0x09 0x0002 | KEYCODE_BUTTON_B (97) |
X1 | 0x09 0x0004 | KEYCODE_BUTTON_X (99) |
Y1 | 0x09 0x0005 | KEYCODE_BUTTON_Y (100) |
D-pad ขึ้น1 D-pad ลง1 |
0x01 0x00393 | AXIS_HAT_Y4 |
D-pad ซ้าย1 D-pad ขวา1 |
0x01 0x00393 | AXIS_HAT_X4 |
ปุ่ม L1 | 0x09 0x0007 | KEYCODE_BUTTON_L1 (102) |
ปุ่ม L R ขวา1 | 0x09 0x0008 | KEYCODE_BUTTON_R1 (103) |
คลิกแท่งบังคับซ้าย1 | 0x09 0x000E | KEYCODE_BUTTON_THUMBL (106) |
คลิกแท่งบังคับด้านขวา1 | 0x09 0x000F | KEYCODE_BUTTON_THUMBR (107) |
กลับ1 | 0x0c 0x0224 | KEYCODE_BACK (4) |
1 KeyEvent
2 การใช้งาน HID ข้างต้นต้องประกาศภายใน 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 |
7.2.7. การควบคุมระยะไกล
ดูข้อกำหนดเฉพาะอุปกรณ์ได้ที่ส่วนที่ 2.3.1
7.3. เซ็นเซอร์
หากการติดตั้งใช้งานอุปกรณ์มีเซ็นเซอร์บางประเภทที่มี API ที่สอดคล้องกันสำหรับนักพัฒนาแอปบุคคลที่สาม การติดตั้งใช้งานอุปกรณ์นั้นต้องใช้ API ดังกล่าวตามที่อธิบายไว้ในเอกสารประกอบของ Android SDK และเอกสารประกอบโอเพนซอร์สของ Android เกี่ยวกับเซ็นเซอร์
การติดตั้งใช้งานอุปกรณ์
- [C-0-1] ต้องรายงานการมีอยู่หรือไม่มีของเซ็นเซอร์อย่างถูกต้องตามคลาส
android.content.pm.PackageManager
- [C-0-2] ต้องแสดงรายการเซ็นเซอร์ที่รองรับที่ถูกต้องผ่าน
SensorManager.getSensorList()
และวิธีการที่คล้ายกัน - [C-0-3] ต้องทํางานอย่างสมเหตุสมผลสําหรับ API เซ็นเซอร์อื่นๆ ทั้งหมด (เช่น แสดงผล
true
หรือfalse
ตามเหมาะสมเมื่อแอปพลิเคชันพยายามลงทะเบียนตัวรับฟัง ไม่เรียกใช้ตัวรับฟังเซ็นเซอร์เมื่อไม่มีเซ็นเซอร์ที่เกี่ยวข้อง เป็นต้น)
หากการติดตั้งใช้งานอุปกรณ์มีเซ็นเซอร์บางประเภทที่มี API ที่สอดคล้องกันสำหรับนักพัฒนาแอปบุคคลที่สาม นักพัฒนาแอปบุคคลที่สามจะทำสิ่งต่อไปนี้ได้
- [C-1-1] ต้องรายงานค่าการวัดจากเซ็นเซอร์ทั้งหมดโดยใช้ค่าระบบหน่วยวัดระหว่างประเทศ (เมตริก) ที่เกี่ยวข้องสำหรับเซ็นเซอร์แต่ละประเภทตามที่ระบุไว้ในเอกสารประกอบของ Android SDK
- [C-1-2] ต้องรายงานข้อมูลเซ็นเซอร์โดยมีความล่าช้าสูงสุด 100 มิลลิวินาที + 2 * sample_time ในกรณีที่สตรีมเซ็นเซอร์มีความล่าช้าสูงสุดที่ขอ 0 มิลลิวินาทีเมื่อตัวประมวลผลแอปพลิเคชันทำงานอยู่ ความล่าช้านี้ไม่รวมความล่าช้าในการกรอง
- [C-1-3] ต้องรายงานตัวอย่างเซ็นเซอร์แรกภายใน 400 มิลลิวินาที + 2 * sample_time ของเซ็นเซอร์ที่เปิดใช้งาน ตัวอย่างนี้ยอมรับได้หากมีความแม่นยํา 0
- [C-1-4] สําหรับ API ที่เอกสารประกอบของ Android SDK ระบุว่าเป็นเซ็นเซอร์แบบต่อเนื่อง การติดตั้งใช้งานอุปกรณ์ต้องให้ตัวอย่างข้อมูลเป็นระยะอย่างต่อเนื่อง ซึ่งควรมีความผันผวนต่ำกว่า 3% โดยความผันผวนหมายถึงค่าความเบี่ยงเบนมาตรฐานของความแตกต่างของค่าการประทับเวลาที่รายงานระหว่างเหตุการณ์ที่ต่อเนื่องกัน
- [C-1-5] ต้องตรวจสอบว่าสตรีมเหตุการณ์ของเซ็นเซอร์ต้องไม่ป้องกันไม่ให้ CPU ของอุปกรณ์เข้าสู่สถานะ "หยุดชั่วคราว" หรือตื่นจากสถานะ "หยุดชั่วคราว"
- [C-1-6] ต้องรายงานเวลาของเหตุการณ์เป็นนาโนวินาทีตามที่ระบุไว้ในเอกสารประกอบของ Android SDK ซึ่งแสดงถึงเวลาที่เกิดเหตุการณ์และซิงค์กับนาฬิกา SystemClock.elapsedRealtimeNano()
- [C-SR-1] ขอแนะนำอย่างยิ่งให้มีข้อผิดพลาดในการซิงค์การประทับเวลาต่ำกว่า 100 มิลลิวินาที และควรมีข้อผิดพลาดในการซิงค์การประทับเวลาต่ำกว่า 1 มิลลิวินาที
- เมื่อเซ็นเซอร์หลายตัวทำงานอยู่ ปริมาณการใช้พลังงานไม่ควรเกินยอดรวมของปริมาณการใช้พลังงานที่รายงานของเซ็นเซอร์แต่ละตัว
รายการข้างต้นเป็นเพียงตัวอย่างบางส่วนเท่านั้น ลักษณะการทํางานของ Android SDK ที่บันทึกไว้และเอกสารประกอบโอเพนซอร์สของ Android เกี่ยวกับเซ็นเซอร์ถือเป็นข้อมูลที่น่าเชื่อถือ
หากการติดตั้งใช้งานอุปกรณ์มีเซ็นเซอร์บางประเภทที่มี API ที่สอดคล้องกันสำหรับนักพัฒนาแอปบุคคลที่สาม นักพัฒนาแอปบุคคลที่สามจะทำสิ่งต่อไปนี้ได้
- [C-1-6] ต้องตั้งค่าความละเอียดที่ไม่ใช่ 0 สำหรับเซ็นเซอร์ทั้งหมด และรายงานค่าผ่านเมธอด
Sensor.getResolution()
API
เซ็นเซอร์บางประเภทเป็นแบบผสม ซึ่งหมายความว่าสามารถมาจากข้อมูลที่ได้จากเซ็นเซอร์อื่นๆ อย่างน้อย 1 ตัว (เช่น เซ็นเซอร์การวางแนวและเซ็นเซอร์ความเร่งเชิงเส้น)
การติดตั้งใช้งานอุปกรณ์
- ควรติดตั้งใช้งานเซ็นเซอร์ประเภทเหล่านี้เมื่อรวมเซ็นเซอร์ที่จับสัญญาณได้จริงตามข้อกําหนดไว้ตามที่อธิบายไว้ในประเภทเซ็นเซอร์
หากการติดตั้งใช้งานอุปกรณ์มีเซ็นเซอร์คอมโพสิต อุปกรณ์จะมีลักษณะดังนี้
- [C-2-1] ต้องใช้เซ็นเซอร์ตามที่อธิบายไว้ในเอกสารประกอบโอเพนซอร์สของ Android เกี่ยวกับเซ็นเซอร์คอมโพสิต
หากการติดตั้งใช้งานอุปกรณ์มีเซ็นเซอร์ประเภทหนึ่งๆ ที่มี API ที่สอดคล้องกันสำหรับนักพัฒนาแอปบุคคลที่สาม และเซ็นเซอร์รายงานค่าเพียงค่าเดียว การติดตั้งใช้งานอุปกรณ์จะมีลักษณะดังนี้
- [C-3-1] ต้องตั้งค่าความละเอียดเป็น 1 สําหรับเซ็นเซอร์และรายงานค่าผ่านเมธอด
Sensor.getResolution()
API
หากการติดตั้งใช้งานอุปกรณ์มีเซ็นเซอร์บางประเภทที่รองรับ SensorAdditionalInfo#TYPE_VEC3_CALIBRATION และเซ็นเซอร์ดังกล่าวแสดงต่อนักพัฒนาแอปบุคคลที่สาม นักพัฒนาแอปบุคคลที่สามจะทำสิ่งต่อไปนี้ได้
- [C-4-1] ต้องไม่มีพารามิเตอร์การสอบเทียบที่ตายตัวซึ่งกำหนดโดยโรงงานในข้อมูลที่ให้ไว้
หากการติดตั้งใช้งานอุปกรณ์มีการใช้ตัวตรวจวัดความเร่ง 3 แกน เซ็นเซอร์ไจโรสโคป 3 แกน หรือเซ็นเซอร์แม่เหล็ก อุปกรณ์ดังกล่าวจะมีลักษณะดังนี้
- [C-SR-2] ขอแนะนำอย่างยิ่งให้ตรวจสอบว่าตัวตรวจวัดความเร่ง เซ็นเซอร์วัดการหมุน และเครื่องวัดค่าความเข้มข้นของสนามแม่เหล็กมีตำแหน่งสัมพัทธ์คงที่ เช่น หากอุปกรณ์เปลี่ยนรูปแบบได้ (เช่น พับได้) แกนเซ็นเซอร์จะยังคงอยู่ในแนวเดียวกันและสอดคล้องกับระบบพิกัดของเซ็นเซอร์ในทุกสถานะการเปลี่ยนรูปแบบของอุปกรณ์ที่เป็นไปได้
7.3.1. ตัวตรวจวัดความเร่ง
การติดตั้งใช้งานอุปกรณ์
- [C-SR-1] ขอแนะนำอย่างยิ่งให้ใส่ตัววัดความเร่งแบบ 3 แกน
หากการติดตั้งใช้งานอุปกรณ์มีเครื่องวัดความเร่งแบบ 3 แกน อุปกรณ์จะมีลักษณะดังนี้
- [C-1-1] ต้องสามารถรายงานเหตุการณ์ได้สูงสุดที่ความถี่อย่างน้อย 50 Hz
- [C-1-2] ต้องติดตั้งใช้งานและรายงานเซ็นเซอร์
TYPE_ACCELEROMETER
- [C-1-3] ต้องเป็นไปตามระบบพิกัดเซ็นเซอร์ Android ตามที่ระบุไว้ใน Android API
- [C-1-4] ต้องสามารถวัดจากการตกอย่างอิสระได้สูงสุด 4 เท่าของแรงโน้มถ่วง(4g) ขึ้นไปบนแกนใดก็ได้
- [C-1-5] ต้องมีความละเอียดอย่างน้อย 12 บิต
- [C-1-6] ค่าเบี่ยงเบนมาตรฐานต้องไม่เกิน 0.05 m/s^ โดยค่าเบี่ยงเบนมาตรฐานควรคํานวณตามแกนแต่ละแกนจากตัวอย่างที่รวบรวมในช่วงระยะเวลาอย่างน้อย 3 วินาทีที่อัตราความถี่ในการสุ่มตัวอย่างที่เร็วที่สุด
- [C-SR-2] แนะนำอย่างยิ่งให้ติดตั้ง
TYPE_SIGNIFICANT_MOTION
เซ็นเซอร์คอมโพสิต - [C-SR-3] ขอแนะนําอย่างยิ่งให้ติดตั้งใช้งานและรายงานเซ็นเซอร์
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-4] แนะนำอย่างยิ่งให้ติดตั้งใช้งานเซ็นเซอร์คอมโพสิต
TYPE_GAME_ROTATION_VECTOR
หากการติดตั้งใช้งานอุปกรณ์มีตัวตรวจวัดความเร่งแบบ 3 แกน เซ็นเซอร์เครื่องวัดการหมุนแบบ 3 แกน และเซ็นเซอร์แม่เหล็ก อุปกรณ์จะทําสิ่งต่อไปนี้
- [C-4-1] ต้องใช้เซ็นเซอร์แบบผสม
TYPE_ROTATION_VECTOR
7.3.2. เครื่องวัดค่าความเข้มข้นของสนามแม่เหล็ก
การติดตั้งใช้งานอุปกรณ์
- [C-SR-1] ขอแนะนำอย่างยิ่งให้ใส่มาตรความเข้มสนามแม่เหล็ก 3 แกน (เข็มทิศ)
หากการติดตั้งใช้งานอุปกรณ์มีแม่เหล็ก 3 แกน อุปกรณ์จะมีลักษณะดังนี้
- [C-1-1] ต้องติดตั้งเซ็นเซอร์
TYPE_MAGNETIC_FIELD
- [C-1-2] ต้องสามารถรายงานเหตุการณ์ได้สูงสุดความถี่ 10 Hz และควรรายงานเหตุการณ์ได้สูงสุดความถี่ 50 Hz
- [C-1-3] ต้องเป็นไปตามระบบพิกัดเซ็นเซอร์ Android ตามที่ระบุไว้ใน Android API
- [C-1-4] ต้องสามารถวัดได้ระหว่าง -900 µT ถึง +900 µT ในแต่ละแกนก่อนที่จะอิ่มตัว
- [C-1-5] ต้องมีค่าออฟเซ็ตของเหล็กแข็งน้อยกว่า 700 µT และต้องมีค่าต่ำกว่า 200 µT โดยวางมาตรแม่เหล็กให้ห่างจากสนามแม่เหล็กแบบไดนามิก (เกิดจากกระแสไฟฟ้า) และแบบคงที่ (เกิดจากแม่เหล็ก)
- [C-1-6] ต้องมีความละเอียดเท่ากับหรือหนาแน่นกว่า 0.6 µT
- [C-1-7] ต้องรองรับการปรับเทียบออนไลน์และการชดเชยความเบี่ยงเบนของฮาร์ดดิสก์ และเก็บรักษาพารามิเตอร์การชดเชยไว้ระหว่างการรีบูตอุปกรณ์
- [C-1-8] ต้องใช้การชดเชยด้วยเหล็กอ่อน การปรับเทียบทำได้ขณะใช้งานหรือระหว่างการผลิตอุปกรณ์
- [C-1-9] ค่าเบี่ยงเบนมาตรฐานต้องคำนวณตามแต่ละแกนจากตัวอย่างที่รวบรวมในช่วงระยะเวลาอย่างน้อย 3 วินาทีที่อัตราการสุ่มตัวอย่างเร็วที่สุด โดยต้องไม่เกิน 1.5 µT และควรมีค่าเบี่ยงเบนมาตรฐานไม่เกิน 0.5 µT
- [C-1-10] ต้องใช้เซ็นเซอร์
TYPE_MAGNETIC_FIELD_UNCALIBRATED
หากการติดตั้งใช้งานอุปกรณ์มีเครื่องวัดค่าความเข้มข้นของสนามแม่เหล็ก 3 แกน เซ็นเซอร์ตัวตรวจวัดความเร่ง และเซ็นเซอร์เครื่องวัดการหมุน 3 แกน อุปกรณ์จะทําสิ่งต่อไปนี้
- [C-2-1] ต้องใช้เซ็นเซอร์คอมโพสิต
TYPE_ROTATION_VECTOR
หากการติดตั้งใช้งานอุปกรณ์มีแม่เหล็กไฟฟ้า 3 แกน ตัววัดความเร่ง อุปกรณ์จะทําสิ่งต่อไปนี้
- อาจติดตั้งเซ็นเซอร์
TYPE_GEOMAGNETIC_ROTATION_VECTOR
หากการติดตั้งใช้งานอุปกรณ์มีเครื่องวัดค่าความเข้มข้นของสนามแม่เหล็กแบบ 3 แกน ตัวตรวจวัดความเร่ง และเซ็นเซอร์ TYPE_GEOMAGNETIC_ROTATION_VECTOR
อุปกรณ์จะทําสิ่งต่อไปนี้
- [C-3-1] ต้องใช้พลังงานน้อยกว่า 10 mW
- ควรใช้พลังงานน้อยกว่า 3 mW เมื่อเซ็นเซอร์ลงทะเบียนสำหรับโหมดแบตช์ที่ 10 Hz
7.3.3. GPS
การติดตั้งใช้งานอุปกรณ์
- [C-SR-1] ขอแนะนำอย่างยิ่งให้ใส่เครื่องรับ GPS/GNSS
หากการติดตั้งใช้งานอุปกรณ์มีเครื่องรับ GPS/GNSS และรายงานความสามารถให้กับแอปพลิเคชันผ่าน Flag ฟีเจอร์ android.hardware.location.gps
อุปกรณ์จะมีลักษณะดังนี้
- [C-1-1] ต้องรองรับเอาต์พุตตำแหน่งที่อัตราอย่างน้อย 1 Hz เมื่อมีการขอผ่าน
LocationManager#requestLocationUpdate
- [C-1-2] ต้องระบุตำแหน่งได้ในสภาพท้องฟ้าเปิด (สัญญาณแรง เส้นทางหลายเส้นทางที่ควรละเว้น HDOP < 2) ภายใน 10 วินาที (เวลาในการหาตำแหน่งครั้งแรกที่รวดเร็ว) เมื่อเชื่อมต่อกับอินเทอร์เน็ตที่มีความเร็วข้อมูลตั้งแต่ 0.5 Mbps ขึ้นไป โดยปกติแล้วข้อกำหนดนี้เป็นไปตามการใช้เทคนิค GPS/GNSS แบบเสริมหรือแบบคาดการณ์เพื่อลดเวลาในการล็อก GPS/GNSS (ข้อมูลความช่วยเหลือประกอบด้วยเวลาอ้างอิง ตำแหน่งอ้างอิง และข้อมูลดาวเทียม/นาฬิกา)
- [C-1-6] หลังจากคำนวณตำแหน่งดังกล่าว การติดตั้งใช้งานอุปกรณ์ต้องระบุตำแหน่งของอุปกรณ์ในที่โล่งภายใน 5 วินาทีเมื่อมีการเริ่มคําขอตำแหน่งอีกครั้ง สูงสุด 1 ชั่วโมงหลังจากการคำนวณตำแหน่งครั้งแรก แม้ว่าจะมีการส่งคำขอครั้งต่อๆ ไปโดยไม่มีการเชื่อมต่ออินเทอร์เน็ต และ/หรือหลังจากปิด/เปิดเครื่องแล้ว
ในสภาวะท้องฟ้าเปิดหลังจากระบุตำแหน่งแล้ว ขณะหยุดนิ่งหรือเคลื่อนที่ด้วยอัตราเร่งน้อยกว่า 1 เมตรต่อวินาทียกกำลัง 2 ให้ทำดังนี้
- [C-1-3] ต้องระบุตำแหน่งได้ภายใน 20 เมตร และความเร็วได้ภายใน 0.5 เมตรต่อวินาที อย่างน้อย 95% ของเวลา
- [C-1-4] ต้องติดตามและรายงานผ่านดาวเทียมอย่างน้อย 8 ดวงจากกลุ่มดาวหนึ่งๆ พร้อมกันผ่าน
GnssStatus.Callback
- ควรติดตามดาวเทียมได้อย่างน้อย 24 ดวงพร้อมกันจากกลุ่มดาวหลายกลุ่ม (เช่น GPS + Glonass, Beidou, Galileo อย่างใดอย่างหนึ่งอย่างน้อย 1 กลุ่ม)
[C-SR-2] ขอแนะนำอย่างยิ่งให้ส่งเอาต์พุตตำแหน่ง GPS/GNSS ปกติผ่าน API ของผู้ให้บริการตำแหน่ง GNSS ต่อไปในระหว่างการโทรฉุกเฉินทางโทรศัพท์
[C-SR-3] ขอแนะนำอย่างยิ่งให้รายงานการวัด GNSS จากกลุ่มดาวทั้งหมดที่ติดตาม (ตามที่รายงานในข้อความ GnssStatus) ยกเว้น SBAS
[C-SR-4] ขอแนะนำอย่างยิ่งให้รายงาน AGC และความถี่ในการวัด GNSS
[C-SR-5] ขอแนะนำอย่างยิ่งให้รายงานความแม่นยำโดยประมาณทั้งหมด (รวมถึงทิศทาง ความเร็ว และแนวตั้ง) เป็นส่วนหนึ่งของตำแหน่ง GPS/GNSS แต่ละตำแหน่ง
[C-SR-6] ขอแนะนำอย่างยิ่งให้รายงานการวัด GNSS ทันทีที่พบ แม้ว่าจะยังไม่ได้รายงานตำแหน่งที่คำนวณจาก GPS/GNSS
[C-SR-7] ขอแนะนำอย่างยิ่งให้รายงานช่วงสัญญาณเสมือนและอัตราช่วงสัญญาณเสมือนของ GNSS ซึ่งในสภาพท้องฟ้าเปิดหลังจากระบุตำแหน่งแล้ว ขณะหยุดนิ่งหรือเคลื่อนที่ด้วยความเร่งน้อยกว่า 0.2 เมตรต่อวินาทียกกำลัง 2 จะเพียงพอที่จะคำนวณตำแหน่งภายใน 20 เมตร และความเร็วภายใน 0.2 เมตรต่อวินาที อย่างน้อย 95% ของเวลา
7.3.4. เครื่องวัดการหมุน
การติดตั้งใช้งานอุปกรณ์
- [C-SR-1] ขอแนะนำอย่างยิ่งให้ใส่เซ็นเซอร์ไจโรสโคป
หากการติดตั้งใช้งานอุปกรณ์มีไจโรสโคปแบบ 3 แกน อุปกรณ์จะมีลักษณะดังนี้
- [C-1-1] ต้องสามารถรายงานเหตุการณ์ได้สูงสุดที่ความถี่อย่างน้อย 50 Hz
- [C-1-2] ต้องติดตั้งเซ็นเซอร์
TYPE_GYROSCOPE
- [C-1-4] ต้องมีความละเอียด 12 บิตขึ้นไป
- [C-1-5] ต้องชดเชยอุณหภูมิ
- [C-1-6] ต้องได้รับการสอบเทียบและชดเชยขณะใช้งาน และเก็บพารามิเตอร์การชดเชยไว้ระหว่างการรีบูตอุปกรณ์
- [C-1-7] ต้องมีค่าความแปรปรวนไม่เกิน 1e-7 rad^2 / s^2 ต่อ Hz (ความแปรปรวนต่อ Hz หรือ rad^2 / s) อนุญาตให้ความแปรปรวนเปลี่ยนแปลงตามอัตราการสุ่มตัวอย่าง แต่ต้องถูกจำกัดด้วยค่านี้ กล่าวคือ หากคุณวัดความแปรปรวนของ Gyro ที่อัตราตัวอย่าง 1 Hz ค่าดังกล่าวไม่ควรเกิน 1e-7 rad^2/s^2
- [C-SR-2] ขอแนะนำอย่างยิ่งว่าข้อผิดพลาดในการสอบเทียบต้องน้อยกว่า 0.01 rad/s เมื่ออุปกรณ์อยู่กับที่ที่อุณหภูมิห้อง
- [C-SR-3] ขอแนะนําอย่างยิ่งให้ติดตั้งใช้งานเซ็นเซอร์
TYPE_GYROSCOPE_UNCALIBRATED
- [C-SR-4] ขอแนะนำอย่างยิ่งให้ใช้ความละเอียด 16 บิตขึ้นไป
- ควรรายงานเหตุการณ์อย่างน้อย 200 Hz
หากการติดตั้งใช้งานอุปกรณ์มีเครื่องวัดการหมุนแบบ 3 แกน เซ็นเซอร์ตัวตรวจวัดความเร่ง และเซ็นเซอร์เครื่องวัดค่าความเข้มข้นของสนามแม่เหล็ก อุปกรณ์จะทําสิ่งต่อไปนี้
- [C-2-1] ต้องใช้เซ็นเซอร์คอมโพสิต
TYPE_ROTATION_VECTOR
หากการติดตั้งใช้งานอุปกรณ์มีตัวตรวจวัดความเร่งแบบ 3 แกนและเซ็นเซอร์เครื่องวัดการหมุนแบบ 3 แกน อุปกรณ์จะทําดังนี้
- [C-3-1] ต้องใช้เซ็นเซอร์คอมโพสิต
TYPE_GRAVITY
และTYPE_LINEAR_ACCELERATION
- [C-SR-5] แนะนำอย่างยิ่งให้ติดตั้งใช้งานเซ็นเซอร์คอมโพสิต
TYPE_GAME_ROTATION_VECTOR
7.3.5. บารอมิเตอร์
การติดตั้งใช้งานอุปกรณ์
- [C-SR-1] ขอแนะนำอย่างยิ่งให้ใส่บารอมิเตอร์ (เซ็นเซอร์ความดันอากาศรอบตัว)
หากการติดตั้งใช้งานอุปกรณ์มีบารอมิเตอร์ อุปกรณ์จะมีลักษณะดังนี้
- [C-1-1] ต้องติดตั้งใช้งานและรายงานเซ็นเซอร์
TYPE_PRESSURE
- [C-1-2] ต้องส่งเหตุการณ์ที่ 5 Hz ขึ้นไปได้
- [C-1-3] ต้องชดเชยอุณหภูมิ
- [C-SR-2] ขอแนะนำอย่างยิ่งให้รายงานการวัดความดันได้ในช่วง 300hPa ถึง 1100hPa
- ควรมีความแม่นยำสัมบูรณ์ 1hPa
- ควรมีความแม่นยำสัมพัทธ์ 0.12hPa ในช่วง 20hPa (เทียบเท่ากับความแม่นยำประมาณ 1 เมตรเมื่อการเปลี่ยนแปลงอยู่ที่ประมาณ 200 เมตรที่ระดับน้ำทะเล)
7.3.6. เทอร์โมมิเตอร์
หากการติดตั้งใช้งานอุปกรณ์มีเครื่องวัดอุณหภูมิรอบตัว (เซ็นเซอร์อุณหภูมิ) อุปกรณ์จะดำเนินการต่อไปนี้
- [C-1-1] ต้องกําหนด
SENSOR_TYPE_AMBIENT_TEMPERATURE
สําหรับเซ็นเซอร์อุณหภูมิรอบตัว และเซ็นเซอร์ต้องวัดอุณหภูมิรอบตัว (ห้อง/ห้องโดยสารของยานพาหนะ) จากตําแหน่งที่ผู้ใช้โต้ตอบกับอุปกรณ์เป็นองศาเซลเซียส
หากการติดตั้งใช้งานอุปกรณ์มีเซ็นเซอร์เทอร์โมมิเตอร์ที่วัดอุณหภูมิอื่นนอกเหนือจากอุณหภูมิแวดล้อม เช่น อุณหภูมิ CPU อุปกรณ์จะมีลักษณะดังนี้
- [C-2-1] ต้องไม่กำหนด
SENSOR_TYPE_AMBIENT_TEMPERATURE
สำหรับเซ็นเซอร์อุณหภูมิ
หากการติดตั้งใช้งานอุปกรณ์มีเซ็นเซอร์สำหรับตรวจสอบอุณหภูมิผิวหนัง อุปกรณ์จะดำเนินการต่อไปนี้
- [C-SR-1] ขอแนะนําอย่างยิ่งให้รองรับ API PowerManager.getThermalHeadroom
7.3.7. โฟโตมิเตอร์
- การติดตั้งใช้งานอุปกรณ์อาจรวมถึงโฟโตมิเตอร์ (เซ็นเซอร์แสงแวดล้อม)
7.3.8. พร็อกซิมิตีเซ็นเซอร์
- การติดตั้งใช้งานอุปกรณ์อาจรวมถึงพร็อกซิมิตีเซ็นเซอร์
หากการติดตั้งใช้งานอุปกรณ์มีพร็อกซิมิตีเซ็นเซอร์และรายงานเฉพาะค่าการอ่านแบบไบนารี "ใกล้" หรือ "ไกล" อุปกรณ์จะมีลักษณะดังนี้
- [C-1-1] ต้องวัดระยะใกล้ของวัตถุในทิศทางเดียวกับหน้าจอ กล่าวคือ เซ็นเซอร์ตรวจหาบุคคลในบริเวณใกล้เคียงต้องปรับให้ตรวจจับวัตถุที่อยู่ใกล้กับหน้าจอ เนื่องจากวัตถุประสงค์หลักของเซ็นเซอร์ประเภทนี้คือตรวจหาโทรศัพท์ที่ผู้ใช้กำลังใช้อยู่ หากการติดตั้งใช้งานอุปกรณ์มีเซ็นเซอร์ตรวจหาบุคคลในบริเวณใกล้เคียงที่มีการวางแนวอื่น อุปกรณ์ต้องเข้าถึงผ่าน API นี้ไม่ได้
- [C-1-2] ต้องมีความละเอียด 1 บิตขึ้นไป
- [C-1-3] ต้องใช้ 0 เซนติเมตรเป็นค่าที่อ่านได้ในระยะใกล้และ 5 เซนติเมตรเป็นค่าที่อ่านได้ในระยะไกล
- [C-1-4] ต้องรายงานช่วงสูงสุดและความละเอียด 5
7.3.9. เซ็นเซอร์ความแม่นยำสูง
หากการติดตั้งใช้งานอุปกรณ์มีชุดเซ็นเซอร์คุณภาพสูงขึ้นตามที่ระบุไว้ในส่วนนี้ และทำให้เซ็นเซอร์ดังกล่าวพร้อมใช้งานสำหรับแอปของบุคคลที่สาม แอปของบุคคลที่สามจะทำสิ่งต่อไปนี้ได้
- [C-1-1] ต้องระบุความสามารถผ่าน
android.hardware.sensor.hifi_sensors
Flag ฟีเจอร์
หากการติดตั้งใช้งานอุปกรณ์ประกาศ 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/√Hz
- ต้องใช้เซ็นเซอร์รูปแบบที่ไม่มีการตื่นขึ้นของเซ็นเซอร์นี้โดยมีความจุบัฟเฟอร์อย่างน้อย 3,000 เหตุการณ์ของเซ็นเซอร์
- ต้องมีอัตราการใช้พลังงานในการแบ่งกลุ่มไม่แย่กว่า 3 mW
- [C-SR-1] ขอแนะนำอย่างยิ่งให้มีแบนด์วิดท์การวัด 3dB อย่างน้อย 80% ของความถี่ Nyquist และสเปกตรัมสัญญาณรบกวนสีขาวภายในแบนด์วิดท์นี้
- ควรมีการเดินแบบสุ่มของอัตราเร่งน้อยกว่า 30 μg √Hz ที่ทดสอบที่อุณหภูมิห้อง
- ควรมีการเปลี่ยนแปลงความเบี่ยงเบนเทียบกับอุณหภูมิไม่เกิน +/- 1 mg/°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°/วินาที/√Hz
- [C-SR-2] ขอแนะนำอย่างยิ่งให้มีแบนด์วิดท์การวัด 3dB อย่างน้อย 80% ของความถี่ Nyquist และสเปกตรัมสัญญาณรบกวนสีขาวภายในแบนด์วิดท์นี้
- ควรมีการสุ่มเดินของอัตราน้อยกว่า 0.001 °/s √Hz ที่ทดสอบที่อุณหภูมิห้อง
- ควรมีการเปลี่ยนแปลงความเบี่ยงเบนเทียบกับอุณหภูมิไม่เกิน +/- 0.05 °/ วินาที / °C
- ควรมีการเปลี่ยนแปลงความไวเทียบกับอุณหภูมิไม่เกิน 0.02% / °C
- ควรมีค่าความไม่เป็นเชิงเส้นของเส้นค่าดีที่สุดไม่เกิน 0.2%
- ควรมีความหนาแน่นของสัญญาณรบกวนไม่เกิน 0.007 °/s/√Hz
- ควรมีข้อผิดพลาดในการสอบเทียบน้อยกว่า 0.002 rad/s ในอุณหภูมิ 10-40 ℃ เมื่ออุปกรณ์อยู่กับที่
- ควรมีความไวต่อแรงโน้มถ่วงน้อยกว่า 0.1°/วินาที/g
- ควรมีความไวในแนวทแยงน้อยกว่า 4.0 % และมีความไวในแนวทแยงที่มีความผันผวนน้อยกว่า 0.3% ในช่วงอุณหภูมิที่อุปกรณ์ทำงาน
[C-2-4] ต้องมี
TYPE_GYROSCOPE_UNCALIBRATED
ที่มีข้อกำหนดด้านคุณภาพเหมือนกับTYPE_GYROSCOPE
[C-2-5] ต้องมีเซ็นเซอร์
TYPE_GEOMAGNETIC_FIELD
ซึ่งมีลักษณะดังนี้- ต้องมีช่วงการวัดระหว่าง -900 ถึง +900 μT เป็นอย่างน้อย
- ต้องมีความละเอียดในการวัดอย่างน้อย 5 LSB/uT
- ต้องมีความถี่การวัดขั้นต่ำ 5 Hz หรือต่ำกว่า
- ต้องมีความถี่การวัดสูงสุด 50 Hz ขึ้นไป
- ต้องมีสัญญาณรบกวนการวัดไม่เกิน 0.5 uT
[C-2-6] ต้องมี
TYPE_MAGNETIC_FIELD_UNCALIBRATED
ที่มีข้อกำหนดด้านคุณภาพเหมือนกับTYPE_GEOMAGNETIC_FIELD
และนอกจากนี้- ต้องใช้เซ็นเซอร์รูปแบบที่ไม่มีการตื่นขึ้นของเซ็นเซอร์นี้โดยมีความจุบัฟเฟอร์ของเหตุการณ์เซ็นเซอร์อย่างน้อย 600 รายการ
- [C-SR-3] ขอแนะนําอย่างยิ่งให้มีย่านความถี่ของสัญญาณรบกวนสีขาวตั้งแต่ 1 Hz ไปจนถึงอย่างน้อย 10 Hz เมื่ออัตราการรายงานคือ 50 Hz ขึ้นไป
[C-2-7] ต้องมีเซ็นเซอร์
TYPE_PRESSURE
ซึ่งมีลักษณะดังนี้- ต้องมีช่วงการวัดระหว่าง 300 ถึง 1,100 hPa เป็นอย่างน้อย
- ต้องมีความละเอียดการวัดอย่างน้อย 80 LSB/hPa
- ต้องมีความถี่การวัดขั้นต่ำ 1 Hz หรือต่ำกว่า
- ต้องมีความถี่การวัดสูงสุด 10 Hz ขึ้นไป
- ต้องมีสัญญาณรบกวนในการวัดไม่เกิน 2 Pa/√Hz
- ต้องใช้เซ็นเซอร์รูปแบบที่ไม่มีการตื่นขึ้นของเซ็นเซอร์นี้โดยมีความจุบัฟเฟอร์ของเหตุการณ์เซ็นเซอร์อย่างน้อย 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] ต้องมีการประทับเวลาเหตุการณ์ของเซ็นเซอร์ Gyroscope ในฐานเวลาเดียวกันกับระบบย่อยของกล้องและมีข้อผิดพลาดไม่เกิน 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] ต้องประกาศการรองรับประเภทช่องทางโดยตรงและระดับอัตรารายงานโดยตรงอย่างถูกต้องผ่าน
isDirectChannelTypeSupported
และgetHighestDirectReportRateLevel
API - [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 (เดิมคือสะดวก) โดยอิงตามอัตราการยอมรับการปลอมแปลงและการแอบอ้างเป็นบุคคลอื่น และการรักษาความปลอดภัยของไปป์ไลน์ไบโอเมตริก การจัดประเภทนี้กำหนดความสามารถที่เซ็นเซอร์ไบโอเมตริกมีต่ออินเทอร์เฟซกับแพลตฟอร์มและแอปพลิเคชันของบุคคลที่สาม เซ็นเซอร์จะจัดอยู่ในระดับ Class 1 โดยค่าเริ่มต้น และต้องมีคุณสมบัติตรงตามข้อกำหนดเพิ่มเติมตามที่ระบุไว้ด้านล่างหากต้องการจัดอยู่ในระดับ Class 2 หรือ Class 3 ทั้งข้อมูลไบโอเมตริกระดับ 2 และ 3 จะมีความสามารถเพิ่มเติมตามที่ระบุไว้ด้านล่าง
หากการติดตั้งใช้งานอุปกรณ์ทำให้เซ็นเซอร์ไบโอเมตริกพร้อมใช้งานสำหรับแอปพลิเคชันของบุคคลที่สามผ่าน android.hardware.biometrics.BiometricManager, android.hardware.biometrics.BiometricPrompt และ android.provider.Settings.ACTION_BIOMETRIC_ENROLL แอปพลิเคชันเหล่านั้นจะต้องมีคุณสมบัติดังนี้
- [C-4-1] ต้องเป็นไปตามข้อกำหนดสำหรับข้อมูลไบโอเมตริกระดับ 3 หรือระดับ 2 ตามที่ระบุไว้ในเอกสารนี้
- [C-4-2] ต้องรู้จักและปฏิบัติตามชื่อพารามิเตอร์แต่ละรายการที่กําหนดเป็นค่าคงที่ในคลาส Authenticators และชุดค่าผสมต่างๆ ของชื่อเหล่านั้น ในทางกลับกัน ต้องไม่ยอมรับหรือรู้จักค่าคงที่แบบจำนวนเต็มซึ่งส่งไปยังเมธอด canAuthenticate(int) และ setAllowedAuthenticators(int) นอกเหนือจากค่าคงที่แบบสาธารณะที่ระบุไว้ใน