หน้านี้ได้รับการแปลโดย Cloud Translation API

ทดสอบการตั้งค่า

ชุดทดสอบ

หากต้องการทดสอบเพื่อเป็นส่วนหนึ่งของ 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,

<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 ออกเป็นชาร์ดและรันบนอุปกรณ์หลายเครื่อง