À partir du 27 mars 2025, nous vous recommandons d'utiliser android-latest-release
au lieu de aosp-main
pour créer et contribuer à AOSP. Pour en savoir plus, consultez la section Modifications apportées à AOSP.
Utiliser des appareils dans TF
Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Trade Federation utilise une abstraction appelée ITestDevice
pour exécuter des tests. Cette abstraction objective l'appareil Android le plus commun:
- Il comporte un numéro de série
- Il a un état : "En ligne", "Disponible", "Récupération" ou "Non disponible".
- Il comporte une notion de fiabilité. Par exemple, si nous exécutons une commande, nous pouvons faire la distinction entre le cas où la commande n'est pas encore terminée, le cas où l'appareil n'est pas compatible avec l'exécution de commandes et le cas où l'appareil ne répond plus lors de l'exécution de la commande.
Classes d'appareils
Les trois implémentations principales de ITestDevice
représentent trois cas d'utilisation courants.
Appareil physique
Il s'agit d'un matériel réel, connecté à la machine hôte TF via USB ou à l'aide de la fonctionnalité TCP d'adb. La classe TestDevice se trouve au-dessus de la bibliothèque ddmlib, qui est une interface Java d'adb. Par conséquent, tout appareil physique listé dans adb devices
peut être instancié et utilisé comme TestDevice
.
Émulateur
Les émulateurs sont gérés de manière spéciale par TF, car ils se trouvent dans un autre processus. Pour interagir avec un émulateur, spécifiez l'argument --emulator
pour la commande. Pour en savoir plus, consultez LocalSdkBuildProvider et SdkAvdPreparer.
Aucun appareil
Supposons que vous disposiez d'un test qui n'interagit pas du tout avec un appareil. Par exemple, il peut simplement télécharger un fichier à partir d'un service et vérifier que le fichier lui-même est valide. NullDevice est un ITestDevice
qui n'est qu'un bouchon. Il possède un numéro de série tel que null-device-N
, et la plupart des opérations tentées ne sont pas exécutées de manière silencieuse ou génèrent une exception.
Le contenu et les exemples de code de cette page sont soumis aux licences décrites dans la Licence de contenu. Java et OpenJDK sont des marques ou des marques déposées d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/07/27 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Il n'y a pas l'information dont j'ai besoin","missingTheInformationINeed","thumb-down"],["Trop compliqué/Trop d'étapes","tooComplicatedTooManySteps","thumb-down"],["Obsolète","outOfDate","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Mauvais exemple/Erreur de code","samplesCodeIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 2025/07/27 (UTC)."],[],[],null,["# Work with devices in TF\n\nTrade Federation uses an abstraction called\n[ITestDevice](/reference/com/android/tradefed/device/ITestDevice) to\nrun tests. This abstraction objectifies the lowest-common-denominator Android device:\n\n- It has a serial number\n- It has a state: Online, Available, Recovery, or Not Available\n- It has some notion of reliability. For instance, if we run a command, we can differentiate between the case where the command hasn't finished yet, the case where the device doesn't support running commands, and the case where the device has become unresponsive while running the command.\n\nDevice classes\n--------------\n\nThe three primary implementations of `ITestDevice` represent three common\nusecases.\n\n### Physical device\n\nThis is an actual piece of hardware, connected to the TF host machine either by USB, or by using\nadb's TCP feature. The [TestDevice](/reference/com/android/tradefed/device/TestDevice) class sits atop the ddmlib library, which is a Java interface to adb. So any\nphysical device listed in `adb devices` can be instantiated and used as a\n`TestDevice`.\n\n### Emulator\n\nEmulators are handled specially by TF because they live in another process. To interact with an\nEmulator, specify the `--emulator` argument for the command. See\n[LocalSdkBuildProvider](/reference/com/android/tradefed/build/LocalSdkBuildProvider) and\n[SdkAvdPreparer](/reference/com/android/tradefed/targetprep/SdkAvdPreparer) for more info.\n\n### No device\n\nSuppose you have a test that doesn't interact with a device at all. For instance, it might just\ndownload a file from some service and verify that the file itself is valid. The\n[NullDevice](/reference/com/android/tradefed/device/NullDevice) is an `ITestDevice` that is just a stub. It has a serial number like\n`null-device-N`, and most attempted operations either no-op silently or throw."]]