Towards Understanding Android APIs: Official Lists, Vendor Customizations, and Real-World Usage

arXiv:2604.14943v1 [cs.SE] 16 Apr 2026

Towards Understanding Android APIs: Official Lists, Vendor Customizations, and Real-World Usage Sinan Wang∗

Qi Zhang

Jiacheng Li

Southern University of Science and Technology Shenzhen, Guangdong, China wangsn@mail.sustech.edu.cn

Hong Kong University of Science and Technology Hong Kong SAR, China qzhangdh@cse.ust.hk

University of Maryland College Park, MD, USA jiacli@umd.edu

Lili Wei

Yida Tao

Yepang Liu∗†

McGill University Montréal, QC, Canada lili.wei@mcgill.ca

Southern University of Science and Technology Shenzhen, Guangdong, China taoyd@sustech.edu.cn

Southern University of Science and Technology Shenzhen, Guangdong, China liuyp1@sustech.edu.cn

Abstract

CCS Concepts

Android apps are built on APIs that abstract core Android system functionalities. These APIs are officially documented in multiple files distributed with the Android source code or SDK, which we collectively refer to as Android API Lists (AALs). Prior Android research has relied on specific AALs, often treating them as interchangeable ground truth. However, recent studies suggest that different AALs can lead to substantially different research outcomes, raising concerns about the validity and reproducibility of Android API-based analyses. To address this issue, we present the first indepth empirical study of four official AALs that are widely used in prior work. We systematically characterize their contents and analyze their evolution across Android releases. We then perform a fine-grained comparison of the APIs recorded in each AAL to uncover their underlying API inclusion policies and inconsistencies. To assess the practical impact of these differences, we further examine API availability on nine Android devices, including both stock Android and vendor-customized systems. Finally, we analyze API usage in 17,759 real-world Android apps (including open-source apps, commercial apps, and malware) to quantify how the choice of AAL affects empirical Android research. Our results reveal that official AALs are neither stable nor mutually consistent, and that discrepancies among them can substantially influence research conclusions. We also observe that vendor-customized APIs are actively used by normal apps, yet remain largely overlooked by existing studies. Based on these findings, we discuss their implications for Android API-based research and provide actionable suggestions to help researchers select and interpret AALs more reliably.

• Software and its engineering → Development frameworks and environments; Software libraries and repositories.

∗ Sinan Wang and Yepang Liu are affiliated with the Research Institute of Trustworthy Autonomous Systems (RITAS) at Southern University of Science and Technology. † Yepang Liu is the corresponding author.

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than the author(s) must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from permissions@acm.org. EASE 2026, 9–12 June, 2026, Glasgow, Scotland, United Kingdom © 2018 Copyright held by the owner/author(s). Publication rights licensed to ACM. ACM ISBN 978-1-4503-XXXX-X/18/06 https://doi.org/XXXXXXX.XXXXXXX

Keywords Android, Android API List, Non-SDK Interfaces. ACM Reference Format: Sinan Wang, Qi Zhang, Jiacheng Li, Lili Wei, Yida Tao, and Yepang Liu. 2018. Towards Understanding Android APIs: Official Lists, Vendor Customizations, and Real-World Usage. In Proceedings of The 30th International Conference on Evaluation and Assessment in Software Engineering (EASE 2026). ACM, New York, NY, USA, 12 pages. https://doi.org/XXXXXXX.XXXXXXX

1

Introduction

The Android framework provides a set of APIs that abstract the core Android system functionalities and hardware features, thereby supporting the functioning of running apps. These Android APIs ease app development, but they also bring API compatibility issues [50]. It has been shown that those change-prone Android APIs can trigger more developers’ discussions [35] and even threat to the apps’ ratings [34]. At the user end, one may find a particular app only works on specific Android versions or devices, causing poor user experience. Android SDK [11] provides facilities to reduce developers’ maintaining effort in this situation. For example, AndroidX [29] helps maintain an API’s backward compatibility. Lint [5] is an another SDK tool, which provides a rule-based code smell scanning service. It can detect certain API compatibility issues [24, 48] in the application source code. However, Lint’s performance have been shown to be weak [23, 48, 50, 52]. These compatibility issues attract researchers’ attention. Wei et al. [50] developed FicFinder, a tool for identifying compatibility issues via pairs of APIs and their respective issue-triggering contexts (i.e., API-context pairs). However, FicFinder depends on a set of manually written API-context pairs, limiting its practical usability in the evolving Android ecosystem. Later on, static compatibility issue detectors mostly involve a separate module for systematic API harvesting. For example, CiD [31] has an API Lifecycle Modeling module. It reads the source code of the Android framework and extracts APIs’ lifetimes for API-based issue

EASE 2026, 9–12 June, 2026, Glasgow, Scotland, United Kingdom

detection. IctApiFinder [22], another compatibility issue detector, collects all APIs in the android.jar files bundled in Android SDK. Mahmud et al. proposed ACID [39], which leverages Android API differences report [9] for detecting two kinds of API compatibility issues. As pointed out by Liu et al. [37], tools that have systematic API harvesting methods can detect significantly more issues than those that do not. They also found that tools using different sources of API knowledge output few overlapped results. The research work mentioned so far all rely on specific Android API knowledge. The accuracy of the research outcomes significantly depend on the utilization of carefully curated API lists. We call such curated API files Android API Lists (AALs for short). Despite the pervasive uses of AALs in previous work, little is known about whether they faithfully represent the Android API knowledge. In fact, we revealed that, even in the same Android version, different AALs may record distinct API knowledge, and the recorded APIs in an AAL may not reflect the actual APIs in a running Android device. For example, on Android 13, four Java methods were removed from the AAL current.txt, though they retained in the Android framework and could be used by normal apps. This AAL is utilized by the state-of-the-art API compatibility issue detector, PSDroid. Incomplete API inclusion brings false negatives to PSDroid’s detection results. In other words, incomplete or incorrect AALs pose substantial threats to various research outcomes. Our contribution: A better understanding of the Android API lists helps Android researchers and practitioners make more informed decisions in the future. To this end, we conducted the first in-depth study about four official AALs under six Android release versions. Specifically, we studied how these AALs include APIs from Android system, how they change along with the evolution of Android platform, and how they are different from each other. We further explore the API existence on nine real Android devices and the API usage situations in 17,759 real Android apps. Our study demystifies the API instability and inconsistencies among the four official AALs, as well as their impact on the Android ecosystem. Our research reveals the following key findings: (1) AALs exhibit substantial inconsistencies, with only a few (~10%) APIs shared among all investigated AALs. (2) AALs may include considerable amount of synthesized APIs, which are presented in some AALs but absent from the Android source code or real Android devices. (3) No single AAL completely records all APIs, especially for non-SDK interfaces and vendor-customized APIs. (4) AALs’ API inclusion policies are unstable, which will change during platform evolution. We also highlight research opportunities in the context of Android APIs, with an emphasis on the non-SDK APIs and vendorcustomized APIs. To support future work, we release all our research artifacts on https://github.com/sqlab-sustech/AAL-artifacts, including AAL dataset, source code of tools, and experiment results.

2 Android API Lists 2.1 Research Scope Table 1 lists recent research work that rely on specific Android API knowledge. Among the listed papers, five of them directly utilize the bundled Android API lists from either Android source

Wang et al.

code or Android SDK, which consist of the four bundled AALs involved in our study. To ease presentation, we denote each of them according to their file extensions, that is, JAR for android.jar, XML for api-versions.xml, TXT for current.txt and CSV for hiddenapi-flags.csv, respectively. We do not investigate APIs from the web documentation due to potential inaccuracies, as highlighted in [28]. We also do not consider Android source code as a separate AALs. Instead, we place confidence in it as a dependable reference when investigating the correctness of the investigated AALs.

2.2

API Definitions

Android framework APIs are written in Java, which means they are either fields or methods of some Java classes. Hence we consider APIs to be these three types of Java language constructs. To uniquely identify a Java API, we follow the practice of Java reflection [33] on how it retrieves classes and their members. Specifically, we denote a class by its full_class_name (a.k.a. fully-qualified name), which consists of the class’s package and its short name. A field in the class is denoted by a pair of character strings: ⟨full_class_name, field_name⟩ A method can be uniquely identified by a 3-tuple of strings: ⟨full_class_name, method_name, parameter_list⟩ while the last term is a (possibly empty) list of strings of the method’s formal parameter types. With such notation, constructors can be denoted as methods that have a special name "<init>" [2]. It is worth noting that our notation sufficiently includes nested classes and their members. Also notice that callbacks are special methods whose control are inverted to the application framework [23], thus our notation can cover them without additional adaptation.

2.3

The JAR List

package android.app; import android.content.ContextWrapper; public class Service extends ContextWrapper { public static final int START_STICKY = 1; // other API fields...

}

@Deprecated public final void stopForeground(boolean removeNotification) { throw new RuntimeException("Stub!"); } public final void stopSelf() { throw new RuntimeException("Stub!"); } // other API methods...

Figure 1: Decompiled code snippet in the android.jar file The android.jar file is an essential part of the Android SDK. It can be downloaded by the SDK Manager tool [11], or built through the sdk target from the Android source code. The file contains a collection of compiled Java classes and resources that define the

Towards Understanding Android APIs: Official Lists, Vendor Customizations, and Real-World Usage

EASE 2026, 9–12 June, 2026, Glasgow, Scotland, United Kingdom

Table 1: Tools or studies related to Android APIs, and how they obtain API knowledge Tool/Study

Year

Research Topic

Depending API Knowledge

AAL

PSDroid [54] ACID [40] APIMatchmaker [57] Yang et al. [55] A3 [28] RAPID [53] AppEvolve [21] IctApiFinder [22] CiD [31] CDA [32] Li et al. [30] McDonnell et al. [42]

2023 2023 2022 2022 2020 2020 2019 2018 2018 2018 2016 2013

API compatibility issue detection API compatibility issue detection API recommendation empirical study of non-SDK interfaces API migration API compatibility issue detection API migration API compatibility issue detection API compatibility issue detection empirical study of deprecated APIs empirical study of inaccessible APIs empirical study of API evolution

current.txt file in Android source code API differences report parse Android source code for APIs with lifetime hiddenapi-flags.csv file from Android source code API documentation, Android source code api-versions.xml file from Android SDK API differences report android.jar file from Android SDK parse Android source code for APIs with lifetime parse Android source code for all deprecated APIs parse Android source code for all hidden/internal APIs api-versions.xml file from Android SDK

TXT CSV XML JAR XML

Android application framework at a specific API-level. By linking this file, developers gain access to the Android framework classes, fields, and methods. This allows them to write Java code that utilizes the platform’s features, such as telephony or locationing services. Notably, this file does not contain the actual implementation of API methods. Their actual implementations reside in the running devices. Figure 1 shows the class Service in android.jar at APIlevel 33, which contains one integer constant field, and two method stubs. 2.3.1 API Extraction. We used Soot [27] to load all classes in an android.jar file. Then, for each successfully loaded class, we iterated over its field and method lists to obtain all the declared APIs. We also extracted classes that have no declared members, such as the Serializable interface. It is worth mentioning that, we do not distinguish abstract classes, interfaces, enum classes, or annotation declarations. All of them can be regarded as some special forms of Java classes, while their conceptual differences do not affect the results of our study.

2.4

supports quick lookup for the status of an API (e.g., available, deprecated) at certain API-levels. Figure 2 shows a snippet of this file, which displays the same API information as Figure 1. However, it provides more information about the API’s lifetime, such as when the API was deprecated. Notably, this file also contains removed APIs, indicated by the removed attribute on their XML elements. This enables Lint to determine an API’s lifetime. 2.4.1 API Extraction. We directly parsed the api-versions.xml file to extract all the declared APIs. In particular, we dropped out those elements having a removed attribute, as we are interested in the available APIs at a specific API-level.

2.5

package android.content { public abstract class Context { // constructor ctor public Context(); // API methods... method public final String getString(int,java.lang.Object...); method public final <T> T getSystemService(Class<T>); method public abstract String getSystemServiceName(Class<?>);

The XML List

<class name="android/app/Service" since="1"> <extends name="android/content/ContextWrapper"/> <method name="setForeground(Z)V" removed="11"/> <method name="stopForeground(Z)V" since="5" deprecated="33"/> <method name="stopSelf()V"/> <!−− other API methods... −−> <field name="START_STICKY" since="5"/> <!−− other API fields... −−> </class>

Figure 2: A class in the api-versions.xml file The api-versions.xml file is also bundled in the Android SDK. It is generated along with the android.jar file when building SDK. By referencing this file, one can determine the minimum and maximum API-levels of an API. This information is important for ensuring their apps are compatible with the desired range of Android versions. Lint leverages this file to build a database, which

The TXT List

}

}

// API fields... field public static final int MODE_WORLD_READABLE = 1; // 0x1 field public static final String WINDOW_SERVICE = "window";

Figure 3: A simplified class entry in the current.txt file The TXT list refers to the current.txt files in Android [13]. It is automatically updated once APIs are changed and the update-api build target is triggered [3]. PSDroid [54] utilizes this file to build an API lifetime database, which records when an API was being added to and deprecated from the Android framework. A major difference between the TXT list and the other AALs is that this file records the source-level API signatures. This format retains front-end language features that will be erased in bytecode, for examples, generic types or variable arguments (a.k.a. vararg). Source-level signatures help developers better understand

EASE 2026, 9–12 June, 2026, Glasgow, Scotland, United Kingdom

package Id { 𝝓 −→𝑡 𝝓 [𝑡 { Id] (rule 1, package definition) class Id[.Id] ∗ [(extends | implements) Type] { 𝜽 −→𝑡 𝜽 [𝑡 { Id [.Id] ∗ ] C −→𝑡 C ∪ {⟨𝝓 [𝑡].𝜽 [𝑡]⟩} (rule 2, class definition) field Type Id [= Value]; F −→𝑡 F ∪ {⟨𝝓 [𝑡].𝜽 [𝑡], Id⟩} (rule 3, field definition)

Wang et al.

𝝓 [𝑡], the current class name 𝜽 [𝑡], and a mapping of generic type bound 𝛀 ⊂ {⟨GenericType ↦→ Type⟩ ∗ }. The parser is shown in Figure 4. In rule 1, the action 𝝓 [𝑡 { Id] saves the current package name Id. In rule 2, C ∪ {⟨𝝓 [𝑡].𝜽 [𝑡]⟩} means concatenating current package name and class name with a dot "." and adds it into the set of classes. Similarly, rule 3 and 4 extract the member fields and methods in the current class. Rules 5 and 6 specify the semantic actions for generic types: creating the mapping ⟨Param ↦→ Type⟩ into 𝛀 for bounded generic types (rule 5.1), or converting the class to Object for unbounded generic types (rule 5.2). When encountering type parameters, the parser converts them to their bound type names (rule 6).

2.6 method [GenericTypeList] Type Id ([TypeList]); M −→𝑡 M ∪ {⟨𝝓 [𝑡].𝜽 [𝑡], Id, TypeList⟩} 𝛀 −→𝑡 ∅ (rule 4, method declaration) Param extends Type 𝛀 −→𝑡 𝛀 ∪ {⟨Param ↦→ Type⟩} (rule 5.1, bounded generic type) Param 𝛀 −→𝑡 𝛀 ∪ {⟨Param ↦→ "java.lang.Object"⟩} (rule 5.2, unbounded generic type) Id[.Id’] ∗ [.Id’] ∗ = 𝜖 (if ∃.Ω[𝑖𝑑] then Ω[Id] else Id) { Id (rule 6, generic type name) Figure 4: Parsing the TXT list file the underlying semantics of an API. However, the signatures can be different from that being referenced in the Android bytecode. Figure 3 shows an example class entry in the current.txt file at API-level 33. The file is written in a special context-free grammar, in which each class has multiple sections: its constructors, methods, fields, and so on. In Figure 3, the method getString has a vararg parameter Object..., which will be converted into Object[] in compilation. The next two methods have a type argument T and an unbounded wildcard generic type parameter, respectively. After compilation, the generic types are replaced by Object, and the type parameters are erased. Then their method declarations become: String getString(int, Object[]) Object getSystemService(Class) String getSystemServiceName(Class)

PSDroid employs such conversion to its extracted APIs, thus their database can be utilized to analyze API usages in Android bytecode. 2.5.1 API Extraction. The TXT list is written in a special grammar that involves many source-level language features. Following the API definitions in Section 2.2, we implemented a parser to collect three sets of APIs: classes C, fields F, and methods M. The parser also manipulates three state variables: the current package name

The CSV List

Landroid/content/Context;−>MODE_WORLD_READABLE:I,public−api,sdk Landroid/content/Context;−>canStartActivityForResult()Z,max− ↩→ target−r Landroid/content/Context;−>destroy()V,blocked Landroid/content/Context;−>getString(I[Ljava/lang/Object;)Ljava/ ↩→ lang/String;,public−api,sdk Landroid/content/Context;−>getSystemService(Ljava/lang/Class;) ↩→ Ljava/lang/Object;,public−api,sdk

Figure 5: Sample lines from the hiddenapi-flags.csv file Starting from Android 9, a series of APIs, called non-SDK interfaces, were restricted in usage from normal Android apps [6]. They are internally used by the Android system and are subject to change without notification. Android provides a static checker veridex [7] for scanning non-SDK interface usages in Android apps. It requires a CSV file hiddenapi-flags.csv, in which APIs are listed along with their blocking policies (e.g., public, conditional blocking). Figure 5 displays an excerpt from the CSV file. Each line corresponds to a specific method or field, i.e., an API. The tags associated with each API specify its blocking policy. For examples, the first line indicates that the field MODE_WORLD_READABLE is public. The second line suggests that the API method canStartActivityForResult() can only be used up to Android 11 (code name red velvet cake). The third line signifies that API Context.destroy() cannot be invoked in any versions. It is important to note that this file only contain bytecode-level signatures, which differ from the TXT list presented in Figure 3. 2.6.1 API Extraction. In the CSV file, each line is a JNI signature of either a method or a field. We extracted their declaring classes from the signatures to obtain the API classes in the CSV list. Also note that, in Android 9 (API-level 28), the non-SDK interfaces were declared in multiple non-CSV files. We simply merge all the files to obtain the CSV list for this Android version. A major difference between the CSV list and other AALs is that the former contains all compiled classes during building Android SDK. Thus, the CSV list involves classes or methods that were synthesized from high-level Java language features. For example, anonymous class and lambda expression are two frontend Java expressions that help developers write concise source code. During compilation, they will be synthesized into some classes or methods. These synthesized APIs are implicitly called in Java bytecode, which

Towards Understanding Android APIs: Official Lists, Vendor Customizations, and Real-World Usage

RQ1: AAL Demographics JAR

XML

RQ2: AAL Inconsistency RQ3: API Existence

TXT

CSV

RQ4: API Usage

Figure 6: Research questions of our empirical study will never be used by Android apps. To filter out these APIs, we adopt some heuristic rules. For example, synthesized APIs typically follow some naming patterns (e.g., postfix Lambda\d+), which can be used to quickly identify them. We also excluded the synthesized class initialization methods [2], which have a special method name <clinit>. On average, these synthesized APIs account for 8.7% of APIs in the CSV lists.

3 Empirical Study 3.1 Research Questions This study focuses on the completeness and correctness of the four AALs. To gain a deeper understanding, we also study the API existence on real Android devices and API usage in real-world Android apps. To drive our study, we raise the following research questions (Figure 6): • RQ1 (AAL Demographics): How many APIs are there in the four AALs? How do they change throughout the evolution of the Android platform? • RQ2 (AAL Inconsistency): What are the differences between APIs included in the four AALs? • RQ3 (API Existence): Do the APIs in AALs really exist on real Android devices? • RQ4 (API Usage): Which APIs in the AALs are commonly used by real-world Android apps? In the subsequent parts, we will provide a detailed explanation of our approach to investigate each RQ and present a thorough discussion of the findings obtained throughout this process.

3.2

AAL Files Collection

Our study relies on authenticated ALLs. To ensure this goal, we directly compiled them from Android source code at the release branches of each Android versions. Specifically, the JAR and XML lists are built from the sdk target and the CSV lists are made with the corresponding build command [6]. The TXT lists can be obtained directly from the specific file directory in the codebase [13]. As non-SDK interfaces restriction was starting from API-level 28, we only collected the four AALs since that. To ensure consistency, we limit our analysis to Android 13 (API-level 33), which is the highest API level supported by our available physical devices (Section 3.5.2).

3.3

RQ1: AAL Demographics

To answer RQ1, we directly counted the numbers of APIs after extraction and preprocessing. Then, we inspected the results and analyzed how each AAL changes along with Android evolution.

EASE 2026, 9–12 June, 2026, Glasgow, Scotland, United Kingdom

The data is present in Table 2. Each row shows the name of the release branch for the given API-level, and the numbers of three types of APIs in the four AALs, respectively. Table 2 shows that the numbers of APIs are mostly increasing during the evolution of the Android platform. For the CSV list, at API-level 29, the number of three APIs increased by more than double. This is because, at API-level 28, the CSV list only contained blocked APIs under three restriction levels. However, starting from API-level 29, this list was expanded to include all bytecode generated from the entire Android framework codebase, including public APIs and whitelist system APIs, etc. As a result, the APIs contained in the list have significantly grown. Note that the CSV list contain a considerably larger number of APIs than the others. We will further investigate its reason in RQ2. However, for the TXT list at API-level 31, the number of classes decreases by 33.9% (= (4742 − 3133)/4742), along with a significant drop in the numbers of fields and methods. Meanwhile, the other AALs still increased their API numbers. This observation suggests that the reduction in API numbers within the TXT list may not attribute to the removal of APIs from the Android framework. Table 3 shows the numbers of added/removed APIs (by pairwise set difference) in the TXT list. At API-level 31, there were 1,807 classes, 6,040 fields and 15,688 methods being removed from the TXT list. Moreover, 6,038 (99.97%) removed fields and 15,682 (99.96%) moved methods come from these removed classes. According to their package names, we aggregated the 1,807 classes and found that 78.1% of them come from either JDK (under package java.* or javax.*) or third-party packages (in org.*). This means, at API-level 31, most non-Android packages were removed from the TXT list, causing a significant drop in the numbers of its including APIs. Finding 1: For AALs under study, the rules governing API inclusion can undergo changes throughout the evolution of the Android platform. Consequently, the number of APIs in AALs may experience significant increases or decreases. For backward-compatibility purpose, Android API removal is carried out carefully [32]. This is also supported by Table 3, such that added APIs are generally more than removed APIs. However, it turns out that APIs removed from AALs can still exist. Taking the 569 removed methods from 32 to 33 in TXT (the last cell in Table 3) as an example. For each method, we search the Android codebase for API-level 32 and 33, and compare its presenting status in both versions. Among them, 547 (96.1%) methods were actually removed from the codebase. For the remaining 22 methods, four of them were labeled by a @removed annotation and became non-SDK interfaces, while the other 18 did not exist in either API-level 32 or 33. An example of the former case is WebSettings.setAppCacheMaxSize(long), which was labeled as deprecated in 32 and later annotated with @removed in its Javadoc string in 33. We successfully invoke this method on a Pixel 3 XL device running Android 13 via Java reflection. This indicates that APIs removed from AALs can still be accessed by apps, posing a soundness challenge to API-based compatibility issue detectors. Finding 2: APIs removed from the AALs may still exist in the Android source code or runtime.

EASE 2026, 9–12 June, 2026, Glasgow, Scotland, United Kingdom

Wang et al.

Table 2: Numbers of Java API in each AAL #Class

#Field

#Method

XML

TXT

CSV

JAR

XML

TXT

CSV

JAR

XML

TXT

CSV

pie-release android10-release android11-release android12-release android12L-release android13-release

28 29 30 31 32 33

4,332 4,530 4,746 5,069 5,075 5,276

4,332 4,526 4,831 5,127 5,133 5,334

4,330 4,526 4,742 3,133 3,139 3,197

10,465 20,013 22,407 26,661 26,847 28,906

22,395 23,396 25,144 26,492 26,545 27,868

22,395 23,396 25,175 26,512 26,565 27,888

22,389 23,396 25,144 20,254 20,307 20,669

70,742 144,518 155,610 179,158 180,796 193,357

44,014 46,242 48,101 50,508 50,550 52,716

35,144 36,931 38,888 40,578 40,603 42,371

38,772 40,389 41,988 27,635 27,662 28,178

63,361 205,333 228,343 262,447 264,074 281,872

:

JAR

:

API

:

:

:

Branch Name

:

:

The symbol indicates the number of API decreases compared to the previous API-level, while means it increases by more than twice. -$5

Table 3: Changes of API numbers in TXT lists 

#Class + 28 → 29 29 → 30 30 → 31 31 → 32 32 → 33

196 216 198 6 128

− 0 0 1,807 0 70

#Field + 1,028 1,756 1,150 53 980

− 21 8 6,040 0 618

+ 2,009 1,599 1,335 27 1,085

− 392 0 15,688 0 569

The findings above imply that there can be a disparity between the APIs declared in AALs and those accessible to developers. To gain a deeper understanding of this situation, we explored the differences among the four AALs (RQ2) and assess their presence in real devices (RQ3). Finally, we estimate to what extent these AALs cover API usages in real-world apps (RQ4).

3.4

RQ2: AAL Inconsistency

Table 2 demonstrates that, even at the same API-level, different AALs exhibit great differences in the numbers of their including APIs. For instance, at API-level 33, the number of classes in the CSV list is nine times greater than that in the TXT list. Additionally, the other three AALs contain significantly fewer APIs compared to the CSV list. RQ2 aims to analyze the differences among AALs in a qualitative and quantitative way. Figure 7 visualizes the differences of four AALs at API-level 33. For example, Figure 7a shows that, among the 29,032 classes declared in the four AALs, only 3,177 (10.9%) classes are included by all of them. As for fields and methods, the percentages are 10.5% and 9.1%. The XML list has 62 classes that do not exist in the other three AALs, 40 classes only appear in it and the JAR list, and so on. One can easily verify the data by summing up all numbers in an ellipse to obtain the number of the corresponding API in the last row of Table 2 (e.g., for CSV classes, 3,177+2,035+23,694=28,906). There are only a few APIs in common among the four AALs. The 20,331 shared fields and 25,815 shared methods all come from the 3,177 shared classes. Among these classes, 3,153 (99.2%) of them are located in the android.* namespace. These classes provide fundamental system functionalities to the Android apps, like Android app components, UI widgets, telephony, network management, and so forth. It indicates these shared APIs are the core Android APIs. The other 13 classes were repackaged from Apache HttpClient 4.0 since







#Method



 







DFODVVWRWDO 



 

 









EILHOGWRWDO 









 



&69



 

 

7;7 





 

;0/

  

 



 



FPHWKRGWRWDO 

Figure 7: API differences between each AALs (API-level 33)

Android 1.0 [12] and are under the org.apache.http.* package. The remaining 11 classes are Khronos OpenGL interfaces [15] that are located in the javax.microedition.khronos.* package. Finding 3: At API-level 33, only about 10% of all Java APIs are shared by all the four AALs. Figure 7 shows that the CSV list has a significant number of exclusive APIs. Particularly, 23,694/29,032 = 81.6% of classes, 85.6% of fields, and 81.3 % of methods are exclusive to this list among the four AALs. Furthermore, we found that 134,062 (80.7%) of the exclusive fields and 204,467 (88.9%) of the exclusive methods belong to these 23,694 classes. The result suggests that a large proportion of CSV APIs come from the classes that are only present in it. To comprehend the characteristics of these exclusive classes, due to the lack of explicit categorization rules, we performed manual inspection on them. Specifically, from the total population of 23,694 classes, a sample of 379 classes was randomly selected to achieve representativeness with a confidence level of 95% and a margin of error of 5% [49]. For each class under inspection, an author searched it on the Android Code Search website1 and collected all characteristics about this class (e.g., access level, special annotations). Then, the author determined the major reason why this class is present only in the CSV list. For example, a class can be private and deprecated at the same time, and we consider the former to be the major reason since deprecated APIs can also present in the other three AALs. An author performed this process, and another author verified the result. In case of conflicts, they searched back to the source code and discussed until a consensus was reached. The final result is shown in Table 4. There are three types of exclusive classes in the sample: 1 https://cs.android.com/

Towards Understanding Android APIs: Official Lists, Vendor Customizations, and Real-World Usage

EASE 2026, 9–12 June, 2026, Glasgow, Scotland, United Kingdom

Table 4: Categorization of 379 exclusive classes in CSV list

151

with @hide annotations with @removed annotations non-public access levels internal Android packages

74 2 17 58

Compiled from foreign programming languages

115

from .aidl files from .proto files from C/C++ header files from .sysprop files

90 16 8 1

Repackaged from other Java libraries

113

JDK classes third-party libraries

32 81

Intentionally hidden from public APIs

• 151 classes are explicitly defined as “inaccessible”. They can be attached with @hide or @removed annotations, or have the three non-public access levels in Java. Alternatively, 58 classes are defined in internal packages (e.g., com.android.internal.*). • 115 classes are compiled from languages other than Java. Among them, 90 classes are generated from AIDL interfaces (.aidl files), while 16 classes are from Protocol Buffers message definitions (.proto files). Besides, 9 classes are transcompiled from C/C++ header files or .sysprop file. • 113 classes are repackaged from external Java libraries. Nearly one-third of them come from JDK (e.g., NIO classes, concurrent collections). The other classes originate from third-party libraries. Finding 4: The CSV list includes a large number of APIs which do not exist in the other three AALs. They are mostly generated from other programming languages, repackaged from external libraries, or intentionally blocked from Android SDK. The other AALs also declare exclusive APIs. For example, the XML list contains 20 fields and 374 methods that do not present in the other AALs. All of them come from the 62 exclusive classes, whose package names all start with android.test.* or junit.*. However, we searched the classes in other AALs and could not find APIs under such packages. This indicates the XML list is the only AAL that involves testing-related APIs. The JAR list has 4 exclusive classes and 936 exclusive methods. Upon examination, We confirmed that the four classes are all annotation definitions. Among the exclusive methods, 866 are default constructors generated by the Java compiler, which are absent from the source code. The remaining 70 methods are inlined from their super classes in the JAR list. For example, 49 out of the 70 exclusive methods belong to the class RecordingCanvas in JAR, while none of the methods are defined in this class. Instead, they are defined in its super class Canvas. Another such case will be illustrated in Figure 8. Finding 5: Testing modules contribute to all the exclusive APIs in XML, while exclusive methods in JAR are either default constructors or methods inlined from the super classes. Although the CSV list has a large number of APIs, it, however, cannot cover them all. For example, 40 classes are only present in the JAR and XML lists; 20 classes are shared by the other three AALs. A common characteristic of them is that, they are all empty classes.

Figure 8: Illustration of fields inlined from ZipConstants

In other words, these classes have no field or method members, and thus cannot be shown in the CSV list. As for the fields and methods not covered by CSV, we compared their API signatures and the source code, and found these members were inlined to the concrete classes while their abstract super classes were hidden in the AALs. Figure 8 illustrates such an example. The class ZipInputStream (and ZipOutputStream, ZipEntry, etc.) implements the interface ZipConstants, which has multiple constant fields. The CSV list also declares these fields to be members of ZipConstants. However, in JAR and XML, these fields are inlined to the concrete classes that implement this interface, as indicated by the red arrows. Consequently, these constant fields become the members of the sub-classes in these two AALs. Similar to fields, the inlined methods also cannot be covered by CSV. Finding 6: Empty classes cannot be represented in the CSV list. Some fields and methods are inlined to the concrete classes, which also prevents their inclusion in the CSV list. Due to space limit, this paper only displays the results at APIlevel 33. However, we also observed similar findings in the other API-levels. The complete results can be found in our released dataset.

3.5

RQ3: API Existence

3.5.1 Method. To study the API existence in real Android devices, we developed an Android app, AAL-Reflector. It accepts the AALs at the corresponding runtime version and tries to access their APIs using direct Java reflection [33]. This means AAL-Reflector only retrieves APIs explicitly defined in a class, without searching for inherited APIs from its parents. If an AAL API cannot be reflected, AAL-Reflector regards it as a non-existed API. AAL-Reflector also counts the numbers of non-AAL fields and methods. Here, “non-AAL fields” refer to those that are listed through the reflection API Class.getDeclaredFields() but do not present in any of the four AALs. Similarly, non-AAL methods are also counted. To find non-AAL APIs, we only use classes in the four AALs, and do not search for “non-AAL classes”. This is because Java class loading is an on-demand process, one cannot enumerate all loadable classes without prior knowledge (Java package name, etc.) or access to the system images (it requires rooted devices) [1]. 3.5.2 Devices Pool. We run AAL-Reflector on multiple Android devices. Specifically, six physical devices with customized operating systems were available to us, which include three Android versions. For each available Android version, we also created a virtual device running the corresponding stock Android image. In total, nine Android devices were used in studying RQ3.

EASE 2026, 9–12 June, 2026, Glasgow, Scotland, United Kingdom

Wang et al.

Table 5: Numbers of non-existed APIs on Android devices (retrieved by direct Java reflection) Fields

Methods

Device

System

API

JAR

XML

TXT

CSV

non-AAL†

JAR

XML

TXT

CSV

non-AAL†

Redmi Note 10 Samsung Galaxy A50s virtual

MIUI 12.0.3 One UI 3.1 stock Android

30 30 30

655 655 655

673 673 673

655 655 655

106 108 85

559/1,116 7,622/12,657 81/195

767 767 767

375 375 375

31 31 31

279 311 209

1,007/1,419 8,519/10,525 189/281

Redmi 10X vivo Y33s virtual

MIUI 13.0.1 OriginOS ocean stock Android

31 31 31

655 655 655

675 675 675

334 334 334

17 58 4

470/878 1,283/2,951 7/10

903 903 903

386 386 386

13 13 13

59 72 3

1,003/1,227 3,392/3,931 9/14

Redmi Note 12 Samsung Galaxy A53 virtual

MIUI 14.0.1 One UI 5.1 stock Android

33 33 33

659 659 659

679 679 679

338 338 338

57 255 235

634/1,378 7,613/12,458 406/572

961 961 961

392 392 392

19 19 19

1,776 813 784

2,869/3,184 8,756/11,009 537/669

† “non-AAL” are APIs in the devices but do not present in all AALs. Item 𝑥/𝑦 means there are 𝑥 public APIs and totally 𝑦 APIs.

3.5.3 Result. Table 5 presents the list of our devices and the results of running AAL-Reflector on them. The numbers under each AAL are the number of APIs included in the AAL but failed to reflect on the device. Additionally, the column “non-AAL” shows the numbers of non-AAL fields or methods (Section 3.5.1), in terms of public APIs and all APIs, respectively. Table 5 shows that the API existing statuses for JAR, XML, and TXT are consistent across Android devices at the same API-level. For example, all Android 11 devices lack 655 fields and 767 methods declared in the JAR list, no matter whether they were customized systems or stock Android. Interestingly, their non-existed APIs are those not covered by the CSV list. Take the JAR fields at API-level 33 as an example. Table 5 tells that there are 659 fields declared in the JAR list but cannot be retrieved on all Android 13 devices. Notably, 659 = 321 + 338, which is exactly the JAR fields that have not been included by the CSV list (Figure 7b). The same situation also applies to the non-existed APIs in XML and TXT. This is not surprising. We already pointed out that, these APIs either come from the test framework (Finding 5) or were inlined to their concrete classes in the AALs (Finding 6). They do not necessarily represent the actual APIs in Android devices. On the other hand, only a few CSV APIs are absent on the devices. For instance, there are 281K CSV methods at API-level 33 (Table 2), of which only 784 (0.28%) do not exist in the stock Android 13 system. Customized systems lack more CSV methods than stock Android. Moreover, there is no significant overlap between the non-existed CSV APIs on customized systems. The two customized Android 13 devices have 57 and 255 CSV fields, respectively, that are not in their system images. However, only 7 of them are in common. Similarly, only 41 non-existed CSV methods are shared by both devices. Since most CSV APIs are declared as non-SDK interfaces, it indicates that customized systems can modify these restricted APIs while keeping the core Android APIs consistent. Finding 7: The CSV APIs present discrepancies for their existences in different Android systems. Non-AAL APIs exist on the real devices, but cannot be found in any of the four AALs. Customized devices contain more such APIs than stock Android devices. Moreover, Table 5 shows that

most of them have a public access level. However, there is no public documentation on the open web for these non-AAL APIs. In fact, most of these APIs are used by device manufacturer apps on the corresponding systems [4]. For example, there is a non-AAL method Looper.isPerfLogEnable() in the Samsung Galaxy A53. We found it raises a null-pointer exception when the user encounters a connectivity issue [8]. Finding 8: Customized Android devices widely define their own Java APIs in the Android framework classes. Most of them have a public access level.

3.6

RQ4: API Usage

3.6.1 Method. We implemented a tool, APK-Analyzer, to analyze API usages in an app, i.e., an APK file. The tool integrates Soot [27] and veridex [7], and performs an intra-procedural flow-insensitive analysis. In particular, it scans a method body to collect three types of API callsites in the application classes: (1) Direct API call: referencing APIs via FieldRef or InvokeExpr Jimple expressions; (2) Extra API call: using APIs under Android packages but not present in any of the four AALs; (3) Reflect API call: calling APIs via Java reflection. Here we directly parse the output of veridex and filter out our desired API usages. The analysis of types (2) and (3) allows us to recover more used APIs beyond those listed in the AALs. Also note that, as JDK classes (e.g., generic collections) can be included by AALs, APK-Analyzer will discard them from the output as they are out of our interests. 3.6.2 App Dataset. We collected APK files from three data sources, each of them representing a typical type of Android app. They are: • Open-source app. F-Droid is an open-source app catalog. It has been widely used in Android-related studies [48]. We downloaded all the 4,090 available apps from F-Droid. • Commercial app. Google Play consists of millions of commercial Android apps [18]. To ensure representativeness, we only collected the top-500 apps in 32 categories indexed by AppBrain2 . Finally, we downloaded 15,334 Google Play apps. 2 https://www.appbrain.com/apps/popular

Towards Understanding Android APIs: Official Lists, Vendor Customizations, and Real-World Usage

Table 6: Android API usages in the app datasets direct call

extra call

reflect call

Dataset

#APK

#API

#APK

#API

#APK

#API

#APK

F-Droid Google Play Malware

4,046 12,968 745

24,973 28,200 11,854

4,046 12,968 745

128,233 712,932 12,129

3,332 12,719 629

487 1,556 230

1,601 11,609 360

“#API” stands for all the used APIs (i.e., fields plus methods); “#APK” is the number of APKs that use certain calls of API.

• Android malware. Malware can exhibit distinguishable API usages to normal apps [47]. Here we directly used the sample of 1,238 malicious apps collected by Cao et al. [18]. For the collected apps, we discarded those that have not invoked Android APIs or cannot be analyzed by AAL-Analyzer (e.g., obfuscated APKs [41]). After app exclusion, 4,046 open-source apps, 12,968 commercial apps, and 745 malicious apps remain. In total, 17,759 real Android apps built up our experimental dataset. 3.6.3 Result. Table 6 shows the overall API usages, categorized into three types of API calls. For example, among the 4,046 F-Droid apps, all of them directly invoke APIs in the four AALs, with a total number of 24,973 used APIs (fields and methods). Only 1,601 of them use reflection to invoke a total number of 487 APIs, etc. All apps involve direct API calls, which means every app invokes at least one AAL-included API (either field or method). Further, we found that most of the directly-called APIs are those shared by the four AALs. Take F-Droid as an example, in which 24,973 AAL APIs (3,291 fields and 21,682 methods) are used. Among them, 1,738 (52.8%) fields and 15,825 (73.0%) methods appear in all the four AALs. Meanwhile, 1,537 (46.7%) fields and 3,926 (18.1%) methods are only present in CSV. Apart from them, F-Droid apps also invoke 6 JAR-only and 27 XML-only methods. Notably, the inlined members in JAR (Finding 5) are used by real-world apps. Accessing inlined members from bytecode is valid because their access can be dynamically dispatched at runtime. However, it also poses a challenge for static analyzers to resolve the actual APIs in the relying AALs if they do not involve such inlined members (i.e., CSV). The results on Google Play apps are similar to F-Droid. As for malware, almost 90% of the direct API calls are for shared APIs. Finding 9: Most of the AAL API usages are for those common APIs shared among the four AALs. We also observed nonnegligible usages of APIs that are not shared by all the AALs. The number of extra-call APIs is far more than the APIs in AALs. Most of these APIs are Android Support APIs (package android.support.*) or AndroidX APIs (package androidx.*) [10], which were packed in APK files to ensure backward API compatibility. They can be obfuscated by identifier renaming [19], leading to an explosion of unique API names. In F-Doird, 97.8% of the extra call APIs (including obfuscated ones) are either Android Support APIs or AndroidX APIs. As for Google Play and Malware, the percentages are 92.5% and 89.8%, respectively. Interestingly, we observed the usage of vendor-customized APIs. To be specific, we dumped the extra call APIs and checked if they

EASE 2026, 9–12 June, 2026, Glasgow, Scotland, United Kingdom

had intersections with the non-AAL APIs that were discovered on our experimental devices in RQ3 (Table 5). As a result, we found callsites of three non-AAL APIs in F-Droid apps, and 78 callsites in Google Play apps. For example, an open-source app, App Manager [14], utilizes the field MIUI_OP_START to check whether a file operation can be performed on the MIUI system. Finding 10: Extra API calls are mostly for Support and AndroidX APIs. Apps from F-Droid and Google Play also contain usages of vendor-customized APIs. In our collected apps, 1,601 (39.6%) F-Droid apps contain reflection calls. This percentage is less than that in Google Play apps (89.5%) and Malware (48.3%). By comparing to the CSV file, we found that only 12 reflection call APIs in F-Droid are public, while in Google Play apps and Malware, the numbers are 35 and 11, respectively. This implies that most reflection API calls in real-world apps are targeting non-SDK interfaces (i.e., non-public APIs). Finding 11: Commercial apps and malware are more likely to use reflection calls to non-SDK interfaces than open-source apps.

4 Discussion 4.1 Implications of Our Findings • Extracting API knowledge from web documentation or source code can be hard. The web documentation is well-known to be unreliable [16, 28]. As for the Android source code, researchers often focus on Java files, while Android APIs can also be generated from other programming languages (Finding 4). Moreover, it should consider the inlined members, as they are present in the app’s bytecode (Finding 9). Extracting such APIs poses a significant challenge of emulating a compiler. Android Support and AndroidX libraries should also be taken into account (Finding 10). • AALs are incomplete, inconsistent, and even unstable. None of the AALs can fully cover the other three (Figure 7). Even the largest AAL, CSV, lacks testing APIs (Finding 5). Moreover, the API inclusion policy may change over time (Finding 1). Therefore, it is important for tools that rely on specific AALs to be mindful of potential API mismatches. For instance, four methods were removed from the TXT list in Android 13, but they remain accessible from the Android runtime (Finding 2). Remarkably, we found that 5,055 (39%) Google Play apps in our dataset invoked these methods. • APIs in AALs may not exactly mirror the real Android APIs. Discrepancy exists between the AAL APIs and those present in Android source code or runtime (Finding 2). In particular, JAR, XML, and TXT lists contain inlined members (Figure 8), which are not included by CSV. These inlined APIs are also absent from the Android runtime (Finding 7). As a result, it is necessary to employ distinct API handling for static and dynamic issue detectors.

4.2

Suggestions for Future Research

• Being specific when parsing Android source code. The Android codebase is comprised of over one thousand sub-modules and is developed in tens of programming languages. Thus, parsing the whole codebase to extract Android APIs is not a trivial task. For reproduction purpose, it would be better if more details about such

EASE 2026, 9–12 June, 2026, Glasgow, Scotland, United Kingdom

process is presented. For examples, which programming languages or Android system sub-modules are considered, or what kinds of pre-processing are conducted (generic type erasing, member inlining, etc.). • Choosing appropriate AALs based on the tasks. The four AALs we studied vary in their API inclusion policies. Consequently, researchers are encouraged to provide clearer explanations regarding the particular application of AAL within the context of their research. For example, one may choose the TXT list when they only focus on the core Android functionalities, use XML if Android testing APIs are needed, or resort to CSV for native/IPC API analysis. • Seeking further research on non-SDK APIs and/or customized APIs. Apart from normal Android APIs, we have also observed usages of non-SDK interfaces and vendor-customized APIs. They can bring security vulnerabilities [20] and compatibility issues [30], which would ultimately have a negative impact on the end-users. To enhance the security and privacy of the Android system, more research efforts should be taken to understand these APIs.

4.3

Threats to Validity

• Limited coverage of Android versions and devices. Our study covers six Android versions and nine physical devices, which may limit the generalizability of our findings. Although these versions span multiple major Android releases and the devices include both stock Android and vendor-customized systems, they may not fully represent the diversity of the Android ecosystem, especially given the rapid evolution of Android versions and the continuous introduction of new device models. As a result, some API behaviors or vendor-specific customizations may not be captured in our analysis. • Restricted accessibility of system-only APIs. Certain APIs are only accessible to system apps and cannot be invoked by thirdparty apps, even via reflection. Such APIs are therefore considered non-existent by AAL-Reflector, which focuses on APIs accessible to normal applications. In our analysis, we identified only a small number of such APIs, primarily in the CSV AALs. Since these APIs are not intended for use by third-party apps and fall outside the scope of most Android app analyses, we did not further investigate them. Nevertheless, this limitation may affect studies that explicitly target system-level or privileged applications. • Potential inaccuracies in API usage extraction. A potential construct threat arises from the API usage extraction process implemented by APK-Analyzer, which may not perfectly capture all API invocations in an app. To reduce this threat, we restricted our analysis to application-level classes and relied on conservative extraction rules. While this approach improves precision, it may underestimate the overall API usage in some apps. Future work could incorporate more advanced static or hybrid analysis techniques to further improve extraction accuracy.

5 Related Work 5.1 Empirical Study about Android APIs Android Operating System Project (AOSP) is a large and complicated open-source project [38]. For this reason, many researchers aim to mine empirical knowledge from the Android codebase.

Wang et al.

Among them, the very first work was conducted by McDonnell et al. [42]. They studied the SDK API lists (i.e., the XML list) in 17 Android releases and analyzed 10 open-source apps for how they react to API changes. They have shown that, upon Android 4.2 (APIlevel 17), Android APIs experienced a fast-evolving process. They also found that developers tend to avoid frequently upgrading outdated APIs. Later, Xia et al. [53] investigated how developers handle incompatible evolving APIs on a dataset of 300,000 apps. To determine whether developers provide alternative implementations to incompatible APIs, they proposed an SVM-based approach, RAPID. They found that developers do not always provide alternative implementations to incompatible APIs. Meanwhile, they are more willing to do so if Android officially documents API replacement recommendations. Researchers have also studied other categories of Android APIs. Early in 2016, Li et al. [30] studied inaccessible APIs in the Android framework, and found that they were pervasively used. These inaccessible APIs were later announced to be part of the non-SDK interfaces and enforced by restrictions [6], which form the restricted APIs in the CSV list in our study. However, Yang et al. [55] suggested that restricted APIs can still be accessed by normal apps. Besides, Li et al. proposed CDA [32] to collect deprecated APIs from Android source code. Liu et al. [36] studied silently-evolved methods, which will change their implementation but keep the original documentation.

5.2

Android Compatibility Issue

Android compatibility issue is a long-standing problem [17]. The most recent tool is PSDroid [54]. It employs a path-sensitive analysis of API invocation with four common API usage check patterns, and harvests incompatible API lists by parsing the TXT list files. SAINTDroid [45] is another recent tool that aims at detecting three types of API compatibility issues. It directly parses the Android source code to obtain an API database. Prior to them, Liu et al. [37] conducted a replicability study about seven Android compatibility issue detectors: ACID [39], ACRYL [43, 44], PIVOT [51], CiD [31], IctApiFinder [22], FicFinder [50, 52], and CIDER [23]. Their study shows that tools with systematic API collecting methods can have more detection results than those without. This finding highlights the importance of a complete list of incompatible Android APIs. Our study systematically analyzes the four official AALs, which are complementary to their work. Compatibility issues can be exposed dynamically. JUnitTestGen [46] is capable of generating compatibility issue-triggering test cases for Android. It accepts an arbitrary API list and synthesizes API usages as unit test cases. Researchers have also proposed methods to automatically repair such API-induced compatibility issues: RepairDroid [56] uses a domain-specific language for describing repairing strategies, AppEvolve [21] updates API usages from example patches. Besides API incompatibility, Android compatibility issues can manifest themselves in other aspects, such as UI inconsistencies across running devices [26], different handling methods for configuration items [24, 25], changes in the system’s permission mechanism [48], etc.

Towards Understanding Android APIs: Official Lists, Vendor Customizations, and Real-World Usage

6

Conclusion

This work starts from a systematic literature review about Android API research, from which we summarized four kinds of commonlyused official Android API Lists (AALs). In a comprehensive empirical study of the four AALs, we investigated the API characteristics, differences, existence on real devices, and usage in real-world apps. Based on our empirical findings, we have drawn several implications for future work in related areas. Our study reveals the instability and inconsistency between the four AALs. It also points out research opportunities about non-SDK APIs and vendor-customized APIs in the Android ecosystem. Our study serves as valuable resources for practitioners and researchers, offering them a deeper understanding of the Android APIs and the API lists.

Acknowledgments The authors sincerely appreciate all anonymous reviewers for their valuable comments, which have helped improve this paper. This work is supported by the National Natural Science Foundation of China (Grant Nos. 62372219 and 62202213).

References [1] 2013. Find all classes in a package in Android - Stack Overflow. Retrieved July 9, 2023 from https://stackoverflow.com/questions/15446036 [2] 2014. The Structure of the Java Virtual Machine. Retrieved June 6, 2023 from https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-2.html#jvms-2.9 [3] 2017. How does android generate ’current.txt’ it’s api description file? Retrieved June 5, 2023 from https://stackoverflow.com/questions/42036298/ [4] 2017. pandalion98/SPay-inner-workings - GitHub. Retrieved July 11, 2023 from https://github.com/pandalion98/SPay-inner-workings/blob/master/boot. oat_files/arm64/dex/out1/android/view/KeyEvent.java#L518 Retrieved May 25, 2023 from [5] 2018. Improve your code with lint checks. https://developer.android.com/studio/write/lint [6] 2018. Restrictions on non-SDK interfaces. Retrieved May 25, 2023 from https://developer.android.com/guide/app-compatibility/restrictions-nonsdk-interfaces [7] 2018. Test using the veridex tool. Retrieved May 25, 2023 from https://developer.android.com/guide/app-compatibility/restrictions-nonsdk-interfaces#test-veridex-tool [8] 2021. 3.0 Update - Samsung Members. Retrieved July 11, 2023 from https: //r2.community.samsung.com/t5/Galaxy-M/3-0-Update/td-p/7156608 [9] 2023. Android API Differences Report. Retrieved May 29, 2023 from https: //developer.android.com/sdk/api_diff/33/changes [10] 2023. AndroidX Overview | JetPack | Android Developers. Retrieved May 29, 2023 from https://developer.android.com/jetpack/androidx [11] 2023. sdkmanger. Retrieved June 8, 2023 from https://developer.android.com/ tools/sdkmanager [12] 2024. Apache HttpComponents - HttpClient for Android. Retrieved June 26, 2023 from https://hc.apache.org/httpcomponents-client-4.5.x/android.html [13] 2024. current.txt. Retrieved June 12, 2023 from https://android.googlesource. com/platform/frameworks/base/+/refs/heads/main/core/api/current.txt [14] 2024. MuntashirAkon/AppManager - GitHub. Retrieved July 27, 2023 from https://github.com/MuntashirAkon/AppManager [15] 2024. OpenGL ES Overview - The Khronos Group Inc. Retrieved July 5, 2023 from https://www.khronos.org/opengles/ [16] Gabriele Bavota, Mario Linares-Vasquez, Carlos Eduardo Bernal-Cardenas, Massimiliano Di Penta, Rocco Oliveto, and Denys Poshyvanyk. 2014. The impact of api change-and fault-proneness on the user ratings of android apps. IEEE Transactions on Software Engineering 41, 4 (2014), 384–407. [17] Haipeng Cai, Ziyi Zhang, Li Li, and Xiaoqin Fu. 2019. A large-scale study of application incompatibilities in Android. In the 28th ACM SIGSOFT International Symposium on Software Testing and Analysis. [18] Michael Cao, Khaled Ahmed, and Julia Rubin. 2022. Rotten apples spoil the bunch: An anatomy of Google Play malware. In Proceedings of the 44th International Conference on Software Engineering. 1919–1931. [19] Shuaike Dong, Menghao Li, Wenrui Diao, Xiangyu Liu, Jian Liu, Zhou Li, Fenghao Xu, Kai Chen, Xiaofeng Wang, and Kehuan Zhang. 2018. Understanding android obfuscation techniques: A large-scale investigation in the wild. In Security and Privacy in Communication Networks: 14th International Conference, SecureComm

EASE 2026, 9–12 June, 2026, Glasgow, Scotland, United Kingdom

2018, Singapore, Singapore, August 8-10, 2018, Proceedings, Part I. Springer, 172– 192. [20] Zeinab El-Rewini and Yousra Aafer. 2021. Dissecting residual APIs in custom android ROMs. In Proceedings of the 2021 ACM SIGSAC Conference on Computer and Communications Security. 1598–1611. [21] Mattia Fazzini, Qi Xin, and Alessandro Orso. 2019. Automated API-usage update for Android apps. In Proceedings of the 28th ACM SIGSOFT international symposium on software testing and analysis. 204–215. [22] Dongjie He, Lian Li, Lei Wang, Hengjie Zheng, Guangwei Li, and Jingling Xue. 2018. Understanding and detecting evolution-induced compatibility issues in android apps. In Proceedings of the 33rd ACM/IEEE International Conference on Automated Software Engineering. 167–177. [23] Huaxun Huang, Lili Wei, Yepang Liu, and Shing-Chi Cheung. 2018. Understanding and detecting callback compatibility issues for android applications. In Proceedings of the 33rd ACM/IEEE International Conference on Automated Software Engineering. 532–542. [24] Huaxun Huang, Ming Wen, Lili Wei, Yepang Liu, and Shing-Chi Cheung. 2021. Characterizing and detecting configuration compatibility issues in android apps. In 2021 36th IEEE/ACM International Conference on Automated Software Engineering (ASE). IEEE, 517–528. [25] Huaxun Huang, Chi Xu, Ming Wen, Yepang Liu, and Shing-Chi Cheung. 2023. ConfFix: Repairing Configuration Compatibility Issues in Android Apps. In ACM SIGSOFT International Symposium on Software Testing and Analysis. [26] Taeyeon Ki, Chang Min Park, Karthik Dantu, Steven Y Ko, and Lukasz Ziarek. 2019. Mimic: UI compatibility testing system for Android apps. In 2019 IEEE/ACM 41st International Conference on Software Engineering (ICSE). IEEE, 246–256. [27] Patrick Lam, Eric Bodden, Ondrej Lhoták, and Laurie Hendren. 2011. The Soot Framework for Java Program Analysis: A Retrospective. In Cetus Users and Compiler Infastructure Workshop (CETUS 2011). [28] Maxime Lamothe, Weiyi Shang, and Tse-Hsun Peter Chen. 2020. A3: Assisting android api migrations using code examples. IEEE Transactions on Software Engineering 48, 2 (2020), 417–431. [29] Jiacheng Li, Kerui Huang, Sinan Wang, and Yepang Liu. 2023. Towards the Adoption and Adaptation of the AndroidX Library: An Empirical Study. In 2023 IEEE 23rd International Conference on Software Quality, Reliability, and Security (QRS). IEEE, 418–427. [30] Li Li, Tegawendé F Bissyandé, Yves Le Traon, and Jacques Klein. 2016. Accessing inaccessible android apis: An empirical study. In 2016 IEEE International Conference on Software Maintenance and Evolution (ICSME). IEEE, 411–422. [31] Li Li, Tegawendé F Bissyandé, Haoyu Wang, and Jacques Klein. 2018. Cid: Automating the detection of api-related compatibility issues in android apps. In Proceedings of the 27th ACM SIGSOFT International Symposium on Software Testing and Analysis. 153–163. [32] Li Li, Jun Gao, Tegawendé F Bissyandé, Lei Ma, Xin Xia, and Jacques Klein. 2018. Characterising deprecated android apis. In Proceedings of the 15th International Conference on Mining Software Repositories. 254–264. [33] Yue Li, Tian Tan, and Jingling Xue. 2019. Understanding and analyzing java reflection. ACM Transactions on Software Engineering and Methodology (TOSEM) 28, 2 (2019), 1–50. [34] Mario Linares-Vásquez, Gabriele Bavota, Carlos Bernal-Cárdenas, Massimiliano Di Penta, Rocco Oliveto, and Denys Poshyvanyk. 2013. Api change and fault proneness: A threat to the success of android apps. In Proceedings of the 2013 9th joint meeting on foundations of software engineering. 477–487. [35] Mario Linares-Vásquez, Gabriele Bavota, Massimiliano Di Penta, Rocco Oliveto, and Denys Poshyvanyk. 2014. How do api changes trigger stack overflow discussions? a study on the android sdk. In Proceedings of the 22nd International Conference on Program Comprehension. 83–94. [36] Pei Liu, Li Li, Yichun Yan, Mattia Fazzini, and John Grundy. 2021. Identifying and characterizing silently-evolved methods in the android API. In 2021 IEEE/ACM 43rd International Conference on Software Engineering: Software Engineering in Practice (ICSE-SEIP). IEEE, 308–317. [37] Pei Liu, Yanjie Zhao, Haipeng Cai, Mattia Fazzini, John Grundy, and Li Li. 2022. Automatically detecting api-induced compatibility issues in android apps: a comparative analysis (replicability study). In Proceedings of the 31st ACM SIGSOFT International Symposium on Software Testing and Analysis. 617–628. [38] Mehran Mahmoudi and Sarah Nadi. 2018. The android update problem: An empirical study. In Proceedings of the 15th International Conference on Mining Software Repositories. 220–230. [39] Tarek Mahmud, Meiru Che, and Guowei Yang. 2021. Android compatibility issue detection using api differences. In 2021 IEEE International Conference on Software Analysis, Evolution and Reengineering (SANER). IEEE, 480–490. [40] Tarek Mahmud, Meiru Che, and Guowei Yang. 2023. Detecting Android API Compatibility Issues With API Differences. IEEE Transactions on Software Engineering (2023). [41] William Martin, Federica Sarro, Yue Jia, Yuanyuan Zhang, and Mark Harman. 2016. A survey of app store analysis for software engineering. IEEE transactions on software engineering 43, 9 (2016), 817–847.

EASE 2026, 9–12 June, 2026, Glasgow, Scotland, United Kingdom

[42] Tyler McDonnell, Baishakhi Ray, and Miryung Kim. 2013. An empirical study of api stability and adoption in the android ecosystem. In 2013 IEEE International Conference on Software Maintenance. IEEE, 70–79. [43] Simone Scalabrino, Gabriele Bavota, Mario Linares-Vásquez, Michele Lanza, and Rocco Oliveto. 2019. Data-driven solutions to detect api compatibility issues in android: an empirical study. In 2019 IEEE/ACM 16th International Conference on Mining Software Repositories (MSR). IEEE, 288–298. [44] Simone Scalabrino, Gabriele Bavota, Mario Linares-Vásquez, Valentina Piantadosi, Michele Lanza, and Rocco Oliveto. 2020. API compatibility issues in Android: Causes and effectiveness of data-driven detection techniques. Empirical Software Engineering 25, 6 (2020), 5006–5046. [45] Bruno Silva, Clay Stevens, Niloofar Mansoor, Witawas Srisa-An, Tingting Yu, and Hamid Bagheri. 2022. SAINTDroid: Scalable, Automated Incompatibility Detection for Android. In 2022 52nd Annual IEEE/IFIP International Conference on Dependable Systems and Networks (DSN). IEEE, 567–579. [46] Xiaoyu Sun, Xiao Chen, Yanjie Zhao, Pei Liu, John Grundy, and Li Li. 2022. Mining android api usage to generate unit test cases for pinpointing compatibility issues. In 37th IEEE/ACM International Conference on Automated Software Engineering. 1–13. [47] Kimberly Tam, Ali Feizollah, Nor Badrul Anuar, Rosli Salleh, and Lorenzo Cavallaro. 2017. The evolution of android malware and android analysis techniques. ACM Computing Surveys (CSUR) 49, 4 (2017), 1–41. [48] Sinan Wang, Yibo Wang, Xian Zhan, Ying Wang, Yepang Liu, Xiapu Luo, and Shing-Chi Cheung. 2022. Aper: evolution-aware runtime permission misuse detection for Android apps. In Proceedings of the 44th International Conference on Software Engineering. 125–137. [49] Sinan Wang, Ming Wen, Yepang Liu, Ying Wang, and Rongxin Wu. 2021. Understanding and facilitating the co-evolution of production and test code. In 2021 IEEE International conference on software analysis, evolution and reengineering

Wang et al.

(SANER). IEEE, 272–283. [50] Lili Wei, Yepang Liu, and Shing-Chi Cheung. 2016. Taming android fragmentation: Characterizing and detecting compatibility issues for android apps. In Proceedings of the 31st IEEE/ACM International Conference on Automated Software Engineering. 226–237. [51] Lili Wei, Yepang Liu, and Shing-Chi Cheung. 2019. Pivot: learning api-device correlations to facilitate android compatibility issue detection. In 2019 IEEE/ACM 41st International Conference on Software Engineering (ICSE). IEEE, 878–888. [52] Lili Wei, Yepang Liu, Shing-Chi Cheung, Huaxun Huang, Xuan Lu, and Xuanzhe Liu. 2018. Understanding and detecting fragmentation-induced compatibility issues for android apps. IEEE Transactions on Software Engineering 46, 11 (2018), 1176–1199. [53] Hao Xia, Yuan Zhang, Yingtian Zhou, Xiaoting Chen, Yang Wang, Xiangyu Zhang, Shuaishuai Cui, Geng Hong, Xiaohan Zhang, Min Yang, et al. 2020. How Android developers handle evolution-induced API compatibility issues: a largescale study. In Proceedings of the ACM/IEEE 42nd International Conference on Software Engineering. 886–898. [54] Sen Yang, Sen Chen, Lingling Fan, Sihan Xu, Zhanwei Hui, and Song Huang. 2023. Compatibility Issue Detection for Android Apps Based on Path-Sensitive Semantic Analysis. In 45th International Conference on Software Engineering. [55] Shishuai Yang, Rui Li, Jiongyi Chen, Wenrui Diao, and Shanqing Guo. 2022. Demystifying Android non-SDK APIs: measurement and understanding. In Proceedings of the 44th International Conference on Software Engineering. 647–658. [56] Yanjie Zhao, Li Li, Kui Liu, and John Grundy. 2022. Towards automatically repairing compatibility issues in published android apps. In Proceedings of the 44th International Conference on Software Engineering. 2142–2153. [57] Yanjie Zhao, Li Li, Haoyu Wang, Qiang He, and John Grundy. 2022. APIMatchmaker: Matching the Right APIs for Supporting the Development of Android Apps. IEEE Transactions on Software Engineering 49, 1 (2022), 113–130.

Related documents

• APPSim-Bench: Bridging Real-world Apps and Reproducible Evaluation for Mobile GUI Agents#984614
• Desired Enhancements to Generic Security Services Application Program Interface (GSS-API) Version 3 Naming#254497
• A Pseudo-Random Function (PRF) API Extension for the Generic Security Service Application Program Interface (GSS-API)#500641
• A Platform to analyze android application components for vulnerabilities#955875
• SpecFirst: Behavioral Specification Elicitation as a First-Class Step in Agent-Based Program Synthesis from Scratch#411100