> This method is supported since API version 7. Updates will be marked with a superscript to indicate their earliest API version.
## Modules to Import
```
import app from '@system.app'
```
## Required Permissions
None
## app.setImageCacheCount
setImageCacheCount(value: number): void
Sets the maximum number of decoded images that can be cached in the memory to speed up the loading of images from the same sources. If the input parameter is not set, the default value **0** is used, indicating that images are not cached. The built-in Least Recently Used (LRU) policy is used for caching. After new images are loaded, if the upper limit of the cache is exceeded, the images that have not been updated for the longest time will be replaced. You are advised to set the input parameter based on the application memory requirements. If the number of images is too large, the memory usage may be too high.
- Parameters
| Name | Type | Mandatory | Description |
| -------- | -------- | -------- | -------- |
| value | number | Yes | Number of decoded images that are cached in the memory. |
- Example
```
// app.ets
import app from '@system.app';
export default {
onCreate() {
app.setImageCacheCount(100) // Set the maximum number of decoded images that can be cached in the memory to 100.
console.info('Application onCreate')
},
onDestroy() {
console.info('Application onDestroy')
},
}
```
## app.setImageRawDataCacheSize
setImageRawDataCacheSize(value: number): void
Sets the maximum size (in bytes) of the image data cached in the memory before decoding to speed up the loading of images from the same sources. If the input parameter is not set, the default value **0** is used, indicating that images are not cached. The LRU policy is used for caching. After new images are loaded, if the upper limit of the cache is exceeded, the images that have not been updated for the longest time will be replaced. You are advised to set the input parameter based on the application memory requirements. If the image cache is too large, the memory usage may be too high.
- Parameters
| Name | Type | Mandatory | Description |
| -------- | -------- | -------- | -------- |
| value | number | Yes | Size of the image data cached before decoding, in bytes. |
- Example
```
// app.ets
import app from '@system.app';
export default {
onCreate() {
app.setImageRawDataCacheSize(104,857,600) // Set the upper limit of the memory for caching image data before decoding to 100 MB.
console.info('Application onCreate')
},
onDestroy() {
console.info('Application onDestroy')
},
}
```
## app.setImageFileCacheSize
setImageFileCacheSize(value: number): void
Sets the maximum size of the image file cache (in bytes) to speed up the loading of images from the same sources, especially online image sources and thumbnails. If the input parameter is not set, the default value 100 MB is used. The LRU policy is used for caching. After new images are loaded, if the upper limit of the cache is exceeded, the images that have not been updated for the longest time will be replaced. You are advised to set the input parameter based on the application memory requirements. If the image cache is too large, the disk usage may be too high.
- Parameters
| Name | Type | Mandatory | Description |
| -------- | -------- | -------- | -------- |
| value | number | Yes | Size of the image file cache, in bytes. |
- Example
```
// app.ets
import app from '@system.app';
export default {
onCreate() {
app.setImageFileCacheSize(209,715,200) // Set the upper limit of the image file cache to 200 MB.
An ability is an abstraction of a functionality that an application can provide. Abilities of applications are classified into two types: Feature Ability \(FA\) and Particle Ability \(PA\).
-**AbilitySlice**
An AbilitySlice is the combination of a single visualized UI and its interactive logic. AbilitySlice is the fundamental unit of a Feature Ability. A Feature Ability can contain a group of UIs representing closely associated services, and each UI corresponds to one AbilitySlice.
-**AMS**
Ability Manager Service, a service that manages abilities
OpenHarmony Ability Package, released as a HAP file. One HAP file describes all content of an application, including code, resources, third-party libraries, and a configuration file.
-**HCS**
HDF Configuration Source \(HCS\) describes the HDF configuration using key-value pairs. HCS is designed to decouple configuration code from driver code, thereby facilitating configuration management.
-**HC-GEN**
HDF Configuration Generator \(HC-GEN\) is a tool for converting a configuration file into a file that can be read by the target software.
-**HDF**
Hardware Driver Foundation that allows unified access from peripheral devices and provides foundation for driver development and management in OpenHarmony
Intelligent Distributed Networking, a distributed networking capability unit specific to OpenHarmony. You can use IDN to obtain the device list and device states and subscribe to the connection state changes of devices on the distributed network.
Particle Ability, representing an ability without a UI. PAs are invoked to implement Feature Ability \(FA\) functionalities. For example, a PA runs in the background to provide the computing capability or acts as a data warehouse to provide the data access capability.
Also called super device. It integrates the capabilities of multiple devices through the distributed technology into a virtual hardware resource pool and then centrally manages and schedules these capabilities based on application requirements.
-**System type**
- Mini system: refers to a system running on the devices whose memory is greater than or equal to 128 KB and that are equipped with only limited resources and MCU processors such as ARM Cortex-M and 32-bit RISC-V. This system provides rich short-distance connection capabilities and a bus for accessing peripherals. This system applies to smart home products such as LinkIoT module devices and sensors.
- Small system: refers to a system running on the devices whose memory is greater than or equal to 1 MB and that are equipped with application processors such as ARM Cortex-A. This system provides higher security capabilities, standard graphics frameworks, and video encoding and decoding capabilities. This system applies to smart home products such as IP cameras, peephole cameras, and routers as well as smart travel products such as event data recorders \(EDRs\).
- Standard system: refers to a system running on the devices whose memory is greater than or equal to 128 MB and that are equipped with application processors such as ARM Cortex-A. This system provides a complete application framework supporting the enhanced interaction, 3D GPU, hardware composer, diverse components, and rich animations. This system applies to high-end refrigerator displays.
- Large system: refers to a system running on the devices whose memory is greater than or equal to 1 GB and that are equipped with application processors such as ARM Cortex-A. This system provides a complete compatible application framework. This system applies to smart TVs and watches.
# Before You Start<a name="EN-US_TOPIC_0000001199722625"></a>
This document provides basic guidance for OpenHarmony developers and system on a chip \(SoC\) or module vendors to port OpenHarmony to typical chip architectures, such as the cortex-M and RISC-V series. Currently, the Bluetooth service is not supported. Due to the complexity of the OpenHarmony project, this document is subject to update as the version and APIs change.
This guide is intended for readers who have experience in developing embedded systems. Therefore, it mainly describes operations and key points during platform porting instead of basic introduction to the OS.
The implementation of the OpenHarmony project directories and functions relies on the OS itself. If no enhancement for a complex feature is involved, you only need to focus on the directories described in the following table.
**Table 1** Key directories in the porting process
<tdclass="cellrowborder"valign="top"width="72.28999999999999%"headers="mcps1.2.3.1.2 "><pid="p1573342917172"><aname="p1573342917172"></a><aname="p1573342917172"></a>Basic building framework for <spanid="text8913173395513"><aname="text8913173395513"></a><aname="text8913173395513"></a>OpenHarmony</span></p>
<tdclass="cellrowborder"valign="top"width="72.28999999999999%"headers="mcps1.2.3.1.2 "><pid="p92741311181915"><aname="p92741311181915"></a><aname="p92741311181915"></a>Basic kernel. The implementation related to the chip architecture is in the <strongid="b155382041192418"><aname="b155382041192418"></a><aname="b155382041192418"></a>arch</strong> directory.</p>
<tdclass="cellrowborder"valign="top"width="72.28999999999999%"headers="mcps1.2.3.1.2 "><pid="p64331415171913"><aname="p64331415171913"></a><aname="p64331415171913"></a>Board-level code implementation, which is provided by third-party vendors based on the <spanid="text117091750175520"><aname="text117091750175520"></a><aname="text117091750175520"></a>OpenHarmony</span> specifications. For detailed structure about the <strongid="b118614195115"><aname="b118614195115"></a><aname="b118614195115"></a>device</strong> directory and porting process, see <ahref="porting-chip-board-overview.md">Board-Level OS Porting</a>.</p>
<tdclass="cellrowborder"valign="top"width="72.28999999999999%"headers="mcps1.2.3.1.2 "><pid="p1849841341920"><aname="p1849841341920"></a><aname="p1849841341920"></a>Product-level implementation, which is contributed by Huawei or product vendors.</p>
</td>
</tr>
</tbody>
</table>
The **device** directory is in the internal structure of **device/\{Chip solution vendor\}/\{Development board\}**. The following uses HiSilicon **hispark\_taurus** as an example:
```
device
└── hisilicon # Name of the chip solution vendor
├── common # Common part of the chip solution development board
└── hispark_taurus # Name of the development board
├── BUILD.gn # Entry to building the development board
├── hals # OS hardware adaptation of the chip solution vendor
├── linux # Linux version
│ └── config.gni # Configurations of the building toolchain and building options for the Linux version
└── liteos_a # LiteOS Cortex-A version
└── config.gni # Configurations of the building toolchain and building options for the LiteOS Cortex-A version
```
The **vendor** directory is in the internal structure of **vendor/\{Product solution vendor\}/\{Product name\}**. The following uses Huawei Wi-Fi IoT product as an example:
```
vendor # Product solution vendor
└── huawei # Name of the product solution vendor
└── wifiiot # Product name
├── hals # OS adaptation of the product solution vendor
The **device** directory of OpenHarmony is the adaptation directory for the basic SoC. You can skip the porting process and directly develop system applications if complete SoC adaptation code is already available in the directory. If there is no corresponding SoC porting implementation in the directory, complete the porting process by following the instructions provided in this document. The following figure shows the process of porting OpenHarmony to a third-party SoC.
**Figure 1** Key steps for SoC porting<aname="fig24801925498"></a>
- The porting must comply with the basic OpenHarmony principles described in [Contribution](../../contribute/contribution.md).
- The code required for third-party SoC adaptation is stored in the **device**, **vendor**, and **arch** directories. Naming and usage of these directories must comply with specified naming and usage specifications. For details, see [Directory Specifications](porting-chip-kernel-overview.md) and [Board-Level Directory Specifications](porting-chip-board-overview.md#section6204129143013).
This document provides development guidelines related to the telephony subsystem, including modem vendor library integration, initialization, service request responding, and modem event reporting. It is intended as a reference for developers of different modem chips, helping them efficiently develop telephony service-related functions.
## Basic Concepts<a name="section187mcpsimp"></a>
- Telephony Service: core service layer of the telephony subsystem. Its main functions are as follows:
- Initializes the RIL Manager module, SIM card module, and network search modules.
- Provides access to the RIL Adapter service, and implements communication with RIL Adapter by registering the callback service.
- Implements communication between modules, such as the call module and SMS module, by subscribing to callbacks.
- RIL Adapter: RIL adaptation layer of the Telephony subsystem. This layer provides functions such as vendor library loading and service API implementation. It shields the differences of modems supplied by different vendors to provide a unified API for the telephony service layer. It communicates with the telephony service layer by registering the Hardware Driver Foundation \(HDF\) service.
- HDF: Hardware Driver Foundation, which allows for unified access from peripheral devices and provides a framework for driver development and management.
- hdc\_std: OpenHarmony Device Connector, a command line tool provided by OpenHarmony for developers to debug device connectivity.
## Working Principles<a name="section194mcpsimp"></a>
As shown in the preceding figure, RIL Adapter is logically divided into three layers: **hril\_hdf**, **hril**, and **vendorlib**.
-**hril\_hdf**: unique entry of RIL Adapter. The main function of this layer is to load modem vendor library files. Wherein, **modem\_adapter** enables a single firmware to adapt to different modems.
Specifically, **hril\_hdf** obtains the modem type from the kernel and then loads the target modem vendor library based on the modem type.
-**hril**: OpenHarmony Radio Interface Layer, which provides APIs for communication between the **vendorlib** and various Telephony Service modules, including the SIM card, network search, cellular call, cellular data, and SMS/MMS modules.
-**vendorlib**: Modem vendor library file. Different modem vendor libraries are developed based on standard APIs or service request IDs provided by RIL Adapter. \(**vendorlib** is provided by modem vendors.\)
After **hril\_hdf** is executed, **vendorlib** is dynamically loaded so that it can obtain the pointers to the response processing and event reporting functions from **hril\_hdf**. After this process is complete, **hril\_hdf** can communicate with a modem through **vendorlib**.
## Constraints<a name="section205mcpsimp"></a>
**Specifications**
At least one modem must be supported by a device vendor. If no modem is supported, **vendorlib** APIs do not need to be implemented.
The OpenHarmony driver subsystem is constructed using the C object-oriented programming \(OOP\). It provides a unified driver platform through platform decoupling, kernel decoupling, and compatible kernels. This unified driver architecture platform is designed to provide a more precise and efficient development environment, where you develop a driver that can be deployed on different systems supporting HDF.
The OpenHarmony driver subsystem provides the following key features and capabilities to shorten the driver development period and make third-party device driver integration much easier:
- Flexible framework capabilities
Based on the traditional driver framework, the OpenHarmony driver subsystem builds flexible framework capabilities to deploy terminal products with the capacity ranging from hundreds KB to hundreds MB of memory.
- Standardized driver APIs
The OpenHarmony driver subsystem provides you with abundant and stable driver APIs, which are compatible with those of future-proof smartphones, tablets, smart TVs.
- Component-based driver models
The OpenHarmony driver subsystem supports component-based driver models. It provides more refined driver management to dismantle components, enabling you to focus on the interaction between the hardware and driver.
The subsystem also presets some template-based driver model components, such as the network device models.
- Normalized configuration GUIs
The OpenHarmony driver subsystem provides a unified configuration GUI and a cross-platform tool for configuration conversion and generation to implement seamless switchover across platforms.
You can use DevEco to manage driver projects, generate driver templates, and manage settings to make the development of OpenHarmony drivers easier.
Driver loading is mostly done by the driver framework, and you only need to register and configure required APIs. The driver framework will load and initialize the driver based on the parsing content.
Driver development based on the HDF consists of the following three parts:
1. Driver: Develop the functions.
2. Information configuration: Present the loading information of the driver.
3. Resource configuration: Configure the hardware information of the driver.
The driver mainly aims to develop the functions.
The first part that catches your eyes is the driver entry, which is described through **DriverEntry**.
Three APIs are available, namely **bind**, **init**, and **release**.
```
struct HdfDriverEntry g_deviceSample = {
.moduleVersion = 1,
.moduleName = "sample_driver",
.Bind = SampleDriverBind,
.Init = SampleDriverInit,
.Release = SampleDriverRelease,
};
```
**Bind**: This API is used to bind driver devices and its functions.
// And you can also initialize device resources here.
return HDF_SUCCESS;
}
```
**Init**: When devices are successfully bound, the framework calls **Init** to initialize the driver. After initialization is complete, the driver framework will determine whether to create external service interfaces based on the configuration file. If the driver fails to be initialized, the driver framework will automatically release the created device interface.
**Release**: When you need to uninstall a driver, the driver framework calls this function to release the driver resources. Then, other internal resources will be released.
The OpenHarmony driver is mainly deployed in the kernel space using the static link mode. It is compiled and packed with the kernel subsystem and system image.
This document describes the changes of APIs in OpenHarmony 3.1 LTS when compared with OpenHarmony 3.1 Beta.
## API Changes
| Module| API| Change Type| Change Description|
| -------- | -------- | -------- | -------- |
| Distributed Hardware Subsystem - DeviceManager| release(): void | Deleted| This API is deleted to reduce security risks.|
| Distributed Hardware Subsystem - DeviceManager| getTrustedDeviceListSync(): Array<DeviceInfo> | Deleted| This API is deleted to reduce security risks.|
| Distributed Hardware Subsystem - DeviceManager| on(type: 'deviceStateChange', callback: Callback<{action:DeviceStateChangeAction,device:DeviceInfo}>): void | Deleted| This API is deleted to reduce security risks.|
| Distributed Hardware Subsystem - DeviceManager| off(type: 'deviceStateChange', callback?: Call back<{action:DeviceStateChangeAction,device:DeviceInfo}>): void | Deleted| This API is deleted to reduce security risks.|
| Distributed Hardware Subsystem - DeviceManager| on(type: 'serviceDie', callback: () => void): void | Deleted| This API is deleted to reduce security risks.|
| Distributed Hardware Subsystem - DeviceManager| off(type: 'serviceDie', callback?: () => void): void | Deleted| This API is deleted to reduce security risks.|
