The State of OpenHarmony Ecosystem: Initiatives, Toolchains, and Datasets

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

3 THE STATE OF OPENHARMONY ECOSYSTEM

As revealed in the previous literature review, despite Mobile Software Engineering has been a longstanding and hot topic, the efforts spent by our fellow researchers for exploring OpenHarmony have been limited. Indeed, there is almost no contribution made to OpenHarmony in the current MSE community. Therefore, as our initial attempt towards bringing OpenHarmony research to

the Mobile Software Engineering (MSE) community, we summarize the current achievements of OpenHarmony to help readers better understand the state of the OpenHarmony ecosystem. Specifically, in this section, we first briefly introduce the OpenAtom OpenHarmony initiative and subsequently highlight the existing toolchains and datasets available in the community. After that, we go one step further to also summarize other existing resources that may not be directly related to OpenHarmony but could still be beneficial to grow the ecosystem of OpenHarmony.

3.1 The OpenAtom OpenHarmony Initiative

Recall that OpenHarmony is now a fully open-sourced project, which is currently incubated by the OpenAtom Foundation. At the moment, the OpenHarmony project is run by an operating committee, and its technical part is mainly run by a Technical Steering Committee (TSC). To support the technical success of OpenHarmony, the TSC has further set up various domain-specific Technical Supporting Groups (TSG). At the moment, there are six TSGs and the number is growing. The current supporting groups cover the following six domains: (1) Program Language, (2) Crossplatform App Development Framework, (3) Security and Privacy Computing, (4) Web3 Standard, (5) Robot, and (6) Integrated Development Environment (IDE). These domain-specific TSGs are responsible for understanding the domain-related requirements, summarizing the technical map of the domain, and preparing the fundamental technicals for helping domain-specific technical-related decision-making and eventually supporting the overall success of OpenHarmony.

3.2 Existing Toolchains

We then look at the existing toolchains offered by the official OpenHarmony framework to support app developments and these toolchains are considered important and essential. Indeed, these tools could provide fundamental capabilities to support the implementation of more advanced OpenHarmony-specific toolchains. Ideally, these toolchains should cover the full lifecycle of app development, including development, build, testing, debugging, code review, and publishing. Table 1 summarizes some of the tools provided by OpenHarmony. The second column demonstrates the software engineering phase that the tool intends to support. At the moment, these toolchains have covered almost all the aforementioned lifecycle phases, e.g., including app development-related ones (e.g., IDE, Emulator, Device Manager), app building tools (e.g., hvigor), app testing tools (e.g., jsunit, uitest), debugging tools (e.g., HiLog, profiler), code reviewing tools (e.g., Code Linter), command line tools (e.g., hdc), and package management tool (e.g., ohpm). The only exception is the phase of publishing. At the moment, there is no such tool offered for OpenHarmony. It is nonetheless understandable as there is no app market available for hosting OpenHarmony apps yet. We believe such a tool will be provided once a dedicated app market is offered.

It is worth noting that, at the moment, we only conducted a high-level overview and did not check in detail to what extent are the required functions in each phase covered by these tools. For example, there is a tool called Monkey in Android that supports random exploration of Android apps, it is not clear to us if the existing toolchains of OpenHarmony provide equivalent functions. As for our future work, we plan to have a more detailed look at these tools and provide to the community a clearer overview of these toolchains.

3.3 Existing Datasets

As shown in Section 4, the datasets targeted by our MSE community can be mainly divided into four types: (1) Mobile apps (including both open-sourced and closed-sourced apps), (2) Mobile App Development Framework, (3) Third-party Libraries, (4) App Store Info (including app reviews). We now respectively summarize the current situation of these types of datasets in OpenHarmony, respectively. We further go one step deeper to harvest the relevant datasets, if possible, and make them publicly available for supporting our fellow researchers to conduct OpenHarmony-related software engineering research.

OpenHarmony Framework. Recall that OpenHarmony is a fully open-sourced system, its app development framework is open-sourced. The framework is the first gate that OpenHarmony apps need to interact with before running into the system. The interaction is mainly through

APIs provided by the app development SDK, as part of the OpenHarmony framework. Some of the meta-data of the OpenHarmony framework are shown in Table 2. The current framework is open-sourced at the interface_sdk-js repository[4] on Gitee and it currently has 105 branches, 30 tags, 1,400 forks, 57 stars, 7,833 commits, and 627 contributors. As a comparison, the last column of Table 2 shows the meta-data of the Android framework repository, respectively. It is obvious that OpenHarmony has a big step to go in order to catch up with Android, which poses lots of opportunities for our MSE community to mitigate the gap between the OpenHarmony framework and the Android framework

We further look into the number of APIs offered by the OpenHarmony framework. Since there is no such information directly provided on the web, we decide to write a parser to directly harvest that from the open-source repository. We select the latest version (i.e., OpenHarmony 4.0) and only count the number of functions (including static and non-static functions). In the latest version, there are 10,435 APIs. This number is also significantly smaller than that of the Android framework, which already has over 30,000 APIs in 2018 (i.e., API version 28 [66]). Nonetheless, as illustrated in Fig. 5, the number of APIs (again, any functions are considered) is continuously increasing, showing that the capabilities of OpenHarmony are keeping maturing. We believe as time goes by, such a difference between the APIs of Android and OpenHarmony will be much smaller.

OpenHarmony Apps. One of the most important reasons that make mobile software engineering (especially for the Android community) a longstanding hot topic is due to the existence of a large number of mobile apps [35, 49]. Indeed, there are over 2 million Android apps (there is a similar number for the iOS community) available on the official Google Play store. In the famous AndroZoo dataset [67], there are over 23 million Android apps collected from various sources (e.g., the official Google Play store and over 10 third-party markets such as PlayDrone, AppChina, etc.) spanning various years. Liu et al. have subsequently harvested the open-sourced Android apps and formed them as a dataset called AndroZooOpen [72]. This dataset is also made publicly available to the software engineering community and has been demonstrated to be useful in supporting Android research tasks. Inspired by this, we hypothesize that OpenHarmony apps will be one of the most important resources for supporting OpenHarmony research. We, therefore, take our initial attempt to harvest existing OpenHarmony apps. Since there is no app market available for OpenHarmony yet, we solely focus on open-sourced OpenHarmony apps. Specifically, we take OpenHarmony as well as HarmonyOS as the search keyword and apply it to two famous cloud-based software version control websites, namely GitHub and Gitee, which are the most famous sites of such in the world and in China, respectively.

Our initial search results in 3,804 repositories[5] , for which 910 of them are from GitHub while the remaining 2,894 from Gitee. We remind the readers that these identified repositories may not always be OpenHarmony apps. Therefore, we resort to a Shell script (with manually identified features of OpenHarmony apps considered) to select such repositories that indeed contain OpenHarmony apps. Our experiment has eventually discovered 174 such repositories, with 147 and 27 from Gitee and Github, respectively. To facilitate further research, we have also made this list publicly available on the same site.[6]

Third-party Libraries We remind the readers that OpenHarmony takes a newly introduced language called ArkTS to support app implementations. In this work, we also look at the existing third-party libraries that are available for supporting the development of OpenHarmony apps. Specifically, we would like to understand to what extent are ArkTS-based libraries available in our community and what are they designed for. In OpenHarmony, the official team has introduced a tool called ohpm (as also shown in Table 1) for managing all the third-party libraries designed for developing OpenHarmony apps. In the current central registry[7] , there are already 96 libraries and the number is growing. The functions of these libraries can be divided into 10 categories. Table 3 enumerates some of the representative ones for each category. Generally, we show one or two libraries for each category. The two are randomly chosen if there are more libraries available for the given category.

Furthermore, as mentioned previously, ArkTS is not entirely new. It actually extends Typescript, which has been a popular programming language for more than 10 years. Typescript is Javascript with syntax for types, i.e., adding static typing with optional type annotations to Javascript. Theoretically, existing Typescript code (as well as Javascript code) can be directly reused for developing OpenHarmony apps. Those Typescript/Javascript implementations could be regarded as third-party libraries as well. By taking Typescript and Javascript as the search keyword, Github returns 513,000

and 1.7 million repositories for Typescript and Javascript, respectively. Such a large number of repositories (despite not all of them being code-related repositories) indicates that there are already a lot of potential third-party libraries available for OpenHarmony.[8] Those libraries could be leveraged (either directly or with additional efforts contributed by our fellow researchers) to facilitate the development of OpenHarmony apps and its broad ecosystem.

App Store Info. Our software engineering researchers have leveraged app store info (such as the app’s author information, description, user rating, user reviews, etc.) to support various studies. For example, Gorla et al. [43] have leveraged the app’s description to check against the app’s behavior. Obie et al. [83] have leveraged the app’s review data to investigate the violation of honesty in mobile apps. To the best of our knowledge, there is barely any app store hosting OpenHarmony apps at the moment. Therefore, there is no such dataset that can be collected so far. Nonetheless, the OpenHarmony version of a given app will also share much of such information as that available in Android or iOS. This information could also be helpful when mining OpenHarmony-specific app store information.

3.4 Existing OpenHarmony Research

As our initial attempt towards building the research roadmap for guiding our software engineering researchers to contribute to OpenHarmony, we start by conducting a lightweight literature review about OpenHarmony. Our method is straightforward. We use OpenHarmony and HarmonyOS as the search keywords and we apply them separately to search for relevant publications on both Google Scholar and DBLP, respectively. At this step, when applied to Google Scholar, we will only consider the top 100 results. Table 4 enumerates the list of OpenHarmony-related publications. In total, we only found 8 papers and among which only one (i.e., the one published at the APWeb conference) can be found on DBLP, while all of them can be found on Google Scholar. At this step, we only consider a paper relevant if and only if it directly contributes to the OpenHarmony project or if it takes OpenHarmony as its dataset to evaluate their approaches. There are several other papers that are not included in this review although they do involve OpenHarmony/HarmonyOS systems. They are excluded because they do not contribute anything to OpenHarmony as they only involve running their approaches on OpenHarmony/HarmonyOS systems. For example, the work proposed by Qiu et al. [87] is not included in this paper because it only leverages HarmonyOS to support their model implementation about supporting distributed user interfaces to be dynamically configured on multiple IoT devices based on user preferences.

As shown in Table 4, there are only eight OpenHarmony-related papers published in the community. The efforts could be neglected if compared to those for Android, where there are over 7,000 papers published as recorded in DBLP (searching by taking Android as the keyword). This evidence confirms our previous argument that there is still a huge gap between OpenHarmony and Android. This, however, also demonstrates that there are huge opportunities open for our community. Ideally, the research methods applied to Android or iOS could also be applied to OpenHarmony. Despite there being only eight papers published, it is motivating to find that the number of relevant papers keeps growing. The venues where the current papers are published are generally not in reputed journals or conferences. Indeed, among the eight papers, only four of them are published at venues recorded by CORE and only three of them are ranked. We would hope that our community could spend more effort in developing software engineering approaches for OpenHarmony and publish more papers at mainstream venues.

[4] We remind the readers that the framework and the SDK are not exactly the same as the framework may contain more capabilities that are reserved for system apps while SDK is only supposed to be used by third-party apps. For simplicity, in this work, we will not differentiate this as there is no direct repository provided for hosting the framework code of OpenHarmony.

[5]The full list is made available on GitHub (https://github.com/SMAT-Lab/SE4OpenHarmony).

[6] Our further investigation finds that most of these apps are not comprehensive ones (i.e., might be toy apps or demonstrating the usability of certain libraries). We hence commit to keep updating this list toward forming a more useful dataset for supporting OpenHarmony-based software engineering research.

[7]https://ohpm.openharmony.cn

[8] We hypothesize that this is one of the major reasons why ArkTS is proposed as the default programming language for developing OpenHarmony apps.