ชุดทดสอบ
หากต้องการทดสอบเพื่อเป็นส่วนหนึ่งของ VTS จะต้องมีการตั้งค่าต่อไปนี้ใน Android.bp
test_suites: ["vts"],
นอกจากนี้ การเพิ่มการทดสอบลงในชุด general-tests
ทำให้สามารถเป็นส่วนหนึ่งของชุดการทดสอบ Mapping ที่ใช้ในการตรวจสอบก่อนส่งได้
ทดสอบการกำหนดค่า
ในกรณีส่วนใหญ่ การกำหนดค่าการทดสอบซึ่งเป็นไฟล์ XML ที่ใช้โดย Trade Federation เพื่อรันการทดสอบ VTS จะถูกสร้างขึ้นโดยอัตโนมัติในระหว่างการสร้าง อย่างไรก็ตาม คุณสามารถปรับแต่งการกำหนดค่าการทดสอบได้
สร้างไฟล์การกำหนดค่าการทดสอบที่กำหนดเอง
การสร้างไฟล์ XML การทดสอบใหม่ตั้งแต่ต้นอาจมีความซับซ้อน เนื่องจากจะต้องไม่เข้าใจวิธีการทำงานของชุดทดสอบ รวมถึงความแตกต่างระหว่างผู้ทดสอบแต่ละคน ไฟล์กำหนดค่าการทดสอบที่สร้างขึ้นอัตโนมัติได้รับการออกแบบมาเพื่อทำให้กระบวนการนี้ง่ายขึ้น
หากคุณต้องปรับแต่งไฟล์ XML ทดสอบ คุณสามารถใช้ไฟล์ที่สร้างอัตโนมัติเป็นจุดเริ่มต้นได้
หากต้องการค้นหาไฟล์กำหนดค่าการทดสอบที่สร้างขึ้นอัตโนมัติ ให้เรียกใช้คำสั่ง make
เพื่อสร้างการกำหนดค่าดังที่แสดงด้านล่าง
$ m VtsHalUsbV1_1TargetTest
ในไดเร็กทอรี build out ของคุณ คุณสามารถค้นหาไฟล์กำหนดค่าตามชื่อโมดูลได้ ดังที่แสดงด้านล่าง
$ find out/ -name VtsHalUsbV1_1TargetTest.config
ไฟล์สามารถมีได้หลายสำเนาและคุณสามารถใช้สำเนาใดก็ได้ คัดลอกไฟล์ .config
ไปยังไดเร็กทอรีที่มีไฟล์ Android.bp
หากมีโมดูลทดสอบเพียงโมดูลเดียวในไฟล์ Android.bp
คุณสามารถเปลี่ยนชื่อไฟล์ XML เป็น AndroidTest.xml
และระบบบิลด์จะใช้โมดูลนั้นเป็นไฟล์กำหนดค่าของโมดูลทดสอบโดยอัตโนมัติ มิฉะนั้น ให้เพิ่มแอตทริบิวต์ test_config
ให้กับโมดูล ดังที่แสดงในตัวอย่างด้านล่าง
test_config: "VtsHalUsbV1_1TargetTest.xml",
ตอนนี้คุณมีไฟล์การกำหนดค่าทดสอบเพื่อใช้งานและใช้งานการปรับแต่ง
บังคับให้การทดสอบรันด้วย adb root
การทดสอบ VTS ส่วนใหญ่ต้องการสิทธิ์รูทจึงจะรันได้ หากไฟล์การกำหนดค่าการทดสอบถูกสร้างขึ้นโดยอัตโนมัติ คุณสามารถเพิ่มแอตทริบิวต์ต่อไปนี้ใน Android.bp
ได้
require_root: true,
หากมีการปรับแต่งไฟล์การกำหนดค่าการทดสอบ ให้เพิ่มสิ่งต่อไปนี้ในไฟล์ XML ทดสอบ
<target_preparer class="com.android.tradefed.targetprep.RootTargetPreparer"/>
หยุดกรอบงานระหว่างการทดสอบ
การทดสอบ VTS จำนวนมากไม่จำเป็นต้องใช้เฟรมเวิร์ก Android ในการรัน และการรันการทดสอบโดยที่เฟรมเวิร์กหยุดทำงานจะทำให้การทดสอบทำงานได้อย่างเสถียรโดยไม่ได้รับผลกระทบจากช่องโหว่ของอุปกรณ์ หากไฟล์การกำหนดค่าการทดสอบถูกสร้างขึ้นโดยอัตโนมัติ คุณสามารถเพิ่มแอตทริบิวต์ต่อไปนี้ใน Android.bp
ได้
disable_framework: true,
หากมีการปรับแต่งไฟล์การกำหนดค่าการทดสอบ ให้เพิ่มสิ่งต่อไปนี้ในไฟล์ XML ทดสอบ
<target_preparer class="com.android.tradefed.targetprep.StopServicesSetup"/>
เพิ่มข้อโต้แย้งการทดสอบเพิ่มเติม
การทดสอบ gtest บางรายการอาจต้องใช้เวลามากขึ้นในการรัน ในกรณีเช่นนี้ คุณสามารถเพิ่มตัวเลือกตัวดำเนินการทดสอบในไฟล์ XML ได้
ตัวอย่างเช่น การตั้งค่า native-test-timeout
ในรายการต่อไปนี้ทำให้การทดสอบรันโดยหมดเวลา 3 นาที แทนที่จะเป็นค่าเริ่มต้นที่ 1 นาที
<test class="com.android.tradefed.testtype.GTest" >
<option name="native-test-device-path" value="/data/local/tmp" />
<option name="module-name" value="VtsHalNfcV1_0TargetTest" />
<option name="native-test-timeout" value="180000"/>
</test>
ต้องการระดับ API ขั้นต่ำ
การทดสอบ VTS บางอย่างสามารถทำงานได้บนอุปกรณ์ที่มีระดับ API ขั้นต่ำเท่านั้น หากไฟล์การกำหนดค่าการทดสอบถูกสร้างขึ้นโดยอัตโนมัติ คุณสามารถเพิ่มแอตทริบิวต์ต่อไปนี้ใน Android.bp
ได้
test_min_api_level: 29,
หากไฟล์การกำหนดค่าการทดสอบได้รับการปรับแต่ง ให้เพิ่มคำสั่งต่อไปนี้ในไฟล์ XML การทดสอบ
<object type="module_controller" class="com.android.tradefed.testtype.suite.module.MinApiLevelModuleController">
<option name="min-api-level" value="29" />
</object>
Android 12 กำหนดคุณสมบัติ ro.board.first_api_level
และ ro.board.api_level
เพื่อแสดงระดับ API ของอิมเมจของผู้ให้บริการบนอุปกรณ์เหล่านี้ เมื่อรวมคุณสมบัติเหล่านี้เข้ากับ ro.product.first_api_level
ชุดการทดสอบจะเลือกกรณีการทดสอบที่เหมาะสมสำหรับอุปกรณ์
Android 13 กำหนด ro.vendor.api_level
ที่ตั้งค่าโดยอัตโนมัติโดยการคำนวณระดับ API ของผู้ขายที่จำเป็นโดยใช้คุณสมบัติ ro.product.first_api_level
, ro.board.first_api_level
และ ro.board.api_level
ro.board.first_api_level
คุณสมบัติ ro.board.first_api_level
คือระดับ API เมื่ออิมเมจของผู้จำหน่ายสำหรับ SoC ได้รับการเผยแพร่เป็นครั้งแรกด้วยคุณสมบัตินี้ สิ่งนี้ไม่ได้ขึ้นอยู่กับระดับ API การเปิดใช้งานของอุปกรณ์ แต่ขึ้นอยู่กับระดับ API แรกของ SoC ที่กำหนดค่านี้เท่านั้น ค่านี้จะถาวรตลอดอายุการใช้งานของ SoC
หากต้องการตั้งค่า ro.board.first_api_level
ผู้ผลิตอุปกรณ์สามารถกำหนด BOARD_SHIPPING_API_LEVEL
ในไฟล์ device.mk
ของตนได้ ดังที่แสดงในตัวอย่างต่อไปนี้:
# BOARD_SHIPPING_API_LEVEL sets ro.product.first_api_level to indicate
# the first api level that the device has been commercially launched on.
BOARD_SHIPPING_API_LEVEL := 23
โดยจะกำหนดคุณสมบัติ ro.board.first_api_level ให้กับ vendor/build.prop
บนอุปกรณ์โดยอัตโนมัติ คุณสมบัติถูกกำหนดโดยกระบวนการ init
ของผู้ขาย
ro.board.api_level
คุณสมบัติ ro.board.api_level
คือระดับ API ปัจจุบันของอิมเมจของผู้จำหน่ายสำหรับ SoC เมื่อมีการอัปเดตระดับ API ของอิมเมจของผู้จำหน่ายที่มี ro.board.first_api_level
อุปกรณ์ที่ใช้ SoC จะต้องกำหนดคุณสมบัติ ro.board.api_level
ด้วยระดับ API ปัจจุบันของอิมเมจของผู้จำหน่าย แทนที่จะอัปเดต ro.board.first_api_level
. หากไม่ได้ตั้งค่าคุณสมบัตินี้ ro.board.first_api_level
จะถูกใช้เป็นค่าเริ่มต้น
หากต้องการตั้งค่า ro.board.api_level
ให้กำหนด BOARD_API_LEVEL
ในไฟล์ device.mk
ด้วยค่าที่ต้องการ
ro.vendor.api_level
คุณสมบัติ ro.vendor.api_level
เปิดตัวใน Android 13 เพื่อแสดงระดับ API ที่อิมเมจของผู้ให้บริการจำเป็นต้องรองรับ ซึ่งจะถูกตั้งค่าเป็น ro.board.api_level
ขั้นต่ำโดยอัตโนมัติ (หรือ ro.board.first_api_level
หากไม่ได้กำหนด ro.board.api_level
) และ ro.product.first_api_level
การทดสอบการใช้งานของผู้จำหน่ายที่จำเป็นต้องมีการอัพเกรดอิมเมจของผู้จำหน่ายอาจไม่รวมอยู่ในข้อกำหนดของผู้จำหน่ายสำหรับ SoC โดยอ้างอิงถึงคุณสมบัตินี้
กระบวนการแบ่งส่วนโดยใช้ VTS
สำหรับ Android เวอร์ชัน 10 ขึ้นไป คุณสามารถดำเนินการกระบวนการชาร์ดดิ้งบนอุปกรณ์หลายเครื่องได้ในขณะที่ทดสอบกับทั้งแผน VTS และ CTS-on-GSI โดยทำตามคำแนะนำด้านล่าง
run vts --shard-count <number of devices> -s <device serial> ...
คำสั่งนี้จะแบ่งแผน VTS ออกเป็นชาร์ดและรันบนอุปกรณ์หลายเครื่อง
run cts-on-gsi --shard-count <number of devices> -s <device serial> -s ...
คำสั่งนี้จะแบ่งแผน CTS-on-GSI ออกเป็นชาร์ดและรันบนอุปกรณ์หลายเครื่อง
,ชุดทดสอบ
หากต้องการทดสอบเพื่อเป็นส่วนหนึ่งของ VTS จะต้องมีการตั้งค่าต่อไปนี้ใน Android.bp
test_suites: ["vts"],
นอกจากนี้ การเพิ่มการทดสอบลงในชุด general-tests
ทำให้สามารถเป็นส่วนหนึ่งของชุดการทดสอบ Mapping ที่ใช้ในการตรวจสอบก่อนส่งได้
ทดสอบการกำหนดค่า
ในกรณีส่วนใหญ่ การกำหนดค่าการทดสอบซึ่งเป็นไฟล์ XML ที่ใช้โดย Trade Federation เพื่อรันการทดสอบ VTS จะถูกสร้างขึ้นโดยอัตโนมัติในระหว่างการสร้าง อย่างไรก็ตาม คุณสามารถปรับแต่งการกำหนดค่าการทดสอบได้
สร้างไฟล์การกำหนดค่าการทดสอบที่กำหนดเอง
การสร้างไฟล์ XML การทดสอบใหม่ตั้งแต่ต้นอาจมีความซับซ้อน เนื่องจากจะต้องไม่เข้าใจวิธีการทำงานของชุดทดสอบ รวมถึงความแตกต่างระหว่างผู้ทดสอบแต่ละคน ไฟล์กำหนดค่าการทดสอบที่สร้างขึ้นอัตโนมัติได้รับการออกแบบมาเพื่อทำให้กระบวนการนี้ง่ายขึ้น
หากคุณต้องปรับแต่งไฟล์ XML ทดสอบ คุณสามารถใช้ไฟล์ที่สร้างอัตโนมัติเป็นจุดเริ่มต้นได้
หากต้องการค้นหาไฟล์กำหนดค่าการทดสอบที่สร้างขึ้นอัตโนมัติ ให้เรียกใช้คำสั่ง make
เพื่อสร้างการกำหนดค่าดังที่แสดงด้านล่าง
$ m VtsHalUsbV1_1TargetTest
ในไดเร็กทอรี build out ของคุณ คุณสามารถค้นหาไฟล์กำหนดค่าตามชื่อโมดูลได้ ดังที่แสดงด้านล่าง
$ find out/ -name VtsHalUsbV1_1TargetTest.config
ไฟล์สามารถมีได้หลายสำเนาและคุณสามารถใช้สำเนาใดก็ได้ คัดลอกไฟล์ .config
ไปยังไดเร็กทอรีที่มีไฟล์ Android.bp
หากมีโมดูลทดสอบเพียงโมดูลเดียวในไฟล์ Android.bp
คุณสามารถเปลี่ยนชื่อไฟล์ XML เป็น AndroidTest.xml
และระบบบิลด์จะใช้โมดูลนั้นเป็นไฟล์กำหนดค่าของโมดูลทดสอบโดยอัตโนมัติ มิฉะนั้น ให้เพิ่มแอตทริบิวต์ test_config
ให้กับโมดูล ดังที่แสดงในตัวอย่างด้านล่าง
test_config: "VtsHalUsbV1_1TargetTest.xml",
ตอนนี้คุณมีไฟล์การกำหนดค่าทดสอบเพื่อใช้งานและใช้งานการปรับแต่ง
บังคับให้การทดสอบรันด้วย adb root
การทดสอบ VTS ส่วนใหญ่ต้องการสิทธิ์รูทจึงจะรันได้ หากไฟล์การกำหนดค่าการทดสอบถูกสร้างขึ้นโดยอัตโนมัติ คุณสามารถเพิ่มแอตทริบิวต์ต่อไปนี้ใน Android.bp
ได้
require_root: true,
หากมีการปรับแต่งไฟล์การกำหนดค่าการทดสอบ ให้เพิ่มสิ่งต่อไปนี้ในไฟล์ XML ทดสอบ
<target_preparer class="com.android.tradefed.targetprep.RootTargetPreparer"/>
หยุดกรอบงานระหว่างการทดสอบ
การทดสอบ VTS จำนวนมากไม่จำเป็นต้องใช้เฟรมเวิร์ก Android ในการรัน และการรันการทดสอบโดยที่เฟรมเวิร์กหยุดทำงานจะทำให้การทดสอบทำงานได้อย่างเสถียรโดยไม่ได้รับผลกระทบจากช่องโหว่ของอุปกรณ์ หากไฟล์การกำหนดค่าการทดสอบถูกสร้างขึ้นโดยอัตโนมัติ คุณสามารถเพิ่มแอตทริบิวต์ต่อไปนี้ใน Android.bp
ได้
disable_framework: true,
หากมีการปรับแต่งไฟล์การกำหนดค่าการทดสอบ ให้เพิ่มสิ่งต่อไปนี้ในไฟล์ XML ทดสอบ
<target_preparer class="com.android.tradefed.targetprep.StopServicesSetup"/>
เพิ่มข้อโต้แย้งการทดสอบเพิ่มเติม
การทดสอบ gtest บางรายการอาจต้องใช้เวลามากขึ้นในการรัน ในกรณีเช่นนี้ คุณสามารถเพิ่มตัวเลือกตัวดำเนินการทดสอบในไฟล์ XML ได้
ตัวอย่างเช่น การตั้งค่า native-test-timeout
ในรายการต่อไปนี้ทำให้การทดสอบรันโดยหมดเวลา 3 นาที แทนที่จะเป็นค่าเริ่มต้นที่ 1 นาที
<test class="com.android.tradefed.testtype.GTest" >
<option name="native-test-device-path" value="/data/local/tmp" />
<option name="module-name" value="VtsHalNfcV1_0TargetTest" />
<option name="native-test-timeout" value="180000"/>
</test>
ต้องการระดับ API ขั้นต่ำ
การทดสอบ VTS บางอย่างสามารถทำงานได้บนอุปกรณ์ที่มีระดับ API ขั้นต่ำเท่านั้น หากไฟล์การกำหนดค่าการทดสอบถูกสร้างขึ้นโดยอัตโนมัติ คุณสามารถเพิ่มแอตทริบิวต์ต่อไปนี้ใน Android.bp
ได้
test_min_api_level: 29,
หากไฟล์การกำหนดค่าการทดสอบได้รับการปรับแต่ง ให้เพิ่มคำสั่งต่อไปนี้ในไฟล์ XML การทดสอบ
<object type="module_controller" class="com.android.tradefed.testtype.suite.module.MinApiLevelModuleController">
<option name="min-api-level" value="29" />
</object>
Android 12 กำหนดคุณสมบัติ ro.board.first_api_level
และ ro.board.api_level
เพื่อแสดงระดับ API ของอิมเมจของผู้ให้บริการบนอุปกรณ์เหล่านี้ เมื่อรวมคุณสมบัติเหล่านี้เข้ากับ ro.product.first_api_level
ชุดการทดสอบจะเลือกกรณีการทดสอบที่เหมาะสมสำหรับอุปกรณ์
Android 13 กำหนด ro.vendor.api_level
ที่ตั้งค่าโดยอัตโนมัติโดยการคำนวณระดับ API ของผู้ขายที่จำเป็นโดยใช้คุณสมบัติ ro.product.first_api_level
, ro.board.first_api_level
และ ro.board.api_level
ro.board.first_api_level
คุณสมบัติ ro.board.first_api_level
คือระดับ API เมื่ออิมเมจของผู้จำหน่ายสำหรับ SoC ได้รับการเผยแพร่เป็นครั้งแรกด้วยคุณสมบัตินี้ สิ่งนี้ไม่ได้ขึ้นอยู่กับระดับ API การเปิดใช้งานของอุปกรณ์ แต่ขึ้นอยู่กับระดับ API แรกของ SoC ที่กำหนดค่านี้เท่านั้น ค่านี้จะถาวรตลอดอายุการใช้งานของ SoC
หากต้องการตั้งค่า ro.board.first_api_level
ผู้ผลิตอุปกรณ์สามารถกำหนด BOARD_SHIPPING_API_LEVEL
ในไฟล์ device.mk
ของตนได้ ดังที่แสดงในตัวอย่างต่อไปนี้:
# BOARD_SHIPPING_API_LEVEL sets ro.product.first_api_level to indicate
# the first api level that the device has been commercially launched on.
BOARD_SHIPPING_API_LEVEL := 23
โดยจะกำหนดคุณสมบัติ ro.board.first_api_level ให้กับ vendor/build.prop
บนอุปกรณ์โดยอัตโนมัติ คุณสมบัติถูกกำหนดโดยกระบวนการ init
ของผู้ขาย
ro.board.api_level
คุณสมบัติ ro.board.api_level
คือระดับ API ปัจจุบันของอิมเมจของผู้จำหน่ายสำหรับ SoC เมื่อมีการอัปเดตระดับ API ของอิมเมจของผู้จำหน่ายที่มี ro.board.first_api_level
อุปกรณ์ที่ใช้ SoC จะต้องกำหนดคุณสมบัติ ro.board.api_level
ด้วยระดับ API ปัจจุบันของอิมเมจของผู้จำหน่าย แทนที่จะอัปเดต ro.board.first_api_level
. หากไม่ได้ตั้งค่าคุณสมบัตินี้ ro.board.first_api_level
จะถูกใช้เป็นค่าเริ่มต้น
หากต้องการตั้ง ro.board.api_level
ให้กำหนด BOARD_API_LEVEL
ในไฟล์ device.mk
ด้วยค่าที่ต้องการ
ro.vendor.api_level
คุณสมบัติ ro.vendor.api_level
เปิดตัวใน Android 13 เพื่อแสดงระดับ API ที่อิมเมจของผู้ให้บริการจำเป็นต้องรองรับ ซึ่งจะถูกตั้งค่าเป็น ro.board.api_level
ขั้นต่ำโดยอัตโนมัติ (หรือ ro.board.first_api_level
หากไม่ได้กำหนด ro.board.api_level
) และ ro.product.first_api_level
การทดสอบการใช้งานของผู้จำหน่ายที่จำเป็นต้องมีการอัพเกรดอิมเมจของผู้จำหน่ายอาจไม่รวมอยู่ในข้อกำหนดของผู้จำหน่ายสำหรับ SoC โดยอ้างอิงถึงคุณสมบัตินี้
กระบวนการแบ่งส่วนโดยใช้ VTS
สำหรับ Android เวอร์ชัน 10 ขึ้นไป คุณสามารถดำเนินการกระบวนการชาร์ดดิ้งบนอุปกรณ์หลายเครื่องได้ในขณะที่ทดสอบกับทั้งแผน VTS และ CTS-on-GSI โดยทำตามคำแนะนำด้านล่าง
run vts --shard-count <number of devices> -s <device serial> ...
คำสั่งนี้จะแยกแผน VTS ออกเป็นชาร์ดและรันบนอุปกรณ์หลายเครื่อง
run cts-on-gsi --shard-count <number of devices> -s <device serial> -s ...
คำสั่งนี้จะแบ่งแผน CTS-on-GSI ออกเป็นชาร์ดและรันบนอุปกรณ์หลายเครื่อง