رصد الأجهزة في Tradefed

يؤدي ربط جهاز جديد إلى بدء سلسلة من الأحداث غير المتزامنة التي ليست واضحة، ولكن من المفيد فهمها.

متصلة جسديًا

يستخدم Tradefed مكتبة ddmlib (مكتبة adb لتطبيقات Java) لتوفير التفاعل الأساسي مع adb والأجهزة. ويتمثل جزء من هذا الحل في واجهة IDeviceChangeListener التي تسمح باستقبال أحداث الأجهزة الجديدة، مثل:

• deviceConnected: عندما يرصد adb جهازًا جديدًا
• deviceDisconnected: عندما يتوقف أحد الأجهزة عن إرسال التقارير إلى adb
• deviceChanged: عند حدوث تغيير كبير في حالة الجهاز (مثل الجهاز غير متصل بالإنترنت أو الجهاز متصل بالإنترنت)

تكفي هذه الأحداث على مستوى adb لتحديد ما إذا كان الجهاز متصلاً بالإنترنت أو غير متصل بالإنترنت أم لا. أمّا بالنسبة إلى مفعِّل الاختبار، نحتاج إلى حالة أقوى من تلك المتوفّرة لضمان أن يكون الجهاز جاهزًا لبدء إجراء الاختبارات، وبالتالي يجب ألا يتأثر باهتزاز الحالة المحتمل الذي قد يتسبّب به الجهاز الذي تم توصيله حديثًا.

في ما يلي تسلسل الأحداث في Tradefed:

1. تم التعرّف على الجهاز بأنّه deviceConnected وهو مفتوح للأحداث العادية من adb.

2. يتمّ إنشاء حدث داخلي في Tradefed سيؤدي إلى ما يلي:

   • تحقّق ممّا إذا كان الجهاز معروفًا من قبل، إذ يحتفظ Tradefed بمرجع داخلي لبعض الأجهزة (خاصةً الجهاز الذي تم تخصيصه حاليًا وإجراء الاختبارات عليه) لتجنّب فقدان TF تتبُّعه بشكل عشوائي.
   • تحقَّق مما إذا كان الجهاز ONLINE أو OFFLINE.

3. إذا كان الجهاز:

   • OFFLINE: سيتم تبديل حالة الجهاز إلى CONNECTED_OFFLINE Tradefed، وهي حالة لا تسمح للجهاز بإجراء الاختبارات بعد. إذا كان الجهاز متصلاً بالإنترنت لاحقًا، سيخضع لدورة ONLINE. إذا تلقّينا حدثًا بعنوان deviceDisconnect، ستتم إزالة الجهاز من القائمة.

   • ONLINE (كما يظهر من خلال adb): سيتم ضبط الجهاز على الحالة CONNECTED_ONLINE وسيتم التحقّق من مدى توفّر الجهاز لرصد تخصيص الاختبار: checking_availability.

4. إذا تم فحص "availability" بنجاح، سيتم وضع علامة على الجهاز بأنّه متاح لتخصيص الاختبار، وسيتمكّن من إجراء الاختبارات. وفي حال عدم إجراء ذلك، سيتم وضع علامة unavailable على الجهاز لتخصيصه ولن يتمكّن من إجراء أي اختبارات.

تظهر كل هذه الحالات في وحدة تحكم Tradefed عند إدراج الأجهزة من خلال: tf> list devices

تجدر الإشارة إلى أنّه عند تخصيص الجهاز حاليًا لإجراء اختبار، لن يحدث معظم ما سبق، وسيحدِّد Tradefed حالة الجهاز داخليًا. وبالتالي، من الممكن أن يختفي جهاز من adb devices مع أنّه لا يزال مُدرَجًا في Tradefed. ويمكن أن يحدث ذلك عندما يعيد الاختبار تشغيل الجهاز، على سبيل المثال.

جهاز افتراضي متصل باستخدام adb connect

عند إنشاء جهاز افتراضي بعيد، يتصل تطبيق Tradefed به باستخدام adb connect. سيؤدي ذلك عادةً إلى ظهور الجهاز في adb devices على أنّه <some ip>:<port number> وسيتّبع التسلسل نفسه للأجهزة التي يتم ربطها جسديًا.

تتبُّع الجهاز عند وقوع حدث deviceConnected

عند حدوث deviceConnected، ينشئ ddmlib مرجعًا جديدًا IDevice لتتبُّع الجهاز الذي تم ربطه حديثًا.

يستخدم Tradefed هذا المرجع ويغلفه في تنفيذه الخاص لواجهة الجهاز ITestDevice لتوفير خدمة أكثر تقدمًا. ولكن جهاز IDevice الأساسي هو دائمًا الجهاز الذي يأتي من ddmlib.

وهذا يعني أنّه في حال ربط جهاز جديد، يتم إنشاء عنصر ITestDevice جديد وربطه بعنصر IDevice. وعندما يحدث ذلك أثناء الاستدعاء وأثناء استخدام ITestDevice، لا يزال يتم استبدال IDevice الأساسي بحيث يمكن متابعة الاختبار إلى المرجع الصحيح. ويتم ذلك بسلاسة في كل مرة يتم فيها فصل/إعادة توصيل أحد الأجهزة (على سبيل المثال، أثناء إعادة التشغيل).