Android 9 شامل زیرساخت «مجموعه آزمون فروشنده» (VTS) برای آزمون خودکار VTS، CTS، یا آزمونهای دیگر در دستگاههای شریک است که تصویر سیستم عمومی AOSP (GSI) را اجرا میکنند. قبلاً اجرای این آزمایشها یک عملیات بسیار دستی بود؛ زیرساخت جدید آزمایش VTS برای پشتیبانی از آزمایش خودکار چند بار در روز روی چندین دستگاه طراحی شده است.
معماری
زیرساخت آزمایش خودکار VTS از معماری زیر استفاده میکند:
وقتی آزمایشی راهاندازی میشود، زیرساخت آزمایش خودکار VTS کارهای زیر را انجام میدهد:
- آرتیفکتهای ساخت و منابع آزمایشی را از مکانهای مختلف واکشی میکند:
- ساخت Android شریک (PAB). برای GSI، چارچوب VTS، و برخی ساختهای دیگر.
- سیستم فایل محلی، Google Cloud Storage، یا سیستم ساخت مخصوص فروشنده دیگر. برای شرکایی که ساختها را در فضای ابری Google ذخیره نمیکنند.
- ساختمانهای مصنوع (از دستگاه) و GSI (از AOSP) را روی دستگاه(های) متصل فلش میکند.
- آزمایشهای VTS را بااستفاده از TradeFed محلی یا TradeFed در ابر اجرا میکند.
- نتایج آزمایش را به داشبورد VTS گزارش میکند
این فرایند توسط کنترلکننده میزبان VTS (HC)، ماشینی در آزمایشگاه که رفتار همه دستگاههای متصل تحت آزمایش را هدایت میکند، هماهنگ میشود. HC مسئول واکشی جدیدترین ساختها، فلش کردن آنها روی دستگاهها، و فراخوانی آزمایشها (بهصورت محلی یا ازطریق فرماندهنده) است. همچنین با زمانبند ابری ارتباط برقرار میکند و ترافیک را بین زمانبند و نمونه TradeFed (یا برخی مهاربندهای دیگر) که روی HC اجرا میشود هدایت میکند. برای جزئیات مربوط به کنترلکننده میزبان، به معماری کنترلکننده میزبان مراجعه کنید.
ارائهدهندگان منبع
آزمایش خودکارشده به منابعی مانند ساختارهای سیستم، فایلهای آزمایش، و آثار VTS نیاز دارد. While it's possible to build these from source, it is easier to build them from tip-of-tree regularly then post the artifacts for download.
شرکا میتوانند بااستفاده از مکانهای زیر به منابع خودکارسازی دسترسی داشته باشند:
- ساخت Android شریک. دسترسی برنامهریزیشده براساس هر حساب اعطا شده است.
- سیستم فایل محلی (یا موارد مشابه). برای شرکایی که از «ساخت Android شریک» استفاده نمیکنند.
برای استفاده در چشمک زدن دستگاهها در آینده، منابع شامل ارائهدهندگان ساخت برای هر دو گزینه میشود، که از یک build_provider.py که ساختها را در دایرکتوریهای موقت محلی ذخیره میکند، گسترش مییابد.
ساخت Android شریک
در Android نسخه ۸.۱ و پایینتر، شرکای Android ملزم بودند به وبسایت «ساخت Android شریک» (https://partner.android.com/build) مراجعه کنند، به حساب خودشان بروند، و جدیدترین تصاویر سیستم را ازطریق رابط کاربری واکشی کنند. برای کمک به شرکا در اجتناب از این فرایند کند و پرزحمت، Android 9 از بارگیری خودکار این منابع از PAB درصورت ارائه اطلاعات اعتباری مناسب پشتیبانی میکند.
برقراری دسترسی
دسترسی برنامهریزیشده از OAuth2 در Google APIs برای دسترسی به RPCهای موردنیاز استفاده میکند.
بااستفاده از رویکرد استاندارد برای تولید اعتبارنامههای OAuth2، شریک باید یک جفت شناسه/رمز کارخواه با Google تنظیم کند. وقتی
PartnerAndroidBuildClient برای اولینبار به آن راز اشاره میکند،
پنجره مرورگری برای کاربر باز میشود تا به سیستم حساب Google خود وارد شود،
که اطلاعات اعتباری OAuth2 موردنیاز برای ادامه کار را تولید میکند. اعتبارنامهها (کد دسترسی و کد بازآوری) بهصورت محلی ذخیره میشوند، به این معنی که شرکا فقط یکبار باید وارد سیستم شوند.
درخواست POST برای نشانی وب
کلیک کردن روی پیوند منبع در PAB درخواست POST را ارسال میکند که شامل دادههای لازم برای آن منبع است، ازجمله:
- شناسه ساخت، هدف ساخت
- نام منبع
- شاخه
- نام نامزد انتشار و اینکه آیا نامزد ساخت داخلی است یا نه
درخواست POST توسط روش downloadBuildArtifact
از buildsvc RPC دریافت میشود، که نشانی وبی را برمیگرداند که میتوان از آن برای
دسترسی به منبع استفاده کرد.
- برای منابع APK «همراه ساعت»، نشانی وب نشانی وب خوانایی است که در PAB میزبانی میشود (که با اعتبارنامههای OAuth2 مناسب محافظت میشود و قابلدسترسی است).
- برای منابع دیگر، نشانی وب طولانی و محافظتنشده از «میانای برنامهسازی کاربردی ساخت Android» داخلی است (که پساز پنج دقیقه منقضی میشود).
دریافت نشانی وب
برای جلوگیری از جعل درخواست بینسایتی، buildsvc RPC نیاز دارد
تا کد XSRF با پارامترهای دیگر پست شود. اگرچه این کد دسترسی فرایند را ایمنتر میکند، اما دسترسی برنامهریزیشده را نیز بسیار دشوارتر میکند زیرا کد دسترسی (که فقط در جاوا اسکریپت صفحه PAB دردسترس است) اکنون برای دسترسی نیز لازم است.
برای جلوگیری از بروز این مشکل، Android 9 طرح نامگذاری نشانی وب را برای همه فایلها (نه فقط فایلهای APK) بازطراحی میکند تا از نامهای نشانی وب قابلپیشبینی برای دسترسی به فهرستهای آرتیفکت و نشانیهای وب آرتیفکت استفاده کند. اکنون PAB از قالب نشانی وب مناسبی استفاده میکند که شرکا را قادر میسازد منابع را بارگیری کنند؛ برنامههای HC میتوانند این فایلهای APK را بهراحتی بارگیری کنند، زیرا قالب نشانی وب مشخص است و 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 پشتیبانی میکند اما میتواند در آینده برای پشتیبانی از مهارهای دیگر گسترش یابد.
پساز آماده شدن دستگاهها، میتوانید بااستفاده از یکی از گزینههای زیر، آزمایشها را فراخوانی کنید:
- هنگام استفاده از TradeFed بهصورت محلی، از فرمان
testدر کنترلکننده میزبان استفاده کنید که نام طرح آزمایشی VTS را میگیرد (برای نمونه،vts-selftest) و آزمون را اجرا میکند. - هنگام استفاده از TradeFed Cluster (که بهطور اختیاری به MTT متصل است)، از فرمان
leaseدر کنسول کنترلکننده میزبان استفاده کنید که بهدنبال اجراهای آزمایشی انجامنشده میگردد.
اگر از TradeFedCluster استفاده میکنید، TradeFed بهصورت محلی بهعنوان مدیر از دور اجرا میشود. اگر نه، آزمایشها بااستفاده از زیرفرایندهای Python فراخوانی میشوند.
گزارش کردن نتایج
نتایج آزمایش بهطور خودکار توسط
VtsMultiDeviceTest به برخیاز پروژههای داشبورد VTS گزارش میشود.