يتضمّن Android 9 بنية تحتية لمجموعة اختبارات المورِّد (VTS) لإجراء اختبارات VTS أو CTS أو اختبارات أخرى تلقائيًا على أجهزة الشركاء التي تعمل بصورة النظام العامة (GSI) من مشروع Android مفتوح المصدر (AOSP). في السابق، كان إجراء هذه الاختبارات عملية يدوية للغاية. تم تصميم البنية التحتية الجديدة لاختبارات VTS لإجراء الاختبارات تلقائيًا عدة مرات في اليوم على أجهزة متعددة.
هندسة معمارية
تستخدم البنية التحتية للاختبارات التلقائية في VTS الهندسة المعمارية التالية:
عند بدء اختبار، تنفّذ البنية التحتية للاختبارات التلقائية في VTS المهام التالية:
- تجلُب عناصر الإصدار وموارد الاختبار من مواقع مختلفة:
- إصدار Android للشركاء (PAB) : بالنسبة إلى GSI وإطار عمل VTS وبعض الإصدارات الأخرى
- نظام الملفات المحلي أو Google Cloud Storage أو نظام إصدار آخر خاص بالمورِّد نظام الإصدار. للشركاء الذين لا يخزّنون الإصدارات في سحابة Google
- تثبِّت عناصر الإصدار (من الجهاز) وGSI (من AOSP) على الأجهزة المتصلة.
- تُجري اختبارات VTS باستخدام TradeFed محليًا أو TradeFed في السحابة الإلكترونية.
- تُبلغ عن نتائج الاختبارات في لوحة بيانات VTS
تتولى تنسيق العملية وحدة التحكّم بالمضيف (HC) في VTS، وهي جهاز في الـ مختبر يوجّه سلوك جميع الأجهزة المتصلة الخاضعة للاختبار. تتولى وحدة التحكّم بالمضيف مسؤولية جلب أحدث الإصدارات وتثبيتها على الأجهزة وبدء الاختبارات (إما محليًا أو من خلال أداة التحكّم). تتواصل أيضًا مع أداة جدولة في السحابة الإلكترونية وتوجّه حركة البيانات بين أداة الجدولة ومثيل TradeFed (أو أي أداة أخرى) قيد التشغيل على وحدة التحكّم بالمضيف. لمعرفة التفاصيل عن وحدة التحكّم بالمضيف، يُرجى الاطّلاع على الهندسة المعمارية لوحدة التحكّم بالمضيف.
موفّرو الموارد
تتطلب الاختبارات التلقائية موارد، مثل إصدارات النظام وملفات الاختبار و عناصر VTS. على الرغم من إمكانية إنشاء هذه الموارد من المصدر، من الأسهل إنشاؤها بانتظام من أحدث إصدار ثم نشر عناصر الإصدار لتنزيلها.
يمكن للشركاء الوصول إلى موارد التشغيل التلقائي باستخدام المواقع التالية:
- إصدار Android للشركاء : يتم منح إذن الوصول آليًا على أساس كل حساب.
- نظام الملفات المحلي (أو ما شابه): للشركاء الذين لا يستخدمون إصدار Android للشركاء
لاستخدامها في تثبيت الإصدارات على الأجهزة لاحقًا، تتضمّن الموارد موفّري إصدارات لـ
كلا الخيارَين، بدءًا من ملف build_provider.py واحد يخزّن الإصدارات في أدلة مؤقتة محلية.
إصدار Android للشركاء
في Android 8.1 والإصدارات الأقدم، كان على شركاء Android الانتقال إلى الموقع الإلكتروني لإصدار Android للشركاء (https://partner.android.com/build)، والانتقال إلى حساباتهم، وجلب أحدث صور النظام من خلال واجهة المستخدم. لمساعدة الشركاء في تجنُّب هذه العملية البطيئة والمكلفة، يتضمّن Android 9 إمكانية تنزيل هذه الموارد تلقائيًا من إصدار Android للشركاء عند تقديم بيانات الاعتماد المناسبة.
منح إذن الوصول
يستخدم الوصول آليًا بروتوكول OAuth2 على Google APIs للوصول إلى إجراءات RPC المطلوبة.
باستخدام الطريقة
العادية
لإنشاء بيانات اعتماد OAuth2، على الشريك إعداد زوج من معرّف العميل/السر مع Google. عندما يتم توجيه
PartnerAndroidBuildClient إلى هذا السر للمرة الأولى، تفتح نافذة متصفّح للمستخدم لتسجيل الدخول إلى حسابه على Google
، ما يؤدي إلى إنشاء بيانات اعتماد OAuth2 اللازمة للمتابعة. يتم تخزين بيانات الاعتماد (رمز الدخول والرمز المميز لإعادة التحميل) محليًا، ما يعني أنّه على الشركاء تسجيل الدخول مرة واحدة فقط.
طلب POST لعنوان URL
يؤدي النقر على رابط مورد في إصدار Android للشركاء إلى إرسال طلب POST يتضمّن البيانات الضرورية لهذا المورد، بما في ذلك:
- رقم تعريف الإصدار، هدف الإصدار
- اسم المورِد
- فرع
- اسم الإصدار المحتمل وما إذا كان الإصدار المحتمل إصدارًا داخليًا أم لا
يتلقّى طلب POST طريقة downloadBuildArtifact في إجراء RPC buildsvc، التي تعرض عنوان URL يمكن استخدامه للوصول إلى المورِد.
- بالنسبة إلى موارد حزمة APK لتطبيق Clockwork Companion، يكون عنوان URL عنوان URL قابلاً للقراءة ومستضافًا على إصدار Android للشركاء (المحمي بمصادقة ويمكن الوصول إليه باستخدام بيانات اعتماد OAuth2 المناسبة).
- بالنسبة إلى الموارد الأخرى، يكون عنوان URL عنوان URL طويلاً وغير محمي من واجهة برمجة التطبيقات الداخلية لإصدار Android (الذي تنتهي صلاحيته بعد خمس دقائق).
الحصول على عنوان URL
لتجنُّب تزوير الطلبات من موقع إلكتروني مختلف، يتطلب إجراء RPC buildsvc إرسال رمز XSRF مع المعلمات الأخرى باستخدام طريقة POST. على الرغم من أنّ هذا الرمز يزيد من أمان العملية، إلا أنّه يجعل الوصول آليًا أكثر صعوبة بكثير لأنّ الرمز (الذي لا يتوفّر إلا في JavaScript لصفحة إصدار Android للشركاء) مطلوب الآن أيضًا للوصول.
لتجنُّب هذه المشكلة، يعيد Android 9 تصميم نظام تسمية عناوين URL
لجميع الملفات (وليس حِزم APK فقط) لاستخدام أسماء عناوين URL يمكن توقّعها للوصول إلى قوائم عناصر الإصدار وعناوين URL لعناصر الإصدار. يستخدم إصدار Android للشركاء الآن تنسيق عنوان URL
مناسبًا يمكّن الشركاء من تنزيل الموارد. يمكن لبرامج HC النصية تنزيل حِزم APK هذه بسهولة، لأنّ تنسيق عنوان URL
معروف، ويمكن لوحدة التحكّم بالمضيف تجاوز مشاكل XSRF/ملفات تعريف الارتباط لأنّها لا تحتاج إلى إجراء RPC buildsvc.
نظام الملفات المحلي
عند تحديد دليل يتضمّن قائمة (أو ملف zip) بعناصر الإصدار، يضبط موفّر الإصدار الصور ذات الصلة استنادًا إلى محتوى الدليل. يمكنك استخدام أداة gsutil لنسخ الملفات من Google Cloud Storage إلى دليل محلي.
تثبيت الإصدارات
بعد تنزيل أحدث صور الجهاز على المضيف، يجب تثبيت هذه الصور
على الأجهزة. يتم ذلك باستخدام الأوامر العادية
adb وfastboot والعمليات الفرعية في Python،
استنادًا إلى مسارات الملفات المؤقتة التي يخزّنها موفّرو الإصدارات.
الإجراءات المتاحة:
- تثبيت GSI فقط
- تثبيت صور فردية من النظام الرئيسي (مثل
fastboot flash boot boot.img) - تثبيت جميع الصور من النظام الرئيسي مثال:
fastboot flashall(باستخدام الأداة المضمّنةflashallutility)fastboot flash(واحدة في كل مرة)
إجراء الاختبارات
في Android 9، لا تدعم البنية التحتية للاختبارات التلقائية في VTS سوى أداة اختبار TradeFed، ولكن يمكن توسيعها لدعم أدوات أخرى في المستقبل.
بعد إعداد الأجهزة، يمكنك بدء الاختبارات باستخدام أحد الخيارَين التاليَين:
- عند استخدام TradeFed محليًا، استخدِم الأمر
testفي وحدة التحكّم بالمضيف ، الذي يأخذ اسم خطة اختبار VTS (مثلvts-selftest) ويُجري الاختبار. - عند استخدام TradeFed Cluster (المرتبط اختياريًا بـ MTT)، استخدِم الـ
leaseأمر في وحدة التحكّم بالمضيف، الذي يبحث عن عمليات تشغيل الاختبارات غير المكتملة.
في حال استخدام TradeFedCluster، يتم تشغيل TradeFed محليًا كمدير عن بُعد. إذا لم يكن الأمر كذلك، يتم بدء الاختبارات باستخدام العمليات الفرعية في Python.
الإبلاغ عن النتائج
يتم تلقائيًا الإبلاغ عن نتائج الاختبارات إلى بعض مشاريع لوحة بيانات VTS من خلال
VtsMultiDeviceTest.