This article aims to deeply explore the technical details of the Huawei HarmonyOS Next system (up to API 12 as of now) in developing multilingual e-commerce platforms, and is summarized based on actual development practices. It mainly serves as a vehicle for technical sharing and communication. Mistakes and omissions are inevitable. Colleagues are welcome to put forward valuable opinions and questions so that we can make progress together. This article is original content, and any form of reprint must indicate the source and the original author.
In the digital wave, the security of mobile applications has been increasingly emphasized. The HarmonyOS Next system, with its powerful application encryption capabilities, provides developers with comprehensive protection for code security. Today, we will explore in depth the application encryption mechanism of HarmonyOS Next, including its capability introduction, encryption impacts, encryption effects, and usage steps, to help developers better understand and apply this important feature.

I. Capability Introduction

(I) End-to-End Encryption Mechanism

The application encryption of HarmonyOS Next provides end-to-end security assurance. From the moment developers upload the application package until the application runs on users' devices, every step is encrypted. When developers submit an application for listing to the application market, they can choose to encrypt the application package. Once encryption is selected, after the application market approves the application, it will perform code encryption on the listed application. At this time, when the application is installed on the device, the installation file remains encrypted even after it is saved to the disk, effectively preventing the application program from being illegally obtained and tampered with. When the application is launched, the application files loaded by the kernel are in an encrypted state. These files will be decrypted and executed on demand in the kernel, and the decrypted plaintext only exists in the memory and will not be stored on the device, thus forming a complete end-to-end encryption scheme. This encryption method ensures that even if the application installation package is stolen during transmission or storage, attackers cannot obtain the source code of the application, significantly enhancing the security of the application.

(II) Advantages of System-Level Application Encryption

1. End-to-End Encryption of Applications, Decryption and Execution on Demand The system-level end-to-end encryption ensures the security of the application throughout its life cycle. During the application startup process, the decryption operation is only performed when the kernel executes the relevant code, reducing the risk of exposing plaintext code. For example, in a financial application during operation, the code related to users' fund transactions will only be decrypted when the actual transaction operation is performed. At other times, it is stored in ciphertext form, effectively preventing attackers from obtaining sensitive information when the application is not running critical code.
2. System-Level Decryption Optimization with Minimal Performance Impact Compared with traditional reinforcement methods such as packing, the system-level application encryption of HarmonyOS Next has a smaller impact on performance. This is because the system has fully considered the impact of the encryption and decryption processes on performance during design and has carried out optimization. In actual applications, compared with unencrypted applications, encrypted applications have little difference in startup speed and running efficiency, and will not cause obvious stuttering to users, ensuring the smoothness of the user experience.
3. Secure Storage of Decryption Keys The decryption keys are securely transmitted and then stored in the system TEE (Trusted Execution Environment). The TEE provides a secure execution environment independent of the ordinary operating system, with higher security. Even if the device is breached, it is extremely difficult for attackers to obtain the decryption keys stored in the TEE, further ensuring the security of the application code. ## II. Encryption Impacts ### (I) Impact on Performance Encrypted applications may slightly increase performance overhead during program startup and running. This is mainly due to the need for decryption operations during application startup and the possible encryption and decryption processing of data during running. However, through system optimization, this performance overhead is kept within a small range and usually does not have a significant impact on the user experience. For example, in some performance tests, the startup time of encrypted applications may increase by several tens of milliseconds, which is within the acceptable range for users. Moreover, as hardware performance continues to improve, this performance impact will gradually become negligible. ### (II) Impact on Volume Encrypted applications have a larger volume compared to unencrypted applications because the encryption process adds additional encrypted data and related information. The larger application volume may cause a slight increase in download and installation time. However, in the modern network environment where network speeds are constantly increasing, this increased time usually does not cause too much trouble for users. Meanwhile, developers can reasonably optimize application resources during the application development process to minimize unnecessary files and data, thereby reducing the impact of encryption on volume. ## III. Encryption Effects ### (I) Encryption Objects and Security The main encryption objects are the compiled code files within the application, covering.abc files (except for the file header, the entire file is encrypted). This encryption method makes it possible to decompile the code files before encryption, but the encrypted code files cannot be analyzed, effectively protecting the application code from reverse analysis and cracking. For example, when attackers attempt to decompile an encrypted application, since the code files have been encrypted, they will not be able to obtain meaningful source code information, thus being unable to perform malicious tampering or stealing of application logic. Currently,.so files are not encrypted by default, but they may be encrypted according to developer requirements in the future to further enhance the overall security of the application. ### (II) Security of Encryption Keys Since the keys used for application encryption do not appear in the application package at all, even if the encrypted application package is obtained, attackers can only get the ciphertext of the code and still need to crack the AES encryption algorithm to perform reverse analysis. AES is a widely used and highly secure encryption algorithm with extremely high difficulty in cracking, providing a solid security guarantee for the application code. ## IV. Usage Steps ### (I) Development Stage During the development stage, developers do not need to perform additional encryption operations and can focus on developing the application functions. At this time, the application code is written and debugged in plaintext form, facilitating the development work of developers. ### (II) Listing Stage
4. Select and Upload the Software Package to be Released After completing the application development, developers select the software package to be released and upload it to the application market. During the upload process, they can choose whether to encrypt the distributed software package.
5. Select the Encryption Option If developers choose to encrypt, the application market will perform encryption processing on the application after approval. This process is transparent to developers. Developers only need to focus on selecting the encryption option to ensure that the application obtains effective security protection before distribution. ### (III) Distribution Stage The application will be encrypted and distributed by the application market, ensuring that the application installation package exists in ciphertext form during transmission, preventing the installation package from being obtained and then reverse-analyzed. When distributing the encrypted application, the application market will adopt a secure transmission protocol to ensure the integrity and confidentiality of the application package. ### (IV) Installation Stage
6. Key Negotiation and Storage When the application is installed on the device, the decryption key is securely stored in the TEE environment after end-cloud secure negotiation. This process ensures the security of the key and provides crucial support for the decryption operation when the application runs.
7. Installation File Encryption Storage After the installation file is saved to the disk, it remains in an encrypted state, preventing the application files stored locally on the device from being illegally accessed and tampered with. ### (V) Running Stage When the kernel loads the application, it decrypts on demand. Only when the application executes specific code will the kernel decrypt the corresponding encrypted code, ensuring the security and performance balance of the application during running. For example, when the application starts and enters the login interface, the code related to login will be decrypted and executed, while the other unused code parts remain encrypted. The application encryption feature of HarmonyOS Next provides comprehensive and powerful protection for application code security. Although there are certain impacts on performance and volume, these impacts can be effectively controlled through system optimization and reasonable development strategies. We need to make full use of this feature to provide users with more secure and reliable applications. We hope this article can help you deeply understand the application encryption mechanism of HarmonyOS Next and better ensure application security during the application development process.