Known Problematic Compatibility Issues with CommCare

This page serves as a guide to the known problematic issues within mobile phones that may lead to compatibility issues with CommCare. The list provided here is not exhaustive and will be continually updated as we learn more about potential challenges.

Aggressive Application Closing Processes

We have discovered that certain devices have unique, aggressive application closing processes on them which will close CommCare when it is running in the background and potentially result in a loss of data.

Identification by symptom

You can also test for the symptom directly using the following process, which uses techniques to put moderate pressure on the device’s memory in an attempt to provoke a force-close of CommCare. If it does result in a force close, this is a good indication that the device has an aggressive application closing process.

Open CommCare on the device and fill in a form, ideally with multimedia questions or signature questions. Leave the form filled but unsubmitted, and navigate away from CommCare.
You should notice a persistent notification at the top of the screen which indicates that CommCare is running in the background.
Open additional applications one by one and do not close them. For instance, open Google Sheets then navigate away without closing. Open Slack, then navigate away without closing. Open the web browser, navigate to various websites, and navigate away without closing. Repeat this process for 5+ large applications.
As you do this, continue to monitor the persistent notification at the top of the screen. As the phone continues to load more and more applications in the background, CommCare should remain open.
However, if at a certain point you see that the notification is gone, that means CommCare has been forced closed, and the device likely has an aggressive application closing process.
As you navigate back to CommCare, you will notice that the application has now crashed and resulted in logging you out.

Identification by specific process name

This section requires using advanced developer options and some familiarity with software developer tools. For a more broadly accessible identification method, see Identification by symptom.

Below is a list of known processes to look out for and avoid:

Process Name

How to test for this process

Known devices where this has been identified

Griffin

The most comprehensive way to identify the presence of a process in an Operating System involves accessing system logs and searching by its name. On Android devices, this can be done using a tool called logcat (Logs Catalog), which allows real-time access to system and application logs. The steps below describe how to prepare the device and configure the environment to run that tool.

Prepare device

This step is mainly to allow a communication between the computer and the mobile device for Debugging purposes.

Enable Developer option, follows the steps described here
1. Depending on the device manufacturer the steps can be slightly different
Enable USB debugging, follow the steps described here
Connect the device to the computer using an USB cable, by doing so a dialog should popup asking permission to do so (see image below)

Now that the device is ready, let’s download the necessary tools and run the logcat tool:

Download Android SDK platform tools from here
1. The actual tool needed here is adb (Android Debug Bridge), which allows the communication between the computer and the mobile device
Unpack the downloaded file and store its content in an easy to access/known folder
Open a terminal and navigate to the folder from number 2
Execute the following command:
1. Windows
  1. ./adb logcat | findstr Griffin
2. Linux/Mac
  1. ./adb logcat | grep Griffin
3. In case the execution fails, try without the ./ in the beginning of the command so adb logcat ...
Once the command is executed and if the process in question is present, a continuous stream of logs will be outputted to the terminal (see image below):
1. If not present, then nothing will be printed. If unsure whether the setup is working well, execute the command without the filtering:
  1. ./adb logcat

logs_outputted_to_terminal.mov

Multiple Infinix and Tecno models

Potential Workarounds

Below you will find workarounds that may help your projects if you are using phones that have these issues associated with them. Since we cannot guarantee that aggressive application closing processes will not change in the future and no longer make the workarounds effective, we still recommend avoiding these phones altogether, if possible.

Enable Graceful Session Pause (upcoming in CommCare version 2.54.1)

There is a feature you can enable to auto-restore CommCare after a force-close so that the form state is not lost. This feature is currently slated for release in version 2.54.1. This section will be updated with information on the new feature after release.

Use Device Features to Keep CommCare Open Preferentially

Some devices come with a features on the Recents screen (the background screen that lets you switch apps) that lets you tell the OS you do not want it to force-close the app. On the Recents screen (with CommCare recently open), find CommCare and tap the lock icon in the top right corner to make it go from unlocked to locked. This may reduce the rate of force-closes CommCare experiences. Some example lock icons are shown below:

Example 1:

Example 2: