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