pith. sign in

arxiv: 2604.14943 · v1 · submitted 2026-04-16 · 💻 cs.SE

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

Sinan Wang , Qi Zhang , Jiacheng Li , Lili Wei , Yida Tao , Yepang Liu This is my paper

Pith reviewed 2026-05-10 11:09 UTC · model grok-4.3

classification 💻 cs.SE
keywords Android APIsAPI listsvendor customizationsAPI usage analysisempirical studyAndroid researchreproducibility
0
0 comments X

The pith

Official Android API lists differ in content and stability, leading to varying research conclusions and overlooking vendor customizations.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper conducts an empirical study of four official Android API lists that researchers commonly treat as ground truth. It shows these lists are not consistent with each other and evolve differently across Android versions because of varying inclusion policies. Applying the lists to real devices and 17,759 apps reveals that the choice of list can change which APIs are counted as available or used. The study also finds that apps do use vendor-customized APIs, which most existing research overlooks.

Core claim

The authors establish that the four official AALs are neither stable nor mutually consistent, with discrepancies among them that can substantially influence research conclusions. They further observe that vendor-customized APIs are actively used by normal apps yet remain largely overlooked by existing studies.

What carries the argument

Systematic comparison of four official Android API Lists across releases, device availability checks on nine phones, and usage measurement in 17,759 real-world apps.

If this is right

  • Android researchers cannot treat different official API lists as interchangeable without risking different outcomes.
  • Studies of API usage must account for vendor customizations to avoid incomplete pictures of what apps actually call.
  • Reproducibility of earlier Android API research may be limited by the specific list chosen in each paper.
  • Researchers should document the exact AAL used and test sensitivity to other lists when reporting results.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • Analysis tools could query device-specific APIs at runtime instead of relying on any single static list.
  • A combined or version-aware reference list might reduce the inconsistencies that affect current empirical work.
  • Benchmarks for Android studies could be expanded to include both stock and vendor-modified systems to better match real usage.

Load-bearing premise

The four chosen lists, nine devices, and 17,759 apps sufficiently represent the broader Android ecosystem, and the method for detecting API usage in apps accurately captures real behavior without false positives from unused code.

What would settle it

Re-running multiple published Android API studies with each of the four AALs in turn and finding that all major conclusions stay the same would show the discrepancies do not substantially influence results.

Figures

Figures reproduced from arXiv: 2604.14943 by Jiacheng Li, Lili Wei, Qi Zhang, Sinan Wang, Yepang Liu, Yida Tao.

Figure 1
Figure 1. 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 [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 3
Figure 3. 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… view at source ↗
Figure 5
Figure 5. Figure 5: Sample lines from the hiddenapi-flags.csv file Starting from Android 9, a series of APIs, called non-SDK inter￾faces, 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.c… view at source ↗
Figure 4
Figure 4. 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 [PITH_FULL_IMAGE:figures/full_fig_p004_4.png] view at source ↗
Figure 6
Figure 6. Figure 6: Research questions of our empirical study [PITH_FULL_IMAGE:figures/full_fig_p005_6.png] view at source ↗
Figure 7
Figure 7. Figure 7: API differences between each AALs (API-level 33) [PITH_FULL_IMAGE:figures/full_fig_p006_7.png] view at source ↗
Figure 8
Figure 8. 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 mem￾bers were inlined to the concrete classes while their abstract super classes were hidden in the AALs [PITH_FULL_IMAGE:figures/full… view at source ↗
read the original abstract

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 in-depth 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.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

1 major / 2 minor

Summary. The paper performs the first in-depth empirical study of four widely-used official Android API Lists (AALs). It characterizes their contents, analyzes evolution across releases, compares them to uncover inclusion policies and inconsistencies, checks API availability on nine devices (stock and vendor-customized), and examines API usage in 17,759 real-world apps. The key findings are that AALs are unstable and inconsistent, discrepancies can substantially influence research conclusions, and vendor-customized APIs are used by normal apps but overlooked.

Significance. If the results hold, this study is significant because it challenges the assumption in Android API-based research that official lists are interchangeable ground truth. The large-scale analysis provides concrete data on inconsistencies and real usage, which could improve reproducibility. The observation on vendor APIs highlights a gap in existing studies.

major comments (1)
  1. The claim in the abstract that discrepancies among AALs 'can substantially influence research conclusions' lacks direct supporting evidence. The paper reports set differences, per-app API counts, and overlap percentages but does not include a controlled proxy experiment demonstrating that substituting one AAL for another in a typical research pipeline (e.g., deprecation scanning, permission inference, or vulnerability detection) produces materially different statistical or qualitative outcomes. This is load-bearing for the primary claim about practical impact on research validity.
minor comments (2)
  1. The methods section should provide explicit details on selection criteria for the four AALs, nine devices, and 17,759 apps, as well as data exclusion rules, to allow assessment of representativeness.
  2. In the API usage analysis, clarify the detection approach for real-world apps and address potential false positives from dead code or obfuscation, including any statistical measures (e.g., error bars) on usage counts.

Simulated Author's Rebuttal

1 responses · 0 unresolved

Thank you for the constructive review of our manuscript. We appreciate the referee's focus on ensuring the evidence for our primary claims is robust and directly tied to research impact. We address the major comment below.

read point-by-point responses

  1. Referee: The claim in the abstract that discrepancies among AALs 'can substantially influence research conclusions' lacks direct supporting evidence. The paper reports set differences, per-app API counts, and overlap percentages but does not include a controlled proxy experiment demonstrating that substituting one AAL for another in a typical research pipeline (e.g., deprecation scanning, permission inference, or vulnerability detection) produces materially different statistical or qualitative outcomes. This is load-bearing for the primary claim about practical impact on research validity.

    Authors: We thank the referee for this observation. The usage analysis in Section 5 was intended to provide exactly this form of evidence by measuring how AAL choice alters the detected set of APIs in 17,759 real apps. Specifically, we report per-app differences in API counts (often exceeding 10-20% relative change) and Jaccard overlaps as low as 0.6-0.8 between AALs, which translate directly into different conclusions about API prevalence, deprecation status, and permission requirements. These metrics are foundational inputs to the pipelines mentioned (e.g., a deprecation scanner would flag different APIs; a vulnerability detector would consider different call sites). While we did not re-implement a complete prior study as a controlled proxy, the scale and diversity of the app corpus (open-source, commercial, and malware) demonstrate that the discrepancies are not marginal and would change statistical and qualitative outcomes in typical Android API research. We will revise the manuscript to strengthen the explicit mapping from our usage results to these pipelines and add a short illustrative proxy example (e.g., a simplified deprecation scan) if space allows. revision: partial

Circularity Check

0 steps flagged

No circularity: pure empirical measurement study with independent data comparisons

full rationale

The paper conducts direct empirical comparisons of four official AALs across Android releases, measures API availability on nine devices, and scans API usage in 17,759 apps. No equations, fitted parameters, predictions, or derivations exist that could reduce to inputs by construction. Claims rest on observable set differences, overlap statistics, and usage counts extracted from external sources (source code, devices, APKs), which are independently verifiable without self-reference. No self-citation load-bearing steps, uniqueness theorems, or ansatzes are invoked; the work is self-contained against external benchmarks.

Axiom & Free-Parameter Ledger

0 free parameters · 0 axioms · 0 invented entities

This is a purely empirical characterization study. No mathematical derivations, fitted constants, or new postulated entities are introduced. The only implicit assumptions are standard ones about API lists being extractable from source and usage being detectable in APKs.

pith-pipeline@v0.9.0 · 5593 in / 1275 out tokens · 39613 ms · 2026-05-10T11:09:25.514357+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

61 extracted references · 61 canonical work pages

  1. [1]

    Find all classes in a package in Android - Stack Overflow

    2013. Find all classes in a package in Android - Stack Overflow. Retrieved July 9, 2023 from https://stackoverflow.com/questions/15446036

    work page arXiv 2013

  2. [2]

    The Structure of the Java Virtual Machine

    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

    work page 2014

  3. [3]

    How does android generate ’current.txt’ it’s api description file? Retrieved June 5, 2023 from https://stackoverflow.com/questions/42036298/

    2017. How does android generate ’current.txt’ it’s api description file? Retrieved June 5, 2023 from https://stackoverflow.com/questions/42036298/

    work page arXiv 2017

  4. [4]

    pandalion98/SPay-inner-workings - GitHub

    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

    work page 2017

  5. [5]

    Improve your code with lint checks

    2018. Improve your code with lint checks. Retrieved May 25, 2023 from https://developer.android.com/studio/write/lint

    work page 2018

  6. [6]

    Restrictions on non-SDK interfaces

    2018. Restrictions on non-SDK interfaces. Retrieved May 25, 2023 from https://developer.android.com/guide/app-compatibility/restrictions-non- sdk-interfaces

    work page 2018

  7. [7]

    Test using the veridex tool

    2018. Test using the veridex tool. Retrieved May 25, 2023 from https://developer.android.com/guide/app-compatibility/restrictions-non- sdk-interfaces#test-veridex-tool

    work page 2018

  8. [8]

    3.0 Update - Samsung Members

    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

    work page arXiv 2021

  9. [9]

    Android API Differences Report

    2023. Android API Differences Report. Retrieved May 29, 2023 from https: //developer.android.com/sdk/api_diff/33/changes

    work page 2023

  10. [10]

    AndroidX Overview | JetPack | Android Developers

    2023. AndroidX Overview | JetPack | Android Developers. Retrieved May 29, 2023 from https://developer.android.com/jetpack/androidx

    work page 2023

  11. [11]

    sdkmanger

    2023. sdkmanger. Retrieved June 8, 2023 from https://developer.android.com/ tools/sdkmanager

    work page 2023

  12. [12]

    Apache HttpComponents - HttpClient for Android

    2024. Apache HttpComponents - HttpClient for Android. Retrieved June 26, 2023 from https://hc.apache.org/httpcomponents-client-4.5.x/android.html

    work page 2024

  13. [13]

    current.txt

    2024. current.txt. Retrieved June 12, 2023 from https://android.googlesource. com/platform/frameworks/base/+/refs/heads/main/core/api/current.txt

    work page 2024

  14. [14]

    MuntashirAkon/AppManager - GitHub

    2024. MuntashirAkon/AppManager - GitHub. Retrieved July 27, 2023 from https://github.com/MuntashirAkon/AppManager

    work page 2024

  15. [15]

    OpenGL ES Overview - The Khronos Group Inc

    2024. OpenGL ES Overview - The Khronos Group Inc. Retrieved July 5, 2023 from https://www.khronos.org/opengles/

    work page 2024

  16. [16]

    Gabriele Bavota, Mario Linares-Vasquez, Carlos Eduardo Bernal-Cardenas, Mas- similiano 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 Engineering41, 4 (2014), 384–407

    work page 2014

  17. [17]

    Haipeng Cai, Ziyi Zhang, Li Li, and Xiaoqin Fu. 2019. A large-scale study of application incompatibilities in Android. Inthe 28th ACM SIGSOFT International Symposium on Software Testing and Analysis

    work page 2019

  18. [18]

    Michael Cao, Khaled Ahmed, and Julia Rubin. 2022. Rotten apples spoil the bunch: An anatomy of Google Play malware. InProceedings of the 44th International Conference on Software Engineering. 1919–1931

    work page 2022

  19. [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. InSecurity and Privacy in Communication Networks: 14th International Conference, SecureComm 2018, Singapore, Singapore, August 8-10, 2018,...

    work page 2018

  20. [20]

    Zeinab El-Rewini and Yousra Aafer. 2021. Dissecting residual APIs in custom android ROMs. InProceedings of the 2021 ACM SIGSAC Conference on Computer and Communications Security. 1598–1611

    work page 2021

  21. [21]

    Mattia Fazzini, Qi Xin, and Alessandro Orso. 2019. Automated API-usage up- date for Android apps. InProceedings of the 28th ACM SIGSOFT international symposium on software testing and analysis. 204–215

    work page 2019

  22. [22]

    Dongjie He, Lian Li, Lei Wang, Hengjie Zheng, Guangwei Li, and Jingling Xue

    work page

  23. [23]

    InProceedings of the 33rd ACM/IEEE International Conference on Automated Software Engineering

    Understanding and detecting evolution-induced compatibility issues in android apps. InProceedings of the 33rd ACM/IEEE International Conference on Automated Software Engineering. 167–177

    work page

  24. [24]

    Huaxun Huang, Lili Wei, Yepang Liu, and Shing-Chi Cheung. 2018. Under- standing and detecting callback compatibility issues for android applications. In Proceedings of the 33rd ACM/IEEE International Conference on Automated Software Engineering. 532–542

    work page 2018

  25. [25]

    Huaxun Huang, Ming Wen, Lili Wei, Yepang Liu, and Shing-Chi Cheung. 2021. Characterizing and detecting configuration compatibility issues in android apps. In2021 36th IEEE/ACM International Conference on Automated Software Engineer- ing (ASE). IEEE, 517–528

    work page 2021

  26. [26]

    Huaxun Huang, Chi Xu, Ming Wen, Yepang Liu, and Shing-Chi Cheung. 2023. ConfFix: Repairing Configuration Compatibility Issues in Android Apps. InACM SIGSOFT International Symposium on Software Testing and Analysis

    work page 2023

  27. [27]

    Taeyeon Ki, Chang Min Park, Karthik Dantu, Steven Y Ko, and Lukasz Ziarek

    work page

  28. [28]

    In2019 IEEE/ACM 41st International Conference on Software Engineering (ICSE)

    Mimic: UI compatibility testing system for Android apps. In2019 IEEE/ACM 41st International Conference on Software Engineering (ICSE). IEEE, 246–256

    work page

  29. [29]

    Patrick Lam, Eric Bodden, Ondrej Lhoták, and Laurie Hendren. 2011. The Soot Framework for Java Program Analysis: A Retrospective. InCetus Users and Compiler Infastructure Workshop (CETUS 2011)

    work page 2011

  30. [30]

    Maxime Lamothe, Weiyi Shang, and Tse-Hsun Peter Chen. 2020. A3: Assisting android api migrations using code examples.IEEE Transactions on Software Engineering48, 2 (2020), 417–431

    work page 2020

  31. [31]

    Jiacheng Li, Kerui Huang, Sinan Wang, and Yepang Liu. 2023. Towards the Adoption and Adaptation of the AndroidX Library: An Empirical Study. In2023 IEEE 23rd International Conference on Software Quality, Reliability, and Security (QRS). IEEE, 418–427

    work page 2023

  32. [32]

    Li Li, Tegawendé F Bissyandé, Yves Le Traon, and Jacques Klein. 2016. Access- ing inaccessible android apis: An empirical study. In2016 IEEE International Conference on Software Maintenance and Evolution (ICSME). IEEE, 411–422

    work page 2016

  33. [33]

    Li Li, Tegawendé F Bissyandé, Haoyu Wang, and Jacques Klein. 2018. Cid: Automating the detection of api-related compatibility issues in android apps. InProceedings of the 27th ACM SIGSOFT International Symposium on Software Testing and Analysis. 153–163

    work page 2018

  34. [34]

    Li Li, Jun Gao, Tegawendé F Bissyandé, Lei Ma, Xin Xia, and Jacques Klein. 2018. Characterising deprecated android apis. InProceedings of the 15th International Conference on Mining Software Repositories. 254–264

    work page 2018

  35. [35]

    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

    work page 2019

  36. [36]

    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. InProceedings of the 2013 9th joint meeting on foundations of software engineering. 477–487

    work page 2013

  37. [37]

    Mario Linares-Vásquez, Gabriele Bavota, Massimiliano Di Penta, Rocco Oliveto, and Denys Poshyvanyk. 2014. How do api changes trigger stack overflow dis- cussions? a study on the android sdk. InProceedings of the 22nd International Conference on Program Comprehension. 83–94

    work page 2014

  38. [38]

    Pei Liu, Li Li, Yichun Yan, Mattia Fazzini, and John Grundy. 2021. Identifying and characterizing silently-evolved methods in the android API. In2021 IEEE/ACM 43rd International Conference on Software Engineering: Software Engineering in Practice (ICSE-SEIP). IEEE, 308–317

    work page 2021

  39. [39]

    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). InProceedings of the 31st ACM SIGSOFT International Symposium on Software Testing and Analysis. 617–628

    work page 2022

  40. [40]

    Mehran Mahmoudi and Sarah Nadi. 2018. The android update problem: An empirical study. InProceedings of the 15th International Conference on Mining Software Repositories. 220–230

    work page 2018

  41. [41]

    Tarek Mahmud, Meiru Che, and Guowei Yang. 2021. Android compatibility issue detection using api differences. In2021 IEEE International Conference on Software Analysis, Evolution and Reengineering (SANER). IEEE, 480–490

    work page 2021

  42. [42]

    Tarek Mahmud, Meiru Che, and Guowei Yang. 2023. Detecting Android API Com- patibility Issues With API Differences.IEEE Transactions on Software Engineering (2023)

    work page 2023

  43. [43]

    William Martin, Federica Sarro, Yue Jia, Yuanyuan Zhang, and Mark Harman

    work page

  44. [44]

    EASE 2026, 9–12 June, 2026, Glasgow, Scotland, United Kingdom Wang et al

    A survey of app store analysis for software engineering.IEEE transactions on software engineering43, 9 (2016), 817–847. EASE 2026, 9–12 June, 2026, Glasgow, Scotland, United Kingdom Wang et al

    work page 2016

  45. [45]

    Tyler McDonnell, Baishakhi Ray, and Miryung Kim. 2013. An empirical study of api stability and adoption in the android ecosystem. In2013 IEEE International Conference on Software Maintenance. IEEE, 70–79

    work page 2013

  46. [46]

    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. In2019 IEEE/ACM 16th International Conference on Mining Software Repositories (MSR). IEEE, 288–298

    work page 2019

  47. [47]

    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 Engineering25, 6 (2020), 5006–5046

    work page 2020

  48. [48]

    Bruno Silva, Clay Stevens, Niloofar Mansoor, Witawas Srisa-An, Tingting Yu, and Hamid Bagheri. 2022. SAINTDroid: Scalable, Automated Incompatibility Detection for Android. In2022 52nd Annual IEEE/IFIP International Conference on Dependable Systems and Networks (DSN). IEEE, 567–579

    work page 2022

  49. [49]

    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. In37th IEEE/ACM International Conference on Automated Software Engineering. 1–13

    work page 2022

  50. [50]

    Kimberly Tam, Ali Feizollah, Nor Badrul Anuar, Rosli Salleh, and Lorenzo Caval- laro. 2017. The evolution of android malware and android analysis techniques. ACM Computing Surveys (CSUR)49, 4 (2017), 1–41

    work page 2017

  51. [51]

    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. InProceedings of the 44th International Conference on Software Engineering. 125–137

    work page 2022

  52. [52]

    Sinan Wang, Ming Wen, Yepang Liu, Ying Wang, and Rongxin Wu. 2021. Under- standing and facilitating the co-evolution of production and test code. In2021 IEEE International conference on software analysis, evolution and reengineering (SANER). IEEE, 272–283

    work page 2021

  53. [53]

    Lili Wei, Yepang Liu, and Shing-Chi Cheung. 2016. Taming android fragmentation: Characterizing and detecting compatibility issues for android apps. InProceedings of the 31st IEEE/ACM International Conference on Automated Software Engineering. 226–237

    work page 2016

  54. [54]

    Lili Wei, Yepang Liu, and Shing-Chi Cheung. 2019. Pivot: learning api-device correlations to facilitate android compatibility issue detection. In2019 IEEE/ACM 41st International Conference on Software Engineering (ICSE). IEEE, 878–888

    work page 2019

  55. [55]

    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 Engineering46, 11 (2018), 1176–1199

    work page 2018

  56. [56]

    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 large- scale study. InProceedings of the ACM/IEEE 42nd International Conference on Software Engineering. 886–898

    work page 2020

  57. [57]

    Sen Yang, Sen Chen, Lingling Fan, Sihan Xu, Zhanwei Hui, and Song Huang

    work page

  58. [58]

    In45th International Conference on Software Engineering

    Compatibility Issue Detection for Android Apps Based on Path-Sensitive Semantic Analysis. In45th International Conference on Software Engineering

    work page

  59. [59]

    Shishuai Yang, Rui Li, Jiongyi Chen, Wenrui Diao, and Shanqing Guo. 2022. Demystifying Android non-SDK APIs: measurement and understanding. InPro- ceedings of the 44th International Conference on Software Engineering. 647–658

    work page 2022

  60. [60]

    Yanjie Zhao, Li Li, Kui Liu, and John Grundy. 2022. Towards automatically repairing compatibility issues in published android apps. InProceedings of the 44th International Conference on Software Engineering. 2142–2153

    work page 2022

  61. [61]

    Yanjie Zhao, Li Li, Haoyu Wang, Qiang He, and John Grundy. 2022. APIMatch- maker: Matching the Right APIs for Supporting the Development of Android Apps.IEEE Transactions on Software Engineering49, 1 (2022), 113–130

    work page 2022