Figure 5 - uploaded by Salmin Sultana
Content may be subject to copyright.
Different Types of Code Modifications. Total number of modifications considered for this analysis was 233.
Source publication
As smart phones grow in popularity, manufacturers are in a race to pack an increasingly rich set of features into these tiny devices. This brings additional complexity in the system software that has to fit within the constraints of the devices (chiefly memory, stable storage, and power consumption) and hence, new bugs are revealed. How this evolut...
Context in source publication
Context 1
... Add/modify cond: Add some new checks (if-stmt), or add a missing else clause, or modify the condition expression. 4. Modify settings: Update system constants or include modification in the makefiles, application configuration files etc. 5. Add/modify func call: Introduce a new function call, or modify the arguments of an existing invocation. 6. Lock problems: Bug was caused because a critical segment was not locked or a lock was not removed and deleted upon exit. 7. Add/modify lib ref: Bug was caused because code was accessing some non-existent or incorrect libraries or classes. 8. Modify data type: Update the datatype of a variable. 9. Preprocess change: Introduce a preprocessor directive (e.g. adding an ifdef ). 10. Reorganize code: Change the order of execution of certain code blocks. 11. Others: The bug fixes that could not be placed under any of the above-mentioned categories are considered here. In our analysis, some fixes contained multiple changes (e.g. some bugs needed both modification of settings and addition of new attribute values), hence, they were considered under both the categories. We show the breakup of the different bug fix categories in Fig. 5. We observe that only 22% of the fixes required major changes. These modifications primarily include addition of new functions, data structures, and constants. Among the rest, most of the fixes were of the type Add/modify attr value (16%) and Add/modify cond (15%). The large percentage of Add/modify attr val (16%) arises due to the fact that some applications/drivers in Android are still undergoing major code revisions. The list of changes may be seen from the release notes of different versions of Android. Within the sizable category Add/modify cond , we observed several instances where an if-stmt did not have a corresponding else clause. This resulted in exceptional cases not being handled correctly. Detailed specification of the program behavior could have avoided such errors. It is known that introducing new conditional statements adds to the cyclomatic complexity of a program. Hence, while implementing these fixes, the designers must be careful so that understandability and testability of the resulting code is not altered significantly, e.g., if a fix introduces a high degree of nesting for conditional statements, the designers may try to simplify by reorganizing the code. The presence of 11% Modify settings bugs motivated us to delve deeper into the Android code base and analyze the flexibilty provided by Android runtime environment to the upper layer applications. The customizability claim is buttressed by the fact that Android may be adapted for a wide range of mobile hardware (people have even used it to run notebooks), it incorporates virtual machine, Sqlite for data storage, and the fact that people may use their phone to write programs. We observed that a large chunk of the failures requir- ing Modify Settings surfaced during building (compiling) the Android source code. This resulted in modifications of the Makefiles to support new architectures and APIs, modification of environment variables, changing application permissions etc. Note that many of the application configuration files are also generated during the build process itself. Hence, we consider that Modify settings errors relate to customizability of the system, where customizability is defined to include both the process of building the system and of executing the system. However, this category of bugs only covers a subset of the errors caused by the need to support customizability. According to our categorization, if a new condition needs to be introduced to handle a configuration parameter, that would be classified under Add/Modify cond , while some support for customizability may necessitate large changes in the software (considered under the category Major ). Thus, the percentage of bugs to support customizability is non-trivial. This suggests that customizability does have some negative impact on the reliability. But this is not egregiously high for the level of customizability supported by Android. Further, improvements in software practices, especially targeted at the problematic segments that we have identified here, plus a natural maturing of the code base (recollect that we are talking of something that has been open sourced for only about a year and a half) will likely bring these bug incidences down. We observe that applications often read system configurations and locations of various executables from the environment variables defined in the runtime kernel. These parameters, though not comprehensive, are a significant indicator of a framework’s customizability. Extending from the conclusions in the previous section, we counted the number of environment variables defined in the ...
Citations
... Many studies have conducted qualitative mobile-bug reports platform analysis [5,11,30] and Android-related bug reporting tool [35]. Markus et al. [31] propose a Braille interface platform named MOST with such a wide range of applications. ...
... One extremely large and successful community that has received considerable text mining attention is that of the Android OS. Studies have examined where bugs are most prevalent in the Android architecture [14], the quality of various types of bug reports [15], top user concerns and the attention they receive from the Android community [6], and the scale and severity of Android security threats as reported by its stakeholders [16]. With Android devices now leading mobile device sales [17], it is fitting that the text mining community would look to understand this platform and provide improvement advice. ...
... Although the Android issue tracker is publicly hosted, and so is likely to capture a wide range of the community's concerns [14], issues may also be informally communicated and addressed within the development teams at Google. Similarly, unreported issues are not captured by our analysis. ...
Text mining approaches are being used increasingly for business analytics. In particular, such approaches are now central to understanding users' feedback regarding systems delivered via online application distribution platforms such as Google Play. In such settings, large volumes of reviews of potentially numerous apps and systems means that it is infeasible to use manual mechanisms to extract insights and knowledge that could inform product improvement. In this context of identifying software system improvement options, text mining techniques are used to reveal the features that are mentioned most often as being in need of correction (e.g., GPS), and topics that are associated with features perceived as being defective (e.g., inaccuracy of GPS). Other approaches may supplement such techniques to provide further insights for online communities and solution providers. In this work we augment text mining approaches with social network analysis to demonstrate the utility of using multiple techniques. Our outcomes suggest that text mining approaches may indeed be supplemented with other methods to deliver a broader range of insights.
... While previous work has considered where most software issues are localized (Kumar Maji et al. 2010), the nature and volume of these issues have not been considered. Applications of the Pareto principle to software development have shown that power-law behavior applies to software fault localization -80% of software defects are typically found in 20% of the components (e.g., Boehm 1987) -suggesting that specific types of features consume most developer rework effort (Louridas et al. 2008). ...
... Of note is that frequently requested features are all end-user facing, and thus likely affected a large cohort of users. Our findings here lend support to those previously noted by Kumar Maji et al. (2010), who found that app-related defects dominated the early versions of Android. Here we see a similar pattern in end-user calls for system enhancements. ...
... Although the Android issue tracker is publicly hosted, and so is likely to capture a wide range of the community's concerns (Kumar Maji et al. 2010), issues may also be informally communicated and addressed within the development teams at Google. We also accept that there is a possibility that we could have missed misspelt features. ...
It is known that user involvement and user-centered design enhance system acceptance, particularly when end-users' views are considered early in the process. However, the increasingly common method of system deployment, through frequent releases via an online application distribution platform, relies more on post-release feedback from a virtual community. Such feedback may be received from large and diverse communities of users, posing challenges to developers in terms of extracting and identifying the most pressing requests to address. In seeking to tackle these challenges we have used natural language processing techniques to study enhancement requests logged by the Android community. We observe that features associated with a specific subset of topics were most frequently requested for improvement, and that end-users expressed particular discontent with the Jellybean release. End-users also tended to request improvements to specific issues together, potentially posing a prioritization challenge to Google.
... Researchers have thus examined this interface to understand various aspects of the Android OS. For instance, Kumar Maji et al. [13] studied issues reported for four early versions of the Android OS (versions 1.1, 1.5, 1.6 and 2.0) and found most defects to be present in the application layer. Guana et al. [5] classified 8,597 Android OS issues in four layers of this OS (application framework, library, android runtime and Linux kernel), omitting those that were suspected to be in the application layer. ...
... Although the Android issue tracker is publicly hosted, and so is likely to capture most of the community's concerns [13], issues may also be informally communicated to and addressed within the development teams at Google. Similarly, unreported issues are not captured by our analysis. ...
Context: Post-release user feedback plays an integral role in improving software quality and informing new features. Given its growing importance, feedback concerning security enhancements is particularly noteworthy. In considering the rapid uptake of Android we have examined the scale and severity of Android security threats as reported by its stakeholders. Objective: We systematically mine Android issue logs to derive insights into stakeholder perceptions and experiences in relation to certain Android security issues. Method: We employed contextual analysis techniques to study issues raised regarding confidentiality and privacy in the last three major Android releases, considering covariance of stakeholder comments, and the level of consistency in user preferences and priorities. Results: Confidentiality and privacy concerns varied in severity, and were most prevalent over Jelly Bean releases. Issues raised in regard to confidentiality related mostly to access, user credentials and permission management, while privacy concerns were mainly expressed about phone locking. Community users also expressed divergent preferences for new security features, ranging from more relaxed to very strict. Conclusion: Strategies that support continuous corrective measures for both old and new Android releases would likely maintain stakeholder confidence. An approach that provides users with basic default security settings, but with the power to configure additional security features if desired, would provide the best balance for Android's wide cohort of stakeholders.
... Mojica et al. [24] studied code reuse in 4,323 Android apps and found that, on average, 61% in the classes in a mobile app are reused by other apps in the same domain (e.g., social networking), also found that 23% of the 534,057 classes in their case study inherit from a class in the Android platform. Maji et al. [25] studied defect reports in the Android and Symbian platforms to understand where defects occur in these platforms and how defects are fixed. The authors determine that development tools, web browsers, and multimedia modules are the most defect-prone and that most defects require minor code changes. ...
... This growing trend is reinforced by the fierce competition among device vendors, which need to release new products at a fast pace, and which heavily customize the mobile OS to differentiate their products [6]- [8]. Unfortunately, this complexity also increases the likelihood of faults from the components of the mobile stack, including hardware-abstraction libraries, native processes, device drivers, etc. [9]- [11]. The mobile OS needs to manage these faults to prevent failures of the mobile device. ...
The reliability of mobile devices is a challenge for vendors, since the mobile software stack has significantly grown in complexity. In this paper, we study how to assess the impact of faults on the quality of user experience in the Android mobile OS through fault injection. We first address the problem of identifying a realistic fault model for the Android OS, by providing to developers a set of lightweight and systematic guidelines for fault modeling. Then, we present an extensible fault injection tool (AndroFIT) to apply such fault model on actual, commercial Android devices. Finally, we present a large fault injection experimentation on three Android products from major vendors, and point out several reliability issues and opportunities for improving the Android OS.
... Federal University of Campina Grande -UFCG, Aprigio Veloso Street, 882, Campina Grande, Brazil system development demands greater attention to the reliability aspects of applications of these mobile devices. As demonstrated in some studies [2], [3], [4], mobile applications are not bug-free, and new software engineering approaches are required to test these applications [5]. ...
Context
Mobile devices, such as smartphones, have increased their capacity of information processing and sensors have been aggregated to their hardware. Such sensors allow capturing information from the environment in which they are introduced. As a result, mobile applications that use the environment and user information to provide services or perform context-based actions are increasingly common. This type of application is known as context-aware application. While software testing is an expensive activity in general, testing context-aware applications is an even more expensive and challenging activity. Thus, efforts are needed to automate testing for context-aware applications, particularly in the scope of Android, which is currently the most used operating system by smartphones.
Objective
This paper aims to identify and discuss the state-of-the-art tools that allow the automation of testing Android context-aware applications.
Method
In order to do so, we carried out a systematic mapping study (SMS) to find out the studies in the existing literature that describe or present Android testing tools. The discovered tools were then analyzed to identify their potential in testing Android context-aware applications.
Result
A total of 68 works and 80 tools were obtained as a result of the SMS. From the identified tools, five are context-aware Android application testing tools, and five are general Android application testing tools, but support the test of the context-aware feature.
Conclusion
Although context-aware application testing tools do exist, they do not support automatic generation or execution of test cases focusing on high-level contexts. Moreover, they do not support asynchronous context variations.
... They reported that the propagation time of the API references to be updated is around 14 months. Maji et al. (2010) applied a failure characterization study on Android and Symbian apps. They investigate the relationship between bugs, locations of the bugs in the code and code changes. ...
The competitive market of mobile applications (apps) has driven app developers to pay more attention to addressing the issues of mobile apps. Prior studies have shown that addressing the issues that are reported in user-reviews shares a statistically significant relationship with star-ratings. However, despite the prevalence and importance of user-reviews and issue reports prioritization, no prior research has analyzed the relationship between issue reports prioritization and star-ratings. In this paper, we integrate user-reviews into the process of issue reports prioritization. We propose an approach to map issue reports that are recorded in issue tracking systems to user-reviews. Through an empirical study of 326 open-source Android apps, our approach achieves a precision of 79% in matching user-reviews with issue reports. Moreover, we observe that prioritizing the issue reports that are related to user-reviews shares a significant positive relationship with star-ratings. Furthermore, we use the top apps, in terms of star-ratings, to train a model for prioritizing issue reports. It is a good practice to learn from the top apps as there is no well-established approach for prioritizing issue reports. The results show that mobile apps with a similar prioritization approach to our trained model achieve higher star-ratings.
... Then, we collect the number of issues in each issue topic and compare the number of issues across the iOS and Android platforms for each case study system. We randomly selected 3,000 issues from Chromium (2,297 bug reports sampled from the Android platform, and 703 bug reports from iOS) and 3,000 from Firefox (1,500 for each platform) to perform the LDA analysis, since this represents a sample with a 99% confidence level and a 2% confidence interval 4 . We did not run the LDA analysis on all the bugs despite the approach be fully automatic because, there were more bugs in Firefox than in Chromium. ...
... The fact that Android has to deal with a heterogeneous set of devices explains why Topic 7 is more prevalent on Android, while it is unclear why offline use is more of an issue for iOS apps. 4 Smaller, but still substantial differences between Android and iOS are shared between Firefox and Chromium for Topics 2 and 5. Topic 2 appears to concern playing and controlling video content, while Topic 5 appears to concern browser tabs and how many can be opened. Again, it is unclear why Android is more prone to video content issues (Topic 2) than iOS, and iOS more prone to tab issues than Android. ...
... Maji et al. [4] analyzed the reported cases of failures of two operating systems, Android and Symbian, based on issue reports. These reports had been provided by end users, third-party developers, and documentation of issue fixes from Android developers. ...
... However, they did not discuss other types of Android-specific bugs and their solutions. Maji et al. [11] performed a characterization study on failures in Android and Symbian platforms. They also discussed the solutions implemented by developers in fixing the bugs. ...
Android platform provides a unique framework for app development. Failure to comply with the framework may result in serious bugs. Android platform is also evolving rapidly and developers extensively use APIs provided by the framework, which may lead to serious compatibility bugs if developers do not update the released apps frequently. Furthermore, Android apps run on a wide range of memory-constrained devices, which may cause various device-specific and memory-related bugs. There are several other Android-specific issues that developers need to address during app development and maintenance. Failure to address the issues may result in serious bugs manifested as crashes. In this paper, we perform an empirical study to investigate and characterize various Android-specific crash bugs, their prevalence, root causes, and solutions by analyzing 1,862 confirmed crash reports of 418 open source Android apps. The investigation results can help app developers in understanding, preventing, and fixing the Android-specific crash bugs. Moreover, the results can help app developers and researchers in designing effective bug detection tools for Android apps.
