สารบัญ
3.1. ความเข้ากันได้ของ Managed API
3.2. ความเข้ากันได้แบบ Soft API
3.2.3. ความเข้ากันได้ของ Intent
3.2.3.1. Intent ของแอปพลิเคชันหลัก
3.2.3.5. การตั้งค่าแอปเริ่มต้น
3.3. ความเข้ากันได้ของ Native API
3.3.1. อินเทอร์เฟซแบบไบนารีของแอปพลิเคชัน
3.3.2. ความเข้ากันได้ของโค้ดเนทีฟ ARM แบบ 32 บิต
3.4.1. ความเข้ากันได้ของ WebView
3.4.2. ความเข้ากันได้กับเบราว์เซอร์
3.5. ความเข้ากันได้ของลักษณะการทํางานของ API
3.8. ความเข้ากันได้ของอินเทอร์เฟซผู้ใช้
3.8.7. วอลเปเปอร์ภาพเคลื่อนไหว
3.9.1.1 การจัดสรรอุปกรณ์สำหรับเจ้าของอุปกรณ์
3.9.1.2 การจัดสรรโปรไฟล์ที่มีการจัดการ
3.9.2. การสนับสนุนเกี่ยวกับโปรไฟล์ที่มีการจัดการ
3.12.1.1. คู่มือรายการทีวีอิเล็กทรอนิกส์
3.12.1.3. การลิงก์แอปอินพุตของทีวี
4. ความเข้ากันได้ของแพ็กเกจแอปพลิเคชัน
5. ความเข้ากันได้ของมัลติมีเดีย
5.4.2. บันทึกเสียงเพื่อใช้การจดจำเสียง
5.4.3. บันทึกเพื่อเปลี่ยนเส้นทางการเล่น
5.5.3. ระดับเสียงเอาต์พุตเสียง
6. ความเข้ากันได้ของเครื่องมือและตัวเลือกสำหรับนักพัฒนาแอป
6.1. เครื่องมือสำหรับนักพัฒนาซอฟต์แวร์
6.2. ตัวเลือกสำหรับนักพัฒนาแอป
7.1.4. การเร่งกราฟิก 2 มิติและ 3 มิติ
7.1.5. โหมดความเข้ากันได้ของแอปพลิเคชันเดิม
7.2.4. การป้อนข้อมูลด้วยหน้าจอสัมผัส
7.2.5. การป้อนข้อมูลด้วยการสัมผัสจำลอง
7.2.6. การรองรับเกมคอนโทรลเลอร์
7.4.2.2. การตั้งค่าลิงก์โดยตรงที่ส่งผ่านอุโมงค์ Wi-Fi
7.4.4. Near-Field Communication
7.4.5. ความสามารถขั้นต่ำของเครือข่าย
7.5.4. ลักษณะการทํางานของ Camera API
7.6. หน่วยความจำและพื้นที่เก็บข้อมูล
7.6.1. หน่วยความจำและพื้นที่เก็บข้อมูลขั้นต่ำ
7.6.2. พื้นที่เก็บข้อมูลที่ใช้ร่วมกันของแอปพลิเคชัน
7.6.3. พื้นที่เก็บข้อมูลแบบ Adoptable
7.8.2.1. พอร์ตเสียงแบบแอนะล็อก
8.1. ความสอดคล้องของประสบการณ์ของผู้ใช้
9. ความเข้ากันได้ของรูปแบบการรักษาความปลอดภัย
9.2. UID และกระบวนการแยกต่างหาก
9.4. สภาพแวดล้อมการดําเนินการสํารอง
9.6. คำเตือนเกี่ยวกับ SMS แบบพรีเมียม
9.7. ฟีเจอร์ความปลอดภัยของเคอร์เนล
9.9. การเข้ารหัสดิสก์ทั้งเครื่อง
9.10. การเปิดเครื่องที่ได้รับการยืนยัน
9.11. คีย์และข้อมูลเข้าสู่ระบบ
10. การทดสอบความเข้ากันได้ของซอฟต์แวร์
10.1. ชุดเครื่องมือทดสอบความเข้ากันได้
1. ข้อมูลเบื้องต้น
เอกสารนี้จะระบุข้อกำหนดที่อุปกรณ์ต้องปฏิบัติตามเพื่อให้เข้ากันได้กับ Android 6.0
การใช้คำว่า "ต้อง" "ต้องไม่" "ต้อง" "ต้องไม่" "ควร" "ไม่ควร" "แนะนำ" "อาจ" และ "ไม่บังคับ" เป็นไปตามมาตรฐาน IETF ที่ระบุไว้ใน RFC2119 [แหล่งข้อมูล, 1]
"ผู้ติดตั้งใช้งานอุปกรณ์" หรือ "ผู้ติดตั้งใช้งาน" หมายถึงบุคคลหรือองค์กรที่พัฒนาโซลูชันฮาร์ดแวร์/ซอฟต์แวร์ที่ใช้ Android 6.0 "การติดตั้งใช้งานอุปกรณ์" หรือ "การติดตั้งใช้งานคือโซลูชันฮาร์ดแวร์/ซอฟต์แวร์ที่พัฒนาขึ้น"
การติดตั้งใช้งานอุปกรณ์ต้องเป็นไปตามข้อกำหนดที่ระบุไว้ในคำจำกัดความความเข้ากันได้นี้ รวมถึงเอกสารประกอบที่รวมไว้ผ่านข้อมูลอ้างอิง จึงจะถือว่าเข้ากันได้กับ Android 6.0
ในกรณีที่คำจำกัดความนี้หรือการทดสอบซอฟต์แวร์ที่อธิบายไว้ในส่วนที่ 10 ไม่ได้กล่าวถึง ไม่ชัดเจน หรือไม่สมบูรณ์ ผู้ติดตั้งใช้งานอุปกรณ์มีหน้าที่รับผิดชอบในการตรวจสอบความเข้ากันได้กับการติดตั้งใช้งานที่มีอยู่
ด้วยเหตุนี้ โครงการโอเพนซอร์ส Android [แหล่งข้อมูล, 2] จึงถือเป็นทั้งข้อมูลอ้างอิงและการใช้งาน Android ที่แนะนำ เราขอแนะนำอย่างยิ่งให้ผู้ติดตั้งใช้งานอุปกรณ์อิงตามการติดตั้งใช้งานจากซอร์สโค้ด "ต้นทาง" ให้ได้มากที่สุดจากโปรเจ็กต์โอเพนซอร์ส Android แม้ว่าในทางทฤษฎีแล้ว คอมโพเนนต์บางอย่างอาจแทนที่ด้วยการติดตั้งใช้งานทางเลือกได้ แต่เราขอแนะนำอย่างยิ่งว่าอย่าทำเช่นนั้นเนื่องจากการผ่านการทดสอบซอฟต์แวร์จะยากขึ้นอย่างมาก ผู้ติดตั้งใช้งานมีหน้าที่รับผิดชอบในการตรวจสอบว่าลักษณะการทำงานมีความเข้ากันได้ทั้งหมดกับการติดตั้งใช้งาน Android มาตรฐาน ซึ่งรวมถึงและนอกเหนือจากชุดทดสอบความเข้ากันได้ สุดท้าย โปรดทราบว่าเอกสารนี้ห้ามไม่ให้ใช้ชิ้นส่วนทดแทนและการดัดแปลงบางอย่างอย่างชัดเจน
แหล่งข้อมูลจํานวนมากที่ระบุไว้ในส่วนที่ 14 มาจาก Android SDK โดยตรงหรือโดยอ้อม และจะทํางานเหมือนกับข้อมูลในเอกสารประกอบของ SDK นั้น ในกรณีที่นิยามความเข้ากันได้นี้หรือชุดเครื่องมือทดสอบความเข้ากันได้ขัดแย้งกับเอกสารประกอบของ SDK ระบบจะถือว่าเอกสารประกอบของ SDK นั้นน่าเชื่อถือ รายละเอียดทางเทคนิคที่ระบุไว้ในข้อมูลอ้างอิงซึ่งรวมอยู่ในส่วนที่ 14 จะถือว่าเป็นส่วนหนึ่งของคำจำกัดความความเข้ากันได้นี้
2. ประเภทอุปกรณ์
แม้ว่าโปรเจ็กต์โอเพนซอร์ส Android จะใช้ในการติดตั้งใช้งานอุปกรณ์ประเภทต่างๆ และรูปแบบต่างๆ แต่ข้อกำหนดด้านสถาปัตยกรรมและความเข้ากันได้หลายประการได้รับการเพิ่มประสิทธิภาพสำหรับอุปกรณ์พกพา ตั้งแต่ Android 5.0 เป็นต้นไป โปรเจ็กต์โอเพนซอร์สของ Android มีเป้าหมายที่จะรองรับอุปกรณ์ประเภทต่างๆ มากขึ้นตามที่อธิบายไว้ในส่วนนี้
อุปกรณ์มือถือ Android หมายถึงการใช้งานอุปกรณ์ Android ที่มักใช้โดยถือไว้ในมือ เช่น เครื่องเล่น MP3, โทรศัพท์ และแท็บเล็ต การติดตั้งใช้งานอุปกรณ์ Android Handheld
- ต้องมีหน้าจอสัมผัสที่ฝังอยู่ในอุปกรณ์
- ต้องมีแหล่งจ่ายไฟที่ให้ความคล่องตัว เช่น แบตเตอรี่
อุปกรณ์ Android Television หมายถึงการใช้งานอุปกรณ์ Android ที่เป็นอินเทอร์เฟซความบันเทิงสําหรับรับชมสื่อดิจิทัล ภาพยนตร์ เกม แอป และ/หรือรายการทีวีสดสําหรับผู้ใช้ที่นั่งอยู่ห่างออกไปประมาณ 10 ฟุต ("การนั่งดูทีวีแบบผ่อนคลาย" หรือ "อินเทอร์เฟซผู้ใช้ระยะ 10 ฟุต") อุปกรณ์ Android Television มีลักษณะดังนี้
- ต้องมีหน้าจอที่ฝังไว้หรือมีพอร์ตเอาต์พุตวิดีโอ เช่น VGA, HDMI หรือพอร์ตไร้สายสำหรับแสดงผล
- ต้องประกาศฟีเจอร์ android.software.leanback และ android.hardware.type.television [แหล่งข้อมูล, 3]
อุปกรณ์นาฬิกา Android หมายถึงการใช้งานอุปกรณ์ Android ที่มีไว้สวมใส่บนร่างกาย ซึ่งอาจเป็นข้อมือ และมีลักษณะดังนี้
- ต้องมีหน้าจอที่มีความยาวเส้นทแยงมุมจริงอยู่ในช่วง 1.1 ถึง 2.5 นิ้ว
- ต้องประกาศฟีเจอร์ android.hardware.type.watch
- ต้องรองรับ uiMode = UI_MODE_TYPE_WATCH [Resources, 4]
การติดตั้งใช้งาน Android Automotive หมายถึงเครื่องเล่นวิทยุของรถยนต์ที่ใช้ Android เป็นระบบปฏิบัติการสำหรับระบบและ/หรือฟังก์ชันการทำงานของระบบสาระบันเทิงบางส่วนหรือทั้งหมด การติดตั้งใช้งาน Android Automotive
- ต้องประกาศฟีเจอร์ android.hardware.type.automotive
- ต้องรองรับ uiMode = UI_MODE_TYPE_CAR [Resources, 5]
การติดตั้งใช้งานอุปกรณ์ Android ทั้งหมดที่ไม่ตรงกับประเภทอุปกรณ์ข้างต้นยังต้องเป็นไปตามข้อกำหนดทั้งหมดในเอกสารนี้จึงจะใช้งานร่วมกับ Android 6.0 ได้ เว้นแต่ว่าข้อกำหนดจะระบุไว้อย่างชัดเจนว่าใช้ได้กับอุปกรณ์ Android บางประเภทจากข้างต้นเท่านั้น
2.1 การกําหนดค่าอุปกรณ์
ต่อไปนี้เป็นสรุปความแตกต่างที่สำคัญในการกำหนดค่าฮาร์ดแวร์ตามประเภทอุปกรณ์ (เซลล์ว่างหมายถึง "อาจ") ตารางนี้ไม่ได้ครอบคลุมการกำหนดค่าทั้งหมด โปรดดูรายละเอียดเพิ่มเติมในส่วนฮาร์ดแวร์ที่เกี่ยวข้อง
หมวดหมู่ | ฟีเจอร์ | ส่วน | มือถือ | โทรทัศน์ | ดู | ยานยนต์ | อื่นๆ |
---|---|---|---|---|---|---|---|
อินพุต | D-pad | 7.2.2. การนำทางแบบไม่สัมผัส | ต้อง | ||||
หน้าจอสัมผัส | 7.2.4. การป้อนข้อมูลด้วยหน้าจอสัมผัส | ต้อง | ต้อง | ควร | |||
ไมโครโฟน | 7.8.1. ไมโครโฟน | ต้อง | ควร | ต้อง | ต้อง | ควร | |
เซ็นเซอร์ | ตัวตรวจวัดความเร่ง | 7.3.1 ตัวตรวจวัดความเร่ง | ควร | ควร | ควร | ||
GPS | 7.3.3. GPS | ควร | ควร | ||||
การเชื่อมต่อ | Wi-Fi | 7.4.2. IEEE 802.11 | ควร | ต้อง | ควร | ควร | |
Wi-Fi Direct | 7.4.2.1. Wi-Fi Direct | ควร | ควร | ควร | |||
บลูทูธ | 7.4.3. บลูทูธ | ควร | ต้อง | ต้อง | ต้อง | ควร | |
บลูทูธพลังงานต่ำ | 7.4.3. บลูทูธ | ควร | ต้อง | ควร | ควร | ควร | |
โหมดอุปกรณ์ต่อพ่วง/โฮสต์ USB | 7.7. USB | ควร | ควร | ควร | |||
เอาต์พุต | พอร์ตลำโพงและ/หรือเอาต์พุตเสียง | 7.8.2. เอาต์พุตเสียง | ต้อง | ต้อง | ต้อง | ต้อง |
3. ซอฟต์แวร์
3.1 ความเข้ากันได้ของ Managed API
สภาพแวดล้อมการเรียกใช้ไบต์โค้ด Dalvik ที่มีการจัดการเป็นแพลตฟอร์มหลักสําหรับแอปพลิเคชัน Android Application Programming Interface (API) ของ Android คือชุดอินเทอร์เฟซแพลตฟอร์ม Android ที่แสดงต่อแอปพลิเคชันที่ทำงานในสภาพแวดล้อมรันไทม์ที่มีการจัดการ การใช้งานอุปกรณ์ต้องระบุการใช้งานที่สมบูรณ์ ซึ่งรวมถึงลักษณะการทำงานที่บันทึกไว้ทั้งหมดของ API ที่บันทึกไว้ซึ่ง Android SDK [แหล่งข้อมูล, 6] แสดง หรือ API ที่มีเครื่องหมาย "@SystemApi" ในซอร์สโค้ด Android ต้นทาง
การติดตั้งใช้งานอุปกรณ์ต้องไม่ละเว้น API ที่มีการจัดการ เปลี่ยนแปลงอินเทอร์เฟซหรือลายเซ็น API เบี่ยงเบนจากลักษณะการทำงานที่ระบุไว้ หรือรวมการดำเนินการที่ไม่มีผล ยกเว้นในกรณีที่คำจำกัดความความเข้ากันได้นี้อนุญาตไว้โดยเฉพาะ
คําจํากัดความความเข้ากันได้นี้อนุญาตให้อุปกรณ์ละเว้นการใช้ API ของ Android สำหรับฮาร์ดแวร์บางประเภท ในกรณีเช่นนี้ API ต้องยังคงอยู่และทํางานอย่างสมเหตุสมผล โปรดดูข้อกำหนดเฉพาะสำหรับสถานการณ์นี้ในส่วนที่ 7
3.2 ความเข้ากันได้แบบ Soft API
นอกจาก API ที่มีการจัดการจากส่วนที่ 3.1 แล้ว Android ยังมี API "แบบซอฟต์" ที่สำคัญซึ่งใช้ได้เฉพาะในรันไทม์ในรูปแบบของสิ่งต่างๆ เช่น Intent, สิทธิ์ และลักษณะที่คล้ายกันของแอปพลิเคชัน Android ซึ่งไม่สามารถบังคับใช้ขณะคอมไพล์แอปพลิเคชันได้
3.2.1. สิทธิ์
ผู้ติดตั้งใช้งานอุปกรณ์ต้องรองรับและบังคับใช้ค่าคงที่ของสิทธิ์ทั้งหมดตามที่ระบุไว้ในหน้าข้อมูลอ้างอิงเกี่ยวกับสิทธิ์ [แหล่งข้อมูล, 7] โปรดทราบว่าส่วนที่ 9 แสดงข้อกำหนดเพิ่มเติมที่เกี่ยวข้องกับรูปแบบความปลอดภัยของ Android
3.2.2. พารามิเตอร์การสร้าง
API ของ Android มีค่าคงที่หลายรายการในคลาส android.os.Build [ทรัพยากร, 8] ที่มีไว้เพื่ออธิบายอุปกรณ์ปัจจุบัน ตารางด้านล่างมีข้อจํากัดเพิ่มเติมเกี่ยวกับรูปแบบของค่าเหล่านี้ ซึ่งการติดตั้งใช้งานอุปกรณ์ต้องเป็นไปตามข้อจํากัดดังกล่าวเพื่อให้ค่าที่สอดคล้องกันและสื่อความหมายในการติดตั้งใช้งานอุปกรณ์
พารามิเตอร์ | รายละเอียด |
---|---|
VERSION.RELEASE | เวอร์ชันของระบบ Android ที่ใช้งานอยู่ในปัจจุบันในรูปแบบที่มนุษย์อ่านได้ ช่องนี้ต้องมีค่าสตริงอย่างใดอย่างหนึ่งที่ระบุไว้ใน [ทรัพยากร, 9] |
VERSION.SDK | เวอร์ชันของระบบ Android ที่ใช้งานอยู่ในปัจจุบันในรูปแบบที่โค้ดแอปพลิเคชันของบุคคลที่สามเข้าถึงได้ สำหรับ Android 6.0 ช่องนี้ต้องมีค่าจำนวนเต็ม 23 |
VERSION.SDK_INT | เวอร์ชันของระบบ Android ที่ใช้งานอยู่ในปัจจุบันในรูปแบบที่โค้ดแอปพลิเคชันของบุคคลที่สามเข้าถึงได้ สำหรับ Android 6.0 ช่องนี้ต้องมีค่าจำนวนเต็ม 23 |
VERSION.INCREMENTAL | ค่าที่ผู้ติดตั้งใช้งานอุปกรณ์เลือกเพื่อระบุบิลด์ที่เฉพาะเจาะจงของระบบ Android ที่ใช้งานอยู่ในปัจจุบันในรูปแบบที่มนุษย์อ่านได้ ห้ามนำค่านี้ไปใช้กับบิลด์อื่นที่พร้อมให้บริการแก่ผู้ใช้ปลายทาง การใช้งานทั่วไปของช่องนี้คือเพื่อระบุหมายเลขบิลด์หรือตัวระบุการเปลี่ยนแปลงในระบบควบคุมแหล่งที่มาที่ใช้สร้างบิลด์ ไม่มีข้อกำหนดเกี่ยวกับรูปแบบที่เจาะจงของช่องนี้ ยกเว้นว่าต้องไม่มีค่าเป็น Null หรือสตริงว่าง ("") |
กระดาน | ค่าที่นักติดตั้งใช้งานอุปกรณ์เลือกเพื่อระบุฮาร์ดแวร์ภายในที่เฉพาะเจาะจงซึ่งอุปกรณ์ใช้ในรูปแบบที่มนุษย์อ่านได้ การใช้ช่องนี้ที่เป็นไปได้คือการระบุการแก้ไขที่เฉพาะเจาะจงของแผงวงจรที่จ่ายไฟให้อุปกรณ์ ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII 7 บิตและตรงกับนิพจน์ทั่วไป "^[a-zA-Z0-9_-]+$" |
แบรนด์ | ค่าที่แสดงถึงชื่อแบรนด์ที่เชื่อมโยงกับอุปกรณ์ตามที่ผู้ใช้ปลายทางทราบ ต้องเป็นรูปแบบที่มนุษย์อ่านได้ และควรแสดงถึงผู้ผลิตอุปกรณ์หรือแบรนด์ของบริษัทที่ทําการตลาดอุปกรณ์ ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII 7 บิตได้และตรงกับนิพจน์ทั่วไป "^[a-zA-Z0-9_-]+$" |
SUPPORTED_ABIS | ชื่อชุดคำสั่ง (ประเภท CPU + รูปแบบ ABI) ของโค้ดเนทีฟ โปรดดูส่วนที่ 3.3 ความเข้ากันได้ของ Native API |
SUPPORTED_32_BIT_ABIS | ชื่อชุดคำสั่ง (ประเภท CPU + รูปแบบ ABI) ของโค้ดเนทีฟ โปรดดูส่วนที่ 3.3 ความเข้ากันได้ของ Native API |
SUPPORTED_64_BIT_ABIS | ชื่อชุดคำสั่งที่ 2 (ประเภท CPU + รูปแบบ ABI) ของโค้ดเนทีฟ โปรดดูส่วนที่ 3.3 ความเข้ากันได้ของ Native API |
CPU_ABI | ชื่อชุดคำสั่ง (ประเภท CPU + รูปแบบ ABI) ของโค้ดเนทีฟ โปรดดูส่วนที่ 3.3 ความเข้ากันได้ของ Native API |
CPU_ABI2 | ชื่อชุดคำสั่งที่ 2 (ประเภท CPU + รูปแบบ ABI) ของโค้ดเนทีฟ โปรดดูส่วนที่ 3.3 ความเข้ากันได้ของ Native API |
อุปกรณ์ | ค่าที่ผู้ติดตั้งใช้งานอุปกรณ์เลือกซึ่งมีชื่อการพัฒนาหรือชื่อรหัสที่ระบุการกำหนดค่าของฟีเจอร์ฮาร์ดแวร์และการออกแบบอุตสาหกรรมของอุปกรณ์ ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII 7 บิตได้ และตรงกับนิพจน์ทั่วไป "^[a-zA-Z0-9_-]+$" |
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 หรือสตริงว่าง ("") |
MODEL | ค่าที่ผู้ติดตั้งใช้งานอุปกรณ์เลือกซึ่งมีชื่อของอุปกรณ์ตามที่ผู้ใช้ปลายทางรู้จัก ชื่อนี้ควรเป็นชื่อเดียวกับที่อุปกรณ์ใช้ในการทําการตลาดและขายแก่ผู้ใช้ปลายทาง ไม่มีข้อกำหนดเฉพาะเกี่ยวกับรูปแบบของฟิลด์นี้ ยกเว้นว่าต้องไม่มีค่าเป็น Null หรือสตริงว่าง ("") |
ผลิตภัณฑ์ | ค่าที่ผู้ติดตั้งใช้งานอุปกรณ์เลือกซึ่งมีชื่อการพัฒนาหรือชื่อรหัสของผลิตภัณฑ์ที่เฉพาะเจาะจง (SKU) และต้องไม่ซ้ำกันภายในแบรนด์เดียวกัน ต้องเป็นชื่อที่มนุษย์อ่านได้ แต่ไม่จำเป็นต้องมีไว้เพื่อให้ผู้ใช้ปลายทางดู ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII 7 บิตได้และตรงกับนิพจน์ทั่วไป "^[a-zA-Z0-9_-]+$" |
SERIAL | หมายเลขซีเรียลของฮาร์ดแวร์ ซึ่งต้องพร้อมใช้งานและไม่ซ้ำกันสำหรับอุปกรณ์ที่มีรุ่นและผู้ผลิตเดียวกัน ค่าของช่องนี้ต้องเข้ารหัสเป็น ASCII 7 บิตและตรงกับนิพจน์ทั่วไป "^([a-zA-Z0-9]{6,20})$" |
แท็ก | รายการแท็กที่คั่นด้วยคอมมาซึ่งผู้ติดตั้งใช้งานอุปกรณ์เลือกไว้เพื่อแยกความแตกต่างของบิลด์เพิ่มเติม ช่องนี้ต้องมีค่าใดค่าหนึ่งที่สอดคล้องกับการกำหนดค่า Signing ของแพลตฟอร์ม Android ทั่วไป 3 รายการ ได้แก่ release-keys, dev-keys, test-keys |
เวลา | ค่าที่แสดงการประทับเวลาที่บิลด์เกิดขึ้น |
ประเภท | ค่าที่ผู้ติดตั้งใช้งานอุปกรณ์เลือกซึ่งระบุการกำหนดค่ารันไทม์ของบิลด์ ช่องนี้ต้องมีค่าใดค่าหนึ่งซึ่งสอดคล้องกับการกำหนดค่ารันไทม์ Android ทั่วไป 3 รูปแบบ ได้แก่ user, userdebug หรือ eng |
ผู้ใช้ | ชื่อหรือรหัสผู้ใช้ของผู้ใช้ (หรือผู้ใช้อัตโนมัติ) ที่สร้างบิลด์ ไม่มีข้อกำหนดเกี่ยวกับรูปแบบที่เฉพาะเจาะจงของฟิลด์นี้ ยกเว้นว่าต้องไม่มีค่าเป็น Null หรือสตริงว่าง ("") |
SECURITY_PATCH | ค่าที่ระบุระดับแพตช์ความปลอดภัยของบิลด์ และต้องระบุว่าบิลด์มีแพตช์ความปลอดภัยทั้งหมดที่เผยแพร่ผ่านกระดานข่าวสารความปลอดภัยสาธารณะของ Android โดยต้องเป็นรูปแบบ [YYYY-MM-DD] ซึ่งตรงกับสตริงระดับแพตช์ความปลอดภัยของ Android รายการใดรายการหนึ่งของ กระดานข่าวสารความปลอดภัยแบบสาธารณะ เช่น "2015-11-01" |
BASE_OS | ค่าที่แสดงพารามิเตอร์ FINGERPRINT ของบิวด์ที่เหมือนกันกับบิวด์นี้ ยกเว้นแพตช์ที่ระบุไว้ในกระดานข่าวสารความปลอดภัยสาธารณะของ Android และต้องรายงานค่าที่ถูกต้อง และหากไม่มีบิลด์ดังกล่าว ให้รายงานสตริงว่าง ("") |
3.2.3. ความเข้ากันได้ของ Intent
การติดตั้งใช้งานอุปกรณ์ต้องเป็นไปตามระบบ Intent แบบหลวมๆ ของ Android ตามที่อธิบายไว้ในส่วนด้านล่าง "ปฏิบัติตาม" หมายความว่าผู้ติดตั้งใช้งานอุปกรณ์ต้องระบุกิจกรรมหรือบริการ Android ที่ระบุตัวกรอง Intent ที่ตรงกันซึ่งเชื่อมโยงและใช้งานลักษณะการทำงานที่ถูกต้องสำหรับรูปแบบ Intent ที่ระบุแต่ละรายการ
3.2.3.1. Intent ของแอปพลิเคชันหลัก
Intent ของ Android ช่วยให้คอมโพเนนต์แอปพลิเคชันขอฟังก์ชันการทำงานจากคอมโพเนนต์ Android อื่นๆ ได้ โปรเจ็กต์อัปสตรีมของ Android มีรายการแอปพลิเคชันที่ถือว่าเป็นแอปพลิเคชันหลักของ Android ซึ่งใช้รูปแบบ Intent หลายรูปแบบเพื่อดำเนินการทั่วไป แอปพลิเคชันหลักของ Android มีดังนี้
- นาฬิกาตั้งโต๊ะ
- เบราว์เซอร์
- ปฏิทิน
- รายชื่อติดต่อ
- แกลเลอรี
- GlobalSearch
- ปืนยิงลูกระเบิด
- เพลง
- การตั้งค่า
การติดตั้งใช้งานในอุปกรณ์ควรมีแอปพลิเคชัน Android หลักตามความเหมาะสม แต่ต้องมีคอมโพเนนต์ที่ใช้รูปแบบ Intent เดียวกันซึ่งกำหนดโดยคอมโพเนนต์ Activity หรือ Service "สาธารณะ" ทั้งหมดของแอปพลิเคชัน Android หลักเหล่านี้ โปรดทราบว่าระบบจะถือว่าคอมโพเนนต์กิจกรรมหรือบริการเป็น "สาธารณะ" เมื่อไม่มีแอตทริบิวต์ android:exported หรือมีค่าเป็น "จริง"
3.2.3.2. การแก้ไข Intent
เนื่องจาก Android เป็นแพลตฟอร์มที่ขยายได้ การติดตั้งใช้งานอุปกรณ์ต้องอนุญาตให้แอปพลิเคชันของบุคคลที่สามลบล้างรูปแบบ Intent แต่ละรูปแบบที่อ้างอิงในส่วนที่ 3.2.3.1 การใช้งานโอเพนซอร์สของ Android เวอร์ชันอัปสตรีมอนุญาตให้ดำเนินการนี้โดยค่าเริ่มต้น ผู้ใช้งานอุปกรณ์ต้องไม่แนบสิทธิ์พิเศษไว้กับการใช้รูปแบบ Intent เหล่านี้ของแอปพลิเคชันระบบ หรือป้องกันไม่ให้แอปพลิเคชันของบุคคลที่สามเชื่อมโยงและควบคุมรูปแบบเหล่านี้ ข้อห้ามนี้รวมถึงแต่ไม่จำกัดเพียงการปิดใช้อินเทอร์เฟซผู้ใช้ "เครื่องมือเลือก" ที่อนุญาตให้ผู้ใช้เลือกระหว่างแอปพลิเคชันหลายรายการที่จัดการรูปแบบ Intent เดียวกันทั้งหมด
การติดตั้งใช้งานอุปกรณ์ต้องมีอินเทอร์เฟซผู้ใช้เพื่อให้ผู้ใช้แก้ไขกิจกรรมเริ่มต้นสำหรับ Intent ได้
อย่างไรก็ตาม การติดตั้งใช้งานอุปกรณ์อาจระบุกิจกรรมเริ่มต้นสำหรับรูปแบบ URI ที่เฉพาะเจาะจง (เช่น http://play.google.com) เมื่อกิจกรรมเริ่มต้นระบุแอตทริบิวต์ที่เฉพาะเจาะจงมากขึ้นสำหรับ URI ของข้อมูล ตัวอย่างเช่น รูปแบบตัวกรอง Intent ที่ระบุ URI ข้อมูล "http://www.android.com" จะเฉพาะเจาะจงกว่ารูปแบบ Intent หลักของเบราว์เซอร์สําหรับ "http://"
Android ยังมีกลไกสําหรับแอปของบุคคลที่สามในการประกาศลักษณะการลิงก์แอปเริ่มต้นที่เชื่อถือได้สําหรับ Intent URI ของเว็บบางประเภท [แหล่งข้อมูล, 140] เมื่อมีการกําหนดประกาศที่เชื่อถือได้ดังกล่าวในรูปแบบตัวกรอง Intent ของแอป การใช้งานอุปกรณ์จะมีลักษณะดังนี้
- ต้องพยายามตรวจสอบตัวกรอง Intent โดยทำตามขั้นตอนการตรวจสอบที่ระบุไว้ในข้อกำหนดของลิงก์เนื้อหาดิจิทัล [แหล่งข้อมูล, 141] ตามที่ Package Manager ในโปรเจ็กต์โอเพนซอร์ส Android ต้นทางนำมาใช้
- ต้องพยายามตรวจสอบตัวกรอง Intent ระหว่างการติดตั้งแอปพลิเคชัน และตั้งค่าตัวกรอง Intent ของ UIR ทั้งหมดที่ตรวจสอบเรียบร้อยแล้วเป็นตัวจัดการแอปเริ่มต้นสำหรับ UIR ของตน
- อาจตั้งค่าตัวกรอง Intent ของ URI ที่เฉพาะเจาะจงเป็นตัวจัดการแอปเริ่มต้นสำหรับ URI ของแอปนั้นๆ หากได้รับการยืนยันเรียบร้อยแล้ว แต่ตัวกรอง URI อื่นๆ ที่เป็นไปได้ไม่ได้รับการยืนยัน หากการใช้งานอุปกรณ์ทําเช่นนี้ อุปกรณ์ต้องให้ผู้ใช้ลบล้างรูปแบบต่อ URI ที่เหมาะสมในเมนูการตั้งค่า
- ต้องมีการควบคุม App Link ต่อแอปให้แก่ผู้ใช้ในการตั้งค่า ดังนี้
- ผู้ใช้ต้องสามารถลบล้างลักษณะการทํางานของ App Link เริ่มต้นโดยรวมเพื่อให้แอปเปิดอยู่เสมอ ถามเสมอ หรือไม่เคยเปิด ซึ่งต้องมีผลกับตัวกรอง Intent ของ URI ทั้งหมดที่ตรงตามเกณฑ์อย่างเท่าเทียมกัน
- ผู้ใช้ต้องดูรายการตัวกรอง Intent ของ URI ที่เป็นไปได้ได้
- การติดตั้งใช้งานอุปกรณ์อาจช่วยให้ผู้ใช้สามารถลบล้างตัวกรอง Intent ของ URI ที่เป็นไปได้ที่ยืนยันเรียบร้อยแล้วตามแต่ละตัวกรอง Intent
- การติดตั้งใช้งานอุปกรณ์ต้องให้สิทธิ์ผู้ใช้ในการดูและลบล้างตัวกรอง Intent ของ URI ที่เป็นไปได้บางรายการ หากการติดตั้งใช้งานอุปกรณ์ทําให้ตัวกรอง Intent ของ URI ที่เป็นไปได้บางรายการยืนยันสําเร็จ ขณะที่ตัวกรองอื่นๆ ยืนยันไม่สําเร็จ
3.2.3.3. เนมสเปซของ Intent
การติดตั้งใช้งานอุปกรณ์ต้องไม่มีคอมโพเนนต์ Android ที่รองรับ Intent ใหม่หรือรูปแบบ Intent แบบออกอากาศโดยใช้สตริงคีย์ ACTION, CATEGORY หรืออื่นๆ ในเนมสเปซ android.* หรือ com.android.* ผู้ติดตั้งใช้งานอุปกรณ์ต้องไม่รวมคอมโพเนนต์ Android ใดๆ ที่รองรับรูปแบบ Intent ใหม่หรือรูปแบบ Intent การออกอากาศโดยใช้สตริงคีย์ ACTION, CATEGORY หรืออื่นๆ ในสเปซแพ็กเกจที่เป็นขององค์กรอื่น ผู้ติดตั้งใช้งานอุปกรณ์ต้องไม่เปลี่ยนแปลงหรือขยายรูปแบบ Intent ที่แอปหลักที่ระบุไว้ในส่วนที่ 3.2.3.1 ใช้ การติดตั้งใช้งานอุปกรณ์อาจรวมถึงรูปแบบ Intent โดยใช้เนมสเปซที่เชื่อมโยงกับองค์กรของตนเองอย่างชัดเจน ข้อห้ามนี้คล้ายกับข้อห้ามที่ระบุไว้สำหรับชั้นเรียนภาษา Java ในส่วนที่ 3.6
3.2.3.4. เจตนาการออกอากาศ
แอปพลิเคชันของบุคคลที่สามอาศัยแพลตฟอร์มนี้เพื่อเผยแพร่ Intent บางรายการเพื่อแจ้งให้ทราบถึงการเปลี่ยนแปลงในสภาพแวดล้อมฮาร์ดแวร์หรือซอฟต์แวร์ อุปกรณ์ที่ใช้ร่วมกันได้กับ Android จะต้องออกอากาศ Intent การออกอากาศสาธารณะเพื่อตอบสนองต่อเหตุการณ์ของระบบที่เหมาะสม อธิบาย Intent แบบออกอากาศไว้ในเอกสารประกอบ SDK
3.2.3.5. การตั้งค่าแอปเริ่มต้น
Android มีการตั้งค่าที่ช่วยให้ผู้ใช้เลือกแอปพลิเคชันเริ่มต้นได้ง่ายๆ เช่น สําหรับหน้าจอหลักหรือ SMS การติดตั้งใช้งานอุปกรณ์ต้องระบุเมนูการตั้งค่าที่คล้ายกันและเข้ากันได้กับรูปแบบตัวกรอง Intent และเมธอด API ที่อธิบายไว้ในเอกสารประกอบ SDK ดังต่อไปนี้
การติดตั้งใช้งานอุปกรณ์
- ต้องปฏิบัติตาม Intent android.settings.HOME_SETTINGS เพื่อแสดงเมนูการตั้งค่าแอปเริ่มต้นสำหรับหน้าจอหลัก หากการติดตั้งใช้งานอุปกรณ์รายงาน android.software.home_screen [แหล่งข้อมูล, 10]
- ต้องมีเมนูการตั้งค่าที่จะเรียกใช้ Intent android.provider.Telephony.ACTION_CHANGE_DEFAULT เพื่อแสดงกล่องโต้ตอบสำหรับเปลี่ยนแอปพลิเคชัน SMS เริ่มต้น หากการติดตั้งใช้งานอุปกรณ์รายงาน android.hardware.telephony [แหล่งข้อมูล, 11]
- ต้องปฏิบัติตาม Intent android.settings.NFC_PAYMENT_SETTINGS เพื่อแสดงเมนูการตั้งค่าแอปเริ่มต้นสำหรับการแตะและจ่าย หากการติดตั้งใช้งานอุปกรณ์รายงาน android.hardware.nfc.hce [แหล่งข้อมูล, 10]
3.3 ความเข้ากันได้ของ API เดิม
3.3.1. อินเทอร์เฟซแบบไบนารีของแอปพลิเคชัน
บิตโค้ด Dalvik ที่มีการจัดการสามารถเรียกใช้โค้ดเนทีฟที่ระบุไว้ในไฟล์ .apk ของแอปพลิเคชันเป็นไฟล์ ELF .so ที่คอมไพล์มาสำหรับสถาปัตยกรรมฮาร์ดแวร์ของอุปกรณ์ที่เหมาะสม เนื่องจากโค้ดเนทีฟมีความเกี่ยวข้องกับเทคโนโลยีโปรเซสเซอร์พื้นฐานเป็นอย่างมาก Android จึงกำหนดอินเทอร์เฟซแบบไบนารีของแอปพลิเคชัน (ABI) หลายรายการใน Android NDK การติดตั้งใช้งานอุปกรณ์ต้องเข้ากันได้กับ ABI ที่กําหนดไว้อย่างน้อย 1 รายการ และต้องเข้ากันได้กับ Android NDK ดังที่ระบุไว้ด้านล่าง
หากการติดตั้งใช้งานอุปกรณ์รองรับ ABI ของ Android การดำเนินการต่อไปนี้จะเกิดขึ้น
- ต้องรองรับโค้ดที่ทำงานในสภาพแวดล้อมที่มีการจัดการเพื่อเรียกใช้โค้ดเนทีฟโดยใช้นิพจน์ความหมาย Java Native Interface (JNI) มาตรฐาน
- ต้องเข้ากันได้กับซอร์สโค้ด (กล่าวคือ เข้ากันได้กับส่วนหัว) และเข้ากันได้กับไบนารี (สำหรับ ABI) กับไลบรารีที่จำเป็นแต่ละรายการในรายการด้านล่าง
- ต้องรองรับ ABI 32 บิตที่เทียบเท่าหากรองรับ ABI 64 บิต
- ต้องรายงาน 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 ที่บันทึกไว้และอธิบายไว้ในเอกสารประกอบการจัดการ ABI ของ Android NDK เวอร์ชันล่าสุด [แหล่งข้อมูล, 12] และต้องมีส่วนขยายการรองรับ SIMD ขั้นสูง (หรือที่เรียกว่า NEON) [แหล่งข้อมูล, 13]
- ควรสร้างโดยใช้ซอร์สโค้ดและไฟล์ส่วนหัวที่มีอยู่ในโครงการโอเพนซอร์ส Android ต้นทาง
API โค้ดเนทีฟต่อไปนี้ต้องพร้อมใช้งานสำหรับแอปที่มีโค้ดเนทีฟ
- libc (คลัง C)
- libm (คลังคณิตศาสตร์)
- รองรับ C++ เพียงเล็กน้อย
- อินเทอร์เฟซ JNI
- liblog (การบันทึกของ Android)
- libz (การบีบอัด Zlib)
- libdl (ตัวลิงก์แบบไดนามิก)
- libGLESv1_CM.so (OpenGL ES 1.x)
- libGLESv2.so (OpenGL ES 2.0)
- libGLESv3.so (OpenGL ES 3.x)
- libEGL.so (การจัดการพื้นผิว OpenGL ดั้งเดิม)
- libjnigraphics.so
- libOpenSLES.so (การรองรับเสียง OpenSL ES 1.0.1)
- libOpenMAXAL.so (รองรับ OpenMAX AL 1.0.1)
- libandroid.so (การรองรับกิจกรรม Android ดั้งเดิม)
- libmediandk.so (รองรับ API สื่อแบบเนทีฟ)
- การรองรับ OpenGL ตามที่อธิบายไว้ด้านล่าง
โปรดทราบว่า Android NDK รุ่นต่อๆ ไปอาจรองรับ ABI เพิ่มเติม หากการติดตั้งใช้งานอุปกรณ์ใช้งานร่วมกับ ABI ที่กําหนดไว้ล่วงหน้าไม่ได้ อุปกรณ์ต้องไม่รายงานการรองรับ ABI ใดๆ ทั้งสิ้น
โปรดทราบว่าการติดตั้งใช้งานอุปกรณ์ต้องรวม libGLESv3.so และต้องมีการลิงก์สัญลักษณ์ (Symbolic Link) กับ libGLESv2.so ซึ่งในทางกลับกัน จะต้องส่งออกสัญลักษณ์ฟังก์ชัน OpenGL ES 3.1 และแพ็กเกจส่วนขยาย Android [ทรัพยากร, 14] ทั้งหมดตามที่ระบุไว้ในรุ่น NDK android-21 แม้ว่าจะต้องมีสัญลักษณ์ทั้งหมด แต่จะต้องใช้งานเฉพาะฟังก์ชันที่เกี่ยวข้องสำหรับเวอร์ชันและส่วนขยาย OpenGL ES ที่อุปกรณ์รองรับเท่านั้น
การใช้งานอุปกรณ์ หากมีไลบรารีเนทีฟชื่อ libvulkan.so ต้องส่งออกสัญลักษณ์ฟังก์ชันและระบุการใช้งาน Vulkan 1.0 API รวมถึงส่วนขยาย VK_KHR_surface, VK_KHR_swapchain และ VK_KHR_android_surface ตามที่กลุ่ม Khronos กำหนดไว้ และผ่านการทดสอบการปฏิบัติตามข้อกำหนดของ Khronos
ความเข้ากันได้ของโค้ดที่มาพร้อมเครื่องเป็นเรื่องยาก ด้วยเหตุนี้ เราจึงขอแนะนำอย่างยิ่งให้ผู้ติดตั้งใช้งานอุปกรณ์ใช้การติดตั้งใช้งานไลบรารีที่ระบุไว้ข้างต้นจากโปรเจ็กต์โอเพนซอร์ส Android ที่เป็น upstream
3.3.2. ความเข้ากันได้ของโค้ดเนทีฟ ARM แบบ 32 บิต
สถาปัตยกรรม ARMv8 เลิกใช้งานการดำเนินการของ CPU หลายรายการ รวมถึงการดำเนินการบางอย่างที่ใช้ในโค้ดเนทีฟที่มีอยู่ ในอุปกรณ์ ARM 64 บิต การดำเนินการต่อไปนี้ซึ่งเลิกใช้งานแล้วต้องยังคงพร้อมใช้งานสำหรับโค้ดเนทีฟ ARM แบบ 32 บิต ไม่ว่าจะผ่านการรองรับ CPU เนทีฟหรือการจําลองซอฟต์แวร์
- วิธีการ SWP และ SWPB
- คำสั่ง SETEND
- การดำเนินการกับสิ่งกีดขวาง CP15ISB, CP15DSB และ CP15DMB
NDK ของ Android เวอร์ชันเดิมใช้ /proc/cpuinfo เพื่อค้นหาฟีเจอร์ของ CPU จากโค้ดเนทีฟ ARM 32 บิต อุปกรณ์ต้องใส่บรรทัดต่อไปนี้ใน /proc/cpuinfo เมื่อแอปพลิเคชัน ARM 32 บิตอ่าน เพื่อใช้ร่วมกับแอปพลิเคชันที่สร้างขึ้นโดยใช้ NDK นี้
- "ฟีเจอร์: " ตามด้วยรายการฟีเจอร์ CPU ARMv7 ที่ไม่บังคับซึ่งอุปกรณ์รองรับ
- "สถาปัตยกรรม CPU: " ตามด้วยจำนวนเต็มซึ่งอธิบายถึงสถาปัตยกรรม ARM ที่รองรับสูงสุดของอุปกรณ์ (เช่น "8" สำหรับอุปกรณ์ ARMv8)
ข้อกำหนดเหล่านี้จะมีผลเฉพาะเมื่อแอปพลิเคชัน ARM แบบ 32 บิตอ่าน /proc/cpuinfo เท่านั้น อุปกรณ์ไม่ควรเปลี่ยนแปลง /proc/cpuinfo เมื่อแอปพลิเคชัน ARM 64 บิตหรือแอปพลิเคชันที่ไม่ใช้ ARM อ่าน
3.4. ความเข้ากันได้ของเว็บ
3.4.1. ความเข้ากันได้ของ WebView
อุปกรณ์ Android Watch อาจใช้ แต่การติดตั้งใช้งานอุปกรณ์อื่นๆ ทั้งหมดต้องระบุการใช้งาน android.webkit.Webview API อย่างสมบูรณ์
คุณต้องรายงานฟีเจอร์แพลตฟอร์ม android.software.webview ในอุปกรณ์ที่มีการติดตั้งใช้งาน android.webkit.WebView API อย่างสมบูรณ์ และห้ามรายงานในอุปกรณ์ที่ไม่มีการติดตั้งใช้งาน API อย่างสมบูรณ์ การใช้งานโอเพนซอร์สของ Android ใช้โค้ดจากโปรเจ็กต์ Chromium เพื่อใช้งาน android.webkit.WebView [แหล่งข้อมูล, 15] เนื่องจากการพัฒนาชุดทดสอบที่ครอบคลุมสำหรับระบบการแสดงผลเว็บนั้นไม่สามารถทำได้ ผู้ติดตั้งใช้งานอุปกรณ์จึงต้องใช้ Chromium รุ่นที่อัปเดตจาก upstream ที่เจาะจงในการใช้งาน WebView ดังนี้
- การติดตั้งใช้งาน android.webkit.WebView ของอุปกรณ์ต้องอิงตาม Chromium ที่สร้างขึ้นจากโปรเจ็กต์โอเพนซอร์ส Android ต้นทางสำหรับ Android 6.0 บิลด์นี้รวมชุดการแก้ไขฟังก์ชันการทำงานและความปลอดภัยที่เฉพาะเจาะจงสำหรับ WebView [แหล่งข้อมูล, 16]
- สตริง User Agent ที่ WebView รายงานต้องเป็นรูปแบบนี้
Mozilla/5.0 (Linux; Android $(VERSION); $(MODEL) Build/$(BUILD); wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 $(CHROMIUM_VER) Mobile Safari/537.36
- ค่าของสตริง $(VERSION) ต้องเป็นค่าเดียวกับค่าสำหรับ android.os.Build.VERSION.RELEASE
- ค่าของสตริง $(MODEL) ต้องเหมือนกับค่าสำหรับ android.os.Build.MODEL
- ค่าของสตริง $(BUILD) ต้องเหมือนกับค่าสำหรับ android.os.Build.ID
- ค่าของสตริง $(CHROMIUM_VER) ต้องเป็นเวอร์ชัน Chromium ในโปรเจ็กต์โอเพนซอร์ส Android ต้นทาง
- การติดตั้งใช้งานอุปกรณ์อาจไม่ใส่ Mobile ในสตริง User Agent
คอมโพเนนต์ WebView ควรรองรับฟีเจอร์ HTML5 ให้ได้มากที่สุด และหากรองรับฟีเจอร์ดังกล่าว ก็ควรเป็นไปตามข้อกำหนด HTML5 [แหล่งข้อมูล, 17]
3.4.2. ความเข้ากันได้กับเบราว์เซอร์
การติดตั้งใช้งาน Android Television, Watch และ Android Automotive อาจไม่ระบุแอปพลิเคชันเบราว์เซอร์ แต่ต้องรองรับรูปแบบ Intent สาธารณะตามที่อธิบายไว้ในส่วนที่ 3.2.3.1 การติดตั้งใช้งานอุปกรณ์ประเภทอื่นๆ ทั้งหมดต้องมีแอปพลิเคชันเบราว์เซอร์แบบสแตนด์อโลนสำหรับการท่องเว็บของผู้ใช้ทั่วไป
เบราว์เซอร์แบบสแตนด์อโลนอาจอิงตามเทคโนโลยีเบราว์เซอร์อื่นที่ไม่ใช่ WebKit อย่างไรก็ตาม แม้ว่าจะใช้แอปพลิเคชันเบราว์เซอร์อื่น แต่คอมโพเนนต์ android.webkit.WebView ที่ให้บริการแก่แอปพลิเคชันของบุคคลที่สามต้องอิงตาม WebKit ตามที่อธิบายไว้ในส่วนที่ 3.4.1
การติดตั้งใช้งานอาจส่งสตริง User Agent ที่กําหนดเองในแอปพลิเคชันเบราว์เซอร์แบบสแตนด์อโลน
แอปพลิเคชันเบราว์เซอร์แบบสแตนด์อโลน (ไม่ว่าจะอิงตามแอปพลิเคชันเบราว์เซอร์ WebKit เวอร์ชันอัปสตรีมหรือแอปพลิเคชันทดแทนของบุคคลที่สาม) ควรรองรับ HTML5 [แหล่งข้อมูล 17] ให้ได้มากที่สุด การติดตั้งใช้งานอุปกรณ์ต้องรองรับ API ต่อไปนี้อย่างน้อย 1 รายการ ซึ่งเชื่อมโยงกับ HTML5
- แคชของแอปพลิเคชัน/การดำเนินการแบบออฟไลน์ [แหล่งข้อมูล, 18]
- แท็ก <video> [แหล่งข้อมูล, 19]
- geolocation [แหล่งข้อมูล, 20]
นอกจากนี้ การติดตั้งใช้งานอุปกรณ์ต้องรองรับ Webstorage API ของ HTML5/W3C [แหล่งข้อมูล, 21] และต้องรองรับ IndexedDB API ของ HTML5/W3C [แหล่งข้อมูล, 22] โปรดทราบว่าเนื่องจากองค์กรมาตรฐานการพัฒนาเว็บกําลังเปลี่ยนไปใช้ IndexedDB แทน Web Storage คาดว่า IndexedDB จะกลายเป็นคอมโพเนนต์ที่จําเป็นใน Android เวอร์ชันในอนาคต
3.5 ความเข้ากันได้ของลักษณะการทํางานของ API
ลักษณะการทํางานของ API แต่ละประเภท (ที่มีการจัดการ ซอฟต์ เนทีฟ และเว็บ) ต้องสอดคล้องกับการใช้งานที่ต้องการของโปรเจ็กต์โอเพนซอร์ส Android เวอร์ชันที่อัปเดตจากเวอร์ชันหลัก [แหล่งข้อมูล 2] ตัวอย่างความเข้ากันได้ที่เฉพาะเจาะจงมีดังนี้
- อุปกรณ์ต้องไม่เปลี่ยนแปลงลักษณะการทํางานหรือความหมายของ Intent มาตรฐาน
- อุปกรณ์ต้องไม่เปลี่ยนแปลงวงจรหรือความหมายของวงจรของคอมโพเนนต์ระบบบางประเภท (เช่น บริการ กิจกรรม ContentProvider ฯลฯ)
- อุปกรณ์ต้องไม่เปลี่ยนความหมายของสิทธิ์มาตรฐาน
โปรดทราบว่ายังมีกรณีอื่นๆ นอกเหนือจากรายการด้านบน ชุดเครื่องมือทดสอบความเข้ากันได้ (CTS) จะทดสอบแพลตฟอร์มส่วนใหญ่เพื่อดูความเข้ากันได้ของลักษณะการทำงาน แต่ไม่ได้ทดสอบทั้งหมด ผู้ติดตั้งใช้งานมีหน้าที่รับผิดชอบในการตรวจสอบความเข้ากันได้ของลักษณะการทำงานกับโครงการโอเพนซอร์ส Android ด้วยเหตุนี้ ผู้ติดตั้งใช้งานอุปกรณ์จึงควรใช้ซอร์สโค้ดที่มีให้ผ่านโครงการโอเพนซอร์ส Android หากเป็นไปได้ แทนที่จะติดตั้งใช้งานส่วนสำคัญของระบบอีกครั้ง
3.6 เนมสเปซของ API
Android เป็นไปตามรูปแบบเนมสเปซของแพ็กเกจและคลาสที่ภาษาโปรแกรม Java กำหนด ผู้ติดตั้งใช้งานอุปกรณ์ต้องไม่ทำการแก้ไขที่ไม่ได้รับอนุญาต (ดูด้านล่าง) ในเนมสเปซของแพ็กเกจต่อไปนี้เพื่อให้มั่นใจว่าแอปพลิเคชันของบุคคลที่สามจะใช้งานร่วมกันได้
- java.*
- javax.*
- sun.*
- android.*
- com.android.*
การแก้ไขที่ไม่อนุญาต ได้แก่
- การใช้งานอุปกรณ์ต้องไม่แก้ไข API ที่เผยแพร่ต่อสาธารณะบนแพลตฟอร์ม Android โดยการเปลี่ยนลายเซ็นเมธอดหรือคลาส หรือการนำคลาสหรือช่องคลาสออก
- ผู้ติดตั้งใช้งานอุปกรณ์อาจแก้ไขการใช้งาน API พื้นฐานได้ แต่การแก้ไขดังกล่าวต้องไม่ส่งผลต่อลักษณะการทำงานที่ระบุและลายเซ็นภาษา Java ของ API ที่เปิดเผยต่อสาธารณะ
- ผู้ติดตั้งใช้งานอุปกรณ์ต้องไม่เพิ่มองค์ประกอบที่เปิดเผยต่อสาธารณะ (เช่น คลาสหรืออินเทอร์เฟซ หรือฟิลด์หรือเมธอดในคลาสหรืออินเทอร์เฟซที่มีอยู่) ลงใน API ด้านบน
"องค์ประกอบที่เปิดเผยต่อสาธารณะ" คือองค์ประกอบใดก็ตามที่ไม่ได้ตกแต่งด้วยเครื่องหมาย "@hide" ตามที่ใช้ในซอร์สโค้ด Android ต้นทาง กล่าวคือ ผู้ติดตั้งใช้งานอุปกรณ์ต้องไม่เปิดเผย API ใหม่หรือแก้ไข API ที่มีอยู่ในพื้นที่ชื่อที่ระบุไว้ข้างต้น ผู้ติดตั้งใช้งานอุปกรณ์อาจทำการแก้ไขภายในเท่านั้น แต่ต้องไม่โฆษณาหรือเปิดเผยการแก้ไขเหล่านั้นต่อนักพัฒนาแอป
ผู้ติดตั้งใช้งานอุปกรณ์อาจเพิ่ม API ที่กําหนดเองได้ แต่ API ดังกล่าวต้องไม่อยู่ในเนมสเปซที่เป็นของหรืออ้างอิงถึงองค์กรอื่น ตัวอย่างเช่น ผู้ติดตั้งใช้งานอุปกรณ์ต้องไม่เพิ่ม API ลงในเนมสเปซ com.google.* หรือเนมสเปซที่คล้ายกัน เฉพาะ Google เท่านั้นที่เพิ่ม API ได้ ในทำนองเดียวกัน Google ต้องไม่เพิ่ม API ลงในเนมสเปซของบริษัทอื่นๆ นอกจากนี้ หากการติดตั้งใช้งานอุปกรณ์มี API ที่กำหนดเองซึ่งอยู่นอกเนมสเปซ Android มาตรฐาน API เหล่านั้นต้องได้รับการบรรจุในไลบรารีที่ใช้ร่วมกันของ Android เพื่อให้มีเพียงแอปที่ใช้ API เหล่านั้นอย่างชัดเจน (ผ่านกลไก <uses-librarygt;) เท่านั้นที่ได้รับผลกระทบจากการใช้หน่วยความจำที่เพิ่มขึ้นของ API ดังกล่าว
หากผู้ติดตั้งใช้งานอุปกรณ์เสนอที่จะปรับปรุงเนมสเปซแพ็กเกจใดแพ็กเกจหนึ่งข้างต้น (เช่น การเพิ่มฟังก์ชันการทำงานใหม่ที่มีประโยชน์ลงใน API ที่มีอยู่ หรือการเพิ่ม API ใหม่) ผู้ติดตั้งใช้งานควรไปที่ source.android.com และเริ่มกระบวนการมีส่วนร่วมในการเปลี่ยนแปลงและโค้ดตามข้อมูลในเว็บไซต์ดังกล่าว
โปรดทราบว่าข้อจำกัดข้างต้นสอดคล้องกับแบบแผนมาตรฐานในการตั้งชื่อ API ในภาษาโปรแกรม Java ส่วนนี้มีจุดประสงค์เพียงเพื่อเสริมแบบแผนเหล่านั้นและทำให้แบบแผนเหล่านั้นมีผลบังคับใช้ผ่านการรวมไว้ในคำจำกัดความความเข้ากันได้นี้
3.7. ความเข้ากันได้ของรันไทม์
การติดตั้งใช้งานอุปกรณ์ต้องรองรับรูปแบบ Dalvik Executable (DEX) แบบเต็ม รวมถึงข้อกำหนดและความหมายของไบต์โค้ด Dalvik [แหล่งข้อมูล, 23] ผู้ติดตั้งใช้งานอุปกรณ์ควรใช้ ART, การใช้งานตามลําดับชั้นอ้างอิงของรูปแบบ Dalvik Executable และระบบการจัดการแพ็กเกจของการใช้งานอ้างอิง
การติดตั้งใช้งานอุปกรณ์ต้องกำหนดค่ารันไทม์ Dalvik เพื่อจัดสรรหน่วยความจำตามแพลตฟอร์ม Android ต้นทาง และตามที่ระบุไว้ในตารางต่อไปนี้ (ดูคำจำกัดความของขนาดหน้าจอและความหนาแน่นของหน้าจอได้ที่ส่วนที่ 7.1.1)
โปรดทราบว่าค่าหน่วยความจําที่ระบุไว้ด้านล่างถือเป็นค่าขั้นต่ำ และการติดตั้งใช้งานอุปกรณ์อาจจัดสรรหน่วยความจําเพิ่มเติมต่อแอปพลิเคชัน
เลย์เอาต์หน้าจอ | ความหนาแน่นของหน้าจอ | หน่วยความจําของแอปพลิเคชันขั้นต่ำ |
---|---|---|
Android Watch | 120 dpi (ldpi) | 32MB |
160 dpi (mdpi) | ||
213 dpi (tvdpi) | ||
240 dpi (hdpi) | 36MB | |
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 |
160 dpi (mdpi) | ||
213 dpi (tvdpi) | 48MB | |
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 |
160 dpi (mdpi) | 48MB | |
213 dpi (tvdpi) | 80MB | |
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 |
160 dpi (mdpi) | 80MB | |
213 dpi (tvdpi) | 96MB | |
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 ของอุปกรณ์ (หน้าจอหลัก) การติดตั้งใช้งานอุปกรณ์ที่อนุญาตให้แอปพลิเคชันของบุคคลที่สามแทนที่หน้าจอหลักของอุปกรณ์ได้ต้องประกาศฟีเจอร์แพลตฟอร์ม android.software.home_screen
3.8.2. วิดเจ็ต
วิดเจ็ตเป็นตัวเลือกสำหรับการติดตั้งใช้งานอุปกรณ์ Android ทั้งหมด แต่ควรรองรับในอุปกรณ์ Android แบบพกพา
Android กําหนดประเภทคอมโพเนนต์และ API ที่เกี่ยวข้อง รวมถึงวงจรชีวิตของคอมโพเนนต์ที่อนุญาตให้แอปพลิเคชันแสดง "AppWidget" ต่อผู้ใช้ปลายทาง [แหล่งข้อมูล, 24] ซึ่งเป็นฟีเจอร์ที่แนะนําอย่างยิ่งให้รองรับการใช้งานในอุปกรณ์พกพา การติดตั้งใช้งานอุปกรณ์ที่รองรับการฝังวิดเจ็ตในหน้าจอหลักต้องเป็นไปตามข้อกำหนดต่อไปนี้และประกาศการรองรับฟีเจอร์แพลตฟอร์ม android.software.app_widgets
- ตัวเปิดแอปของอุปกรณ์ต้องรองรับ App Widgets ในตัว และแสดงความสามารถในการใช้งานอินเทอร์เฟซของผู้ใช้เพื่อเพิ่ม กำหนดค่า ดู และนำ App Widgets ออกได้โดยตรงภายในตัวเปิดแอป
- การติดตั้งใช้งานอุปกรณ์ต้องสามารถแสดงผลวิดเจ็ตขนาด 4 x 4 ในตารางกริดมาตรฐาน ดูรายละเอียดได้ในหลักเกณฑ์การออกแบบวิดเจ็ตแอปในเอกสารประกอบ Android SDK [แหล่งข้อมูล, 24]
- การติดตั้งใช้งานอุปกรณ์ที่รองรับหน้าจอล็อกอาจรองรับวิดเจ็ตแอปพลิเคชันในหน้าจอล็อก
3.8.3. การแจ้งเตือน
Android มี API ที่ช่วยให้นักพัฒนาแอปแจ้งเตือนผู้ใช้เกี่ยวกับเหตุการณ์สำคัญ [แหล่งข้อมูล 25] โดยใช้ฟีเจอร์ฮาร์ดแวร์และซอฟต์แวร์ของอุปกรณ์
API บางรายการอนุญาตให้แอปพลิเคชันทำการแจ้งเตือนหรือดึงดูดความสนใจโดยใช้ฮาร์ดแวร์ โดยเฉพาะเสียง การสั่น และแสง การติดตั้งใช้งานอุปกรณ์ต้องรองรับการแจ้งเตือนที่ใช้ฟีเจอร์ฮาร์ดแวร์ตามที่อธิบายไว้ในเอกสารประกอบ SDK และรองรับฮาร์ดแวร์ในการติดตั้งใช้งานอุปกรณ์มากที่สุด ตัวอย่างเช่น หากการติดตั้งใช้งานอุปกรณ์มีเครื่องสั่น การติดตั้งใช้งานนั้นต้องใช้ API การสั่นอย่างถูกต้อง หากการติดตั้งใช้งานอุปกรณ์ไม่มีฮาร์ดแวร์ จะต้องติดตั้งใช้งาน API ที่เกี่ยวข้องแบบไม่ดำเนินการ ลักษณะการทํางานนี้มีรายละเอียดเพิ่มเติมในส่วนที่ 7
นอกจากนี้ การติดตั้งใช้งานต้องแสดงผลทรัพยากรทั้งหมด (ไอคอน ไฟล์ภาพเคลื่อนไหว ฯลฯ) ที่ระบุไว้ใน API อย่างถูกต้อง [ทรัพยากร 26] หรือในคู่มือสไตล์ไอคอนแถบสถานะ/แถบระบบ [ทรัพยากร 27] ซึ่งในกรณีของอุปกรณ์ Android TV อาจมีกรณีที่ไม่แสดงการแจ้งเตือน ผู้ติดตั้งใช้งานอุปกรณ์อาจมอบประสบการณ์การใช้งานการแจ้งเตือนที่แตกต่างจากที่ได้จากการใช้งาน Android Open Source อ้างอิง แต่ระบบการแจ้งเตือนระบบอื่นดังกล่าวต้องรองรับแหล่งข้อมูลการแจ้งเตือนที่มีอยู่ดังที่ระบุไว้ข้างต้น
Android รองรับการแจ้งเตือนต่างๆ เช่น
- การแจ้งเตือนแบบริชมีเดีย มุมมองแบบอินเทอร์แอกทีฟสําหรับการแจ้งเตือนต่อเนื่อง
- การแจ้งเตือนล่วงหน้า ผู้ใช้สามารถดำเนินการกับหรือปิดมุมมองแบบอินเทอร์แอกทีฟได้โดยไม่ต้องออกจากแอปปัจจุบัน
- การแจ้งเตือนบนหน้าจอล็อก การแจ้งเตือนที่แสดงบนหน้าจอล็อกพร้อมการควบคุมการแสดงผลอย่างละเอียด
การใช้งานอุปกรณ์ Android เมื่อแสดงการแจ้งเตือนดังกล่าว จะต้องดำเนินการอย่างถูกต้องกับการแจ้งเตือนแบบริชมีเดียและการแจ้งเตือนแบบ Heads-up รวมถึงใส่ชื่อ/ชื่อ ไอคอน ข้อความตามที่ระบุไว้ใน Android API [แหล่งข้อมูล 28]
Android มี Notification Listener Service API ที่ช่วยให้แอป (เมื่อผู้ใช้เปิดใช้อย่างชัดเจน) ได้รับสำเนาของการแจ้งเตือนทั้งหมดเมื่อมีการโพสต์หรืออัปเดต การติดตั้งใช้งานอุปกรณ์ต้องส่งการแจ้งเตือนทั้งหมดไปยังบริการผู้ฟังที่ติดตั้งไว้และผู้ใช้เปิดใช้ทั้งหมดอย่างถูกต้องและทันที รวมถึงข้อมูลเมตาทั้งหมดที่แนบมากับออบเจ็กต์การแจ้งเตือน
3.8.4. ค้นหา
Android มี API [แหล่งข้อมูล, 29] ที่ช่วยนักพัฒนาแอปในการรวมการค้นหาไว้ในแอปพลิเคชัน และแสดงข้อมูลแอปพลิเคชันในการค้นหาระบบทั่วโลก โดยทั่วไปแล้ว ฟังก์ชันการทำงานนี้ประกอบด้วยอินเทอร์เฟซผู้ใช้แบบรวมทั่วทั้งระบบที่ช่วยให้ผู้ใช้ได้ป้อนข้อความค้นหา แสดงคำแนะนำขณะที่ผู้ใช้พิมพ์ และแสดงผลลัพธ์ Android API ช่วยให้นักพัฒนาแอปนําอินเทอร์เฟซนี้ไปใช้ซ้ำเพื่อให้บริการค้นหาภายในแอปของตนเองได้ และช่วยให้นักพัฒนาแอประบุผลการค้นหาไปยังอินเทอร์เฟซผู้ใช้การค้นหาทั่วโลกได้
การติดตั้งใช้งานในอุปกรณ์ Android ควรมี Global Search ซึ่งเป็นอินเทอร์เฟซผู้ใช้การค้นหาแบบแชร์ร่วมกันสำหรับทั้งระบบที่แสดงคำแนะนำแบบเรียลไทม์ตามข้อมูลที่ผู้ใช้ป้อน การติดตั้งใช้งานอุปกรณ์ควรใช้ API ที่อนุญาตให้นักพัฒนาแอปนําอินเทอร์เฟซผู้ใช้นี้ไปใช้ซ้ำเพื่อให้บริการค้นหาภายในแอปพลิเคชันของตนเอง การติดตั้งใช้งานอุปกรณ์ที่ใช้อินเทอร์เฟซการค้นหาทั่วโลกต้องติดตั้งใช้งาน API ที่อนุญาตให้แอปพลิเคชันของบุคคลที่สามเพิ่มคำแนะนำลงในช่องค้นหาเมื่อทำงานในโหมดการค้นหาทั่วโลก หากไม่ได้ติดตั้งแอปพลิเคชันของบุคคลที่สามที่ใช้ฟังก์ชันการทำงานนี้ ลักษณะการทำงานเริ่มต้นควรแสดงผลการค้นหาและคำแนะนำของเครื่องมือค้นหาบนเว็บ
การติดตั้งใช้งานอุปกรณ์ Android ควรใช้ผู้ช่วยในอุปกรณ์เพื่อจัดการการดำเนินการ Assist [แหล่งข้อมูล, 30]
นอกจากนี้ Android ยังมี Assist API ที่ให้แอปพลิเคชันเลือกปริมาณข้อมูลของบริบทปัจจุบันที่จะแชร์กับผู้ช่วยในอุปกรณ์ [แหล่งข้อมูล, 31] การติดตั้งใช้งานอุปกรณ์ที่รองรับการดำเนินการ Assist จะต้องระบุให้ผู้ใช้ปลายทางทราบอย่างชัดเจนเมื่อมีการแชร์บริบทด้วยการแสดงไฟสีขาวรอบๆ ขอบของหน้าจอ ข้อความระบุต้องเป็นไปตามหรือมากกว่าระยะเวลาและความสว่างของการใช้งานโปรเจ็กต์โอเพนซอร์ส Android เพื่อให้ผู้ใช้ปลายทางมองเห็นได้ชัดเจน
3.8.5. ข้อความโทสต์
แอปพลิเคชันสามารถใช้ API "Toast" เพื่อแสดงสตริงแบบไม่โมดัลสั้นๆ ต่อผู้ใช้ปลายทาง ซึ่งจะหายไปหลังจากผ่านไประยะหนึ่ง [แหล่งข้อมูล, 32] การติดตั้งใช้งานอุปกรณ์ต้องแสดงข้อความแจ้งเตือนจากแอปพลิเคชันต่อผู้ใช้ปลายทางในลักษณะที่มองเห็นได้ชัดเจน
3.8.6. ธีม
Android มี "ธีม" เป็นกลไกสำหรับแอปพลิเคชันที่จะใช้รูปแบบในกิจกรรมหรือแอปพลิเคชันทั้งหมด
Android มีชุดธีม "Holo" เป็นชุดสไตล์ที่กําหนดไว้สําหรับนักพัฒนาแอปพลิเคชันเพื่อใช้หากต้องการจับคู่รูปลักษณ์และความรู้สึกของธีม Holo ตามที่ Android SDK กําหนด [แหล่งข้อมูล, 33] การติดตั้งใช้งานอุปกรณ์ต้องไม่เปลี่ยนแปลงแอตทริบิวต์ธีม Holo ที่แสดงต่อแอปพลิเคชัน [ทรัพยากร, 34]
Android มีชุดธีม "Material" เป็นชุดสไตล์ที่กําหนดไว้สําหรับนักพัฒนาแอปพลิเคชันเพื่อใช้หากต้องการจับคู่รูปลักษณ์และความรู้สึกของธีมการออกแบบในอุปกรณ์ Android ประเภทต่างๆ การติดตั้งใช้งานอุปกรณ์ต้องรองรับตระกูลธีม "Material" และต้องไม่เปลี่ยนแปลงแอตทริบิวต์ธีม Material หรือชิ้นงานที่แสดงต่อแอปพลิเคชัน [แหล่งข้อมูล, 35]
นอกจากนี้ Android ยังมีชุดธีม "ค่าเริ่มต้นของอุปกรณ์" เป็นชุดสไตล์ที่กําหนดไว้สําหรับนักพัฒนาแอปพลิเคชันเพื่อใช้หากต้องการจับคู่รูปลักษณ์และความรู้สึกของธีมอุปกรณ์ตามที่ผู้ติดตั้งใช้งานอุปกรณ์กําหนด การติดตั้งใช้งานในอุปกรณ์อาจแก้ไขแอตทริบิวต์ธีมค่าเริ่มต้นของอุปกรณ์ที่แสดงต่อแอปพลิเคชัน [แหล่งข้อมูล, 34]
Android รองรับธีมรูปแบบต่างๆ ที่มีแถบระบบแบบโปร่งแสง ซึ่งช่วยให้นักพัฒนาแอปพลิเคชันเติมเนื้อหาแอปในพื้นที่ด้านหลังแถบสถานะและแถบนําทางได้ สิ่งสำคัญคือต้องคงสไตล์ไอคอนแถบสถานะไว้สำหรับการใช้งานในอุปกรณ์ต่างๆ เพื่อให้นักพัฒนาแอปได้รับประสบการณ์การใช้งานที่สอดคล้องกันในการกำหนดค่านี้ ดังนั้น การใช้งานอุปกรณ์ Android ต้องใช้สีขาวสำหรับไอคอนสถานะของระบบ (เช่น ระดับสัญญาณและระดับแบตเตอรี่) และการแจ้งเตือนที่ระบบออกให้ เว้นแต่ว่าไอคอนจะบ่งบอกถึงสถานะที่มีปัญหาหรือแอปขอแถบสถานะแบบสว่างโดยใช้ Flag SYSTEM_UI_FLAG_LIGHT_STATUS_BAR เมื่อแอปขอแถบสถานะแบบสว่าง การใช้งานอุปกรณ์ Android จะต้องเปลี่ยนสีไอคอนสถานะของระบบเป็นสีดํา [แหล่งข้อมูล, 34]
3.8.7. วอลเปเปอร์เคลื่อนไหว
Android กําหนดประเภทคอมโพเนนต์และ API รวมถึงวงจรที่เกี่ยวข้อง ซึ่งอนุญาตให้แอปพลิเคชันแสดง "วอลเปเปอร์สด" อย่างน้อย 1 รายการต่อผู้ใช้ปลายทาง [แหล่งข้อมูล, 36] วอลเปเปอร์เคลื่อนไหวคือภาพเคลื่อนไหว ลาย หรือรูปภาพที่คล้ายกันซึ่งมีการจำกัดความสามารถในการป้อนข้อมูลซึ่งแสดงเป็นวอลเปเปอร์อยู่หลังแอปพลิเคชันอื่นๆ
ระบบจะถือว่าฮาร์ดแวร์สามารถใช้งานวอลเปเปอร์ภาพเคลื่อนไหวได้อย่างเสถียรหากสามารถใช้งานวอลเปเปอร์ภาพเคลื่อนไหวทั้งหมดได้โดยไม่มีข้อจำกัดด้านฟังก์ชันการทำงานที่อัตราเฟรมที่เหมาะสมโดยไม่ส่งผลเสียต่อแอปพลิเคชันอื่นๆ หากข้อจำกัดของฮาร์ดแวร์ทําให้วอลเปเปอร์และ/หรือแอปพลิเคชันขัดข้อง ทำงานผิดปกติ ใช้พลังงาน CPU หรือแบตเตอรี่มากเกินไป หรือทำงานด้วยอัตราเฟรมที่ต่ำจนยอมรับไม่ได้ ระบบจะถือว่าฮาร์ดแวร์ดังกล่าวไม่สามารถใช้งานวอลเปเปอร์แบบเคลื่อนไหวได้ ตัวอย่างเช่น วอลเปเปอร์เคลื่อนไหวบางรายการอาจใช้บริบท OpenGL 2.0 หรือ 3.x เพื่อแสดงผลเนื้อหา ภาพพื้นหลังแบบเคลื่อนไหวจะไม่ทำงานอย่างเสถียรในฮาร์ดแวร์ที่ไม่รองรับบริบท OpenGL หลายรายการ เนื่องจากการใช้บริบท OpenGL ของภาพพื้นหลังแบบเคลื่อนไหวอาจขัดแย้งกับแอปพลิเคชันอื่นๆ ที่ใช้บริบท OpenGL ด้วย
การติดตั้งใช้งานอุปกรณ์ที่เรียกใช้วอลเปเปอร์ภาพเคลื่อนไหวได้อย่างเสถียรตามที่อธิบายไว้ข้างต้นควรใช้วอลเปเปอร์ภาพเคลื่อนไหว และเมื่อติดตั้งใช้งานแล้ว จะต้องรายงาน Flag ฟีเจอร์แพลตฟอร์ม android.software.live_wallpaper
3.8.8. การเปลี่ยนกิจกรรม
เนื่องจากปุ่มการไปยังส่วนต่างๆ ของฟังก์ชันล่าสุดเป็นตัวเลือก อุปกรณ์ Android Television และอุปกรณ์ Android Watch จึงไม่จำเป็นต้องปฏิบัติตามข้อกำหนดในการใช้งานหน้าจอภาพรวม
แหล่งที่มาของ Android เวอร์ชันอัปสตรีมมีหน้าจอภาพรวม [แหล่งข้อมูล 37] ซึ่งเป็นอินเทอร์เฟซผู้ใช้ระดับระบบสำหรับการสลับงานและแสดงกิจกรรมและงานที่เข้าถึงล่าสุดโดยใช้ภาพขนาดย่อของสถานะกราฟิกของแอปพลิเคชัน ณ เวลาที่ผู้ใช้ออกจากแอปพลิเคชันครั้งล่าสุด การติดตั้งใช้งานในอุปกรณ์ รวมถึงปุ่มการไปยังส่วนต่างๆ ของฟังก์ชันล่าสุดตามที่ระบุไว้ในส่วนที่ 7.2.3 อาจเปลี่ยนแปลงอินเทอร์เฟซได้ แต่ต้องเป็นไปตามข้อกำหนดต่อไปนี้
- ต้องแสดงรายการล่าสุดที่เกี่ยวข้องเป็นกลุ่มที่เคลื่อนไหวไปด้วยกัน
- ต้องรองรับกิจกรรมที่แสดงอย่างน้อย 6 รายการ
- ควรแสดงชื่อกิจกรรมอย่างน้อย 4 รายการพร้อมกัน
- ควรแสดงสีไฮไลต์ ไอคอน ชื่อหน้าจอในส่วนล่าสุด
- ต้องใช้ลักษณะการปักหมุดหน้าจอ [แหล่งข้อมูล, 38] และจัดให้มีเมนูการตั้งค่าให้ผู้ใช้เพื่อเปิด/ปิดฟีเจอร์
- ควรแสดงการปิด ("x") แต่อาจเลื่อนเวลานี้ออกไปจนกว่าผู้ใช้จะโต้ตอบกับหน้าจอ
ขอแนะนําอย่างยิ่งให้ใช้อินเทอร์เฟซผู้ใช้ Android ต้นทาง (หรืออินเทอร์เฟซที่คล้ายกันซึ่งใช้ภาพขนาดย่อ) สําหรับหน้าจอภาพรวมในการติดตั้งใช้งานอุปกรณ์
3.8.9. การจัดการอินพุต
Android รองรับการจัดการอินพุตและรองรับเครื่องมือแก้ไขวิธีการป้อนข้อมูลของบุคคลที่สาม [แหล่งข้อมูล, 39] การติดตั้งใช้งานอุปกรณ์ที่อนุญาตให้ผู้ใช้ใช้วิธีการป้อนข้อมูลของบุคคลที่สามในอุปกรณ์ต้องประกาศฟีเจอร์แพลตฟอร์ม android.software.input_methods และรองรับ IME API ตามที่ระบุไว้ในเอกสารประกอบ Android SDK
การใช้งานอุปกรณ์ที่ประกาศฟีเจอร์ android.software.input_methods ต้องระบุกลไกที่ผู้ใช้เข้าถึงได้เพื่อเพิ่มและกําหนดค่าวิธีการป้อนข้อมูลของบุคคลที่สาม การติดตั้งใช้งานอุปกรณ์ต้องแสดงอินเทอร์เฟซการตั้งค่าเพื่อตอบสนองต่อ Intent android.settings.INPUT_METHOD_SETTINGS
3.8.10. การควบคุมสื่อบนหน้าจอล็อก
ระบบเลิกใช้งาน Remote Control Client API ตั้งแต่ Android 5.0 และใช้เทมเพลตการแจ้งเตือนสื่อแทน ซึ่งช่วยให้แอปพลิเคชันสื่อผสานรวมกับการควบคุมการเล่นที่แสดงบนหน้าจอล็อก [แหล่งข้อมูล, 40] เป็นการแจ้งเตือนบนหน้าจอล็อก การติดตั้งใช้งานอุปกรณ์ต้องแสดงผลเทมเพลตการแจ้งเตือนด้วยสื่ออย่างถูกต้องโดยเป็นส่วนหนึ่งของการแจ้งเตือนบนหน้าจอล็อกตามที่อธิบายไว้ในส่วนที่ 3.8.3
3.8.11. ความฝัน
Android รองรับโปรแกรมรักษาหน้าจอแบบอินเทอร์แอกทีฟที่เรียกว่า Dreams [Resources, 41] Dreams ช่วยให้ผู้ใช้โต้ตอบกับแอปพลิเคชันได้เมื่ออุปกรณ์ที่เชื่อมต่อกับแหล่งจ่ายไฟไม่มีการใช้งานหรือวางอยู่ในแท่นชาร์จบนโต๊ะ อุปกรณ์ Android Watch อาจใช้ Dreams ได้ แต่การใช้งานอุปกรณ์ประเภทอื่นๆ ควรรองรับ Dreams และมีตัวเลือกการตั้งค่าให้ผู้ใช้กำหนดค่า Dreams เพื่อตอบสนองต่อ Intent android.settings.DREAM_SETTINGS
3.8.12. ตำแหน่ง
เมื่ออุปกรณ์มีเซ็นเซอร์ฮาร์ดแวร์ (เช่น GPS) ที่สามารถระบุพิกัดตำแหน่งได้ โหมดตำแหน่งต้องแสดงในเมนูตำแหน่งภายในการตั้งค่า [แหล่งข้อมูล 42]
3.8.13. Unicode และแบบอักษร
Android รองรับอักขระอีโมจิสี เมื่อการติดตั้งใช้งานอุปกรณ์ Android มี IME อุปกรณ์ควรระบุวิธีการป้อนข้อมูลสำหรับผู้ใช้สำหรับอักขระอีโมจิที่ระบุไว้ใน Unicode 6.1 [แหล่งข้อมูล 43] อุปกรณ์ทั้งหมดต้องแสดงผลอักขระอีโมจิเหล่านี้เป็นสัญลักษณ์สีได้
Android รองรับแบบอักษร Roboto 2 ที่มีน้ำหนักแบบต่างๆ ซึ่งได้แก่ sans-serif-thin, sans-serif-light, sans-serif-medium, sans-serif-black, sans-serif-condensed, sans-serif-condensed-light ซึ่งต้องรวมไว้ทั้งหมดสำหรับภาษาที่มีในอุปกรณ์และการครอบคลุม Unicode 7.0 ทั้งหมดของภาษาละติน กรีก และซีริลลิก รวมถึงช่วง Latin Extended A, B, C และ D และสัญลักษณ์ทั้งหมดในบล็อกสัญลักษณ์สกุลเงินของ Unicode 7.0
3.9. การดูแลระบบของอุปกรณ์
Android มีฟีเจอร์ที่ช่วยให้แอปพลิเคชันที่คำนึงถึงความปลอดภัยสามารถดำเนินการด้านการดูแลระบบอุปกรณ์ที่ระดับระบบ เช่น การบังคับใช้นโยบายรหัสผ่านหรือการดำเนินการล้างข้อมูลระยะไกล ผ่าน Android Device Administration API [แหล่งข้อมูล, 44] การติดตั้งใช้งานอุปกรณ์ต้องระบุการใช้งานคลาส DevicePolicyManager [แหล่งข้อมูล, 45] การใช้งานอุปกรณ์ที่รองรับหน้าจอล็อกแบบ PIN (ตัวเลข) หรือรหัสผ่าน (ตัวอักษรและตัวเลข) จะต้องรองรับนโยบายการดูแลอุปกรณ์ทั้งหมดที่ระบุไว้ในเอกสารประกอบ Android SDK [แหล่งข้อมูล, 44] และรายงานฟีเจอร์แพลตฟอร์ม android.software.device_admin
3.9.1 การจัดสรรอุปกรณ์
3.9.1.1 การจัดเตรียมเจ้าของอุปกรณ์
หากการติดตั้งใช้งานอุปกรณ์ประกาศฟีเจอร์ android.software.device_admin ขั้นตอนการตั้งค่าแบบสำเร็จรูปต้องทำให้ลงทะเบียนแอปพลิเคชันเครื่องมือควบคุมนโยบายด้านอุปกรณ์ (DPC) เป็นแอปเจ้าของอุปกรณ์ได้ [ แหล่งข้อมูล, 46] การติดตั้งใช้งานอุปกรณ์อาจมีแอปพลิเคชันที่ติดตั้งไว้ล่วงหน้าซึ่งทำหน้าที่จัดการอุปกรณ์ แต่ต้องไม่ตั้งค่าแอปพลิเคชันนี้เป็นแอปเจ้าของอุปกรณ์โดยไม่ได้รับความยินยอมหรือการดำเนินการอย่างชัดเจนจากผู้ใช้หรือผู้ดูแลระบบของอุปกรณ์
ประสบการณ์ของผู้ใช้ในกระบวนการจัดสรรอุปกรณ์ของเจ้าของ (ขั้นตอนที่เริ่มต้นโดย android.app.action.PROVISION_MANAGED_DEVICE [ แหล่งข้อมูล, 47]) ต้องสอดคล้องกับการใช้งาน AOSP
หากการติดตั้งใช้งานอุปกรณ์รายงาน android.hardware.nfc อุปกรณ์จะต้องเปิดใช้ NFC แม้ในระหว่างขั้นตอนการตั้งค่าแบบพร้อมใช้งานทันที เพื่อให้สามารถจัดสรร NFC ให้กับผู้เป็นเจ้าของอุปกรณ์ได้ [แหล่งข้อมูล, 48]
3.9.1.2 การจัดสรรโปรไฟล์ที่มีการจัดการ
หากการติดตั้งใช้งานอุปกรณ์ประกาศ android.software.managed_users ต้องลงทะเบียนแอปพลิเคชันเครื่องมือควบคุมนโยบายด้านอุปกรณ์ (DPC) เป็นเจ้าของโปรไฟล์ที่มีการจัดการใหม่ได้ [ แหล่งข้อมูล 49]
ประสบการณ์ของผู้ใช้ในกระบวนการจัดสรรโปรไฟล์ที่มีการจัดการ (โฟลว์ที่เริ่มต้นโดย android.app.action.PROVISION_MANAGED_PROFILE [ แหล่งข้อมูล, 50]) ต้องสอดคล้องกับการใช้งาน AOSP
3.9.2 การรองรับโปรไฟล์ที่มีการจัดการ
อุปกรณ์ที่พร้อมใช้งานโปรไฟล์ที่จัดการคืออุปกรณ์ที่มีลักษณะดังนี้
- ประกาศ android.software.device_admin (ดูส่วนที่ 3.9 การดูแลระบบอุปกรณ์)
- ไม่ใช่อุปกรณ์ที่มี RAM ต่ำ (ดูส่วนที่ 7.6.1
- จัดสรรพื้นที่เก็บข้อมูลภายใน (แบบถอดไม่ได้) เป็นพื้นที่เก็บข้อมูลที่ใช้ร่วมกัน (ดูส่วนที่ 7.6.2)
อุปกรณ์ที่พร้อมใช้งานโปรไฟล์ที่มีการจัดการต้องมีคุณสมบัติดังนี้
- ประกาศ Flag ฟีเจอร์แพลตฟอร์ม android.software.managed_users
- รองรับโปรไฟล์ที่มีการจัดการผ่าน android.app.admin.DevicePolicyManager API
- อนุญาตให้สร้างโปรไฟล์ที่มีการจัดการได้เพียงโปรไฟล์เดียว [แหล่งข้อมูล, 50]
- ใช้ป้ายไอคอน (คล้ายกับป้ายงาน Upstream ของ AOSP) เพื่อแสดงแอปพลิเคชันและวิดเจ็ตที่มีการจัดการ รวมถึงองค์ประกอบ UI อื่นๆ ที่มีป้าย เช่น ล่าสุดและการแจ้งเตือน
- แสดงไอคอนการแจ้งเตือน (คล้ายกับป้ายงานของ AOSP Upstream) เพื่อบ่งบอกว่าผู้ใช้อยู่ในแอปพลิเคชันโปรไฟล์ที่มีการจัดการ
- แสดงข้อความแจ้งที่ระบุว่าผู้ใช้อยู่ในโปรไฟล์ที่มีการจัดการเมื่ออุปกรณ์ตื่นขึ้น (ACTION_USER_PRESENT) และแอปพลิเคชันที่ทำงานอยู่เบื้องหน้าอยู่ในโปรไฟล์ที่มีการจัดการ
- หากมีโปรไฟล์ที่จัดการ ให้แสดงสิ่งอำนวยความสะดวกที่มองเห็นได้ใน "เครื่องมือเลือก" ของ Intent เพื่ออนุญาตให้ผู้ใช้ส่งต่อ Intent จากโปรไฟล์ที่จัดการไปยังผู้ใช้หลักหรือในทางกลับกัน หากผู้ควบคุมนโยบายอุปกรณ์เปิดใช้
- หากมีโปรไฟล์ที่มีการจัดการ ให้แสดงสิ่งต่างๆ ต่อไปนี้สำหรับทั้งผู้ใช้หลักและโปรไฟล์ที่มีการจัดการ
- แยกการนับแบตเตอรี่ ตำแหน่ง อินเทอร์เน็ตมือถือ และพื้นที่เก็บข้อมูลสำหรับผู้ใช้หลักและโปรไฟล์ที่มีการจัดการ
- การจัดการแอปพลิเคชัน VPN ที่ติดตั้งภายในผู้ใช้หลักหรือโปรไฟล์ที่มีการจัดการอย่างอิสระ
- การจัดการแอปพลิเคชันที่ติดตั้งภายในผู้ใช้หลักหรือโปรไฟล์ที่มีการจัดการอย่างอิสระ
- การจัดการบัญชีภายในผู้ใช้หลักหรือโปรไฟล์ที่มีการจัดการอย่างอิสระ
- ตรวจสอบว่าเครื่องมือโทรเริ่มต้นสามารถค้นหาข้อมูลผู้โทรจากโปรไฟล์ที่มีการจัดการ (หากมี) ควบคู่ไปกับข้อมูลจากโปรไฟล์หลักได้ หากเครื่องมือควบคุมนโยบายอุปกรณ์อนุญาต
- ต้องตรวจสอบว่าโปรไฟล์เป็นไปตามข้อกำหนดด้านความปลอดภัยทั้งหมดที่มีผลกับอุปกรณ์ที่เปิดใช้ผู้ใช้หลายคน (ดูส่วนที่ 9.5) แม้ว่าระบบจะไม่นับโปรไฟล์ที่มีการจัดการเป็นผู้ใช้รายอื่นนอกเหนือจากผู้ใช้หลัก
3.10. การช่วยเหลือพิเศษ
Android มีเลเยอร์การช่วยเหลือพิเศษที่ช่วยให้ผู้ใช้ที่พิการไปยังส่วนต่างๆ ของอุปกรณ์ได้ง่ายขึ้น นอกจากนี้ Android ยังมี API แพลตฟอร์มที่ช่วยให้การติดตั้งใช้งานบริการการช่วยเหลือพิเศษสามารถรับการเรียกกลับสำหรับเหตุการณ์ของผู้ใช้และระบบ รวมถึงสร้างกลไกการแสดงผลผลป้อนกลับทางเลือก เช่น การอ่านออกเสียงข้อความ การสั่นเพื่อแจ้งผลป้อนกลับ และการไปยังส่วนต่างๆ ด้วยแทร็กบอล/ปุ่มบังคับทิศทาง [แหล่งข้อมูล 51]
การติดตั้งใช้งานอุปกรณ์มีข้อกำหนดต่อไปนี้
- การใช้งาน Android Automotive ควรมีการใช้งานเฟรมเวิร์กการช่วยเหลือพิเศษของ Android ที่สอดคล้องกันกับการใช้งาน Android เริ่มต้น
- การใช้งานอุปกรณ์ (ยกเว้น Android Automotive) ต้องมีการใช้งานเฟรมเวิร์กการช่วยเหลือพิเศษของ Android ที่สอดคล้องกันกับการใช้งาน Android เริ่มต้น
- การติดตั้งใช้งานอุปกรณ์ (ยกเว้น Android Automotive) จะต้องรองรับการติดตั้งใช้งานบริการการช่วยเหลือพิเศษของบุคคลที่สามผ่าน API ของ android.accessibilityservice [แหล่งข้อมูล, 52]
- การใช้งานอุปกรณ์ (ยกเว้น Android Automotive) จะต้องสร้าง AccessibilityEvents และส่งเหตุการณ์เหล่านี้ไปยังการใช้งาน AccessibilityService ที่ลงทะเบียนไว้ทั้งหมดในลักษณะที่สอดคล้องกับการใช้งาน Android เริ่มต้น
- การติดตั้งใช้งานอุปกรณ์ (ยกเว้นอุปกรณ์ Android Automotive และ Android Watch ที่ไม่มีเอาต์พุตเสียง) ต้องมีกลไกที่ผู้ใช้เข้าถึงได้เพื่อเปิดใช้และปิดใช้บริการการช่วยเหลือพิเศษ และต้องแสดงอินเทอร์เฟซนี้เพื่อตอบสนองต่อ Intent android.provider.Settings.ACTION_ACCESSIBILITY_SETTINGS
นอกจากนี้ การใช้งานอุปกรณ์ควรมีการใช้งานบริการการช่วยเหลือพิเศษในอุปกรณ์ และควรมีกลไกให้ผู้ใช้เปิดใช้บริการการช่วยเหลือพิเศษในระหว่างการตั้งค่าอุปกรณ์ การใช้งานบริการช่วยเหลือพิเศษแบบโอเพนซอร์สมีอยู่ในโปรเจ็กต์ Eyes Free [แหล่งข้อมูล, 53]
3.11. การอ่านออกเสียงข้อความ
Android มี API ที่อนุญาตให้แอปพลิเคชันใช้บริการการอ่านออกเสียงข้อความ (TTS) และอนุญาตให้ผู้ให้บริการติดตั้งใช้งานบริการ TTS [แหล่งข้อมูล, 54] การติดตั้งใช้งานอุปกรณ์ที่รายงานฟีเจอร์ android.hardware.audio.output ต้องเป็นไปตามข้อกําหนดเหล่านี้ที่เกี่ยวข้องกับเฟรมเวิร์ก TTS ของ Android
การติดตั้งใช้งาน Android Automotive
- ต้องรองรับ API เฟรมเวิร์ก TTS ของ Android
- อาจรองรับการติดตั้งเครื่องมือ TTS ของบุคคลที่สาม พาร์ทเนอร์ต้องจัดเตรียมอินเทอร์เฟซที่ผู้ใช้เข้าถึงได้ซึ่งช่วยให้ผู้ใช้เลือกเครื่องมือ TTS เพื่อใช้งานในระดับระบบได้ (หากรองรับ)
การติดตั้งใช้งานอุปกรณ์อื่นๆ ทั้งหมด
- ต้องรองรับ API เฟรมเวิร์ก TTS ของ Android และควรมีเครื่องมือ TTS ที่รองรับภาษาที่มีในอุปกรณ์ โปรดทราบว่าซอฟต์แวร์โอเพนซอร์สต้นทางของ Android มีการใช้งานเอ็นจิ้น TTS แบบเต็มรูปแบบ
- ต้องรองรับการติดตั้งเครื่องมือ TTS ของบุคคลที่สาม
- ต้องมีอินเทอร์เฟซที่ผู้ใช้เข้าถึงได้ ซึ่งช่วยให้ผู้ใช้เลือกเครื่องมือ TTS เพื่อใช้งานในระดับระบบได้
3.12. TV Input Framework
เฟรมเวิร์กอินพุต Android Television (TIF) ช่วยให้การส่งเนื้อหาสดไปยังอุปกรณ์ Android Television ง่ายขึ้น TIF มี API มาตรฐานสำหรับสร้างข้อบังคับของอินพุตที่ควบคุมอุปกรณ์ Android Television การติดตั้งใช้งานอุปกรณ์ Android Television ต้องรองรับ TV Input Framework [แหล่งข้อมูล, 55]
การใช้งานอุปกรณ์ที่รองรับ TIF จะต้องประกาศฟีเจอร์แพลตฟอร์ม android.software.live_tv
3.12.1. แอปทีวี
การติดตั้งใช้งานอุปกรณ์ที่ประกาศว่ารองรับรายการทีวีสดต้องมีแอปพลิเคชันทีวี (แอปทีวี) ที่ติดตั้งไว้ โครงการโอเพนซอร์ส Android มีการใช้งานแอป TV
แอปทีวีเริ่มต้นต้องให้สิทธิ์เข้าถึงช่องจากอินพุตที่ติดตั้งไว้และอินพุตของบุคคลที่สาม โปรดทราบว่าอินพุตที่ติดตั้งจะรวมอินพุตทั้งหมดที่ระบุไว้โดยค่าเริ่มต้น ไม่ว่าจะอิงตาม TIF หรือไม่ก็ตามแอปทีวีต้องจัดให้มีสิ่งอำนวยความสะดวกในการติดตั้งและใช้ช่องทีวี [แหล่งข้อมูล, 56] และเป็นไปตามข้อกำหนดต่อไปนี้
- การติดตั้งใช้งานอุปกรณ์ต้องอนุญาตให้ติดตั้งและจัดการอินพุตตาม TIF ของบุคคลที่สาม (อินพุตของบุคคลที่สาม) [แหล่งข้อมูล, 57]
- การติดตั้งใช้งานอุปกรณ์อาจแยกอินพุตตาม TIF ที่ติดตั้งไว้ล่วงหน้า (อินพุตที่ติดตั้ง) [แหล่งข้อมูล, 58] ออกจากอินพุตของบุคคลที่สาม
- การติดตั้งใช้งานอุปกรณ์ต้องไม่แสดงอินพุตของบุคคลที่สามมากกว่าการไปยังส่วนต่างๆ 1 ครั้งจากแอปทีวี (เช่น การขยายรายการอินพุตของบุคคลที่สามจากแอปทีวี)
3.12.1.1. คู่มือรายการทีวีอิเล็กทรอนิกส์
การติดตั้งใช้งานอุปกรณ์ Android Television จะต้องแสดงการวางซ้อนที่ให้ข้อมูลและเป็นแบบอินเทอร์แอกทีฟ ซึ่งต้องมีคู่มือโปรแกรมอิเล็กทรอนิกส์ (EPG) ที่สร้างขึ้นจากค่าในช่อง TvContract.Programs [แหล่งข้อมูล, 59] EPG ต้องเป็นไปตามข้อกำหนดต่อไปนี้
- EPG ต้องแสดงข้อมูลจากอินพุตที่ติดตั้งไว้ทั้งหมดและอินพุตของบุคคลที่สาม
- EPG อาจแยกอินพุตที่ติดตั้งไว้กับอินพุตของบุคคลที่สาม
- ขอแนะนำอย่างยิ่งให้ EPG แสดงอินพุตที่ติดตั้งและอินพุตของบุคคลที่สามอย่างโดดเด่นเท่าๆ กัน EPG ต้องไม่แสดงอินพุตของบุคคลที่สามที่ห่างออกไปมากกว่า 1 การดำเนินการไปยังส่วนต่างๆ จากอินพุตที่ติดตั้งใน EPG
- เมื่อเปลี่ยนช่อง การติดตั้งใช้งานอุปกรณ์ต้องแสดงข้อมูล EPG สำหรับรายการที่กำลังเล่นอยู่
3.12.1.2. การไปยังรายการต่างๆ
อุปกรณ์อินพุตของอุปกรณ์ Android Television (เช่น รีโมต แอปพลิเคชันรีโมต หรือตัวควบคุมเกม) ต้องอนุญาตให้ไปยังส่วนต่างๆ ของหน้าจอที่ดำเนินการได้ทั้งหมดผ่านปุ่ม D-pad ต้องใช้ปุ่มขึ้นและลงของ D-pad เพื่อเปลี่ยนช่องทีวีสดเมื่อไม่มีส่วนที่ทำการดำเนินการได้บนหน้าจอ
แอปทีวีควรส่งเหตุการณ์สำคัญไปยังอินพุต HDMI ผ่าน CEC
3.12.1.3. การลิงก์แอปอินพุตทีวี
การติดตั้งใช้งานอุปกรณ์ Android Television จะต้องรองรับการลิงก์แอปอินพุตทีวี ซึ่งช่วยให้อินพุตทั้งหมดระบุลิงก์กิจกรรมจากกิจกรรมปัจจุบันไปยังกิจกรรมอื่นได้ (เช่น ลิงก์จากรายการสดไปยังเนื้อหาที่เกี่ยวข้อง) [แหล่งข้อมูล, 60] แอปทีวีต้องแสดงการลิงก์แอปอินพุตทีวีเมื่อมีให้
4. ความเข้ากันได้ของแพ็กเกจแอปพลิเคชัน
การติดตั้งใช้งานอุปกรณ์ต้องติดตั้งและเรียกใช้ไฟล์ ".apk" ของ Android ตามที่เครื่องมือ "aapt" ที่รวมอยู่ใน Android SDK อย่างเป็นทางการสร้างขึ้น [แหล่งข้อมูล, 61]
การติดตั้งใช้งานอุปกรณ์ต้องไม่ขยายรูปแบบ .apk [ทรัพยากร, 62], Android Manifest [ทรัพยากร, 49], บา이트โค้ด Dalvik [ทรัพยากร, 23] หรือบา이트โค้ด RenderScript ในลักษณะที่ทําให้ไฟล์เหล่านั้นติดตั้งและทํางานอย่างถูกต้องในอุปกรณ์อื่นๆ ที่เข้ากันได้
5. ความเข้ากันได้ของมัลติมีเดีย
5.1 ตัวแปลงรหัสสื่อ
การติดตั้งใช้งานอุปกรณ์ต้องรองรับรูปแบบสื่อหลักที่ระบุไว้ในเอกสารประกอบ Android SDK [ทรัพยากร, 64] ยกเว้นในกรณีที่เอกสารนี้อนุญาตไว้อย่างชัดเจน กล่าวโดยละเอียดคือ การติดตั้งใช้งานอุปกรณ์ต้องรองรับรูปแบบสื่อ โปรแกรมเข้ารหัส โปรแกรมถอดรหัส ประเภทไฟล์ และรูปแบบคอนเทนเนอร์ที่ระบุไว้ในตารางด้านล่างและรายงานผ่าน MediaCodecList [แหล่งข้อมูล 65] การติดตั้งใช้งานอุปกรณ์ต้องสามารถถอดรหัสโปรไฟล์ทั้งหมดที่รายงานใน CamcorderProfile [แหล่งข้อมูล, 66] และสามารถถอดรหัสรูปแบบทั้งหมดที่อุปกรณ์สามารถเข้ารหัสได้ โปรแกรมเปลี่ยนไฟล์เหล่านี้ทั้งหมดมีให้บริการเป็นการใช้งานซอฟต์แวร์ในการใช้งาน Android ที่ต้องการจากโครงการโอเพนซอร์ส Android
โปรดทราบว่าทั้ง Google และ Open Handset Alliance ไม่ได้รับรองว่าตัวแปลงรหัสเหล่านี้ปราศจากสิทธิบัตรของบุคคลที่สาม เราขอแนะนำให้ผู้ที่ตั้งใจจะใช้ซอร์สโค้ดนี้ในผลิตภัณฑ์ฮาร์ดแวร์หรือซอฟต์แวร์ทราบว่าการใช้งานโค้ดนี้ ซึ่งรวมถึงในซอฟต์แวร์โอเพนซอร์สหรือแชร์แวร์ อาจต้องใช้ใบอนุญาตสิทธิบัตรจากผู้ถือครองสิทธิบัตรที่เกี่ยวข้อง
5.1.1. ตัวแปลงรหัสเสียง
รูปแบบ/ตัวแปลงรหัส | โปรแกรมเปลี่ยนไฟล์ | ตัวถอดรหัส | รายละเอียด | ประเภทไฟล์/รูปแบบคอนเทนเนอร์ที่รองรับ |
---|---|---|---|---|
โปรไฟล์ MPEG-4 AAC (AAC LC) |
ต้องระบุ1 | ต้องระบุ | รองรับเนื้อหาโมโน/สเตอริโอ/5.0/5.12 ที่มีอัตราการสุ่มตัวอย่างมาตรฐานตั้งแต่ 8 ถึง 48 kHz |
|
โปรไฟล์ MPEG-4 HE AAC (AAC+) | ต้องระบุ1 (Android 4.1 ขึ้นไป) |
ต้องระบุ | รองรับเนื้อหาโมโน/สเตอริโอ/5.0/5.12 ที่มีอัตราการสุ่มตัวอย่างมาตรฐานตั้งแต่ 16 ถึง 48 kHz | |
MPEG-4 HE AACv2 โปรไฟล์ (AAC+ ที่ปรับปรุงแล้ว) |
ต้องระบุ | รองรับเนื้อหาโมโน/สเตอริโอ/5.0/5.12 ที่มีอัตราการสุ่มตัวอย่างมาตรฐานตั้งแต่ 16 ถึง 48 kHz | ||
AAC ELD (AAC แบบเวลาในการตอบสนองต่ำที่ปรับปรุงแล้ว) | ต้องระบุ1 (Android 4.1 ขึ้นไป) |
ต้องระบุ (Android 4.1 ขึ้นไป) |
รองรับเนื้อหาโมโน/สเตอริโอที่มีอัตราการสุ่มตัวอย่างมาตรฐานตั้งแต่ 16 ถึง 48 kHz | |
AMR-NB | ต้องระบุ3 | ต้องระบุ3 | 4.75 ถึง 12.2 kbps ที่อัตราตัวอย่าง 8 kHz | 3GPP (.3gp) |
AMR-WB | ต้องระบุ3 | ต้องระบุ3 | 9 อัตราตั้งแต่ 6.60 Kbps ถึง 23.85 Kbps ที่อัตราตัวอย่าง 16 kHz | |
FLAC | ต้องระบุ (Android 3.1 ขึ้นไป) |
โมโน/สเตอริโอ (ไม่มีหลายช่อง) อัตราการสุ่มตัวอย่างสูงสุด 48 kHz (แต่แนะนำให้ใช้สูงสุด 44.1 kHz ในอุปกรณ์ที่มีเอาต์พุต 44.1 kHz เนื่องจากตัวแปลงสัญญาณ 48 เป็น 44.1 kHz จะไม่มีตัวกรอง Low Pass) แนะนำ 16 บิต ไม่ใช้การกรองความถี่แบบดิทเทอร์สำหรับ 24 บิต | FLAC (.flac) เท่านั้น | |
MP3 | ต้องระบุ | โมโน/สเตอริโอ 8-320 Kbps แบบคงที่ (CBR) หรืออัตราบิตแบบผันแปร (VBR) | MP3 (.mp3) | |
MIDI | ต้องระบุ | MIDI ประเภท 0 และ 1 DLS เวอร์ชัน 1 และ 2 XMF และ Mobile XMF การรองรับรูปแบบริงโทน RTTTL/RTX, OTA และ iMelody |
|
|
Vorbis | ต้องระบุ |
|
||
PCM/WAVE | ต้องระบุ4 (Android 4.1 ขึ้นไป) |
ต้องระบุ | PCM แบบเชิงเส้น 16 บิต (อัตราสูงสุดตามขีดจำกัดของฮาร์ดแวร์) อุปกรณ์ต้องรองรับอัตราการสุ่มตัวอย่างสำหรับการบันทึก PCM ดิบที่ความถี่ 8000, 11025, 16000 และ 44100 Hz | WAVE (.wav) |
Opus | ต้องระบุ (Android 5.0 ขึ้นไป) |
Matroska (.mkv) |
1 ต้องระบุสำหรับการติดตั้งใช้งานอุปกรณ์ที่กําหนด android.hardware.microphone แต่ไม่จำเป็นต้องระบุสำหรับการติดตั้งใช้งานอุปกรณ์ Android Watch
2 จำเป็นต้องมีการลดคุณภาพเนื้อหา 5.0/5.1 เท่านั้น การบันทึกหรือการแสดงผลมากกว่า 2 แชนแนลเป็นตัวเลือก
3 ต้องระบุสำหรับการติดตั้งใช้งานในอุปกรณ์ Android Handheld
4 ต้องระบุสำหรับการติดตั้งใช้งานอุปกรณ์ที่กําหนด android.hardware.microphone รวมถึงการติดตั้งใช้งานอุปกรณ์ Android Watch
5.1.2. ตัวแปลงรหัสรูปภาพ
รูปแบบ/ตัวแปลงรหัส | โปรแกรมเปลี่ยนไฟล์ | ตัวถอดรหัส | รายละเอียด | ประเภทไฟล์/รูปแบบคอนเทนเนอร์ที่รองรับ |
---|---|---|---|---|
JPEG | ต้องระบุ | ต้องระบุ | Base+progressive | JPEG (.jpg) |
GIF | ต้องระบุ | GIF (.gif) | ||
PNG | ต้องระบุ | ต้องระบุ | PNG (.png) | |
BMP | ต้องระบุ | BMP (.bmp) | ||
WebP | ต้องระบุ | ต้องระบุ | WebP (.webp) |
5.1.3. ตัวแปลงรหัสวิดีโอ
รูปแบบ/ตัวแปลงรหัส | โปรแกรมเปลี่ยนไฟล์ | ตัวถอดรหัส | รายละเอียด | ประเภทไฟล์/ รูปแบบคอนเทนเนอร์ที่รองรับ |
---|---|---|---|---|
H.263 | ต้องระบุ1 | ต้องระบุ2 |
|
|
H.264 AVC | ต้องระบุ2 | ต้องระบุ2 | ดูรายละเอียดได้ที่ส่วนที่ 5.2 และ 5.3 |
|
H.265 HEVC | ต้องระบุ5 | ดูรายละเอียดได้ที่ส่วนที่ 5.3 | MPEG-4 (.mp4) | |
MPEG-2 | แนะนำอย่างยิ่ง6 | โปรไฟล์หลัก | MPEG2-TS | |
MPEG-4 SP | ต้องระบุ2 | 3GPP (.3gp) | ||
VP83 | ต้องระบุ2 (Android 4.3 ขึ้นไป) |
ต้องระบุ2 (Android 2.3.3 ขึ้นไป) |
ดูรายละเอียดที่ส่วนที่ 5.2 และ 5.3 |
|
VP9 | ต้องระบุ2 (Android 4.4 ขึ้นไป) |
ดูรายละเอียดได้ที่ส่วนที่ 5.3 |
|
1 ต้องระบุสำหรับการติดตั้งใช้งานอุปกรณ์ที่มีฮาร์ดแวร์กล้องและกำหนดค่า android.hardware.camera หรือ android.hardware.camera.front
2 ต้องระบุสำหรับการติดตั้งใช้งานอุปกรณ์ ยกเว้นอุปกรณ์ Android Watch
3 เพื่อให้บริการสตรีมมิงวิดีโอบนเว็บและบริการวิดีโอคอนเฟอเรนซ์มีคุณภาพที่ยอมรับได้ การติดตั้งใช้งานอุปกรณ์ควรใช้ตัวแปลงรหัส VP8 ของฮาร์ดแวร์ที่เป็นไปตามข้อกำหนดใน [แหล่งข้อมูล, 68]
4 การใช้งานอุปกรณ์ควรรองรับการเขียนไฟล์ Matroska WebM
5 แนะนำอย่างยิ่งสำหรับ Android Automotive ไม่บังคับสำหรับ Android Watch และจำเป็นสำหรับอุปกรณ์ประเภทอื่นๆ ทั้งหมด
6 มีผลเฉพาะกับการติดตั้งใช้งานอุปกรณ์ Android Television เท่านั้น
5.2 การเข้ารหัสวิดีโอ
คุณไม่จำเป็นต้องใช้ตัวแปลงรหัสวิดีโอสำหรับการติดตั้งใช้งานอุปกรณ์ Android Watch
การติดตั้งใช้งานอุปกรณ์ Android ที่มีโปรแกรมเปลี่ยนไฟล์ H.263 จะต้องรองรับโปรไฟล์พื้นฐานระดับ 45
การใช้งานอุปกรณ์ Android ที่รองรับตัวแปลงรหัส H.264 จะต้องรองรับโปรไฟล์ Baseline ระดับ 3 และโปรไฟล์การเข้ารหัสวิดีโอ SD (ความละเอียดมาตรฐาน) ต่อไปนี้ และควรรองรับโปรไฟล์ Main ระดับ 4 และโปรไฟล์การเข้ารหัสวิดีโอ HD (ความละเอียดสูง) ต่อไปนี้ ขอแนะนำอย่างยิ่งให้อุปกรณ์ Android TV เข้ารหัสวิดีโอ HD 1080p ที่ 30 fps
SD (คุณภาพต่ำ) | SD (คุณภาพสูง) | HD 720p1 | HD 1080p1 | |
---|---|---|---|---|
ความละเอียดของวิดีโอ | 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 |
1 เมื่อฮาร์ดแวร์รองรับ แต่แนะนำอย่างยิ่งสำหรับอุปกรณ์ Android Television
การใช้งานอุปกรณ์ Android ที่รองรับตัวแปลงรหัส VP8 จะต้องรองรับโปรไฟล์การเข้ารหัสวิดีโอ SD และควรรองรับโปรไฟล์การเข้ารหัสวิดีโอ HD (ความละเอียดสูง) ต่อไปนี้
SD (คุณภาพต่ำ) | SD (คุณภาพสูง) | HD 720p1 | HD 1080p1 | |
---|---|---|---|---|
ความละเอียดของวิดีโอ | 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 |
1 เมื่อฮาร์ดแวร์รองรับ
5.3 การถอดรหัสวิดีโอ
คุณไม่จำเป็นต้องใช้ตัวแปลงรหัสวิดีโอสำหรับการติดตั้งใช้งานอุปกรณ์ Android Watch
การติดตั้งใช้งานอุปกรณ์ต้องรองรับความละเอียดและอัตราเฟรมวิดีโอแบบไดนามิกที่เปลี่ยนผ่าน Android API มาตรฐานภายในสตรีมเดียวกันสำหรับตัวแปลงรหัส VP8, VP9, H.264 และ H.265 ทั้งหมดแบบเรียลไทม์และสูงสุดถึงความละเอียดที่ตัวแปลงรหัสแต่ละรายการในอุปกรณ์รองรับ
การติดตั้งใช้งานอุปกรณ์ Android ที่มีโปรแกรมถอดรหัส H.263 จะต้องรองรับ Baseline Profile ระดับ 30
การติดตั้งใช้งานอุปกรณ์ Android ที่มีโปรแกรมถอดรหัส MPEG-4 จะต้องรองรับ Simple Profile ระดับ 3
การใช้งานอุปกรณ์ Android ที่มีตัวถอดรหัส H.264 จะต้องรองรับโปรไฟล์หลักระดับ 3.1 และโปรไฟล์การถอดรหัสวิดีโอ SD ต่อไปนี้ และควรรองรับโปรไฟล์การถอดรหัส HD อุปกรณ์ Android TV ต้องรองรับ High Profile ระดับ 4.2 และโปรไฟล์การถอดรหัส HD 1080p
SD (คุณภาพต่ำ) | SD (คุณภาพสูง) | HD 720p1 | HD 1080p1 | |
---|---|---|---|---|
ความละเอียดของวิดีโอ | 320 x 240 พิกเซล | 720 x 480 พิกเซล | 1280 x 720 พิกเซล | 1920 x 1080 พิกเซล |
อัตราเฟรมของวิดีโอ | 30 fps | 30 fps | 60 FPS | 30 fps / 60 fps2 |
อัตราบิตของวิดีโอ | 800 Kbps | 2 Mbps | 8 Mbps | 20 Mbps |
1 ต้องระบุเมื่อความสูงที่รายงานโดยเมธอด Display.getSupportedModes() เท่ากับหรือมากกว่าความละเอียดของวิดีโอ
2 ต้องระบุสำหรับการติดตั้งใช้งานอุปกรณ์ Android Television
การใช้งานอุปกรณ์ Android เมื่อรองรับตัวแปลงรหัส VP8 ตามที่อธิบายไว้ในส่วนที่ 5.1.3 จะต้องรองรับโปรไฟล์การถอดรหัส SD ต่อไปนี้และควรรองรับโปรไฟล์การถอดรหัส HD อุปกรณ์ Android TV ต้องรองรับโปรไฟล์การถอดรหัส HD 1080p
SD (คุณภาพต่ำ) | SD (คุณภาพสูง) | HD 720p1 | HD 1080p1 | |
---|---|---|---|---|
ความละเอียดของวิดีโอ | 320 x 180 พิกเซล | 640 x 360 พิกเซล | 1280 x 720 พิกเซล | 1920 x 1080 พิกเซล |
อัตราเฟรมของวิดีโอ | 30 fps | 30 fps | 30 fps / 60 fps2 | 30 / 60 fps2 |
อัตราบิตของวิดีโอ | 800 Kbps | 2 Mbps | 8 Mbps | 20 Mbps |
1 ต้องระบุเมื่อความสูงที่รายงานโดยเมธอด Display.getSupportedModes() เท่ากับหรือมากกว่าความละเอียดของวิดีโอ
2 ต้องระบุสำหรับการติดตั้งใช้งานอุปกรณ์ Android Television
การใช้งานอุปกรณ์ Android เมื่อรองรับตัวแปลงรหัส VP9 ตามที่อธิบายไว้ในส่วนที่ 5.1.3 จะต้องรองรับโปรไฟล์การถอดรหัสวิดีโอ SD ต่อไปนี้ และควรรองรับโปรไฟล์การถอดรหัส HD เราขอแนะนำอย่างยิ่งให้อุปกรณ์ Android TV รองรับโปรไฟล์การถอดรหัส HD 1080p และควรรองรับโปรไฟล์การถอดรหัส UHD เมื่อรองรับโปรไฟล์การถอดรหัสวิดีโอ UHD อุปกรณ์ต้องรองรับความลึกของสี 8 บิตและควรรองรับ VP9 โปรไฟล์ 2 (10 บิต)
SD (คุณภาพต่ำ) | SD (คุณภาพสูง) | HD 720p1 | HD 1080p2 | UHD2 | |
---|---|---|---|---|---|
ความละเอียดของวิดีโอ | 320 x 180 พิกเซล | 640 x 360 พิกเซล | 1280 x 720 พิกเซล | 1920 x 1080 พิกเซล | 3840 x 2160 พิกเซล |
อัตราเฟรมของวิดีโอ | 30 fps | 30 fps | 30 fps | 60 FPS | 60 FPS |
อัตราบิตของวิดีโอ | 600 Kbps | 1.6 Mbps | 4 Mbps | 5 Mbps | 20 Mbps |
1 ต้องระบุสำหรับการติดตั้งใช้งานอุปกรณ์ Android Television แต่สำหรับอุปกรณ์ประเภทอื่นๆ จะต้องระบุก็ต่อเมื่อฮาร์ดแวร์รองรับ
2 ขอแนะนำอย่างยิ่งสำหรับการติดตั้งใช้งานอุปกรณ์ Android Television ที่มีอยู่เมื่อฮาร์ดแวร์รองรับ
การใช้งานอุปกรณ์ Android เมื่อรองรับตัวแปลงรหัส H.265 ตามที่อธิบายไว้ในส่วนที่ 5.1.3 จะต้องรองรับโปรไฟล์หลักระดับ 3 หลักและโปรไฟล์การถอดรหัสวิดีโอ SD ต่อไปนี้ และควรรองรับโปรไฟล์การถอดรหัส HD เราขอแนะนำอย่างยิ่งให้อุปกรณ์ Android TV รองรับโปรไฟล์การถอดรหัส UHD และโปรไฟล์การถอดรหัส HD 1080p หากรองรับโปรไฟล์การถอดรหัส HD 1080p อุปกรณ์จะต้องรองรับโปรไฟล์หลักระดับ 4.1 ระดับหลัก หากรองรับการถอดรหัส UHD อุปกรณ์จะต้องรองรับโปรไฟล์ Main10 ระดับ 5 ระดับหลัก
SD (คุณภาพต่ำ) | SD (คุณภาพสูง) | HD 720p1 | HD 1080p2 | UHD2 | |
---|---|---|---|---|---|
ความละเอียดของวิดีโอ | 352 x 288 พิกเซล | 640 x 360 พิกเซล | 1280 x 720 พิกเซล | 1920 x 1080 พิกเซล | 3840 x 2160 พิกเซล |
อัตราเฟรมของวิดีโอ | 30 fps | 30 fps | 30 fps | 60 FPS2 | 60 FPS |
อัตราบิตของวิดีโอ | 600 Kbps | 1.6 Mbps | 4 Mbps | 10 Mbps | 20 Mbps |
1 ต้องระบุสำหรับการติดตั้งใช้งานอุปกรณ์ Android Television แต่สำหรับอุปกรณ์ประเภทอื่นๆ จะต้องระบุก็ต่อเมื่อฮาร์ดแวร์รองรับ
2 ขอแนะนำอย่างยิ่ง สําหรับการติดตั้งใช้งานอุปกรณ์ Android Television ที่มีอยู่เมื่อฮาร์ดแวร์รองรับ
5.4. การบันทึกเสียง
แม้ว่าข้อกำหนดบางประการที่ระบุไว้ในส่วนนี้จะระบุว่าควรใช้มาตั้งแต่ Android 4.3 แต่เราวางแผนที่จะเปลี่ยนคำนิยามความเข้ากันได้สำหรับเวอร์ชันในอนาคตเป็นต้อง เราขอแนะนำอย่างยิ่งให้อุปกรณ์ Android ที่มีอยู่และอุปกรณ์ใหม่เป็นไปตามข้อกำหนดเหล่านี้ที่ระบุไว้ว่า "ควร" ไม่เช่นนั้นอุปกรณ์จะใช้งานร่วมกับ Android ไม่ได้เมื่ออัปเกรดเป็นเวอร์ชันในอนาคต
5.4.1. การบันทึกเสียงแบบ RAW
การใช้งานอุปกรณ์ที่ประกาศ android.hardware.microphone จะต้องอนุญาตให้บันทึกเนื้อหาเสียงดิบที่มีลักษณะต่อไปนี้
- รูปแบบ: Linear PCM, 16 บิต
- อัตราการสุ่มตัวอย่าง: 8000, 11025, 16000, 44100
- แชแนล: โมโน
การบันทึกสำหรับอัตราตัวอย่างข้างต้นต้องดำเนินการโดยไม่มีการอัปแซมเปิล และการลดขนาดตัวอย่างต้องรวมตัวกรองการลดรอยหยักที่เหมาะสม
การใช้งานอุปกรณ์ที่ประกาศ android.hardware.microphone ควรอนุญาตให้บันทึกเนื้อหาเสียงดิบที่มีคุณลักษณะต่อไปนี้
- รูปแบบ: Linear PCM, 16 บิต
- อัตราการสุ่มตัวอย่าง: 22050, 48000
- ช่อง: สเตอริโอ
หากระบบรองรับการบันทึกสำหรับอัตราการสุ่มตัวอย่างข้างต้น การบันทึกจะต้องดำเนินการโดยไม่มีการอัปสุ่มตัวอย่างในอัตราส่วนสูงกว่า 16000:22050 หรือ 44100:48000 การอัปหรือดาวน์สุ่มตัวอย่างต้องมีตัวกรองการลบรอยหยักที่เหมาะสม
5.4.2. บันทึกเสียงเพื่อจดจำเสียงพูด
นอกเหนือจากข้อกำหนดการบันทึกข้างต้นแล้ว เมื่อแอปพลิเคชันเริ่มบันทึกสตรีมเสียงโดยใช้แหล่งที่มาของเสียง android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION จะมีผลดังนี้
- อุปกรณ์ควรแสดงลักษณะความกว้างของคลื่นที่ราบเรียบเมื่อเทียบกับความถี่ โดยเฉพาะอย่างยิ่ง ±3 dB จาก 100 Hz ถึง 4000 Hz
- ควรตั้งค่าความไวอินพุตเสียงเพื่อให้แหล่งที่มาของระดับกำลังเสียง (SPL) 90 dB ที่ 1000 Hz ให้ค่า RMS 2500 สำหรับตัวอย่าง 16 บิต
- ระดับแอมพลิจูด PCM ควรติดตามการเปลี่ยนแปลง SPL ของอินพุตแบบเชิงเส้นในช่วงอย่างน้อย 30 dB จาก -18 dB ถึง +12 dB เทียบกับ SPL 90 dB ที่ไมโครโฟน
- ความเพี้ยนตามฮาร์โมนิกทั้งหมดควรน้อยกว่า 1% สำหรับ 1 kHz ที่ระดับอินพุต SPL 90 dB ที่ไมโครโฟน
- คุณต้องปิดใช้การประมวลผลการลดเสียงรบกวน (หากมี)
- ต้องปิดใช้การควบคุมระดับสัญญาณอัตโนมัติ (หากมี)
หากแพลตฟอร์มรองรับเทคโนโลยีการลดเสียงรบกวนที่ได้รับการปรับแต่งสำหรับการจดจำคำพูด เอฟเฟกต์จะต้องควบคุมได้จาก API ของ android.media.audiofx.NoiseSuppressor นอกจากนี้ ช่อง UUID สำหรับข้อบ่งชี้ผลของการตัดเสียงรบกวนต้องระบุการใช้งานเทคโนโลยีการตัดเสียงรบกวนแต่ละรายการโดยไม่ซ้ำกัน
5.4.3. บันทึกเพื่อเปลี่ยนเส้นทางการเล่น
คลาส android.media.MediaRecorder.AudioSource มีแหล่งที่มาของเสียง REMOTE_SUBMIX อุปกรณ์ที่ประกาศ android.hardware.audio.output ต้องใช้แหล่งที่มาของเสียง REMOTE_SUBMIX อย่างถูกต้องเพื่อให้แอปพลิเคชันที่ใช้ android.media.AudioRecord API เพื่อบันทึกจากแหล่งที่มาของเสียงนี้สามารถบันทึกเสียงผสมจากสตรีมเสียงทั้งหมดได้ ยกเว้นสตรีมต่อไปนี้
- STREAM_RING
- STREAM_ALARM
- STREAM_NOTIFICATION
5.5. การเล่นเสียง
การใช้งานอุปกรณ์ที่ประกาศ android.hardware.audio.output ต้องเป็นไปตามข้อกำหนดในส่วนนี้
5.5.1. การเล่นเสียงดิบ
อุปกรณ์ต้องอนุญาตให้เล่นเนื้อหาเสียงดิบที่มีคุณลักษณะต่อไปนี้
- รูปแบบ: Linear PCM, 16 บิต
- อัตราการสุ่มตัวอย่าง: 8000, 11025, 16000, 22050, 32000, 44100
- ช่อง: โมโน สเตอริโอ
อุปกรณ์ควรอนุญาตให้เล่นเนื้อหาเสียงดิบที่มีลักษณะต่อไปนี้
- อัตราการสุ่มตัวอย่าง: 24000, 48000
5.5.2. เอฟเฟกต์เสียง
Android มี API สำหรับเอฟเฟกต์เสียงสำหรับการติดตั้งใช้งานอุปกรณ์ [แหล่งข้อมูล, 69] การใช้งานอุปกรณ์ที่ประกาศฟีเจอร์ android.hardware.audio.output
- ต้องรองรับการใช้งาน EFFECT_TYPE_EQUALIZER และ EFFECT_TYPE_LOUDNESS_ENHANCER ที่ควบคุมผ่านคลาสย่อย AudioEffect อย่าง Equalizer และ LoudnessEnhancer
- ต้องรองรับการติดตั้งใช้งาน Visualizer API ซึ่งควบคุมได้ผ่านคลาส Visualizer
- ควรรองรับการใช้งาน EFFECT_TYPE_BASS_BOOST, EFFECT_TYPE_ENV_REVERB, EFFECT_TYPE_PRESET_REVERB และ EFFECT_TYPE_VIRTUALIZER ที่ควบคุมผ่านคลาสย่อยของ AudioEffect ซึ่งได้แก่ BassBoost, EnvironmentalReverb, PresetReverb และ Virtualizer
5.5.3. ระดับเสียงเอาต์พุตเสียง
การติดตั้งใช้งานอุปกรณ์ Android Television ต้องมีระบบที่รองรับระดับเสียงหลักและระดับเสียงเอาต์พุตเสียงดิจิทัลที่ลดลงในเอาต์พุตที่รองรับ ยกเว้นเอาต์พุตการส่งผ่านเสียงแบบบีบอัด (ซึ่งไม่มีการถอดรหัสเสียงในอุปกรณ์)
5.6. เวลาในการตอบสนองของเสียง
เวลาในการตอบสนองของเสียงคือความล่าช้าของเวลาเมื่อสัญญาณเสียงผ่านระบบ แอปพลิเคชันหลายคลาสอาศัยเวลาในการตอบสนองที่ต่ำเพื่อให้ได้เสียงเอฟเฟกต์แบบเรียลไทม์
ในส่วนนี้จะใช้คําจํากัดความต่อไปนี้
- เวลาในการตอบสนองของเอาต์พุต ช่วงเวลาระหว่างที่แอปพลิเคชันเขียนเฟรมของข้อมูลที่เข้ารหัส PCM และเวลาที่ผู้ฟังภายนอกได้ยินเสียงหรือตัวแปลงสัญญาณตรวจพบเสียงที่เกี่ยวข้อง
- เวลาในการตอบสนองของเอาต์พุตแบบไม่อุ่นเครื่อง เวลาในการตอบสนองของเอาต์พุตสำหรับเฟรมแรกเมื่อระบบเอาต์พุตเสียงไม่ได้ทำงานและปิดอยู่ก่อนได้รับคำขอ
- เวลาในการตอบสนองของเอาต์พุตอย่างต่อเนื่อง เวลาในการตอบสนองของเอาต์พุตสำหรับเฟรมต่อๆ ไปหลังจากที่อุปกรณ์เล่นเสียง
- เวลาในการตอบสนองต่อการป้อนข้อมูล ช่วงเวลาระหว่างที่เสียงภายนอกแสดงต่ออุปกรณ์และเวลาที่แอปพลิเคชันอ่านเฟรมที่สอดคล้องกันของข้อมูลที่เข้ารหัส PCM
- เวลาในการตอบสนองของอินพุตแบบ Cold ผลรวมของเวลาอินพุตที่เสียไปและเวลาในการตอบสนองของอินพุตสำหรับเฟรมแรก เมื่อระบบอินพุตเสียงไม่ได้ใช้งานและปิดอยู่ก่อนคําขอ
- เวลาในการตอบสนองของการป้อนข้อมูลอย่างต่อเนื่อง เวลาในการตอบสนองของอินพุตสำหรับเฟรมต่อๆ ไปขณะที่อุปกรณ์บันทึกเสียง
- การกระวนของเอาต์พุตแบบเย็น ความแปรปรวนในการวัดค่าเวลาในการตอบสนองของเอาต์พุตแบบ Cold แยกกัน
- ความผันผวนของอินพุตแบบเย็น ความแปรปรวนในการวัดค่าเวลาในการตอบสนองของอินพุตแบบ Cold Start แยกกัน
- เวลาในการตอบสนองแบบไปกลับอย่างต่อเนื่อง ผลรวมของเวลาในการตอบสนองของอินพุตแบบต่อเนื่องบวกเวลาในการตอบสนองของเอาต์พุตแบบต่อเนื่องบวก 1 ช่วงบัฟเฟอร์ ระยะเวลาบัฟเฟอร์ช่วยให้แอปมีเวลาประมวลผลและลดความแตกต่างของเฟสระหว่างสตรีมอินพุตและเอาต์พุต
- OpenSL ES PCM buffer queue API ชุด OpenSL ES API ที่เกี่ยวข้องกับ PCM ภายใน Android NDK ดูข้อมูลได้ที่ NDK_root/docs/opensles/index.html
ขอแนะนำอย่างยิ่งให้การติดตั้งใช้งานอุปกรณ์ที่ประกาศ android.hardware.audio.output เป็นไปตามข้อกำหนดเอาต์พุตเสียงต่อไปนี้หรือสูงกว่า
- เวลาในการตอบสนองของเอาต์พุตแบบ Cold ไม่เกิน 100 มิลลิวินาที
- เวลาในการตอบสนองของเอาต์พุตแบบต่อเนื่องไม่เกิน 45 มิลลิวินาที
- ลดการกระวนกระวายของเอาต์พุตที่เย็น
หากการติดตั้งใช้งานอุปกรณ์เป็นไปตามข้อกำหนดของส่วนนี้หลังจากการปรับเทียบเบื้องต้นเมื่อใช้ OpenSL ES PCM buffer queue API สำหรับเวลาในการตอบสนองของเอาต์พุตแบบต่อเนื่องและเวลาในการตอบสนองของเอาต์พุตแบบ Cold บนอุปกรณ์เอาต์พุตเสียงที่รองรับอย่างน้อย 1 เครื่อง เราขอแนะนำอย่างยิ่งให้รายงานการรองรับเสียงที่มีเวลาในการตอบสนองต่ำ โดยรายงานฟีเจอร์ android.hardware.audio.low_latency ผ่านคลาส android.content.pm.PackageManager [แหล่งข้อมูล, 70] ในทางกลับกัน หากการติดตั้งใช้งานอุปกรณ์ไม่เป็นไปตามข้อกำหนดเหล่านี้ อุปกรณ์ต้องไม่รายงานการรองรับเสียงที่มีเวลาในการตอบสนองต่ำ
ขอแนะนำอย่างยิ่งให้การติดตั้งใช้งานอุปกรณ์ที่มี android.hardware.microphone เป็นไปตามข้อกำหนดด้านเสียงอินพุตต่อไปนี้
- เวลาในการตอบสนองของอินพุตแบบ Cold Start ไม่เกิน 100 มิลลิวินาที
- เวลาในการตอบสนองของอินพุตต่อเนื่องไม่เกิน 30 มิลลิวินาที
- เวลาในการตอบสนองไป-กลับแบบต่อเนื่องไม่เกิน 50 มิลลิวินาที
- ลดการกระวนกระวายของอินพุตที่เย็น
5.7. โปรโตคอลเครือข่าย
อุปกรณ์ต้องรองรับโปรโตคอลเครือข่ายสื่อสำหรับการเล่นเสียงและวิดีโอตามที่ระบุไว้ในเอกสารประกอบของ Android SDK [แหล่งข้อมูล, 64] กล่าวโดยละเอียดคือ อุปกรณ์ต้องรองรับโปรโตคอลเครือข่ายสื่อต่อไปนี้
- RTSP (RTP, SDP)
- การสตรีมแบบ Progressive ของ HTTP(S)
- โปรโตคอลฉบับร่างสําหรับสตรีมมิงแบบสดของ HTTP(S) เวอร์ชัน 3 [แหล่งข้อมูล, 71]
5.8. Secure Media
การติดตั้งใช้งานอุปกรณ์ที่รองรับเอาต์พุตวิดีโอที่ปลอดภัยและรองรับแพลตฟอร์มที่ปลอดภัยต้องประกาศการรองรับ Display.FLAG_SECURE การใช้งานอุปกรณ์ที่ประกาศรองรับ Display.FLAG_SECURE หากรองรับโปรโตคอลจอแสดงผลแบบไร้สาย จะต้องรักษาความปลอดภัยของลิงก์ด้วยกลไกการเข้ารหัสที่มีประสิทธิภาพ เช่น HDCP 2.x ขึ้นไปสำหรับจอแสดงผลแบบไร้สาย Miracast ในทำนองเดียวกัน หากอุปกรณ์รองรับจอแสดงผลภายนอกแบบใช้สาย การติดตั้งใช้งานอุปกรณ์จะต้องรองรับ HDCP 1.2 ขึ้นไป การติดตั้งใช้งานอุปกรณ์ Android TV ต้องใช้ HDCP 2.2 สำหรับอุปกรณ์ที่รองรับความละเอียด 4K และ HDCP 1.4 ขึ้นไปสำหรับความละเอียดที่ต่ำกว่า การใช้งานโอเพนซอร์สจากฝั่งอัปสตรีมของ Android มีการรองรับจอแสดงผลแบบไร้สาย (Miracast) และแบบใช้สาย (HDMI) ที่เป็นไปตามข้อกำหนดนี้
5.9. Musical Instrument Digital Interface (MIDI)
หากการติดตั้งใช้งานอุปกรณ์รองรับการส่งผ่าน MIDI ซอฟต์แวร์ระหว่างแอป (อุปกรณ์ MIDI เสมือนจริง) และรองรับ MIDI ผ่านการส่งผ่านฮาร์ดแวร์ที่รองรับ MIDI ทั้งหมดต่อไปนี้ ซึ่งให้การเชื่อมต่อที่ไม่ใช่ MIDI ทั่วไป เราขอแนะนำอย่างยิ่งให้รายงานการรองรับฟีเจอร์ android.software.midi ผ่านคลาส android.content.pm.PackageManager [แหล่งข้อมูล, 70]
การส่งผ่านฮาร์ดแวร์ที่รองรับ MIDI มีดังนี้
- โหมดโฮสต์ USB (ส่วนที่ 7.7 USB)
- โหมดอุปกรณ์ต่อพ่วง USB (ส่วนที่ 7.7 USB)
ในทางกลับกัน หากการติดตั้งใช้งานอุปกรณ์มีการเชื่อมต่อที่ไม่ใช่ MIDI ทั่วไปผ่านตัวส่งผ่านฮาร์ดแวร์ที่รองรับ MIDI บางรายการที่ระบุไว้ข้างต้น แต่ไม่รองรับ MIDI ผ่านตัวส่งผ่านฮาร์ดแวร์ดังกล่าว อุปกรณ์ต้องไม่รายงานการรองรับฟีเจอร์ android.software.midi
MIDI ผ่านบลูทูธ LE ที่ทำหน้าที่ในบทบาทกลาง (ส่วนที่ 7.4.3 บลูทูธ) อยู่ในสถานะทดลองใช้ การใช้งานอุปกรณ์ที่รายงานฟีเจอร์ android.software.midi และให้การเชื่อมต่อที่ไม่ใช่ MIDI ทั่วไปผ่าน Bluetooth LE ควรรองรับ MIDI ผ่าน Bluetooth LE
5.10. เสียงระดับมืออาชีพ
หากการติดตั้งใช้งานอุปกรณ์เป็นไปตามข้อกำหนดต่อไปนี้ทั้งหมด เราขอแนะนำอย่างยิ่งให้รายงานการรองรับฟีเจอร์ android.hardware.audio.pro ผ่านคลาส android.content.pm.PackageManager [แหล่งข้อมูล, 70]
- การติดตั้งใช้งานอุปกรณ์ต้องรายงานการรองรับฟีเจอร์ android.hardware.audio.low_latency
- เวลาในการตอบสนองไป-กลับของเสียงแบบต่อเนื่องตามที่ระบุไว้ในส่วนที่ 5.6 เวลาในการตอบสนองของเสียงต้องไม่เกิน 20 มิลลิวินาทีและควรไม่เกิน 10 มิลลิวินาทีในเส้นทางที่รองรับอย่างน้อย 1 เส้นทาง
- หากอุปกรณ์มีช่องเสียบเสียง 3.5 มม. แบบ 4 สาย เวลาในการตอบสนองของเสียงแบบไป-กลับอย่างต่อเนื่องต้องไม่เกิน 20 มิลลิวินาทีผ่านเส้นทางของช่องเสียบเสียง และควรไม่เกิน 10 มิลลิวินาทีผ่านเส้นทางของช่องเสียบเสียง
- การติดตั้งใช้งานอุปกรณ์ต้องมีพอร์ต USB ที่รองรับโหมดโฮสต์ USB และโหมดอุปกรณ์ต่อพ่วง USB
- โหมดโฮสต์ USB ต้องใช้คลาสเสียง USB
- หากอุปกรณ์มีพอร์ต HDMI การใช้งานอุปกรณ์ต้องรองรับเอาต์พุตแบบสเตอริโอและ 8 แชนแนลที่ความลึก 20 บิตหรือ 24 บิตและ 192 kHz โดยไม่มีการสูญเสียความลึกของบิตหรือการสุ่มตัวอย่างอีกครั้ง
- การติดตั้งใช้งานอุปกรณ์ต้องรายงานการรองรับฟีเจอร์ android.software.midi
- หากอุปกรณ์มีขั้วต่อเสียง 4 เส้นขนาด 3.5 มม.เราขอแนะนำอย่างยิ่งให้การติดตั้งใช้งานอุปกรณ์เป็นไปตามส่วนข้อกำหนดเฉพาะของอุปกรณ์เคลื่อนที่ (แจ็ค) ของข้อกำหนดเฉพาะของชุดหูฟังแบบใช้สาย (v1.1)
6. ความเข้ากันได้ของเครื่องมือและตัวเลือกสำหรับนักพัฒนาแอป
6.1 เครื่องมือสำหรับนักพัฒนาซอฟต์แวร์
การติดตั้งใช้งานอุปกรณ์ต้องรองรับเครื่องมือสําหรับนักพัฒนาแอป Android ที่มีให้ใน Android SDK อุปกรณ์ Android ที่เข้ากันได้ต้องเข้ากันได้กับสิ่งต่อไปนี้
- Android Debug Bridge (adb) [แหล่งข้อมูล, 72]
การติดตั้งใช้งานอุปกรณ์ต้องรองรับฟังก์ชัน adb ทั้งหมดตามที่ระบุไว้ใน Android SDK รวมถึง dumpsys [Resources, 73] เดรัม adb ฝั่งอุปกรณ์ต้องไม่ทำงานโดยค่าเริ่มต้น และต้องมีข้อบังคับให้ผู้ใช้เข้าถึงกลไกเพื่อเปิด Android Debug Bridge ได้ หากการใช้งานอุปกรณ์ไม่มีโหมดอุปกรณ์ต่อพ่วง USB อุปกรณ์นั้นต้องใช้ Android Debug Bridge ผ่านเครือข่าย LAN (เช่น อีเทอร์เน็ตหรือ 802.11)
Android รองรับ adb ที่ปลอดภัย adb ที่ปลอดภัยจะเปิดใช้ adb ในโฮสต์ที่รู้จักและผ่านการตรวจสอบสิทธิ์ การติดตั้งใช้งานอุปกรณ์ต้องรองรับ adb ที่ปลอดภัย
- Dalvik Debug Monitor Service (ddms) [แหล่งข้อมูล, 74]
การติดตั้งใช้งานอุปกรณ์ต้องรองรับฟีเจอร์ ddms ทั้งหมดตามที่ระบุไว้ในเอกสารประกอบของ Android SDK เนื่องจาก ddms ใช้ adb การรองรับ ddms จึงควรปิดอยู่โดยค่าเริ่มต้น แต่ต้องรองรับทุกครั้งที่ผู้ใช้เปิดใช้งาน Android Debug Bridge ตามที่ระบุไว้ข้างต้น
- Monkey [Resources, 75]
การติดตั้งใช้งานอุปกรณ์ต้องมีเฟรมเวิร์ก Monkey และทำให้แอปพลิเคชันใช้งานได้
- SysTrace [Resources, 76]
การติดตั้งใช้งานอุปกรณ์ต้องรองรับเครื่องมือ Systrace ตามที่ระบุไว้ใน Android SDK Systrace ต้องปิดอยู่โดยค่าเริ่มต้น และต้องมีข้อบังคับให้ผู้ใช้เข้าถึงได้เพื่อเปิด Systrace
ระบบที่ใช้ Linux ส่วนใหญ่และระบบ Apple Macintosh จะจดจำอุปกรณ์ Android ได้โดยใช้เครื่องมือ Android SDK มาตรฐานโดยไม่ต้องมีการสนับสนุนเพิ่มเติม อย่างไรก็ตาม ระบบ Microsoft Windows มักจะต้องใช้ไดรเวอร์สำหรับอุปกรณ์ Android เครื่องใหม่ (เช่น รหัสผู้ให้บริการใหม่และบางครั้งรหัสอุปกรณ์ใหม่ต้องใช้ไดรเวอร์ USB ที่กําหนดเองสําหรับระบบ Windows) หากเครื่องมือ adb ใน Android SDK มาตรฐานไม่รู้จักการติดตั้งใช้งานอุปกรณ์ ผู้ติดตั้งใช้งานอุปกรณ์ต้องจัดหาไดรเวอร์ Windows ที่อนุญาตให้นักพัฒนาแอปเชื่อมต่อกับอุปกรณ์โดยใช้โปรโตคอล adb คุณต้องจัดเตรียมไดรเวอร์เหล่านี้สำหรับ Windows XP, Windows Vista, Windows 7, Windows 8 และ Windows 10 ทั้งเวอร์ชัน 32 บิตและ 64 บิต
6.2 ตัวเลือกสำหรับนักพัฒนาแอป
Android รองรับให้นักพัฒนาแอปกำหนดการตั้งค่าที่เกี่ยวข้องกับการพัฒนาแอป การติดตั้งใช้งานอุปกรณ์ต้องเป็นไปตาม Intent android.settings.APPLICATION_DEVELOPMENT_SETTINGS เพื่อแสดงการตั้งค่าที่เกี่ยวข้องกับการพัฒนาแอปพลิเคชัน [แหล่งข้อมูล, 77] การใช้งาน Android เวอร์ชันอัปสตรีมจะซ่อนเมนูตัวเลือกสำหรับนักพัฒนาแอปโดยค่าเริ่มต้น และอนุญาตให้ผู้ใช้เปิดตัวเลือกสำหรับนักพัฒนาแอปหลังจากกดรายการเมนูการตั้งค่า > เกี่ยวกับอุปกรณ์ > หมายเลขบิลด์ 7 ครั้ง การติดตั้งใช้งานอุปกรณ์ต้องมอบประสบการณ์การใช้งานที่สอดคล้องกันสำหรับตัวเลือกของนักพัฒนาแอป กล่าวโดยละเอียดคือ การติดตั้งใช้งานอุปกรณ์ต้องซ่อนตัวเลือกสำหรับนักพัฒนาแอปโดยค่าเริ่มต้น และต้องจัดให้มีกลไกในการเปิดใช้ตัวเลือกสำหรับนักพัฒนาแอปที่สอดคล้องกับการติดตั้งใช้งาน Android เวอร์ชันที่พัฒนาขึ้น
7. ความเข้ากันได้ของฮาร์ดแวร์
หากอุปกรณ์มีส่วนประกอบฮาร์ดแวร์บางอย่างที่มี API ที่เกี่ยวข้องสำหรับนักพัฒนาแอปบุคคลที่สาม การติดตั้งใช้งานอุปกรณ์ต้องใช้ API ดังกล่าวตามที่อธิบายไว้ในเอกสารประกอบ Android SDK หาก API ใน SDK โต้ตอบกับคอมโพเนนต์ฮาร์ดแวร์ที่ระบุว่าไม่บังคับ และการใช้งานอุปกรณ์ไม่มีคอมโพเนนต์ดังกล่าว ให้ทำดังนี้
- คุณต้องยังคงแสดงคำจำกัดความของคลาสที่สมบูรณ์ (ตามที่ SDK ระบุไว้) สำหรับ API ของคอมโพเนนต์
- ลักษณะการทํางานของ API ต้องติดตั้งใช้งานแบบ No-Ops ในลักษณะที่เหมาะสม
- เมธอด API ต้องแสดงผลค่า Null ตามที่เอกสารประกอบของ SDK อนุญาต
- เมธอด API ต้องแสดงผลการใช้งานคลาสแบบไม่มีการดำเนินการในกรณีที่เอกสารประกอบ SDK ไม่อนุญาตให้ใช้ค่า Null
- เมธอด API ต้องไม่แสดงข้อยกเว้นที่ไม่ได้ระบุไว้ในเอกสารประกอบของ SDK
ตัวอย่างทั่วไปของสถานการณ์ที่มีการใช้ข้อกำหนดเหล่านี้คือ API โทรศัพท์: แม้แต่ในอุปกรณ์ที่ไม่ใช่โทรศัพท์ ก็ต้องติดตั้งใช้งาน API เหล่านี้แบบไม่มีการดำเนินการใดๆ ที่สมเหตุสมผล
การติดตั้งใช้งานอุปกรณ์ต้องรายงานข้อมูลการกำหนดค่าฮาร์ดแวร์ที่ถูกต้องอย่างสม่ำเสมอผ่านเมธอด getSystemAvailableFeatures() และ hasSystemFeature(String) ในคลาส android.content.pm.PackageManager สำหรับลายนิ้วมือของบิลด์เดียวกัน [Resources, 70]
7.1. การแสดงผลและกราฟิก
Android มีเครื่องมือที่ปรับชิ้นงานแอปพลิเคชันและเลย์เอาต์ UI โดยอัตโนมัติให้เหมาะสมกับอุปกรณ์ เพื่อให้แอปพลิเคชันของบุคคลที่สามทำงานได้อย่างราบรื่นในการกำหนดค่าฮาร์ดแวร์ต่างๆ [แหล่งข้อมูล, 78] อุปกรณ์ต้องใช้ 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. ขนาดหน้าจอ
อุปกรณ์ Android Watch (ดูรายละเอียดในส่วนที่ 2) อาจมีขนาดหน้าจอเล็กกว่าตามที่อธิบายไว้ในส่วนนี้
เฟรมเวิร์ก UI ของ Android รองรับหน้าจอขนาดต่างๆ และอนุญาตให้แอปพลิเคชันค้นหาขนาดหน้าจอของอุปกรณ์ (หรือที่เรียกว่า "เลย์เอาต์หน้าจอ") ผ่าน android.content.res.Configuration.screenLayout ที่มี SCREENLAYOUT_SIZE_MASK การติดตั้งใช้งานอุปกรณ์ต้องรายงานขนาดหน้าจอที่ถูกต้องตามที่ระบุไว้ในเอกสารประกอบ Android SDK [ทรัพยากร, 78] และกำหนดโดยแพลตฟอร์ม Android ต้นทาง กล่าวโดยละเอียดคือ การติดตั้งใช้งานอุปกรณ์ต้องรายงานขนาดหน้าจอที่ถูกต้องตามมิติข้อมูลหน้าจอพิกเซล (dp) ที่ไม่ขึ้นอยู่กับความหนาแน่นตามตรรกะต่อไปนี้
- อุปกรณ์ต้องมีขนาดหน้าจออย่างน้อย 426 dp x 320 dp ("เล็ก") เว้นแต่จะเป็นอุปกรณ์ Android Watch
- อุปกรณ์ที่รายงานขนาดหน้าจอเป็น "ปกติ" ต้องมีขนาดหน้าจออย่างน้อย 480 dp x 320 dp
- อุปกรณ์ที่รายงานขนาดหน้าจอเป็น "ใหญ่" ต้องมีหน้าจอขนาดอย่างน้อย 640 dp x 480 dp
- อุปกรณ์ที่รายงานขนาดหน้าจอเป็น "ขนาดใหญ่พิเศษ" ต้องมีหน้าจอขนาดอย่างน้อย 960 dp x 720 dp
นอกจากนี้
- อุปกรณ์ Android Watch ต้องมีหน้าจอที่มีขนาดเส้นทแยงมุมจริงอยู่ในช่วง 1.1-2.5 นิ้ว
- การติดตั้งใช้งานอุปกรณ์ Android ประเภทอื่นๆ ที่มีหน้าจอแบบผสานรวมเข้ากับตัวเครื่อง ต้องมีหน้าจอขนาดเส้นทแยงมุมอย่างน้อย 2.5 นิ้ว
อุปกรณ์ต้องไม่เปลี่ยนขนาดหน้าจอที่รายงานไม่ว่าเมื่อใดก็ตาม
แอปพลิเคชันจะระบุขนาดหน้าจอที่รองรับผ่านแอตทริบิวต์ <supports-screens> ในไฟล์ AndroidManifest.xml หรือไม่ก็ได้ การติดตั้งใช้งานอุปกรณ์ต้องเป็นไปตามการรองรับที่ระบุไว้ของแอปพลิเคชันสำหรับหน้าจอขนาดเล็ก ปกติ ขนาดใหญ่ และขนาดใหญ่พิเศษตามที่อธิบายไว้ในเอกสารประกอบของ Android SDK
7.1.1.2. สัดส่วนภาพหน้าจอ
อุปกรณ์ Android Watch อาจใช้สัดส่วนภาพ 1.0 (1:1)
สัดส่วนการแสดงผลของหน้าจอต้องเป็นค่าตั้งแต่ 1.3333 (4:3) ถึง 1.86 (ประมาณ 16:9) แต่อุปกรณ์ Android Watch อาจมีสัดส่วนการแสดงผล 1.0 (1:1) ได้ เนื่องจากการติดตั้งใช้งานอุปกรณ์ดังกล่าวจะใช้ UI_MODE_TYPE_WATCH เป็น android.content.res.Configuration.uiMode
7.1.1.3. ความหนาแน่นของหน้าจอ
เฟรมเวิร์ก UI ของ Android จะกำหนดชุดความหนาแน่นเชิงตรรกะมาตรฐานเพื่อช่วยนักพัฒนาแอปกำหนดเป้าหมายทรัพยากรแอป การติดตั้งใช้งานอุปกรณ์ต้องรายงานความหนาแน่นของเฟรมเวิร์ก Android เชิงตรรกะเพียงค่าใดค่าหนึ่งต่อไปนี้ผ่าน API android.util.DisplayMetrics และต้องเรียกใช้แอปพลิเคชันที่ความหนาแน่นมาตรฐานนี้ และต้องไม่เปลี่ยนแปลงค่าสำหรับการแสดงผลเริ่มต้นไม่ว่าเมื่อใดก็ตาม
- 120 dpi (ldpi)
- 160 dpi (mdpi)
- 213 dpi (tvdpi)
- 240 dpi (hdpi)
- 280 dpi (280dpi)
- 320 dpi (xhdpi)
- 360 dpi (360dpi)
- 400 dpi (400dpi)
- 420 dpi (420dpi)
- 480 dpi (xxhdpi)
- 560 dpi (560dpi)
- 640 dpi (xxxhdpi)
การใช้งานอุปกรณ์ควรกำหนดความหนาแน่นของเฟรมเวิร์ก Android มาตรฐานซึ่งใกล้เคียงกับค่าความหนาแน่นจริงของหน้าจอมากที่สุด เว้นแต่ความหนาแน่นเชิงตรรกะดังกล่าวจะทำให้ขนาดหน้าจอที่รายงานต่ำกว่าค่าต่ำสุดที่รองรับ หากความหนาแน่นของเฟรมเวิร์ก Android มาตรฐานที่ใกล้เคียงกับความหนาแน่นจริงที่สุดทำให้ขนาดหน้าจอเล็กกว่าขนาดหน้าจอที่เล็กที่สุดที่เข้ากันได้ (ความกว้าง 320 dp) การใช้งานอุปกรณ์ควรรายงานความหนาแน่นของเฟรมเวิร์ก Android มาตรฐานที่ต่ำที่สุดถัดไป
7.1.2. เมตริก Display
การติดตั้งใช้งานอุปกรณ์ต้องรายงานค่าที่ถูกต้องสำหรับเมตริกการแสดงผลทั้งหมดที่กําหนดไว้ใน android.util.DisplayMetrics [Resources, 79] และต้องรายงานค่าเดียวกันไม่ว่าจะใช้หน้าจอแบบฝังหรือหน้าจอภายนอกเป็นจอแสดงผลเริ่มต้นก็ตาม
7.1.3. การวางแนวหน้าจอ
อุปกรณ์ต้องรายงานการวางแนวหน้าจอที่รองรับ (android.hardware.screen.portrait และ/หรือ android.hardware.screen.landscape) และรายงานการวางแนวที่รองรับอย่างน้อย 1 รายการ เช่น อุปกรณ์ที่มีหน้าจอแนวนอนแบบปรับทิศทางไม่ได้ เช่น ทีวีหรือแล็ปท็อป ควรรายงานเฉพาะ android.hardware.screen.landscape
อุปกรณ์ที่รายงานการวางแนวหน้าจอทั้ง 2 แบบต้องรองรับการวางแนวแบบไดนามิกโดยแอปพลิเคชันสำหรับการวางแนวหน้าจอในแนวตั้งหรือแนวนอน กล่าวคือ อุปกรณ์ต้องปฏิบัติตามคำขอของแอปพลิเคชันสำหรับการวางแนวหน้าจอที่เจาะจง การติดตั้งใช้งานอุปกรณ์อาจเลือกการวางแนวแนวตั้งหรือแนวนอนเป็นค่าเริ่มต้น
อุปกรณ์ต้องรายงานค่าที่ถูกต้องสำหรับการวางแนวปัจจุบันของอุปกรณ์ทุกครั้งที่มีการค้นหาผ่าน android.content.res.Configuration.orientation, android.view.Display.getOrientation() หรือ API อื่นๆ
อุปกรณ์ต้องไม่เปลี่ยนขนาดหรือความหนาแน่นของหน้าจอที่รายงานเมื่อเปลี่ยนการวางแนว
7.1.4. การเร่งกราฟิก 2 มิติและ 3 มิติ
การติดตั้งใช้งานอุปกรณ์ต้องรองรับทั้ง OpenGL ES 1.0 และ 2.0 ตามที่ระบุไว้ในเอกสารประกอบของ Android SDK การติดตั้งใช้งานอุปกรณ์ควรรองรับ OpenGL ES 3.0 หรือ 3.1 ในอุปกรณ์ที่รองรับ การติดตั้งใช้งานบนอุปกรณ์ยังต้องรองรับ Android RenderScript ด้วย ตามที่ระบุไว้ในเอกสารประกอบ Android SDK [ทรัพยากร, 80]
การติดตั้งใช้งานอุปกรณ์ต้องระบุตัวเองอย่างถูกต้องว่ารองรับ OpenGL ES 1.0, OpenGL ES 2.0, OpenGL ES 3.0 หรือ OpenGL 3.1 นั่นคือ
- API ที่มีการจัดการ (เช่น ผ่านเมธอด GLES10.getString()) จะต้องรายงานการรองรับ OpenGL ES 1.0 และ OpenGL ES 2.0
- API ของ OpenGL ที่เป็น C/C++ ดั้งเดิม (API ที่พร้อมให้บริการแก่แอปผ่าน libGLES_v1CM.so, libGLES_v2.so หรือ libEGL.so) จะต้องรายงานการรองรับ OpenGL ES 1.0 และ OpenGL ES 2.0
- การติดตั้งใช้งานอุปกรณ์ที่ประกาศรองรับ OpenGL ES 3.0 หรือ 3.1 จะต้องรองรับ API ที่มีการจัดการที่เกี่ยวข้องและรองรับ API ของ C/C++ ดั้งเดิม ในการใช้งานบนอุปกรณ์ที่ประกาศรองรับ OpenGL ES 3.0 หรือ 3.1 libGLESv2.so จะต้องส่งออกสัญลักษณ์ฟังก์ชันที่เกี่ยวข้องนอกเหนือจากสัญลักษณ์ฟังก์ชัน OpenGL ES 2.0
นอกจาก OpenGL ES 3.1 แล้ว Android ยังมีแพ็กเกจส่วนขยายที่มีอินเทอร์เฟซ Java [ทรัพยากร, 81] และการรองรับแบบเนทีฟสำหรับฟังก์ชันกราฟิกขั้นสูง เช่น เทสเซลเลชันและรูปแบบการบีบอัดพื้นผิว ASTC การติดตั้งใช้งานอุปกรณ์ Android อาจรองรับแพ็กเกจส่วนขยายนี้ และจะต้องระบุการรองรับผ่าน Flag ฟีเจอร์ android.hardware.opengles.aep เฉพาะในกรณีที่ติดตั้งใช้งานอย่างเต็มรูปแบบเท่านั้น
นอกจากนี้ การใช้งานอุปกรณ์อาจใช้ส่วนขยาย OpenGL ES ที่ต้องการ อย่างไรก็ตาม การติดตั้งใช้งานอุปกรณ์ต้องรายงานสตริงส่วนขยายทั้งหมดที่รองรับผ่าน API ของ OpenGL ES ที่มีการจัดการและ API เดิม และในทางกลับกัน ต้องไม่รายงานสตริงส่วนขยายที่ไม่รองรับ
โปรดทราบว่า Android รองรับแอปพลิเคชันที่จะระบุ (ไม่บังคับ) ว่าต้องใช้รูปแบบการบีบอัดพื้นผิว OpenGL ที่เฉพาะเจาะจง รูปแบบเหล่านี้มักเจาะจงผู้ให้บริการ Android ไม่ได้กำหนดให้การติดตั้งใช้งานอุปกรณ์ต้องใช้รูปแบบการบีบอัดพื้นผิวที่เฉพาะเจาะจง อย่างไรก็ตาม อุปกรณ์ควรรายงานรูปแบบการบีบอัดพื้นผิวที่รองรับอย่างถูกต้องผ่านเมธอด getString() ใน OpenGL API
Android มีกลไกสำหรับแอปพลิเคชันในการประกาศว่าต้องการเปิดใช้การเร่งด้วยฮาร์ดแวร์สำหรับกราฟิก 2 มิติที่ระดับแอปพลิเคชัน กิจกรรม หน้าต่าง หรือมุมมอง โดยใช้แท็กไฟล์ Manifest รูปแบบ android:hardwareAccelerated หรือการเรียก API โดยตรง [แหล่งข้อมูล, 82]
การติดตั้งใช้งานอุปกรณ์ต้องเปิดใช้การเร่งฮาร์ดแวร์โดยค่าเริ่มต้น และต้องปิดใช้การเร่งฮาร์ดแวร์หากนักพัฒนาแอปร้องขอโดยการตั้งค่า android:hardwareAccelerated="false" หรือปิดใช้การเร่งฮาร์ดแวร์โดยตรงผ่าน Android View API
นอกจากนี้ การติดตั้งใช้งานอุปกรณ์ต้องแสดงลักษณะการทำงานที่สอดคล้องกับเอกสารประกอบ Android SDK เกี่ยวกับการเร่งฮาร์ดแวร์ [แหล่งข้อมูล, 82]
Android มีออบเจ็กต์ TextureView ที่ช่วยนักพัฒนาแอปผสานรวมพื้นผิว OpenGL ES ที่เร่งด้วยฮาร์ดแวร์โดยตรงเป็นเป้าหมายการแสดงผลในลําดับชั้น UI การติดตั้งใช้งานอุปกรณ์ต้องรองรับ TextureView API และต้องแสดงลักษณะการทำงานที่สอดคล้องกันกับการติดตั้งใช้งาน Android เวอร์ชันที่ใหม่กว่า
Android รองรับ EGL_ANDROID_RECORDABLE ซึ่งเป็นแอตทริบิวต์ EGLConfig ที่ระบุว่า EGLConfig รองรับการแสดงผลไปยัง ANativeWindow ที่บันทึกรูปภาพเป็นวิดีโอหรือไม่ การติดตั้งใช้งานอุปกรณ์ต้องรองรับส่วนขยาย EGL_ANDROID_RECORDABLE [ทรัพยากร, 83]
7.1.5. โหมดความเข้ากันได้ของแอปพลิเคชันเดิม
Android จะระบุ "โหมดความเข้ากันได้" ซึ่งเฟรมเวิร์กจะทํางานในโหมดขนาดหน้าจอ "ปกติ" (ความกว้าง 320dp) เพื่อประโยชน์ของแอปพลิเคชันเดิมที่ไม่ได้พัฒนาขึ้นสําหรับ Android เวอร์ชันเก่าซึ่งอยู่ก่อนยุคที่รองรับทุกขนาดหน้าจอ
- Android Automotive ไม่รองรับโหมดความเข้ากันได้เดิม
- การติดตั้งใช้งานอุปกรณ์อื่นๆ ทั้งหมดต้องรองรับโหมดความเข้ากันได้ของแอปพลิเคชันเดิมตามที่โค้ดโอเพนซอร์สของ Android ต้นทางนำมาใช้งาน กล่าวคือ การติดตั้งใช้งานอุปกรณ์ต้องไม่เปลี่ยนแปลงทริกเกอร์หรือเกณฑ์ที่เปิดใช้งานโหมดความเข้ากันได้ และต้องไม่เปลี่ยนแปลงลักษณะการทํางานของโหมดความเข้ากันได้
7.1.6. เทคโนโลยีหน้าจอ
แพลตฟอร์ม Android มี API ที่ช่วยให้แอปพลิเคชันแสดงผลกราฟิกแบบริชมีเดียบนจอแสดงผลได้ อุปกรณ์ต้องรองรับ API ทั้งหมดเหล่านี้ตามที่ Android SDK กำหนด เว้นแต่จะได้รับอนุญาตอย่างเจาะจงในเอกสารนี้
- อุปกรณ์ต้องรองรับจอแสดงผลที่แสดงผลกราฟิกสี 16 บิตได้ และควรรองรับจอแสดงผลที่แสดงผลกราฟิกสี 24 บิตได้
- อุปกรณ์ต้องรองรับจอแสดงผลที่แสดงภาพเคลื่อนไหวได้
- เทคโนโลยีการแสดงผลที่ใช้ต้องมีสัดส่วนพิกเซล (PAR) ระหว่าง 0.9 ถึง 1.15 กล่าวคือ อัตราส่วนพิกเซลต้องใกล้เคียงกับสี่เหลี่ยมจัตุรัส (1.0) โดยมีความคลาดเคลื่อน 10-15%
7.1.7. จอแสดงผลสำรอง
Android รองรับจอแสดงผลรองเพื่อให้สามารถแชร์สื่อได้ รวมถึง API ของนักพัฒนาแอปสำหรับการเข้าถึงจอแสดงผลภายนอก หากอุปกรณ์รองรับจอแสดงผลภายนอกผ่านการเชื่อมต่อจอแสดงผลเพิ่มเติมแบบใช้สาย แบบไร้สาย หรือแบบฝัง การใช้งานอุปกรณ์ต้องใช้ Display Manager API ตามที่อธิบายไว้ในเอกสารประกอบ Android SDK [แหล่งข้อมูล, 84]
7.2. อุปกรณ์อินพุต
อุปกรณ์ต้องรองรับหน้าจอสัมผัสหรือเป็นไปตามข้อกำหนดที่ระบุไว้ใน 7.2.2 สำหรับการนำทางแบบไม่สัมผัส
7.2.1. แป้นพิมพ์
การติดตั้งใช้งาน Android Watch และ Android Automotive อาจใช้แป้นพิมพ์เสมือนจริง การติดตั้งใช้งานอุปกรณ์อื่นๆ ทั้งหมดต้องใช้แป้นพิมพ์บนหน้าจอและมีคุณสมบัติดังนี้
การติดตั้งใช้งานอุปกรณ์
- ต้องรองรับเฟรมเวิร์กการจัดการอินพุต (ซึ่งช่วยให้นักพัฒนาแอปบุคคลที่สามสร้างเครื่องมือแก้ไขวิธีการป้อนข้อมูลได้ เช่น แป้นพิมพ์เสมือนจริง) ตามที่ระบุไว้อย่างละเอียดที่ http://developer.android.com
- ต้องระบุการใช้งานแป้นพิมพ์บนหน้าจออย่างน้อย 1 รายการ (ไม่ว่าจะมีแป้นพิมพ์จริงหรือไม่ก็ตาม) ยกเว้นอุปกรณ์ Android Watch ที่ขนาดหน้าจอทำให้การมีแป้นพิมพ์บนหน้าจอไม่เหมาะสม
- อาจรวมถึงการติดตั้งใช้งานแป้นพิมพ์เสมือนเพิ่มเติม
- อาจรวมแป้นพิมพ์ฮาร์ดแวร์
- ต้องไม่มีแป้นพิมพ์ฮาร์ดแวร์ที่ไม่ตรงกับรูปแบบใดรูปแบบหนึ่งที่ระบุไว้ใน android.content.res.Configuration.keyboard [Resources, 85] (QWERTY หรือ 12 ปุ่ม)
7.2.2. การนำทางแบบไม่สัมผัส
อุปกรณ์ Android Television ต้องใช้ปุ่ม D-pad
การติดตั้งใช้งานอุปกรณ์
- อาจละเว้นตัวเลือกการไปยังส่วนต่างๆ ที่ไม่ใช้การสัมผัส (แทร็กบอล แป้นบังคับทิศทาง หรือล้อ) หากการใช้งานอุปกรณ์ไม่ใช่อุปกรณ์ Android Television
- ต้องรายงานค่าที่ถูกต้องสำหรับ android.content.res.Configuration.navigation [Resources, 85]
- ต้องจัดให้มีกลไกอินเทอร์เฟซผู้ใช้ทางเลือกที่สมเหตุสมผลสำหรับการเลือกและแก้ไขข้อความ ซึ่งเข้ากันได้กับเครื่องมือจัดการอินพุต การใช้งานโอเพนซอร์สของ Android เวอร์ชัน upstream มีกลไกการเลือกที่เหมาะสมสำหรับใช้กับอุปกรณ์ที่ไม่มีอินพุตการไปยังส่วนต่างๆ ที่ไม่ใช้การสัมผัส
7.2.3. ปุ่มนำทาง
ความพร้อมใช้งานและข้อกำหนดการแสดงผลของฟังก์ชันหน้าแรก ล่าสุด และกลับจะแตกต่างกันไปตามประเภทอุปกรณ์ตามที่อธิบายไว้ในส่วนนี้
ฟังก์ชันหน้าแรก ล่าสุด และย้อนกลับ (แมปกับเหตุการณ์คีย์ KEYCODE_HOME, KEYCODE_APP_SWITCH, KEYCODE_BACK ตามลำดับ) เป็นฟังก์ชันที่จำเป็นต่อรูปแบบการนําทางของ Android ดังนั้น
- การติดตั้งใช้งานอุปกรณ์ Android แบบพกพาต้องมีฟังก์ชันหน้าแรก ล่าสุด และย้อนกลับ
- การติดตั้งใช้งานอุปกรณ์ Android Television ต้องมีฟังก์ชันหน้าแรกและย้อนกลับ
- การติดตั้งใช้งานอุปกรณ์ Android Watch ต้องมีฟังก์ชันหน้าแรกสำหรับผู้ใช้และฟังก์ชันกลับ ยกเว้นในกรณีที่อยู่ใน UI_MODE_TYPE_WATCH
- การติดตั้งใช้งาน Android Automotive ต้องมีฟังก์ชันหน้าแรก และอาจมีฟังก์ชันย้อนกลับและล่าสุด
- การติดตั้งใช้งานอุปกรณ์ประเภทอื่นๆ ทั้งหมดต้องมีฟังก์ชันหน้าแรกและย้อนกลับ
ฟังก์ชันเหล่านี้อาจใช้ผ่านปุ่มจริงเฉพาะ (เช่น ปุ่มสัมผัสแบบกลไกหรือแบบ Capacitive) หรืออาจใช้ผ่านแป้นซอฟต์แวร์เฉพาะในส่วนต่างๆ ของหน้าจอ ท่าทางสัมผัส แผงสัมผัส ฯลฯ Android รองรับการใช้งานทั้ง 2 แบบ ฟังก์ชันเหล่านี้ทั้งหมดต้องเข้าถึงได้ด้วยการดำเนินการเพียงครั้งเดียว (เช่น แตะ ดับเบิลคลิก หรือท่าทางสัมผัส) เมื่อมองเห็น
ฟังก์ชันล่าสุด (หากมี) ต้องมีปุ่มหรือไอคอนที่มองเห็นได้ เว้นแต่ว่าจะถูกซ่อนไว้ ควบคู่ไปกับฟังก์ชันการไปยังส่วนต่างๆ อื่นๆ ในโหมดเต็มหน้าจอ การดำเนินการนี้จะไม่มีผลกับอุปกรณ์ที่อัปเกรดจาก Android เวอร์ชันเก่าซึ่งมีปุ่มสำหรับการไปยังส่วนต่างๆ ของหน้าจอและไม่มีปุ่มรายการล่าสุด
ฟังก์ชันหน้าแรกและกลับ (หากมี) ต้องมีปุ่มหรือไอคอนที่มองเห็นได้ เว้นแต่จะซ่อนไว้พร้อมกับฟังก์ชันการไปยังส่วนต่างๆ อื่นๆ ในโหมดเต็มหน้าจอ หรือเมื่อตั้งค่า uiMode UI_MODE_TYPE_MASK เป็น UI_MODE_TYPE_WATCH
ฟังก์ชันเมนูเลิกใช้งานแล้วตั้งแต่ Android 4.0 เปลี่ยนไปใช้แถบการดำเนินการแทน ดังนั้น การติดตั้งใช้งานอุปกรณ์ใหม่ที่ใช้ Android 6.0 ขึ้นไปต้องไม่ใช้ปุ่มกดเฉพาะสำหรับฟังก์ชันเมนู การติดตั้งใช้งานอุปกรณ์รุ่นเก่าไม่ควรใช้ปุ่มบนตัวเครื่องสำหรับฟังก์ชันเมนูโดยเฉพาะ แต่หากมีการใช้ปุ่มเมนูบนตัวเครื่องและอุปกรณ์กำลังเรียกใช้แอปพลิเคชันที่มี targetSdkVersion มากกว่า 10 การติดตั้งใช้งานอุปกรณ์จะมีลักษณะดังนี้
- ต้องแสดงปุ่มรายการเพิ่มเติมของการดำเนินการในแถบการดำเนินการเมื่อมองเห็นได้ และป๊อปอัปเมนูรายการเพิ่มเติมของการดำเนินการที่ปรากฏขึ้นจะต้องไม่ว่างเปล่า สำหรับการติดตั้งใช้งานในอุปกรณ์ที่เปิดตัวก่อน Android 4.4 แต่อัปเกรดเป็น Android 6.0 เราขอแนะนำให้ใช้ตัวเลือกนี้
- ต้องไม่แก้ไขตําแหน่งของป๊อปอัปรายการเพิ่มเติมของการดำเนินการที่แสดงโดยการเลือกปุ่มรายการเพิ่มเติมในแถบการดำเนินการ
- อาจแสดงผลป๊อปอัปการทำงานเพิ่มเติมในตำแหน่งที่แก้ไขแล้วบนหน้าจอเมื่อแสดงโดยเลือกปุ่มเมนูจริง
การติดตั้งใช้งานอุปกรณ์ต้องทําให้ฟังก์ชันเมนูพร้อมใช้งานสําหรับแอปพลิเคชันเมื่อ targetSdkVersion น้อยกว่า 10 ไม่ว่าจะใช้ปุ่มจริง ปุ่มซอฟต์แวร์ หรือท่าทางสัมผัสก็ตาม เพื่อรองรับการใช้งานย้อนหลัง ฟังก์ชันเมนูนี้ควรแสดงขึ้น เว้นแต่จะซ่อนไว้พร้อมกับฟังก์ชันการไปยังส่วนต่างๆ อื่นๆ
การใช้งานอุปกรณ์ Android ที่รองรับการดำเนินการของ Assist [แหล่งข้อมูล, 30] จะต้องเข้าถึงการดำเนินการนี้ได้ด้วยการดําเนินการเพียงครั้งเดียว (เช่น แตะ ดับเบิลคลิก หรือท่าทางสัมผัส) เมื่อปุ่มการนําทางอื่นๆ ปรากฏอยู่ และขอแนะนําอย่างยิ่งให้ใช้การกดปุ่มหน้าแรกหรือปุ่มซอฟต์แวร์ค้างไว้เป็นการดําเนินการเพียงครั้งเดียว
การติดตั้งใช้งานอุปกรณ์อาจใช้ส่วนต่างๆ ของหน้าจอเพื่อแสดงปุ่มการไปยังส่วนต่างๆ แต่หากเป็นเช่นนั้น อุปกรณ์ต้องเป็นไปตามข้อกำหนดต่อไปนี้
- ปุ่มการไปยังส่วนต่างๆ ของการใช้งานอุปกรณ์ต้องใช้พื้นที่บนหน้าจอที่แยกต่างหาก ซึ่งแอปพลิเคชันไม่สามารถเข้าถึงได้ และต้องไม่บดบังหรือรบกวนพื้นที่บนหน้าจอที่แอปพลิเคชันเข้าถึงได้
- การติดตั้งใช้งานอุปกรณ์ต้องจัดสรรพื้นที่ส่วนหนึ่งของจอแสดงผลให้กับแอปพลิเคชันที่เป็นไปตามข้อกำหนดที่ระบุไว้ในส่วนที่ 7.1.1
- การติดตั้งใช้งานอุปกรณ์ต้องแสดงปุ่มการนําทางเมื่อแอปพลิเคชันไม่ได้ระบุโหมด UI ของระบบ หรือไม่ได้ระบุ SYSTEM_UI_FLAG_VISIBLE
- การติดตั้งใช้งานอุปกรณ์ต้องแสดงปุ่มการไปยังส่วนต่างๆ ในโหมด "โหมดใช้งานน้อย" (เช่น สลัว) ที่ไม่รบกวนเมื่อแอปพลิเคชันระบุ SYSTEM_UI_FLAG_LOW_PROFILE
- การติดตั้งใช้งานอุปกรณ์ต้องซ่อนปุ่มการนําทางเมื่อแอปพลิเคชันระบุ SYSTEM_UI_FLAG_HIDE_NAVIGATION
7.2.4. การป้อนข้อมูลด้วยหน้าจอสัมผัส
อุปกรณ์มือถือและนาฬิกา Android ต้องใช้อินพุตหน้าจอสัมผัส
การติดตั้งใช้งานอุปกรณ์ควรมีระบบการป้อนข้อมูลด้วยเคอร์เซอร์บางประเภท (แบบเมาส์หรือแบบสัมผัส) อย่างไรก็ตาม หากการติดตั้งใช้งานอุปกรณ์ไม่รองรับระบบอินพุตเคอร์เซอร์ อุปกรณ์ต้องไม่รายงานค่าคงที่ของฟีเจอร์ android.hardware.touchscreen หรือ android.hardware.faketouch การใช้งานอุปกรณ์ที่มีระบบอินพุตเคอร์เซอร์
- ควรรองรับเคอร์เซอร์ที่ติดตามอย่างอิสระได้อย่างเต็มที่ หากระบบอินพุตของอุปกรณ์รองรับเคอร์เซอร์หลายตัว
- ต้องรายงานค่าของ android.content.res.Configuration.touchscreen [Resources, 85] ที่สอดคล้องกับประเภทของหน้าจอสัมผัสที่เฉพาะเจาะจงในอุปกรณ์
Android รองรับหน้าจอสัมผัส แท็บเล็ตสัมผัส และอุปกรณ์อินพุตแบบสัมผัสจำลองที่หลากหลาย การใช้งานอุปกรณ์ที่ใช้หน้าจอสัมผัสจะเชื่อมโยงกับจอแสดงผล [แหล่งข้อมูล, 86] เพื่อให้ผู้ใช้รู้สึกว่าได้โต้ตอบกับรายการต่างๆ บนหน้าจอโดยตรง เนื่องจากผู้ใช้สัมผัสหน้าจอโดยตรง ระบบจึงไม่จำเป็นต้องมีสิ่งอำนวยความสะดวกเพิ่มเติมเพื่อระบุวัตถุที่กำลังมีการจัดการ ในทางตรงกันข้าม อินเทอร์เฟซการสัมผัสจำลองมีระบบการป้อนข้อมูลของผู้ใช้ซึ่งใกล้เคียงกับความสามารถของหน้าจอสัมผัสเพียงบางส่วน เช่น เมาส์หรือรีโมตคอนโทรลที่ควบคุมเคอร์เซอร์บนหน้าจอจะคล้ายกับการสัมผัส แต่กำหนดให้ผู้ใช้ต้องชี้หรือโฟกัสก่อนแล้วจึงคลิก อุปกรณ์อินพุตจำนวนมาก เช่น เมาส์ แทร็กแพด เมาส์ไร้สายแบบใช้แรงโน้มถ่วง ชี้เซอร์แบบใช้แรงโน้มถ่วง จอยสติ๊ก และแทร็กแพดแบบมัลติทัช รองรับการโต้ตอบแบบสัมผัสจำลอง Android มีค่าคงที่ของฟีเจอร์ android.hardware.faketouch ซึ่งสอดคล้องกับอุปกรณ์อินพุตแบบไม่สัมผัส (อิงตามเคอร์เซอร์) ที่มีความเที่ยงตรงสูง เช่น เมาส์หรือแทร็กแพด ซึ่งสามารถจําลองอินพุตแบบสัมผัสได้อย่างเพียงพอ (รวมถึงการรองรับท่าทางสัมผัสพื้นฐาน) และบ่งชี้ว่าอุปกรณ์รองรับฟังก์ชันการทำงานของหน้าจอสัมผัสชุดย่อยที่จำลอง การติดตั้งใช้งานอุปกรณ์ที่ประกาศฟีเจอร์การแตะจำลองต้องเป็นไปตามข้อกำหนดการแตะจำลองในส่วนที่ 7.2.5
การติดตั้งใช้งานอุปกรณ์ต้องรายงานฟีเจอร์ที่ถูกต้องซึ่งสอดคล้องกับประเภทอินพุตที่ใช้ การติดตั้งใช้งานอุปกรณ์ที่มีหน้าจอสัมผัส (แบบสัมผัสเดียวหรือดีกว่า) จะต้องรายงานค่าคงที่ของฟีเจอร์แพลตฟอร์ม android.hardware.touchscreen การติดตั้งใช้งานอุปกรณ์ที่รายงานค่าคงที่ของแพลตฟอร์มฟีเจอร์ android.hardware.touchscreen จะต้องรายงานค่าคงที่ของแพลตฟอร์มฟีเจอร์ android.hardware.faketouch ด้วย การติดตั้งใช้งานอุปกรณ์ที่ไม่มีหน้าจอสัมผัส (และใช้อุปกรณ์ชี้ตำแหน่งเท่านั้น) ต้องไม่รายงานฟีเจอร์หน้าจอสัมผัสใดๆ และต้องรายงานเฉพาะ android.hardware.faketouch หากเป็นไปตามข้อกำหนดการแตะจำลองในส่วนที่ 7.2.5
7.2.5. การป้อนข้อมูลด้วยการสัมผัสจำลอง
การติดตั้งใช้งานอุปกรณ์ที่ประกาศรองรับ android.hardware.faketouch
- ต้องรายงานตำแหน่งสัมบูรณ์ X และ Y ของหน้าจอของตำแหน่งเคอร์เซอร์ และแสดงเคอร์เซอร์ที่มองเห็นได้บนหน้าจอ [แหล่งข้อมูล, 87]
- ต้องรายงานเหตุการณ์การสัมผัสด้วยรหัสการดำเนินการที่ระบุการเปลี่ยนแปลงสถานะที่เกิดขึ้นเมื่อเคอร์เซอร์เลื่อนขึ้นหรือลงบนหน้าจอ [แหล่งข้อมูล, 87]
- ต้องรองรับการกดเคอร์เซอร์ลงและขึ้นบนวัตถุบนหน้าจอ ซึ่งช่วยให้ผู้ใช้สามารถจำลองการแตะวัตถุบนหน้าจอได้
- ต้องรองรับการกดเคอร์เซอร์ลง การกดเคอร์เซอร์ขึ้น การกดเคอร์เซอร์ลงแล้วกดเคอร์เซอร์ขึ้นอีกครั้งในตำแหน่งเดียวกันบนวัตถุบนหน้าจอภายในเกณฑ์เวลา ซึ่งช่วยให้ผู้ใช้สามารถจำลองการแตะสองครั้งที่วัตถุบนหน้าจอได้ [แหล่งข้อมูล, 87]
- ต้องรองรับการกดเคอร์เซอร์ลงที่จุดใดก็ได้บนหน้าจอ การย้ายเคอร์เซอร์ไปยังจุดใดก็ได้บนหน้าจอ ตามด้วยการกดเคอร์เซอร์ขึ้น ซึ่งจะช่วยให้ผู้ใช้จําลองการลากด้วยการแตะได้
- ต้องรองรับการกดแป้นลูกศรลง จากนั้นอนุญาตให้ผู้ใช้ย้ายวัตถุไปยังตำแหน่งอื่นบนหน้าจออย่างรวดเร็ว แล้วกดแป้นลูกศรขึ้นบนหน้าจอ ซึ่งจะช่วยให้ผู้ใช้เหวี่ยงวัตถุบนหน้าจอได้
อุปกรณ์ที่ประกาศรองรับ android.hardware.faketouch.multitouch.distinct ต้องเป็นไปตามข้อกําหนดสําหรับฟีเจอร์การแตะเสมือนจริงข้างต้น และต้องรองรับการติดตามอินพุตเคอร์เซอร์อิสระอย่างน้อย 2 รายการด้วย
7.2.6. การรองรับเกมคอนโทรลเลอร์
การใช้งานอุปกรณ์ Android Television จะต้องรองรับการแมปปุ่มสำหรับตัวควบคุมเกมตามที่ระบุไว้ด้านล่าง การติดตั้งใช้งาน Android เวอร์ชัน upstream นั้นรวมถึงการติดตั้งใช้งานสำหรับตัวควบคุมเกมที่เป็นไปตามข้อกำหนดนี้
7.2.6.1. การแมปปุ่ม
การติดตั้งใช้งานอุปกรณ์ Android Television ต้องรองรับการแมปคีย์ต่อไปนี้
ปุ่ม | การใช้งาน 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) |
Home1 | 0x0c 0x0223 | KEYCODE_HOME (3) |
กลับ1 | 0x0c 0x0224 | KEYCODE_BACK (4) |
1 [Resources, 88]
2 การใช้งาน HID ข้างต้นต้องประกาศภายใน CA ของเกมแพด (0x01 0x0005)
3 การใช้งานนี้ต้องมีค่าต่ำสุดเชิงตรรกะ 0, ค่าสูงสุดเชิงตรรกะ 7, ค่าต่ำสุดเชิงกายภาพ 0, ค่าสูงสุดเชิงกายภาพ 315, หน่วยเป็นองศา และขนาดรายงาน 4 ค่าตรรกะจะกำหนดให้เป็นการหมุนตามเข็มนาฬิกาออกจากแกนแนวตั้ง เช่น ค่าตรรกะ 0 แสดงถึงการไม่หมุนและการกดปุ่มขึ้น ส่วนค่าตรรกะ 1 แสดงการหมุน 45 องศาและการกดทั้งแป้นขึ้นและซ้าย
4 [Resources, 87]
การควบคุมแบบแอนะล็อก1 | การใช้งาน HID | ปุ่ม Android |
---|---|---|
ทริกเกอร์ซ้าย | 0x02 0x00C5 | AXIS_LTRIGGER |
ทริกเกอร์ขวา | 0x02 0x00C4 | AXIS_RTRIGGER |
จอยสติ๊กซ้าย | 0x01 0x0030 0x01 0x0031 |
AXIS_X AXIS_Y |
จอยสติ๊กขวา | 0x01 0x0032 0x01 0x0035 |
AXIS_Z AXIS_RZ |
1 [Resources, 87]
7.2.7. การควบคุมระยะไกล
การติดตั้งใช้งานอุปกรณ์ Android Television ควรมีรีโมตคอนโทรลเพื่อให้ผู้ใช้เข้าถึงอินเทอร์เฟซทีวีได้ รีโมตคอนโทรลอาจเป็นรีโมตจริงหรือรีโมตที่ใช้ซอฟต์แวร์ซึ่งเข้าถึงได้จากโทรศัพท์มือถือหรือแท็บเล็ต รีโมตคอนโทรลต้องเป็นไปตามข้อกำหนดที่ระบุไว้ด้านล่าง
- Search affordance การติดตั้งใช้งานอุปกรณ์ต้องเรียกใช้ KEYCODE_SEARCH (หรือ KEYCODE_ASSIST หากอุปกรณ์รองรับผู้ช่วย) เมื่อผู้ใช้เรียกใช้การค้นหาด้วยเสียงบนรีโมตแบบมีตัวตนหรือแบบซอฟต์แวร์
- การไปยังส่วนต่างๆ รีโมตทีวี Android ทั้งหมดต้องมีปุ่มย้อนกลับ หน้าแรก และเลือก รวมถึงรองรับเหตุการณ์ D-pad [แหล่งข้อมูล, 88]
7.3. เซ็นเซอร์
Android มี API สําหรับการเข้าถึงเซ็นเซอร์หลายประเภท โดยทั่วไปการติดตั้งใช้งานอุปกรณ์อาจไม่รวมเซ็นเซอร์เหล่านี้ตามที่ระบุไว้ในส่วนย่อยต่อไปนี้ หากอุปกรณ์มีเซ็นเซอร์บางประเภทที่มี API ที่สอดคล้องกันสำหรับนักพัฒนาแอปบุคคลที่สาม การติดตั้งใช้งานอุปกรณ์ต้องติดตั้งใช้งาน API ดังกล่าวตามที่อธิบายไว้ในเอกสารประกอบของ Android SDK และเอกสารประกอบโอเพนซอร์สของ Android เกี่ยวกับเซ็นเซอร์ [แหล่งข้อมูล, 89] เช่น การติดตั้งใช้งานอุปกรณ์
- ต้องรายงานการมีอยู่หรือไม่มีอยู่ของเซ็นเซอร์อย่างถูกต้องตามคลาส android.content.pm.PackageManager [Resources, 70]
- ต้องแสดงรายการเซ็นเซอร์ที่รองรับที่ถูกต้องผ่าน SensorManager.getSensorList() และเมธอดที่คล้ายกัน
- ต้องทํางานอย่างสมเหตุสมผลสําหรับ API เซ็นเซอร์อื่นๆ ทั้งหมด (เช่น แสดงผลเป็น "จริง" หรือ "เท็จ" ตามเหมาะสมเมื่อแอปพลิเคชันพยายามลงทะเบียนตัวรับฟัง ไม่เรียกใช้ตัวรับฟังเซ็นเซอร์เมื่อไม่มีเซ็นเซอร์ที่เกี่ยวข้อง เป็นต้น)
- ต้องรายงานค่าการวัดจากเซ็นเซอร์ทั้งหมดโดยใช้ค่าระบบหน่วยวัดระหว่างประเทศ (เมตริก) ที่เกี่ยวข้องสำหรับเซ็นเซอร์แต่ละประเภทตามที่ระบุไว้ในเอกสารประกอบ Android SDK [แหล่งข้อมูล, 90]
- ควรรายงานเวลาของเหตุการณ์เป็นนาโนวินาทีตามที่ระบุไว้ในเอกสารประกอบของ Android SDK ซึ่งแสดงถึงเวลาที่เกิดเหตุการณ์และซิงค์กับนาฬิกา SystemClock.elapsedRealtimeNano() เราขอแนะนำอย่างยิ่งให้อุปกรณ์ Android ทั้งรุ่นเก่าและรุ่นใหม่มีคุณสมบัติตรงตามข้อกำหนดเหล่านี้เพื่อให้อัปเกรดเป็นแพลตฟอร์มรุ่นถัดไปได้ ซึ่งอาจต้องใช้คอมโพเนนต์นี้ ข้อผิดพลาดในการซิงค์ควรน้อยกว่า 100 มิลลิวินาที [แหล่งข้อมูล 91]
- ต้องรายงานข้อมูลเซ็นเซอร์โดยมีความล่าช้าสูงสุด 100 มิลลิวินาที + 2 * sample_time ในกรณีที่มีการสตรีมเซ็นเซอร์ โดยมีเวลาในการตอบสนองขั้นต่ำที่ต้องการ 5 มิลลิวินาที + 2 * sample_time เมื่อตัวประมวลผลแอปพลิเคชันทำงานอยู่ ความล่าช้านี้ไม่รวมความล่าช้าในการกรอง
- ต้องรายงานตัวอย่างเซ็นเซอร์แรกภายใน 400 มิลลิวินาที + 2 * sample_time ของเซ็นเซอร์ที่เปิดใช้งาน ตัวอย่างนี้มีความแม่นยำ 0 ได้
รายการข้างต้นเป็นเพียงตัวอย่างบางส่วน ลักษณะการทำงานที่บันทึกไว้ของ Android SDK และเอกสารประกอบโอเพนซอร์สของ Android เกี่ยวกับเซ็นเซอร์ [แหล่งข้อมูล, 89] ถือว่าเป็นข้อมูลที่น่าเชื่อถือ
เซ็นเซอร์บางประเภทเป็นแบบผสม ซึ่งหมายความว่าสามารถมาจากข้อมูลที่ได้จากเซ็นเซอร์อื่นๆ อย่างน้อย 1 ตัว (เช่น เซ็นเซอร์การวางแนวและเซ็นเซอร์ความเร่งเชิงเส้น) การติดตั้งใช้งานอุปกรณ์ควรใช้เซ็นเซอร์ประเภทเหล่านี้เมื่อรวมเซ็นเซอร์ทางกายภาพที่จำเป็นตามที่อธิบายไว้ใน [แหล่งข้อมูล, 92] หากการติดตั้งใช้งานอุปกรณ์มีเซ็นเซอร์คอมโพสิต อุปกรณ์นั้นต้องใช้เซ็นเซอร์ตามที่อธิบายไว้ในเอกสารประกอบโอเพนซอร์สของ Android เกี่ยวกับเซ็นเซอร์คอมโพสิต [แหล่งข้อมูล, 92]
เซ็นเซอร์ Android บางรุ่นรองรับโหมดทริกเกอร์ "ต่อเนื่อง" ซึ่งจะแสดงข้อมูลอย่างต่อเนื่อง [แหล่งข้อมูล, 93] สําหรับ API ที่เอกสารประกอบของ Android SDK ระบุว่าเป็นเซ็นเซอร์แบบต่อเนื่อง การติดตั้งใช้งานอุปกรณ์ต้องให้ตัวอย่างข้อมูลเป็นระยะอย่างต่อเนื่อง ซึ่งควรมีความผันผวนต่ำกว่า 3% โดยความผันผวนหมายถึงค่าเบี่ยงเบนมาตรฐานของความแตกต่างของค่าการประทับเวลาที่รายงานระหว่างเหตุการณ์ที่ต่อเนื่องกัน
โปรดทราบว่าการติดตั้งใช้งานอุปกรณ์ต้องตรวจสอบว่าสตรีมเหตุการณ์เซ็นเซอร์ต้องไม่ป้องกันไม่ให้ CPU ของอุปกรณ์เข้าสู่สถานะ "หยุดชั่วคราว" หรือตื่นจากสถานะ "หยุดชั่วคราว"
สุดท้าย เมื่อเซ็นเซอร์หลายตัวเปิดใช้งาน ปริมาณการใช้พลังงานไม่ควรเกินยอดรวมของปริมาณการใช้พลังงานที่รายงานของเซ็นเซอร์แต่ละตัว
7.3.1. ตัวตรวจวัดความเร่ง
การติดตั้งใช้งานอุปกรณ์ควรมีตัววัดความเร่งแบบ 3 แกน ขอแนะนำอย่างยิ่งให้อุปกรณ์ Android Handheld และอุปกรณ์ Android Watch มีเซ็นเซอร์นี้ หากการติดตั้งใช้งานอุปกรณ์มีตัววัดความเร่งแบบ 3 แกน อุปกรณ์จะมีลักษณะดังนี้
- ต้องติดตั้งใช้งานและรายงานเซ็นเซอร์ TYPE_ACCELEROMETER [แหล่งข้อมูล, 94]
- ต้องสามารถรายงานเหตุการณ์ได้สูงสุดที่ความถี่อย่างน้อย 50 Hz สำหรับอุปกรณ์ Android Watch เนื่องจากอุปกรณ์ดังกล่าวมีข้อจำกัดด้านพลังงานที่เข้มงวดกว่า และ 100 Hz สำหรับอุปกรณ์ประเภทอื่นๆ ทั้งหมด
- ควรรายงานเหตุการณ์อย่างน้อย 200 Hz
- ต้องเป็นไปตามระบบพิกัดเซ็นเซอร์ของ Android ตามที่ระบุไว้ใน Android API [Resources, 90]
- ต้องสามารถวัดจากการตกอย่างอิสระได้สูงสุด 4 เท่าของแรงโน้มถ่วง (4g) หรือมากกว่านั้นในแนวแกนใดก็ได้
- ต้องมีความละเอียดอย่างน้อย 12 บิตและควรมีความละเอียดอย่างน้อย 16 บิต
- ควรได้รับการปรับเทียบขณะใช้งานหากลักษณะการทำงานมีการเปลี่ยนแปลงตลอดอายุการใช้งานและได้รับการชดเชย รวมถึงเก็บพารามิเตอร์การชดเชยไว้ระหว่างการรีบูตอุปกรณ์
- ควรมีการชดเชยอุณหภูมิ
- ต้องมีค่าเบี่ยงเบนมาตรฐานไม่เกิน 0.05 m/s^ โดยค่าเบี่ยงเบนมาตรฐานควรคํานวณตามแต่ละแกนจากตัวอย่างที่รวบรวมในช่วงระยะเวลาอย่างน้อย 3 วินาทีที่อัตราการสุ่มตัวอย่างที่เร็วที่สุด
- ควรใช้เซ็นเซอร์คอมโพสิต TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER ตามที่อธิบายไว้ในเอกสาร Android SDK เราขอแนะนําอย่างยิ่งให้อุปกรณ์ Android เครื่องเก่าและใหม่ใช้เซ็นเซอร์คอมโพสิต TYPE_SIGNIFICANT_MOTION หากมีการใช้เซ็นเซอร์เหล่านี้ ปริมาณการใช้พลังงานทั้งหมดต้องน้อยกว่า 4 mW เสมอ และแต่ละเซ็นเซอร์ควรมีปริมาณการใช้พลังงานต่ำกว่า 2 mW และ 0.5 mW เมื่ออุปกรณ์อยู่ในสถานะแบบไดนามิกหรือแบบคงที่
- หากมีเซ็นเซอร์ไจโรสโคป ต้องติดตั้งใช้งานเซ็นเซอร์คอมโพสิต TYPE_GRAVITY และ TYPE_LINEAR_ACCELERATION และควรติดตั้งใช้งานเซ็นเซอร์คอมโพสิต TYPE_GAME_ROTATION_VECTOR ขอแนะนำอย่างยิ่งให้อุปกรณ์ Android ทั้งรุ่นเก่าและรุ่นใหม่ใช้เซ็นเซอร์ TYPE_GAME_ROTATION_VECTOR
- ต้องติดตั้งใช้งานเซ็นเซอร์คอมโพสิต TYPE_ROTATION_VECTOR หากมีเซ็นเซอร์ไจโรสโคปและเซ็นเซอร์แม่เหล็กรวมอยู่ด้วย
7.3.2. เครื่องวัดค่าความเข้มข้นของสนามแม่เหล็ก
การติดตั้งใช้งานอุปกรณ์ควรมีแม่เหล็กไฟฟ้า 3 แกน (เข็มทิศ) หากอุปกรณ์มีแม่เหล็ก 3 แกน อุปกรณ์จะทําสิ่งต่อไปนี้
- ต้องติดตั้งใช้งานเซ็นเซอร์ TYPE_MAGNETIC_FIELD และควรติดตั้งใช้งานเซ็นเซอร์ TYPE_MAGNETIC_FIELD_UNCALIBRATED ด้วย เราขอแนะนำอย่างยิ่งให้อุปกรณ์ Android ทั้งเครื่องเก่าและเครื่องใหม่ใช้เซ็นเซอร์ TYPE_MAGNETIC_FIELD_UNCALIBRATED
- ต้องรายงานเหตุการณ์ได้สูงสุดที่ความถี่อย่างน้อย 10 Hz และควรรายงานเหตุการณ์ได้สูงสุดที่ความถี่อย่างน้อย 50 Hz
- ต้องเป็นไปตามระบบพิกัดเซ็นเซอร์ของ Android ตามที่ระบุไว้ใน Android API [Resources, 90]
- ต้องสามารถวัดค่าระหว่าง -900 µT ถึง +900 µT ในแต่ละแกนก่อนที่จะอิ่มตัว
- ต้องมีค่าออฟเซ็ตของเหล็กแข็งน้อยกว่า 700 µT และควรมีค่าต่ำกว่า 200 µT โดยวางมาตรแม่เหล็กให้ห่างจากสนามแม่เหล็กแบบไดนามิก (เกิดจากกระแสไฟฟ้า) และแบบคงที่ (เกิดจากแม่เหล็ก)
- ต้องมีความละเอียดเท่ากับหรือหนาแน่นกว่า 0.6 µT และควรมีความละเอียดเท่ากับหรือหนาแน่นกว่า 0.2 µ
- ควรมีการชดเชยอุณหภูมิ
- ต้องรองรับการปรับเทียบออนไลน์และการชดเชยความเบี่ยงเบนของฮาร์ดเหล็ก และรักษาพารามิเตอร์การชดเชยระหว่างการรีบูตอุปกรณ์
- ต้องใช้การชดเชยด้วยเหล็กอ่อน การปรับเทียบทำได้ขณะใช้งานหรือระหว่างการผลิตอุปกรณ์
- ควรมีค่าเบี่ยงเบนมาตรฐานที่คำนวณตามแต่ละแกนจากตัวอย่างที่รวบรวมในช่วงระยะเวลาอย่างน้อย 3 วินาทีที่อัตราการสุ่มตัวอย่างเร็วที่สุด โดยไม่เกิน 0.5 µT
- ต้องใช้เซ็นเซอร์คอมโพสิต TYPE_ROTATION_VECTOR หากมีเซ็นเซอร์วัดความเร่งและเซ็นเซอร์ไจโรสโคปด้วย
- อาจใช้เซ็นเซอร์ TYPE_GEOMAGNETIC_ROTATION_VECTOR หากมีการใช้เซ็นเซอร์ตรวจจับความเร่งด้วย อย่างไรก็ตาม หากติดตั้งใช้งาน อุปกรณ์ต้องกินไฟน้อยกว่า 10 mW และต้องกินไฟน้อยกว่า 3 mW เมื่อเซ็นเซอร์ลงทะเบียนสำหรับโหมดกลุ่มที่ 10 Hz
7.3.3. GPS
การติดตั้งใช้งานอุปกรณ์ควรมีเครื่องรับสัญญาณ GPS หากการติดตั้งใช้งานอุปกรณ์มีเครื่องรับสัญญาณ GPS ก็ควรมีเทคนิค "GPS เสริม" บางรูปแบบเพื่อลดเวลาในการล็อก GPS
7.3.4. เครื่องวัดการหมุน
การติดตั้งใช้งานอุปกรณ์ควรมีไจโรสโคป (เซ็นเซอร์การเปลี่ยนแปลงเชิงมุม) อุปกรณ์ไม่ควรมีเซ็นเซอร์วัดการหมุน เว้นแต่จะมีตัวตรวจวัดความเร่งแบบ 3 แกนรวมอยู่ด้วย หากการติดตั้งใช้งานอุปกรณ์มีไจโรสโคป อุปกรณ์จะทําดังนี้
- ต้องติดตั้งใช้งานเซ็นเซอร์ TYPE_GYROSCOPE และควรติดตั้งใช้งานเซ็นเซอร์ TYPE_GYROSCOPE_UNCALIBRATED ด้วย เราขอแนะนำอย่างยิ่งให้อุปกรณ์ Android ทั้งเครื่องเก่าและเครื่องใหม่ใช้เซ็นเซอร์ SENSOR_TYPE_GYROSCOPE_UNCALIBRATED
- ต้องสามารถวัดการเปลี่ยนแปลงการวางแนวได้สูงสุด 1,000 องศาต่อวินาที
- ต้องสามารถรายงานเหตุการณ์ได้สูงสุดที่ความถี่อย่างน้อย 50 Hz สำหรับอุปกรณ์ Android Watch เนื่องจากอุปกรณ์ดังกล่าวมีข้อจำกัดด้านพลังงานที่เข้มงวดกว่า และ 100 Hz สำหรับอุปกรณ์ประเภทอื่นๆ ทั้งหมด
- ควรรายงานเหตุการณ์อย่างน้อย 200 Hz
- ต้องมีความละเอียด 12 บิตขึ้นไปและควรมีความละเอียด 16 บิตขึ้นไป
- ต้องชดเชยอุณหภูมิ
- ต้องได้รับการปรับเทียบและชดเชยขณะใช้งาน และเก็บพารามิเตอร์การชดเชยไว้ระหว่างการรีบูตอุปกรณ์
- ต้องมีความแปรปรวนไม่เกิน 1e-7 rad^2 / s^2 ต่อ Hz (ความแปรปรวนต่อ Hz หรือ rad^2 / s) อนุญาตให้ความแปรปรวนเปลี่ยนแปลงตามอัตราการสุ่มตัวอย่าง แต่ต้องถูกจำกัดด้วยค่านี้ กล่าวคือ หากคุณวัดความแปรปรวนของgyroที่อัตราตัวอย่าง 1 Hz ค่าไม่ควรเกิน 1e-7 rad^2/s^2
- ต้องใช้เซ็นเซอร์คอมโพสิต TYPE_ROTATION_VECTOR หากมีเซ็นเซอร์วัดความเร่งและเซ็นเซอร์แม่เหล็กรวมอยู่ด้วย
- หากมีเซ็นเซอร์วัดความเร่ง ต้องติดตั้งใช้งานเซ็นเซอร์คอมโพสิต TYPE_GRAVITY และ TYPE_LINEAR_ACCELERATION และควรติดตั้งใช้งานเซ็นเซอร์คอมโพสิต TYPE_GAME_ROTATION_VECTOR ขอแนะนำอย่างยิ่งให้อุปกรณ์ Android ทั้งรุ่นเก่าและรุ่นใหม่ใช้เซ็นเซอร์ TYPE_GAME_ROTATION_VECTOR
7.3.5. บารอมิเตอร์
การติดตั้งใช้งานอุปกรณ์ควรมีบารอมิเตอร์ (เซ็นเซอร์ความดันอากาศรอบตัว) หากการติดตั้งใช้งานอุปกรณ์มีบารอมิเตอร์ อุปกรณ์จะทําสิ่งต่อไปนี้
- ต้องติดตั้งใช้งานและรายงานเซ็นเซอร์ TYPE_PRESSURE
- ต้องส่งเหตุการณ์ที่ 5 Hz ขึ้นไปได้
- ต้องมีความแม่นยำเพียงพอเพื่อให้สามารถประมาณระดับความสูงได้
- ต้องชดเชยอุณหภูมิ
7.3.6. เทอร์โมมิเตอร์
การติดตั้งใช้งานอุปกรณ์อาจรวมถึงเทอร์โมมิเตอร์วัดอุณหภูมิแวดล้อม (เซ็นเซอร์อุณหภูมิ) หากมี จะต้องกำหนดเป็น SENSOR_TYPE_AMBIENT_TEMPERATURE และต้องวัดอุณหภูมิแวดล้อม (ห้อง) เป็นองศาเซลเซียส
การติดตั้งใช้งานอุปกรณ์อาจ (แต่ไม่ควร) มีเซ็นเซอร์อุณหภูมิ CPU หากมี ต้องกำหนดเป็น SENSOR_TYPE_TEMPERATURE ต้องวัดอุณหภูมิของ CPU ของอุปกรณ์ และต้องไม่วัดอุณหภูมิอื่นๆ โปรดทราบว่าประเภทเซ็นเซอร์ SENSOR_TYPE_TEMPERATURE ถูกเลิกใช้งานใน Android 4.0
7.3.7. โฟโตมิเตอร์
การติดตั้งใช้งานอุปกรณ์อาจรวมถึงโฟโตมิเตอร์ (เซ็นเซอร์แสงแวดล้อม)
7.3.8. พร็อกซิมิตีเซ็นเซอร์
การติดตั้งใช้งานอุปกรณ์อาจรวมถึงพร็อกซิมิตีเซ็นเซอร์ อุปกรณ์ที่โทรออกได้และระบุค่าอื่นที่ไม่ใช่ PHONE_TYPE_NONE ใน getPhoneType ควรมีเซ็นเซอร์ตรวจหาบุคคลในบริเวณใกล้เคียง หากการติดตั้งใช้งานอุปกรณ์มีพร็อกซิมิตีเซ็นเซอร์ อุปกรณ์จะทําสิ่งต่อไปนี้
- ต้องวัดระยะใกล้ของวัตถุในทิศทางเดียวกับหน้าจอ กล่าวคือ เซ็นเซอร์ตรวจจับบุคคลในบริเวณใกล้เคียงต้องอยู่ในทิศทางที่ตรวจจับวัตถุที่อยู่ใกล้กับหน้าจอได้ เนื่องจากวัตถุประสงค์หลักของเซ็นเซอร์ประเภทนี้คือการตรวจจับโทรศัพท์ที่ผู้ใช้กำลังใช้อยู่ หากการติดตั้งใช้งานอุปกรณ์มีพร็อกซิมิตีเซ็นเซอร์ที่มีการวางแนวอื่น อุปกรณ์ต้องเข้าถึงผ่าน API นี้ไม่ได้
- ต้องมีความละเอียดอย่างน้อย 1 บิต
7.3.9. เซ็นเซอร์ความแม่นยำสูง
การติดตั้งใช้งานอุปกรณ์ที่รองรับชุดเซ็นเซอร์คุณภาพสูงขึ้นซึ่งสามารถปฏิบัติตามข้อกำหนดทั้งหมดที่ระบุไว้ในส่วนนี้ต้องระบุการรองรับผ่านandroid.hardware.sensor.hifi_sensors
Flag ฟีเจอร์
อุปกรณ์ที่ประกาศ android.hardware.sensor.hifi_sensors จะต้องรองรับเซ็นเซอร์ประเภทต่อไปนี้ทั้งหมดที่เป็นไปตามข้อกำหนดด้านคุณภาพดังต่อไปนี้
- SENSOR_TYPE_ACCELEROMETER
- ต้องมีช่วงการวัดระหว่าง -8 ถึง +8 กรัมเป็นอย่างน้อย
- ต้องมีความละเอียดในการวัดอย่างน้อย 1024 LSB/G
- ต้องมีความถี่การวัดขั้นต่ำ 12.5 Hz หรือต่ำกว่า
- ต้องมีความถี่การวัดสูงสุด 200 เฮิร์ตซ์ขึ้นไป
- ต้องมีสัญญาณรบกวนในการวัดไม่เกิน 400uG/√Hz
- ต้องใช้เซ็นเซอร์รูปแบบที่ไม่มีการตื่นขึ้นของเซ็นเซอร์นี้โดยมีความจุการบัฟเฟอร์อย่างน้อย 3,000 เหตุการณ์ของเซ็นเซอร์
- ต้องมีการใช้พลังงานในการแบ่งกลุ่มที่ดีกว่า 3 mW
- SENSOR_TYPE_GYROSCOPE
- ต้องมีช่วงการวัดระหว่าง -1,000 ถึง +1,000 dps เป็นอย่างน้อย
- ต้องมีความละเอียดในการวัดอย่างน้อย 16 LSB/dps
- ต้องมีความถี่การวัดขั้นต่ำ 12.5 Hz หรือต่ำกว่า
- ต้องมีความถี่การวัดสูงสุด 200 เฮิร์ตซ์ขึ้นไป
- ต้องมีสัญญาณรบกวนการวัดไม่เกิน 0.014°/วินาที/√Hz
- SENSOR_TYPE_GYROSCOPE_UNCALIBRATED ที่มีข้อกำหนดด้านคุณภาพเหมือนกับ SENSOR_TYPE_GYROSCOPE
- SENSOR_TYPE_GEOMAGNETIC_FIELD
- ต้องมีช่วงการวัดระหว่าง -900 ถึง +900 uT เป็นอย่างน้อย
- ต้องมีความละเอียดในการวัดอย่างน้อย 5 LSB/uT
- ต้องมีความถี่การวัดขั้นต่ำ 5 Hz หรือต่ำกว่า
- ต้องมีความถี่การวัดสูงสุด 50 เฮิรตซ์ขึ้นไป
- ต้องมีสัญญาณรบกวนการวัดไม่เกิน 0.5 uT
- SENSOR_TYPE_MAGNETIC_FIELD_UNCALIBRATED มีข้อกำหนดด้านคุณภาพเหมือนกับ SENSOR_TYPE_GEOMAGNETIC_FIELD และข้อกำหนดเพิ่มเติมคือ
- ต้องใช้เซ็นเซอร์รูปแบบที่ไม่มีการตื่นขึ้นซึ่งสามารถบัฟเฟอร์เหตุการณ์ของเซ็นเซอร์ได้อย่างน้อย 600 รายการ
- SENSOR_TYPE_PRESSURE
- ต้องมีช่วงการวัดระหว่าง 300 ถึง 1,100 hPa เป็นอย่างน้อย
- ต้องมีความละเอียดในการวัดอย่างน้อย 80 LSB/hPa
- ต้องมีความถี่การวัดขั้นต่ำ 1 Hz หรือต่ำกว่า
- ต้องมีความถี่การวัดสูงสุด 10 Hz ขึ้นไป
- ต้องมีสัญญาณรบกวนการวัดไม่เกิน 2 Pa/√Hz
- ต้องใช้เซ็นเซอร์รูปแบบที่ไม่มีการตื่นขึ้นซึ่งสามารถบัฟเฟอร์เหตุการณ์เซ็นเซอร์ได้อย่างน้อย 300 รายการ
- ต้องมีปริมาณการใช้พลังงานในการแบ่งกลุ่มที่ไม่เกิน 2 mW
- TYPE_GAME_ROTATION_VECTOR
- ต้องใช้เซ็นเซอร์รูปแบบที่ไม่มีการตื่นขึ้นของเซ็นเซอร์นี้โดยมีความจุการบัฟเฟอร์อย่างน้อย 300 เหตุการณ์ของเซ็นเซอร์
- ต้องมีอัตราการใช้พลังงานในการแบ่งกลุ่มที่ดีกว่า 4 mW
- SENSOR_TYPE_SIGNIFICANT_MOTION
- ต้องมีอัตราการใช้พลังงานไม่เกิน 0.5 mW เมื่ออุปกรณ์ไม่มีการเคลื่อนไหว และ 1.5 mW เมื่ออุปกรณ์มีการเคลื่อนไหว
- SENSOR_TYPE_STEP_DETECTOR
- ต้องใช้เซ็นเซอร์รูปแบบที่ไม่มีการตื่นขึ้นของเซ็นเซอร์นี้โดยมีความจุการบัฟเฟอร์ของเหตุการณ์เซ็นเซอร์อย่างน้อย 100 รายการ
- ต้องมีอัตราการใช้พลังงานไม่เกิน 0.5 mW เมื่ออุปกรณ์ไม่มีการเคลื่อนไหว และ 1.5 mW เมื่ออุปกรณ์มีการเคลื่อนไหว
- ปริมาณการใช้พลังงานในการแบ่งกลุ่มต้องไม่แย่กว่า 4 mW
- SENSOR_TYPE_STEP_COUNTER
- ต้องมีอัตราการใช้พลังงานไม่เกิน 0.5 mW เมื่ออุปกรณ์ไม่มีการเคลื่อนไหว และ 1.5 mW เมื่ออุปกรณ์มีการเคลื่อนไหว
- SENSOR_TILT_DETECTOR
- ต้องมีอัตราการใช้พลังงานไม่เกิน 0.5 mW เมื่ออุปกรณ์ไม่มีการเคลื่อนไหว และ 1.5 mW เมื่ออุปกรณ์มีการเคลื่อนไหว
นอกจากนี้ อุปกรณ์ดังกล่าวต้องเป็นไปตามข้อกำหนดของระบบย่อยเซ็นเซอร์ต่อไปนี้
- การประทับเวลาของเหตุการณ์ของเหตุการณ์จริงเดียวกันที่รายงานโดยเซ็นเซอร์วัดความเร่ง เซ็นเซอร์ไจโรสโคป และเซ็นเซอร์แม่เหล็กไฟฟ้าต้องอยู่ภายใน 2.5 มิลลิวินาที
- การประทับเวลาเหตุการณ์ของเซ็นเซอร์ Gyroscope ต้องเป็นฐานเวลาเดียวกับระบบย่อยของกล้องและมีความคลาดเคลื่อนไม่เกิน 1 มิลลิวินาที
- เวลาในการตอบสนองของการนำส่งตัวอย่างไปยัง HAL ควรต่ำกว่า 5 มิลลิวินาทีนับจากทันทีที่มีข้อมูลในฮาร์ดแวร์เซ็นเซอร์
- ปริมาณการใช้พลังงานต้องไม่เกิน 0.5 mW เมื่ออุปกรณ์อยู่กับที่ และ 2.0 mW เมื่ออุปกรณ์เคลื่อนไหวเมื่อเปิดใช้เซ็นเซอร์ต่อไปนี้ร่วมกัน
- SENSOR_TYPE_SIGNIFICANT_MOTION
- SENSOR_TYPE_STEP_DETECTOR
- SENSOR_TYPE_STEP_COUNTER
- SENSOR_TILT_DETECTORS
โปรดทราบว่าข้อกำหนดทั้งหมดเกี่ยวกับการบริโภคพลังงานในส่วนนี้ไม่รวมการบริโภคพลังงานของหน่วยประมวลผลแอปพลิเคชัน ซึ่งรวมเอากำลังไฟฟ้าที่ดึงมาจากทั้งแชแนลเซ็นเซอร์ ซึ่งก็คือเซ็นเซอร์ วงจรสนับสนุน ระบบการประมวลผลเซ็นเซอร์เฉพาะ เป็นต้น
อุปกรณ์ที่ใช้ android.hardware.sensor.hifi_sensors อาจรองรับเซ็นเซอร์ประเภทต่อไปนี้ด้วย แต่หากมีเซ็นเซอร์ประเภทเหล่านี้ อุปกรณ์ต้องมีคุณสมบัติตรงตามข้อกำหนดความสามารถในการบัฟเฟอร์ขั้นต่ำต่อไปนี้
- SENSOR_TYPE_PROXIMITY: เหตุการณ์เซ็นเซอร์ 100 รายการ
7.3.10. เซ็นเซอร์ลายนิ้วมือ
การติดตั้งใช้งานอุปกรณ์ที่มีหน้าจอล็อกที่ปลอดภัยควรมีเซ็นเซอร์ลายนิ้วมือ หากการติดตั้งใช้งานอุปกรณ์มีเซ็นเซอร์ลายนิ้วมือและมี API ที่เกี่ยวข้องสําหรับนักพัฒนาแอปบุคคลที่สาม อุปกรณ์จะมีลักษณะดังนี้
- ต้องประกาศการรองรับฟีเจอร์ android.hardware.fingerprint
- ต้องติดตั้งใช้งาน API ที่เกี่ยวข้องอย่างเต็มรูปแบบตามที่อธิบายไว้ในเอกสารประกอบของ Android SDK [แหล่งข้อมูล, 95]
- ต้องมีอัตรายอมรับที่ผิดพลาดไม่เกิน 0.002%
- ขอแนะนำอย่างยิ่งให้มีอัตราการปฏิเสธที่ไม่ถูกต้องน้อยกว่า 10% โดยวัดในอุปกรณ์
- ขอแนะนำอย่างยิ่งให้มีเวลาในการตอบสนองต่ำกว่า 1 วินาที โดยวัดจากเวลาที่แตะเซ็นเซอร์ลายนิ้วมือจนกว่าหน้าจอจะปลดล็อกสำหรับนิ้วที่ลงทะเบียน 1 นิ้ว
- ต้องจำกัดจำนวนครั้งที่พยายามเป็นอย่างน้อย 30 วินาทีหลังจากการพยายามยืนยันลายนิ้วมือที่ไม่สำเร็จ 5 ครั้ง
- ต้องมีการใช้งานคีย์สโตร์ที่สำรองข้อมูลด้วยฮาร์ดแวร์ และทำการจับคู่ลายนิ้วมือในสภาพแวดล้อมการดำเนินการที่เชื่อถือได้ (TEE) หรือในชิปที่มีช่องทางที่ปลอดภัยไปยัง TEE
- ต้องมีการเข้ารหัสข้อมูลลายนิ้วมือที่ระบุตัวตนได้ทั้งหมดและได้รับการรับรองทางวิทยาการเข้ารหัสเพื่อให้ไม่สามารถรับ อ่าน หรือแก้ไขข้อมูลดังกล่าวได้นอกสภาพแวดล้อมการดำเนินการที่เชื่อถือได้ (TEE) ตามที่ระบุไว้ในหลักเกณฑ์การใช้งานบนเว็บไซต์โปรเจ็กต์โอเพนซอร์ส Android [แหล่งข้อมูล, 96]
- ต้องป้องกันไม่ให้เพิ่มลายนิ้วมือโดยไม่สร้างเชนความน่าเชื่อถือก่อน โดยให้ผู้ใช้ยืนยันข้อมูลเข้าสู่ระบบที่มีอยู่หรือเพิ่มข้อมูลเข้าสู่ระบบใหม่ของอุปกรณ์ (PIN/รูปแบบ/รหัสผ่าน) ที่ TEE รักษาความปลอดภัยไว้ การใช้งานโปรเจ็กต์โอเพนซอร์ส Android มีกลไกในเฟรมเวิร์กสำหรับดำเนินการดังกล่าว
- ต้องไม่เปิดใช้แอปพลิเคชันของบุคคลที่สามเพื่อแยกแยะลายนิ้วมือแต่ละลาย
- ต้องปฏิบัติตาม Flag DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT
- เมื่ออัปเกรดจากเวอร์ชันที่เก่ากว่า Android 6.0 จะต้องย้ายข้อมูลลายนิ้วมืออย่างปลอดภัยเพื่อให้เป็นไปตามข้อกำหนดข้างต้นหรือนำออก
- ควรใช้ไอคอนลายนิ้วมือ Android ที่ระบุไว้ในโปรเจ็กต์โอเพนซอร์ส Android
7.4. การเชื่อมต่อข้อมูล
7.4.1. โทรศัพท์
"โทรศัพท์" ตามที่ใช้โดย Android API และเอกสารนี้หมายถึงฮาร์ดแวร์ที่เกี่ยวข้องกับการโทรด้วยเสียงและการส่งข้อความ SMS ผ่านเครือข่าย GSM หรือ CDMA โดยเฉพาะ แม้ว่าการโทรด้วยเสียงเหล่านี้อาจใช้หรือไม่ได้ใช้การเปลี่ยนแพ็กเก็ต แต่ Android จะถือว่าการโทรเหล่านี้ไม่เกี่ยวข้องกับการเชื่อมต่อข้อมูลใดๆ ที่อาจใช้เครือข่ายเดียวกัน กล่าวคือ ฟังก์ชันการทำงานและ API "โทรศัพท์" ของ Android หมายถึงการโทรด้วยเสียงและ SMS โดยเฉพาะ ตัวอย่างเช่น การติดตั้งใช้งานอุปกรณ์ที่โทรออกหรือส่ง/รับข้อความ SMS ไม่ได้ต้องไม่รายงานฟีเจอร์ android.hardware.telephony หรือฟีเจอร์ย่อยใดๆ ก็ตาม ไม่ว่าจะใช้เครือข่ายมือถือเพื่อเชื่อมต่อข้อมูลหรือไม่ก็ตาม
Android อาจใช้ในอุปกรณ์ที่ไม่มีฮาร์ดแวร์โทรศัพท์ กล่าวคือ Android ใช้ได้กับอุปกรณ์ที่ไม่ใช่โทรศัพท์ อย่างไรก็ตาม หากการติดตั้งใช้งานอุปกรณ์มีโทรศัพท์ GSM หรือ CDMA อุปกรณ์นั้นต้องรองรับ API ของเทคโนโลยีนั้นอย่างเต็มรูปแบบ การติดตั้งใช้งานอุปกรณ์ที่ไม่มีฮาร์ดแวร์โทรศัพท์ต้องติดตั้งใช้งาน API แบบเต็มเป็น No-Ops
7.4.2. IEEE 802.11 (Wi-Fi)
การติดตั้งใช้งานอุปกรณ์ Android Television ต้องมี Wi-Fi
การติดตั้งใช้งานอุปกรณ์ Android Television จะต้องรองรับ 802.11 อย่างน้อย 1 รูปแบบ (b/g/a/n ฯลฯ) และการติดตั้งใช้งานอุปกรณ์ Android ประเภทอื่นๆ ควรรองรับ 802.11 อย่างน้อย 1 รูปแบบ หากการติดตั้งใช้งานอุปกรณ์รองรับ 802.11 และแสดงฟังก์ชันการทำงานต่อแอปพลิเคชันของบุคคลที่สาม การติดตั้งใช้งานนั้นต้องใช้ Android API ที่เกี่ยวข้องและมีคุณสมบัติดังนี้
- ต้องรายงาน Flag ฟีเจอร์ฮาร์ดแวร์ android.hardware.wifi
- ต้องติดตั้งใช้งาน Multicast API ตามที่อธิบายไว้ในเอกสารประกอบ SDK [แหล่งข้อมูล, 97]
- ต้องรองรับมัลติแคสต์ DNS (mDNS) และต้องไม่กรองแพ็กเก็ต mDNS (224.0.0.251) ในทุกช่วงเวลาของการทำงาน ซึ่งรวมถึง
- แม้ว่าหน้าจอจะไม่อยู่ในสถานะทำงาน
- สำหรับการติดตั้งใช้งานอุปกรณ์ Android Television แม้ว่าจะอยู่ในสถานะพลังงานสแตนด์บาย
7.4.2.1. Wi-Fi Direct
การติดตั้งใช้งานอุปกรณ์ควรรองรับ Wi-Fi Direct (Wi-Fi แบบผู้ใช้ต่อผู้ใช้) หากการติดตั้งใช้งานอุปกรณ์รองรับ Wi-Fi Direct อุปกรณ์นั้นต้องใช้ Android API ที่เกี่ยวข้องตามที่อธิบายไว้ในเอกสารประกอบ SDK [แหล่งข้อมูล, 98] หากการติดตั้งใช้งานอุปกรณ์รองรับ Wi-Fi Direct อุปกรณ์จะมีลักษณะดังนี้
- ต้องรายงานฟีเจอร์ฮาร์ดแวร์ android.hardware.wifi.direct
- ต้องรองรับการใช้งาน Wi-Fi ปกติ
- ควรรองรับการใช้งาน Wi-Fi และ Wi-Fi Direct พร้อมกัน
7.4.2.2. การตั้งค่าลิงก์โดยตรงที่ผ่านอุโมงค์ Wi-Fi
การติดตั้งใช้งานอุปกรณ์ Android Television ต้องมีการสนับสนุนการตั้งค่าลิงก์โดยตรงแบบ Tunneled (TDLS) ของ Wi-Fi
การติดตั้งใช้งานอุปกรณ์ Android Television จะต้องรองรับ Wi-Fi Direct Link Setup (TDLS) และการติดตั้งใช้งานอุปกรณ์ Android ประเภทอื่นๆ ควรรองรับ Wi-Fi TDLS ตามที่อธิบายไว้ในเอกสารประกอบ Android SDK [แหล่งข้อมูล, 99] หากการติดตั้งใช้งานอุปกรณ์รองรับ TDLS และ WiFiManager API เปิดใช้ TDLS ไว้ อุปกรณ์จะทําดังนี้
- ควรใช้ TDLS เฉพาะเมื่อเป็นไปได้และมีประโยชน์เท่านั้น
- ควรใช้การเรียนรู้เชิงสืบสวนบ้างและอย่าใช้ TDLS เมื่อประสิทธิภาพอาจแย่กว่าการผ่านจุดเข้าใช้งาน Wi-Fi
7.4.3. บลูทูธ
การติดตั้งใช้งาน Android Watch และ Automotive ต้องใช้บลูทูธ Android การติดตั้งใช้งานทีวีต้องรองรับบลูทูธและบลูทูธ LE
Android รองรับบลูทูธและบลูทูธพลังงานต่ำ [แหล่งข้อมูล, 100] การติดตั้งใช้งานอุปกรณ์ที่รองรับบลูทูธและบลูทูธพลังงานต่ำต้องประกาศฟีเจอร์แพลตฟอร์มที่เกี่ยวข้อง (android.hardware.bluetooth และ android.hardware.bluetooth_le ตามลำดับ) และใช้ API ของแพลตฟอร์ม การใช้งานอุปกรณ์ควรใช้โปรไฟล์บลูทูธที่เกี่ยวข้อง เช่น A2DP, AVCP, OBEX ฯลฯ ตามเหมาะสมกับอุปกรณ์ การติดตั้งใช้งานอุปกรณ์ Android Television ต้องรองรับบลูทูธและบลูทูธ LE
การติดตั้งใช้งานอุปกรณ์ที่รองรับบลูทูธพลังงานต่ำ
- ต้องประกาศฟีเจอร์ฮาร์ดแวร์ android.hardware.bluetooth_le
- ต้องเปิดใช้ API บลูทูธที่อิงตาม GATT (โปรไฟล์แอตทริบิวต์ทั่วไป) ตามที่อธิบายไว้ในเอกสารประกอบ SDK และ [แหล่งข้อมูล, 100]
- ขอแนะนําอย่างยิ่งให้ใช้ที่อยู่ส่วนตัวที่แก้ไขได้ (RPA) ที่มีระยะหมดเวลาไม่เกิน 15 นาที และเปลี่ยนที่อยู่เมื่อหมดเวลาเพื่อปกป้องความเป็นส่วนตัวของผู้ใช้
- ควรรองรับการย้ายข้อมูลตรรกะการกรองไปยังชิปเซ็ตบลูทูธเมื่อติดตั้งใช้งาน ScanFilter API [แหล่งข้อมูล, 101] และต้องรายงานค่าที่ถูกต้องของตำแหน่งที่ติดตั้งใช้งานตรรกะการกรองทุกครั้งที่มีการค้นหาผ่านเมธอด android.bluetooth.BluetoothAdapter.isOffloadedFilteringSupported()
- ควรรองรับการโอนการสแกนแบบเป็นกลุ่มไปยังชิปเซ็ตบลูทูธ แต่หากไม่รองรับ จะต้องรายงานเป็น "เท็จ" ทุกครั้งที่มีการค้นหาผ่านเมธอด android.bluetooth.BluetoothAdapater.isOffloadedScanBatchingSupported()
- ควรรองรับการโฆษณาหลายรายการที่มีช่องอย่างน้อย 4 ช่อง แต่หากไม่รองรับ ต้องรายงานเป็น "เท็จ" ทุกครั้งที่มีการค้นหาผ่านเมธอด android.bluetooth.BluetoothAdapter.isMultipleAdvertisementSupported()
7.4.4. Near Field Communication
การติดตั้งใช้งานอุปกรณ์ควรมีตัวรับส่งสัญญาณและฮาร์ดแวร์ที่เกี่ยวข้องสำหรับการสื่อสารระยะใกล้ (NFC) หากการติดตั้งใช้งานอุปกรณ์มีฮาร์ดแวร์ NFC และวางแผนที่จะให้บริการแก่แอปของบุคคลที่สาม อุปกรณ์จะต้องมีคุณสมบัติดังนี้
- ต้องรายงานฟีเจอร์ android.hardware.nfc จากเมธอด android.content.pm.PackageManager.hasSystemFeature() [แหล่งข้อมูล, 70]
- ต้องสามารถอ่านและเขียนข้อความ NDEF ผ่านมาตรฐาน NFC ต่อไปนี้
- ต้องสามารถทําหน้าที่เป็นเครื่องอ่าน/เขียน NFC Forum (ตามที่ระบุไว้ในข้อกําหนดทางเทคนิค NFC Forum NFCForum-TS-DigitalProtocol-1.0) ผ่านมาตรฐาน NFC ต่อไปนี้
- NfcA (ISO14443-3A)
- NfcB (ISO14443-3B)
- NfcF (JIS X 6319-4)
- IsoDep (ISO 14443-4)
- แท็ก NFC Forum ประเภท 1, 2, 3, 4 (กำหนดโดย NFC Forum)
- ขอแนะนําอย่างยิ่งให้สามารถอ่านและเขียนข้อความ NDEF รวมถึงข้อมูลดิบผ่านมาตรฐาน NFC ต่อไปนี้ โปรดทราบว่าแม้ว่ามาตรฐาน NFC ด้านล่างจะระบุว่า "แนะนำอย่างยิ่ง" แต่เราวางแผนที่จะเปลี่ยนคำจำกัดความของความเข้ากันได้สำหรับเวอร์ชันในอนาคตเป็น "ต้อง" มาตรฐานเหล่านี้เป็นมาตรฐานที่ไม่บังคับในเวอร์ชันนี้ แต่จะบังคับใช้ในเวอร์ชันในอนาคต เราขอแนะนำให้อุปกรณ์ที่มีอยู่และอุปกรณ์ใหม่ที่ใช้ Android เวอร์ชันนี้มีคุณสมบัติตรงตามข้อกำหนดเหล่านี้ตั้งแต่ตอนนี้เพื่อให้อัปเกรดเป็นแพลตฟอร์มเวอร์ชันในอนาคตได้
- NfcV (ISO 15693)
- ควรอ่านบาร์โค้ดและ URL (หากเข้ารหัส) ของผลิตภัณฑ์ที่มีบาร์โค้ด NFC แบบ Thinfilm ได้ [แหล่งข้อมูล, 102]
- ต้องสามารถส่งและรับข้อมูลผ่านมาตรฐานและโปรโตคอลแบบ peer-to-peer ต่อไปนี้
- ISO 18092
- LLCP 1.2 (กำหนดโดย NFC Forum)
- SDP 1.0 (กำหนดโดย NFC Forum)
- โปรโตคอลการพุช NDEF [แหล่งข้อมูล, 103]
- SNEP 1.0 (กำหนดโดย NFC Forum)
- ต้องรองรับ Android Beam [แหล่งข้อมูล, 104]:
- ต้องใช้เซิร์ฟเวอร์เริ่มต้น SNEP ข้อความ NDEF ที่ถูกต้องซึ่งเซิร์ฟเวอร์ SNEP เริ่มต้นได้รับต้องส่งไปยังแอปพลิเคชันโดยใช้ Intent android.nfc.ACTION_NDEF_DISCOVERED การปิดใช้ Android Beam ในการตั้งค่า ต้องไม่ปิดใช้การส่งข้อความ NDEF ขาเข้า
- ต้องปฏิบัติตาม Intent android.settings.NFCSHARING_SETTINGS เพื่อแสดงการตั้งค่าการแชร์ NFC [แหล่งข้อมูล, 105]
- ต้องติดตั้งใช้งานเซิร์ฟเวอร์ NPP ข้อความที่ได้รับจากเซิร์ฟเวอร์ NPP ต้องได้รับการประมวลผลในลักษณะเดียวกับเซิร์ฟเวอร์เริ่มต้น SNEP
- ต้องใช้ไคลเอ็นต์ SNEP และพยายามส่ง P2P NDEF ขาออกไปยังเซิร์ฟเวอร์ SNEP เริ่มต้นเมื่อเปิดใช้ Android Beam หากไม่พบเซิร์ฟเวอร์ SNEP เริ่มต้น ไคลเอ็นต์ต้องพยายามส่งไปยังเซิร์ฟเวอร์ NPP
- ต้องอนุญาตให้กิจกรรมที่ทำงานอยู่เบื้องหน้าตั้งค่าข้อความ NDEF ของ P2P ขาออกโดยใช้ android.nfc.NfcAdapter.setNdefPushMessage และ android.nfc.NfcAdapter.setNdefPushMessageCallback และ android.nfc.NfcAdapter.enableForegroundNdefPush
- ควรใช้ท่าทางสัมผัสหรือการยืนยันบนหน้าจอ เช่น "แตะเพื่อส่ง" ก่อนส่งข้อความ NDEF แบบ P2P ขาออก
- ควรเปิดใช้ Android Beam โดยค่าเริ่มต้น และต้องสามารถส่งและรับโดยใช้ Android Beam ได้ แม้ว่าจะเปิดโหมด NFC P2P ที่เป็นกรรมสิทธิ์อื่นไว้ก็ตาม
- ต้องรองรับการส่งต่อการเชื่อมต่อ NFC ไปยังบลูทูธเมื่ออุปกรณ์รองรับโปรไฟล์การพุชออบเจ็กต์บลูทูธ การติดตั้งใช้งานอุปกรณ์ต้องรองรับการส่งต่อการเชื่อมต่อไปยังบลูทูธเมื่อใช้ android.nfc.NfcAdapter.setBeamPushUris โดยการใช้ข้อกำหนด "การส่งต่อการเชื่อมต่อเวอร์ชัน 1.2" [แหล่งข้อมูล, 106] และ "การจับคู่ที่ง่ายดายและปลอดภัยของบลูทูธโดยใช้ NFC เวอร์ชัน 1.0" [แหล่งข้อมูล, 107] จาก NFC Forum การใช้งานดังกล่าวต้องใช้บริการ LLCP สำหรับการโอนด้วยชื่อบริการ "urn:nfc:sn:handover" เพื่อแลกเปลี่ยนคำขอโอน/ระเบียนการเลือกผ่าน NFC และต้องใช้โปรไฟล์การพุชออบเจ็กต์บลูทูธสำหรับการโอนข้อมูลบลูทูธจริง การติดตั้งใช้งานควรยังคงยอมรับคําขอ GET ของ SNEP เพื่อแลกเปลี่ยนคําขอส่งต่อ/ระเบียนบางรายการผ่าน NFC ต่อไปด้วยเหตุผลด้านเดิม (เพื่อให้ใช้งานร่วมกับอุปกรณ์ Android 4.1 ได้อยู่) อย่างไรก็ตาม การติดตั้งใช้งานไม่ควรส่งคําขอ SNEP GET เพื่อส่งต่อการเชื่อมต่อ
- ต้องสำรวจเทคโนโลยีที่รองรับทั้งหมดขณะอยู่ในโหมดการค้นพบ NFC
- ควรอยู่ในโหมดการค้นหา NFC ขณะที่อุปกรณ์ทำงานอยู่โดยมีหน้าจอเปิดอยู่และหน้าจอล็อกปลดล็อก
- ต้องสามารถทําหน้าที่เป็นเครื่องอ่าน/เขียน NFC Forum (ตามที่ระบุไว้ในข้อกําหนดทางเทคนิค NFC Forum NFCForum-TS-DigitalProtocol-1.0) ผ่านมาตรฐาน NFC ต่อไปนี้
(โปรดทราบว่าลิงก์ที่เผยแพร่ต่อสาธารณะไม่มีให้บริการสำหรับข้อกำหนดของ JIS, ISO และ NFC Forum ที่ระบุไว้ข้างต้น)
Android รองรับโหมดการจําลองบัตรของโฮสต์ (HCE) ของ NFC หากการติดตั้งใช้งานอุปกรณ์มีชิปเซ็ตตัวควบคุม NFC ที่รองรับ HCE และการกำหนดเส้นทางแอปพลิเคชัน (AID) อุปกรณ์จะมีลักษณะดังนี้
- ต้องรายงานค่าคงที่ของฟีเจอร์ android.hardware.nfc.hce
- ต้องรองรับ NFC HCE API ตามที่ระบุไว้ใน Android SDK [แหล่งข้อมูล, 108]
นอกจากนี้ การติดตั้งใช้งานอุปกรณ์อาจรวมถึงการรองรับเครื่องอ่าน/เครื่องเขียนสำหรับเทคโนโลยี MIFARE ต่อไปนี้
- MIFARE Classic
- MIFARE Ultralight
- NDEF ใน MIFARE Classic
โปรดทราบว่า Android มี API สำหรับ MIFARE ประเภทเหล่านี้ หากการติดตั้งใช้งานอุปกรณ์รองรับ MIFARE ในบทบาทเครื่องอ่าน/เครื่องเขียน อุปกรณ์จะทําสิ่งต่อไปนี้
- ต้องใช้ Android API ที่เกี่ยวข้องตามที่ Android SDK ระบุไว้
- ต้องรายงานฟีเจอร์ com.nxp.mifare จากเมธอด android.content.pm.PackageManager.hasSystemFeature() [แหล่งข้อมูล, 70] โปรดทราบว่านี่ไม่ใช่ฟีเจอร์มาตรฐานของ Android และจะไม่ปรากฏเป็นค่าคงที่ในคลาส android.content.pm.PackageManager
- ต้องไม่ใช้ Android API ที่เกี่ยวข้องหรือรายงานฟีเจอร์ com.nxp.mifare เว้นแต่จะใช้การรองรับ NFC ทั่วไปตามที่อธิบายไว้ในส่วนนี้ด้วย
หากการใช้งานอุปกรณ์ไม่มีฮาร์ดแวร์ NFC จะต้องไม่ประกาศฟีเจอร์ android.hardware.nfc จากเมธอด android.content.pm.PackageManager.hasSystemFeature() [แหล่งข้อมูล, 70] และต้องใช้งาน Android NFC API แบบไม่ดำเนินการ
เนื่องจากคลาส android.nfc.NdefMessage และ android.nfc.NdefRecord แสดงรูปแบบการนำเสนอข้อมูลที่แยกจากโปรโตคอล การติดตั้งใช้งานอุปกรณ์จึงต้องใช้ API เหล่านี้แม้ว่าจะไม่รองรับ NFC หรือประกาศฟีเจอร์ android.hardware.nfc ก็ตาม
7.4.5. ความสามารถขั้นต่ำของเครือข่าย
การติดตั้งใช้งานอุปกรณ์ต้องรองรับรูปแบบเครือข่ายข้อมูลอย่างน้อย 1 รูปแบบ กล่าวโดยละเอียดคือ การติดตั้งใช้งานอุปกรณ์ต้องรองรับมาตรฐานข้อมูลอย่างน้อย 1 รายการที่รับส่งข้อมูลได้ 200 Kbit/วินาทีขึ้นไป ตัวอย่างเทคโนโลยีที่เป็นไปตามข้อกำหนดนี้ ได้แก่ EDGE, HSPA, EV-DO, 802.11g, Ethernet, Bluetooth PAN ฯลฯ
การติดตั้งใช้งานอุปกรณ์ที่ใช้มาตรฐานเครือข่ายทางกายภาพ (เช่น อีเทอร์เน็ต) เป็นการเชื่อมต่อข้อมูลหลักควรรองรับมาตรฐานข้อมูลไร้สายทั่วไปอย่างน้อย 1 รายการ เช่น 802.11 (Wi-Fi)
อุปกรณ์อาจใช้การเชื่อมต่อข้อมูลมากกว่า 1 รูปแบบ
อุปกรณ์ต้องมีสแต็กเครือข่าย IPv6 และรองรับการสื่อสาร IPv6 โดยใช้ API ที่มีการจัดการ เช่น java.net.Socket
และ java.net.URLConnection
รวมถึง API เดิม เช่น AF_INET6
socket ระดับการรองรับ IPv6 ที่จำเป็นจะขึ้นอยู่กับประเภทเครือข่าย ดังนี้
- อุปกรณ์ที่รองรับเครือข่าย Wi-Fi จะต้องรองรับการใช้งานแบบ Dual-Stack และ IPv6 เท่านั้นใน Wi-Fi
- อุปกรณ์ที่รองรับเครือข่ายอีเทอร์เน็ตต้องรองรับการดำเนินการแบบ Dual Stack ในอีเทอร์เน็ต
- อุปกรณ์ที่รองรับอินเทอร์เน็ตมือถือควรรองรับการใช้งาน IPv6 (IPv6 เท่านั้นและอาจรองรับแบบ Dual-Stack) ในอินเทอร์เน็ตมือถือ
- เมื่ออุปกรณ์เชื่อมต่อกับเครือข่ายมากกว่า 1 เครือข่ายพร้อมกัน (เช่น Wi-Fi และอินเทอร์เน็ตมือถือ) อุปกรณ์ต้องเป็นไปตามข้อกำหนดเหล่านี้พร้อมกันในแต่ละเครือข่ายที่เชื่อมต่อ
IPv6 ต้องเปิดใช้โดยค่าเริ่มต้น
แพ็กเก็ต IPv6 แบบยูนิแคสต์ที่ส่งไปยังอุปกรณ์ต้องไม่ถูกทิ้งเพื่อให้การสื่อสาร IPv6 มีความน่าเชื่อถือเท่ากับ IPv4 แม้ว่าหน้าจอจะไม่อยู่ในสถานะทำงานก็ตาม แพ็กเก็ต IPv6 แบบมัลติแคสต์ที่ซ้ำกัน เช่น การโฆษณาเราเตอร์ที่เหมือนกันซ้ำๆ อาจมีการจำกัดอัตราในฮาร์ดแวร์หรือเฟิร์มแวร์ หากจำเป็นต่อการประหยัดพลังงาน ในกรณีเช่นนี้ การจำกัดอัตราการส่งข้อมูลต้องไม่ทําให้อุปกรณ์สูญเสียการเชื่อมต่อ IPv6 ในเครือข่ายที่เป็นไปตามข้อกําหนดของ IPv6 ซึ่งใช้อายุของ RA อย่างน้อย 180 วินาที
การเชื่อมต่อ IPv6 ต้องคงอยู่ในโหมดสลีป
7.4.6. การตั้งค่าการซิงค์
การติดตั้งใช้งานอุปกรณ์ต้องเปิดการตั้งค่าการซิงค์อัตโนมัติหลักไว้โดยค่าเริ่มต้นเพื่อให้เมธอด getMasterSyncAutomatically() แสดงผลเป็น "จริง" [แหล่งข้อมูล, 109]
7.5 กล้อง
การติดตั้งใช้งานอุปกรณ์ควรมีกล้องหลังและอาจมีกล้องหน้า กล้องหลังคือกล้องที่อยู่ด้านข้างของอุปกรณ์ซึ่งอยู่ตรงข้ามกับจอแสดงผล กล่าวคือ กล้องจะจับภาพฉากที่อยู่อีกด้านหนึ่งของอุปกรณ์ เช่น กล้องแบบดั้งเดิม กล้องหน้าคือกล้องที่อยู่ที่ด้านเดียวกับจอแสดงผลของอุปกรณ์ กล่าวคือกล้องที่มักใช้ถ่ายภาพผู้ใช้ เช่น สำหรับการประชุมทางวิดีโอและแอปพลิเคชันที่เกี่ยวข้อง
หากการติดตั้งใช้งานอุปกรณ์มีกล้องอย่างน้อย 1 ตัว แอปพลิเคชันควรจัดสรรบิตแมป 3 รายการพร้อมกันได้เท่ากับขนาดของรูปภาพที่ผลิตโดยเซ็นเซอร์กล้องที่มีความละเอียดสูงสุดในอุปกรณ์
7.5.1. กล้องหลัง
การติดตั้งใช้งานอุปกรณ์ควรมีกล้องหลัง หากการติดตั้งใช้งานอุปกรณ์มีกล้องหลังอย่างน้อย 1 ตัว อุปกรณ์จะมีลักษณะดังนี้
- ต้องรายงาน Flag ฟีเจอร์ android.hardware.camera และ android.hardware.camera.any
- ต้องมีความละเอียดอย่างน้อย 2 ล้านพิกเซล
- ควรมีการใช้โฟกัสอัตโนมัติของฮาร์ดแวร์หรือโฟกัสอัตโนมัติของซอฟต์แวร์ในไดรเวอร์กล้อง (ซอฟต์แวร์แอปพลิเคชันจะทำงานได้โดยไม่มีปัญหา)
- อาจใช้ฮาร์ดแวร์แบบโฟกัสคงที่หรือ EDOF (ระยะชัดลึกแบบขยาย)
- อาจใช้แฟลช หากกล้องมีแฟลช หลอดไฟแฟลชต้องไม่สว่างขึ้นขณะที่ลงทะเบียนอินสแตนซ์ android.hardware.Camera.PreviewCallback บนแพลตฟอร์มแสดงตัวอย่างของกล้อง เว้นแต่แอปพลิเคชันจะเปิดใช้แฟลชอย่างชัดเจนโดยเปิดใช้แอตทริบิวต์ FLASH_MODE_AUTO หรือ FLASH_MODE_ON ของออบเจ็กต์ Camera.Parameters โปรดทราบว่าข้อจำกัดนี้ไม่มีผลกับแอปพลิเคชันกล้องของระบบในตัวของอุปกรณ์ แต่จะมีผลกับแอปพลิเคชันของบุคคลที่สามที่ใช้ Camera.PreviewCallback เท่านั้น
7.5.2. กล้องหน้า
การติดตั้งใช้งานอุปกรณ์อาจรวมถึงกล้องหน้า หากการติดตั้งใช้งานอุปกรณ์มีกล้องหน้าอย่างน้อย 1 ตัว อุปกรณ์จะมีลักษณะดังนี้
- ต้องรายงาน Flag ฟีเจอร์ android.hardware.camera.any และ android.hardware.camera.front
- ต้องมีความละเอียดอย่างน้อย VGA (640x480 พิกเซล)
- ต้องไม่ใช้กล้องหน้าเป็นค่าเริ่มต้นสำหรับ Camera API API ของกล้องใน Android รองรับกล้องหน้าโดยเฉพาะ และการใช้งานอุปกรณ์ต้องไม่กำหนดค่า API ให้ถือว่ากล้องหน้าเป็นกล้องหลังเริ่มต้น แม้ว่าจะเป็นกล้องเพียงตัวเดียวในอุปกรณ์ก็ตาม
- อาจรวมฟีเจอร์ (เช่น โฟกัสอัตโนมัติ แฟลช ฯลฯ) ที่มีให้ใช้งานกับกล้องหลังตามที่อธิบายไว้ในส่วนที่ 7.5.1
- ต้องสะท้อนแนวนอน (มิเรอร์) สตรีมที่แสดงโดยแอปใน CameraPreview ดังนี้
- หากผู้ใช้สามารถหมุนการใช้งานอุปกรณ์ได้ (เช่น หมุนโดยอัตโนมัติผ่านเครื่องวัดความเร่ง หรือหมุนด้วยตนเองผ่านอินพุตของผู้ใช้) ตัวอย่างจากกล้องจะต้องสะท้อนแนวนอนตามการวางแนวปัจจุบันของอุปกรณ์
- หากแอปพลิเคชันปัจจุบันได้ส่งคำขออย่างชัดเจนให้หมุนจอแสดงผลของกล้องผ่านการเรียกใช้เมธอด android.hardware.Camera.setDisplayOrientation()[Resources, 110] ตัวอย่างภาพจากกล้องจะต้องแสดงแบบมิเรอร์ในแนวนอนตามการวางแนวที่แอปพลิเคชันระบุ
- มิฉะนั้น ตัวอย่างเพลงต้องมิเรอร์ตามแกนแนวนอนเริ่มต้นของอุปกรณ์
- ต้องมิเรอร์รูปภาพที่แสดงโดยฟีเจอร์ดูตัวอย่างโพสต์ในลักษณะเดียวกับสตรีมรูปภาพตัวอย่างของกล้อง หากการติดตั้งใช้งานอุปกรณ์ไม่รองรับโพสต์วิว ก็ไม่จําเป็นต้องปฏิบัติตามข้อกําหนดนี้
- ต้องไม่มิเรอร์สตรีมวิดีโอหรือภาพนิ่งที่จับภาพไว้แล้วซึ่งส่งกลับไปยังการเรียกกลับของแอปพลิเคชันหรือส่งไปยังพื้นที่เก็บข้อมูลสื่อ
7.5.3. กล้องภายนอก
การติดตั้งใช้งานอุปกรณ์ที่มีโหมดโฮสต์ USB อาจรองรับกล้องภายนอกที่เชื่อมต่อกับพอร์ต USB หากอุปกรณ์รองรับกล้องภายนอก อุปกรณ์จะมีลักษณะดังนี้
- ต้องประกาศฟีเจอร์แพลตฟอร์ม android.hardware.camera.external และ android.hardware camera.any
- ต้องรองรับ USB Video Class (UVC 1.0 ขึ้นไป)
- อาจรองรับกล้องหลายตัว
เราขอแนะนำให้รองรับการบีบอัดวิดีโอ (เช่น MJPEG) เพื่อให้โอนสตรีมคุณภาพสูงที่ไม่ได้เข้ารหัสได้ (เช่น สตรีมรูปภาพที่ไม่มีการบีบอัดหรือบีบอัดแยกต่างหาก) ระบบอาจรองรับการเข้ารหัสวิดีโอจากกล้อง หากเป็นเช่นนั้น การติดตั้งใช้งานอุปกรณ์ต้องเข้าถึงสตรีม MJPEG/ ที่ไม่ได้เข้ารหัส (ความละเอียด QVGA ขึ้นไป) ได้พร้อมกัน
7.5.4. ลักษณะการทํางานของ Camera API
Android มีแพ็กเกจ API 2 รายการสําหรับเข้าถึงกล้อง โดย API เวอร์ชันใหม่อย่าง android.hardware.camera2 จะแสดงการควบคุมกล้องในระดับล่างให้กับแอป ซึ่งรวมถึงการถ่ายต่อเนื่อง/สตรีมแบบไม่คัดลอกข้อมูล (Zero-Copy) ที่มีประสิทธิภาพ และการควบคุมระดับเฟรมของการรับแสง อัตราขยาย อัตราขยายของการปรับสมดุลสีขาว การเปลี่ยนสี การตัดเสียงรบกวน การเพิ่มความคมชัด และอื่นๆ
ระบบได้ทําเครื่องหมายแพ็กเกจ API เก่าอย่าง android.hardware.Camera ว่าเลิกใช้งานแล้วใน Android 5.0 แต่เนื่องจากแพ็กเกจดังกล่าวควรยังคงพร้อมให้แอปใช้กับการติดตั้งใช้งานอุปกรณ์ Android ต่อไป จึงต้องรองรับ API ดังกล่าวต่อไปตามที่อธิบายไว้ในส่วนนี้และใน Android SDK
การติดตั้งใช้งานอุปกรณ์ต้องใช้ลักษณะการทำงานต่อไปนี้สําหรับ API ที่เกี่ยวข้องกับกล้องสําหรับกล้องทั้งหมดที่ใช้ได้
- หากแอปพลิเคชันไม่เคยเรียกใช้ android.hardware.Camera.Parameters.setPreviewFormat(int) อุปกรณ์ต้องใช้ android.hardware.PixelFormat.YCbCr_420_SP สำหรับข้อมูลพรีวิวที่ส่งไปยังการเรียกกลับของแอปพลิเคชัน
- หากแอปพลิเคชันลงทะเบียนอินสแตนซ์ android.hardware.Camera.PreviewCallback และระบบเรียกใช้เมธอด onPreviewFrame() เมื่อรูปแบบการแสดงตัวอย่างเป็น YCbCr_420_SP ข้อมูลใน byte[] ที่ส่งไปยัง onPreviewFrame() จะต้องอยู่ในรูปแบบการเข้ารหัส NV21 กล่าวคือ NV21 ต้องเป็นค่าเริ่มต้น
- สำหรับ android.hardware.Camera การติดตั้งใช้งานอุปกรณ์ต้องรองรับรูปแบบ YV12 (ตามที่ระบุโดยค่าคงที่ android.graphics.ImageFormat.YV12) สำหรับการแสดงตัวอย่างกล้องทั้งกล้องหน้าและกล้องหลัง (โปรแกรมเปลี่ยนรูปแบบวิดีโอฮาร์ดแวร์และกล้องอาจใช้รูปแบบพิกเซลเดิมใดก็ได้ แต่การใช้งานอุปกรณ์ต้องรองรับการเปลี่ยนรูปแบบเป็น YV12)
- สำหรับ android.hardware.camera2 การติดตั้งใช้งานอุปกรณ์ต้องรองรับรูปแบบ android.hardware.ImageFormat.YUV_420_888 และ android.hardware.ImageFormat.JPEG เป็นเอาต์พุตผ่าน android.media.ImageReader API
การใช้งานอุปกรณ์ยังคงต้องใช้ Camera API แบบเต็มซึ่งรวมอยู่ในเอกสารประกอบ Android SDK [แหล่งข้อมูล, 111] ไม่ว่าอุปกรณ์จะมีระบบโฟกัสอัตโนมัติแบบฮาร์ดแวร์หรือความสามารถอื่นๆ หรือไม่ก็ตาม ตัวอย่างเช่น กล้องที่ไม่มีโฟกัสอัตโนมัติยังคงต้องเรียกใช้อินสแตนซ์ android.hardware.Camera.AutoFocusCallback ที่ลงทะเบียนไว้ (แม้ว่าจะไม่มีความเกี่ยวข้องกับกล้องที่ไม่มีโฟกัสอัตโนมัติก็ตาม) โปรดทราบว่าการดำเนินการนี้มีผลกับกล้องหน้าด้วย เช่น แม้ว่ากล้องหน้าส่วนใหญ่จะไม่รองรับโฟกัสอัตโนมัติ แต่การเรียกกลับ API ยังคงต้อง "จำลอง" ตามที่อธิบายไว้
การใช้งานอุปกรณ์ต้องรู้จักและปฏิบัติตามชื่อพารามิเตอร์แต่ละรายการที่กําหนดเป็นค่าคงที่ในคลาส android.hardware.Camera.Parameters หากฮาร์ดแวร์ที่เกี่ยวข้องรองรับฟีเจอร์นี้ หากฮาร์ดแวร์ของอุปกรณ์ไม่รองรับฟีเจอร์หนึ่งๆ API จะต้องทํางานตามที่ระบุไว้ในเอกสาร ในทางกลับกัน การใช้งานอุปกรณ์ต้องไม่ยอมรับหรือจดจำค่าคงที่สตริงที่ส่งไปยังเมธอด android.hardware.Camera.setParameters() นอกเหนือจากค่าคงที่ที่ระบุไว้ใน android.hardware.Camera.Parameters กล่าวคือ การใช้งานอุปกรณ์ต้องรองรับพารามิเตอร์กล้องมาตรฐานทั้งหมดหากฮาร์ดแวร์อนุญาต และจะต้องไม่รองรับประเภทพารามิเตอร์กล้องที่กำหนดเอง ตัวอย่างเช่น การใช้งานอุปกรณ์ที่รองรับการจับภาพโดยใช้เทคนิคการถ่ายภาพแบบ High Dynamic Range (HDR) จะต้องรองรับพารามิเตอร์กล้อง Camera.SCENE_MODE_HDR [แหล่งข้อมูล, 112]
เนื่องจากการติดตั้งใช้งานอุปกรณ์บางรุ่นอาจไม่รองรับฟีเจอร์ทั้งหมดของ android.hardware.camera2 API การติดตั้งใช้งานอุปกรณ์จึงต้องรายงานระดับการรองรับที่เหมาะสมด้วยพร็อพเพอร์ตี้ android.info.supportedHardwareLevel ตามที่อธิบายไว้ใน Android SDK [แหล่งข้อมูล, 113] และรายงาน Flag ฟีเจอร์เฟรมเวิร์กที่เหมาะสม [แหล่งข้อมูล, 114]
การติดตั้งใช้งานอุปกรณ์ต้องประกาศความสามารถของกล้องแต่ละตัวใน android.hardware.camera2 ผ่านพร็อพเพอร์ตี้ android.request.availableCapabilities และประกาศ Flag ฟีเจอร์ที่เหมาะสม [แหล่งข้อมูล, 114] อุปกรณ์ต้องกำหนด Flag ฟีเจอร์หากอุปกรณ์กล้องที่เชื่อมต่อรองรับฟีเจอร์ดังกล่าว
การติดตั้งใช้งานอุปกรณ์ต้องออกอากาศ Intent Camera.ACTION_NEW_PICTURE ทุกครั้งที่กล้องถ่ายภาพใหม่และเพิ่มรายการรูปภาพลงในที่เก็บสื่อแล้ว
การติดตั้งใช้งานอุปกรณ์ต้องออกอากาศ Intent Camera.ACTION_NEW_VIDEO ทุกครั้งที่กล้องบันทึกวิดีโอใหม่และเพิ่มรายการรูปภาพลงในที่เก็บสื่อ
7.5.5. การวางแนวของกล้อง
กล้องหน้าและกล้องหลัง (หากมี) จะต้องวางแนวให้มิติข้อมูลแนวยาวของกล้องสอดคล้องกับมิติข้อมูลแนวยาวของหน้าจอ กล่าวคือ เมื่อถืออุปกรณ์ในแนวนอน กล้องต้องจับภาพในแนวนอน การตั้งค่านี้จะมีผลไม่ว่าอุปกรณ์จะอยู่ในแนวนอนหรือแนวตั้งตามปกติ กล่าวคือ การตั้งค่านี้จะมีผลกับอุปกรณ์ที่ใช้งานแนวนอนเป็นหลักและอุปกรณ์ที่ใช้งานแนวตั้งเป็นหลัก
7.6. หน่วยความจำและพื้นที่เก็บข้อมูล
7.6.1. หน่วยความจำและพื้นที่เก็บข้อมูลขั้นต่ำ
อุปกรณ์ Android TV ต้องมีพื้นที่เก็บข้อมูลแบบถาวรอย่างน้อย 5 GB ที่ใช้เก็บข้อมูลส่วนตัวของแอปพลิเคชันได้
หน่วยความจำที่ใช้ได้กับเคอร์เนลและพื้นที่ผู้ใช้ในการใช้งานอุปกรณ์ต้องเท่ากับหรือมากกว่าค่าต่ำสุดที่ระบุไว้ในตารางต่อไปนี้เป็นอย่างน้อย (ดูคำจำกัดความของขนาดและความหนาแน่นของหน้าจอได้ที่ส่วนที่ 7.1.1)
ความหนาแน่นและขนาดหน้าจอ | อุปกรณ์ 32 บิต | อุปกรณ์ 64 บิต |
---|---|---|
อุปกรณ์ Android Watch (เนื่องจากหน้าจอมีขนาดเล็กกว่า) | 416MB | ไม่เกี่ยวข้อง |
|
424MB | 704MB |
|
512MB | 832MB |
|
896MB | 1280MB |
|
1344MB | 1824MB |
ค่าหน่วยความจำขั้นต่ำต้องเพิ่มจากพื้นที่หน่วยความจำที่กําหนดไว้สําหรับคอมโพเนนต์ฮาร์ดแวร์ เช่น วิทยุ วิดีโอ และอื่นๆ ที่ไม่ได้อยู่ภายใต้การควบคุมของเคิร์กัล
การใช้งานอุปกรณ์ที่มีหน่วยความจำน้อยกว่า 512 MB สำหรับเคอร์เนลและพื้นที่ผู้ใช้ จะต้องแสดงผลค่า "จริง" สำหรับ ActivityManager.isLowRamDevice() ยกเว้น Android Watch
อุปกรณ์ Android TV ต้องมีพื้นที่เก็บข้อมูลอย่างน้อย 5 GB และการใช้งานอุปกรณ์อื่นๆ ต้องมีพื้นที่เก็บข้อมูลแบบถาวรอย่างน้อย 1.5 GB สำหรับข้อมูลส่วนตัวของแอปพลิเคชัน กล่าวคือ พาร์ติชัน /data ต้องมีอย่างน้อย 5 GB สำหรับอุปกรณ์ Android TV และอย่างน้อย 1.5 GB สำหรับการติดตั้งใช้งานในอุปกรณ์อื่นๆ เราขอแนะนำอย่างยิ่งให้อุปกรณ์ที่ใช้ Android มีพื้นที่เก็บข้อมูลแบบถาวรอย่างน้อย 3 GB สำหรับข้อมูลส่วนตัวของแอปพลิเคชันเพื่อให้สามารถอัปเกรดเป็นแพลตฟอร์มรุ่นในอนาคตได้
Android API มีเครื่องมือจัดการการดาวน์โหลดที่แอปพลิเคชันอาจใช้เพื่อดาวน์โหลดไฟล์ข้อมูล [แหล่งข้อมูล, 115] การติดตั้งใช้งานตัวจัดการการดาวน์โหลดในอุปกรณ์ต้องสามารถดาวน์โหลดไฟล์แต่ละไฟล์ที่มีขนาดอย่างน้อย 100 MB ไปยังตำแหน่ง "แคช" เริ่มต้น
7.6.2. พื้นที่เก็บข้อมูลที่ใช้ร่วมกันของแอปพลิเคชัน
การติดตั้งใช้งานอุปกรณ์ต้องมีพื้นที่เก็บข้อมูลที่ใช้ร่วมกันสำหรับแอปพลิเคชัน ซึ่งมักเรียกว่า "พื้นที่เก็บข้อมูลภายนอกที่ใช้ร่วมกัน"
การติดตั้งใช้งานอุปกรณ์ต้องกำหนดค่าด้วยพื้นที่เก็บข้อมูลที่ใช้ร่วมกันซึ่งติดตั้งโดยค่าเริ่มต้น "พร้อมใช้งานทันที" หากไม่ได้ติดตั้งพื้นที่เก็บข้อมูลที่ใช้ร่วมกันในเส้นทาง /sdcard ของ Linux อุปกรณ์ต้องมีลิงก์สัญลักษณ์ Linux จาก /sdcard ไปยังจุดต่อเชื่อมจริง
การติดตั้งใช้งานอุปกรณ์อาจมีฮาร์ดแวร์สำหรับพื้นที่เก็บข้อมูลที่ถอดออกได้ซึ่งผู้ใช้เข้าถึงได้ เช่น ช่องเสียบการ์ด Secure Digital (SD) หากใช้ช่องนี้เพื่อปฏิบัติตามข้อกำหนดของพื้นที่เก็บข้อมูลที่ใช้ร่วมกัน การติดตั้งใช้งานอุปกรณ์จะมีลักษณะดังนี้
- ต้องใช้อินเทอร์เฟซผู้ใช้แบบป๊อปอัปหรือแบบแสดงข้อมูลชั่วคราวเพื่อเตือนผู้ใช้เมื่อไม่มีการ์ด SD
- ต้องมีการ์ด SD รูปแบบ FAT ขนาด 1 GB ขึ้นไป หรือแสดงบนกล่องและสื่ออื่นๆ ที่มีให้ ณ เวลาที่ซื้อว่าต้องซื้อการ์ด SD แยกต่างหาก
- ต้องต่อเชื่อมการ์ด SD โดยค่าเริ่มต้น
หรือการติดตั้งใช้งานอุปกรณ์อาจจัดสรรพื้นที่เก็บข้อมูลภายใน (แบบถอดออกไม่ได้) เป็นพื้นที่เก็บข้อมูลที่ใช้ร่วมกันสำหรับแอปตามที่รวมอยู่ในโปรเจ็กต์โอเพนซอร์ส Android ต้นทาง การติดตั้งใช้งานอุปกรณ์ควรใช้การกำหนดค่านี้และการติดตั้งใช้งานซอฟต์แวร์ หากการติดตั้งใช้งานอุปกรณ์ใช้พื้นที่เก็บข้อมูลภายใน (แบบถอดไม่ได้) เพื่อตอบสนองข้อกำหนดของพื้นที่เก็บข้อมูลที่ใช้ร่วมกัน แม้ว่าพื้นที่เก็บข้อมูลดังกล่าวอาจแชร์พื้นที่กับข้อมูลส่วนตัวของแอปพลิเคชัน แต่พื้นที่เก็บข้อมูลดังกล่าวต้องมีขนาดอย่างน้อย 1 GB และติดตั้งใน /sdcard (หรือ /sdcard ต้องเป็นลิงก์สัญลักษณ์ไปยังตำแหน่งจริงหากติดตั้งไว้ที่อื่น)
การใช้งานอุปกรณ์ต้องบังคับใช้สิทธิ์ android.permission.WRITE_EXTERNAL_STORAGE ในพื้นที่เก็บข้อมูลที่แชร์นี้ตามที่ระบุไว้ มิเช่นนั้น แอปพลิเคชันใดก็ตามที่ได้รับสิทธิ์ดังกล่าวต้องเขียนลงในพื้นที่เก็บข้อมูลที่ใช้ร่วมกันได้
การติดตั้งใช้งานอุปกรณ์ที่มีเส้นทางพื้นที่เก็บข้อมูลที่ใช้ร่วมกันหลายเส้นทาง (เช่น ทั้งช่องการ์ด SD และพื้นที่เก็บข้อมูลภายในที่แชร์) ต้องอนุญาตให้เฉพาะแอปพลิเคชัน Android ที่ติดตั้งไว้ล่วงหน้าและมีสิทธิ์ซึ่งมีสิทธิ์ WRITE_EXTERNAL_STORAGE เท่านั้นที่เขียนลงในพื้นที่เก็บข้อมูลภายนอกรอง ยกเว้นเมื่อเขียนลงในไดเรกทอรีเฉพาะแพ็กเกจหรือภายใน URI
ที่แสดงผลจากการเรียกใช้ Intent ACTION_OPEN_DOCUMENT_TREE
อย่างไรก็ตาม การใช้งานอุปกรณ์ควรแสดงเนื้อหาจากทั้ง 2 เส้นทางของพื้นที่เก็บข้อมูลอย่างโปร่งใสผ่านบริการสแกนมัลติมีเดียของ Android และ android.provider.MediaStore
ไม่ว่าระบบจะใช้พื้นที่เก็บข้อมูลแบบใดก็ตาม หากการติดตั้งใช้งานอุปกรณ์มีพอร์ต USB ที่รองรับโหมดอุปกรณ์ต่อพ่วง USB อุปกรณ์นั้นจะต้องมีกลไกบางอย่างในการเข้าถึงเนื้อหาของพื้นที่เก็บข้อมูลที่ใช้ร่วมกันจากคอมพิวเตอร์โฮสต์ การติดตั้งใช้งานอุปกรณ์อาจใช้อุปกรณ์เก็บข้อมูลขนาดใหญ่ USB แต่ควรใช้ Media Transfer Protocol เพื่อปฏิบัติตามข้อกำหนดนี้ หากการติดตั้งใช้งานอุปกรณ์รองรับ Media Transfer Protocol อุปกรณ์จะดำเนินการต่อไปนี้
- ควรเข้ากันได้กับโฮสต์ MTP ของ Android ที่ใช้อ้างอิง ซึ่งก็คือ Android File Transfer [แหล่งข้อมูล, 116]
- ควรรายงานคลาสอุปกรณ์ USB เป็น 0x00
- ควรรายงานชื่ออินเทอร์เฟซ USB เป็น "MTP"
7.6.3. พื้นที่เก็บข้อมูลแบบ Adoptable
ขอแนะนำอย่างยิ่งให้ใช้พื้นที่เก็บข้อมูลที่รองรับหากพอร์ตอุปกรณ์เก็บข้อมูลแบบถอดได้อยู่ในตำแหน่งที่มั่นคงในระยะยาว เช่น ภายในกล่องแบตเตอรี่หรือฝาครอบป้องกันอื่นๆ [แหล่งข้อมูล, 117]
การติดตั้งใช้งานอุปกรณ์ เช่น ทีวี อาจเปิดใช้การนำไปใช้ผ่านพอร์ต USB ได้ เนื่องจากอุปกรณ์ดังกล่าวคาดว่าจะอยู่กับที่และไม่ใช่อุปกรณ์เคลื่อนที่ แต่สำหรับการติดตั้งใช้งานอุปกรณ์อื่นๆ ที่มีลักษณะเป็นอุปกรณ์เคลื่อนที่ เราขอแนะนำอย่างยิ่งให้ใช้พื้นที่เก็บข้อมูลที่นำมาใช้ได้ในตำแหน่งที่มั่นคงในระยะยาว เนื่องจากการเชื่อมต่ออุปกรณ์ออกโดยไม่ตั้งใจอาจทำให้ข้อมูลสูญหาย/เสียหาย
7.7. USB
การติดตั้งใช้งานอุปกรณ์ควรรองรับโหมดอุปกรณ์ต่อพ่วง USB และควรรองรับโหมดโฮสต์ USB
หากการติดตั้งใช้งานอุปกรณ์มีพอร์ต USB ที่รองรับโหมดอุปกรณ์ต่อพ่วง ให้ทำดังนี้
- พอร์ตต้องเชื่อมต่อกับโฮสต์ USB ที่มีพอร์ต USB มาตรฐาน Type-A หรือ Type-C ได้
- พอร์ตควรใช้รูปแบบของ USB แบบไมโคร-B, ไมโคร-AB หรือ Type-C เราขอแนะนำอย่างยิ่งให้อุปกรณ์ Android ที่มีอยู่และอุปกรณ์ใหม่มีคุณสมบัติตรงตามข้อกำหนดเหล่านี้เพื่อให้อัปเกรดเป็นแพลตฟอร์มรุ่นต่อๆ ไปได้
- พอร์ตควรอยู่ด้านล่างของอุปกรณ์ (ตามการวางแนวตามปกติ) หรือเปิดใช้การหมุนหน้าจอด้วยซอฟต์แวร์สำหรับแอปทั้งหมด (รวมถึงหน้าจอหลัก) เพื่อให้จอแสดงผลวาดภาพได้อย่างถูกต้องเมื่ออุปกรณ์วางแนวโดยให้พอร์ตอยู่ด้านล่าง เราขอแนะนำอย่างยิ่งให้อุปกรณ์ Android ทั้งเครื่องเก่าและเครื่องใหม่มีคุณสมบัติตรงตามข้อกำหนดเหล่านี้เพื่อให้อัปเกรดเป็นแพลตฟอร์มรุ่นถัดไปได้
- อุปกรณ์ควรใช้ API และข้อกำหนดของ Android Open Accessory (AOA) ตามที่ระบุไว้ในเอกสารประกอบของ Android SDK และหากเป็นอุปกรณ์ Android แบบพกพา อุปกรณ์นั้นต้องใช้ AOA API การติดตั้งใช้งานอุปกรณ์ที่ใช้ข้อกำหนด AOA
- ต้องประกาศการรองรับฟีเจอร์ฮาร์ดแวร์ android.hardware.usb.accessory [แหล่งข้อมูล, 118]
- ต้องรองรับการสร้างการสื่อสารตามโปรโตคอล AOA เมื่อเชื่อมต่อกับเครื่องโฮสต์ USB ที่ทำหน้าที่เป็นอุปกรณ์เสริมเป็นครั้งแรก โดยที่ผู้ใช้ไม่ต้องเปลี่ยนโหมด USB เริ่มต้น
- ต้องติดตั้งใช้งานคลาสเสียง USB ตามที่ระบุไว้ในเอกสารประกอบ Android SDK [แหล่งข้อมูล, 119]
- และคลาสอุปกรณ์เก็บข้อมูลขนาดใหญ่ USB ต้องมีสตริง "android" ที่ท้ายสตริงคำอธิบายอินเทอร์เฟซ
iInterface
ของอุปกรณ์เก็บข้อมูลขนาดใหญ่ USB
- ควรรองรับการดึงกระแส 1.5 A ระหว่างการส่งสัญญาณ HS และการรับส่งข้อมูล ตามที่ระบุไว้ในข้อกำหนดการชาร์จแบตเตอรี่ USB ฉบับแก้ไขครั้งที่ 1.2 [แหล่งข้อมูล, 120] เราขอแนะนำอย่างยิ่งให้อุปกรณ์ Android ที่มีอยู่และอุปกรณ์ใหม่มีคุณสมบัติตรงตามข้อกำหนดเหล่านี้เพื่อให้อัปเกรดเป็นแพลตฟอร์มรุ่นในอนาคตได้ มาตรฐานตัวต้านทาน Type-C
- ค่าของ iSerialNumber ในข้อบ่งชี้อุปกรณ์มาตรฐาน USB ต้องเท่ากับค่าของ android.os.Build.SERIAL
หากการติดตั้งใช้งานอุปกรณ์มีพอร์ต USB ที่รองรับโหมดโฮสต์ อุปกรณ์จะมีลักษณะดังนี้
- ควรใช้พอร์ต USB Type-C หากการติดตั้งใช้งานอุปกรณ์รองรับ USB 3.1
- ใช้รูปแบบพอร์ตที่ไม่ใช่มาตรฐานได้ แต่หากใช้ อุปกรณ์ต้องมาพร้อมกับสายหรือสายที่แปลงพอร์ตเป็นพอร์ต USB Type-A หรือ Type-C มาตรฐาน
- อาจใช้พอร์ต USB แบบไมโคร AB แต่หากใช้ ก็ควรมีสายสำหรับแปลงพอร์ตเป็นพอร์ต USB มาตรฐาน Type-A หรือ Type-C
- เราขอแนะนำอย่างยิ่งให้ใช้คลาสเสียง USB ตามที่ระบุไว้ในเอกสารประกอบ Android SDK [แหล่งข้อมูล, 119]
- ต้องติดตั้งใช้งาน Android USB Host API ตามที่ระบุไว้ใน Android SDK และ ต้องประกาศการรองรับฟีเจอร์ฮาร์ดแวร์ android.hardware.usb.host [แหล่งข้อมูล, 121]
- ควรรองรับการชาร์จอุปกรณ์ขณะอยู่ในโหมดโฮสต์ แสดงกระแสแหล่งที่มาอย่างน้อย 1.5A ตามที่ระบุไว้ในส่วนพารามิเตอร์การสิ้นสุดของข้อกำหนดเฉพาะสำหรับสายและขั้วต่อ USB Type-C ฉบับที่ 1.2 [] สำหรับขั้วต่อ USB Type-C หรือใช้ช่วงกระแสเอาต์พุตของพอร์ตดาวน์สตรีมการชาร์จ(CDP) ตามที่ระบุไว้ในข้อกำหนดเฉพาะการชาร์จแบตเตอรี่ USB ฉบับที่ 1.2 [แหล่งข้อมูล, 120] สำหรับขั้วต่อ Micro-AB
7.8. เสียง
7.8.1. ไมโครโฟน
การใช้งาน Android สำหรับมือถือ นาฬิกา และยานยนต์ต้องมีไมโครโฟน
การติดตั้งใช้งานอุปกรณ์อาจไม่รวมไมโครโฟน อย่างไรก็ตาม หากการใช้งานอุปกรณ์ไม่มีไมโครโฟน อุปกรณ์ต้องไม่รายงานค่าคงที่ของฟีเจอร์ android.hardware.microphone และต้องใช้งาน API การบันทึกเสียงเป็น No-Op เป็นอย่างน้อย ตามส่วนที่ 7 ในทางกลับกัน การใช้งานอุปกรณ์ที่มีไมโครโฟนจะมีลักษณะดังนี้
- ต้องรายงานค่าคงที่ของฟีเจอร์ android.hardware.microphone
- ต้องเป็นไปตามข้อกำหนดการบันทึกเสียงในส่วนที่ 5.4
- ต้องเป็นไปตามข้อกำหนดเวลาในการตอบสนองของเสียงในส่วนที่ 5.6
- ขอแนะนำอย่างยิ่งให้รองรับการบันทึกเสียงที่ใกล้เคียงกับคลื่นอัลตราซาวด์ตามที่อธิบายไว้ในส่วนที่ 7.8.3
7.8.2 เอาต์พุตเสียง
อุปกรณ์ Android Watch อาจมีเอาต์พุตเสียง
การติดตั้งใช้งานอุปกรณ์ที่มีลำโพงหรือมีพอร์ตเอาต์พุตเสียง/มัลติมีเดียสำหรับอุปกรณ์ต่อพ่วงเอาต์พุตเสียง เช่น ชุดหูฟังหรือลำโพงภายนอก
- ต้องรายงานค่าคงที่ของฟีเจอร์ android.hardware.audio.output
- ต้องเป็นไปตามข้อกำหนดการเล่นเสียงในส่วนที่ 5.5
- ต้องเป็นไปตามข้อกำหนดเกี่ยวกับเวลาในการตอบสนองของเสียงในส่วนที่ 5.6
- ขอแนะนำอย่างยิ่งให้รองรับการเล่นที่เกือบเป็นคลื่นอัลตราซาวด์ตามที่อธิบายไว้ในส่วนที่ 7.8.3
ในทางกลับกัน หากการติดตั้งใช้งานอุปกรณ์ไม่มีลำโพงหรือพอร์ตเอาต์พุตเสียง อุปกรณ์ต้องไม่รายงานฟีเจอร์เอาต์พุต android.hardware.audio และต้องใช้ API ที่เกี่ยวข้องกับเอาต์พุตเสียงเป็น No-Op เป็นอย่างน้อย
การใช้งานอุปกรณ์ Android Watch อาจ (แต่ไม่ควร) มีเอาต์พุตเสียง แต่การใช้งานอุปกรณ์ Android ประเภทอื่นๆ ต้องมีเอาต์พุตเสียงและประกาศ android.hardware.audio.output
7.8.2.1. พอร์ตเสียงแบบแอนะล็อก
เพื่อให้ใช้งานร่วมกับชุดหูฟังและอุปกรณ์เสริมอื่นๆ สำหรับเสียงที่ใช้ปลั๊กเสียง 3.5 มม. ในระบบนิเวศของ Android ได้ [แหล่งข้อมูล, 122] หากการติดตั้งใช้งานอุปกรณ์มีพอร์ตเสียงแอนะล็อกอย่างน้อย 1 พอร์ต พอร์ตเสียงอย่างน้อย 1 พอร์ตควรเป็นช่องเสียบเสียง 3.5 มม. แบบ 4 ตัวนำ หากการใช้งานอุปกรณ์มีช่องเสียบเสียง 3.5 มม. แบบ 4 สาย อุปกรณ์จะมีลักษณะดังนี้
- ต้องรองรับการเล่นเสียงผ่านหูฟังสเตอริโอและชุดหูฟังสเตอริโอที่มีไมโครโฟน และควรรองรับการบันทึกเสียงจากชุดหูฟังสเตอริโอที่มีไมโครโฟน
- ต้องรองรับปลั๊กเสียง TRRS ที่มีลําดับการต่อขาต่อ CTIA และควรรองรับปลั๊กเสียงที่มีลําดับการต่อขาต่อ OMTP
- ต้องรองรับการตรวจหาไมโครโฟนในอุปกรณ์เสริมเสียงที่เสียบอยู่ หากการใช้งานอุปกรณ์รองรับไมโครโฟน และออกอากาศ android.intent.action.HEADSET_PLUG โดยตั้งค่าไมโครโฟนค่าพิเศษเป็น 1
- ควรรองรับการตรวจจับและการแมปกับคีย์โค้ดสำหรับช่วงอิมพีแดนซ์ที่เทียบเท่า 3 ช่วงต่อไปนี้ระหว่างตัวนำไมโครโฟนและสายกราวด์บนปลั๊กเสียง
- 70 โอห์มหรือน้อยกว่า: KEYCODE_HEADSETHOOK
- 210-290 โอห์ม: KEYCODE_VOLUME_UP
- 360-680 โอห์ม: KEYCODE_VOLUME_DOWN
- ควรรองรับการตรวจจับและการแมปกับรหัสคีย์สำหรับช่วงต่อไปนี้ของอิมพีแดนซ์ที่เทียบเท่าระหว่างไมโครโฟนและตัวนำกราวด์บนปลั๊กเสียง
- 110-180 โอห์ม: KEYCODE_VOICE_ASSIST
- ต้องทริกเกอร์ ACTION_HEADSET_PLUG เมื่อเสียบปลั๊ก แต่ต้องหลังจากที่หน้าสัมผัสทั้งหมดบนปลั๊กสัมผัสกับส่วนที่เกี่ยวข้องบนแจ็คแล้วเท่านั้น
- ต้องขับเคลื่อนแรงดันไฟฟ้าเอาต์พุตอย่างน้อย 150mV ± 10% ในอิมพีแดนซ์ของลำโพง 32 โอห์ม
- ต้องมีแรงดันไฟฟ้า Bias ของไมโครโฟนระหว่าง 1.8V ~ 2.9V
7.8.3. อัลตราซาวด์ระยะใกล้
เสียงที่เกือบเป็นคลื่นอัลตราซาวด์คือย่านความถี่ 18.5-20 KHz การติดตั้งใช้งานอุปกรณ์ต้องรายงานการรองรับความสามารถของเสียงย่านความถี่อัลตราซาวด์อย่างถูกต้องผ่าน AudioManager.getProperty API ดังนี้
- หาก PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND เป็น "true" ให้ทำดังนี้
- การตอบสนองกำลังไฟฟ้าเฉลี่ยของไมโครโฟนในย่านความถี่ 18.5 kHz ถึง 20 kHz ต้องต่ำกว่าการตอบสนองที่ 2 kHz ไม่เกิน 15 dB
- อัตราส่วนสัญญาณต่อสัญญาณรบกวน (SNR) ที่ไม่ถ่วงน้ำหนักของไมโครโฟนในช่วง 18.5 kHz ถึง 20 kHz สำหรับเสียงความถี่ 19 kHz ที่ -26 dBFS ต้องไม่ต่ำกว่า 50 dB
- หาก PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND เป็น "จริง" การตอบสนองค่าเฉลี่ยของลำโพงในย่านความถี่ 18.5 kHz - 20 kHz ต้องไม่ต่ำกว่า 40 dB ต่ำกว่าการตอบสนองที่ 2 kHz
8. ประสิทธิภาพและกำลังไฟ
เกณฑ์ประสิทธิภาพและพลังงานขั้นต่ำบางอย่างมีความสำคัญต่อประสบการณ์ของผู้ใช้และส่งผลต่อสมมติฐานพื้นฐานที่นักพัฒนาแอปจะมีเมื่อพัฒนาแอป อุปกรณ์ Android Watch ควรและการติดตั้งใช้งานอุปกรณ์ประเภทอื่นๆ ต้องเป็นไปตามเกณฑ์ต่อไปนี้
8.1. ความสอดคล้องของประสบการณ์ของผู้ใช้
การติดตั้งใช้งานอุปกรณ์ต้องให้อินเทอร์เฟซผู้ใช้ที่ราบรื่นโดยการตรวจสอบอัตราเฟรมและเวลาในการตอบสนองที่สอดคล้องกันสำหรับแอปพลิเคชันและเกม การติดตั้งใช้งานอุปกรณ์ต้องเป็นไปตามข้อกำหนดต่อไปนี้
- เวลาในการตอบสนองของเฟรมที่สอดคล้องกัน เวลาในการตอบสนองของเฟรมที่ไม่สอดคล้องกันหรือการเลื่อนเวลาแสดงผลเฟรมต้องไม่เกิดขึ้นบ่อยกว่า 5 เฟรมต่อวินาที และควรน้อยกว่า 1 เฟรมต่อวินาที
- เวลาในการตอบสนองของอินเทอร์เฟซผู้ใช้ การติดตั้งใช้งานอุปกรณ์ต้องช่วยให้ผู้ใช้ได้รับประสบการณ์การใช้งานที่เวลาในการตอบสนองต่ำโดยการเลื่อนรายการรายการ 10,000 รายการตามที่ชุดเครื่องมือทดสอบความเข้ากันได้ของ Android (CTS) กำหนดภายในเวลาไม่ถึง 36 วินาที
- การสลับงาน เมื่อเปิดแอปพลิเคชันหลายรายการแล้ว การเปิดตัวแอปพลิเคชันที่ทำงานอยู่แล้วอีกครั้งหลังจากเปิดตัวแล้วต้องใช้เวลาไม่ถึง 1 วินาที
8.2. ประสิทธิภาพการเข้าถึง I/O ของไฟล์
การติดตั้งใช้งานอุปกรณ์ต้องตรวจสอบความสม่ำเสมอของประสิทธิภาพการเข้าถึงไฟล์ในที่จัดเก็บข้อมูลภายในสำหรับการดำเนินการอ่านและเขียน
- การเขียนตามลำดับ การติดตั้งใช้งานอุปกรณ์ต้องมีประสิทธิภาพการเขียนตามลำดับอย่างน้อย 5 MB/วินาทีสำหรับไฟล์ขนาด 256 MB โดยใช้บัฟเฟอร์การเขียนขนาด 10 MB
- การเขียนแบบสุ่ม การติดตั้งใช้งานอุปกรณ์ต้องมีประสิทธิภาพการเขียนแบบสุ่มอย่างน้อย 0.5 MB/วินาทีสำหรับไฟล์ขนาด 256 MB โดยใช้บัฟเฟอร์การเขียน 4 KB
- การอ่านตามลําดับ การติดตั้งใช้งานอุปกรณ์ต้องมีประสิทธิภาพการอ่านตามลำดับอย่างน้อย 15 MB/วินาทีสำหรับไฟล์ขนาด 256 MB โดยใช้บัฟเฟอร์การเขียนขนาด 10 MB
- การอ่านแบบสุ่ม การติดตั้งใช้งานอุปกรณ์ต้องมีประสิทธิภาพการอ่านแบบสุ่มอย่างน้อย 3.5 MB/วินาทีสำหรับไฟล์ขนาด 256 MB โดยใช้บัฟเฟอร์การเขียน 4 KB
8.3 โหมดประหยัดพลังงาน
แอปทั้งหมดที่ได้รับการยกเว้นจากโหมดแอปรอและ/หรือโหมดสลีปต้องแสดงให้ผู้ใช้ปลายทางเห็น นอกจากนี้ อัลกอริทึมการทริกเกอร์ การดูแลรักษา การตื่น และการใช้การตั้งค่าระบบส่วนกลางของโหมดประหยัดพลังงานเหล่านี้ต้องไม่แตกต่างจากโปรเจ็กต์โอเพนซอร์ส Android
8.4 การบัญชีการใช้พลังงาน
การบัญชีและการรายงานการสิ้นเปลืองพลังงานที่แม่นยำยิ่งขึ้นจะช่วยให้นักพัฒนาแอปมีแรงจูงใจและเครื่องมือในการเพิ่มประสิทธิภาพรูปแบบการใช้พลังงานของแอปพลิเคชัน ดังนั้น การติดตั้งใช้งานอุปกรณ์จึงมีลักษณะดังนี้
- ต้องสามารถติดตามการใช้พลังงานของคอมโพเนนต์ฮาร์ดแวร์และระบุแหล่งที่มาของการใช้พลังงานนั้นให้กับแอปพลิเคชันหนึ่งๆ กล่าวโดยละเอียดคือ การใช้งานต้องมีลักษณะดังนี้
- ต้องระบุโปรไฟล์พลังงานต่อคอมโพเนนต์ที่กําหนดค่าการใช้พลังงานปัจจุบันสําหรับคอมโพเนนต์ฮาร์ดแวร์แต่ละรายการและการสิ้นเปลืองแบตเตอรี่โดยประมาณที่เกิดจากคอมโพเนนต์เมื่อเวลาผ่านไปตามที่ระบุไว้ในเว็บไซต์โปรเจ็กต์โอเพนซอร์ส Android [แหล่งข้อมูล, 123]
- ต้องรายงานค่าการใช้พลังงานทั้งหมดเป็นมิลลิแอมป์ชั่วโมง (mAh)
- ควรระบุแหล่งที่มาเป็นคอมโพเนนต์ฮาร์ดแวร์เอง หากไม่สามารถระบุแหล่งที่มาเป็นการใช้พลังงานของคอมโพเนนต์ฮาร์ดแวร์ในแอปพลิเคชันได้
- ต้องรายงานการใช้พลังงานของ CPU ต่อ UID ของแต่ละกระบวนการ โครงการโอเพนซอร์ส Android เป็นไปตามข้อกำหนดผ่านการใช้งาน
uid_cputime
ของโมดูลเคอร์เนล
- ต้องทำให้การใช้พลังงานนี้พร้อมใช้งานผ่านคำสั่งเชลล์
adb shell dumpsys batterystats
ให้แก่นักพัฒนาแอป [แหล่งข้อมูล, 124] - ต้องปฏิบัติตาม Intent android.intent.action.POWER_USAGE_SUMMARY และแสดงเมนูการตั้งค่าที่แสดงปริมาณการใช้พลังงานนี้ [แหล่งข้อมูล, 125]
9. ความเข้ากันได้ของรูปแบบการรักษาความปลอดภัย
การติดตั้งใช้งานอุปกรณ์ต้องใช้รูปแบบการรักษาความปลอดภัยที่สอดคล้องกับรูปแบบการรักษาความปลอดภัยของแพลตฟอร์ม Android ตามที่ระบุไว้ในเอกสารอ้างอิงเกี่ยวกับความปลอดภัยและสิทธิ์ใน API [แหล่งข้อมูล, 126] ในเอกสารประกอบสำหรับนักพัฒนาแอป Android การติดตั้งใช้งานอุปกรณ์ต้องรองรับการติดตั้งแอปพลิเคชันที่ลงนามด้วยตนเองโดยไม่ต้องขอสิทธิ์/ใบรับรองเพิ่มเติมจากบุคคลที่สาม/หน่วยงาน กล่าวโดยละเอียดคือ อุปกรณ์ที่เข้ากันได้ต้องรองรับกลไกความปลอดภัยที่อธิบายไว้ในส่วนย่อยต่อไปนี้
9.1. สิทธิ์
การติดตั้งใช้งานอุปกรณ์ต้องรองรับรูปแบบสิทธิ์ของ Android ตามที่ระบุไว้ในเอกสารสำหรับนักพัฒนาแอป Android [แหล่งข้อมูล, 126] กล่าวโดยละเอียดคือ การใช้งานต้องบังคับใช้สิทธิ์แต่ละรายการตามที่อธิบายไว้ในเอกสารประกอบ SDK โดยต้องไม่ละเว้น เปลี่ยนแปลง หรือละเลยสิทธิ์ใดๆ การใช้งานอาจเพิ่มสิทธิ์เพิ่มเติมได้ ตราบใดที่สตริงรหัสสิทธิ์ใหม่ไม่ได้อยู่ในเนมสเปซ android.*
สิทธิ์ที่มีระดับการป้องกันเป็น "อันตราย" คือสิทธิ์รันไทม์ แอปพลิเคชันที่มี targetSdkVersion มากกว่า 22 จะขอข้อมูลดังกล่าวขณะรันไทม์ การติดตั้งใช้งานอุปกรณ์
- ต้องแสดงอินเทอร์เฟซเฉพาะเพื่อให้ผู้ใช้ตัดสินใจว่าจะให้สิทธิ์รันไทม์ที่ขอหรือไม่ รวมถึงต้องมีอินเทอร์เฟซสำหรับให้ผู้ใช้จัดการสิทธิ์รันไทม์ด้วย
- ต้องมีการติดตั้งใช้งานอินเทอร์เฟซผู้ใช้ทั้ง 2 รายการเพียงรายการเดียว
- ต้องไม่ให้สิทธิ์รันไทม์แก่แอปที่ติดตั้งไว้ล่วงหน้า เว้นแต่ในกรณีต่อไปนี้
- ขอความยินยอมจากผู้ใช้ได้ก่อนที่แอปพลิเคชันจะใช้ข้อมูล
- สิทธิ์รันไทม์เชื่อมโยงกับรูปแบบ Intent ที่กำหนดแอปพลิเคชันที่ติดตั้งไว้ล่วงหน้าเป็นตัวแฮนเดิลเริ่มต้น
9.2. UID และการแยกกระบวนการ
การติดตั้งใช้งานอุปกรณ์ต้องรองรับรูปแบบแซนด์บ็อกซ์แอปพลิเคชันของ Android ซึ่งแอปพลิเคชันแต่ละรายการจะทำงานเป็น UID สไตล์ Unix ที่ไม่ซ้ำกันและในกระบวนการแยกต่างหาก การติดตั้งใช้งานอุปกรณ์ต้องรองรับการเรียกใช้แอปพลิเคชันหลายรายการเป็นรหัสผู้ใช้ Linux เดียวกัน โดยมีเงื่อนไขว่าแอปพลิเคชันได้รับการลงชื่อและสร้างอย่างถูกต้องตามที่ระบุไว้ในข้อมูลอ้างอิงด้านความปลอดภัยและสิทธิ์ [แหล่งข้อมูล, 126]
9.3. สิทธิ์ในระบบไฟล์
การติดตั้งใช้งานอุปกรณ์ต้องรองรับรูปแบบสิทธิ์การเข้าถึงไฟล์ Android ตามที่ระบุไว้ในข้อมูลอ้างอิงด้านความปลอดภัยและสิทธิ์ [ทรัพยากร, 126]
9.4. สภาพแวดล้อมการดําเนินการอื่น
การติดตั้งใช้งานอุปกรณ์อาจรวมถึงสภาพแวดล้อมรันไทม์ที่เรียกใช้แอปพลิเคชันโดยใช้ซอฟต์แวร์หรือเทคโนโลยีอื่นที่ไม่ใช่รูปแบบไฟล์ Dalvik Executable หรือโค้ดแบบเนทีฟ อย่างไรก็ตาม สภาพแวดล้อมการเรียกใช้ทางเลือกดังกล่าวต้องไม่ทำให้รูปแบบความปลอดภัยของ Android หรือความปลอดภัยของแอปพลิเคชัน Android ที่ติดตั้งไว้ลดลงตามที่อธิบายไว้ในส่วนนี้
รันไทม์ทางเลือกต้องเป็นแอปพลิเคชัน Android และเป็นไปตามรูปแบบการรักษาความปลอดภัยมาตรฐานของ Android ตามที่อธิบายไว้ในส่วนอื่นๆ ในส่วนที่ 9
รันไทม์อื่นต้องไม่ได้รับสิทธิ์เข้าถึงทรัพยากรที่ได้รับการปกป้องโดยสิทธิ์ที่ไม่ได้ขอในไฟล์ AndroidManifest.xml ของรันไทม์ผ่านกลไก <uses-permission>
รันไทม์ทางเลือกต้องไม่อนุญาตให้แอปพลิเคชันใช้ประโยชน์จากฟีเจอร์ที่ได้รับการปกป้องโดยสิทธิ์ Android ที่จำกัดไว้สำหรับแอปพลิเคชันระบบ
รันไทม์ทางเลือกต้องเป็นไปตามรูปแบบแซนด์บ็อกซ์ของ Android กล่าวโดยละเอียดคือ รันไทม์ทางเลือก
- ควรติดตั้งแอปผ่าน PackageManager ลงในแซนด์บ็อกซ์ Android แยกต่างหาก (รหัสผู้ใช้ Linux ฯลฯ)
- อาจจัดหาแซนด์บ็อกซ์ Android เดียวที่แอปพลิเคชันทั้งหมดใช้ร่วมกันโดยใช้รันไทม์สำรอง
- และแอปพลิเคชันที่ติดตั้งโดยใช้รันไทม์อื่น ต้องไม่นําแซนด์บ็อกซ์ของแอปอื่นที่ติดตั้งในอุปกรณ์มาใช้ซ้ำ ยกเว้นผ่านกลไกมาตรฐานของ Android สําหรับรหัสผู้ใช้และใบรับรองการรับรองที่ใช้ร่วมกัน
- ต้องไม่เปิดใช้งาน ให้สิทธิ์ หรือได้รับสิทธิ์เข้าถึงแซนด์บ็อกซ์ที่สอดคล้องกับแอปพลิเคชัน Android อื่นๆ
- ต้องไม่เปิดใช้งาน ไม่ได้รับสิทธิ์ หรือให้สิทธิ์แอปพลิเคชันอื่นๆ เกี่ยวกับอภิสิทธิ์ของผู้ดูแลระบบ (รูท) หรือรหัสผู้ใช้อื่นๆ
ไฟล์ .apk ของรันไทม์อื่นอาจรวมอยู่ในอิมเมจระบบของการติดตั้งใช้งานอุปกรณ์ แต่ต้องลงนามด้วยคีย์ที่แตกต่างจากคีย์ที่ใช้ลงนามแอปพลิเคชันอื่นๆ ที่รวมอยู่ในการติดตั้งใช้งานอุปกรณ์
เมื่อติดตั้งแอปพลิเคชัน รันไทม์อื่นต้องได้รับความยินยอมจากผู้ใช้สำหรับสิทธิ์ Android ที่แอปพลิเคชันใช้ หากแอปพลิเคชันต้องใช้ทรัพยากรของอุปกรณ์ซึ่งมีสิทธิ์ Android ที่เกี่ยวข้อง (เช่น กล้อง, GPS ฯลฯ) รันไทม์สำรองต้องแจ้งให้ผู้ใช้ทราบว่าแอปพลิเคชันจะเข้าถึงทรัพยากรนั้นได้ หากสภาพแวดล้อมรันไทม์ไม่ได้บันทึกความสามารถของแอปพลิเคชันด้วยวิธีนี้ สภาพแวดล้อมรันไทม์ต้องแสดงรายการสิทธิ์ทั้งหมดที่รันไทม์มีเมื่อติดตั้งแอปพลิเคชันที่ใช้รันไทม์นั้น
9.5 การรองรับผู้ใช้หลายคน
ฟีเจอร์นี้ไม่บังคับสำหรับอุปกรณ์ทุกประเภท
Android รองรับผู้ใช้หลายคนและรองรับการแยกผู้ใช้อย่างเต็มรูปแบบ [แหล่งข้อมูล, 127] การติดตั้งใช้งานอุปกรณ์อาจเปิดใช้ผู้ใช้หลายคนได้ แต่เมื่อเปิดใช้แล้ว อุปกรณ์ต้องเป็นไปตามข้อกำหนดต่อไปนี้ที่เกี่ยวข้องกับการรองรับผู้ใช้หลายคน [แหล่งข้อมูล, 128]
- การติดตั้งใช้งานอุปกรณ์ที่ไม่ได้ประกาศ Flag ฟีเจอร์ android.hardware.telephony จะต้องรองรับโปรไฟล์ที่จํากัด ซึ่งเป็นฟีเจอร์ที่ช่วยให้เจ้าของอุปกรณ์จัดการผู้ใช้เพิ่มเติมและความสามารถของผู้ใช้เหล่านั้นในอุปกรณ์ได้ โปรไฟล์ที่จํากัดช่วยให้เจ้าของอุปกรณ์ตั้งค่าสภาพแวดล้อมแยกต่างหากสําหรับผู้ใช้เพิ่มเติมได้อย่างรวดเร็ว พร้อมทั้งจัดการข้อจํากัดที่ละเอียดยิ่งขึ้นในแอปที่ใช้ได้ในสภาพแวดล้อมเหล่านั้น
- ในทางกลับกัน การใช้งานอุปกรณ์ที่ประกาศ Flag ฟีเจอร์ android.hardware.telephony ต้องไม่รองรับโปรไฟล์ที่จํากัด แต่ต้องสอดคล้องกับการใช้งานการควบคุมของ AOSP เพื่อเปิด /ปิดใช้ไม่ให้ผู้ใช้รายอื่นเข้าถึงการโทรด้วยเสียงและ SMS
- การติดตั้งใช้งานอุปกรณ์ต้องติดตั้งใช้งานรูปแบบการรักษาความปลอดภัยที่สอดคล้องกับรูปแบบการรักษาความปลอดภัยของแพลตฟอร์ม Android ตามที่ระบุไว้ในเอกสารอ้างอิงเกี่ยวกับความปลอดภัยและสิทธิ์ใน API [แหล่งข้อมูล, 126] สำหรับผู้ใช้แต่ละราย
- อินสแตนซ์ผู้ใช้แต่ละรายการในอุปกรณ์ Android ต้องมีไดเรกทอรีพื้นที่เก็บข้อมูลภายนอกแยกต่างหากและแยกกัน การติดตั้งใช้งานอุปกรณ์อาจจัดเก็บข้อมูลของผู้ใช้หลายคนในวอลุ่มหรือระบบไฟล์เดียวกัน อย่างไรก็ตาม การติดตั้งใช้งานอุปกรณ์ต้องตรวจสอบว่าแอปพลิเคชันที่ผู้ใช้เป็นเจ้าของและเรียกใช้ในนามของผู้ใช้รายดังกล่าวไม่สามารถแสดงรายการ อ่าน หรือเขียนข้อมูลของผู้ใช้รายอื่น โปรดทราบว่าสื่อแบบถอดออกได้ เช่น ช่องการ์ด SD อาจอนุญาตให้ผู้ใช้รายหนึ่งเข้าถึงข้อมูลของผู้ใช้รายอื่นได้ผ่าน PC โฮสต์ ด้วยเหตุนี้ การติดตั้งใช้งานอุปกรณ์ที่ใช้สื่อแบบถอดออกได้สำหรับ API พื้นที่เก็บข้อมูลภายนอกหลักต้องเข้ารหัสเนื้อหาของการ์ด SD หากเปิดใช้ผู้ใช้หลายคนโดยใช้คีย์ที่จัดเก็บไว้ในสื่อแบบถอดออกไม่ได้เท่านั้นที่ระบบเข้าถึงได้ เนื่องจากพีซีโฮสต์จะอ่านสื่อไม่ได้ การติดตั้งใช้งานอุปกรณ์จะต้องเปลี่ยนไปใช้ MTP หรือระบบที่คล้ายกันเพื่อให้พีซีโฮสต์เข้าถึงข้อมูลของผู้ใช้ปัจจุบันได้ ดังนั้น การติดตั้งใช้งานอุปกรณ์อาจเปิดใช้ผู้ใช้หลายคนได้ แต่ไม่ควรเปิดใช้หากใช้สื่อแบบถอดออกได้ [แหล่งข้อมูล, 129] เป็นพื้นที่เก็บข้อมูลภายนอกหลัก
9.6 คำเตือนเกี่ยวกับ SMS แบบพรีเมียม
Android รองรับการเตือนผู้ใช้เกี่ยวกับข้อความ SMS แบบพรีเมียมขาออก [แหล่งข้อมูล, 130] ข้อความ SMS แบบพรีเมียมคือ SMS ที่ส่งไปยังบริการที่ลงทะเบียนกับผู้ให้บริการ ซึ่งอาจมีการเรียกเก็บเงินจากผู้ใช้ การติดตั้งใช้งานอุปกรณ์ที่ประกาศรองรับ android.hardware.telephony จะต้องเตือนผู้ใช้ก่อนส่งข้อความ SMS ไปยังหมายเลขที่ระบุด้วยนิพจน์ทั่วไปที่กําหนดไว้ในไฟล์ /data/misc/sms/codes.xml ในอุปกรณ์ โปรเจ็กต์โอเพนซอร์ส Android ต้นทางมีการใช้งานที่เป็นไปตามข้อกำหนดนี้
9.7 ฟีเจอร์ความปลอดภัยของเคิร์นัล
แซนด์บ็อกซ์ของ Android มีฟีเจอร์ที่ใช้ระบบการควบคุมการเข้าถึงแบบบังคับ (MAC) ของ Security-Enhanced Linux (SELinux) และฟีเจอร์ด้านความปลอดภัยอื่นๆ ในเคอร์เนล Linux SELinux หรือฟีเจอร์ความปลอดภัยอื่นๆ ที่ติดตั้งใช้งานด้านล่างเฟรมเวิร์ก Android
- ต้องคงความเข้ากันได้กับแอปพลิเคชันที่มีอยู่
- ต้องไม่มีอินเทอร์เฟซผู้ใช้ที่มองเห็นได้เมื่อตรวจพบการละเมิดความปลอดภัยและบล็อกได้สําเร็จ แต่อาจมีอินเทอร์เฟซผู้ใช้ที่มองเห็นได้เมื่อเกิดการละเมิดความปลอดภัยที่ระบบไม่ได้บล็อก ซึ่งส่งผลให้มีการแสวงหาประโยชน์สําเร็จ
- ไม่ควรกำหนดค่าโดยผู้ใช้หรือนักพัฒนาแอป
หาก API สำหรับการกำหนดค่านโยบายแสดงต่อแอปพลิเคชันที่สามารถส่งผลต่อแอปพลิเคชันอื่นได้ (เช่น Device Administration API) API นั้นต้องไม่อนุญาตให้มีการกำหนดค่าที่ทำให้ใช้งานร่วมกันไม่ได้
อุปกรณ์ต้องใช้ SELinux หรือหากใช้เคอร์เนลอื่นที่ไม่ใช่ Linux ให้ใช้ระบบควบคุมการเข้าถึงที่จําเป็นเทียบเท่า อุปกรณ์ต้องเป็นไปตามข้อกำหนดต่อไปนี้ด้วย ซึ่งเป็นไปตามการใช้งานอ้างอิงในโปรเจ็กต์โอเพนซอร์ส Android ต้นทาง
การติดตั้งใช้งานอุปกรณ์
- ต้องตั้งค่า SELinux เป็นโหมดการบังคับใช้แบบรวม
- ต้องกําหนดค่าโดเมนทั้งหมดในโหมดบังคับใช้ ไม่อนุญาตให้ใช้โดเมนโหมดอนุญาต รวมถึงโดเมนสำหรับอุปกรณ์/ผู้ให้บริการโดยเฉพาะ
- ต้องไม่แก้ไข ละเว้น หรือแทนที่กฎ neverallow ที่มีอยู่ในโฟลเดอร์ external/sepolicy ที่ระบุไว้ในโครงการโอเพนซอร์ส Android (AOSP) ต้นทาง และนโยบายต้องคอมไพล์ด้วยกฎ neverallow ทั้งหมดที่มีอยู่ ทั้งสำหรับโดเมน SELinux ของ AOSP และโดเมนเฉพาะอุปกรณ์/ผู้ให้บริการ
การใช้งานอุปกรณ์ควรเก็บนโยบาย SELinux เริ่มต้นไว้ตามที่ระบุไว้ในโฟลเดอร์ external/sepolicy ของโปรเจ็กต์โอเพนซอร์ส Android ต้นทาง และเพิ่มนโยบายนี้สำหรับการกำหนดค่าเฉพาะอุปกรณ์ของตนเองเท่านั้น การติดตั้งใช้งานในอุปกรณ์ต้องเข้ากันได้กับโครงการโอเพนซอร์ส Android เวอร์ชันที่พัฒนาขึ้นก่อนหน้า
9.8 ความเป็นส่วนตัว
หากอุปกรณ์ใช้ฟังก์ชันการทำงานในระบบที่จับภาพเนื้อหาที่แสดงบนหน้าจอและ/หรือบันทึกสตรีมเสียงที่เล่นในอุปกรณ์ อุปกรณ์จะต้องแจ้งให้ผู้ใช้ทราบอย่างต่อเนื่องทุกครั้งที่เปิดใช้ฟังก์ชันการทำงานนี้และกำลังจับภาพ/บันทึกอยู่
หากการติดตั้งใช้งานอุปกรณ์มีกลไกที่กำหนดเส้นทางการรับส่งข้อมูลเครือข่ายผ่านพร็อกซีเซิร์ฟเวอร์หรือเกตเวย์ VPN โดยค่าเริ่มต้น (เช่น โหลดบริการ VPN ล่วงหน้าด้วย android.permission.CONTROL_VPN ที่อนุญาต) การติดตั้งใช้งานอุปกรณ์จะต้องขอความยินยอมจากผู้ใช้ก่อนเปิดใช้กลไกดังกล่าว
หากการติดตั้งใช้งานอุปกรณ์มีพอร์ต USB ที่รองรับโหมดอุปกรณ์ต่อพ่วง USB อุปกรณ์นั้นต้องแสดงอินเทอร์เฟซผู้ใช้เพื่อขอความยินยอมจากผู้ใช้ก่อนที่จะอนุญาตให้เข้าถึงเนื้อหาของพื้นที่เก็บข้อมูลที่ใช้ร่วมกันผ่านพอร์ต USB
9.9. การเข้ารหัสดิสก์ทั้งเครื่อง
ไม่บังคับสำหรับการติดตั้งใช้งานอุปกรณ์ Android ที่ไม่มีหน้าจอล็อก
หากการติดตั้งใช้งานอุปกรณ์รองรับหน้าจอล็อกที่ปลอดภัยซึ่งรายงาน "true
" สำหรับ KeyguardManager.isDeviceSecure()
[แหล่งข้อมูล, 131] และไม่ใช่อุปกรณ์ที่มีหน่วยความจำจํากัดตามที่รายงานผ่านเมธอด ActivityManager.isLowRamDevice() อุปกรณ์ต้องรองรับการเข้ารหัสทั้งดิสก์ [แหล่งข้อมูล, 132] ของข้อมูลส่วนตัวของแอปพลิเคชัน (พาร์ติชัน /data) รวมถึงพาร์ติชันพื้นที่เก็บข้อมูลที่ใช้ร่วมกันของแอปพลิเคชัน (พาร์ติชัน /sdcard) หากเป็นส่วนถาวรที่ไม่สามารถนําออกได้ของอุปกรณ์
สำหรับการติดตั้งใช้งานอุปกรณ์ที่รองรับการเข้ารหัสทั้งดิสก์และมีประสิทธิภาพการเข้ารหัส Advanced Encryption Standard (AES) มากกว่า 50 MiB/วินาที จะต้องเปิดใช้การเข้ารหัสทั้งดิสก์โดยค่าเริ่มต้นเมื่อผู้ใช้ตั้งค่าอุปกรณ์จากกล่องเสร็จสมบูรณ์ หากมีการใช้งานอุปกรณ์ใน Android เวอร์ชันเก่าซึ่งปิดใช้การเข้ารหัสทั้งดิสก์โดยค่าเริ่มต้นอยู่แล้ว อุปกรณ์ดังกล่าวจะไม่สามารถปฏิบัติตามข้อกำหนดผ่านการอัปเดตซอฟต์แวร์ระบบ จึงอาจได้รับการยกเว้น
การเข้ารหัสต้องใช้ AES ที่มีคีย์ 128 บิต (หรือมากกว่า) และโหมดที่ออกแบบมาสำหรับพื้นที่เก็บข้อมูล (เช่น AES-XTS, AES-CBC-ESSIV) คีย์การเข้ารหัสต้องไม่เขียนลงในพื้นที่เก็บข้อมูลโดยไม่มีการเข้ารหัส นอกเหนือจากกรณีที่ใช้งานอยู่ คีย์การเข้ารหัสควรได้รับการเข้ารหัส AES ด้วยรหัสผ่านหน้าจอล็อกที่ขยายโดยใช้อัลกอริทึมการขยายแบบช้า (เช่น PBKDF2 หรือ scrypt) หากผู้ใช้ไม่ได้ระบุรหัสผ่านหน้าจอล็อกหรือปิดใช้รหัสผ่านสําหรับการเข้ารหัส ระบบควรใช้รหัสผ่านเริ่มต้นเพื่อรวมคีย์การเข้ารหัส หากอุปกรณ์มีที่เก็บคีย์ที่รองรับฮาร์ดแวร์ อัลกอริทึมการขยายรหัสผ่านต้องเชื่อมโยงกับที่เก็บคีย์นั้นด้วยการเข้ารหัส ห้ามส่งคีย์การเข้ารหัสออกจากอุปกรณ์ (แม้ว่าจะรวมไว้กับรหัสผ่านของผู้ใช้และ/หรือคีย์ที่เชื่อมโยงกับฮาร์ดแวร์ก็ตาม) โปรเจ็กต์โอเพนซอร์ส Android ต้นทางมีการใช้งานฟีเจอร์นี้ตามฟีเจอร์ dm-crypt ของเคอร์เนล Linux
9.10. การเปิดเครื่องที่ได้รับการยืนยัน
การเปิดเครื่องที่ได้รับการยืนยันเป็นฟีเจอร์ที่รับประกันความสมบูรณ์ของซอฟต์แวร์ในอุปกรณ์ หากการติดตั้งใช้งานอุปกรณ์รองรับฟีเจอร์นี้ อุปกรณ์จะต้องมีคุณสมบัติดังนี้
- ประกาศ Flag ฟีเจอร์แพลตฟอร์ม android.software.verified_boot
- ดำเนินการยืนยันในลำดับการบูตทุกรายการ
- เริ่มการยืนยันจากคีย์ฮาร์ดแวร์ที่แก้ไขไม่ได้ซึ่งเป็นรูทของความน่าเชื่อถือ ไปจนถึงพาร์ติชันระบบ
- ใช้การยืนยันแต่ละระยะเพื่อตรวจสอบความสมบูรณ์และความถูกต้องของไบต์ทั้งหมดในขั้นถัดไปก่อนที่จะเรียกใช้โค้ดในขั้นถัดไป
- ใช้อัลกอริทึมการยืนยันที่มีประสิทธิภาพเทียบเท่ากับคำแนะนำปัจจุบันจาก NIST สำหรับอัลกอริทึมการแฮช (SHA-256) และขนาดคีย์สาธารณะ (RSA-2048)
โครงการโอเพนซอร์ส Android ต้นทางมีการใช้งานฟีเจอร์นี้ตามที่ต้องการโดยอิงตามฟีเจอร์ dm-verity ของเคอร์เนล Linux
ตั้งแต่ Android 6.0 เป็นต้นไป การใช้งานอุปกรณ์ที่มีมาตรฐานการเข้ารหัสขั้นสูง (AES) ที่มีประสิทธิภาพการเข้ารหัสมากกว่า 50 MiB/วินาที จะต้องรองรับการบูตที่ยืนยันแล้วเพื่อรักษาความสมบูรณ์ของอุปกรณ์ หากมีการใช้งานอุปกรณ์ไปแล้วโดยไม่รองรับการบูตที่ยืนยันแล้วใน Android เวอร์ชันเก่า อุปกรณ์ดังกล่าวจะเพิ่มการรองรับฟีเจอร์นี้ด้วยการอัปเดตซอฟต์แวร์ระบบไม่ได้ จึงได้รับการยกเว้นจากข้อกำหนดนี้
9.11. คีย์และข้อมูลเข้าสู่ระบบ
ระบบ Keystore ของ Android [แหล่งข้อมูล, 133] ช่วยให้นักพัฒนาแอปจัดเก็บคีย์การเข้ารหัสในคอนเทนเนอร์ และใช้คีย์ดังกล่าวในการดำเนินการที่เข้ารหัสผ่าน KeyChain API [แหล่งข้อมูล, 134] หรือ Keystore API [แหล่งข้อมูล, 135]
การติดตั้งใช้งานอุปกรณ์ Android ทั้งหมดต้องเป็นไปตามข้อกำหนดต่อไปนี้
- ไม่ควรจํากัดจํานวนคีย์ที่สร้างได้ และต้องอนุญาตให้นําเข้าคีย์ได้มากกว่า 8,192 คีย์เป็นอย่างน้อย
- การตรวจสอบสิทธิ์หน้าจอล็อกต้องจำกัดจำนวนครั้งที่พยายาม และควรมีพารามิเตอร์การลดจำนวนครั้งแบบทวีคูณตามที่ติดตั้งใช้งานในโปรเจ็กต์โอเพนซอร์ส Android
- เมื่อการติดตั้งใช้งานอุปกรณ์รองรับหน้าจอล็อกที่ปลอดภัยและมีฮาร์ดแวร์ที่ปลอดภัย เช่น องค์ประกอบที่ปลอดภัย (SE) ที่ใช้ติดตั้งใช้งานสภาพแวดล้อมการดำเนินการที่เชื่อถือได้ (TEE) ได้ ระบบจะดำเนินการดังนี้
- ขอแนะนำอย่างยิ่งให้สำรองข้อมูลการติดตั้งใช้งานคีย์สโตร์ด้วยฮาร์ดแวร์ที่มีความปลอดภัย โปรเจ็กต์โอเพนซอร์ส Android ต้นทางมีการใช้งานเลเยอร์การแยกแยะข้อมูลฮาร์ดแวร์ (HAL) ของ Keymaster ที่ใช้เพื่อปฏิบัติตามข้อกำหนดนี้ได้
- ต้องดำเนินการตรวจสอบสิทธิ์หน้าจอล็อกในฮาร์ดแวร์ที่มีความปลอดภัยหากอุปกรณ์มีการใช้งานคีย์สโตร์ที่สำรองข้อมูลด้วยฮาร์ดแวร์ และอนุญาตให้ใช้คีย์ที่เชื่อมโยงกับการตรวจสอบสิทธิ์ได้ก็ต่อเมื่อตรวจสอบสิทธิ์สำเร็จเท่านั้น โปรเจ็กต์โอเพนซอร์ส Android ต้นทางมีเลเยอร์การแยกแยะฮาร์ดแวร์ (HAL) ของ Gatekeeper ที่ใช้เพื่อปฏิบัติตามข้อกำหนดนี้ได้ [แหล่งข้อมูล, 136]
โปรดทราบว่าแม้ว่าข้อกำหนดข้างต้นที่เกี่ยวข้องกับ TEE จะระบุว่า "แนะนำอย่างยิ่ง" แต่เราวางแผนที่จะเปลี่ยนคำจำกัดความของความเข้ากันได้สำหรับ API เวอร์ชันถัดไปเป็น "ต้องระบุ" หากมีการใช้งานอุปกรณ์ใน Android เวอร์ชันเก่าอยู่แล้วและยังไม่ได้ติดตั้งใช้งานระบบปฏิบัติการที่เชื่อถือได้ในฮาร์ดแวร์ที่มีความปลอดภัย อุปกรณ์ดังกล่าวอาจไม่เป็นไปตามข้อกำหนดผ่านการอัปเดตซอฟต์แวร์ระบบ เราจึงขอแนะนำอย่างยิ่งให้ติดตั้งใช้งาน TEE
9.12. การลบข้อมูล
อุปกรณ์ต้องจัดเตรียมกลไกให้ผู้ใช้ในการ "รีเซ็ตข้อมูลเป็นค่าเริ่มต้น" ซึ่งจะอนุญาตให้ลบข้อมูลทั้งหมดทั้งแบบตรรกะและแบบกายภาพ ยกเว้นอิมเมจระบบและข้อมูลในพาร์ติชันอื่นๆ ที่ถือว่าเป็นส่วนหนึ่งของอิมเมจระบบ การดำเนินการนี้ต้องเป็นไปตามมาตรฐานอุตสาหกรรมที่เกี่ยวข้องสำหรับการลบข้อมูล เช่น NIST SP800-88 ต้องใช้สิ่งนี้เพื่อติดตั้งใช้งาน API ของ wipeData() (เป็นส่วนหนึ่งของ Android Device Management API) ที่อธิบายไว้ในส่วนที่ 3.9 การจัดการอุปกรณ์
อุปกรณ์อาจมีการล้างข้อมูลอย่างรวดเร็วซึ่งจะลบข้อมูลเชิงตรรกะ
10. การทดสอบความเข้ากันได้ของซอฟต์แวร์
การติดตั้งใช้งานอุปกรณ์ต้องผ่านการทดสอบทั้งหมดที่อธิบายในส่วนนี้
อย่างไรก็ตาม โปรดทราบว่าไม่มีแพ็กเกจทดสอบซอฟต์แวร์ใดที่ครอบคลุมทั้งหมด ด้วยเหตุนี้ เราจึงขอแนะนำอย่างยิ่งให้ผู้ใช้งานอุปกรณ์ทำการเปลี่ยนแปลงน้อยที่สุดเท่าที่จะเป็นไปได้กับการใช้งาน Android อ้างอิงและการใช้งานที่แนะนำจากโครงการโอเพนซอร์ส Android วิธีนี้จะช่วยลดความเป็นไปได้ที่จะเกิดข้อบกพร่องซึ่งทำให้เกิดความเข้ากันไม่ได้ซึ่งต้องทํางานใหม่และอาจต้องมีการอัปเดตอุปกรณ์
10.1. ชุดเครื่องมือทดสอบความเข้ากันได้
การติดตั้งใช้งานอุปกรณ์ต้องผ่านชุดเครื่องมือทดสอบความเข้ากันได้กับอุปกรณ์ Android (CTS) [แหล่งข้อมูล, 137] ซึ่งมีอยู่ในโปรเจ็กต์โอเพนซอร์ส Android โดยใช้ซอฟต์แวร์เวอร์ชันที่พร้อมจำหน่ายในอุปกรณ์ นอกจากนี้ ผู้ติดตั้งใช้งานอุปกรณ์ควรใช้การใช้งานอ้างอิงในต้นไม้ซอร์สโค้ดแบบเปิดของ Android ให้ได้มากที่สุด และจะต้องตรวจสอบความเข้ากันได้ในกรณีที่ CTS มีความคลุมเครือ และในกรณีที่มีการใช้งานโค้ดต้นฉบับอ้างอิงบางส่วนอีกครั้ง
CTS ออกแบบมาเพื่อใช้งานบนอุปกรณ์จริง CTS อาจมีข้อบกพร่องเช่นเดียวกับซอฟต์แวร์อื่นๆ CTS จะมีเวอร์ชันเป็นอิสระจากคำจำกัดความความเข้ากันได้นี้ และอาจมีการเผยแพร่ CTS เวอร์ชันต่างๆ สำหรับ Android 6.0 การติดตั้งใช้งานอุปกรณ์ต้องผ่าน CTS เวอร์ชันล่าสุดที่มี ณ เวลาที่สร้างซอฟต์แวร์ของอุปกรณ์เสร็จสมบูรณ์
10.2. โปรแกรมตรวจสอบ CTS
การติดตั้งใช้งานอุปกรณ์ต้องดำเนินการกับกรณีที่เกี่ยวข้องทั้งหมดใน CTS Verifier อย่างถูกต้อง CTS Verifier จะรวมอยู่ในชุดทดสอบความเข้ากันได้ และมีไว้ให้ผู้ดำเนินการที่เป็นมนุษย์ใช้งานเพื่อทดสอบฟังก์ชันการทำงานที่ระบบอัตโนมัติทดสอบไม่ได้ เช่น การทำงานของกล้องและเซ็นเซอร์ที่ถูกต้อง
CTS Verifier มีการทดสอบฮาร์ดแวร์หลายประเภท รวมถึงฮาร์ดแวร์บางอย่างที่ไม่บังคับ การติดตั้งใช้งานอุปกรณ์ต้องผ่านทุกการทดสอบสำหรับฮาร์ดแวร์ที่อุปกรณ์มี เช่น หากอุปกรณ์มีเครื่องวัดความเร่ง อุปกรณ์ต้องเรียกใช้กรณีทดสอบเครื่องวัดความเร่งใน CTS Verifier อย่างถูกต้อง ระบบอาจข้ามหรือละเว้นกรณีทดสอบสำหรับฟีเจอร์ที่เอกสารนิยามความเข้ากันได้นี้ระบุว่าไม่บังคับ
อุปกรณ์และบิลด์ทุกรุ่นต้องเรียกใช้ CTS Verifier อย่างถูกต้องตามที่ระบุไว้ข้างต้น อย่างไรก็ตาม เนื่องจากบิลด์จำนวนมากมีความคล้ายคลึงกันมาก ผู้ติดตั้งใช้งานอุปกรณ์จึงไม่จำเป็นต้องเรียกใช้ CTS Verifier กับบิลด์ที่แตกต่างกันเพียงเล็กน้อย กล่าวโดยละเอียดคือ การติดตั้งใช้งานอุปกรณ์ที่แตกต่างจากการติดตั้งใช้งานที่ผ่าน CTS Verifier เฉพาะชุดภาษา การสร้างแบรนด์ ฯลฯ ที่รวมอยู่ อาจไม่ต้องทำการทดสอบ CTS Verifier
11. ซอฟต์แวร์ที่อัปเดตได้
การติดตั้งใช้งานอุปกรณ์ต้องมีกลไกในการแทนที่ซอฟต์แวร์ระบบทั้งหมด กลไกนี้ไม่จำเป็นต้องทำการอัปเกรด "แบบเรียลไทม์" กล่าวคือ คุณอาจต้องรีสตาร์ทอุปกรณ์
คุณใช้วิธีการใดก็ได้ ตราบใดที่วิธีการดังกล่าวสามารถแทนที่ซอฟต์แวร์ทั้งหมดที่ติดตั้งไว้ล่วงหน้าในอุปกรณ์ ตัวอย่างเช่น แนวทางต่อไปนี้จะเป็นไปตามข้อกำหนดนี้
- การดาวน์โหลด "ผ่านอากาศ (OTA)" ที่มีการอัปเดตแบบออฟไลน์ผ่านการรีบูต
- การอัปเดตแบบ "ใช้การเชื่อมต่ออินเทอร์เน็ตมือถือจากมือถือ" ผ่าน USB จาก PC โฮสต์
- การอัปเดต "ออฟไลน์" ผ่านการรีบูตและการอัปเดตจากไฟล์ในพื้นที่เก็บข้อมูลแบบถอดได้
อย่างไรก็ตาม หากการติดตั้งใช้งานอุปกรณ์รองรับการเชื่อมต่อข้อมูลแบบไม่จำกัด เช่น โปรไฟล์ 802.11 หรือ PAN (เครือข่ายส่วนบุคคล) ของบลูทูธ ให้ทำดังนี้
- การติดตั้งใช้งาน Android Automotive ควรรองรับการดาวน์โหลด OTA ด้วยการอัปเดตแบบออฟไลน์ผ่านการรีบูต
- การติดตั้งใช้งานอุปกรณ์อื่นๆ ทั้งหมดต้องรองรับการดาวน์โหลด OTA ด้วยการอัปเดตแบบออฟไลน์ผ่านการรีบูต
กลไกการอัปเดตที่ใช้ต้องรองรับการอัปเดตโดยไม่ล้างข้อมูลผู้ใช้ กล่าวคือ กลไกการอัปเดตต้องรักษาข้อมูลส่วนตัวของแอปพลิเคชันและข้อมูลที่แชร์ของแอปพลิเคชัน โปรดทราบว่าซอฟต์แวร์ Android เวอร์ชัน upstream มีกลไกการอัปเดตที่เป็นไปตามข้อกำหนดนี้
สำหรับการติดตั้งใช้งานอุปกรณ์ที่เปิดตัวด้วย Android 6.0 ขึ้นไป กลไกการอัปเดตควรรองรับการยืนยันว่าอิมเมจระบบเป็นไบนารีที่เหมือนกับผลลัพธ์ที่คาดไว้หลังจาก OTA การใช้งาน OTA ตามบล็อกในโปรเจ็กต์โอเพนซอร์ส Android ต้นทางซึ่งเพิ่มเข้ามาตั้งแต่ Android 5.1 เป็นไปตามข้อกำหนดนี้
หากพบข้อผิดพลาดในการใช้งานอุปกรณ์หลังจากที่เปิดตัวแล้ว แต่อยู่ภายในอายุการใช้งานที่เหมาะสมของผลิตภัณฑ์ซึ่งกำหนดโดยทีมความเข้ากันได้ของ Android เพื่อส่งผลต่อความเข้ากันได้ของแอปพลิเคชันของบุคคลที่สาม ผู้ติดตั้งใช้งานอุปกรณ์ต้องแก้ไขข้อผิดพลาดผ่านการอัปเดตซอฟต์แวร์ที่ใช้ได้ตามกลไกที่อธิบายไป
Android มีฟีเจอร์ที่อนุญาตให้แอปเจ้าของอุปกรณ์ (หากมี) ควบคุมการติดตั้งการอัปเดตระบบ ระบบย่อยการอัปเดตระบบสำหรับอุปกรณ์ที่รายงาน android.software.device_admin ต้องใช้ลักษณะการทำงานที่อธิบายไว้ในคลาส SystemUpdatePolicy [ แหล่งข้อมูล, 138] เพื่อให้การดำเนินการนี้สะดวกขึ้น
12. บันทึกการเปลี่ยนแปลงของเอกสาร
ตารางต่อไปนี้แสดงสรุปการเปลี่ยนแปลงคำจำกัดความของความเข้ากันได้ในรุ่นนี้
ส่วน | สรุปการเปลี่ยนแปลง | |
---|---|---|
หลากหลาย | แทนที่คำว่า "แนะนำ" ด้วย "แนะนำ" | |
2. ประเภทอุปกรณ์ | ข้อมูลอัปเดตสำหรับการติดตั้งใช้งาน Android Automotive | |
3.2.2. พารามิเตอร์การสร้าง | ข้อมูลเพิ่มเติมสำหรับหมายเลขซีเรียลของฮาร์ดแวร์และระดับแพตช์ด้านความปลอดภัยของบิลด์ | |
3.2.3.2. การแก้ไข Intent | เปลี่ยนชื่อส่วนจาก "การลบล้าง Intent" เป็น "การแก้ไข Intent" พร้อมข้อกำหนดใหม่ที่เกี่ยวข้องกับการลิงก์แอปเริ่มต้นที่เชื่อถือได้ | |
3.3.1. อินเทอร์เฟซแบบไบนารีของแอปพลิเคชัน | การเพิ่มเติมการรองรับ ABI ของ Android การเปลี่ยนแปลงที่เกี่ยวข้องกับชื่อไลบรารี Vulkan | |
3.4.1. ความเข้ากันได้ของ WebView | การเปลี่ยนแปลงสตริง User Agent ที่ WebView รายงาน | |
3.7. ความเข้ากันได้ของรันไทม์ | การอัปเดตตารางการจัดสรรหน่วยความจํา | |
3.8.4. ค้นหา | ข้อมูลอัปเดตเกี่ยวกับข้อกำหนดของ Assistant | |
3.8.6. ธีม | เพิ่มข้อกำหนดให้รองรับไอคอนระบบสีดําเมื่อได้รับคําขอจาก Flag SYSTEM_UI_FLAG_LIGHT_STATUS_BAR | |
3.8.8. การเปลี่ยนกิจกรรม | ผ่อนปรนข้อกำหนดด้านจำนวนชื่อในภาพรวม | |
3.8.10. การควบคุมสื่อบนหน้าจอล็อก | การควบคุมสื่อในหน้าจอล็อกเพื่อดูรายละเอียดของ 3.8.3 | |
3.9.1. การจัดเตรียมอุปกรณ์ | มีส่วนใหม่สำหรับการจัดสรรเจ้าของอุปกรณ์และการจัดสรรโปรไฟล์ที่จัดการ | |
3.9.2. การสนับสนุนโปรไฟล์ที่มีการจัดการ | ส่วนใหม่ที่มีข้อกำหนดสำหรับการรองรับฟังก์ชันการทำงานของโปรไฟล์ที่มีการจัดการในอุปกรณ์ | |
3.12.1. แอปทีวี | เพิ่มส่วนเพื่อชี้แจงข้อกำหนดของแอปทีวีสำหรับอุปกรณ์ Android Television | |
3.12.1.1. คู่มือรายการทีวีอิเล็กทรอนิกส์ | เพิ่มส่วนเพื่อชี้แจงข้อกำหนด EPG สำหรับอุปกรณ์ Android TV | |
3.12.1.2. การไปยังรายการต่างๆ | เพิ่มส่วนเพื่อชี้แจงข้อกำหนดในการนําทางของแอปทีวีสําหรับอุปกรณ์ Android Television | |
3.12.1.3. การลิงก์แอปอินพุตทีวี | เพิ่มส่วนเพื่อชี้แจงข้อกำหนดการรองรับการลิงก์แอปอินพุตทีวีสำหรับอุปกรณ์ Android Television | |
5.1 ตัวแปลงรหัสสื่อ | การอัปเดตเกี่ยวกับการรองรับรูปแบบสื่อหลักและการถอดรหัส | |
5.1.3. ตัวแปลงรหัสวิดีโอ | การเปลี่ยนแปลงและการเพิ่มที่เกี่ยวข้องกับโทรทัศน์ Android | |
5.2 การเข้ารหัสวิดีโอ | การเปลี่ยนแปลงสำหรับผู้เข้ารหัส | |
5.3 การถอดรหัสวิดีโอ | การเปลี่ยนแปลงสำหรับโปรแกรมถอดรหัส รวมถึงการรองรับความละเอียดวิดีโอแบบไดนามิก การเปลี่ยนอัตราเฟรม และอื่นๆ | |
5.4. การบันทึกเสียง | การเพิ่มที่เกี่ยวข้องกับการบันทึกเสียง | |
5.6. เวลาในการตอบสนองของเสียง | ข้อมูลอัปเดตเกี่ยวกับการรายงานการรองรับเสียงที่มีเวลาในการตอบสนองต่ำ | |
5.10. เสียงระดับมืออาชีพ | การอัปเดตทั่วไปสำหรับการรองรับเสียงระดับมืออาชีพ การอัปเดตสำหรับข้อกำหนดเฉพาะของอุปกรณ์เคลื่อนที่ (แจ็ค) โหมดโฮสต์เสียง USB และการอัปเดตอื่นๆ | |
5.9. Musical Instrument Digital Interface (MIDI) | เพิ่มส่วนใหม่เกี่ยวกับการรองรับ Musical Instrument Digital Interface (MIDI) ที่ไม่บังคับ | |
6.1 เครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ | การอัปเดตสำหรับไดรเวอร์ที่รองรับ Windows 10 | |
7.1.1.3. ความหนาแน่นของหน้าจอ | การอัปเดตความหนาแน่นของหน้าจอ เช่น ที่เกี่ยวข้องกับนาฬิกา Android | |
7.2.3. ปุ่มนำทาง | ข้อกำหนดที่อัปเดตสำหรับการติดตั้งใช้งานอุปกรณ์ที่มีการดำเนินการ Assist | |
7.3. เซ็นเซอร์ (และส่วนย่อย) | ข้อกำหนดใหม่สำหรับเซ็นเซอร์บางประเภท | |
7.3.9. เซ็นเซอร์ความแม่นยำสูง | ส่วนใหม่ที่มีข้อกำหนดสำหรับอุปกรณ์ที่รองรับเซ็นเซอร์ความละเอียดสูง | |
7.3.10. เซ็นเซอร์ลายนิ้วมือ | ส่วนใหม่เกี่ยวกับข้อกำหนดที่เกี่ยวข้องกับเซ็นเซอร์ลายนิ้วมือ | |
7.4.2. IEEE 802.11 (Wi-Fi) | การอัปเดตเกี่ยวกับการรองรับ Multicast DNS (mDNS) | |
7.4.3. บลูทูธ | การเพิ่มที่เกี่ยวข้องกับที่อยู่ส่วนตัวที่แก้ไขได้ (RPA) สำหรับบลูทูธพลังงานต่ำ (BLE) | |
7.4.4. Near Field Communication | ข้อกำหนดเพิ่มเติมสำหรับ Near Field Communication (NFC) | |
7.4.5. ความสามารถขั้นต่ำของเครือข่าย | ข้อกําหนดเพิ่มเติมสําหรับการรองรับ IPv6 | |
7.6.3. พื้นที่เก็บข้อมูลแบบ Adoptable | ส่วนใหม่สําหรับการใช้งานพื้นที่เก็บข้อมูลแบบ Adoptable | |
7.7. USB | ข้อกำหนดที่เกี่ยวข้องกับการใช้ข้อกำหนด AOA | |
7.8.3. อัลตราซาวด์ระยะใกล้ | การเพิ่มที่เกี่ยวข้องกับการบันทึก การเล่น และเสียงในย่านความถี่ใกล้อัลตราซาวด์ | ผ่อนปรนข้อกำหนด SNR ของไมโครโฟนย่านความถี่อัลตราซาวด์ |
8.3 โหมดประหยัดพลังงาน | ส่วนใหม่ที่มีข้อกำหนดเกี่ยวกับโหมดสแตนด์บายแอปและโหมด Doze | |
8.4 การบัญชีการใช้พลังงาน | ส่วนใหม่ที่มีข้อกำหนดในการติดตามการใช้พลังงานของคอมโพเนนต์ฮาร์ดแวร์และระบุแหล่งที่มาของการใช้พลังงานนั้นไปยังแอปพลิเคชันหนึ่งๆ | |
9.1. สิทธิ์ | ข้อมูลเพิ่มเติมเกี่ยวกับข้อกำหนดด้านสิทธิ์ | |
9.7 ฟีเจอร์ความปลอดภัยของเคิร์นัล | การอัปเดต SE Linux | |
9.8 ความเป็นส่วนตัว | ข้อมูลเพิ่มเติมเกี่ยวกับความยินยอมของผู้ใช้ในการเข้าถึงพื้นที่เก็บข้อมูลที่ใช้ร่วมกันผ่านพอร์ต USB | |
9.9. การเข้ารหัสดิสก์ทั้งเครื่อง | ข้อกำหนดที่เกี่ยวข้องกับการเข้ารหัสดิสก์เต็มรูปแบบ | |
9.10. การเปิดเครื่องที่ได้รับการยืนยัน | ข้อกำหนดเพิ่มเติมสำหรับการเริ่มระบบที่ยืนยันแล้ว | |
9.11. คีย์และข้อมูลเข้าสู่ระบบ | ส่วนใหม่ของข้อกำหนดที่เกี่ยวข้องกับคีย์และข้อมูลเข้าสู่ระบบ | |
9.12. การลบข้อมูล | ส่วนใหม่สำหรับ "รีเซ็ตข้อมูลเป็นค่าเริ่มต้น" | |
11. ซอฟต์แวร์ที่อัปเดตได้ | ข้อกำหนดที่เกี่ยวข้องกับนโยบายการอัปเดตระบบที่กำหนดโดยเจ้าของอุปกรณ์ |
13. ติดต่อเรา
คุณสามารถเข้าร่วมฟอรัมความเข้ากันได้กับ Android [แหล่งข้อมูล, 139] เพื่อขอคำชี้แจงหรือแจ้งปัญหาที่คุณคิดว่าเอกสารไม่ได้กล่าวถึง
14. แหล่งข้อมูล
1. ระดับข้อกําหนด IETF RFC2119: http://www.ietf.org/rfc/rfc2119.txt
2. โครงการโอเพนซอร์ส Android: http://source.android.com/
3. ฟีเจอร์ของ Android Television: http://developer.android.com/reference/android/content/pm/PackageManager.html#FEATURE_LEANBACK
4. ฟีเจอร์ของ Android Watch: http://developer.android.com/reference/android/content/res/Configuration.html#UI_MODE_TYPE_WATCH
5. Android UI_MODE_TYPE_CAR API: http://developer.android.com/reference/android/content/res/Configuration.html#UI_MODE_TYPE_CAR
6. คําจํากัดความและเอกสารประกอบของ API: http://developer.android.com/reference/packages.html
7. ข้อมูลอ้างอิงเกี่ยวกับสิทธิ์ของ Android: http://developer.android.com/reference/android/Manifest.permission.html
8. ข้อมูลอ้างอิงสำหรับ android.os.Build: http://developer.android.com/reference/android/os/Build.html
9. สตริงเวอร์ชันที่อนุญาตของ Android 6.0: http://source.android.com/docs/compatibility/6.0/versions.html
10. การตั้งค่าสำหรับนักพัฒนาแอป Android: http://developer.android.com/reference/android/provider/Settings.html
11. ผู้ให้บริการโทรศัพท์: http://developer.android.com/reference/android/provider/Telephony.html
12. การจัดการ ABI ของ Android NDK: https://developer.android.com/ndk/guides/abis.html
13. สถาปัตยกรรม SIMD ขั้นสูง: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0388f/Beijfcja.html
14. Android Extension Pack: http://developer.android.com/guide/topics/graphics/opengl.html#aep
15. คลาส android.webkit.WebView: http://developer.android.com/reference/android/webkit/WebView.html
16. ความเข้ากันได้ของ WebView: http://www.chromium.org/
17. HTML5: http://html.spec.whatwg.org/multipage/
18. ความสามารถออฟไลน์ของ HTML5: http://dev.w3.org/html5/spec/Overview.html#offline
19. แท็กวิดีโอ HTML5: http://dev.w3.org/html5/spec/Overview.html#video
20. API ตําแหน่งทางภูมิศาสตร์ HTML5/W3C: http://www.w3.org/TR/geolocation-API/
21. HTML5/W3C webstorage API: http://www.w3.org/TR/webstorage/
22. HTML5/W3C IndexedDB API: http://www.w3.org/TR/IndexedDB/
23. รูปแบบไฟล์ปฏิบัติการ Dalvik และข้อกำหนดไบต์โค้ด: มีอยู่ในซอร์สโค้ด Android ที่ dalvik/docs
24. AppWidget: http://developer.android.com/guide/practices/ui_guidelines/widget_design.html
25. การแจ้งเตือน: http://developer.android.com/guide/topics/ui/notifiers/notifications.html
26. แหล่งข้อมูลแอปพลิเคชัน: https://developer.android.com/guide/topics/resources/available-resources.html
27. คู่มือสไตล์ไอคอนแถบสถานะ: http://developer.android.com/design/style/iconography.html
28. แหล่งข้อมูลการแจ้งเตือน: https://developer.android.com/design/patterns/notifications.html
29. Search Manager: http://developer.android.com/reference/android/app/SearchManager.html
30. การช่วยเหลือด้านการดําเนินการ: http://developer.android.com/reference/android/content/Intent.html#ACTION_ASSIST
31. Android Assist API: https://developer.android.com/reference/android/app/assist/package-summary.html
32. ข้อความแจ้ง: http://developer.android.com/reference/android/widget/Toast.html
33. ธีม: http://developer.android.com/guide/topics/ui/themes.html
34. คลาส R.style: http://developer.android.com/reference/android/R.style.html
35. Material Design: http://developer.android.com/reference/android/R.style.html#Theme_Material
36. วอลเปเปอร์เคลื่อนไหว: http://developer.android.com/reference/android/service/wallpaper/WallpaperService.html
37. แหล่งข้อมูลเกี่ยวกับหน้าจอภาพรวม: http://developer.android.com/guide/components/recents.html
38. การปักหมุดหน้าจอ: https://developer.android.com/about/versions/android-5.0.html#ScreenPinning
39. วิธีการป้อนข้อมูล: http://developer.android.com/guide/topics/text/creating-input-method.html
40. การแจ้งเตือนสื่อ: https://developer.android.com/reference/android/app/Notification.MediaStyle.html
41. ความฝัน: http://developer.android.com/reference/android/service/dreams/DreamService.html
42. Settings.Secure LOCATION_MODE: http://developer.android.com/reference/android/provider/Settings.Secure.html#LOCATION_MODE
43. Unicode 6.1.0: http://www.unicode.org/versions/Unicode6.1.0/
44. การดูแลจัดการอุปกรณ์ Android: http://developer.android.com/guide/topics/admin/device-admin.html
45. ข้อมูลอ้างอิงเกี่ยวกับ DevicePolicyManager: http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html
46. แอปเจ้าของอุปกรณ์: http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#isDeviceOwnerApp(java.lang.String)
47. ขั้นตอนการเตรียมอุปกรณ์สำหรับเจ้าของอุปกรณ์ Android: http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#ACTION_PROVISION_MANAGED_DEVICE
48. การจัดสรรเจ้าของอุปกรณ์ผ่าน NFC: /devices/tech/admin/provision.html#device_owner_provisioning_via_nfc
49. แอปเจ้าของโปรไฟล์ Android:http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#isProfileOwnerApp(java.lang.String)
50. ขั้นตอนการเตรียมโปรไฟล์ที่จัดการของ Android: http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#ACTION_PROVISION_MANAGED_PROFILE
51. API บริการการช่วยเหลือพิเศษของ Android: http://developer.android.com/reference/android/accessibilityservice/AccessibilityService.html
52. Android Accessibility API: http://developer.android.com/reference/android/view/accessibility/package-summary.html
53. โปรเจ็กต์ Eyes Free: http://code.google.com/p/eyes-free
54. Text-To-Speech API: http://developer.android.com/reference/android/speech/tts/package-summary.html
55. เฟรมเวิร์กอินพุตทีวี: /devices/tv/index.html
56. ช่องแอปทีวี: http://developer.android.com/reference/android/media/tv/TvContract.Channels.html
57. อินพุตทีวีของบุคคลที่สาม: /devices/tv/index.html#third-party_input_example
58. อินพุตของทีวี: /devices/tv/index.html#tv_inputs
59. ช่อง EPG ของช่องทีวี: https://developer.android.com/reference/android/media/tv/TvContract.Programs.html
60. การลิงก์แอปอินพุตทีวี: http://developer.android.com/reference/android/media/tv/TvContract.Channels.html#COLUMN_APP_LINK_INTENT_URI
61. เอกสารประกอบของเครื่องมืออ้างอิง (สําหรับ adb, aapt, ddms, systrace): http://developer.android.com/tools/help/index.html
62. คำอธิบายไฟล์ APK ของ Android: http://developer.android.com/guide/components/fundamentals.html
63. ไฟล์ Manifest: http://developer.android.com/guide/topics/manifest/manifest-intro.html
64. รูปแบบสื่อของ Android: http://developer.android.com/guide/appendix/media-formats.html
65. Android MediaCodecList API: http://developer.android.com/reference/android/media/MediaCodecList.html
66. Android CamcorderProfile API: http://developer.android.com/reference/android/media/CamcorderProfile.html
67. โปรเจ็กต์ WebM: http://www.webmproject.org/
68. ข้อกำหนดการเขียนโค้ดฮาร์ดแวร์ RTC: http://www.webmproject.org/hardware/rtc-coding-requirements/
69. AudioEffect API: http://developer.android.com/reference/android/media/audiofx/AudioEffect.html
70. คลาส android.content.pm.PackageManager ของ Android และรายการฟีเจอร์ของฮาร์ดแวร์: http://developer.android.com/reference/android/content/pm/PackageManager.html
71. โปรโตคอลฉบับร่างของ HTTP Live Streaming: http://tools.ietf.org/html/draft-pantos-http-live-streaming-03
72. ADB: http://developer.android.com/tools/help/adb.html
73. Dumpsys: /devices/input/diagnostics.html
74. DDMS: http://developer.android.com/tools/debugging/ddms.html
75. เครื่องมือทดสอบ Monkey: http://developer.android.com/tools/help/monkey.html
76. เครื่องมือ SysyTrace: http://developer.android.com/tools/help/systrace.html
77. การตั้งค่าที่เกี่ยวข้องกับการพัฒนาแอปพลิเคชัน Android: http://developer.android.com/reference/android/provider/Settings.html#ACTION_APPLICATION_DEVELOPMENT_SETTINGS
78. การรองรับหน้าจอหลายหน้าจอ: http://developer.android.com/guide/practices/screens_support.html
79. android.util.DisplayMetrics: http://developer.android.com/reference/android/util/DisplayMetrics.html
80. RenderScript: http://developer.android.com/guide/topics/renderscript/
81. ชุดส่วนขยาย Android สำหรับ OpenGL ES: https://developer.android.com/reference/android/opengl/GLES31Ext.html
82. การเร่งด้วยฮาร์ดแวร์: http://developer.android.com/guide/topics/graphics/hardware-accel.html
83. ส่วนขยาย EGL-EGL_ANDROID_RECORDABLE: http://www.khronos.org/registry/egl/extensions/ANDROID/EGL_ANDROID_recordable.txt
84. Display Manager: http://developer.android.com/reference/android/hardware/display/DisplayManager.html
85. android.content.res.Configuration: http://developer.android.com/reference/android/content/res/Configuration.html
86. การกําหนดค่าอินพุตการสัมผัส: http://source.android.com/docs/core/interaction/input/touch-devices
87. Motion Event API: http://developer.android.com/reference/android/view/MotionEvent.html
88. Key Event API: http://developer.android.com/reference/android/view/KeyEvent.html
89. เซ็นเซอร์โอเพนซอร์สของ Android: http://source.android.com/docs/core/interaction/sensors
90. android.hardware.SensorEvent: http://developer.android.com/reference/android/hardware/SensorEvent.html
91. เหตุการณ์เซ็นเซอร์การประทับเวลา: http://developer.android.com/reference/android/hardware/SensorEvent.html#timestamp
92. เซ็นเซอร์คอมโพสิตโอเพนซอร์สของ Android: /docs/core/interaction/sensors/sensor-types#composite_sensor_type_summary
93. โหมดทริกเกอร์ต่อเนื่อง: http://developer.android.com/reference/android/hardware/Sensor.html#TYPE_ACCELEROMETER
95. Android Fingerprint API: https://developer.android.com/reference/android/hardware/fingerprint/package-summary.html
96. Android Fingerprint HAL: /devices/tech/security/authentication/fingerprint-hal.html
97. Wi-Fi Multicast API: http://developer.android.com/reference/android/net/wifi/WifiManager.MulticastLock.html
98. Wi-Fi Direct (Wi-Fi P2P): http://developer.android.com/reference/android/net/wifi/p2p/WifiP2pManager.html
99. WifiManager API: http://developer.android.com/reference/android/net/wifi/WifiManager.html
100 Bluetooth API: http://developer.android.com/reference/android/bluetooth/package-summary.html
101. Bluetooth ScanFilter API: https://developer.android.com/reference/android/bluetooth/le/ScanFilter.html
102. บาร์โค้ด NFC: http://developer.android.com/reference/android/nfc/tech/NfcBarcode.html
103. โปรโตคอล Push ของ NDEF: http://source.android.com/docs/compatibility/ndef-push-protocol.pdf
104. Android Beam: http://developer.android.com/guide/topics/connectivity/nfc/nfc.html
105. การตั้งค่าการแชร์ NFC ของ Android: http://developer.android.com/reference/android/provider/Settings.html#ACTION_NFCSHARING_SETTINGS
106 NFC Connection Handover: http://members.nfc-forum.org/specs/spec_list/#conn_handover
107. การจับคู่ที่ปลอดภัยแบบง่ายของบลูทูธโดยใช้ NFC: http://members.nfc-forum.org/apps/group_public/download.php/18688/NFCForum-AD-BTSSP_1_1.pdf
108 โปรแกรมจำลองการ์ดแบบโฮสต์: http://developer.android.com/guide/topics/connectivity/nfc/hce.html
109. เครื่องมือจัดการเนื้อหา: http://developer.android.com/reference/android/content/ContentResolver.html
110. Camera orientation API: http://developer.android.com/reference/android/hardware/Camera.html#setDisplayOrientation(int)
111. กล้อง: http://developer.android.com/reference/android/hardware/Camera.html
112. กล้อง: http://developer.android.com/reference/android/hardware/Camera.Parameters.html
113. ระดับฮาร์ดแวร์ของกล้อง: https://developer.android.com/reference/android/hardware/camera2/CameraCharacteristics.html#INFO_SUPPORTED_HARDWARE_LEVEL
114. การรองรับเวอร์ชันกล้อง: http://source.android.com/docs/core/camera/versioning
115. DownloadManager ของ Android: http://developer.android.com/reference/android/app/DownloadManager.html
116. Android File Transfer: http://www.android.com/filetransfer
117. พื้นที่เก็บข้อมูลแบบ Adoptable: http://source.android.com/docs/core/storage/adoptable
118. อุปกรณ์เสริมแบบเปิดของ Android: http://developer.android.com/guide/topics/connectivity/usb/accessory.html
119. เสียง USB ของ Android: http://developer.android.com/reference/android/hardware/usb/UsbConstants.html#USB_CLASS_AUDIO
120 ข้อกำหนดการชาร์จแบตเตอรี่ USB ฉบับแก้ไขครั้งที่ 1.2: http://www.usb.org/developers/docs/devclass_docs/BCv1.2_070312.zip
121. USB Host API: http://developer.android.com/guide/topics/connectivity/usb/host.html
122. ชุดหูฟังแบบมีสาย: http://source.android.com/docs/core/interaction/accessories/headset/plug-headset-spec
123 คอมโพเนนต์โปรไฟล์พลังงาน: http://source.android.com/docs/core/power/values
124. Batterystats: https://developer.android.com/tools/dumpsys#battery
125 สรุปการใช้พลังงาน: http://developer.android.com/reference/android/content/Intent.html#ACTION_POWER_USAGE_SUMMARY
126. ข้อมูลอ้างอิงเกี่ยวกับความปลอดภัยและสิทธิ์ของ Android: http://developer.android.com/guide/topics/security/permissions.html
127. ข้อมูลอ้างอิงเกี่ยวกับ UserManager: http://developer.android.com/reference/android/os/UserManager.html
128 ข้อมูลอ้างอิงเกี่ยวกับที่จัดเก็บข้อมูลภายนอก: http://source.android.com/docs/core/storage/traditional
129. External Storage API: http://developer.android.com/reference/android/os/Environment.html
130. รหัสสั้น SMS: http://en.wikipedia.org/wiki/Short_code
131. การรายงานหน้าจอล็อกที่ปลอดภัย: http://developer.android.com/reference/android/app/KeyguardManager.html#isDeviceSecure()
132. การเข้ารหัสแบบโอเพนซอร์สของ Android: http://source.android.com/docs/security/features/encryption
133. ระบบ Android Keystore: https://developer.android.com/training/articles/keystore.html
134. KeyChain API: https://developer.android.com/reference/android/security/KeyChain.html
135. Keystore API: https://developer.android.com/reference/java/security/KeyStore.html
136. HAL ของ Gatekeeper: http://source.android.com/docs/security/features/authentication/gatekeeper
137. ภาพรวมโปรแกรมความเข้ากันได้กับอุปกรณ์ Android: http://source.android.com/docs/compatibility
138. คลาส SystemUpdatePolicy: http://developer.android.com/reference/android/app/admin/SystemUpdatePolicy.html
139. ฟอรัมความเข้ากันได้กับ Android: https://groups.google.com/forum/#!forum/android-compatibility
140 การจัดการ App Link: https://developer.android.com/training/app-links/index.html
141. Google Digital Asset Links: https://developers.google.com/digital-asset-links
แหล่งข้อมูลเหล่านี้จำนวนมากมาจาก Android SDK โดยตรงหรือโดยอ้อม และจะมีฟังก์ชันการทำงานเหมือนกับข้อมูลในเอกสารประกอบของ SDK นั้น ในกรณีที่นิยามความเข้ากันได้นี้หรือชุดเครื่องมือทดสอบความเข้ากันได้ขัดแย้งกับเอกสารประกอบ SDK ระบบจะถือว่าเอกสารประกอบ SDK ถูกต้อง รายละเอียดทางเทคนิคที่ระบุไว้ในข้อมูลอ้างอิงข้างต้นจะถือว่าเป็นส่วนหนึ่งของคำจำกัดความความเข้ากันได้นี้