Software Engineering for OpenHarmony: The Research Roadmap

Table of Links

Introduction

Background of OpenHarmony

The State Of OpenHarmony Ecosystem

Overview Of Mobile Software Engineering

The Research Roadmap

Discussion

Related Work

Conclusion & References

5 THE RESEARCH ROADMAP

As our initial attempt to prompt software engineering research for OpenHarmony, we now present the preliminary research roadmap by summarizing the research gaps between Android/iOS and OpenHarmony. When detailing the gaps, we also present example works that we believe should be also proposed for OpenHarmony. We hope these works could be contributed by our fellow researchers so as to fill the aforementioned gaps, making OpenHarmony a popular mobile platform and a popular research topic in the mobile software engineering field.

5.1 Gap in App-related Research

As highlighted in Section 4, the majority of MSE studies focus on mobile apps. At the beginning of this section, we first summarize some of the representative works that propose software engineering techniques to support their studies. Specifically, we summarize them based on the general software development processes, including Requirement, Design, Development, Test, Code Review, and Deployment. As expected, there are fewer works that target the phases before app development. Indeed, most of the works are proposed to examine mobile apps once they are developed.

(1) [Requirement] Mining User Reviews for Requirement Analysis. Since it is generally not possible to obtain the original requirements of mobile apps (e.g., what functions to offer and how should they be interacted with users), which are often considered confidential, the research community mainly focuses on mining user reviews for requirement understanding. Here, user reviews can be collected either through actual interviews or through user comments made to the app’s releasing page on the app store. Fortunately, such efforts can directly be leveraged to improve OpenHarmony apps as the identified requirements are often independent to mobile platforms. Nevertheless, the proposed techniques could be also leveraged to mine user reviews that are specifically made to OpenHarmony apps.

−→Representative Works: Chen et al. [21] argue that it is possible to dig out user needs and preferences by analyzing user online comments, which can subsequently benefit app developers to make accurate market positioning and thereby increase the volume of app downloads. By using a set of NLP techniques such as semantic analysis, word frequency analysis, the authors demonstrate the possibility to obtain useful requirements. Similarly, Palomba et al. [84] propose to support the evolution of mobile apps via crowdsourcing user reviews. By surveying 73 developers, they have found that over 75% of developers will take user reviews into consideration when updating their apps and such updates are often rewarded in terms of significant increases of user ratings.

(2) [Design] Sketch Recognizing App designers often use sketches to quickly draw the app’s user interfaces so as to accelerate the iterative design process when designing apps. Such sketches, however, cannot be directly used to build a prototype app that can be immediately tested to collect user feedback. To bridge the gap, researchers have proposed techniques to automatically recognize sketches and subsequently transform them into UI components. In this way, app developers can focus on designing the user experience rather than building the prototypes with various tools. Such approaches could be extremely beneficial to OpenHarmony developers when designing their apps.

−→Representative Works: Kim et al. [52] have presented to the community an approach to identify UI widgets of mobile apps directly from sketch images using geometric and text analysis features. the extraction of graphic elements such as text or shapes from the input sketch image using the Optical Character Recognition (OCR) technique and edge detection. Similarly, Li et al. [68] have proposed to the community a sketch-based prototyping tool called Xketch for accelerating mobile app design processes. They have demonstrated that Xketch is indeed useful and can benefit app developers in designing apps quickly on their tablets.

(3) [Design] Visual Search for Recommending Design Examples. Since it is non-trivial to design a beautiful user interface from scratch, developers often resort to relative UI design examples to gain inspiration and compare design alternatives. However, finding such design examples is challenging as existing search systems only support text-based queries. To mitigate this, our community has proposed to conduct a visual search, which takes as input a UI design image and outputs visually similar designs. Since visual search is independent of mobile platforms, such efforts can directly be leveraged to benefit the OpenHarmony community as well. Nevertheless, OpenHarmony apps may have specific preferences in their UI pages, there is also a need to invent dedicated visual search systems for supporting the design of OpenHarmony apps.

−→Representative Works: Bunian et al. [17] have proposed to the community a visual search system, which includes an object-detection based image retrieval framework that models the UI context and hierarchical structure. Based on a large-scale UI dataset, the authors have shown that their visual search framework can achieve high performance in querying similar UI designs.

(4**) [Development] Code Recommendation**. Mobile apps are developed based on an official SDK with thousands of APIs, and there are hundreds of thousands of APIs available in the wild through the so-called third-party libraries. there is hence a strong need to automatically recommend appropriate APIs (or libraries) for developers to choose when they implement their apps. Furthermore, libraries have been demonstrated to be extremely useful for facilitating app development as they provide lots of existing function implementations that are reusable and are often high-quality (e.g., being already validated by their various usages). It is not uncommon to encourage developers to leverage third-party libraries for implementing OpenHarmony apps. As the number of available libraries keeps growing, it is non-trivial for developers to search for the appropriate libraries. Therefore, there is a strong need to automatically recommend the required libraries for OpenHarmony app developers.

−→Representative Work: Zhao et al. [122] have presented to the community a prototype tool called APIMatchmaker that automatically matches the correct APIs for supporting the development of Android apps. The recommended APIs are learned from other Android apps that are deemed similar to the one under development. As another example, Yuan et al. [116] propose to leverage API search engine to recommend function APIs and they go one step further to demonstrate the need to recommend event callbacks (that need to be overridden to contain function code) for developers.

(5) [Development] GUI Component Implementation. Mobile apps involve lots of icons. To maintain the same look and feel, similar GUI components (icons or animations) across different mobile apps often reserve similar functionalities. Therefore, it is possible to learn the semantics behind popular GUI components and subsequently recommend code implementations to developers when relevant GUI components are used.

−→Representative Work: Zhao et al. [121] have proposed an approach called Icon2Code that leverages an intelligent recommendation system for helping app developers efficiently and effectively implement the callback methods of Android icons. The recommendation system is built based on a large-scale dataset that contains mappings from icons to their code implementations. Similarly, Wang et al. [104] have proposed an approach to recommend APIs for implementing Android UI animations. This approach constructs a database containing mappings between UI animations in GIF/video format and their corresponding APIs and subsequently leverages it to achieve the recommendation.

(6) [Test] Random Testing (Test Case Generation). Mobile apps, like any other software, need to be adequately tested before being released to app users. There is no difference when applied to OpenHarmony. There are at least two scenarios that require generating test cases to ensure that the apps behave as expected. The first one is to generate test cases for unit tests, which only ensures the correctness of certain functions. The second one is to generate inputs for apps that run on Mobile operating systems. The OpenHarmony community has similar requirements. Random testing has been regarded as one of the most useful tools for generating test cases to explore mobile apps due to its easy-of-use and scalability. Our fellow researchers have shown that Monkey, a simple approach and tool for random testing of Android apps, is surprisingly effective, outperforming much more sophisticated tools by achieving higher code coverage. In OpenHarmony, we believe this random testing approach is also required, which is also the base for supporting the implementation of many advanced app testing tools.

−→Representative Work: Amalfitano et al. [5] have presented to the community a research prototype named AndroidRipper, which embeds an automated technique that tests Android apps via their Graphical User Interface (by automatically explores the app’s GUI with the aim of exercising the application in a structured manner). Existing experimental results show that AndroidRipper outperforms the random testing approach, being capable of detecting severe and previously unknown faults in open-source Android apps. Li et al. [69] have presented to the community another automated test input generator for Android apps. The tool, named DroidBot, is designed to be lightweight (no need to instrument the app under testing) and supports customization to fulfill dedicated testing GUI-guided strategies. Similarly, in the field of iOS, Wu et al. [108] have presented to the community a model-based testing framework called CydiOS for randomly testing iOS apps. The CydiOS tool has been made publicly available as an open-source project by its authors.

(7) [Test] Mock Testing. Performing unit tests for mobile apps, including OpenHarmony apps, is non-trivial. Indeed, certain functions under testing require the context that is a part of the app’s lifecycle or the system. This context information is only available when the app is running on the mobile system, which is contradictory to the fact that unit tests do not expect to have the apps actually run on mobile devices.

−→Representative Work: There are several well-known frameworks such as Mockito in MSE that are provided by practitioners to support mock unit testing. Similar frameworks are highly demanded by the OpenHarmony community as well. On the research side, Beresford et al. [14] have proposed to the community a novel approach called MockDroid that allows a user to ’mock’ an app’s access to a resource. The resource is subsequently reported as empty or unavailable whenever the app requests it. Their work is demonstrated to be useful for testing mobile apps w.r.t. their tolerance to resource failures.

(8) [Test] Targeted Fuzzing. Nowadays, mobile apps are running on touch-sensitive displays involving many GUI pages, for which each of them involving various lifecycle methods and containing various widgets that are further associated with callback methods. Such a complex setting makes it difficult to achieve highly efficient random testing. To mitigate this, researchers propose to conduct targeted fuzzing, e.g., by generating test inputs that allow the app to reach a certain state. OpenHarmony apps are GUI-intensive as well and the drawbacks of random testing would also apply to them. Hence, there is also a strong need to invent targeted fuzzing approaches to properly test OpenHarmony apps.

−→Representative Work: Rasthofer et al. [90] present to the community a targeted fuzzing approach, namely FuzzDroid, for automatically generating an Android execution environment where an app exposes malicious behavior. This objective is achieved by combining an extensible set of static and dynamic analyses through a search-based algorithm that steers the app toward a configurable target location. As another example, Azim et al. [10] present another approach called 𝐴 3𝐸 that uses static, taint-style, dataflow analysis to first conduct a high-level control flow graph that captures legal transitions among app screens. 𝐴 3𝐸 then performs targeted exploration to achieve fast, direct exploration of activities.

(9) [Test] Record-and-Replay. Mobile apps, after being released to the public, need to be run on multiple devices that may run different framework versions. Those devices may also have different screen sizes with customized framework versions. To ensure the same app can be correctly run on all of those devices, researchers propose to conduct Record-and-Replay testing, which first records a testing scenario on a device and then applies it to other devices, with the expectation of achieving the same testing results. As one of the most important features of OpenHarmony is to support the so-called “1+8+N” strategy (i.e., supporting one major device (i.e., smartphone), 8 important devices such as TV, Smartwatch, Pad, PC, etc., and many other user-customized devices, this record-and-replay technique is extremely important for OpenHarmony to ensure the “1+8+N” strategy to be successful.

−→Representative Work: Gomez et al. [42] present a prototype tool called RERAN that achieves timing- and touch-sensitive record-and-replay for Android. RERAN attempts to directly capture the low-level event stream on the phone and replay it later on with microsecond accuracy. Since mobile apps may be run on different devices with diverse screen sizes, a record-and-replay tool may be applied to apps that could have different GUI layouts on different devices. To accommodate that, Guo et al. [44] present another record-and-replay tool called Sara that achieves such a purpose through an adaptive replay mechanism with a dynamic instrumentation approach for taking into account the rich sources of inputs in current mobile apps.

(10) [Test] Crowdsourced Testing. Automated app testing cannot achieve 100% coverage and hence user commitments are always needed in order to ensure the quality of mobile apps. However, manually exploring an app in a comprehensive way is difficult and time-consuming. To alleviate that, researchers have proposed to leverage crowdsourcing efforts to achieve the aforementioned testing purpose. Indeed, crowdsourced testing provides a promising way to conduct large-scale and user-oriented testing scenarios. Such an approach could be also leveraged to comprehensively test OpenHarmony apps.

−→Representative Work: Ge et al. [39] find that most crowdsourced app testing is of low quality as crowd workers are often unfamiliar with the app under test and do not know which part of the app should be tested. To fill this gap, the authors propose to construct an Annotated Window Transition Graph (AWTG) model for the app under test by merging dynamic and static analysis results and subsequently leverage the AWTG model to implement a testing assistance pipeline that offers test task extraction, test task recommendation, and test task guidance for crowd workers. Recently, Sun et al. [101] present to the community a lightweight approach that aims to achieve fully automated crowdsourced app testing by only dispatching the app’s partial code for crowdsourced execution. The experimental results involving tests of API-related code only (of real-world apps) show that their approach is useful (as demonstrated by being able to find many API-induced compatibility issues) and welcome in practice.

(11) [Code Review] Static Analysis Framework. Static analysis is a fundamental technical that has been frequently applied to resolve various Android app analysis problems. Such solutions are often implemented based on the so-called static analysis frameworks that offer implementations to core static analysis functions such as control-flow graph construction, call graph constructions, etc. OpenHarmony takes a new program language called ArkTS to develop its apps. Therefore, an ArkTS-specific static analysis framework is required to support the implementation of other purpose-oriented static analysis approaches (e.g., vulnerability detection).

−→Representative Work: Soot [56] is one of the most popular static analysis frameworks that are capable of analyzing Android apps. Soot is initially designed for Java program analysis and is further extended for Android apps (which are written in Java) thanks to the Dexpler module contributed by Bartel et al. [12]. Another popular static analysis framework should be the one named WALA [93], which is developed and maintained by IBM. In Android, both Soot and WALA have been recurrently adopted by our fellow researchers to support the implementation of static analysis approaches.

(12) [Code Review] Static Taint Analysis (for Detecting Privacy Leaks). One of the most popular usages of static analysis is to perform static taint analysis for pinpointing sensitive data flows (also known as privacy leaks). Static taint analysis works by first coloring some variables that contain sensitive data such as the user’s phone number and then tracking their flows in the code. A sensitive data flow is considered detected if such colored data eventually flows to sensitive operations (e.g., sending the colored data outside the device via SMS). OpenHarmony apps will be run on mobile devices and hence will have similar requirements. Therefore, it is also essential ed to invent static taint analysis approaches for examining OpenHarmony apps.

−→Representative Work: Arzt et al. [7] have presented to the MSE community an opensource tool called FlowDroid, which performs context-, flow-, field-, and object-sensitive and lifecycle-aware taint analysis for Android apps. The authors further provide on-demand algorithms for FlowDroid to achieve high efficiency and precision at the same time. Based on FlowDroid, researchers further present to the community three extensions, namely IccTA [58], DroidRA [62, 63, 102], and SEEKER [100], that perform static taint analysis by additionally considering apps’ inter-component communication, reflection, and sensor-related features, respectively. In the field of iOS, Egele et al. [31] present a tool called Pios, which leverages static taint analysis to detect privacy leaks in iOS apps

(13) [Code Review] Code Similarity Analysis. Code similarity analysis is another common application of static analysis that has also been recurrently adopted by developers to achieve various functions, e.g., to detect code clones, the usage of third-party libraries, and repackaged (or piggybacked) apps. Code similarity analysis is also essential to understand the difference between two code snippets, including the two timestamped versions of the same code snippet. Such a difference can then be leveraged to support the implementation of various software engineering tasks such as automatically generating commit messages or inferring patches to given code defects, etc.

−→Representative Work: Russell et al. [24] have presented to the MSE community a prototype tool called AnDarwin for detecting semantically similar Android apps. AnDarwin leverages a clustering-based approach, for which it attempts to cluster similar apps into the same group based on semantic information extracted from the apps’ code. More recently, Li et al. [59, 65] have developed another prototype tool called SimiDroid that aims at identifying similarities in Android apps through static code analysis. The SimiDroid tool is designed to be a generic framework that can be easily extended to support multi-level comparisons of Android apps. The authors have demonstrated the usefulness of SimiDroid by achieving efficient similarity analysis of Android apps in three scenarios (Resource, Component, and Method-level comparisons).

(14) [Code Review] App Lineage Analysis. Due to the fast evolution of the OS framework as well as the requirement to fix bugs or add new features, mobile apps are continuously updated by their developers (often over app stores). Such updates will lead to a series of releases of the same app, which is referred to by the community as app lineages. Because these app lineages have recorded all the app changes, our fellow researchers have proposed to mine them[11] to learn why the mobile apps updated. Similar approaches could also be applied to OpenHarmony, e.g., to mine knowledge for updating (or fixing) existing apps.

−→Representative Work: Gao et al. [37] present an experimental study about the evolution of Android app vulnerabilities. They first define the term “app lineage” (i.e., the series of a given app’s historical versions). Then, they collect a dataset of app lineages and subsequently leverage it to understand the vulnerability evolution by mining the updates between an app’s two consecutive versions. Their empirical study has revealed various interesting findings. The authors further conduct another work to mine app lineages for understanding the evolution of Android app complexities [36]. Their experimental results reveal a controversial finding where app developers might not really be aware of controlling the complexity of their apps.

(15) [Code Review] Automated Program Repair. Automated Program Repair (APR) has been a hot topic in the software engineering community for years. The idea of APR is for computers to automatically produce source code-level patches for bugs and vulnerabilities. Our fellow researchers have also attempted to invent techniques to automatically repair mobile apps. We argue that such techniques should also be explored to target OpenHarmony apps.

−→Representative Work: Marginean et al. [77] present an industry tool called SapFix that achieves end-to-end fault fixing, from test case design to deployed repairs in production code. SapFix achieves its purpose by combining a number of different techniques, including mutation testing, search-based software testing, and fault localization. Zhao et al. [120] have presented to the community another prototype tool called RepairDroid, which aims at automatically repairing compatibility issues directly in published Android apps (at the bytecode level). To support flexible repair, the authors have introduced a generic app patch description language that allows users to create fix templates using IR code.

(16) [Code Review] Cross-language Static Analysis. Mobile apps are not always written in a single programming language. Indeed, there are various apps that are implemented in multiple languages. For example, the module requiring high performance in Android apps could be written in C or C++ while the main part is still written in Java, which is the default language to implement Android apps. As another example, for such Android apps that leverage web-related components, certain functions could be written in Javascript, in order to supplement the main functions written in Java. In order to properly analyze these apps involving multiple programming languages, we argue that there is a need to conduct cross-language static analysis, for which the data-flow analysis should propagate variables from one language to another.

−→Representative Work: Wei et al. [106] and Zhou et al. [125] demonstrate that it is important to support inter-language static analysis in order to support security vetting of Android apps. To do so, Samhi et al. [92] present to the community a prototype tool called Jucify that aims to unify Android code (between Java and C/C++) to support static analysis. Their work is able to build a comprehensive call graph across all the methods written in the app, no matter they are written in Java or C/C++. Xue et al. [111] have also invented a prototype tool called NDroid for tracking information flows across multiple Android contexts, including the analysis of native code in Android apps [126].

(17) [Code Review] Hybrid Analysis. As discussed previously, both testing (also known as dynamic analysis) and static analysis techniques are recurrently adopted by our fellow researchers to dissect mobile apps. However, both of these two techniques are known to have drawbacks, e.g., testing approaches suffer from code coverage problems that eventually lead to false negative results, meanwhile, static analysis is known to likely yield false positive results. To mitigate this, our fellow researchers have proposed to combine these two approaches to conduct the so-called hybrid analysis of mobile apps. We believe there is also a need to invent hybrid approaches for analyzing OpenHarmony apps.

−→Representative Work: Wang et al. [103] present an automated hybrid analysis of Android malware through augmenting fuzzing with forced execution. They propose an approach called DirectDroid, which aims to trigger hidden malicious behavior by bypassing some related checks when adopting fuzzing to feed the necessary program input. Spreitzenbarth et al. [? ] have developed another hybrid analysis approach called Mobile-Sandbox, for which static analysis is leveraged to reach higher code coverage during dynamic analysis (i.e., app testing).

(18) [Code Review] Machine/Deep Learning. Machine Learning has become one of the most popular techniques that are frequently adopted by our fellow researchers for reviewing apps’ logic code. Indeed, a lot of research efforts are spent to find the best feature set that could closely represent the app’s behavior. Such a feature set is then leveraged to support two types of machine learning approaches: supervised learning and unsupervised learning. Supervised learning requires knowing the labels of the training dataset, e.g., it is essential to collect a set of known malware in order to train a malware predictor. On the contrary, unsupervised learning does not need to know the labels of the dataset. This type of approach is often used to cluster similar samples into the same group. When deep learning is concerned, feature engineering is no longer needed.

−→Representative Work: Liu et al. [75] have recently conducted a systematic literature review about deep learning approaches applied to defend Android malware. The authors have surveyed papers published from 2014 to 2021 and have located 132 closely related papers. The authors find that static analysis is the most used technique to obtain features from Android apps and there are 13 works that achieve malware classification by directly encoding the raw bytecode of Android apps into feature vectors. Machine learning is not only applied to dissect malware but is also used for resolving other software engineering tasks. For example, Rasthofer et al. [89] have presented to the community a machine learning-based approach for classifying and categorizing sources and sinks in Android, which can then be leveraged to support taint analysis of Android apps, so as to detect privacy leaks.

(19) [Deployment] Code Obfuscation. Because of the nature of mobile devices, mobile apps need to be downloaded to the devices before installation. This, unfortunately, makes it possible for attackers to directly access the mobile apps. Even worse, the attackers might be able to directly access the code implementations of the apps if reverse engineering techniques are applied. To prevent attackers from easily understanding the code, the MSE community has adopted the practice to perform code obfuscation before assembling the app code to a release version. Since OpenHarmony apps need to be installed on users’ devices, it is also essential to invent code obfuscation techniques to prevent OpenHarmony apps from being exploited by attackers.

−→Representative Work: Aonzo et al. [6] have developed an open-source black-box obfuscation tool for Android apps. The authors named their approach Obfuscapk and have designed a modular architecture for users to straightforwardly extend so as to support the implementation of new obfuscation strategies. Dong et al. [29] conduct a large-scale empirical study of Android obfuscation techniques, with the hope of better understanding the usage of obfuscation. The authors have specifically looked into four popular obfuscation approaches: identifier renaming, string encryption, Java reflection, and packing, leading to various findings that could help developers select the most suitable obfuscation approach.

(20) [Deployment] App Hardening. Code obfuscation is a useful technique to prevent attackers from easily understanding the code. It is nonetheless not possible to prevent attackers from obtaining the code. With the help of deobfuscation approaches, attackers could still understand the implementation details. To prevent that from happening, the MSE community further introduced to the community the so-called aWpp hardening technique, which aims to make it difficult to extract code implementation from the apps (e.g., will stop reverse engineering tools from disassembling released apps).

−→Representative Work: Russello et al. [91] present to the MSE community a policy-based framework called FireDroid that enforces security policies without modifying Android OS or the actual applications. FireDroid includes a novel mechanism to attach, monitor, and enforce policies for any process spawned by the Android’s mother process Zygote. With that, FireDroid can be applied to block OS and app vulnerabilities, hardening security on Android phones. Zhang et al. [119] have conducted the first systematic investigation on Android packing services toward understanding the major techniques used by state-of-the-art packing services and their effects on apps. They further find that the protection given by those packing services is not reliable, i.e., the Dex can be recovered. To demonstrate that, the authors have designed and implemented a prototype tool called DexHunter for extracting Dex files from packed Android apps. Following that, Xue et al. [112–114] have gone steps further to achieve unpacking through various methods, e.g., Hardware-assisted approach, VM-based approach, etc.

5.1.1 Gap in OS Framework-related Research. As highlighted in Fig. 1, OS framework is the layer that connects the apps with the system capabilities. It provides all the necessary capabilities (including all the APIs offered by the SDK) to support apps running on mobile devices. Since this part is closely related to apps, it has also been a frequent topic targeted by our SE researchers. We now summarize the representative ones.

(20) [Static] Evolution Analysis. Like what has been done for mobile apps, our fellow researchers have also proposed approaches to study the evolution of OS frameworks. They have shown that understanding the evolution of the framework could provide useful information for the mobile community. However, unlike mobile apps, the studies related to the evolution of OS framework are mainly based on source code as the framework (mainly Android framework) is open-sourced. Since the OpenHarmony’s framework is also opensourced, such techniques applied to study the evolution of the Android framework could be also applied to OpenHarmony.

−→Representative Work: Li et al. [66] have proposed to study the evolution of the Android framework to characterize deprecated APIs. Their empirical study has revealed various interesting findings including the inconsistency among the API’s implementation, its comments, and annotations. They have also found that the Android framework includes a lot of inaccessible APIs that are not designed to be invoked by client apps but have actually been accessed in practice [61]. As argued by Liu et al. [71], by looking into the evolution of Android APIs, we could find the silently evolved APIs that could eventually lead to indiscoverable compatibility issues [101] as the API’s implementation is updated during the evolution while its comment remained the same.

(21) [Static] Permission Analysis. A lot of research efforts have been put in by our SE community to understand Android’s permission system, which has been regarded as the primary mechanism to ensure the security of apps and the system. Ideally, the apps should declare the permission they need to properly run on given mobile devices. However, there is no clear mapping about permission to APIs provided to app developers. As a result, app developers often declare more permissions than what the apps actually need, resulting in an enlarged attacking surface. Our fellow researchers have hence proposed to dissect the framework code to build such a mapping and subsequently to support more fine-grained permission analyses. Since OpenHarmony also includes a permission system to ensure the security of apps, similar permission-related weaknesses that have been discovered in Android could also happen in OpenHarmony. Hence, there is also a strong need to conduct similar research to ensure the proper use of permissions in OpenHarmony.

−→Representative Work: Au et al. [8] present to the community a prototype tool called PScout that automatically extracts the permission specification from the Android OS source code (i.e., over a million lines of code) using static analysis. Their approach has resolved several challenges including the one to take into account permission enforcement due to Android’s use of IPC and Android’s diverse permission-checking mechanisms. Bartel et al. [13] have conducted a similar study by leveraging static analysis for extracting permission checks from the Android framework. Their approach is designed to be field-sensitive with an advanced class-hierarchy analysis strategy and uses novel domain-specific optimizations dedicated to Android.

(22) [Static] Access Control Enforcement. Security is not only the biggest problem in mobile apps, it is also one of the biggest problems in the OS framework side. To ensure the security of the system, the OS framework often relies on access control mechanisms to achieve the purpose. However, such access control mechanisms could be bypassed by malware so as to achieve unauthorized security-sensitive operations. Therefore, there is a need to enforce the access control function being properly applied.

−→Representative Work: Zhou et al. [124] have presented to the community a prototype tool called IAceFinder that aims to extract and contrast the access control enforced in the Java and native contexts of Android and subsequently to discover cross-context inconsistencies, as a major means to stop access control functions from being bypassed. The authors have applied their approach to analyzing 14 open-source Android OS frameworks (i.e., ROMs), from which they are able to disclose 23 inconsistencies that can be abused by attackers to compromise the device.

(23) [Static] Framework Customization. Due to the openness of Android and the requirement to provide vendor-specific user experience, the Android framework has been recurrently customized by smartphone vendors. For example, Xiaomi has done that and named the customized version MIUI. Similarly, Huawei has released EMUI to feature a more personalized user experience when using Huawei phones. Unfortunately, such a wide range of customizations has introduced significant compatibility issues to the community, making it difficult for app developers to implement an app that is compatible with all the available mobile devices. Our SE researchers have hence proposed approaches to mine the difference between the customized frameworks so as to mitigate the compatibility issues in the mobile community. As an open-source system, OpenHarmony could face similar problems. Therefore, there is also a need to spend research efforts to control the customization and thereby keep such problems from happening in OpenHarmony.

−→Representative Work: Liu et al. [70] have conducted an empirical study to understand whether customized Android frameworks keep pace with the official Android. They have looked at the evolution of eight downstream frameworks (e.g., AOKP, AOSPA, LineageOS, SlimROMs, etc.) and discovered various interesting findings (e.g., Downstream projects perform merge operations only for a small portion of all the version releases in the upstream project and most of the downstream projects take more than 20 days to bring changes from their corresponding upstream projects). The authors further look at the differences among the customized frameworks (including the ones modified by popular technical companies such as Xiaomi and Huawei) and find that this customization has led to serious compatibility issues (also known as the fragmentation problem) in the Android community [73]. This result strongly suggests that more efforts are required to ensure framework customization is properly handled and managed.

(24) [Dynamic] Runtime Instrumentation. Since it is not possible to resolve all the issues statically, researchers have also explored the possibility of dynamically analyzing the framework, e.g., to control the execution of the framework. One of the representative works is to instrument the framework to add hook methods to interested functions. At runtime, such hook methods, when executed, will provide runtime information of the framework, which has been demonstrated to be useful for comprehending the behavior of the framework, so do the apps running on it. Such a useful technique should be also provided to the OpenHarmony community so as to allow the implementation of many advanced framework/app analysis approaches.

−→Representative Work: One of the most famous runtime instrumentation approaches in Android is the Xposed framework, which allows developers to install little programs (called modules) to Android devices to customize their look and functionality. On the research side, Costamagna et al. [23] present a similar approach called ARTDroid that supports virtual method hooking on Android ART runtime. As another example, the most representative work related to runtime instrumentation is the one proposed by Enck et al. [32], who have presented to the MSE community one of the first approaches targeting runtime instrumentation in Android. They have implemented an information-tracking system called TaintDroid, aiming to achieve real-time privacy monitoring on smartphones. The runtime instrumentation of TaintDroid is enabled by leveraging Android’s virtualized execution environment.

5.2 Gap in Ecosystem-related Research

Except for the aforementioned research studies related to mobile apps and frameworks, there are also a significant number of studies focusing on the other aspects of MSE, for which we refer to in this work as ecosystem-related studies. We now discuss some of the representative ones.

(24) [App Store] Consistency Check. App store has become a touchstone experience of modern living and has penetrated into many distinctive platforms. The most famous app stores are the Google Play store and the Apple Store, which are set up to facilitate the discovery, purchasing, installation, and management of Android and iOS apps for Android phone and iPhone users, respectively. These app stores essentially form a central repository that records a large list of available apps and their metadata, which is considered useful for helping users discover the app and subsequently decide whether to purchase it or not. To keep the healthy of the ecosystem, app store maintainers will often set up a vetting system to filter low-quality apps (e.g., the app contains vulnerabilities or suffers from compatibility problems) from entering the store. Here, the metadata often contains two types of information: (1) the ones provided by the app authors such as the app’s name and the app’s description, and (2) the ones collected by the platform such as the app’s user rating, etc. In this section, since app analysis has been well discussed already, we will only focus on the metadata side and argue that the app and its metadata need to be kept consistent. If not, the experience of using the app will be significantly impacted and that negative feeling could further be propagated to the experience of using the app store.

−→Representative Works: Gorla et al. [43] have proposed to check app behavior against app descriptions as they believe that there is no guarantee the code of the app does what it claims to do when uploaded to the app store. Their experimental results on a set of 22,500+ Android apps show that such inconsistency indeed exists in the community, confirming the hypothesis that the app store does not yet perform consistency checks at the time when apps are uploaded. Another closely related example is the one proposed by Hu et al. ?? who introduce to the community a new type of attack called Mobile App Squatting. In “App Squatting”, attackers release apps (on app stores) with identifiers (e.g., app name or package name) that are confusingly similar to those of popular apps or well-known Internet brands. With such tricks, attackers hope to have their apps selected by app users who do not intend to use them. All the aforementioned problems could be avoided if the app stores performed thorough consistency checks.

(25) [App Store] Compliance Check. Except for consistency checks, there is also a need to perform compliance checks before allowing mobile apps submitted to app stores. There are various policies that mobile apps need to follow. Such policies include the ones made by the government (e.g., the General Data Protection Regulation (GDPR) by the European Union), by the app store itself (e.g., the Spam and Minimum Functionality policies by Google Play), as well as the ones made by certain libraries (the content policies and behavioral policies by AdMob & AdSense.) These compliance checks should be also conducted for vetting OpenHarmony apps and hence dedicated efforts are needed to implement such approaches.

−→Representative Works: Fan et al. [33] have conducted a study to explore the violations of GDPR compliance in Android eHealth apps. Their experimental study shows that such violations (including the incompleteness of privacy policy, the inconsistency of data collection, and the insecurity of data transmission) are indeed widely presented in the Android community. Zhao et al. [123] have performed a study to check if mobile ads are in compliance with the app’s age group. Dong et al. [28] have conducted an exploratory study to understand how mobile apps violate the behavioral policies given by ad libraries. All the aforementioned works have confirmed that there are lots of compliance violations in the current mobile community, which eventually lead to poor user experiences. Therefore, to avoid such, we argue that the app store of OpenHarmony should support compliance checks so as to restrict the happening of such compliance violations.

(26) [App Review] Human Values. Mobile apps are essentially developed for users and it is necessary to consider the relationship between human values and the development and deployment of mobile apps. Indeed, it has been demonstrated that violation of human values such as privacy, fairness, integrity, curiosity, honesty, or social justice by mobile apps (or technology in general) will lead to significant negative consequences. If such violations could be identified earlier, developers can look to better address them and thereby mitigate them in the first place (e.g., before the apps are released to their users). Since human values should also be the ‘first citizen’ in OpenHarmony, such violation detection approaches should be also supported.

−→Representative Works: Obie et al. [82] have presented to the MSE community the first study about human values-violation in app reviews given by real-world app users. Through 22,119 app reviews collected from the Google Play store, the authors find that 26.5% of the reviews contained text indicating user-perceived violations of human values, with benevolence and self-direction as the most violated value categories. Obie et al. ?? further go one step deeper to look at the violation of honesty in mobile apps and subsequently propose approaches to automatically detect them. Their study shows that honesty violation is quite common and top violation categories include unfair cancellation and refund policies, false advertisements, delusive subscriptions, cheating systems, etc. These approaches highlight the need for proactive approaches taken by the community to better embed human values in OpenHarmony apps.

(27) [Other] Black Market Analysis. With the fast growth of the mobile ecosystem, attackers have attempted to explore various ways to gain illegal profits (e.g., through some hidden malicious behaviors). For example, attackers have attempted to gain profits by injecting advertisements in benign apps or by sending SMS messages to premium-rate numbers. Others have attempted to collect user private info (by leveraging single devices or by accumulating the info from multiple devices) and subsequently sell them to third parties for supporting other malicious activities. The aforementioned types of activities are referred to as black market by our fellow researchers who have spent lots of effort to understand and subsequently defend against them in the mobile ecosystem. Unfortunately, as long as there are opportunities to gain profits, there will be malicious people to exploit it. This applies to OpenHarmony as well. Therefore, we argue that there is a strong need to mitigate the black market for OpenHarmony and we invite our fellow researchers to collaboratively explore this important research direction.

−→Representative Works: Gao et al. [38] have conducted an exploratory study to demystify illegal mobile gambling apps, which have become one of the most popular and lucrative underground businesses. Their study reveals that, in order to bypass the strict regulations from both government authorities and app markets, the devious app authors have developed a number of covert channels to distribute their apps and abused fourth-party payment services to gain profits. As another example, Hu et al. [47] have performed a thorough study to understand the ecosystem of fraudulent dating apps, which attempt to lure users into purchasing premium services to start conversations with other (likely fake female) accounts, i.e., chatbots. All of such black market behaviors could happen to the OpenHarmony community as well so dedicated approaches are required to keep that from happening.

5.3 New Research Opportunities

• LLM-based SE Approaches for OpenHarmony. As summarized in Section 4, the majority of Mobile Software Engineering research works focus on the analyzing phase. There are only a limited number of studies focusing on app development phases. This does make sense as Android app development has already been quite mature (with a lot of support from Google and the community) when our fellow researchers jumped into this field. This is, however, not the case for OpenHarmony. Indeed, OpenHarmony is still at a very early stage, with only a small number of apps developed and a limited number of third-party libraries made available to the community. It will be extremely beneficial to the OpenHarmony community if there are more works proposed to facilitate the development of OpenHarmony apps. Now, with the fast development of large language models (especially the development-focused ones such as Github’s Copilot), we feel this is an even better opportunity to support that now. LLMs could help developers quickly learn the basic knowledge of OpenHarmony, understand the usage of APIs, automatically generate code (one line or multiple lines), generate unit test cases, recommend repair options, etc.

• Corss-platfrom Framework for Supporting OpenHarmony. To embrace the idea of developing once, running everywhere, the MSE community has invented the so-called crossplatform frameworks such as ReactNative and Flutter to support that. These cross-platform frameworks by themselves have defined a way to develop the universal app. For example, with ReactNative, the codebase of the app is usually formed via Javascript. This codebase can then be compiled into both a native Android app and a native iOS app. The best part of using cross-language platforms is that the app’s maintenance is also unified. No matter it is to fix bugs or add new features, it only needs to be done once. Considering this great benefit, we believe it will be extremely helpful to OpenHarmony’s ecosystem if these cross-platform frameworks can support OpenHarmony. In that case, all the existing apps that are developed via cross-platform frameworks can be directly running on OpenHarmony devices. Therefore, we highly recommend our fellow researchers considering exploring this research direction.

• Learn from Android/iOS. In this work, we have summarized lots of Android/iOS-related approaches and believe it is necessary to learn from them by building dedicated approaches for OpenHarmony. While that is certainly true, we also feel that there is a need to learn from the large number of artifacts accumulated in Android and iOS. Indeed, the MSE community has gained a lot of artifacts, including millions of real-world apps, thousands of open-source apps, documentation, question-and-answer records, user reviews, etc. Although harvested from different platforms, we argue that these artifacts could be still useful for supporting the implementation of OpenHarmony-related tasks. For example, one possibility is to explore the direction of automatically transforming the Java-written Android apps (or Swift-written iOS apps) to ArkTS-written OpenHarmony apps. In this work, we also invite our fellow researchers to explore this direction, flourishing the OpenHarmony ecosystem by standing on the shoulders of giants.

[11] Researchers have to focus on the app’s released versions because it is often not possible to obtain its source code.