|The information below concerns legacy mobile tests that work with mobile devices connected to the local computer. For new mobile tests, we recommend using the newer cloud-compatible approach.
You may come across some problems when testing Android applications. This topic explains the cause of the known issues and offers possible workarounds.
Accessing applications on Android 11
TestComplete may fail to access internal objects of an application built with Android SDK 30 for Android version 11. To avoid the issue, ask the application developers to update the application manifest as described in Preparing Android Applications (Legacy) and recompile the application.
Disconnecting an overloaded device
TestComplete works with Android devices using Android Debug Bridge (ADB). When TestComplete requests data from a device, it waits for the device to respond to ADB. If the device is busy, it may fail to answer in time. In this case, TestComplete considers the device frozen and disconnects it.
For example, virtual machines and emulators may be disconnected when TestComplete uses the
Desktop.Picture method. This method is used not only when you call methods like
AndroidControl.Picture in your script code, it is also used for drawing the Mobile Screen, finding a control’s image for image-based tests and for other purposes. If the device is performing some time-consuming operation, for example, installing an application, the
Desktop.Picture method may fail because the device cannot respond in time.
To avoid disconnection during playback, try inserting the
Delay method after the test operations that overload the device, for example, after the methods of the
PackageManager object, after the test commands that press the Back button and others.
Disconnecting devices because too many devices are connected
This issue occurs if too many devices, emulators or virtual machines are connected to the currently running ADB process. On Windows, ADB does not support more than 64 port forwardings (see the issue description in the Android Issue Tracker). Each connected device increases the number of port forwardings in use. If too many devices are connected, ADB can stop responding to TestComplete requests.
When TestComplete detects this issue, it checks the state of the Terminate ADB if it does not respond setting:
If the setting is on (default), TestComplete terminates the currently running ADB process and then starts a new ADB instance. This disconnects the devices connected to ADB. If this happens at design time, you will see no processes and internal objects under the device nodes in the Object Browser. If this happens during a test run, you will see errors in the test log. If needed, you can handle the problem in your tests.
If the setting is off, TestComplete shows a message that warns you about the problem with ADB.
To avoid the issue, control the number of connected devices and disconnect them when they are not needed.
Disconnecting Android emulators when making a call
Emulators that use Android 4.3 or later disconnect from ADB when making a phone call. Since TestComplete uses ADB to work with Android applications, the disconnection will cause an error when your test tries to work with the device. This happens whatever method your test uses to simulate a call: typing a phone number on the device screen or using the
To avoid the issue, run your test on a physical device or on a virtual machine.
Asynchronous test actions
Most of the
Mobile.Device object methods and mobile keyword-test operations are asynchronous:
- Device Keys (operation)
- Device Touch
This means that the method or operation sends a command to a device and TestComplete does not wait until the device completes the operation, it goes to the subsequent script statements or keyword-test operations. This may cause problems if the command causes time-consuming actions on the device, as the subsequent script statements or operations may depend on the result of the previous command.
To pause the script execution for certain time period, you can use the
aqUtils.Delay method or the Delay operation. If your tested Android application is Open (instrumented), you can use the
Wait method to pause the test run until the application is in the needed state. Below are some typical cases and hints:
Simulating text input with the
Device.Keysmethod may take a long time. If your tested application is Open, you can use the
WaitPropertymethod to make sure that the control contains the needed text. The following code snippet pauses the test until the
wTextproperty of the
EditTextcontrol has the needed text:
Call EditTextObj.WaitProperty(wText, "text")
Note: You can use the TestComplete Android Agent keyboard to input text without delays.
When you start an application by touching its icon, TestComplete does not wait until the application starts and creates all its windows and controls. TestComplete simply goes to the subsequent test commands. These commands can fail if they work with test objects that have not been created yet.
When working with Open Applications, you can wait for new objects or for changes in object states using the methods described in the following topics:
For image-based tests, you can use mobile checkpoints to wait for an object image as described in the following topics:
The FLAG_SECURE flag was cleared during instrumentation
TestComplete resets the
FLAG_SECURE flag for every activity window during instrumentation. This does not affect the functionality of your application in general, but may cause issues if the application uses this flag explicitly.
For more information about the
FLAG_SECURE flag, see the Android documentation for developers.
Connecting to Android 5 devices or installing applications on them takes a long time
TestComplete uses the system's dex2oat service when connecting to a device or installing applications on it. On some devices running Android 5.0, 5.1, and later, such as Nexus 7 with Android 5.1.1, this service may cause a heavy CPU load, which may delay other actions. Wait until TestComplete connects to the device or installs the application and continue testing.
If the test duration is important, connect to the device and install the tested application before running the test.
Android 4.3 memory leak
TestComplete uses Android’s surfaceflinger service to get information about the device screen orientation and to capture control images. In Android 4.3, this service has memory-leak-like issues that cause decreasing the amount of free RAM on the device. To free memory, Android terminates the applications running on the device, including the system processes. This causes exceptions in TestComplete, or TestComplete may wait for a response from a process for a long time (you may think that TestComplete has hung).
These issues can happen both during the test run and at design time if the Mobile Screen window is open for a long time.
To avoid the issues:
Close the Mobile Screen if you do not need it.
Reboot the device before running long tests.
Turn off Visualizer before running tests if you do not need it.
Changing GPS settings from tests
Some Android devices do not allow third-party applications to change their system settings. In this case, you cannot use the
AndroidDevice.GPS.AllowMockLocation properties to change GPS-related settings. If you try to change the GPS settings by using these properties, an error will occur. If this happens, consider running your tests on another device or changing the settings manually.
Connecting to Android devices from multiple user sessions
If TestComplete is launched on the same computer under several user sessions, only the first TestComplete instance launched can connect to Android devices and work with them. When you launch TestComplete, it connects to Android Debug Bridge and keeps using it without providing access for other TestComplete instances. To run tests on several devices at the same time, use different computers.
Slow access to WebView control properties and methods
WebView control belongs to a
ScrollView control in your tested Android application, it may take a lot of time for TestComplete to access internal properties and methods of the
WebView control. In addition, the content of a
WebView control that belongs to a
ScrollView control may be scrolled incorrectly.
To avoid these issues, we recommend that you ask your application developers to use another container for the
WebView controls or to use the
WebView control’s own functionality for scrolling.
Slow access to Wi-Fi-connected devices during recording
During test recording, TestComplete actively exchanges data with the tested Android application. If you are recording a test on a virtual machine, or on a physical Android device that is connected via Wi-Fi, the data goes through your local network. You might experience a slowdown when interacting with the tested application due to data transmission delays. This is typically noticeable if your local network is busy.
If you use physical devices, then we recommend that you use USB connection devices for test recording, and re-connect the devices via Wi-Fi for test runs, if needed.
Gestures are not played back on Android 10 and 11 devices
Currently, TestComplete does not support playing back gestures on devices with Android ver. 10.x - 11.x.
Keyboard input issues
Zooming or scrolling screen on keyboard input
When displaying a keyboard on screen, some mobile devices and applications can zoom in the screen or scroll it. This happens, for example, in application that use WebView controls: when the device displays the keyboard, the WebView control resizes. At that, it zooms in the web page and scrolls it to make a text box “closer” to the user.
These zooming and scrolling operations affect the way TestComplete calculates coordinates for subsequent touch events. Some devices, for example, Nexus 6, do not notify the test engine about zooming properly, so, TestComplete detects the coordinates of touch events incorrectly, and the test playback fails.
To work around the issue, use the TestComplete Android Agent keyboard to input text on your test devices. If this keyboard is used, the device does not activate the onscreen keyboard when a text box gets focus. As a result, no “hidden” zooming and scrolling operations occur, and TestComplete detects control coordinates correctly.
Backspace key input
When you use the Android onscreen keyboard to input data in your tested applications during the test recording, TestComplete may detect and record the Backspace key input (
To work around this issue, use the TestComplete Android Agent Keyboard. If this keyboard is used, TestComplete will detect and record the Backspace key input correctly.
Instrumenting debug builds of Xamarin applications
Xamarin Studio can create debug versions of an application. These versions are created in a special way to increase the installation speed. If you instrument a debug version of your application in TestComplete, the application will not launch. You can instrument the release version of Xamarin applications.
Handling system dialogs in Android Open (instrumented) applications
Some Android applications can open system dialogs. These dialogs do not appear in the Object Browser and you cannot work with them in the same way you work with objects of Android Open Applications.
To handle these dialogs in your tests, create or record image-based test commands that simulate the required action (for example, close the dialog).
Image-based testing issues
Long search for controls
In image-based tests, it can take much time for TestComplete to find a needed image on the screen. This happens, because TestComplete searches for the images on the screen pixel-by-pixel.
To avoid the issue, you can use lower pixel and color tolerance values.
To learn more, see Possible Issues (Image-Based Tests).
TestComplete records wrong controls
If there are several matching controls, for example, check boxes or switches, then to avoid ambiguous recognition, TestComplete records touches on them as touches on their parent controls with appropriate touch coordinates. In the ImageSet editor, you will see that TestComplete does not highlight the controls, it highlights their parent controls instead. So, this is not an error, TestComplete does this to simulate the recorded actions correctly.
It is quite possible that some controls overlap other controls, so the touch point belongs to both control areas. To determine the control with witch the user is actually working during recording, TestComplete chooses the control with a minimum area. In some cases, this decision can be erroneous, TestComplete selects a wrong control, and the recorded test runs with errors. As a workaround, we suggest that you add images of the needed control to the Image Repository manually and modify the test commands appropriately. See Updating Image Repository Data.
Recognition artifacts on Android 4.3 and 4.4
Android versions 4.3 and 4.4 have several graphic issues that may affect your image-based testing. During test recording and test run, images captured on devices running one of these Android versions may have visual artifacts, which causes image recognition to fail.
As a workaround, you can change the image recognition parameters so that the test engine ignores visual artifacts in captured images. You can also create and run your image-based tests on a device running an earlier Android version.
Accessibility information is unavailable (screen coordinates in tests)
To get information about the controls of non-instrumented applications (their names, images, position), TestComplete uses accessibility APIs of the Android platform. Accessibility information is optional (but desirable) for testing Android applications. If accessibility information is not available, TestComplete cannot recognize individual GUI objects. In this case, TestComplete records tests using screen coordinates.
Since accessibility information helps people with disabilities interact with your application, we recommend that you make your Android applications as accessible as possible. To learn how to make your application accessible, see the following page on the Android Developer web site: https://developer.android.com/guide/topics/ui/accessibility/index.html.
Keep in mind the following limits on providing accessibility information:
API level 15 and below (Android 4.0.4 and earlier) do not provide accessibility information.
Android emulators do not provide accessibility information unless they emulate an SD card. To run image-based tests on an emulator, you need to enter a non-zero value in the SD Card | Size setting. See Preparing Android Emulator for Testing (Legacy).
Updating image-based tests created in TestComplete 10.20 and earlier
Since version 10.30, TestComplete uses an improved algorithm for capturing images for mobile image-based tests. Earlier TestComplete versions had issues with capturing images from emulators and virtual machines (due to the specifics of the Android components, the colors of some pixels could be distorted). The new algorithm has fixed these issues.
TestComplete does not change the images in your image-based tests recorded in earlier versions. So, these tests will fail when you run them with a newer TestComplete version.
Below are some recommendations that will help you avoid possible issues:
Change the Color tolerance parameter of the images in your image-based tests. We recommend that you set the value of the Color tolerance parameter to eight or higher. For information on how to change recognition parameters of images stored in the image repository, see Specifying Item Parameters.
– or –
Re-capture images used in your problematic image-based tests. For information on how to do this, see Adding Images to the Image Strip.
– or –
Re-record your image-based tests for Android device emulators and virtual machines. Alternatively, consider moving from image-based tests for Android applications to object-based tests.
See the following issues in the Android Issue Tracker:
See the following issues in the Android Issue Tracker: