Getting Started with Hongmeng Development: Quick Fixes

Quick fix overview

Quick fix is ​​a technical means provided by the HarmonyOS system to developers, allowing developers to repair defects in application packages much faster than application upgrades. Compared with full application upgrade software version, the main advantages of quick repair are small size, speed and good user experience. Repair application defects in a short period of time without interrupting the running application (that is, without restarting the application).

Quick fix usage rules

• Only the TS and C++ codes of the application are supported. The corresponding files are .abc files (TS compiled files) and .so files (C++ compiled files). Repair of resources is not supported.
• New .abc files and .so files are not supported.
• When deploying a quick fix package, make sure that the corresponding application package is installed. If it is not installed, the deployment will fail.
• The package name and application version number configured in the quick fix package must be the same as the installed package name and version number application. If they are different, the deployment will fail.
• If a quick fix package has been deployed, the version number of the newly deployed quick fix package must be greater than the version number of the previous quick fix package, otherwise the deployment will fail.
• The signature information of the quick fix package and the signature information of the application to be repaired must be consistent, otherwise the deployment will fail.
• When a new application version is released and installed, the quick fix package will be cleaned up.

Quick fix package structure

The picture above is the package format of the quick fix released by the HarmonyOS application

• As can be seen from the figure, there are two packet formats:

  • appqf（Application Quick Fix）

    There is a one-to-one correspondence between appqf and the application's app pack. For details, please refer to the introduction of Application Package Structure.

    • The appqf package is the unit used by HarmonyOS applications to be published to the application market and cannot be installed directly on the device.
    • It is composed of one or more hqf (Harmony Ability Package Quick Fix). These hqf packages will be separated from the appqf package in the application market and then distributed to specific devices.
    • The appqf package must have the developer's signature information before it is put on the application market.

  • hqf（Harmony Ability Package Quick Fix）

    The hqf package is a quick fix package that fixes problems in HAP and is used to install the quick fix unit on the device. An hqf can contain a .abc quick fix file, a .so quick fix file and a configuration file describing the package.

    • .abc file: modified ts code in the application, bytecode file generated after compilation.

    • libs directory: stores the difference files of .so library files, with .so.diff as the suffix. Different system CPU architectures are distinguished, such as arm platform and x86 platform.

    • patch.json：

      This file is used to describe the configuration file of the hqf package version information. It is filled in by the developer. The specific content is as follows:

      {    "app" : {        "bundleName" : "com.ohos.quickfix",        "versionCode" : 1000000,        "versionName" : "1.0.0",        "patchVersionCode" : 1000000,        "patchVersionName" : "1.0.0"    },    "module" : {        "name" : "entry",        "type" : "patch",        "deviceTypes" : [        "default",        "tablet"        ],        "originalModuleHash" : "11223344556677889900"    }}
      

      Specific field description:

      Field	type	illustrate	Remark
      bundleName	string	The package name of the corresponding application.	Cannot be defaulted
      versionCode	int	Corresponding application version number.	Cannot be defaulted
      versionName	string	The version name of the corresponding application.	patch type cannot be defaulted
      patchVersionCode	int	The version number of the patch package.	Cannot be defaulted
      patchVersionName	string	The version name of the patch package.	patch type cannot be defaulted
      name	string	The moduleName of the corresponding application is used to repair the module.	Cannot be defaulted
      type	string	Corresponding to the type of patch package, patch can currently be selected.	Cannot be defaulted
      deviceTypes	array	Device types supported by the patch package.	Cannot be defaulted
      originalModuleHash	string	The hash value of the original module Name corresponding to the package can be generated by yourself using the SHA256 generator.	Cannot be defaulted

Quickly repair TS compiled files

The picture above is the process of generating a quick repair .abc file through the TS code compilation tool:

• When the original application is compiled, .abc files and .map files are generated. .abc is a bytecode file compiled from TS code, which is used when the application is running. The .map file is an intermediate file generated when compiling TS code through the TS code compilation tool, recording functions, classes and other information in the code.
• When the application after fixing the problem is compiled, the difference part is obtained based on the above .map file and the current TS code, and a quickly repaired .abc file is generated based on the difference part. The .abc file is also the quick fix file that will eventually be placed in the hqf package.

Quickly repair C++ compiled files

The figure above is the process of generating quick repair .so files through differential tools:

• The original application C++ source code is generated by the compilation tool. The .so file is used by the application at runtime.
• The C++ source code after the problem is repaired is used to generate a .so file through the compilation tool. The .so file and the .so file of the original application are used to generate a .so quick repair file through a difference tool. The .so quick repair file will also be eventually placed in the hqf package. quick repair file.

Quick fix package release and deployment process

The modules involved in the above picture are as follows:

• DevEco Studio: Integrated development environment for project engineering for developing code. In the quick repair project, the code of the original application and the code after repairing the problem can be used to generate a quick repair package, and the signature of the quick repair package can be completed.
• Application market server side: Developers will put the developed quick fix package on the platform. The platform will perform signature verification, risk scanning, unpacking and re-signing on the put up package, and then distribute it to the client.
• App Market Client: Used to receive the quick fix package distributed by the App Market server and trigger the installation of the quick fix package.
• Package management service: A system service program on the device used to manage the installation and uninstallation of application packages and quick fix packages.
• Quick Repair Engine: A system service program on the device used to manage app switching using quick fix packages. If the application is running, the quick repair engine will notify the application to switch to the quick fix package after receiving that the quick fix package has been deployed, thereby enabling the application to enable the quick fix package.
• File system: The location where applications and quick fix packages are deployed on the device.

The figure above is the end-to-end release and deployment process of the quick fix package:

1. Developers use DevEco Studio to compile and package a quick fix package based on the source code of the original application and the repaired source code, and complete the signature of the quick fix package through DevEco Studio.
2. The generated quick fix package with signature is put on the application market, and the application market distributes it after verifying the signature, risk scanning, and unpacking and re-signing.
3. When the App Market client on the device detects that there is a newly released quick fix package on the App Market server, it will download the latest version of the quick fix package, and then install and deploy the quick fix package through the package management service in the system.
4. After the quick fix package is deployed, the quick fix engine triggers the application to use the quick fix package, thereby ensuring that users can use the functions after the problem has been fixed.

Debugging process for quick fix packages

• DevEco Studio does not yet have the ability to integrate quick fixes. At the current stage, HarmonyOS provides developers with command line debugging and development tools for use. The specific debugging and development process is as follows:

1. Based on the source code of the original application and the repaired source code, the command line tool can be used to compile and generate a quick repair package, and the command line signature tool can be used to complete the signing of the quick repair package. To debug and develop through the command line, you need to sign the .hqf package and install the .hqf package on the device through the command line tool. The .appqf package cannot be installed directly on the device.
2. Install and deploy the .hqf package to the device through the quick fix command line tool.
3. After the .hqf package is installed and deployed, the callback notifies the quick repair engine to trigger the application to use the quick repair package, thereby ensuring that users can use the functions after the problem is repaired.

at last

Here is a "Hongmeng Zero Basics Beginner's Study Guide", hoping to provide some help to those who want to learn Hongmeng but have no direction. This document is suitable for beginners in HarmonyOS application development (due to the excessive content of the document, in order to avoid affecting everyone’s reading experience, only part of the content is shown in screenshots. There is a free way to obtain the detailed full version at the end of the article!)

"Hongmeng Zero Basics Beginner's Study Guide"

Table of contents

1. Quick Start

Suitable for beginners in HarmonyOS application development. By building a simple application with page jump/return function, you can quickly understand the main files of the project directory and become familiar with the HarmonyOS application development process.

• Development preparation
  • basic concept
  • Tool preparation
• Building the first ArkTS application (Stage model)
• Build the first ArkTS application (FA model)
• Build the first JS application (FA model)

2. Development of basic knowledge

• Application package basics
  • Application package overview
  • Application package structure
  • Application package multi-HAP mechanism
  • Application package installation and uninstallation process
  • Application package update process
  • Shared package
  • Application package quick fix
• Application configuration file (Stage model)
  • Application Profile Overview (Stage Model)
  • app.json5 configuration file
  • module.json5 configuration file
• Application Profile Overview (FA Model)
  • Application Profile Overview (FA Model)
  • app object internal structure
  • deviceConfig internal structure
  • module object internal structure

3. Resource classification and access

During application development, resources such as colors, fonts, spacing, and pictures are often used. The values ​​of these resources may be different in different devices or configurations.

• Resource classification and access
  • Resource classification
  • Resource directory
  • Resource group directory
• Create resource directories and resource files
  • Create resource directories and resource files
  • Create resource directory
  • Create resource files
• resource access
  • Application resources
  • system resource
  • Resource matching
    

4. Learn ArkTs language

ArkTS is the preferred main application development language of HarmonyOS. ArkTS has further expanded on the TypeScript (referred to as TS) ecosystem around application development. It inherits all the features of TS and is a superset of TS. Therefore, before learning the ArkTS language, it is recommended that developers have TS language development capabilities.

• First introduction to ArkTS language
• basic grammar
  • Basic syntax overview
  • Declarative UI description
  • Custom component
• Status management
• Other status management
  • Additional state management overview
  • @Watch decorator: state variable change notification
  • $$ syntax: two-way synchronization of built-in components
• Rendering controls
  • Rendering controls overview
  • if/else: conditional rendering
  • ForEach: Loop rendering
  • LazyForEach: Lazy loading of data

Scan the QR code below to get free "Hongmeng 5.0 Zero Basics Beginner's Study Guide"