از 27 مارس 2025، توصیه می کنیم از android-latest-release به جای aosp-main برای ساختن و کمک به AOSP استفاده کنید. برای اطلاعات بیشتر، به تغییرات AOSP مراجعه کنید.
تشخیص دستگاه در Tradefed
با مجموعه‌ها، منظم بمانید
ذخیره و طبقه‌بندی محتوا براساس اولویت‌های شما.
اتصال دستگاه جدید باعث ایجاد یک سری رویدادهای ناهمزمان می شود که واضح نیستند اما ارزش درک آن را دارند.
از نظر فیزیکی متصل است
Tradefed از کتابخانه ddmlib (یک کتابخانه جاوا adb ) برای ارائه تعامل اولیه با adb و دستگاه ها استفاده می کند. بخشی از این راه حل رابط IDeviceChangeListener است که امکان دریافت رویدادهای جدید دستگاه مانند:
-
deviceConnected : هنگامی که یک دستگاه جدید توسط adb مشاهده می شود -
deviceDisconnected : وقتی دستگاهی دیگر به adb گزارش نمی دهد -
deviceChanged : هنگامی که یک وضعیت اصلی دستگاه رخ می دهد (مانند دستگاه آفلاین یا دستگاه آنلاین)
این رویدادها در سطح adb برای تصمیم گیری در مورد متصل بودن یا نبودن دستگاه، آنلاین یا آفلاین کافی هستند. اما برای مهار تست، به حالت قوی‌تر از این نیاز داریم تا مطمئن شویم دستگاه واقعاً برای شروع آزمایش‌ها آماده است. نباید تحت تأثیر پوسته پوسته شدن حالت بالقوه ای باشد که می تواند با یک دستگاه تازه متصل شود.
توالی رویدادها در Tradefed به این صورت است:
- دستگاه به عنوان
deviceConnected شناخته می شود و برای رویدادهای عادی از adb باز است یک رویداد داخلی Tradefed ایجاد می شود که:
- بررسی کنید که آیا دستگاه از قبل شناخته شده است. Tradefed به برخی از دستگاه‌ها (مخصوصاً دستگاه فعلی اختصاص داده شده و آزمایش‌های در حال اجرا) اشاره داخلی می‌کند تا از گم شدن تصادفی آن‌ها توسط TF جلوگیری کند.
- بررسی کنید که آیا دستگاه
ONLINE یا OFFLINE است.
اگر دستگاه:
OFFLINE : دستگاه به حالت Tradefed CONNECTED_OFFLINE تغییر می‌کند، که هنوز به دستگاه اجازه نمی‌دهد آزمایش‌ها را اجرا کند. اگر دستگاه بعدا آنلاین شود، چرخه ONLINE را طی می کند. اگر یک رویداد deviceDisconnect دریافت کنیم، دستگاه به سادگی از لیست حذف خواهد شد.
ONLINE (همانطور که توسط adb مشاهده می شود): دستگاه در حالت CONNECTED_ONLINE قرار می گیرد و در دسترس بودن آن برای تخصیص آزمایشی بررسی می شود: checking_availability .
اگر بررسی availability موفقیت آمیز باشد، دستگاه به عنوان در دسترس برای تخصیص آزمایش علامت گذاری می شود. قادر به اجرای آزمایشات خواهد بود. در غیر این صورت، دستگاه به عنوان unavailable برای تخصیص علامت گذاری می شود و نمی تواند هیچ آزمایشی را دریافت کند.
همه این حالت ها در هنگام لیست کردن دستگاه ها از طریق: tf> list devices در کنسول Tradefed منعکس می شوند.
توجه به این نکته مهم است که وقتی دستگاه در حال حاضر برای آزمایش اختصاص داده می شود، بیشتر موارد فوق رخ نمی دهد و Tradefed وضعیت دستگاه را به صورت داخلی تعیین می کند. بنابراین ممکن است یک دستگاه در حالی که هنوز توسط Tradefed لیست شده است از adb devices ناپدید شود. برای مثال زمانی که یک تست در حال راه اندازی مجدد دستگاه است، این اتفاق می افتد.
دستگاه مجازی متصل به adb connect
هنگامی که یک دستگاه مجازی راه دور ایجاد می شود، Tradefed با استفاده از adb connect به آن متصل می شود. این معمولاً باعث می‌شود که دستگاه در adb devices به‌عنوان <some ip>:<port number> نشان داده شود و همان ترتیب دستگاه‌های متصل فیزیکی را دنبال می‌کند.
ردیابی دستگاه هنگامی که یک رویداد deviceConnected رخ می دهد
هنگامی که deviceConnected رخ می دهد، ddmlib یک IDevice مرجع جدید برای ردیابی دستگاه تازه متصل ایجاد می کند.
Tradefed از آن مرجع استفاده می‌کند و آن را در پیاده‌سازی رابط دستگاه ITestDevice برای ارائه خدمات پیشرفته‌تر قرار می‌دهد. اما IDevice اساسی همیشه همانی است که از ddmlib می آید.
این بدان معناست که اگر یک دستگاه جدید متصل شود، یک ITestDevice جدید ایجاد شده و با IDevice مرتبط می شود. هنگامی که این اتفاق در طول فراخوانی رخ می دهد و ITestDevice در حال استفاده است، IDevice زیربنایی هنوز جایگزین می شود تا آزمایش بر روی مرجع مناسب ادامه یابد. هر بار که یک دستگاه قطع/وصل می شود (به عنوان مثال، در حین راه اندازی مجدد) این کار به طور یکپارچه انجام می شود.
محتوا و نمونه کدها در این صفحه مشمول پروانههای توصیفشده در پروانه محتوا هستند. جاوا و OpenJDK علامتهای تجاری یا علامتهای تجاری ثبتشده Oracle و/یا وابستههای آن هستند.
تاریخ آخرین بهروزرسانی 2025-07-29 بهوقت ساعت هماهنگ جهانی.
[[["درک آسان","easyToUnderstand","thumb-up"],["مشکلم را برطرف کرد","solvedMyProblem","thumb-up"],["غیره","otherUp","thumb-up"]],[["اطلاعاتی که نیاز دارم وجود ندارد","missingTheInformationINeed","thumb-down"],["بیشازحد پیچیده/ مراحل بسیار زیاد","tooComplicatedTooManySteps","thumb-down"],["قدیمی","outOfDate","thumb-down"],["مشکل ترجمه","translationIssue","thumb-down"],["مشکل کد / نمونهها","samplesCodeIssue","thumb-down"],["غیره","otherDown","thumb-down"]],["تاریخ آخرین بهروزرسانی 2025-07-29 بهوقت ساعت هماهنگ جهانی."],[],[],null,["# Device detection in Tradefed\n\nA new device connection triggers a series of asynchronous events that are not\nobvious yet worth understanding.\n\nPhysically connected\n--------------------\n\nTradefed uses the `ddmlib` library (a Java `adb` library) to provide the basic\ninteraction with `adb` and devices. Part of this solution is the\n[IDeviceChangeListener interface](https://android.googlesource.com/platform/tools/base/+/refs/heads/android16-release/ddmlib/src/main/java/com/android/ddmlib/AndroidDebugBridge.java)\nthat allows reception of new device events, such as:\n\n- `deviceConnected`: When a new device is seen by `adb`\n- `deviceDisconnected`: When a device is not reporting to `adb` anymore\n- `deviceChanged`: When a major device state occurs (such as device offline or device online)\n\nThese events are enough at the `adb` level to decide whether or not a device is\nconnected, online, or offline. But for the test harness, we need a stronger\nstate than this to ensure a device is truly ready to start running tests; it\nshould not be impacted by potential state flakiness that can come with a newly\nconnected device.\n\nThis is the sequence of events in Tradefed:\n\n1. Device is recognized as `deviceConnected` and open to regular events from `adb`\n2. An internal Tradefed event is created that will:\n\n - Check if the device is known already; Tradefed keeps internal reference to some devices (especially the one current allocated and running tests) to avoid TF losing track of them randomly.\n - Check if the device is `ONLINE` or `OFFLINE`.\n3. If device is:\n\n - `OFFLINE`: Device will be switched to Tradefed `CONNECTED_OFFLINE`\n state, which doesn't allow the device to run tests yet. If the device is\n online later, it will go through the `ONLINE` cycle. If we receive a\n `deviceDisconnect` event, the device will simply be removed from the list.\n\n - `ONLINE` (as seen by adb): Device will be put in the state\n `CONNECTED_ONLINE` and will have its availability checked for test\n allocation: `checking_availability`.\n\n4. If `availability` check is successful, the device will be marked as\n available for test allocation; it will be able to run tests. If not, the\n device will be marked as `unavailable` for allocation and cannot receive any\n tests.\n\nAll of these states are reflected in the Tradefed console when listing the\ndevices via: `tf\u003e list devices`\n\nIt's important to note that when the device is currently allocated for a test,\nmost of the above will not occur and Tradefed will determine the device state\ninternally. So it's possible for a device to disappear from `adb devices` while\nstill being listed by Tradefed. That can happen when a test is rebooting the\ndevice for example.\n\nVirtual device connected with adb connect\n-----------------------------------------\n\nWhen a remote virtual device is created, Tradefed connects to it using `adb\nconnect`. This will usually trigger the device showing in `adb devices` as\n`\u003csome ip\u003e:\u003cport number\u003e` and will follow the same sequence as physically\nconnected devices.\n\nDevice tracking when a deviceConnected event occurs\n---------------------------------------------------\n\nWhen `deviceConnected` occurs, `ddmlib` creates a new reference\n[IDevice](https://android.googlesource.com/platform/tools/base/+/refs/heads/android16-release/ddmlib/src/main/java/com/android/ddmlib/IDevice.java)\nto track the newly connected device.\n\nTradefed uses that reference and wraps it in its own implementation of device\ninterface\n[ITestDevice](https://android.googlesource.com/platform/tools/tradefederation/+/refs/heads/android16-release/device_build_interfaces/com/android/tradefed/device/ITestDevice.java)\nto provide more advanced service. But the underlying IDevice is always the one\ncoming from `ddmlib`.\n\nThis means if a new device is connected, a new ITestDevice is created and\nassociated with the IDevice. When this happens during an invocation and the\nITestDevice is being used, the underlying IDevice is still replaced so\ntesting can proceed on the proper reference. This is done seamlessly each time a\ndevice is disconnected/reconnected (for example, during a reboot)."]]
