Fastboot

Important

Make sure you have read Adding new device types first.

Fastboot devices can be simple to integrate but fastboot deployment has several issues which can cause issues in automation.

See also

Deploying LXC devices and Deploying test images using LXC

  1. The fastboot protocol runs from the worker and pushes files to the device. This causes issues with Scalability compared to deployment methods which allow the DUT to pull files over a network connection.

    • As a guideline, ensure that each worker has one CPU core for each fastboot device plus at least one more core for the rest of the system to avoid excessive load on the worker.

  2. Different fastboot devices can need different versions of fastboot to be installed on the worker, so LAVA uses LXC to isolate all fastboot operations on the worker.

  3. Each fastboot process tries to collect all of the fastboot devices which are visible in dev/bus/usb. When fastboot is pushing files to one device, a second fastboot process would not be able to connect to a different device on the same worker. This is the second reason why LAVA uses :term`LXC` with fastboot as LAVA can then ensure that the only device node(s) which show up in /dev inside the LXC are the nodes specifically related to a single fastboot device.

  4. Fastboot relies on every DUT having a unique fastboot serial number which must persist across reboots and test jobs. The fastboot serial number can be the same as the ADB serial number. The fastboot serial number must modifiable by the admin in case an existing device is already using that number.

  5. For automation to work, all fastboot devices must boot into fastboot mode automatically after every hard reset or soft reboot.

  6. The device needs to implement the fastboot boot <boot img> command, so that the test image can be loaded directly into memory and executed.

External constraints

In addition, integrating fastboot devices has some limitations on how the test images are prepared.

Device changes

The DUT should be roooted or unlocked wherever applicable (mostly phones, tabs, etc.) fastboot oem unlock or fastboot flash unlock

Images

No special mangling of supplied images are required, ie., LAVA will not do any magic on the images, except for decompressing images (based on already supported decompression methods) if they are in compressed state.

See also

Android.

Android

LAVA relies on ADB and fastboot to control an Android device. Support for ADB must be enabled in every image running on the device or LAVA will lose the ability to access, reboot or deploy to the device:

ro.secure=0
ro.debuggable=1
ro.adb.secure=0
persist.service.adb.enable=1

These settings enable USB debugging on the DUT and allow the DUT to trust the worker by default.

Specific support for fastboot devices in LAVA

See also

Commands and Other parameters

fastboot sequence or fastboot boot sequence - This is provided as a list within the device dictionary and can take the following values, which are actions that will get added as sub actions to the boot action pipeline:

boot

fastboot boot boot.img where boot.img is supplied via the deploy action

reboot

fastboot reboot which will reboot the DUT to the operating system

auto-login

auto login action

shell-session

wait for a shell session

export-env

export environment as defined for the DUT