Android 9 มีโครงสร้างพื้นฐาน Vendor Test Suite (VTS) สำหรับการทดสอบ VTS, CTS หรือการทดสอบอื่นๆ ในอุปกรณ์ของพาร์ทเนอร์ ที่ใช้ GSI (Generic System Image) ของ AOSP โดยอัตโนมัติ ก่อนหน้านี้ การเรียกใช้การทดสอบเหล่านี้ ต้องทำด้วยตนเองเป็นส่วนใหญ่ โครงสร้างพื้นฐานการทดสอบ VTS ใหม่จึงได้รับการออกแบบมาเพื่อรองรับการทดสอบอัตโนมัติหลายครั้งต่อวันในอุปกรณ์หลายเครื่อง
สถาปัตยกรรม
โครงสร้างพื้นฐานการทดสอบอัตโนมัติของ VTS ใช้สถาปัตยกรรมต่อไปนี้
เมื่อมีการทริกเกอร์การทดสอบ โครงสร้างพื้นฐานการทดสอบอัตโนมัติของ VTS จะทำงาน ต่อไปนี้
- ดึงข้อมูลอาร์ติแฟกต์บิวด์และทรัพยากรการทดสอบจากตำแหน่งต่างๆ ดังนี้
- Partner Android Build (PAB) สำหรับ GSI, เฟรมเวิร์ก VTS และบิวด์อื่นๆ
- ระบบไฟล์ในเครื่อง, Google Cloud Storage หรือระบบบิวด์อื่นๆ ที่เฉพาะเจาะจงของผู้ให้บริการ ระบบบิวด์ สำหรับพาร์ทเนอร์ที่ไม่ได้จัดเก็บข้อมูลบิวด์ไว้ในระบบคลาวด์ของ Google
- แฟลชอาร์ติแฟกต์บิวด์ (จากอุปกรณ์) และ GSI (จาก AOSP) ลงในอุปกรณ์ที่เชื่อมต่อ
- เรียกใช้การทดสอบ VTS โดยใช้ TradeFed ในเครื่องหรือ TradeFed ในระบบคลาวด์
- รายงานผลการทดสอบไปยังแดชบอร์ด VTS
กระบวนการนี้ได้รับการประสานงานโดย VTS Host Controller (HC) ซึ่งเป็นเครื่องใน ห้องแล็บที่ควบคุมการทำงานของอุปกรณ์ที่เชื่อมต่อทั้งหมดที่อยู่ระหว่างการทดสอบ HC มีหน้าที่ดึงข้อมูลบิวด์ล่าสุด แฟลชข้อมูลลงในอุปกรณ์ และ เรียกใช้การทดสอบ (ในเครื่องหรือผ่าน Commander) นอกจากนี้ยังสื่อสาร กับ Cloud Scheduler และกำหนดเส้นทางการรับส่งข้อมูลระหว่าง Scheduler กับ อินสแตนซ์ TradeFed (หรือ Harness อื่นๆ) ที่ทำงานใน HC ดูรายละเอียดเกี่ยวกับ Host Controller ได้ที่ สถาปัตยกรรม Host Controller
ผู้ให้บริการทรัพยากร
การทดสอบอัตโนมัติต้องใช้ทรัพยากรต่างๆ เช่น บิวด์ระบบ ไฟล์ทดสอบ และ อาร์ติแฟกต์ VTS แม้ว่าจะสร้างทรัพยากรเหล่านี้จากซอร์สโค้ดได้ แต่การสร้างจาก Tip-of-Tree เป็นประจำแล้วโพสต์อาร์ติแฟกต์ให้ดาวน์โหลดจะง่ายกว่า
พาร์ทเนอร์สามารถเข้าถึงทรัพยากรการทำงานอัตโนมัติได้จากตำแหน่งต่อไปนี้
- Partner Android Build เข้าถึงแบบเป็นโปรแกรมได้โดยกำหนดสิทธิ์เข้าถึงเป็นรายบัญชี
- ระบบไฟล์ในเครื่อง (หรือระบบที่คล้ายกัน) สำหรับพาร์ทเนอร์ที่ไม่ได้ใช้ Partner Android Build
ทรัพยากรรวมถึงผู้ให้บริการบิวด์สำหรับ
ทั้ง 2 ตัวเลือก โดยขยายจาก build_provider.py รายการเดียวที่
จัดเก็บข้อมูลบิวด์ไว้ในไดเรกทอรีชั่วคราวในเครื่อง เพื่อใช้ในการแฟลชอุปกรณ์ในภายหลัง
Partner Android Build
ใน Android 8.1 และเวอร์ชันที่ต่ำกว่า พาร์ทเนอร์ Android ต้องไปที่ เว็บไซต์ Partner Android Build (https://partner.android.com/build) ไปที่บัญชีของตนเอง และดึงข้อมูลอิมเมจระบบล่าสุดผ่านอินเทอร์เฟซผู้ใช้ Android 9 จึงรองรับการดาวน์โหลดทรัพยากรเหล่านี้จาก PAB โดยอัตโนมัติเมื่อมีการระบุข้อมูลเข้าสู่ระบบที่เหมาะสม เพื่อช่วยให้พาร์ทเนอร์ไม่ต้องทำตามกระบวนการที่ช้าและต้องใช้แรงงานมากนี้
สร้างสิทธิ์เข้าถึง
การเข้าถึงแบบเป็นโปรแกรมใช้ OAuth2 ใน Google API เพื่อเข้าถึง RPC ที่จำเป็น
พาร์ทเนอร์ต้องตั้งค่า
รหัสไคลเอ็นต์/รหัสลับกับ Google โดยใช้วิธี
มาตรฐานในการสร้างข้อมูลเข้าสู่ระบบ OAuth2 เมื่อ
PartnerAndroidBuildClient ชี้ไปยังรหัสลับดังกล่าวเป็นครั้งแรก
ระบบจะเปิดหน้าต่างเบราว์เซอร์ให้ผู้ใช้เข้าสู่ระบบบัญชี Google
ซึ่งจะสร้างข้อมูลเข้าสู่ระบบ OAuth2 ที่จำเป็นสำหรับการดำเนินการต่อ ระบบจะจัดเก็บข้อมูลเข้าสู่ระบบ (โทเค็นเพื่อการเข้าถึงและโทเค็นการรีเฟรช) ไว้ในเครื่อง ซึ่งหมายความว่า
พาร์ทเนอร์จะต้องเข้าสู่ระบบเพียงครั้งเดียว
คำขอ POST สำหรับ URL
การคลิกลิงก์ทรัพยากรใน PAB จะส่งคำขอ POST ที่มี ข้อมูลที่จำเป็นสำหรับทรัพยากรนั้นๆ ซึ่งรวมถึงข้อมูลต่อไปนี้
- รหัสบิวด์ เป้าหมายบิวด์
- ชื่อทรัพยากร
- สาขา
- ชื่อรุ่นที่อาจได้รับการเผยแพร่และระบุว่ารุ่นดังกล่าวเป็นบิวด์ภายในหรือไม่
เมธอด downloadBuildArtifact ของ buildsvc RPC จะรับคำขอ POST ซึ่งจะแสดงผล URL ที่ใช้เข้าถึงทรัพยากรได้
- สำหรับทรัพยากร APK ของ Clockwork Companion URL จะเป็น URL ที่อ่านได้ซึ่งโฮสต์อยู่ใน PAB (ซึ่งได้รับการปกป้องด้วยการตรวจสอบสิทธิ์และเข้าถึงได้ด้วยข้อมูลเข้าสู่ระบบ OAuth2 ที่เหมาะสม)
- สำหรับทรัพยากรอื่นๆ URL จะเป็น URL ที่ยาวและไม่ได้รับการปกป้องจาก Android Build API ภายใน (ซึ่งจะหมดอายุหลังจากผ่านไป 5 นาที)
รับ URL
เพื่อหลีกเลี่ยงการปลอมแปลงคำขอแบบข้ามเว็บไซต์ buildsvc RPC กำหนดให้ต้องมีการโพสต์โทเค็น XSRF พร้อมกับพารามิเตอร์อื่นๆ แม้ว่าโทเค็นนี้จะทำให้
กระบวนการมีความปลอดภัยมากขึ้น แต่ก็ทำให้การเข้าถึงแบบเป็นโปรแกรมทำได้ยากขึ้นมากเช่นกัน เนื่องจากตอนนี้ต้องใช้โทเค็น (ซึ่งมีเฉพาะใน JavaScript ของหน้า PAB) ในการเข้าถึงด้วย
Android 9 จึงออกแบบระบบการตั้งชื่อ URL
ใหม่สำหรับไฟล์ทั้งหมด (ไม่ใช่แค่ APK) เพื่อใช้ชื่อ URL ที่คาดการณ์ได้สำหรับการเข้าถึงรายการอาร์ติแฟกต์และ URL ของอาร์ติแฟกต์ เพื่อหลีกเลี่ยงปัญหานี้ ตอนนี้ PAB ใช้รูปแบบ URL
ที่สะดวกซึ่งช่วยให้พาร์ทเนอร์ดาวน์โหลดทรัพยากรได้ สคริปต์ HC สามารถดาวน์โหลด
APK เหล่านั้นได้อย่างง่ายดาย เนื่องจากทราบรูปแบบ URL และ HC สามารถข้ามปัญหา
XSRF/คุกกี้ได้เนื่องจากไม่จำเป็นต้องใช้ buildsvc RPC
ระบบไฟล์ในเครื่อง
เมื่อมีไดเรกทอรีที่มีรายการ (หรือไฟล์ ZIP) ของอาร์ติแฟกต์ ผู้ให้บริการบิวด์ จะตั้งค่าอิมเมจที่เกี่ยวข้องตามสิ่งที่อยู่ในไดเรกทอรี คุณสามารถใช้เครื่องมือ gsutil เพื่อคัดลอกไฟล์จาก Google Cloud Storage ไปยังไดเรกทอรีในเครื่องได้
แฟลชบิวด์
หลังจากดาวน์โหลดอิมเมจอุปกรณ์ล่าสุดลงในโฮสต์แล้ว คุณต้องแฟลชอิมเมจเหล่านั้น
ลงในอุปกรณ์ ซึ่งทำได้โดยใช้คำสั่งมาตรฐาน
adb และ fastboot และกระบวนการย่อยของ Python
โดยอิงตามเส้นทางไฟล์ชั่วคราวที่ผู้ให้บริการบิวด์จัดเก็บไว้
การดำเนินการที่รองรับ
- แฟลชเฉพาะ GSI
- แฟลชอิมเมจแต่ละรายการจากระบบหลัก (เช่น
fastboot flash boot boot.img) - แฟลชอิมเมจทั้งหมดจากระบบหลัก ตัวอย่าง
fastboot flashall(โดยใช้ยูทิลิตีflashallในตัว)fastboot flash(ทีละรายการ)
เรียกใช้การทดสอบ
ใน Android 9 โครงสร้างพื้นฐานการทดสอบอัตโนมัติของ VTS รองรับเฉพาะ Harness การทดสอบ TradeFed แต่สามารถขยาย เพื่อรองรับ Harness อื่นๆ ในอนาคตได้
หลังจากเตรียมอุปกรณ์แล้ว คุณสามารถเรียกใช้การทดสอบโดยใช้ตัวเลือกใดตัวเลือกหนึ่งต่อไปนี้
- เมื่อใช้ TradeFed ในเครื่อง ให้ใช้คำสั่ง
testใน Host Controller ซึ่งจะใช้ชื่อแผนการทดสอบ VTS (เช่นvts-selftest) และเรียกใช้การทดสอบ - เมื่อใช้ TradeFed Cluster (ซึ่งอาจเชื่อมต่อกับ MTT) ให้ใช้
leaseคำสั่งในคอนโซล Host Controller ซึ่งจะค้นหา การทดสอบที่ยังไม่เสร็จสมบูรณ์
หากใช้ TradeFedCluster, TradeFed จะทำงาน ในเครื่องในฐานะผู้จัดการระยะไกล หากไม่เป็นเช่นนั้น ระบบจะเรียกใช้การทดสอบโดยใช้กระบวนการย่อยของ Python
รายงานผลลัพธ์
ผลการทดสอบจะรายงานไปยังโปรเจ็กต์แดชบอร์ด VTS บางโปรเจ็กต์โดยอัตโนมัติโดย
VtsMultiDeviceTest.