คำถามที่พบบ่อยเกี่ยวกับ CTS

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

คำถามทั่วไป

ส่วนนี้จะแสดงคำถามที่พบบ่อยทั่วไปเกี่ยวกับ CTS

CTS ทดสอบอะไรบ้าง

CTS จะทดสอบว่า API ที่รองรับทั้งหมดของ Android ที่มีการพิมพ์อย่างเข้มงวด มีอยู่และทำงานอย่างถูกต้อง CTS ยังทดสอบลักษณะการทำงานอื่นๆ ของระบบที่ไม่ใช่ API เช่น วงจรแอปและประสิทธิภาพด้วย

CTS ได้รับอนุญาตให้ใช้งานอย่างไร

CTS ได้รับอนุญาตภายใต้สัญญาอนุญาตให้ใช้ซอฟต์แวร์ Apache 2.0 เดียวกันกับที่ Android ส่วนใหญ่ใช้

CTS ยืนยันตัวแปลงรหัสหรือไม่

ได้ CTS จะยืนยันตัวแปลงรหัสที่จำเป็นทั้งหมด

คำถามเฉพาะการทดสอบ

ส่วนนี้มีคำถามที่พบบ่อยซึ่งจะช่วยให้การทดสอบ CTS มีประสิทธิภาพมากขึ้น

CTS Sharding และ TF Sharding แตกต่างกันอย่างไร

การแบ่งพาร์ติชัน CTS และการแบ่งพาร์ติชัน TF เป็นแผนการทดสอบที่แตกต่างกันโดยสิ้นเชิงซึ่งขับเคลื่อนโดย ฐานของโค้ดโครงสร้างพื้นฐานการทดสอบที่แตกต่างกัน แม้ว่าคำสั่งเรียกใช้จะเหมือนกันในเวอร์ชันต่างๆ แต่ผลลัพธ์การแบ่งพาร์ติชันจะทำงานแตกต่างกัน การแบ่ง CTS จะกำหนดกรณีทดสอบให้กับอุปกรณ์ภายใต้การทดสอบ (DUT) แบบคงที่ ดังนี้

การแบ่งพาร์ติชัน TF จะกำหนดกรณีทดสอบแบบไดนามิกให้กับ DUT ที่พร้อมใช้งานดังนี้

อุปกรณ์ที่รองรับ ABI หลายรายการควรมีลักษณะอย่างไร

อุปกรณ์ต้องผ่านการทดสอบ CTS และ CTS Verifier ทั้งหมดสำหรับโหมด ABI แต่ละโหมดที่อ้างว่ารองรับ ดังนั้นจึงจำเป็นต้องเรียกใช้แอปสำหรับ ABI ที่เฉพาะเจาะจง หลักเกณฑ์สำหรับ ABI หลายรายการมีดังนี้

  • สำหรับ CTS และ CTS Verifier จะมีรุ่น ARM และ x86 สำหรับแต่ละสถาปัตยกรรม แต่ละรายการรองรับโหมด 32 บิตหรือ 64 บิต
  • สำหรับการทดสอบ CTS หากอุปกรณ์รองรับทั้ง ARM และ x86 อุปกรณ์จะต้องเรียกใช้ และผ่านการทดสอบ CTS ทั้ง ARM และ x86 ตามลำดับ

ดู CDD 3.3.1 อินเทอร์เฟซแบบไบนารีของแอปพลิเคชัน สำหรับข้อกำหนด CDD ใน ABI

การทดสอบเฉพาะใน ABI หลัก (เช่น 64 บิต) เพียงพอที่จะลดเวลาในการดำเนินการทดสอบหรือไม่

ไม่ แอป Android จะทำงานในรันไทม์ 32 บิตหรือ 64 บิตของตัวเอง โค้ดเครื่องจริง เส้นทางโค้ด และสถานะจะแตกต่างกัน ระหว่าง 32 กับ 64 หากข้ามโหมดใดโหมดหนึ่ง คุณจะครอบคลุม ABI ของอุปกรณ์เพียง 50%

เหตุใดจึงมีกรณีทดสอบจำนวนมากที่รายงานว่า "ไม่ได้ดำเนินการ"

คุณควรตรวจสอบหมายเลขโมดูลที่ทำเสร็จแล้วแทนหมายเลขไม่ได้ดำเนินการ

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

โมดูลที่ทำงานจนเสร็จจะรายงาน Module Not Done ในการเรียกใช้ล่าสุด (done="false") ในรายงานระหว่างการดำเนินการต่อไปนี้

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

  • ลองอีกครั้ง (ใช้ตัวเลือก -r/--retry) พร้อมตัวเลือกการกรองเพิ่มเติม เช่น

    • --include-filter
    • --exclude-filter
    • -t/--test (ยังไม่รองรับตัวเลือกในการลองอีกครั้ง)
    • --retry-type failed
    • --subplan

หากต้องการรับสถานะ Module Done (done="true") สำหรับโมดูลเหล่านี้ ให้ลองเรียกใช้คำสั่งต่อไปนี้อีกครั้งสำหรับการเรียกใช้ล่าสุด

run retry --retry <session_id> for Android 9 and later versions
run cts --retry <session_id> for Android 8.1 and previous versions

โมดูลที่ดำเนินการโดยไม่มีปัญหาใดๆ ที่กล่าวถึงก่อนหน้านี้ (แม้ว่าจะมี การทดสอบเหลืออยู่ 0 รายการ) จะมีการทำเครื่องหมายเป็นโมดูลเสร็จสมบูรณ์ในรายงานใหม่

ข้อยกเว้น

  • CtsNNAPITestCases มีปัญหาที่ทราบเนื่องจากข้อจำกัดของอาร์กิวเมนต์ใน Linux/OS คุณเรียกใช้โมดูลอีกครั้งแยกกันได้โดยตรงผ่าน run cts -m CtsNNAPITestCases

ฉันจะหลีกเลี่ยงไม่ให้การเตรียมสอบล้มเหลวเนื่องจากไฟร์วอลล์ขององค์กรได้อย่างไร

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

export JAVA_TOOL_OPTIONS='-Djava.net.useSystemProxies=true'

ฉันต้องใช้ซิมการ์ดสำหรับ CTS สำหรับ Secure Element ไหม

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

  • หากอุปกรณ์ไม่จำเป็นต้องรองรับแอป Android ที่เข้าถึง องค์ประกอบที่ปลอดภัย ไม่ว่าจะอยู่ใน UICC (เช่น ซิมการ์ด) ที่จัดจำหน่ายโดยผู้ให้บริการเครือข่ายมือถือ (ผู้ให้บริการ) หรือฝังอยู่ในอุปกรณ์ คุณสามารถกำหนดค่าไฟล์ Manifest ของ HIDL เพื่อไม่ให้มีองค์ประกอบ android.hardware.secure_element HAL ได้ ในกรณีนี้ API android.se.omapi.SEService.getReaders() จะรายงานรายการที่ว่างเปล่า และการทดสอบ CTS จะผ่านโดยอัตโนมัติ และรายงานว่าผ่านสำหรับ CTS
  • หากอุปกรณ์ต้องรองรับการเข้าถึงแอป Android ใน องค์ประกอบที่ปลอดภัย ไม่ว่าจะอยู่ใน UICC (เช่น ซิมการ์ด) ที่จัดจำหน่ายโดยผู้ให้บริการเครือข่ายมือถือ (ผู้ให้บริการ) หรือ ฝังอยู่ในอุปกรณ์ คุณต้องติดตั้งองค์ประกอบที่ปลอดภัยอย่างเหมาะสม และทดสอบภายใน การทดสอบ CTS สำหรับองค์ประกอบที่ปลอดภัย อธิบายวิธีเตรียมพร้อมเพื่อเรียกใช้การทดสอบ CTS ที่ช่วยให้มั่นใจว่า แพ็กเกจ API android.se.omapi ที่เพิ่มใน Android 9 ทำงานได้ นอกจากนี้ เราขอแนะนำให้คุณทำการทดสอบเพิ่มเติมด้วยตนเองเนื่องจากความครอบคลุมของการทดสอบ CTS มีน้อย

ฉันจะขอรับซิมการ์ดสำหรับ CTS สำหรับ Secure Element ได้จากที่ใด

คุณสามารถติดต่อผู้จำหน่ายซิมที่ต้องการได้

เหตุใดจึงมีซิมสีส้มบนหน้าจอล็อกระหว่างการดำเนินการ CTS ด้วยการแยกส่วนโทเค็น

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

การทดสอบจะทำงานเมื่อปิดใช้ค่าสถานะฟีเจอร์ในอุปกรณ์

สำหรับแฟล็กทั้งหมดในบิลด์ที่เผยแพร่ คำอธิบายประกอบ @RequiresFlagsEnabledหรือ@RequiresFlagsDisabledจะใช้ค่า ของแฟล็กจากการกำหนดค่าการเผยแพร่ไบนารี CTS ไม่ใช่จากการกำหนดค่าการเผยแพร่ อุปกรณ์ การปิดใช้ฟีเจอร์ค่าสถานะในอุปกรณ์ไม่ได้เป็นการปิดใช้การทดสอบ เนื่องจากชุดการทดสอบ CTS ที่เรียกใช้สำหรับรุ่นที่กำหนดจะได้รับการแก้ไขเป็นการกำหนดค่าที่เผยแพร่ในแพลตฟอร์ม AOSP