Android Emulators have software buttons and a hardware keyboard. In a regular Android emulator the device buttons are software buttons displayed on the right size of the emulator. For the Android emulators with different skins (e.g Google Nexus 7 HD, LG Nexus 4, Samsung Galaxy Nexus, Samsung Galaxy S3, etc) the device buttons are also software buttons that are overplayed on top of the skin. For instance, if you hover the mouse around the edges of any of our Android emulators with an specified skin, a hover icon will appear and you should be able to find whatever buttons actually exist on the device that the skinned emulator is trying to emulate (e.g power button along the top, volume buttons along the edge, back/home buttons right below the screen, etc).
If you wish to use the native Android testing framework (Espresso), please refer to the following documentation for real device testing or emulator and simulator testing .
Currently the only browser that can be automated in our Android emulators is the stock browser (i.e Chrome).
The mobile real device cloud is a new feature that Sauce Labs is currently working on. For more information about this feature please directly email your account representative or email (email@example.com).
Appium 1.6.0 will default to using `automationName: XCUITest` for iOS 10.x tests, and `automationName: UIAutomation` for iOS 9.x tests. However, if you specify `automationName: XCUITest` in the device capabilities for the test, you can get XCUITest for iOS 9.x tests.
Our devices are real, physical devices. They are standard, commercially available devices and not modified or rooted. We use virtual networking computer (VNC) to transmit mouse and keyboard events on the devices. The VNC server on the devices relays back the content of the screen of the devices in real time.
The top lists indicate the ten most common devices by country. We gather information from an external provider who analyses mobile web traffic data from thousands of websites worldwide. The lists are generally reliable, but by using the "web traffic" metric for device distribution numbers, high-end devices and tablets might be overrepresented. Older and low-cost devices often have a smaller screen and a poorer performance, and are less used for surfing the web than top devices. This is why the "web-traffic" metric might underrepresent the overall distribution of these devices.
When you compare the most popular devices of your users with our top lists you probably will see differences. A reason for this might be that our lists represent all mobile users, where your users may differ in certain aspects from the overall population of mobile users. For example, a food recipe app probably attracts a different user group than an outdoor navigation app, and these user groups probably also prefer different device models.
We try to source new popular devices really quickly. Usually, we can provide new models immediately after they are launched.
Generally, yes. If the model you are looking for is not in our pool yet you can request it. In the device selection screen for your manual test, click the Device request link under Search devices. We'll add that request to our purchasing list. If a device is requested by enough users, we will look to source it in our next purchasing round.
While you will be able to access the camera on all our devices, our smartphones and tablets are usually located in racks to allow higher density in our data centers. This means that you will only see what is immediately in front of the camera lens.
Yes. For iOS you will need to disable resigning before testing to enable notifications testing. Disabling resigning is a feature to be used on private devices only and will require you to start keeping track of the iOS device UDIDs (Unique Device Identifier) by maintaining them in your own Apple Developer profile used at app build time. Android testing requires no changes.
The Real Device Cloud servers are located in the Europe and US at certified data centers. The communication is SSL secured. We try to ensure as much safety as a cloud service can provide. The Real Device Cloud will never abuse your data, and we respect your data privacy at all times. For very high security requirements we also provide a private cloud solution.
It is of great importance for us to make sure that no other user can have access to your data. This is why we clean up the devices after each testing session. In detail we:
Yes, we support OAuth login via LinkedIn, Google and GitHub.
The number of concurrent test sessions in your plan tells you
You can upgrade your plan at any time and get access to all its features immediately. Charges will also apply immediately. If you downgrade, your new plan starts from the next billing cycle.
Yes, all Real Device Cloud plans - monthly and annual - are auto-renewal subscriptions. To cancel your subscription you have to actively downgrade to the "free" plan. This will not delete your Real Device Cloud account and you can re-subscribe to a paid plan at any time.
We accept credit card payments (Visa, MasterCard, Maestro). When you have subscribed to a monthly plan, your credit card will be charged monthly. When you've subscribed to an annual plan, the full amount for 12 months will be charged once at the beginning of the billing cycle. For annual plans we also accept PayPal or direct invoicing. Please contact our sales team for further information: firstname.lastname@example.org.
Yes, you will receive an invoice for every payment via email. You also can access your billing history from your account settings.
Yes. You need to upgrade to a paid plan to get access to devices that are not password-protected. Note that the free devices will remain 'free' even if you have a paid account. These will still be accessible to you, but there will also be other devices available that are not password protected.
To make sure the availability stays high, we need to password-protect certain functionality on our free devices. This usually includes the Settings and the Play Store. The password protection is not in place on our premium devices.
You can run as many tests as you wish on your trial account, but you will only be able to run one test at a time. Also, no manual test is allowed to run for more than ten minutes.
You can do that for Robotium and Espresso, but not for Appium. Tests that rely on Appium must be initiated by local test runners.
Yes. You’ll want to use Maven or Gradle. We also have our own Espresso Runner here:
https://github.com/saucelabs/espresso-runner (note the Gradle plugin has been deprecated).
Yes, but only on iOS 10 and iOS 9 (note these OSes have different default behavior).
You need to export your app as an IPA file for Ad Hoc Deployment as described in Creating an ipa File. You can upload your IPA manually to create a project, then upload subsequent versions either manually or through our REST API, as described in Uploading Your App to Real Device Storage with the REST API
Yes. You can upload more than one APK using the “dependency app” functionality.
Yes, but only for manual testing. If the browser is not present on the device, you will need to manually install it. For automated testing, we support the Android device's default browser and Chrome Browser and Safari on iOS.
No. On iOS we re-sign with our own certificate. On Android, there are no extra complications with certificates.
No. Private cloud accounts have the option today to use an IPSEC VPN (which must be specially set up by Sauce Labs). Sauce Connect is supported for both private and public clouds.
No. If there is, our automated cleaning process didn’t work as intended. If this happens, let us know so our Operations team can reset the device and see what went wrong with the cleaning process.
You can add an exception for the Real Device Cloud to your network's whitelist for the IP address
18.104.22.168/22 for the European data center, or the IP ranges
22.214.171.124/21 and 126.96.36.199/21 for the US data center.
15 minutes by default. But you can increase it up to 30 minutes through the
testobject_session_creation_timeout desired capability . You can also shorten it, but putting it to less than 2 minutes is probably a bad idea. At less than 2 minutes, you may see tests not starting because the session may not have time to be initialized.
Yes. The 5 other tests will try to get the requested devices for the next 15 minutes. That’s the default time -- it can be increased to 30 minutes through the
testobject_session_creation_timeout desired capability
No. Sessions are closed after 15 minutes of inactivity.
Yes, for plans purchased after May 1, /2017. No, for plans purchased before that date.
No, because we don’t create reports for manual tests. We only do that for automated tests.
No. We have plans to make that possible in the future.
This could mean something went wrong in our infrastructure. Let us know and we’ll contact our operations team.
The default behaviour for manual tests is to grant all permissions to apps to prevent those popups.
I see the error "Not Yet Implemented Exception" when scrolling in an Appium web test on Android. Why?
Appium cannot scroll in the "web" context, only in the native app context. The test shows this error instead.
Software updates are deployed to the service between 7:30 and 8:30 CEST on most Thursdays. The service does not officially halt during this weekly window of time, but customers should be aware that any automated or manual tests run during this time period might fail.
No. This is feature request that is on our road map.
Yes. Please contact your Customer Success Manager or Account Executive to discuss your specific use case
20 to 30 FPS.
No, there are no inspection tools. We recommend using Appium Desktop for UI inspection, it has built in support for devices on the Real Device Cloud.
Yes. For automated tests this can be done with a command (in Java, it would be:
driver.setOrientation(orientation)). For manual tests, click rotate device.
Yes. In Java, it can be done with the command:
Yes, but only for manual tests. The change can be made in the Settings of the device.
Yes, if you use the Spoon library.
Yes, only on devices that have SIM cards and are connected to the Carrier Network.
Yes, only on devices that have SIM cards and are connected to the Carrier Network.