يتضمّن الإصدار 9 من Android بنية أساسية لـ "مجموعة اختبار المورّدين" (VTS) لإجراء اختبار آلي لـ "مجموعة اختبار المورّدين" أو "مجموعة اختبار التوافق" أو اختبارات أخرى على أجهزة الشركاء التي تعمل بنظام التشغيل AOSP العام (GSI). في السابق، كان تنفيذ هذه الاختبار يتطلّب إجراءً يدويًا بشكل كبير. تم تصميم البنية الأساسية الجديدة لاختبار VTS لدعم الاختبار الآلي عدة مرات في اليوم على عدة أجهزة.
هندسة معمارية
تستخدم بنية الاختبار الآلي في VTS البنية التالية:
عند بدء اختبار، تُنفِّذ بنية الاختبار المبرمَج في VTS المهام التالية:
- تنشئ عمليات الجلب العناصر وتختبر الموارد من مواقع جغرافية مختلفة:
- إصدار Android (PAB) للشريك. بالنسبة إلى GSI وVTS والإطار العام وبعض الإصدارات الأخرى.
- نظام الملفات على الجهاز أو Google Cloud Storage أو أي نظام آخر خاص بالمورّدين نظام التصميم. بالنسبة إلى الشركاء الذين لا يخزّنون إصدارات متوفرة في السحابة الإلكترونية.
- تنشئ الفلاش عناصر (من الجهاز) وGSI (من AOSP) على الأجهزة المتصلة.
- يُجري اختبارات VTS باستخدام TradeFed على الجهاز أو TradeFed في السحابة الإلكترونية.
- الإبلاغ عن نتائج الاختبار في لوحة بيانات مراقبة الأداء في الوقت الفعلي
ويتم تنسيق هذه العملية بواسطة وحدة التحكم في مضيف VTS، وهي آلة في الذي يوجه سلوك جميع الأجهزة المتصلة تحت الاختبار. يتحمّل HC مسؤولية جلب أحدث الإصدارات وفلاشها على الأجهزة، و تشغيل الاختبارات (إما محليًا أو من خلال أداة التحكم). ويتواصل أيضًا مع جدولة السحابة الإلكترونية ويوجّه الزيارات بين جدولة مثيل TradeFed (أو بعض الأجهزة الأخرى) التي تعمل على HC. للحصول على تفاصيل حول وحدة التحكم المضيف، راجع المضيف بنية وحدة التحكّم.
موفِّرو الموارد
يتطلب الاختبار الآلي موارد مثل إصدارات النظام وملفات الاختبار عناصر VTS. على الرغم من أنّه من الممكن إنشاء هذه العناصر من المصدر، من الأسهل إنشاؤها من أحدث إصدار بشكل منتظم ثم نشر العناصر لتنزيلها.
يمكن للشركاء الوصول إلى موارد التشغيل الآلي من خلال المواقع الجغرافية التالية:
- إصدار Android شريك: تم منح إذن الوصول الآلي إلى لكل حساب.
- نظام ملفات محلي (أو ما شابه). بالنسبة إلى الشركاء الذين لا يستخدمون إصدار Android المخصّص للشركاء
لاستخدامها في إعادة تحميل البرامج الثابتة على الأجهزة لاحقًا، تتضمّن الموارد موفّري الإصدارات لكلٍّ من الخيارَين، بدءًا من build_provider.py واحد يخزّن الإصدارات في أدلة مؤقتة محلية.
إصدار Android للشريك
في الإصدار Android 8.1 والإصدارات الأقدم، كان على شركاء Android زيارة الموقع الإلكتروني الشريك المخصص لإصدار Android (https://partner.android.com/build)، الانتقال إلى حسابه وجلب أحدث صور النظام من خلال المستخدم من واجهة pyplot. لمساعدة الشركاء في تجنّب هذه العملية البطيئة التي تتطلب عمالة كثيفة، يشمل Android 9 إمكانية استخدام تنزيل هذه الموارد من PAB عند تقديم بيانات الاعتماد المناسبة.
منح الإذن بالوصول
يستخدم الوصول الآلي بروتوكول OAuth2 على Google APIs للوصول إلى إجراءات استدعاء الإجراء عن بُعد المطلوبة.
باستخدام
قياسي
لإنشاء بيانات اعتماد OAuth2، يجب على الشريك إعداد
زوج معرّف/سر العميل مع Google. عندما
يتم توجيه PartnerAndroidBuildClient إلى هذا المفتاح السرّي لأول مرة
يؤدي ذلك إلى فتح نافذة متصفح للمستخدم لتسجيل الدخول إلى
الذي ينشئ بيانات اعتماد OAuth2 اللازمة للمضي قدمًا. يتم تخزين بيانات اعتماد
(رمز الوصول المميّز ورمز إعادة التحميل المميّز) على الجهاز، ما يعني أنّه
على الشركاء تسجيل الدخول مرة واحدة فقط.
طلب POST لعنوان URL
يؤدي النقر على رابط مرجع في "مركز عملائي" إلى إرسال طلب POST يتضمّن البيانات اللازمة لهذا المرجع، بما في ذلك:
- رقم تعريف الإصدار، وهدف الإصدار
- اسم المورد
- فرع
- اسم الإصدار المحتمل وما إذا كان الإصدار المحتمل هو إصدار داخلي
يتم تلقّي طلب POST من خلال طريقة downloadBuildArtifact
من buildsvc RPC، والتي تعرض عنوان URL يمكن استخدامه
للوصول إلى المورد.
- بالنسبة إلى موارد حِزمة APK Clockwork Companion، يكون عنوان URL هو عنوان URL قابل للقراءة ومستضاف على PAB (محمي بموجب المصادقة ويمكن الوصول إليه باستخدام بروتوكول OAuth2 المناسب بيانات الاعتماد).
- بالنسبة إلى الموارد الأخرى، عنوان URL طويل وغير محمي من عنوان URL الداخلي واجهة برمجة التطبيقات Android Build API (تنتهي صلاحيتها بعد خمس دقائق).
الحصول على عنوان URL
لتجنُّب تزوير الطلبات من مواقع إلكترونية مختلفة، يتطلّب buildsvc RPC إرسال رمز XSRF المميّز باستخدام POST مع المَعلمات الأخرى. وفي حين أن هذا الرمز يجعل
هذه العملية أكثر أمانًا، فإنها تجعل الوصول الآلي أكثر صعوبة نظرًا لأن
(متاح فقط في JavaScript لصفحة PAB)
مطلوبة للوصول.
لتجنّب هذه المشكلة، يُعيد نظام Android 9 تصميم عنوان URL.
نظام لتسمية جميع الملفات (وليس فقط حِزم APK) لاستخدام أسماء عناوين URL يمكن توقُّعها
الوصول إلى قوائم العناصر وعناوين URL الخاصة بالعناصر. يستخدم PAB الآن عنوان URL مناسبًا
تنسيق يسمح للشركاء بتنزيل الموارد البرامج النصية لمركز المساعدة التي يمكن تنزيلها
حِزم APK هذه بسهولة، نظرًا لأن تنسيق عنوان URL معروف ويمكن أن يتجاهل "مركز المساعدة"
توجد مشاكل في XSRF أو ملف تعريف الارتباط لأنّه لا يحتاج إلى متوسط عائد النقرة buildsvc.
نظام الملفات على الجهاز
عند توفير دليل يحتوي على قائمة (أو ملف 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 (متصلة اختياريًا بـ MTT)، استخدِم الأمر
leaseفي وحدة تحكّم المضيف، والذي يبحث عن عمليات تنفيذ اختبار لم تكتمل.
في حال استخدام TradeFedCluster، يتم تشغيل TradeFed محليًا كمدير عن بُعد. وإذا لم يكن الأمر كذلك، يتم استدعاء الاختبارات باستخدام العمليات الفرعية في بايثون.
الإبلاغ عن النتائج
يتم تلقائيًا تسجيل نتائج الاختبار في بعض مشاريع لوحة بيانات مراقبة الزيارات من خلال
VtsMultiDeviceTest.