Ever since its initial release in 2008, the Android OS has rapidly grown to become the world’s most widely used mobile OS. Mobile vendors extend the Android Open Source Project (AOSP) led by Google to customize their own Android variants. With the AOSP releasing new versions frequently, vendors need to periodically carry out Android upgrades that integrate the latest code changes from AOSP into their Android variants. Both the AOSP and Android variants independently undergo complex modifications. Consequently, Android upgrades often lead to merge conflicts caused by competing changes to the same code line. Vendors have devoted significant effort to understanding and resolving these problems. Despite extensive research on Android upgrades and merge conflicts, there is little understanding of the conflict-related activities performed in Android upgrade practice, and the corresponding challenges faced by practitioners . In this study, we employed a qualitative research methodology involving questionnaires with 120 practitioners and interviews with a leading Android vendor to explore the challenges and improvement opportunities. Our investigation demonstrates that the Android upgrade process is fundamentally an exercise in architectural evolution, necessitating the adoption of architectural thinking rather than relying on mere code-level patches to systematically address upgrade-induced challenges. We have identified challenges at different stages of Android upgrade implementation, including baseline analysis, conflict reason analysis, conflict resolution, and conflict impact analysis. Our findings indicate opportunities for enhancing the Android upgrade practice, particularly in documentation, management, refactoring activities, and team collaboration. Additionally, we outline future research directions from an architectural perspective. We envision that our study can benefit software ecosystems where customized downstream derivatives need to maintain co-evolution with their upstream core.

Phone vendors customize their Android variants to enhance system functionalities based on the Android Open Source Project (AOSP). While independent development, Android variants have to periodically evolve with the upstream AOSP and merge code changes from AOSP. Vendors have invested great effort to maintain their variants and resolve merging conflicts. In this paper, we characterize the design smells with recurring patterns that break the design boundary between Android variants and AOSP. These smells are manifested as problematic dependencies across the boundary, hindering Android variants' maintainability and co-evolution with AOSP. We propose the DroidDS for automatically detecting design smells. We collect 22 Android variant versions and 22 corresponding AOSP versions, involving 4 open-source projects and 1 industrial project. Our results demonstrate that: files involved in design smells consume higher maintenance costs than other files; these infected files are not merely the files with large code size, increased complexity, and object-oriented smells; the infected files have been involved in more than half of code conflicts induced by re-applying AOSP's changes to Android variants; a substantial portion of design issues could be mitigable. Practitioners can utilize our DroidDS to pinpoint and prioritize design problems for Android variants. Refactoring these problems will help keep a healthy coupling between diverse variants and AOSP, potentially improving maintainability and reducing conflict risks.

During long-term software evolution, it is inevitable that an accumulation of changes leads to architectural erosion and debt. Diverse metric-based methods have been developed to identify architectural problems that violate design principles and degrade software maintainability. However, there still exists a gap between the implementation-level metrics and architecture-level metrics. Consequently, it hinders the comprehensibility, interpretability, and indicative(-bility) of the measurement results. To fill this gap, we propose the dbMIT to identify potential code changes that make architecture decay. Our dbMIT first integrates popular metrics such as the CK suite. Then dbMIT constructs a forest structure of metrics, serving as a knowledge base to relate the metrics across levels together. The forest aims to link the architecture-level metrics and implementation-level metrics. Via pre-defined rules using the forest structure, our dbMIT identifies code changes that potentially cause the architecture decay. The usage of forest structure of metrics makes it easy for developers to understand detection results, explain why the detected code changes are potential contributors to the decay, and indicate the code scope for resolution. We also contribute a web-based tool to integrate our dbMIT. Our experiments on the collected projects demonstrate the effectiveness of dbMIT against a history-based ground-truth.