| Bruce Gay | 39229d4 | 2010-06-25 10:02:12 -0700 | [diff] [blame] | 1 | Overview: |
| 2 | |
| 3 | The labpretest.sh script is designed to emulate a typical automated test lab |
| 4 | session. It puts a device into bootloader mode, reboots into bootloader mode, |
| 5 | determines device type, erases user cache, flashes a generic userdata image, |
| 6 | updates the bootloader image, updates the radio image, updates the system image |
| 7 | and reboots, sets up for a monkey run and finally runs a random monkey test. |
| 8 | It will repeat this based on an optional parameter(-i) or default to 100 times. |
| 9 | It will detect if it is in a low battery situation and wait for it to charge |
| 10 | again. |
| 11 | |
| 12 | The goal is to see if a device is ready for deployment to automated lab testing |
| 13 | and can also be used to verify that lab infrastructure is ready for devices. |
| 14 | The idea is to run this script at the same time for multiple devices, typically |
| 15 | I would connect 8 devices to a host and run this script in 8 separate shell |
| 16 | sessions and watch for failures. |
| 17 | |
| 18 | Running the script: |
| 19 | |
| 20 | If there is only one device attached to the host you can simply just run the |
| 21 | script, it will detect the device and go through 100 cycles, running the monkey |
| 22 | for 200 events each cycle. The script ignores normal monkey failures. If you |
| 23 | have multiple devices attached use the -d <device_id> parameter to target a |
| 24 | specific devices. Additional parameters are -i for how many cycles and -m for |
| 25 | how many monkey events and finally -x to make it skip the monkey run portion |
| 26 | altogether. |
| 27 | |
| 28 | Adding support for new devices or from scratch: |
| 29 | |
| 30 | The script uses included copies of adb and fastboot which are in in the tools/ |
| 31 | sub directory. If you are setting this up with only the script, create a tools |
| 32 | sub directory and put adb and fastboot in it and make sure they are executable. |
| 33 | Currently we use userdebug builds. |
| 34 | |
| 35 | Here are the steps to add a new device: |
| 36 | |
| 37 | 1) Create a new sub directory using the result of "fastboot getvar product". |
| 38 | 2) Copy a build image to the new sub directory in our format. |
| 39 | (i.e. passion-img-24827.zip) |
| 40 | 3) Copy a boot image to the new sub directory in our format. |
| 41 | (i.e. hboot.0.33.2012.img) |
| 42 | 4) Copy a radio image to the new sub directory in our format. |
| 43 | (i.e. radio.4.04.00.03_2.img) |
| 44 | 5) Copy a userdata.img file, possibly from one of the other directories. |
| 45 | |
| 46 | Customizations to the flashing process are handled by adding a custom_flash.sh |
| 47 | file that is read in before the main loop starts. It allows you to add any non |
| 48 | generic functions or details to the flashing process. You must use it to define |
| 49 | the variable "bootpart" which is not defined by default. Also, use this file to |
| 50 | rewrite the flash_device function and any others, etc... |
| 51 | |
| 52 | The script should handle the rest, unless there are radical changes to file |
| 53 | names or the process. |