How to Pet a Two-Headed Snake? Solving Cross-Repository Compatibility Issues with Hera

Android ecosystem is heavily fragmented. The numerous combinations of different device models and operating system versions make it impossible for Android app developers to exhaustively test their apps, and thus various compatibility issues arise. Unfortunately, little is known on the characteristics of such fragmentation-induced compatibility issues. No mature tools exist to help developers quickly diagnose and fix these issues. To bridge the gap, we conducted an empirical study on 220 real-world compatibility issues collected from five popular open-source Android apps. We further interviewed Android practitioners and conducted an online survey to gain insights from real practices. Via the studies, we characterized compatibility issues, investigated common practices to handle compatibility issues, and disclosed that these issues exhibit common patterns. With these findings, we propose a technique, FicFinder, to automatically detect compatibility issues in Android apps. FicFinder performs static code analysis based on a model that captures Android APIs as well as their associated context by which compatibility issues can be triggered. FicFinder reports actionable debugging information to developers when it detects potential issues. We evaluated FicFinder with 53 large-scale open-source Android apps. The results show that FicFinder can precisely detect compatibility issues in these apps and uncover previously-unknown issues.

Fragmentation is a serious problem in the Android ecosystem, which is mainly caused by the fast evolution of the system itself and the various system customizations. Many efforts have attempted to mitigate its impact via approaches to automatically pinpointing compatibility issues in Android apps. We conducted a literature review to identify all the currently available approaches to addressing this issue. Within the nine identified approaches, the four issue detection tools and one incompatible API harvesting tool could be successfully executed. We tried to reproduce them based on their original datasets and then empirically compared those approaches against common datasets. Our experimental results show that existing tool capabilities are quite distinct with only a small overlap in the compatibility issues being identified. Moreover, these detection tools commonly detect compatibility issues via two separate steps including incompatible APIs gathering and compatibility issues (induced by the incorrect invocations of the identified incompatible APIs) determination. To help developers better identify compatibility issues in Android apps, we developed a new approach, AndroMevol , to systematically spot incompatible APIs as they play a crucial role in issue detection. AndroMevol was able to pinpoint 397,678 incompatible APIs against the full history of the official Android framework and 52 customized Android frameworks spanning five popular device manufacturers. Our approach could enhance the ability of the state-of-the-art detection tools by identifying many more incompatible APIs that may cause compatibility issues in Android apps and foster more advanced approaches to pinpointing all types of compatibility issues.

Compatibility and stability issues in all-solid-state batteries and methods for investigation.

Android ecosystem is heavily fragmented. The numerous combinations of different device models and operating system versions make it impossible for Android app developers to exhaustively test their apps. As a result, various compatibility issues arise, causing poor user experience. However, little is known on the characteristics of such fragmentation-induced compatibility issues and no mature tools exist to help developers quickly diagnose and fix these issues. To bridge the gap, we conducted an empirical study on 191 real-world compatibility issues collected from popular open-source Android apps. Our study characterized the symptoms and root causes of compatibility issues, and disclosed that the patches of these issues exhibit common patterns. With these findings, we propose a technique named FicFinder to automatically detect compatibility issues in Android apps. FicFinder performs static code analysis based on a model that captures Android APIs as well as their associated context by which compatibility issues are triggered. FicFinder reports actionable debugging information to developers when it detects potential issues. We evaluated FicFinder with 27 large-scale open-source Android apps. The results show that FicFinder can precisely detect compatibility issues in these apps and uncover previously-unknown issues.

You have accessThe ASHA LeaderFeature1 Nov 2003Hearing Aids and Cell PhonesFast-Track Work Underway to Boost Compatibility Susan Boswell Susan Boswell Google Scholar More articles by this author https://doi.org/10.1044/leader.FTR5.08202003.1 SectionsAbout ToolsAdd to favorites ShareFacebookTwitterLinked In To make cell phones more compatible with hearing aids, ASHA is participating in the ATIS Hearing Aid Compatibility (HAC) Incubator program to develop fast-track solutions and testing protocols in response to a recent Federal Communications Commission (FCC) ruling. In July 2003, the FCC modified the exemption for wireless phones from hearing aid compatibility requirements and established compatibility rules for wireless service providers and handset manufacturers. Within two years, each handset manufacturer and each carrier must provide at least two handsets for each air interface that meets the U3 level for acoustic coupling. Within three years, handset manufacturers must offer at least two handsets that meet the U3T performance level for telecoil coupling as measured using the cited ANSI C63.19 measurement procedure. To meet the challenge, the HAC Incubator initiative—which is part of the Alliance for Telecommunications Industry Solutions (ATIS)—held its first meeting on Sept. 5, bringing together wireless service providers, handset and hearing aid manufacturers, audiologists, professional associations, members of the ANSI accredited standards committee (ASC) C63 (developers of the C63.19 standard), and universities. The work of the incubator “is integral to preserving access to wireless telecommunications to individuals with hearing disabilities,” said FCC Chair Michael Powell in a press release. This initiative “will significantly advance the commission’s commitment to ensuring that all Americans—whether or not they use hearing aids—have an opportunity to enjoy the benefits of wireless communications.” The HAC Incubator is leading an industry solution on electromagnetic compatibility (EMC) issues between hearing aids and cell phones. ASC C63 is leading the refinement and improvement of their test standard. Among the incubator tasks will be to assess the current hearing aid compatibility standard, ANSI C63.19; develop suggested changes to the standard’s methodologies for lab and user testing of digital wireless phones and hearing aids; and encourage implementation of its findings into new products. The group will share the results of its investigation with ASC C63, which has representation by the FCC and the U.S. Food and Drug Administration (FDA), as ASC C63 amends its document. As the ANSI C63.19 standard undergoes its next revision, “There will be a number of refinements and improvements in the testing methodology recommended and inputs from the incubator group are welcome as are other inputs to this open process,” said Donald Heirman, vice chair of ANSI ASC C63, which is responsible for all modifications to the C63.19 standard. As the practice for all ASCs, the full set of C63 standards are periodically reviewed to ensure that their content is technically current. “This will be the case if it is necessary to accommodate changes in cell phones and hearing aids that may affect their EMC assessment,” Heirman noted. While hearing aids are not required to provide immunity to radio frequency interference from cell phones, the FDA encourages manufacturers to label products according to the ANSI C63.19 standard and will determine whether the package labeling is compliant, noted Teri Cygnarowicz, an audiologist and scientific reviewer with the FDA Center for Devices and Radiological Health. “If the manufacturer labels their product as digital cell phone compatible, the FDA will look at how that determination was made.” Wireless phone manufacturers are required to provide package labeling indicating the rating of the handset and include information in the user manual explaining the rating system. The FDA will work with industry, ATIS, and FCC to provide outreach to help consumers and audiologists identify hearing aid-compatible phones. Real-World Solutions “It is exciting to see people coming together to come up with a real-world solution,” Cygnarowicz said, “but there’s a lot of work to be done because the compatibility issue is so complex.” The cell phone and hearing aid interface presents multifaceted challenges in developing standardized testing to measure compatibility, Cygnarowicz noted. Cellular technology is continually evolving. When the phone is in use, the signal strength changes from one location to another, and the hearing loss and amplification technology may present added variables. “A consumer may be wearing a really old hearing aid that may or may not be compatible, or a newer hearing aid that may or may not be compatible,” she said. “Because of all of the factors involved, it’s difficult to know what the result will be.” In developing test protocols to measure compatibility, the fit of the hearing aid must be verified if speech intelligibility through the wireless phone is measured, said Gail Linn, ASHA’s director of audiology practice in industry and private practice. During an informal presentation, Linn provided the ATIS Incubator with information about the process of hearing aid fitting, including the audiological evaluation, selection, physical and acoustic fit, and verification, and how these issues affect hearing aid use with cell phones. “If the consumer doesn’t have a hearing aid with good physical fit, it’s difficult to tell where the interference is coming from,” Linn said. ASHA played a key role in educating the telecommunications industry about the role of audiologists and the need for audiologists to be on hand while measuring cell phone compatibility, she added, emphasizing the need for collaboration and education. For more information on wireless compatibility with hearing aids, contact Linn by e-mail at [email protected] or through the Action Center at 800-498-2071, ext. 4112. HAC Resources Meeting of the Hearing Aid Compatibility Incubator of the Alliance for Telecommunications Industry Solutions (www.atis.org/PRESS/pressreleases2003/090503.htm) FCC ruling on wireless compatibility (http://hraunfoss.fcc.gov/edocs_public/attachmatch/FCC-03-168A1.doc) The Cellular Telecommunications and Internet Association has developed a Web site for consumers listing compatible wireless phones based on information supplied by manufacturers (http://www.accesswireless.org/) Center for Devices and Radiological Health, Cell Phone Facts—Consumer Information on Wireless Phones (http://www.fda.gov/cellphones) Advertising Disclaimer | Advertise With Us Advertising Disclaimer | Advertise With Us Additional Resources FiguresSourcesRelatedDetails Volume 8Issue 20November 2003 Get Permissions Add to your Mendeley library History Published in print: Nov 1, 2003 Metrics Downloaded 161 times Topicsasha-topicsleader_do_tagleader-topicsasha-article-typesCopyright & Permissions© 2003 American Speech-Language-Hearing AssociationLoading ...

The need for additional water resources by many water utilities and a corresponding interest in brackish water and seawater desalination necessitates new materials and equipment to treat more corrosive waters, such as brackish water, raw seawater, reverse osmosis permeate, and membrane concentrate. This article focuses on seawater applications and highlights approaches taken by agencies in Australia and the United States to maximize long-term value of components of their large-scale seawater desalination facilities. This includes examining material selection and compatibility issues that develop during design, construction, and operation, as well as how these issues were mitigated. It is also important to evaluate the impact of specialized materials on equipment availability and maintenance and to help engineers and utilities understand key material compatibility and material supply issues associated with constructing a seawater desalination facility.

As Android platform evolves in a fast pace, API-related compatibility issues become a significant challenge for developers. To handle an incompatible API invocation, developers mainly have two choices: merely performing sufficient checks to avoid invoking incompatible APIs on platforms that do not support them, or gracefully providing replacement implementations on those incompatible platforms. As providing more consistent app behaviors, the latter one is more recommended and more challenging to adopt. However, it is still unknown how these issues are handled in the real world, do developers meet difficulties and what can we do to help them. In light of this, this paper performs the first large-scale study on the current practice of handling evolution-induced API compatibility issues in about 300,000 Android market apps, and more importantly, their solutions (if exist). Actually, it is in general very challenging to determine if developers have put in counter-measure for a compatibility issue, as different APIs have diverse behaviors, rendering various repair. To facilitate a large-scale study, this paper proposes RAPID, an automated tool to determine whether a compatibility issue has been addressed or not, by incorporating both static analysis and machine learning techniques. Results show that our trained classifier is quite effective by achieving a F1-score of 95.21% and 91.96% in the training stage and the validation stage respectively. With the help of RAPID, our study yields many interesting findings, e.g. developers are not willing to provide alternative implementations when handling incompatible API invocations (only 38.4%); for those incompatible APIs that Google gives replacement recommendations, the ratio of providing alternative implementations is significantly higher than those without recommendations; developers find more ways to repair compatibility issues than Google's recommendations and the knowledge acquired from these experienced developers would be extremely useful to novice developers and may significantly improve the current status of compatibility issue handling.

Data pipelines are an integral part of various modern data-driven systems. However, despite their importance, they are often unreliable and deliver poor-quality data. A critical step toward improving this situation is a solid understanding of the aspects contributing to the quality of data pipelines. Therefore, this article first introduces a taxonomy of 41 factors that influence the ability of data pipelines to provide quality data. The taxonomy is based on a multivocal literature review and validated by eight interviews with experts from the data engineering domain. Data, infrastructure, life cycle management, development & deployment, and processing were found to be the main influencing themes. Second, we investigate the root causes of data-related issues, their location in data pipelines, and the main topics of data pipeline processing issues for developers by mining GitHub projects and Stack Overflow posts. We found data-related issues to be primarily caused by incorrect data types (33%), mainly occurring in the data cleaning stage of pipelines (35%). Data integration and ingestion tasks were found to be the most asked topics of developers, accounting for nearly half (47%) of all questions. Compatibility issues were found to be a separate problem area in addition to issues corresponding to the usual data pipeline processing areas (i.e., data loading, ingestion, integration, cleaning, and transformation). These findings suggest that future research efforts should focus on analyzing compatibility and data type issues in more depth and assisting developers in data integration and ingestion tasks. The proposed taxonomy is valuable to practitioners in the context of quality assurance activities and fosters future research into data pipeline quality.

Android apps are developed using a Software Development Kit (SDK), where the Android application programming interface (API) enables app developers to harness the functionalities of Android devices by interacting with services and hardware. However, API frequently evolves together with its associated SDK. The mismatch between the API level supported by the device where apps are installed and the API level targeted by app developers can induce compatibility issues. These issues can manifest themselves as unexpected behaviors, including runtime crashes, creating a poor user experience. In this paper, we propose ACID, a novel approach to detecting compatibility issues caused by API evolution. We leverage API differences and static analysis of the source code of Android apps to detect both API invocation compatibility issues and API callback compatibility issues. Experiments on 20 benchmark apps from previous studies show that ACID is more accurate and faster in detecting compatibility issues than state-of-the-art. We also analyzed 35 more real-world apps to show the practical applicability of our approach.

Android fragmentation refers to the overwhelming diversity of Android devices and OS versions. These lead to the impossibility of testing an app on every supported device, leaving a number of compatibility bugs scattered in the community and thereby resulting in poor user experiences. To mitigate this, our fellow researchers have designed various works to automatically detect such compatibility issues. However, the current state-of-the-art tools can only be used to detect specific kinds of compatibility issues (i.e., compatibility issues caused by API signature evolution), i.e., many other essential types of compatibility issues are still unrevealed. For example, customized OS versions on real devices and semantic changes of OS could lead to serious compatibility issues, which are non-trivial to be detected statically. To this end, we propose a novel, lightweight, crowdsourced testing approach, to fill this research gap and enable the possibility of taming Android fragmentation through crowdsourced efforts. Specifically, crowdsourced testing is an emerging alternative to conventional mobile testing mechanisms that allow developers to test their products on real devices to pinpoint platform-specific issues. Experimental results on thousands of test cases on real-world Android devices show that is effective in automatically identifying and verifying API-induced compatibility issues. Also, after investigating the user experience through qualitative metrics, users' satisfaction provides strong evidence that is useful and welcome in practice.

Android API is frequently updated, and compatibility issues may be induced when the API level supported by the device differs from the API level targeted by app developers. This paper presents ACID, an API compatibility issue detector for Android apps. ACID utilizes API differences and static analysis of Android apps to detect both API invocation compatibility issues and API callback compatibility issues. Our evaluation on 20 benchmark apps from previous studies shows that ACID is more accurate and faster in detecting compatibility issues than state-of-the-art techniques. We also ran ACID on 35 more real-world apps to demonstrate ACID’s practical applicability. ACID is available at https://github.com/TSUMahmud/acid and the demonstration video of ACID is available at https://youtu.be/XUNBPMIx2q4.

Android application programming interface (API) enables app developers to harness the functionalities of Android devices by interfacing with services and hardware using a Software Development Kit (SDK). However, API frequently evolves together with its associated SDK, and compatibility issues may arise when the API level supported by the underlying device differs from the API level targeted by app developers. These issues can lead to unexpected behaviors, resulting in a bad user experience. This article presents ACID, a novel approach to detecting Android API compatibility issues induced by API evolution. It detects both API invocation compatibility issues and API callback compatibility issues using API differences and static analysis of the app code. Experiments with 20 benchmark apps show that ACID is more accurate and faster than the state-of-the-art techniques in detecting API compatibility issues. The application of ACID on 2965 real-world apps further demonstrates its practical applicability. To eliminate the false positives reported by ACID, this article also presents a simple yet effective method to quickly verify the compatibility issues by selecting and executing the relevant tests from app's test suite, and experimental results demonstrate the verification method can eliminate most false positives when app's test suite has good coverage of the API usages.

The Android ecosystem has experienced rapid growth, resulting in a diverse range of platforms and devices. This expansion has also brought about compatibility issues that negatively impact user experiences and hinder app development productivity. Existing relevant studies are focused on and limited to the “static” sense of those issues (in terms of potentialities and proneness), while only addressing compatibility issues that possibly occur during app executions. In this paper, we present an extensive and longitudinal study on app compatibility issues that are disparate from yet complementary to prior studies, characterizing the incompatibilities based on actual , exercised observations and evidence at both installation and run time. With a dataset of 74,545 benign apps and 56,919 malicious apps over a span of 12 years (2010 through 2021) and ten Android versions, we extensively examine the prevalence and symptoms/effects and causes of, as well as the contributing factors to, installation-time and run-time compatibility issues. Our study reveals 12 major novel findings regarding Android app incompatibilities. Firstly ( Findings 1,2 ), installation-time incompatibilities persisted significantly over the 12 years, even more so in malware than benign apps. Secondly ( Findings 7,8 ), run-time compatibility issues were also seen persistently over time but only on specific Android platforms (such as API 26,27,etc.) and much less by malware than benign apps. Thirdly ( Findings 5,6,11,12 ), there is a significant (moderate/stronger) correlation between an app’s specified minSdkVersion and its incompatibilities (over all symptoms and/or with respect to one of its dominating symptom), with stronger correlations seen in malware than in benign apps, for both installation- and run-time incompatibilities. Similar observations hold (although with much stronger correlation in absolute terms) when considering, instead of the minSdkVersion itself, the gap between the app’s minSdkVersion and the SDK API level of the platform the app is installed to or runs on. Lastly ( Findings 3,4,9,10 ), installation-time incompatibilities are primarily caused by the utilization of architecture-incompatible native libraries within apps, while run-time incompatibilities are mainly attributed to API changes during the evolution of the Android SDK; the symptoms of run-time failures seen by malware are much more diverse than by benign apps. In addition to these insights, we provide practical recommendations for both app developers and end users on how to effectively address compatibility issues in Android apps, as well as how to devise effective defenses against malware from the compatibility perspectives.

An empirical study on compatibility issues in Android API field evolution

Python is a popular dynamic programming language. In recent years, many frameworks implemented in Python have been widely used for data science and web development. Similar to frameworks in other languages, the APIs provided by Python frameworks often evolve, which would inevitably induce compatibility issues in client applications. While existing work has studied the evolution of frameworks in static programming languages such as Java, little is known on how Python framework APIs evolve and the characteristics of the compatibility issues induced by such evolution. To bridge this gap, we take a first look at the evolution of Python framework APIs and the resulting compatibility issues in client applications. We analyzed 288 releases of six popular Python frameworks from three different domains and 5,538 open-source projects built on these frameworks. We investigated the evolution patterns of Python framework APIs and found that they largely differ from those of Java framework APIs. We also investigated the compatibility issues in client applications and identified common strategies that developers adopt to fix these issues. Based on the empirical findings, we designed and implemented a tool, P <inf xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">Y</inf> C <inf xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">OMPAT</inf> , to automatically detect compatibility issues caused by misusing evolved framework APIs in Python applications. Experiments on 10 real-world projects show that our tool can effectively detect compatibility issues of developers' concern.