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).
Currently the only browser that can be automated in our Android emulators is the stock browser (i.e., Chrome).
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 strive to support the latest releases within 48 hours to ensure your website and apps work flawlessly across all platforms.
Yes -- see Camera Image Injection.
For Android real devices, it works automatically.
For iOS real devices, you'll 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.
Our 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:
- Uninstall all user apps
- Delete browser data
- Clear the SD card
- Clear all accounts whenever allowed by the OS (e.g., Google Play, Twitter, etc.)
- Finally, we automatically check if the clean-up was successful and block the device for other users if we detect that user data has not been removed properly.
Yes. We support OAuth login via LinkedIn, Google and GitHub.
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 OS versions 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 appropriate domains described in the Whitelisting for Restricted Networks in System and Network Requirements for Sauce Connect Proxy.
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.
No. This is a feature request on our roadmap.
Yes. Please contact your Customer Success Manager or SE 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: driver.setLocation(long, lat).
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.
No. Sessions are closed after 15 minutes of inactivity.
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.
My manual test errors with
App installation failed : INSTALL_FAILED_INSUFFICIENT_STORAGE#
This could mean something went wrong in our infrastructure. Let us know and we’ll contact our operations team.
The default behavior for manual tests is to grant all permissions to apps to prevent those popups.
The number of concurrent test sessions in your plan tells you:
- On how many devices your test scripts can be executed at the same time, in the case of automated testing
- How many devices you can remote control at the same time, in the case of manual testing.
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 five 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.
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'll need to upgrade to a paid plan to gain access to devices that are not password-protected.
If your app uses the Google Play store, you would need to upgrade to a Real Device Cloud plan.
Note that the free-trial 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.
Software updates are deployed to the service on Thursdays between 7:30 and 8:30 CEST. 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.