FAQ

BitBar offers live and automated testing of both native mobiles, hybrid and mobile apps.

No, you don’t unless you choose to use a test framework that specifically requires this.

Each phone is cleaned of apps that are not expected to be there.

Android browser

We do remove any browser app local data implying there will not be any navigation data on the next session. We also uninstall all apps that are possible to uninstall and remove files we know are created during test execution.

iOS browser

We rely on iOS’s own browser history cleaning services to revert Safari to an initial state.

Each device is put through a cleanup phase after each test run. Regardless of all these efforts, some files or data may stay hidden somewhere on the device on Public Cloud devices. For a truly private environment, we recommend Dedicated Device or Private Cloud installation.

The app needs to be an ad-hoc distribution developer debug build. To learn more, see Preparing for testing. You can find more information here.

For Public Cloud, we recommend you use the SecureTunnel to securely connect to browsers or devices. For private clouds, we can implement a VPN or proxy connection.

This is not supported on Public Cloud devices. There is support for this on Dedicated Devices and in Private Cloud environments.

For Public Cloud, you could try to mock the BLE connection data as required by the tests. Otherwise, we can pair devices to required Bluetooth devices on Dedicated Devices or in Private Cloud environments.

Real devices only.

On Public Cloud devices, it is complicated to manage the Google account cache. If a test account can be used to log in and do the purchase completely inside the tested app, then we support it. For Dedicated Devices and Private Cloud environments, we can set accounts controlled by the customer to enable such purchases.

If the used test framework supports testing push notifications, then we can support them too. Triggering of push notifications is up to the customer to handle.

On Public Cloud devices, it is not allowed to access device settings at all. For Dedicated Devices and Private Cloud environments, settings can be changed through remote access to the device.

We provide CPU and Memory usage data.

On Public Cloud devices, setting a Google account on the device isn’t allowed. Using a Google API/Service to log in to an app with your own account can be done. For Private and Enterprise environments, a customer’s own Google account can be set on the devices.

In the ublic Cloud, several Google accounts are in use. These Google accounts may appear when running tests in BitBar Public Cloud:

The complete list of devices with all details can be found in BitBar Cloud. We are adding new devices to increase device availability on existing models and add new models as they come out.

Dedicated devices are available through Private Cloud installations or as part of Public Cloud. Private Cloud installation allows the customer to freely select the number and type of devices, and these are managed by BitBar. On Public Cloud devices, users can reserve one or multiple devices to their use only to assure device availability and security. For more information, please contact our Sales team.

No, devices have a certain version of OS and cannot be changed. We make the change when time goes on and if OEM releases relevant OS update. The purpose is to keep up with the actual use of certain OS versions globally and provide a versatile setup of different devices and OSs as possible. Customers with dedicated or private cloud devices can request that the OS of a device be updated.

Yes, but your application needs to be configured to receive emails. On public cloud, a regular email application on the device cannot be currently configured for sending/receiving emails. However, the email accounts can be configured on dedicated and private cloud devices.

You can create yourself a free account at bitbar.com. After leaving your email address, you’ll get an activation email with a link guiding you through the registration process. You’re now able to log in to BitBar Cloud using your new credentials and access our trial device group.

There are several reasons why test runs can fail on the BitBar cloud. The first and the most typical case is that there is something wrong with the application, and instrumentation makes it crash. Device problems are typically seen as pending test runs.

No. None of our devices is jail broken or rooted.

No, this does not cause problems to our devices or environment. Our system automatically cleans, reboots, and hard resets devices before any new test run.

We have several public cloud data centers with the following IP address ranges (does not apply to test devices based on Windows and Linux systems):

Public Cloud users can also implement a test app to find the current IP of the used device/connection and communicate it to an external service that can open that IP for connections. For Dedicated Devices and Private Cloud Cloud installations, most special network configurations are possible.

When you are running an Appium client-side test, your host will be making a connection to a dynamic IP address and a port range of 10010 to 10090.

BitBar devices are located in our data centers in Mountain View, CA and Wrocław, Poland.

Currently, we don’t support emulating different geographic locations. The GPS sensors on our devices always show the device location: Wroclaw, Poland, or Mountain View, CA, United States.

All our user data, applications, and results are stored in Amazon Cloud and are very safe. We also use SSL and encrypt the data as seen appropriate. Only users with valid accounts can access their own data and results. We also track all IPs connecting to BitBar.

The time between the test run start and delivering results depends entirely on the test case length, current queue, time of the day, and the desired device set. Typically, we’re talking about 2 to 15 minutes. Sometimes, it can be longer if you start multiple test runs on the same devices. We have multiple copies of devices at BitBar, so some devices can ensure results in a few minutes (depending on the test run length).

We periodically clean unused projects and project files from our public cloud. For unused projects (where tests have not been run), after four months, the project files are removed. After this, the whole project is removed after the next three months.

Yes, you can. Our devices are not positioned for any specific photo target and recording of audio can give you arbitrary recording. However, our devices are fully functioning Android and iOS devices, and both mentioned functions are enabled on the devices.

You can close one or more applications with AssistiveTouch:

We support KIF, XCTest, XCUITest, Jasmine, and Appium for iOS test automation with BitBar.

As of the XCode8 release, UI Automation is no longer supported in BitBar testing Public Cloud, as Apple has dropped support for it.

We replace your provisioning profile with our provisioning profile. No need to root or jailbreak devices to get this done.

You can notice that when testing applications on devices using iOS version 13 or later. Once you put the insertion point into a password box, the screen keyboard disappears, and you cannot enter a value into that password box. The box remains blank when you are pasting a value into it or when you are typing text on your computer’s keyboard.

This happens due to the newer security policy these iOS versions use. The entered text is hidden from the video stream that BitBar receives from the device, so you see blank password boxes. Another effect of the newer security policy is that some security popups are also hidden.

You notice these issues when doing live testing and in the video recordings of automated tests.

To work around the issue in live testing, we recommend entering passwords with your computer’s keyboard.

As for automated tests, the issues don’t affect their functioning because these tests simulate user actions by calling specific methods of the objects they find in the tested app. The only issue is that user actions are absent from the video recordings of automated tests.

Yes, you can. To get this done effectively, consider which test automation framework fits your needs best and whether the framework will work with your app/game.

Currently, handling iOS dialogs is performed through the used test framework. We have internal tools using which we are able to avoid and dismiss OS dialogs outside of test runs.

Yes, the documentation with the full API description can be found at Use REST APIs with BitBar. You can integrate your CIs or any scripts with BitBar using the API’s JSON-based calls.

We provide a Jenkins plugin, which is available at JenkinsCI Github.

Our support is located in the USA and Poland. We provide 24/5 (business days) support for all test runs on devices at BitBar as well as email answers for any questions related to BitBar products.

Not for regular app testing. Maintaining a pre-release OS is problematic as such releases can be very unstable and out of our hands to handle.

You can buy the BitBar service online by starting the registration process at BitBar.com.

Our service is purchased at cloud.bitbar.com using popular credit cards. For security reasons, we verify each purchase using 3D Secure (sometimes, also known as “Verified by Visa”, “Mastercard SecureCode”, or “American Express SafeKey”). In some cases, you may need to enable 3D Secure for your credit card if your bank does not support it by default.

BitBar products are not limited to app testing only, e.g. the Appium framework can be used to test mobile websites using real devices.