AWS Device Farm: Developer Guide API Version 2015-06-23
AWS Device Farm: Developer Guide API Version 2015-06-23
Developer Guide
API Version 2015-06-23
Table of Contents
What Is AWS Device Farm? ............................................................................................................ 1
Automated App Testing ........................................................................................................... 1
Supported Test Types and Built-in Tests ............................................................................. 1
Remote Access Interaction ..................................................................................................... 2
Terminology .......................................................................................................................... 2
Setting Up ............................................................................................................................ 3
Setting Up .................................................................................................................................... 4
Step 1: Sign Up for AWS ......................................................................................................... 4
Step 2: Create or Use an IAM User in Your AWS Account ............................................................. 4
Step 3: Give the IAM User Permission to Access Device Farm ....................................................... 5
Next Step ............................................................................................................................. 6
Getting Started ............................................................................................................................. 7
Prerequisites ........................................................................................................................ 7
Step 1: Sign in to the Console .................................................................................................. 8
Step 2: Create a Project .......................................................................................................... 8
Step 3: Create and Start a Run ................................................................................................ 8
Step 4: View the Run's Results ................................................................................................ 9
Next Steps ........................................................................................................................... 9
Concepts ................................................................................................................................... 10
Devices .............................................................................................................................. 10
Supported Devices ...................................................................................................... 10
Device Pools ............................................................................................................... 10
Device Branding .......................................................................................................... 11
Device Slots ............................................................................................................... 11
Pre-Installed Device Apps ............................................................................................. 11
Device Capabilities ...................................................................................................... 11
Test Types .......................................................................................................................... 11
Android Test Types ....................................................................................................... 11
iOS Test Types ............................................................................................................ 12
Web Application Test Types ........................................................................................... 12
Runs ................................................................................................................................. 12
Run Configuration ........................................................................................................ 13
Run Files Retention ..................................................................................................... 13
Parallel Runs .............................................................................................................. 13
Instrumenting Apps ...................................................................................................... 13
Re-Signing Apps in Runs .............................................................................................. 13
Obfuscated Apps in Runs .............................................................................................. 13
Ads in Runs ................................................................................................................ 13
Media in Runs ............................................................................................................. 13
Common Tasks for Runs ............................................................................................... 14
Reports .............................................................................................................................. 14
Report Retention ......................................................................................................... 14
Report Components ..................................................................................................... 14
Performance Samples in Reports ................................................................................... 14
Logs in Reports ........................................................................................................... 14
Common Tasks for Reports ........................................................................................... 14
Sessions ............................................................................................................................ 14
Supported Devices for Remote Access ............................................................................ 15
Session Files Retention ................................................................................................ 15
Instrumenting Apps ...................................................................................................... 15
Re-Signing Apps in Sessions ......................................................................................... 15
Obfuscated Apps in Sessions ........................................................................................ 15
Purchase Device Slots .................................................................................................................. 16
Purchase a Device Slot with the Device Farm Console ............................................................... 16
Purchase a Device Slot with the AWS CLI ................................................................................ 17
API Version 2015-06-23
iii
19
20
20
20
20
21
21
21
21
22
22
22
23
23
23
24
25
25
25
25
26
26
27
28
28
29
29
29
29
29
30
30
31
31
31
31
31
31
32
32
33
33
34
35
35
38
38
38
38
38
39
39
39
39
39
44
Terminology
Device Farm introduces the following terms that define the way information is organized:
project
A logical workspace that contains runs, one run for each test of a single app against one or more
devices. Projects enable you to organize workspaces in whatever way you choose. For example,
there can be one project per app title, or there can be one project per platform. You can create as
many projects as you need.
run
A specific build of your app, with a specific set of tests, to be run on a specific set of devices. A run
produces a report that contains information about the results of the run. A run contains one or more
jobs. For more information, see Runs (p. 12).
report
Contains information about a run, which is a request for Device Farm to test a single app against
one or more devices. For more information, see Reports (p. 14).
job
A request for Device Farm to test a single app against a single device. A job contains one or more
suites.
meter
Metering refers to billing for devices, and you may encounter references to "metered devices" or
"unmetered devices" in the documentation and API reference. For more information about pricing,
see AWS Device Farm Pricing.
suite
The hierarchical organization of tests in a test package. A suite contains one or more tests.
test
An individual test within a test package.
session
An interactive session with a single device in the console.
Setting Up
To get set up to use Device Farm, see Setting Up (p. 4).
Note
The AWS root account or IAM user that you use to complete the following steps must have
permission to create the following IAM policy and attach it to the IAM user. For more information,
see Working with Policies
4.
5.
6.
For Description, type Provides access to all Device Farm actions associated with
the IAM user.
7.
8.
4.
5.
6.
Note
Attaching the policy provides the IAM user with access to all Device Farm actions associated
with that IAM user. To learn how to restrict IAM users to a limited set of Device Farm actions,
see Access Permissions Reference (p. 95).
Next Step
You are now ready to start using Device Farm. See Getting Started (p. 7).
Prerequisites
Before you begin this walkthrough, make sure you have completed the following requirements:
Complete the steps in Setting Up (p. 4), which include signing up for an AWS account, creating or
using an IAM user in the AWS account, and giving the IAM user permission to access Device Farm.
For Android, you will need an .apk (Android app package) file, and for iOS you will need an .ipa (iOS
app archive) file, which you will upload to Device Farm later in this walkthrough.
Note
Make sure that your .ipa file is built for an iOS device and not for a simulator.
Optionally, you will need a test from one of the test types supported by Device Farm. You will upload
this test package to Device Farm, and then run the test later in this walkthrough. (If you do not have a
test package available, you can specify and run a standard built-in test suite.) For more information,
see Working with Test Types in AWS Device Farm (p. 38).
Note
If you type a project name other than MyDemoProject, be sure to use it throughout this
walkthrough.
3.
Choose MyDemoProject.
On the Choose your application page, choose Upload.
Browse to and choose your Android or iOS app file. For Android, the file must be an .apk file. For
iOS, the file must be an .ipa file built for a device, not the simulator.
Choose Next step.
5.
Note
If you do not have any tests available, choose Built-in: Fuzz to run a standard built-in test
suite. For this walkthrough, if you choose Built-in: Fuzz, leave the Event count, Event
throttle, and Randomizer seed boxes at their default values.
6.
7.
8.
If you did not choose Built-in: Fuzz, then choose Upload, and browse to and choose the file that
contains your tests.
Choose Next step.
On the Select devices page, for Device pool, choose Top Devices to select the device pool, and
then choose Next step.
A device pool in Device Farm represents a collection of devices that typically share similar
characteristics such as platform, manufacturer, or model. For more information, see Devices (p. 10).
9.
Next Steps
To learn more about Device Farm, see Concepts (p. 10).
Supported Devices
Device Farm provides support for hundreds of unique, popular Android, iOS, and Fire OS devices and
operating system combinations. The list of available devices grows as new devices enter the market. The
full list of devices can be found here: Device List.
Device Pools
Device Farm organizes its devices into device pools that you can use for your testing. These device pools
contain related devices, such as devices that run only on Android or that run only on iOS. Device Farm
provides curated device pools, such as those for top devices.You can also create your own private device
pools.
Device Branding
Device Farm runs tests on physical, non-rooted devices that are both OEM- and carrier-branded.
Device Slots
Device slots correspond to concurrency in which the number of device slots you have determines how
many devices you can run in tests or remote access sessions. There are two types of device slots, remote
access device slots and automated testing device slots. An automated testing device slot is one on which
you can run tests concurrently. A remote access device slot is one you can run in remote access sessions
concurrently.
If you have one automated testing device slot, then you can only run tests on one device at a time. If you
purchase additional automated testing device slots, then you can run multiple tests concurrently on multiple
devices to get test results faster. If you have one remote access device slot, you can only run one remote
access session at a time. If you purchase additional remote testing device slots, then you can run multiple
sessions concurrently.
You can purchase device slots based on the device family (Android or iOS devices for automated testing
and Android for remote access). For more information, see Device Farm Pricing.
Device Capabilities
All devices have a Wi-Fi connection to the Internet. They do not have carrier connections and cannot
make phone calls or send SMS messages.
You can take photos with any device that supports a front- or rear-facing camera. Due to the way the
devices are mounted, photos may look dark and blurry.
Google Play Services is installed on devices that support it, but these devices do not have an active
Google account.
Run Configuration
As part of a run, you can supply settings Device Farm can use to override current device settings. These
include latitude and longitude coordinates, locale, radio states (such as Bluetooth, GPS, NFC, and Wi-Fi),
extra data (contained in a .zip file), and auxiliary apps (apps that should be installed before the app that
will be tested).
Parallel Runs
Device Farm runs tests in parallel as devices become available.
Instrumenting Apps
You do not need to instrument your apps or provide Device Farm with the source code for your apps.
Android apps can be submitted unmodified. iOS apps must be built with the iOS Device target instead
of with the simulator.
Ads in Runs
We recommend that you remove ads from your apps before you upload them to Device Farm. We cannot
guarantee that ads will be displayed during runs.
Media in Runs
You can provide media or other data to accompany your app. Additional data must be provided in a .zip
file no more than 4 GB in size.
API Version 2015-06-23
13
Report Retention
Device Farm stores your reports for 400 days. These reports include metadata, logs, screenshots, and
performance data.
Report Components
Reports in Device Farm contain pass and fail information, crash reports, test and device logs, screenshots,
and performance data.
Reports include both detailed per-device data as well as high-level results, such as the number of
occurrences of a given problem.
Logs in Reports
Reports include complete logcat captures for Android tests and complete Device Console Logs for iOS
tests.
by step through the customer's issue. Developers can reproduce a problem on a specific device to isolate
possible sources of the problem. You can use remote sessions to conduct usability tests with your target
customers.
A session in Device Farm is a real-time interaction with an actual, physical device hosted in a web browser.
Topics
Supported Devices for Remote Access (p. 15)
Session Files Retention (p. 15)
Instrumenting Apps (p. 15)
Re-Signing Apps in Sessions (p. 15)
Obfuscated Apps in Sessions (p. 15)
Instrumenting Apps
You do not need to instrument your apps or provide Device Farm with the source code for your apps.
Android apps can be submitted unmodified.
Note
To use the device slots feature, you need to be on a metered test plan that allows for unlimited
testing.
Topics
Purchase a Device Slot with the Device Farm Console (p. 16)
Purchase a Device Slot with the AWS CLI (p. 17)
Purchase a Device Slot with the Device Farm API (p. 19)
Note
If you are currently viewing a project or a Run result, you can also access the Project
settings page by choosing the Project settings icon in the upper right-hand corner. The
screen and options look the same.
3.
4.
On the Account settings page (or the Project settings page), choose the number of automated
testing Android slots, automated testing iOS slots, or remote access Android slots you wish to
purchase.
The text dynamically updates with the amount that will be added to your bill for each device slot
purchased. For more information, see Device Farm Pricing.
Choose Purchase.
The next time you create a test run (p. 23), you can have multiple devices running tests concurrently
or multiple remote access sessions running concurrently, based on the number of device slots
purchased.
To get the offering status, run the get-offering-status command. You will see output similar to the
following:
{
"current": {
"GUID": {
"offering": {
"platform": "IOS",
"type": "RECURRING",
"id": "GUID",
"description": "iOS Unmetered Device Slot"
},
"quantity": 1
},
"GUID": {
"offering": {
"platform": "ANDROID",
"type": "RECURRING",
"id": "GUID",
"description": "Android Unmetered Device Slot"
},
"quantity": 1
}
},
"nextPeriod": {
"GUID": {
"effectiveOn": 1459468800.0,
"offering": {
"platform": "IOS",
"type": "RECURRING",
"id": "GUID",
"description": "iOS Unmetered Device Slot"
},
"quantity": 1
},
"8980F81C-00D7-469D-8EC6-BCE39477F2F6": {
"effectiveOn": 1459468800.0,
"offering": {
"platform": "ANDROID",
"type": "RECURRING",
"id": "GUID",
"description": "Android Unmetered Device Slot"
},
"quantity": 1
}
}
}
For information about using the Device Farm API, see API Reference (p. 94).
Prerequisites
Complete the steps in Setting Up (p. 4), which include signing up for an AWS account, creating or
using an IAM user in the AWS account, and giving the IAM user permission to access Device Farm.
Make sure you have set up an AWS account and an IAM user to access Device Farm.
Sign in to the Device Farm console at https://console.aws.amazon.com/devicefarm.
3.
Tip
If neither Create a new project nor Get started is displayed, then do one of the following:
On the secondary navigation bar, choose the Device Farm console home button, and
then choose Create a new project.
On the secondary navigation bar, for Projects, choose View all projects, and then choose
Create a new project.
4.
5.
Make sure you have set up an AWS account and an IAM user to access Device Farm.
Run the create-project command.
Note
For information about using Device Farm with the AWS CLI, see AWS CLI Reference (p. 93).
Make sure you have set up an AWS account and an IAM user to access Device Farm.
Call the CreateProject API.
For information about using the Device Farm API, see API Reference (p. 94).
Prerequisites
Create at least one project in Device Farm. To create a project, follow the instructions in Create a
Project (p. 20), and then return to this page.
3.
If the list of available projects is not displayed, then on the secondary navigation bar, do one of the
following:
Choose the Device Farm console home button.
For Projects, choose View all projects.
Tip
To view information about a single project, run the get-project command.
Note
For information about using Device Farm with the AWS CLI, see AWS CLI Reference (p. 93).
Tip
To view information about a single project, call the GetProject API.
For information about the Device Farm API, see API Reference (p. 94).
Prerequisites
Create a project in Device Farm. Follow the instructions in Create a Project (p. 20), and then return
to this page.
2.
3.
If you see the AWS Device Farm console home page, choose Get started.
If you already have a project, you can upload your tests to an existing project or choose Create a
new project.
4.
5.
6.
7.
Note
If you do not have any tests available, then choose Built-in: Fuzz to run a standard test
suite that is built-in to Device Farm. If you choose Built-in: Fuzz, and the Event count,
Event throttle, and Randomizer seed boxes appear, you can change or leave the values
as desired.
For information about the available test suites, see Working with Test Types in AWS Device
Farm (p. 38).
8. If you did not choose Built-in: Fuzz, then choose Upload, and browse to and choose the file that
contains your tests.
9. Choose Next step.
10. On the Select devices page, do one of the following:
To choose a built-in device pool to run the tests against, for Device pool, choose Top Devices
or All Devices.
To create your own device pool to run the tests against, follow the instructions in Create a Device
Pool (p. 29), and then return to this page.
If you created your own device pool earlier, for Device pool, choose your device pool.
For more information, see Devices (p. 10).
11. Choose Next step.
12. On the Specify device state page, do none, some, or all of the following:
To provide any additional data that Device Farm will use during the run, choose Upload next to
Add extra data, and then browse to and choose the .zip file that contains the additional data.
To install an additional app that Device Farm will use during the run, choose Upload next to Install
other apps, and then browse to and choose the .apk, or .ipa, file that contains the app. Repeat
this for any additional apps that you want to install. You can change the apps' installation order by
dragging and dropping the apps after you upload them.
To specify whether Wi-Fi, Bluetooth, GPS, or NFC will be enabled during the run, next to Set radio
states, select the appropriate boxes.
To preset the device latitude and longitude for the run, next to Device location, type the coordinates.
To preset the device locale for the run, choose the locale in Device Locale.
Note
If you need to stop the test run, see Stop a Run in AWS Device Farm (p. 25).
Note
For information about using Device Farm with the AWS CLI, see AWS CLI Reference (p. 93).
Make sure that you have created a project. For more information, see prerequisites (p. 21).
Call the ScheduleRun API.
For information about using the Device Farm API, see API Reference (p. 94).
Next Steps
You'll know the run is complete when the progress icon changes to a result icon. A report corresponding
to the run will appear as soon as tests are complete. For more information, see Reports (p. 14).
To use the report, follow the instructions in Analyze a Report (p. 31).
Prerequisites
To stop a test run, you must have a test run created and actively running. For more information, see
Create a Run (p. 23).
2.
3.
From the Device Farm console home page, choose the project where you have an active test run.
On the Run results page, choose the test run.
Your screen should look like the following image (with the in-progress icon to the left of the device
name).
4.
Important
If a test has already finished, Device Farm cannot stop it. If a test is in progress, Device
Farm will stop the test and you will see the total minutes for which you will be billed in the
Details page. In addition, you will still be billed for the total minutes that Device Farm takes
to run the Setup Suite and the Teardown Suite. For more information, see Device Farm
Pricing.
The following image shows an example Details page after a test run was successfully stopped.
To get the ARN of your run, use the list-runs command. The output will be similar to the following:
{
"runs": [
{
"status": "RUNNING",
"name": "Name of your run",
"created": 1458329687.951,
"totalJobs": 7,
"completedJobs": 5,
"deviceMinutes": {
"unmetered": 0.0,
"total": 0.0,
"metered": 0.0
},
"platform": "ANDROID_APP",
"result": "PENDING",
"billingMethod": "METERED",
"type": "BUILTIN_EXPLORER",
"arn": "Your ARN will be here",
"counters": {
"skipped": 0,
"warned": 0,
"failed": 0,
"stopped": 0,
"passed": 0,
"errored": 0,
"total": 0
}
}
]
}
Note
For information about using Device Farm with the AWS CLI, see AWS CLI Reference (p. 93).
For information about using the Device Farm API, see API Reference (p. 94).
Prerequisites
Create at least one run in Device Farm. To create a run, follow the instructions in Create a Run (p. 23),
and then return to this page.
Make sure that you complete the prerequisites (p. 29), including the creation of at least one run.
Sign in to the Device Farm console at https://console.aws.amazon.com/devicefarm.
In the list of projects, choose the project that corresponds to the runs list you want to view.
Tip
If the list of available projects is not displayed, then on the secondary navigation bar, do
one of the following:
Choose the Device Farm console home button, and then choose the project.
For Projects, choose View all projects, and then choose the project.
Make sure that you have completed the prerequisites (p. 29), including the creation of at least one
run.
To view a list of runs, run the list-runs command.
Tip
To view information about a single run, run the get-run command.
For general information about using Device Farm with the AWS CLI, see AWS CLI Reference (p. 93).
Make sure that you have completed the prerequisites (p. 29), including the creation at least one run.
2.
Tip
To view information about a single run, call the GetRun API.
For general information about the Device Farm API, see API Reference (p. 94).
Create a Device Pool with the Device Farm API (p. 31)
Prerequisites
Start by creating a run in the Device Farm console. Follow the instructions in Create a Run (p. 23).
When you get to the Select devices page in the Create a new run wizard, continue with the
instructions in this section.
Make sure you have started to create a run and stopped on the Select devices page in the Create
a new run wizard.
On the Select devices page, choose Create new device pool.
For Name, type a name that will make this device pool easy to identify in the future.
4.
5.
For Description, type a description that will make this device pool easy to identify in the future.
If you want to use one or more selection criteria for the devices in this device pool, do the following:
1.
2.
3.
4.
5.
6.
6.
For Operand, type or choose the value you want to specify for the Field and Operator values.
Note that if you choose Platform for Field, then the only available selections are ANDROID and
IOS. Similarly, if you choose Type for Field, then the only available selections are PHONE and
TABLET.
To add another rule, choose Add rule again.
To delete a rule, choose the X icon next to the rule you want to delete.
After you create the first rule, then in the list of devices, the box next to each device that matches
the rule will be selected. After you create additional rules or change existing rules, then in the list of
devices, the box next to each device that matches those combined rules will be selected. Devices
with selected boxes will be included in the device pool. Devices with cleared boxes will be excluded
from the device pool.
If you want to manually include or exclude individual devices, select or clear the box next to each
device.
Note
You can select or clear the boxes only if you do not have any rules specified.
7.
If you want to include or exclude all displayed devices, select or clear the box in the column header
row of the list.
Important
Although you can use the boxes in the column header row to change the list of displayed
devices, this does not mean that the remaining displayed devices will be the only ones
included or excluded. To confirm which devices will be included or excluded, be sure to
API Version 2015-06-23
30
clear the contents of all of the boxes in the column header row. Then browse the boxes to
see which devices will be included or excluded.
8.
For information about using Device Farm with the AWS CLI, see AWS CLI Reference (p. 93).
For information about using the Device Farm API, see API Reference (p. 94).
Prerequisites
Create a run in Device Farm, and verify the run is complete. Follow the instructions in Create a
Run (p. 23), and then return to this page.
Console Icons
Icon
Description
Finished, Success
Warning
Failure
Skipped
Orange square
Stopped
2.
3.
Tip
If the list of projects is not displayed, then on the secondary navigation bar, choose the
Device Farm console home button, and then choose the project.
API Version 2015-06-23
31
4.
In the list, choose the run with the finished icon (green check mark) that corresponds to the report
you want to access. The report's summary page is displayed.
To analyze the various parts of the report, follow the instructions in the following sections.
If the report's summary page is not already displayed, follow the instructions in Open a Report with
the Device Farm Console (p. 31).
2.
Near the beginning of the summary page, the total number of tests, by outcome, is displayed.
A green check mark inside of a circle is displayed next to successful tests.
3.
An orange exclamation mark inside of a triangle is displayed next to tests with warnings.
A red exclamation mark inside of a circle is displayed next to failed tests.
A red exclamation mark is displayed next to tests with errors.
A blue circle with a slash through it is displayed next to skipped tests.
An orange square is displayed next to stopped tests.
4.
The Screenshots tab displays a list of any screenshots Device Farm captured during the run, grouped
by device.
If the report's summary page is not already displayed, follow the instructions in Open a Report with
the Device Farm Console (p. 31).
2.
Following the total number of tests by outcome for the run, on the Details tab, for Unique problems,
choose the problem that you want to analyze.
The Details tab displays information about the problem. The Logs section displays any information
Device Farm logged during the test. To analyze this information, follow the instructions in Analyze
Log Information for a Problem, Device, Suite, or Test in a Report with the Device Farm Console (p. 35).
3.
4.
5.
The Screenshots tab displays a list of any screenshots Device Farm captured during the test.
The Performance tab displays information about any performance data Device Farm generated
during the test. To analyze this performance data, follow the instructions in Analyze Performance
Data for a Problem, Device, Suite, or Test in a Report with the Device Farm Console (p. 35).
If the report's summary page is not already displayed, follow the instructions in Open a Report with
the Device Farm Console (p. 31).
2.
3.
On the Details tab, choose the device whose results you want to analyze.
The Details tab displays information about the suites for the device. For each suite, the following
test results are displayed:
For Test Results, the total number of tests for the suite is displayed by outcome.
Next to the suite's name, one of the following icons is displayed:
An orange square is displayed if there is at least one stopped test for the suite.
A red exclamation mark is displayed if there is at least one test with errors for the suite.
A red exclamation mark inside of a circle is displayed if there is at least one failed test for the
suite.
An orange exclamation mark inside of a triangle is displayed if there is at least one test for the
suite with warnings.
Otherwise, a green check mark inside of a circle is displayed.
To analyze the results by suite, follow the instructions in Analyze a Report by Suite with the Device
Farm Console (p. 33).
4.
5.
6.
The Logs section displays any information Device Farm logged for the device during the run. To
analyze this information, follow the instructions in Analyze Log Information for a Problem, Device,
Suite, or Test in a Report with the Device Farm Console (p. 35).
The Screenshots tab displays a list of any screenshots Device Farm captured during the run for the
device, grouped by suite.
The Performance tab displays information about any performance data Device Farm generated for
the device during the run. To analyze this performance data, follow the instructions in Analyze
Performance Data for a Problem, Device, Suite, or Test in a Report with the Device Farm
Console (p. 35).
The Files tab displays a list of suites for the device and any associated files (such as log files) that
can be downloaded. To download a file, choose the file's link in the list.
If the report's summary page is not already displayed, follow the instructions in Open a Report with
the Device Farm Console (p. 31).
2.
On the Details tab, choose the device that corresponds to the suite whose results you want to
analyze.
Choose the suite that you want to analyze for results.
3.
4.
The Details tab displays information about the tests for the suite. For each test, the following test
results are displayed:
API Version 2015-06-23
33
For Test Results, the outcome for the test is displayed as follows:
If the test succeeded, the number 1 is displayed next to a green check mark inside of a circle.
If the test has warnings, the number 1 is displayed next to an orange exclamation mark inside
of a triangle.
If the test was skipped, the number 1 is displayed next to a blue circle with a slash through it.
If the test failed, the number 1 is displayed next to a red exclamation mark inside of a circle.
If the test has errors, the number 1 is displayed next to a red exclamation mark.
If the test was stopped, the number 1 is displayed next to an orange square.
These icons are also displayed next to the test's name.
To analyze the results by test, follow the instructions in Analyze a Report by Test with the Device
Farm Console (p. 34).
5.
6.
7.
The Logs section displays any information Device Farm logged during the run for the suite. To
analyze this information, follow the instructions in Analyze Log Information for a Problem, Device,
Suite, or Test in a Report with the Device Farm Console (p. 35).
The Screenshots tab displays a list of any screenshots Device Farm captured during the run for the
suite, grouped by test.
The Performance tab displays information about any performance data Device Farm generated
during the run for the suite. To analyze this performance data, follow the instructions in Analyze
Performance Data for a Problem, Device, Suite, or Test in a Report with the Device Farm
Console (p. 35).
The Files tab displays a list of tests for the suite and any associated files (such as log files) that can
be downloaded. To download a file, choose the file's link in the list.
If the report's summary page is not already displayed, open the report by following the instructions
in Open a Report with the Device Farm Console (p. 31).
On the Details tab, choose the device that corresponds to the test you want to analyze for results.
Choose the suite that corresponds to the test you want to analyze for results.
On the Details tab, choose the test whose results you want to analyze.
5.
6.
7.
The Logs section displays any information Device Farm logged during the test. To analyze this
information, follow the instructions in Analyze Log Information for a Problem, Device, Suite, or Test
in a Report with the Device Farm Console (p. 35).
The Screenshots tab displays a list of any screenshots Device Farm captured during the test.
The Performance tab displays information about any performance data Device Farm generated
during the test. To analyze this performance data, follow the instructions in Analyze Performance
Data for a Problem, Device, Suite, or Test in a Report with the Device Farm Console (p. 35).
8.
The Files tab displays a list of any of the test's associated files (such as log files) that can be
downloaded. To download a file, choose the file's link in the list.
2.
3.
To display information for a specific data point, pause in the desired graph at the desired second
along the horizontal axis.
2.
3.
each choice. For example, to show log entries with a Message value that contains either started
or starting, type *start(ed|ing)* in the Message column header box. Similarly, to show all
log entries with a Log value of Info or Debug, type *(Info|Debug)* in the Log column header
box.
To remove all of the characters from a column header box, choose the X in that column header
box. Removing all of the characters from a column header box is the same as typing * in that
column header box.
4.
To download all of the log information for the device, including all of the suites and tests that were
run, choose Download logs.
Note
Even if you display only a portion of the information, if you choose Download logs, all log
information for the device will be downloaded.
Version Information
Currently, Device Farm supports Appium version 1.4.16 and Java version Java 8.
2.
Modify pom.xml to use maven-jar-plugin to build your tests into a JAR file.
The following plugin will build your test source code (anything in the src/test directory) into a JAR
file:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>2.6</version>
<executions>
<execution>
<goals>
<goal>test-jar</goal>
</goals>
</execution>
</executions>
</plugin>
3.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<version>2.10</version>
<executions>
<execution>
<id>copy-dependencies</id>
<phase>package</phase>
<goals>
<goal>copy-dependencies</goal>
</goals>
<configuration>
<outputDirectory>${project.build.directory}/dependency-jars/</out
putDirectory>
</configuration>
</execution>
</executions>
</plugin>
4.
5.
Modify pom.xml to use maven-assembly-plugin to package tests and all dependencies into a
single .zip file.
The following plugin uses the preceding assembly to create a .zip file named
zip-with-dependencies in the build output directory every time mvn package is run:
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<version>2.5.4</version>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>single</goal>
</goals>
<configuration>
<finalName>zip-with-dependencies</finalName>
<appendAssemblyId>false</appendAssemblyId>
<descriptors>
<descriptor>src/main/assembly/zip.xml</descriptor>
</descriptors>
</configuration>
</execution>
</executions>
</plugin>
6.
7.
Tip
If you receive an error saying that annotation is not supported in 1.3, add the following to pom.xml:
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<source>1.7</source>
<target>1.7</target>
</configuration>
</plugin>
Tip
If the list of projects is not displayed, then on the secondary navigation bar, for Projects,
choose the name of the project where you want to upload your tests.
To create a new project, follow the instructions in Create a Project (p. 20).
3.
4.
5.
6.
7.
8.
Browse to and choose the .zip file that contains your tests. The .zip file must follow the format
described in Prepare Your Android Appium Java JUnit Tests (p. 40).
Choose Next step, and then complete the remaining on-screen instructions to select devices and
start the run.
9.
Version Information
Currently, Device Farm supports Appium version 1.4.16 and Java version Java 8.
2.
Modify pom.xml to use maven-jar-plugin to build your tests into a JAR file.
The following plugin will build your test source code (anything in the src/test directory) into a JAR
file:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>2.6</version>
<executions>
<execution>
<goals>
<goal>test-jar</goal>
</goals>
</execution>
</executions>
</plugin>
3.
4.
<include>*.jar</include>
</includes>
</fileSet>
<fileSet>
<directory>${project.build.directory}</directory>
<outputDirectory>./</outputDirectory>
<includes>
<include>/dependency-jars/</include>
</includes>
</fileSet>
</fileSets>
</assembly>
5.
Modify pom.xml to use maven-assembly-plugin to package tests and all dependencies into a
single .zip file.
The following plugin uses the preceding assembly to create a .zip file named
zip-with-dependencies in the build output directory every time mvn package is run:
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<version>2.5.4</version>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>single</goal>
</goals>
<configuration>
<finalName>zip-with-dependencies</finalName>
<appendAssemblyId>false</appendAssemblyId>
<descriptors>
<descriptor>src/main/assembly/zip.xml</descriptor>
</descriptors>
</configuration>
</execution>
</executions>
</plugin>
6.
| log4j-1.2.14.jar
| (and so on...)
7.
Tip
If you receive an error saying that annotation is not supported in 1.3, add the following to pom.xml:
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<source>1.7</source>
<target>1.7</target>
</configuration>
</plugin>
Tip
If the list of projects is not displayed, then on the secondary navigation bar, for Projects,
choose the name of the project where you want to upload your tests.
To create a new project, follow the instructions in Create a Project (p. 20).
3.
4.
5.
6.
7.
8.
9.
Choose Next step, and then complete the remaining on-screen instructions to select devices and
start the run.
Version Information
Currently, Device Farm supports Appium version 1.4.16 and Python version 2.7.6 (pip version 1.5.4).
Note
The instructions below are based on Linux x86_64 and Mac. In the currently supported scheme,
Device Farm requires that the packaging of your Appium Python tests be done on Linux x86_64
if your tests contain non-universal Python wheels dependencies. For the platform on which you
execute a command, the wheels tools gather your .whl dependent files under the wheelhouse/
API Version 2015-06-23
48
folder. When you execute the Python wheel command on any platform other than Linux x86_64,
you would gather the flavor of a non-univesral wheel dependency for that particular platform and
may cause undesired effects. This would most likely lead to errors when executing your tests
on Device Farm.
1.
We strongly recommend that you set up Python virtualenv for developing and packaging tests so
that unnecessary dependencies are not included in your app package.
Tip
Do not create a Python virtualenv with the --system-site-packages option, because
it will inherit packages from /usr/lib/pythonx.x/site-packages or wherever your global
site-packages directory is. This can lead to you including dependencies in your virtual
environment that are not needed by your tests.
You should also verify that your tests do not use dependencies that are dependent on
native libraries, as these native libraries may or may not be present on the instance where
these tests run.
2.
3.
virtualenv workspace
cd workspace
source bin/activate
pip install pytest
Store all Python test scripts under the tests/ folder in your work space.
workspace
tests/ (your tests go here)
4.
Make sure you have py.test installed in your virtual environment and test cases are discoverable by
the following command, which you should run from your virtual environment workspace folder.
$ py.test --collect-only tests/
5.
Make sure the output of py.test command shows you the tests that you want to execute on Device
Farm.
Go to your work space and run the following command to generate the requirements.txt file:
$ pip freeze > requirements.txt
6.
Go to your work space and run the following command to generate the wheelhouse/ folder:
$ pip wheel --wheel-dir wheelhouse -r requirements.txt
7.
You can use the following commands to clean all cached files under your tests/ folder:
$
$
$
$
8.
find
find
find
find
.
.
.
.
-name
-name
-name
-name
'__pycache__'
'*.pyc' -exec
'*.pyo' -exec
'*~' -exec rm
-type
rm -f
rm -f
-f {}
d -exec rm -r {} +
{} +
{} +
+
Zip the tests/ folder, wheelhouse/ folder, and the requirements.txt file into a single archive:
$ zip -r test_bundle.zip tests/ wheelhouse/ requirements.txt
Tip
If the list of projects is not displayed, then on the secondary navigation bar, for Projects,
choose the name of the project where you want to upload your tests.
To create a project, follow the instructions in Create a Project (p. 20).
4.
5.
6.
7.
Tip
Give the run a name that will help you identify a specific build of your app (for example,
Beta-0.1). For more information, see Working with Runs (p. 23).
8. Choose Appium Python to configure your test,
9. To add your Appium test scripts to the test run, choose Upload.
10. Choose Next step, and then complete the instructions to select devices and start the run.
What Is Calabash?
Calabash is a mobile testing framework that enables automated user interface acceptance tests written
in Cucumber to be run on Android apps. For more information, see the Welcome to Calabash for Android
repository on GitHub.
Note
AWS Device Farm currently works with Calabash version 0.5.8.
Version Information
Currently, Device Farm supports Calabash version 0.5.8.
Tip
If the list of projects is not displayed, then on the secondary navigation bar, for Projects,
choose the name of the project where you want to upload your tests.
To create a new project, follow the instructions in Create a Project (p. 20).
3.
4.
5.
6.
7.
8.
On the Configure a test page, choose Calabash, and then choose Upload.
Browse to and choose the .zip file that contains your tests. The .zip file must follow the format
described in Prepare Your Android Calabash Tests (p. 52).
Choose Next step, and then complete the remaining on-screen instructions to select devices and
start the run.
9.
Android Calabash provides a set of predefined steps for taking screenshots. For details, see the
"Screenshots" section of the Canned steps page in the Calabash Android repository on GitHub.
Alternatively, you can define a custom step inside of a Ruby (.rb) file to call the screenshot_embed
function, which creates a screenshot and saves it to a directory you define. For example, the following
code example creates a screenshot and saves it to the /my/custom/path directory with a file name of
screenshot_seconds-since-Epoch:
screenshot_embed(:prefix => "/my/custom/path", :name => "screen
shot_#{Time.now.to_i}")
What Is Instrumentation?
Android instrumentation enables you to invoke callback methods in your test code. This allows you to run
through the lifecycle of a component step by step, as if you were debugging the component. For more
information, see Instrumentation in the Testing Fundamentals section of the Android Developer Tools
documentation.
Tip
If the list of projects is not displayed, then on the secondary navigation bar, for Projects,
choose the name of the project where you want to upload your tests.
To create a new project, follow the instructions in Create a Project (p. 20).
3.
4.
5.
6.
Browse to and choose your Android app file. The file must be an .apk file.
Choose Next step.
7.
8.
9.
On the Configure a test page, choose Instrumentation, and then choose Upload.
Browse to and choose the .apk file that contains your tests.
Choose Next step, and then complete the remaining on-screen instructions to select devices and
start the run.
During a test run, Device Farm automatically gets screenshots from the following locations on the devices,
if they exist, and then adds them to the test reports:
/sdcard/robotium-screenshots
/sdcard/test-screenshots
/sdcard/Download/spoon-screenshots/test-class-name/test-method-name
/data/data/application-package-name/app_spoon-screenshots/test-class-name/test-method-name
Note
This framework is currently in preview and may not work with all scripts and apps.
Topics
What Is UI Automator? (p. 55)
What Is UI Automator?
The UI Automator testing framework provides a set of APIs to build user interface tests that perform
interactions on user and system apps for Android. The UI Automator APIs allow you to perform operations
such as opening the Settings menu or the app launcher in a test device. For more information, see UI
Automator in the Testing Support Library section of the Android Developer Tools documentation.
Tip
If the list of projects is not displayed, then on the secondary navigation bar, for Projects,
choose the name of the project where you want to upload your tests.
To create a new project, follow the instructions in Create a Project (p. 20).
3.
4.
5.
6.
7.
8.
9.
Note
All screenshots must be stored in the /sdcard/uiautomator-screenshots directory. You
must specify the full path (including the file name) of the screenshot to be stored.
The takeScreenshot method works for API Levels 17 and higher only. For API Level 16, UI
Automator is supported, but screenshots are not supported.
Version Information
Currently, Device Farm supports Appium version 1.4.16 (1.3.6 for iOS 6-7) and Java version Java 8.
2.
Modify pom.xml to use maven-jar-plugin to build your tests into a JAR file.
The following plugin will build your test source code (anything in the src/test directory) into a JAR
file:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>2.6</version>
<executions>
<execution>
<goals>
<goal>test-jar</goal>
</goals>
</execution>
</executions>
</plugin>
3.
</execution>
</executions>
</plugin>
4.
5.
Modify pom.xml to use maven-assembly-plugin to package tests and all dependencies into a
single .zip file.
The following plugin uses the preceding assembly to create a .zip file named
zip-with-dependencies in the build output directory every time mvn package is run:
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<version>2.5.4</version>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>single</goal>
</goals>
<configuration>
<finalName>zip-with-dependencies</finalName>
<appendAssemblyId>false</appendAssemblyId>
<descriptors>
<descriptor>src/main/assembly/zip.xml</descriptor>
</descriptors>
</configuration>
</execution>
</executions>
</plugin>
6.
7.
Tip
If you receive an error saying that annotation is not supported in 1.3, add the following to pom.xml:
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<source>1.7</source>
<target>1.7</target>
</configuration>
</plugin>
2.
In the list of projects, choose the option next to the project that you want to upload your tests to.
Tip
If the list of projects is not displayed, then on the secondary navigation bar, for Projects,
choose the name of the project that you want to upload your tests to.
To create a new project, follow the instructions in Create a Project (p. 20).
3.
4.
5.
Note
Make sure that your app file is built for an iOS device and not for a simulator.
6.
7.
8.
Version Information
Currently, Device Farm supports Appium version 1.4.16 (1.3.6 for iOS 6-7) and Java version Java 8.
2.
Modify pom.xml to use maven-jar-plugin to build your tests into a JAR file.
The following plugin will build your test source code (anything in the src/test directory) into a JAR
file:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>2.6</version>
<executions>
<execution>
<goals>
<goal>test-jar</goal>
</goals>
</execution>
</executions>
</plugin>
3.
<execution>
<id>copy-dependencies</id>
<phase>package</phase>
<goals>
<goal>copy-dependencies</goal>
</goals>
<configuration>
<outputDirectory>${project.build.directory}/dependency-jars/</out
putDirectory>
</configuration>
</execution>
</executions>
</plugin>
4.
5.
Modify pom.xml to use maven-assembly-plugin to package tests and all dependencies into a
single .zip file.
The following plugin uses the preceding assembly to create a .zip file named
zip-with-dependencies in the build output directory every time mvn package is run:
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<version>2.5.4</version>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>single</goal>
</goals>
<configuration>
<finalName>zip-with-dependencies</finalName>
<appendAssemblyId>false</appendAssemblyId>
<descriptors>
<descriptor>src/main/assembly/zip.xml</descriptor>
</descriptors>
</configuration>
</execution>
</executions>
</plugin>
6.
7.
Tip
If you receive an error saying that annotation is not supported in 1.3, add the following to pom.xml:
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<source>1.7</source>
<target>1.7</target>
</configuration>
</plugin>
Tip
If the list of projects is not displayed, then on the secondary navigation bar, for Projects,
choose the name of the project that you want to upload your tests to.
To create a new project, follow the instructions in Create a Project (p. 20).
3.
4.
5.
Note
Make sure that your app file is built for an iOS device and not for a simulator.
6.
7.
8.
Version Information
Currently, Device Farm supports Appium version 1.4.16 (1.3.6 for iOS 6-7) and Python version 2.7.6 (pip
version 1.5.4).
Note
The instructions below are based on Linux x86_64 and Mac. In the currently supported scheme,
Device Farm requires that the packaging of your Appium Python tests be done on Linux x86_64
if your tests contain non-universal Python wheels dependencies. For the platform on which you
execute a command, the wheels tools gather your .whl dependent files under the wheelhouse/
folder. When you execute the Python wheel command on any platform other than Linux x86_64,
you would gather the flavor of a non-univesral wheel dependency for that particular platform and
may cause undesired effects. This would most likely lead to errors when executing your tests
on Device Farm.
1.
We strongly recommend that you set up Python virtualenv for developing and packaging tests so
that unnecessary dependencies are not included in your app package.
Tip
Do not create a Python virtualenv with the --system-site-packages option, because
it will inherit packages from /usr/lib/pythonx.x/site-packages or wherever your global
site-packages directory is. This can lead to you including dependencies in your virtual
environment that are not needed by your tests.
You should also verify that your tests do not use dependencies that are dependent on
native libraries, as these native libraries may or may not be present on the instance where
these tests run.
2.
3.
virtualenv workspace
cd workspace
source bin/activate
pip install pytest
Store all Python test scripts under the tests/ folder in your work space.
workspace
tests/ (your tests go here)
4.
Make sure you have py.test installed in your virtual environment and test cases are discoverable by
the following command, which you should run from your virtual environment workspace folder.
$ py.test --collect-only tests/
5.
Make sure the output of py.test command shows you the tests that you want to execute on Device
Farm.
Go to your work space and run the following command to generate the requirements.txt file:
$ pip freeze > requirements.txt
6.
Go to your work space and run the following command to generate the wheelhouse/ folder:
$ pip wheel --wheel-dir wheelhouse -r requirements.txt
7.
You can use the following commands to clean all cached files under your tests/ folder:
$
$
$
$
8.
find
find
find
find
.
.
.
.
-name
-name
-name
-name
'__pycache__'
'*.pyc' -exec
'*.pyo' -exec
'*~' -exec rm
-type
rm -f
rm -f
-f {}
d -exec rm -r {} +
{} +
{} +
+
Zip the tests/ folder, wheelhouse/ folder, and the requirements.txt file into a single archive:
$ zip -r test_bundle.zip tests/ wheelhouse/ requirements.txt
test_bundle.zip
requirements.txt
wheelhouse/
2.
3.
If you see the AWS Device Farm console home page, choose Get started.
If you already have a project, you can upload your tests to an existing project or choose Create a
new project.
Tip
If the list of projects is not displayed, then on the secondary navigation bar, for Projects,
choose the name of the project where you want to upload your tests.
To create a project, follow the instructions in Create a Project (p. 20).
4.
5.
6.
7.
Tip
Give the run a name that will help you identify a specific build of your app (for example,
Beta-0.1). For more information, see Working with Runs (p. 23).
8.
9.
To add your Appium test scripts to the test run, choose Upload.
10. Choose Next step, and then complete the instructions to select devices and start the run.
What is Calabash?
Calabash is a mobile testing framework that enables automated user interface acceptance tests that are
written in Cucumber to be run on iOS apps. For more information, see the Welcome to Calabash iOS
repository on GitHub.
Note
AWS Device Farm currently works with Calabash version 0.14.3.
Version Information
Currently, Device Farm supports Calabash version 0.14.3.
Tip
If the list of projects is not displayed, then on the secondary navigation bar, for Projects,
choose the name of the project that you want to upload your tests to.
To create a new project, follow the instructions in Create a Project (p. 20).
3.
4.
5.
Note
Make sure that your .ipa file is built for an iOS device and not for a simulator.
6.
7.
8.
9.
What is UI Automation?
You can use the Automation instrument to automate user interface tests in your iOS app through test
scripts that you write. These scripts run outside of your app and simulate user interaction by calling the
UI Automation API, a JavaScript programming interface that specifies actions to be performed in your
app as it runs in the simulator or on a connected device. For more information, see About Instruments in
the Instruments User Guide section of the iOS Developer Library.
Tip
If the list of projects is not displayed, then on the secondary navigation bar, for Projects,
choose the name of the project that you want to upload your tests to.
To create a new project, follow the instructions in Create a Project (p. 20).
3.
4.
5.
Note
Make sure that your .ipa file is built for an iOS device and not for a simulator.
6.
7.
8.
On the Configure a test page, choose UI Automation, and then choose Upload.
Browse to and choose the .js file for a single test.
9.
Choose Next step, and then complete the remaining on-screen instructions to select the devices to
run your tests on and to then start the run.
1.
2.
Tip
If the list of projects is not displayed, then on the secondary navigation bar, for Projects,
choose the name of the project that you want to upload your tests to.
To create a new project, follow the instructions in Create a Project (p. 20).
3.
4.
5.
Note
Make sure that your .ipa file is built for an iOS device and not for a simulator.
6.
7.
8.
Browse to and choose the .zip file that contains your iOS XCTest tests. In this .zip file, make sure
that the contents are organized according to the instructions as described in Prepare Your iOS XCTest
Tests (p. 71).
Choose Next step, and then complete the remaining on-screen instructions to select the devices to
run your tests on and to then start the run.
9.
Tip
If the list of projects is not displayed, then on the secondary navigation bar, for Projects,
choose the name of the project that you want to upload your tests to.
To create a new project, follow the instructions in Create a Project (p. 20).
3.
4.
5.
Note
Make sure that your .ipa file is built for an iOS device and not for a simulator.
6.
7.
8.
9.
Version Information
Currently, Device Farm supports Appium version 1.4.16 and Java version Java 8.
3.
If you already have a project, you can upload your tests to an existing project or choose Create a
new project.
Tip
If the list of projects is not displayed, then on the secondary navigation bar, for Projects,
choose the name of the project where you want to upload your tests.
To create a new project, follow the instructions in Create a Project (p. 20).
4.
5.
6.
Tip
Name the run something that helps you easily identify a specific build of your app (for
example, Beta-0.1. For more information, see Working with Runs (p. 23).
7.
8.
9.
Choose Next step, and then complete the remaining on-screen instructions to select devices and
start the run.
Version Information
Currently, Device Farm supports Appium version 1.4.16 and Java version Java 8.
3.
If you already have a project, you can upload your tests to an existing project or choose Create a
new project.
Tip
If the list of projects is not displayed, then on the secondary navigation bar, for Projects,
choose the name of the project where you want to upload your tests.
To create a new project, follow the instructions in Create a Project (p. 20).
4.
5.
6.
Tip
Name the run something that helps you easily identify a specific build of your app (for
example, Beta-0.1. For more information, see Working with Runs (p. 23).
7.
8.
9.
Version Information
Currently, Device Farm supports Appium version 1.4.16 and Python version 2.7.6 (pip version 1.5.4).
Note
The instructions below are based on Linux x86_64 and Mac. In the currently supported scheme,
Device Farm requires that the packaging of your Appium Python tests be done on Linux x86_64
if your tests contain non-universal Python wheels dependencies. For the platform on which you
execute a command, the wheels tools gather your .whl dependent files under the wheelhouse/
folder. When you execute the Python wheel command on any platform other than Linux x86_64,
you would gather the flavor of a non-univesral wheel dependency for that particular platform and
may cause undesired effects. This would most likely lead to errors when executing your tests
on Device Farm.
1.
We strongly recommend that you set up Python virtualenv for developing and packaging tests so
that unnecessary dependencies are not included in your app package.
Tip
Do not create a Python virtualenv with the --system-site-packages option, because
it will inherit packages from /usr/lib/pythonx.x/site-packages or wherever your global
site-packages directory is. This can lead to you including dependencies in your virtual
environment that are not needed by your tests.
You should also verify that your tests do not use dependencies that are dependent on
native libraries, as these native libraries may or may not be present on the instance where
these tests run.
2.
3.
virtualenv workspace
cd workspace
source bin/activate
pip install pytest
Store all Python test scripts under the tests/ folder in your work space.
workspace
tests/ (your tests go here)
4.
Make sure you have py.test installed in your virtual environment and test cases are discoverable by
the following command, which you should run from your virtual environment workspace folder.
$ py.test --collect-only tests/
5.
Make sure the output of py.test command shows you the tests that you want to execute on Device
Farm.
Go to your work space and run the following command to generate the requirements.txt file:
$ pip freeze > requirements.txt
6.
Go to your work space and run the following command to generate the wheelhouse/ folder:
$ pip wheel --wheel-dir wheelhouse -r requirements.txt
7.
You can use the following commands to clean all cached files under your tests/ folder:
$
$
$
$
8.
find
find
find
find
.
.
.
.
-name
-name
-name
-name
'__pycache__'
'*.pyc' -exec
'*.pyo' -exec
'*~' -exec rm
-type
rm -f
rm -f
-f {}
d -exec rm -r {} +
{} +
{} +
+
Zip the tests/ folder, wheelhouse/ folder, and the requirements.txt file into a single archive:
$ zip -r test_bundle.zip tests/ wheelhouse/ requirements.txt
3.
If you already have a project, you can upload your tests to an existing project or choose Create a
new project.
Tip
If the list of projects is not displayed, then on the secondary navigation bar, for Projects,
choose the name of the project where you want to upload your tests.
To create a project, follow the instructions in Create a Project (p. 20).
4.
5.
6.
Tip
Give the run a name that will help you identify a specific build of your app (for example,
Beta-0.1). For more information, see Working with Runs (p. 23).
7.
8.
9.
Choose Next step, and then complete the instructions to select devices and start the run.
The following example shows how to use and consume the SCREENSHOT_PATH property to capture an
Appium screenshot that is pulled into your Device Farm report.
screenshot_folder = os.getenv('SCREENSHOT_PATH', '')
self.driver.save_screenshot(screenshot_folder + "/screenshot.png")
Tip
If the list of projects is not displayed, then on the secondary navigation bar, for Projects,
choose the name of the project where you to run the built-in explorer test.
To create a new project, follow the instructions in Create a Project (p. 20).
3.
4.
5.
6.
7.
8.
Tip
If the list of projects is not displayed, then on the secondary navigation bar, for Projects,
choose the name of the project where you to run the built-in fuzz test.
To create a new project, follow the instructions in Create a Project (p. 20).
3.
4.
5.
6.
7.
8.
9.
Choose Next step, and then complete the remaining on-screen instructions to select devices and
start the run.
Note
For security reasons, we recommend that you avoid providing or entering sensitive information
such as account numbers, personal login information, and other details during a remote access
session.
Create a Session (p. 84)
Use a Session (p. 87)
Get Session Results (p. 88)
Prerequisites
Create a project in Device Farm. Follow the instructions in Create a Project (p. 20), and then return to
this page.
4.
5.
6.
Choose a device for your session. You can choose from the list of available devices or search for a
device using the fields at the top of the list. You can search by:
Name
Platform
Operating system
Form factor
7.
8.
Next Steps
Device Farm will start the session as soon as the requested device is available, typically within a few
minutes. The Device requested dialog box appears until the session starts. To cancel the session request,
choose Cancel request.
After a session starts, if you should close the browser or browser tab without stopping the session or if
the connection between the browser and the Internet is lost, the session remains active for five minutes
from that time. After that, Device Farm ends the session automatically. Your account will be charged for
the idle time, however.
After the session begins, you can start interacting with the device in the web browser.
Prerequisites
Create a session. Follow the instructions in Create a Session (p. 84), and then return to this page.
Installing an Application
To install an application on the session device, in Install applications, choose Upload, and then choose
the .apk file for the Android application you want to install. Applications you run in an remote access
session don't require any test instrumentation or provisioning.
Next Steps
Device Farm will continue the session until you stop it manually or until the sixty-minute time limit is
reached. To end the session, choose the Stop session button. After it stops, you can access captured
video and logs generated by the session. For more information about getting session results, see Get
Session Results (p. 88).
Prerequisites
Complete a session. Follow the instructions in Use a Session (p. 87), and then return to this page.
Choose the project you want to review from the Project drop-down list.
2.
Choose the session you want to review from the list or View all sessions from the Runs & sessions
drop-down list then choose the session you want to review from the list of sessions displayed.
"result": "PENDING"
},
... additional entries ...
]
}
}
}
]
}
The preceding statement allows the IAM user in your AWS account to perform actions in Device Farm
to which your AWS account has access. In practice, you may not want to give the IAM users in your AWS
account this much access.
The following information shows how you can attach a policy to an IAM user to restrict the actions the
IAM user can perform in Device Farm.
2.
Choose Policies, and then choose Create Policy. (If a Get Started button appears, choose it, and
then choose Create Policy.)
Next to Create Your Own Policy, choose Select.
For Policy Name, type any value that will be easy for you to refer to later, if needed.
3.
4.
5.
For Policy Document, type a policy statement with the following format, and then choose Create
Policy:
{
"Version": "2012-10-17",
"Statement" : [
{
"Effect" : "Allow",
"Action" : [
"action-statement"
],
"Resource" : [
"resource-statement"
]
},
{
"Effect" : "Allow",
"Action" : [
"action-statement"
],
"Resource" : [
"resource-statement"
]
}
]
}
In the preceding statement, substitute action-statement as needed, and add additional statements
as needed, to specify the actions in Device Farm the IAM user can perform. (By default, the IAM
user will not have the desired permissions unless a corresponding Allow statement is explicitly
stated.) The following section describes the format of allowed actions for Device Farm.
Note
Currently, the only allowed value for resource-statement in the preceding example is
the asterisk character (*). This means that while you can restrict the actions an IAM user
can perform in Device Farm, you cannot also restrict the Device Farm resources the IAM
user can access.
6.
Choose Users.
7.
8.
Choose the IAM user to whom you want to attach the policy.
In the Permissions area, for Managed Policies, choose Attach Policy.
9.
Select the policy you just created, and then choose Attach Policy.
Note
To download the Jenkins plugin, go to GitHub and follow the instructions in Step 1: Install the
Plugin (p. 101).
This section contains a series of procedures to set up and use the Jenkins CI plugin with AWS Device
Farm.
Topics
Step 1: Installing the Plugin (p. 101)
Step 2: Creating an AWS Identity and Access Management User for your Jenkins CI Plugin (p. 102)
Step 3: First-time configuration instructions (p. 103)
Step 4: Using the Plugin in a Jenkins Job (p. 103)
Dependencies (p. 104)
The following images show the features of the Jenkins CI plugin.
API Version 2015-06-23
99
The plugin can also pull down all the test artifacts (logs, screenshots, etc.) locally:
Find the plugin within the Jenkins UI by choosing Manage Jenkins, Manage Plugins, and then
choose Available.
2.
3.
4.
5.
Restart Jenkins.
2.
3.
4.
Restart Jenkins.
Note
The AWS root account or IAM user that you use to complete the following steps must have
permission to create the following IAM policy and attach it to the IAM user. For more information,
see Working with Policies
2.
3.
4.
Choose Policies.
Choose Create Policy. (If a Get Started button appears, choose it, and then choose Create Policy.)
Next to Create Your Own Policy, choose Select.
5.
For Policy Name, type a name for the policy (for example, AWSDeviceFarmAccessPolicy).
6.
For Description, type a description that helps you associate this IAM user with your Jenkins project.
7.
8.
Note
If you are using device slots (p. 16), the device slots feature is disabled by default.
1.
2.
3.
4.
5.
Copy your security credentials from Step 2: Create an IAM User (p. 102) and paste your Access Key
ID and Secret Access Key into their respective boxes.
Choose Save.
6.
4.
5.
6.
7.
8.
Dependencies
The Jenkins CI Plugin requires the AWS Mobile SDK 1.10.5 or later. For more information and to install
the SDK, see AWS Mobile SDK.
Note
To download the Gradle plugin, go to GitHub and follow the instructions in Building the Device
Farm Gradle Plugin (p. 104).
The Device Farm Gradle Plugin provides Device Farm functionality from your Android Studio environment.
You can kick off tests on real Android phones and tablets hosted by Device Farm.
This section contains a series of procedures to set up and use the Device Farm Gradle Plugin.
Topics
Step 1: Building the AWS Device Farm Gradle Plugin (p. 104)
Step 2: Setting up the AWS Device Farm Gradle Plugin (p. 105)
Step 3: Generating an IAM User (p. 106)
Step 4: Configuring Test Types (p. 107)
Dependencies (p. 109)
Note
Building the plugin is optional. The plugin is published through Maven Central. If you wish to
allow Gradle to download the plugin directly, skip this step and jump to Setting up the Device
Farm Gradle Plugin (p. 105).
2.
Next step: Setting up the Device Farm Gradle Plugin (p. 105)
2.
Configure the plugin in your build.gradle file. The following test specific configuration should
serve as your guide:
apply plugin: 'devicefarm'
devicefarm {
projectName "My Project" // required: Must already exists.
devicePool "My Device Pool Name" // optional: Defaults to "Top
Devices"
useUnmeteredDevices() // optional if you wish to use your un-metered
devices
authentication {
accessKey "aws-iam-user-accesskey"
secretKey "aws-iam-user-secretkey"
// or
roleArn "My role arn" // Optional, if role arn is specified, it
will be used.
// Otherwise use access and secret keys
}
// optional block, radios default to 'on' state, all parameters op
tional
devicestate {
extraDataZipFile file("relative/path/to/zip") // default null
auxiliaryApps [file("path1"), file("path2")] // default empty
list
wifi on
bluetooth off
gps off
nfc on
latitude 47.6204 // default
longitude -122.3491 // default
}
3.
Run your Device Farm test using the following task: gradle devicefarmUpload.
The build output will print out a link to the Device Farm console where you can monitor your test
execution.
Note
The AWS root account or IAM user that you use to complete the following steps must have
permission to create the following IAM policy and attach it to the IAM user. For more information,
see Working with Policies.
2.
3.
Choose Users.
Choose Create New Users.
4.
5.
Choose Create.
6.
Choose Download Credentials and save them in a location where you can easily retrieve them
later.
Choose Close.
Choose the user name in the list.
7.
8.
9. Under Permissions, expand the Inline Policies header by clicking the down arrow on the right.
10. Choose Click here where it says, There are no inline policies to show. To create one, click here.
11. On the Set Permissions screen, choose Custom Policy.
12. Choose Select.
13. Give your policy a name, such as AWSDeviceFarmGradlePolicy.
14. Paste the following policy into Policy Document.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DeviceFarmAll",
"Effect": "Allow",
"Action": [ "devicefarm:*" ],
"Resource": [ "*" ]
}
]
}
Note
If you are using device slots (p. 16), the device slots feature is disabled by default.
Appium
Device Farm provides support for Appium Java JUnit and TestNG for Android.
Appium Java JUnit (p. 39)
Appium Java TestNG (p. 44)
You can choose useTestNG() or useJUnit(). JUnit is the default and does not need to be explicitly
specified.
appium {
tests file("path to zip file") // required
useTestNG() // or useJUnit()
}
Built-in: Explorer
Device Farm provides a built-in app explorer to test user flows through your app without writing custom
test scripts. You can specify a user name and password to test scenarios that require a login. Here is
how you configure user name and password:
appexplorer {
username "my-username"
password "my-password"
}
Built-in: Fuzz
Device Farm provides a built-in fuzz test type, which randomly sends user interface events to devices
and then reports the results.
fuzz {
eventThrottle 50 // optional default
eventCount 6000 // optional default
randomizerSeed 1234 // optional default blank
}
For more information, see Built-in: Fuzz (Android and iOS) (p. 83).
Calabash
Device Farm provides support for Calabash for Android. To learn how to prepare your Android Calabash
tests, see Calabash (p. 51)
calabash {
tests file("path to zip file") // required
tags "my tags" // optional calabash tags
profile "my profile" // optional calabash profile
}
Instrumentation
Device Farm provides support for instrumentation (JUnit, Espresso, Robotium, or any Instrumentation-based
tests) for Android. For more information, see Instrumentation (p. 53).
When running an instrumentation test in Gradle, Device Farm uses the .apk file generated from your
androidTest directory as the source of your tests.
instrumentation {
filter "test filter per developer docs" // optional
}
UI Automator
Upload your app, as well as your UI Automator-based tests, packaged in a .jar file.
uiautomator {
tests file("path to uiautomator jar file") // required
filter "test filter per developer docs" // optional
}
Dependencies
Runtime
The Device Farm Gradle Plugin requires the AWS Mobile SDK 1.10.15 or later. For more information
and to install the SDK, see AWS Mobile SDK.
Android tools builder test api 0.5.2
Apache Commons Lang3 3.3.4
For Unit Tests
Testng 6.8.8
Jmockit 1.19
Android gradle tools 1.3.0
Document History
The following table describes the important changes to the documentation since the last release of this
guide.
API version: 2015-06-23
Latest documentation update: April 19, 2016
Change
Description
Date Changed
You can now remotely access and interact with a single device April 19, 2016
in the console. Learn more about Working with Remote Access (p. 84).
Device Slots Self-Ser- You can now purchase device slots using the AWS Manage- March 22,
vice
ment Console, the AWS Command Line Interface, or the API. 2016
Learn more about how to Purchase Device Slots (p. 16).
How to stop test runs
You can now stop test runs using the AWS Management
March 22,
Console, the AWS Command Line Interface, or the API. Learn 2016
more about how to Stop a Run in AWS Device Farm (p. 25).
You can now run XCTest UI custom tests on iOS applications. March 8, 2016
Learn more about the XCTest UI (p. 72) test type.
You can now run Appium Python custom tests on Android and January 19,
iOS applications, as well as Web applications. Learn more
2016
about Test Types in AWS Device Farm (p. 11).
You can now run Appium Java JUnit and TestNG custom tests November 19,
on Web applications. Learn more about Working with Custom 2015
Web App Tests in AWS Device Farm (p. 74).
Learn more about how to install and use the Device Farm
Gradle Plugin (p. 104).
September 28,
2015
Learn more about Built-in: Explorer (Android) (p. 82). The explorer test crawls your app by analyzing each screen as if it
were an end user and takes screenshots as it explores.
September 16,
2015
Change
Description
Learn more about testing iOS devices and running iOS tests August 4, 2015
(including XCTest) in Working with Test Types in AWS Device
Farm (p. 38).
This is the initial public release of the AWS Device Farm Developer Guide.
Date Changed
AWS Glossary
For the latest AWS terminology, see the AWS Glossary in the AWS General Reference.