Hap (file Format)

The HarmonyOS App Pack or the App file, identified with the file extension ".app", serves as the file format used by the HarmonyOS operating system. It functions as a native HarmonyOS app for distribution and installation through Huawei AppGallery, or for distribution through Huawei Ability Gallery in respect of installation-free apps under both former classic dual-framework and current HarmonyOS NEXT system of unified OpenHarmony app framework. The App file is also used by a number of other open source HarmonyOS-based operating systems such as OpenHarmony and Oniro-based operating systems for distribution and installation of applications, video games and middleware. Including non OpenHarmony-based operating systems, such as GNU Linux-based Unity Operating System that supports the app file format.

Each HarmonyOS app contains one or more HarmonyOS Ability Package (HAP) files with the file extension ".hap", and the pack.info file that describes the attributes of the App file.

Most HarmonyOS apps contain at least one HAP file of the entry type, which is the main module of the app, and additional HAP files of the feature type, which is used to implement a specific app feature.

Overview

App Pack and HAP files

HarmonyOS apps are distributed as a software package file known as the App Pack or the App file, suffixed with .app, which is analogous to other software packages such as apk used by the Android operating system, exe in Microsoft Windows, or a Debian package in Debian-based operating systems.

To make a HarmonyOS app, a software development tool such as DevEco Studio is required to code and pack HarmonyOS Ability Package (HAP) and associated files into an app package.

The HAP files may consist of resources, third-party libraries and configuration files. They are classified into two types of modules, i.e., entry and feature. The entry type of the HAP files is the main module and must be included into an app package, while the feature type of the HAP files is additional modules for implementing the features of the apps.

Moreover, an App file that contains different builds and specifications optimized for the various devices may contain more than one HAP file of the entry type.

Historically, the development of the HAP format has gone through two phases. The first stage, after decompression, there was a non-executable APK as the program entrance to connect with AOSP file libraries of binaries to interact with AOSP base of HarmonyOS 2.0 API 6, which is caused by the imperfect ecology of the early development of the new app file format during dual framework of OpenHarmony L3-L5 that consists of EMUI Android base convergence. During early app development, third party developers facilitated development for mixed packaging of APK and HAP. Since introduction of HAR libraries on HarmonyOS 3.1 API 9 with ArkUI declarative programming framework and ArkTS evolved from eTS on 3.0, as primary programming language replacing Java binaries in the second stage of HAP, APKs was eliminated after decompression, and HAP cannot be converted into APKs by simple unpacking and packaging, therefore HAP file format is not a casing of the APK.

Prior to packing into an App Pack, HAP files are allowed to run directly on a real device or an emulator for developers to debug and verify the apps during the development phase.

After development, the apps containing signature information can be distributed to different devices with AppGallery Connect, a tool kit of services for creation, development, distribution and maintenance of an app.

Shared packages

For sharing code and resources in an App Pack, the operating system offers two kinds of shared packages: Harmony Archive (HAR), which is a static shared package, and Harmony Shared Package (HSP), which is a dynamic shared package.

Both HAR and HSP enable sharing of code, C++ libraries, resources, and configuration files. In HAR, the code and resources are compiled together with invoking modules, possibly resulting in multiple copies of the same code and resources. In contrast, HSP allows independent compilation, leading to only one copy of code and resources in the build product.

When multiple HAPs reference the same HAR, the HSP can be used instead to share some state variables and reduce the size of an App Pack. However, the HSP has some restrictions; for example, it does not support the declaration of abilities in its configuration file and its invoking modules must be in the same stage model as with the HSP.

On OpenHarmony 4.1 API 11 improvements with System-level HSP that supports OTA upgrades within the App Package Management system. Also, the API 11 upgrade under Public Basic Class Library supports the creation of Workers within HSP and HAR that is something a user give a task and continue in the process, while the worker, or multiple workers also known as Thread pools, process the task on a different thread. A call back method is initiated when a special method provided on the initial call gets called.

App file structure

The structure of the App file after built and packaged in a stage model usually contains the following files and folders.

*entry.hap and feature.hap: the basic modules of both entry and feature types for installing an app, containing the following folders and files.
**ets: a folder storing bytecode files generated after the code build.
**libs: a folder storing the dependency files of the main module.
**resources: a folder containing resource files such as graphics, multimedia, character strings, and layouts.
**resources.index: a file providing a resource index table generated when an app is built.
**app.json5 and module.json5: JSON files with configuration information for build tools, operating system and application markets.

* pack.info: a file describing the attributes of the App Pack.

See also

* apk (file format)
* .ipa
* .exe

References

{{Archive formats

Mobile operating systems
Archive formats