رصد الأجهزة في 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. وعندما يحدث ذلك أثناء طلب برمجي واستخدام IDETestDevice، سيظلّ الجهاز الأساسي IDevice مثبّتًا كي تتمكّن من مواصلة الاختبار بالاستناد إلى المرجع المناسب. ويتم ذلك بسلاسة في كل مرة يتم فيها فصل أحد الأجهزة أو إعادة توصيله (على سبيل المثال، أثناء إعادة التشغيل).