In the context of our work, a connectivity issue is a suboptimal implementation choice that can affect the correct behavior of an Android app when used in zero/unreliable connectivity scenarios. As shown in the literature, these issues can cause crashes in apps making users experience issues. Here we describe the six categories of issues we support in CONAN, and the complete list of 16 issue types (belonging to these six categories) is presented in Table I.

When performing network operations within an Android app, the manifest file (a configuration file in an app) must include some essential permissions: (i) INTERNET, allowing full network access to the app, thus being able to open network sockets and use custom network protocols; and (ii) ACCESS_NETWORK_STATE, allowing an app to access information about network connections such as which networks exist and to which ones the device is connected.

Before performing network operations within an app it is recommended to validate the state of the network connectivity, and in particular: (i) the type of network (e.g., WI-FI, MOBILE, ETHERNET) that would allow the developers to check, for example, whether a Wi-Fi network is available in case large amounts of data must be downloaded (to avoid the user to incur in unexpected expenses); (ii) its availability, as a user could be experimenting flaky mobile networks, airplane mode, and restricted background data; and (iii) its Internet capabilities, in consideration of a scenario in which a user is connected to a certain network not providing Internet access. These validations should be implemented globally in the project and before triggering a network request, thus preventing an app from inadvertently using wrong configurations. Also, if a network connection is unavailable, the application should be able to handle such a case via the implementation of offline practices .

Fine-grained control over the usage of network resources should be provided to the user if an application constantly performs network operations. The user should be able to modify such settings, e.g., the frequency at which the app syncs data or whether to trigger network operations only when the device is connected to Wi-Fi. To provide the user with such a possibility, an Activity offering options to control data usage should be defined within the Android manifest.

Libraries providing HTTP services use callback functions for response and error handling. Regarding “successful” onResponse() callbacks and notably when back-end services are not under the app developers control, it is critical to interpret the data provided by the external service (e.g., HTTP message body data and HTTP status codes) since the lack of routines for handling exceptional scenarios can cause broken data manipulation, thus leading to a crash. Therefore, it is important to validate possible errors on the response in order to make the app react properly in such scenarios. Concerning the onFailure() callbacks, it is indispensable to employ the error callback to (i) handle unexpected behaviors and (ii) improve the user experience by presenting informative messages aimed at properly conveying the errors.

It is not recommended to implement network operations performing synchronous requests. Indeed, the latter blocks the execution of code which may cause an unresponsive behavior from the app. Note that this is not an Android-specific issue. Avoiding synchronous requests reduces the chance of running network operations in the main thread, something that it is discouraged and also reported with the throwing of a NetworkOnMainThreadException.

Complementarily, to reliably schedule asynchronous tasks that are expected to be properly executed even under flaky circumstances the WorkManager API is the recommended scheduling API in Android, and should be preferred to older managers (e.g., FirebaseJobDispatcher, GcmNetworkManager, and Job Scheduler).

While the above-presented categories of connectivity issues can affect network operations implemented using different libraries, we also identified a well-known anti-pattern concerning the OkHttp library.