โครงสร้างพื้นฐานการทดสอบอัตโนมัติ

Android 9 มีโครงสร้างพื้นฐาน Vendor Test Suite (VTS) สำหรับการทดสอบ VTS, CTS หรือการทดสอบอื่นๆ โดยอัตโนมัติบนอุปกรณ์ของพันธมิตรที่ใช้อิมเมจระบบทั่วไป (GSI) ของ AOSP ก่อนหน้านี้ การรันการทดสอบเหล่านี้เป็นการดำเนินการด้วยตนเองอย่างมาก โครงสร้างพื้นฐานการทดสอบ VTS ใหม่ได้รับการออกแบบเพื่อรองรับการทดสอบอัตโนมัติหลายครั้งต่อวันบนอุปกรณ์หลายเครื่อง

สถาปัตยกรรม

โครงสร้างพื้นฐานการทดสอบอัตโนมัติ VTS ใช้สถาปัตยกรรมต่อไปนี้:

เมื่อมีการทริกเกอร์การทดสอบ โครงสร้างพื้นฐานการทดสอบอัตโนมัติ VTS จะดำเนินการดังต่อไปนี้:

1. การดึงข้อมูลสร้างสิ่งประดิษฐ์และทดสอบทรัพยากรจากตำแหน่งต่างๆ:
   • พันธมิตร Android Build (PAB) สำหรับกรอบงาน GSI, VTS และรุ่นอื่นๆ
   • ระบบไฟล์ในเครื่อง, Google Cloud Storage หรือระบบบิวด์เฉพาะผู้จำหน่ายอื่นๆ สำหรับพันธมิตรที่ไม่ได้จัดเก็บบิลด์ในระบบคลาวด์ของ Google
2. แฟลชสร้างสิ่งประดิษฐ์ (จากอุปกรณ์) และ GSI (จาก AOSP) บนอุปกรณ์ที่เชื่อมต่อ
3. รันการทดสอบ VTS โดยใช้ TradeFed ในพื้นที่หรือ TradeFed ในระบบคลาวด์
4. รายงานผลการทดสอบไปยังแดชบอร์ด VTS

กระบวนการนี้ประสานงานโดยตัวควบคุมโฮสต์ VTS (HC) ซึ่งเป็นเครื่องจักรในห้องปฏิบัติการที่ควบคุมพฤติกรรมของอุปกรณ์ที่เชื่อมต่อทั้งหมดภายใต้การทดสอบ HC มีหน้าที่รับผิดชอบในการดึงข้อมูลรุ่นล่าสุด แฟลชบนอุปกรณ์ และเรียกใช้การทดสอบ (ทั้งภายในเครื่องหรือผ่านทางผู้บังคับบัญชา) นอกจากนี้ยังสื่อสารกับตัวกำหนดเวลาระบบคลาวด์และกำหนดเส้นทางการรับส่งข้อมูลระหว่างตัวกำหนดเวลาและอินสแตนซ์ TradeFed (หรือตัวควบคุมอื่น ๆ ) ที่ทำงานบน HC สำหรับรายละเอียดเกี่ยวกับตัวควบคุมโฮสต์ โปรดดู สถาปัตยกรรมตัวควบคุมโฮสต์

ผู้ให้บริการทรัพยากร

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

คู่ค้าสามารถเข้าถึงทรัพยากรระบบอัตโนมัติได้โดยใช้ตำแหน่งต่อไปนี้:

• พันธมิตร Android Build สิทธิ์การเข้าถึงทางโปรแกรมเป็นรายบัญชี
• ระบบไฟล์ในเครื่อง (หรือคล้ายกัน) สำหรับพันธมิตรที่ไม่ได้ใช้ Partner Android Build

เพื่อใช้ในการแฟลชอุปกรณ์ในภายหลัง ทรัพยากรจะรวมผู้ให้บริการบิลด์สำหรับทั้งสองตัวเลือก โดยขยายจาก build_provider.py เดียวที่เก็บบิลด์ในไดเร็กทอรีชั่วคราวในเครื่อง

พันธมิตร Android Build

ใน Android 8.1 และรุ่นที่ต่ำกว่า พันธมิตร Android จำเป็นต้องไปที่เว็บไซต์ Partner Android Build ( https://partner.android.com/build ) ไปที่บัญชีของพวกเขา และดึงอิมเมจระบบล่าสุดผ่านอินเทอร์เฟซผู้ใช้ เพื่อช่วยให้คู่ค้าหลีกเลี่ยงกระบวนการที่ช้าและใช้แรงงานมาก Android 9 ได้รวมการสนับสนุนสำหรับการดาวน์โหลดทรัพยากรเหล่านี้จาก PAB โดยอัตโนมัติเมื่อมีการระบุข้อมูลรับรองที่เหมาะสม

สร้างการเข้าถึง

การเข้าถึงแบบเป็นโปรแกรมใช้ OAuth2 บน Google API เพื่อเข้าถึง 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 ภายใน (ซึ่งจะหมดอายุหลังจากห้านาที)

รับ 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 รองรับเฉพาะชุดทดสอบ TradeFed แต่สามารถขยายเพื่อรองรับชุดควบคุมอื่นๆ ได้ในอนาคต

หลังจากเตรียมอุปกรณ์แล้ว คุณสามารถเรียกใช้การทดสอบโดยใช้ตัวเลือกใดตัวเลือกหนึ่งต่อไปนี้:

• เมื่อใช้ TradeFed ภายในเครื่อง ให้ใช้คำสั่ง test ในโฮสต์คอนโทรลเลอร์ ซึ่งใช้ชื่อของแผนการทดสอบ VTS (เช่น vts-selftest ) และรันการทดสอบ
• เมื่อใช้คลัสเตอร์ TradeFed (เป็นทางเลือกที่เชื่อมต่อกับ MTT) ให้ใช้คำสั่ง lease ในคอนโซลตัวควบคุมโฮสต์ ซึ่งจะค้นหาการทดสอบที่ดำเนินการไม่สำเร็จ

หากใช้ TradeFedCluster นั้น TradeFed จะทำงาน ภายในเครื่องในฐานะผู้จัดการระยะไกล ถ้าไม่เช่นนั้น การทดสอบจะถูกเรียกใช้โดยใช้กระบวนการย่อยของ Python

รายงานผล

ผลการทดสอบจะถูกรายงานโดยอัตโนมัติไปยังโครงการแดชบอร์ด VTS บางโครงการโดย VtsMultiDeviceTest