Android 9 มีโครงสร้างพื้นฐาน Vendor Test Suite (VTS) สำหรับการทดสอบ VTS, CTS หรือการทดสอบอื่นๆ โดยอัตโนมัติในอุปกรณ์พาร์ทเนอร์ ที่ใช้รูปภาพระบบทั่วไป (GSI) ของ AOSP ก่อนหน้านี้ การทดสอบเหล่านี้ต้องดำเนินการด้วยตนเองเป็นอย่างมาก โครงสร้างพื้นฐานการทดสอบ VTS ใหม่ได้รับการออกแบบมาเพื่อรองรับการทดสอบอัตโนมัติหลายครั้งต่อวันในอุปกรณ์หลายเครื่อง
สถาปัตยกรรม
โครงสร้างพื้นฐานการทดสอบอัตโนมัติของ VTS ใช้สถาปัตยกรรมต่อไปนี้
เมื่อมีการทริกเกอร์การทดสอบ โครงสร้างพื้นฐานการทดสอบอัตโนมัติของ VTS จะทำงานต่อไปนี้
- ดึงข้อมูลอาร์ติแฟกต์สำหรับบิวด์และทรัพยากรการทดสอบจากตำแหน่งต่างๆ ดังนี้
- บิลด์ Android ของพาร์ทเนอร์ (PAB) สำหรับเฟรมเวิร์ก GSI, VTS และบิลด์อื่นๆ บางรายการ
- ระบบไฟล์ในเครื่อง, Google Cloud Storage หรือระบบ บิลด์อื่นๆ ของผู้ให้บริการ สำหรับพาร์ทเนอร์ที่ไม่ได้จัดเก็บบิลด์ในระบบคลาวด์ของ Google
- แฟลชอาร์ติแฟกต์บิลด์ (จากอุปกรณ์) และ GSI (จาก AOSP) ลงใน อุปกรณ์ที่เชื่อมต่อ
- เรียกใช้การทดสอบ VTS โดยใช้ TradeFed ในเครื่องหรือ TradeFed ในระบบคลาวด์
- รายงานผลการทดสอบไปยังแดชบอร์ด VTS
กระบวนการนี้ได้รับการประสานงานโดยตัวควบคุมโฮสต์ (HC) ของ VTS ซึ่งเป็นเครื่องใน ห้องทดสอบที่กำหนดลักษณะการทำงานของอุปกรณ์ที่เชื่อมต่อทั้งหมดภายใต้การทดสอบ HC มีหน้าที่ ดึงข้อมูลบิลด์ล่าสุด แฟลชบิลด์ลงในอุปกรณ์ และ เรียกใช้การทดสอบ (ในเครื่องหรือผ่านคอมมานเดอร์) นอกจากนี้ยังสื่อสาร กับตัวกำหนดเวลางานในระบบคลาวด์และกํากับการรับส่งข้อมูลระหว่างตัวกำหนดเวลางานกับอินสแตนซ์ TradeFed (หรือฮาร์เนสอื่นๆ) ที่ทํางานใน HC ดูรายละเอียดเกี่ยวกับ เครื่องมือควบคุมโฮสต์ได้ที่สถาปัตยกรรม ของเครื่องมือควบคุมโฮสต์
ผู้ให้บริการทรัพยากร
การทดสอบอัตโนมัติต้องใช้ทรัพยากรต่างๆ เช่น บิลด์ระบบ ไฟล์ทดสอบ และ อาร์ติแฟกต์ VTS แม้ว่าจะสร้างจากแหล่งที่มาได้ แต่การสร้างจากส่วนหัวของทรีเป็นประจำแล้วโพสต์อาร์ติแฟกต์ให้ดาวน์โหลดจะง่ายกว่า
พาร์ทเนอร์สามารถเข้าถึงแหล่งข้อมูลการทำงานอัตโนมัติได้โดยไปที่ตำแหน่งต่อไปนี้
- บิลด์ Android ของพาร์ทเนอร์ สิทธิ์เข้าถึงแบบเป็นโปรแกรมที่มอบให้ ต่อบัญชี
- ระบบไฟล์ในเครื่อง (หรือคล้ายกัน) สำหรับพาร์ทเนอร์ที่ไม่ได้ใช้ Android Build ของพาร์ทเนอร์
สำหรับใช้ในการแฟลชอุปกรณ์ในภายหลัง ทรัพยากรประกอบด้วยผู้ให้บริการบิลด์สำหรับทั้ง 2 ตัวเลือก ซึ่งขยายจาก build_provider.py เดียวที่จัดเก็บบิลด์ในไดเรกทอรีชั่วคราวในเครื่อง
บิลด์ Android ของพาร์ทเนอร์
ใน Android เวอร์ชัน 8.1 และต่ำกว่า พาร์ทเนอร์ Android ต้องไปที่เว็บไซต์ Partner Android Build (https://partner.android.com/build) ไปที่บัญชีของตน และดึงข้อมูลอิมเมจระบบล่าสุดผ่านอินเทอร์เฟซผู้ใช้ Android 9 จึงรองรับการดาวน์โหลดทรัพยากรเหล่านี้จาก PAB โดยอัตโนมัติเมื่อมีการระบุข้อมูลเข้าสู่ระบบที่เหมาะสม เพื่อช่วยให้พาร์ทเนอร์ไม่ต้องผ่านกระบวนการที่ช้าและต้องใช้แรงงานมากนี้
สร้างสิทธิ์เข้าถึง
การเข้าถึงแบบเป็นโปรแกรมใช้ OAuth2 ใน Google APIs เพื่อเข้าถึง RPC ที่จำเป็น
การใช้แนวทางมาตรฐานในการสร้างข้อมูลเข้าสู่ระบบ OAuth2 พาร์ทเนอร์ต้องตั้งค่าคู่รหัสไคลเอ็นต์/รหัสลับกับ Google เมื่อ
PartnerAndroidBuildClient ชี้ไปยังข้อมูลลับนั้นเป็นครั้งแรก
ระบบจะเปิดหน้าต่างเบราว์เซอร์เพื่อให้ผู้ใช้เข้าสู่ระบบบัญชี Google
ซึ่งจะสร้างข้อมูลเข้าสู่ระบบ OAuth2 ที่จำเป็นต่อการดำเนินการต่อ ระบบจะจัดเก็บข้อมูลเข้าสู่ระบบ (โทเค็นเพื่อการเข้าถึงและโทเค็นการรีเฟรช) ไว้ในเครื่อง ซึ่งหมายความว่าพาร์ทเนอร์จะต้องเข้าสู่ระบบเพียงครั้งเดียว
คำขอ POST สำหรับ URL
การคลิกลิงก์ทรัพยากรใน PAB จะส่งคำขอ POST ที่มีข้อมูลที่จำเป็นสำหรับทรัพยากรนั้น ซึ่งรวมถึงข้อมูลต่อไปนี้
- รหัสบิลด์ เป้าหมายบิลด์
- ชื่อทรัพยากร
- สาขา
- ชื่อรุ่นที่อาจได้รับการเผยแพร่และระบุว่ารุ่นที่อาจได้รับการเผยแพร่เป็นบิลด์ภายในหรือไม่
คำขอ POST จะได้รับโดยเมธอด downloadBuildArtifact
ของ buildsvc RPC ซึ่งจะแสดงผล 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 ไปยังไดเรกทอรีในเครื่องได้
บิลด์ Flash
หลังจากดาวน์โหลดอิมเมจอุปกรณ์ล่าสุดไปยังโฮสต์แล้ว คุณจะต้อง
แฟลชอิมเมจเหล่านั้นลงในอุปกรณ์ โดยจะใช้คำสั่งมาตรฐาน
adb และ fastboot รวมถึงกระบวนการย่อยของ Python
ตามเส้นทางไฟล์ชั่วคราวที่ผู้ให้บริการบิลด์จัดเก็บไว้
การดำเนินการที่รองรับ
- แฟลชเฉพาะ GSI
- การแสดงรูปภาพแต่ละรูปจากระบบหลัก (เช่น
fastboot flash boot boot.img) - การแฟลชอิมเมจทั้งหมดจากระบบหลัก ตัวอย่าง
fastboot flashall(ใช้ยูทิลิตีflashallในตัว)fastboot flash(ทีละรายการ)
ทำการทดสอบ
ใน Android 9 โครงสร้างพื้นฐานของการทดสอบอัตโนมัติ VTS รองรับเฉพาะ TradeFed Test Harness แต่สามารถขยาย เพื่อรองรับ Harness อื่นๆ ในอนาคตได้
หลังจากเตรียมอุปกรณ์แล้ว คุณจะเรียกใช้การทดสอบได้โดยใช้ตัวเลือกใดตัวเลือกหนึ่งต่อไปนี้
- เมื่อใช้ TradeFed ในเครื่อง ให้ใช้คำสั่ง
testในตัวควบคุมโฮสต์ ซึ่งจะใช้ชื่อของแผนการทดสอบ VTS (เช่นvts-selftest) และเรียกใช้การทดสอบ - เมื่อใช้คลัสเตอร์ TradeFed (เชื่อมต่อกับ MTT ก็ได้) ให้ใช้คำสั่ง
leaseในคอนโซลของตัวควบคุมโฮสต์ ซึ่งจะค้นหา การทดสอบที่ยังไม่เสร็จสมบูรณ์
หากใช้ TradeFedCluster TradeFed จะทำงานในเครื่องในฐานะเครื่องมือจัดการระยะไกล หากไม่ได้ระบุ ระบบจะเรียกใช้การทดสอบโดยใช้กระบวนการย่อยของ Python
ผลลัพธ์ของรายงาน
ระบบจะรายงานผลการทดสอบไปยังโปรเจ็กต์แดชบอร์ด VTS บางโปรเจ็กต์โดยอัตโนมัติโดย
VtsMultiDeviceTest