Measuring the Declared SDK Versions and Their Consistency with API Calls in Android Apps

TL;DR

This study analyzes the declared SDK versions in Android apps, examining their consistency with actual API calls, revealing issues like runtime crashes and security vulnerabilities caused by incorrect declarations.

Contribution

First comprehensive analysis of declared SDK versions and their consistency with API calls in Android apps, highlighting potential bugs and security risks.

Findings

Approximately 1.8K apps have API calls not supported by their declared SDK versions.

Over 400 apps are potentially vulnerable due to outdated SDK declarations.

The study provides insights into current practices and challenges in SDK version declaration.

Abstract

Android has been the most popular smartphone system, with multiple platform versions (e.g., KITKAT and Lollipop) active in the market. To manage the application's compatibility with one or more platform versions, Android allows apps to declare the supported platform SDK versions in their manifest files. In this paper, we make a first effort to study this modern software mechanism. Our objective is to measure the current practice of the declared SDK versions (which we term as DSDK versions afterwards) in real apps, and the consistency between the DSDK versions and their app API calls. To this end, we perform a three-dimensional analysis. First, we parse Android documents to obtain a mapping between each API and their corresponding platform versions. We then analyze the DSDK-API consistency for over 24K apps, among which we pre-exclude 1.3K apps that provide different app binaries for different Android versions through Google Play analysis. Besides shedding light on the current DSDK practice, our study quantitatively measures the two side effects of inappropriate DSDK versions: (i) around 1.8K apps have API calls that do not exist in some declared SDK versions, which causes runtime crash bugs on those platform versions; (ii) over 400 apps, due to claiming the outdated targeted DSDK versions, are potentially exploitable by remote code execution. These results indicate the importance and difficulty of declaring correct DSDK, and our work can help developers fulfill this goal.