ConfDroid

The goal of this project is to facilitate automated detection of configuration compatibility issues in Android applications. ConfDroid can automatically infer detection rules for configuration compatibility issues given different versions of the Android framework in the Java end. Such detection rules can be used to help app developers identify possible configuration compatibility issues on specific Android versions.

Please download all the materials of ConfDroid here.

[2021-11-14] Correct the errors in the table of issue reports generated by ConfDroid detector

We conducted an empirical study by collecting 196 real configuration compatibility issues from 43 open-source Android apps. Such an empirical study facilitates the design of ConfDroid approach. Please check the 196 real configuration compatibility issues in this link.

ConfDroid takes the Android framework in different API levels as inputs. ConfDroid is built based on the Android configuration constraint model (Please check the detail information in our paper if you are interested). Please refer to the readme file to set up ConfDroid. Please download the package and follow the instructions as follows to try ConfDroid. In our implementation, we refer to the backward symbolic execution module of TSOpen.

To ensure the intra-class level path-sensitive analysis, the implementation of ConfDroid does not take the framework.jar that is originally extracted from the Android framework. Instead, ConfDroid works on jars containing only a single class containing configuration API invocation. Doing this can reduce the time for ConfDroid on building the ICFG for the whole Android framework. You can find the framework jars in framework-jars.zip.

Please make sure your JDK version is 1.8.

When you want to build the source code of ConfDroid, please remember to add all the dependencies located in the lib folder.

ConfDroid takes as input the following parameters:

• apiLevel: the lower API level that ConfDroid works. Since ConfDroid works on two consecutive API level l1 and l2 (l1<l2), here you put l1 as the parameter value.

• jarfolder1: the folder containing framework jars at API level l1.

• jarfolder2: the folder containing framework jars at API level l2.

• jarName: the name of jar you would like ConfDroid to process.

For example, you can extract rules for the class android.widget.Spinner as follows:

java -jar ConfDroid.jar 23 .../api23/jar_files/ .../api24/jar_files/ android_widget_Spinner

ConfDroid will output as follows:

=== output a Type 1 rule ===

Attribute name : Spinner_dropDownSelector

XML tag / class : android.widget.Spinner

Inconsistent data format : [unstyled_drawable, styled_drawable]

API level : 23 , 24

============================

We use 116 open-source and 200 closed-source Android apps to check whether the rules generated by ConfDroid can be used to identify real configuration compatibility issues.

Please try the detector (Detector.jar) with the rules uniquely extracted by ConfDroid. The detector works with the following parameter.

• apkDecompilePath: Given an apk file, please use apktool(https://github.com/iBotPeaches/Apktool) to decompile the apk file first. Assign the path storing the decompiled apk files as the value of this parameter.

For example, assume you have an apk file named test_apk_1.apk, use the apktool to decompile it first.

apktool d test_apk_1.apk

The apk file will be decompiled into the path /path/to/test_apk_1. The detector can be executed by the following command.

java -jar Detector.jar /path/to/test_apk_1

The detector will output warnings as the following formats:

=== find a compatibility issue ===

file path: ./com.marvel.unlimited/res/drawable/afs_thumb_stateful.xml

attribute: android:tint

XML element:

<shape xmlns:android="http://schemas.android.com/apk/res/android"

android:tint="?colorControlNormal" android:shape="rectangle">

<size android:height="48.0dip" android:width="8.0dip"/>

<solid android:color="@android:color/white"/>

</shape>

The source code of detector is also in ConfDroid-src folder. The main class is ReadXmlFiles. You can also compile the source code by setting the main class as ReadXmlFiles to try the detector.

We also reproduced the issue reports generated by the detector. You can find the videos in repro-video.zip.

Huaxun Huang, Ming Wen, Lili Wei, Yepang Liu, Shing-Chi Cheung, "Characterizing and Detecting Configuration Compatibility Issues in Android Apps", in 36th IEEE/ACM International Conference on Automated Software Engineering (ASE 2021) [acceptance rate: 82/440=18.6%] [preprint]