Working with Devices
Working with Devices
Trade Federation uses an abstraction called ITestDevice
to run tests. This abstraction objectifies the lowest-common-denominator Android device:
- It has a serial number
- It has a state: Online, Available, Recovery, or Not Available
- 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.
Different Classes of Devices
The three primary implementations of ITestDevice
represent three common usecases.
Physical Device
This is an actual piece of hardware, connected to the TF host machine either by USB, or by using adb's TCP feature. The TestDevice class sits atop the ddmlib library, which is a Java interface to adb. So any physical device listed in adb devices
can be instantiated and used as a TestDevice
.
Emulator
Emulators are handled specially by TF because they live in another process. To interact with an Emulator, specify the --emulator
argument for the command. See LocalSdkBuildProvider and SdkAvdPreparer for more info.
No Device
Suppose you have a test that doesn't interact with a device at all. For instance, it might just download a file from some service and verify that the file itself is valid. The NullDevice is an ITestDevice
that is just a stub. It has a serial number like null-device-N
, and most attempted operations either no-op silently or throw.
本文来自博客园,作者:dolinux,未经同意,禁止转载