Possible Issues With Android Applications

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 Mobile.Desktop.Picture or 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.

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.

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 Call method.

To avoid the issue, run your test on a physical device or on a virtual machine.

Most of the Mobile.Device object methods and mobile keyword-test operations are asynchronous:

• Mobile.Device.Keys
• Mobile.Device.Touch
• Mobile.Device.DoubleTouch
• Mobile.Device.Drag
• 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.Keys method may take a long time. If your tested application is Open, you can use the WaitProperty method to make sure that the control contains the needed text. The following code snippet pauses the test until the wText property of the EditText control has the needed text:

  JavaScript, JScript

  Python

  VBScript

  DelphiScript

  C++Script, C#Script

  JavaScript, JScript

  EditTextObj.WaitProperty(wText, "text");

  Python

  EditTextObj.WaitProperty(wText, "text");

  VBScript

  Call EditTextObj.WaitProperty(wText, "text")

  DelphiScript

  EditTextObj.WaitProperty(wText, 'text');

  C++Script, C#Script

  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.

  To pause the test run and wait until the application is ready, use the WaitProcess method of the Device object. The code snippet below demonstrates how you can do this:

  JavaScript, JScript

  Python

  VBScript

  DelphiScript

  C++Script, C#Script

  JavaScript, JScript

  Device.WaitProcess("com.example.myapp");

  Python

  Device.WaitProcess("com.example.myapp");

  VBScript

  Device.WaitProcess("com.example.myapp")

  DelphiScript

  Device.WaitProcess('com.example.myapp');

  C++Script, C#Script

  Device["WaitProcess"]("com.example.myapp")

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:

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.

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.

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.

Some Android devices do not allow third-party applications to change their system settings. In this case, you cannot use the AndroidDevice.GPS.GPSEnabled and 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.

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.

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.

Currently, TestComplete does not support playing back gestures on devices with Android ver. 10.x.

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.

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 (KEYCODE_DEL) incorrectly.

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.

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).

• 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.

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.

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.

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.