diff --git a/en/application-dev/reference/arkui-ts/ts-methods-image-cache.md b/en/application-dev/reference/arkui-ts/ts-methods-image-cache.md deleted file mode 100644 index e5f20cef2cae60690a45a4d796bdaa8a4ebbb4a4..0000000000000000000000000000000000000000 --- a/en/application-dev/reference/arkui-ts/ts-methods-image-cache.md +++ /dev/null @@ -1,104 +0,0 @@ -# Image Cache - - -> ![icon-note.gif](public_sys-resources/icon-note.gif) **NOTE** -> 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. - console.info('Application onCreate') - }, - onDestroy() { - console.info('Application onDestroy') - }, - } - ``` diff --git a/en/device-dev/glossary/Readme-EN.md b/en/device-dev/glossary/Readme-EN.md deleted file mode 100644 index 1e7ccafe473286de0e48494b45a313bedad2c4e1..0000000000000000000000000000000000000000 --- a/en/device-dev/glossary/Readme-EN.md +++ /dev/null @@ -1,4 +0,0 @@ -# Glossary - -[Glossary](glossary.md) - diff --git a/en/device-dev/glossary/glossary.md b/en/device-dev/glossary/glossary.md deleted file mode 100644 index a405ee58159b03570a352e4a2e931541befef933..0000000000000000000000000000000000000000 --- a/en/device-dev/glossary/glossary.md +++ /dev/null @@ -1,91 +0,0 @@ -# Glossary - -## A - -- **Ability** - - 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 - - -## B - -- **BMS** - - Bundle Manager Service, a service that manages application bundles - - -## D - -- **DevEco Studio for Embedded** - - Integrated development environment \(IDE\) for developing embedded devices - -- **DMS** - - Distributed Management Service, a service used for distributed data management - - -## F - -- **FA** - - Feature Ability, representing an ability with a UI for interacting with users - - -## H - -- **HAP** - - 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 - - -## I - -- **IDN** - - 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. - - -## P - -- **PA** - - 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. - - -## S - -- **Super virtual device** - - 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. - - diff --git a/en/device-dev/porting/oem_transplant_chip_prepare_knows.md b/en/device-dev/porting/oem_transplant_chip_prepare_knows.md deleted file mode 100644 index 232021a6f31ee4869c9511bfd6161b3adf0bbcf9..0000000000000000000000000000000000000000 --- a/en/device-dev/porting/oem_transplant_chip_prepare_knows.md +++ /dev/null @@ -1,80 +0,0 @@ -# Before You Start - -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. - -## Porting Directory - -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 - - - - - - - - - - - - - - - - - - - -

Directory

-

Description

-

/build/lite

-

Basic building framework for OpenHarmony

-

/kernel/liteos_m

-

Basic kernel. The implementation related to the chip architecture is in the arch directory.

-

/device

-

Board-level code implementation, which is provided by third-party vendors based on the OpenHarmony specifications. For detailed structure about the device directory and porting process, see Board-Level OS Porting.

-

/vendor

-

Product-level implementation, which is contributed by Huawei or product vendors.

-
- -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 - ├── BUILD.gn # Product building script - └── config.json # Product configuration file -``` - -## Porting Process - -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 -![](figure/key-steps-for-soc-porting.png "key-steps-for-soc-porting") - -## Porting Specifications - -- 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). - diff --git a/en/device-dev/subsystems/development-guidelines.md b/en/device-dev/subsystems/development-guidelines.md deleted file mode 100644 index 12a68e42514757dcc387b9ab0345253ed357337d..0000000000000000000000000000000000000000 --- a/en/device-dev/subsystems/development-guidelines.md +++ /dev/null @@ -1,592 +0,0 @@ -# Development Guidelines - -## Initializing a Modem Vendor Library - -### When to Use - -Initializing a modem vendor library means to implement **const HRilOps \*RilInitOps\(const struct HRilReport \*reportOps\)** function in the vendor library. This function is mainly used to: - -- Receive function pointers to event callbacks of RIL Adapter. When a service event needs to be reported, the target pointer will be called to report the event to RIL Adapter. -- Create a thread for reading modem nodes. In this thread, the data reported by the modem is read cyclically and parsed as a specific service event for reporting. -- Return the function pointer of the service request API to RIL Adapter. - -### Available APIs - -The following table describes the API for initializing a modem vendor library. - -**Table 1** API for initializing a modem vendor library - - - - - - - - - - -

API

-

Description

-

const HRilOps *RilInitOps(const struct HRilReport * reportOps)

-

Function: Provides an entry for running a modem vendor library.

-

Input parameter:

-

reportOps: Specifies the pointer to the event callback function, which is passed by RIL Adapter.

-

Return result: function pointer of the service request API.

-
- -### How to Develop - -1. Set the event callback function pointers passed by RIL Adapter through **RilInitOps**. - - ``` - // Define the callback function pointers of the modem vendor library. - static struct HRilReport g_reportOps = { - OnCallReport, // Callback function for call services - OnDataReport, // Callback function for cellular data services - OnModemReport, // Callback function for modem services - OnNetworkReport, // Callback function for network search services - OnSimReport, // Callback function for SIM card services - OnSmsReport // Callback function for SMS services - }; - ``` - - -1. Create the **g\_reader** main thread to enable message looping. - - ``` - pthread_attr_t t; - pthread_attr_init(&t); - pthread_attr_setdetachstate(&t, PTHREAD_CREATE_DETACHED); - ret = pthread_create(&g_reader, &t, ReaderLoop, &t); // Create the g_reader thread. - ``` - - -1. In the **g\_eventListeners** thread, use **open\(\)** to open a modem node and then create the **g\_reader** thread to read and process messages reported by the modem. - - ``` - g_fd = open(g_devicePath, O_RDWR); // Open the device node specified by g_devicePath. - pthread_attr_init(&attr); - pthread_attr_setdetachstate(&attr, PTHREAD_CREATE_DETACHED); - ret = pthread_create(&g_eventListeners, &attr, EventListeners, NULL); - ``` - - -1. Return the function pointer of the service request API. - - ``` - // Structure for the service request API of the call module - typedef struct { - // Obtain the call list. - void (*GetCallList)(ReqDataInfo *requestInfo, const void *data, size_t dataLen); - // Make a call. - void (*Dial)(ReqDataInfo *requestInfo, const void *data, size_t dataLen); - // Disconnect a call. - void (*Hangup)(ReqDataInfo *requestInfo, const void *data, size_t dataLen); - // Reject a call. - void (*Reject)(ReqDataInfo *requestInfo, const void *data, size_t dataLen); - // Answer a call. - void (*Answer)(ReqDataInfo *requestInfo, const void *data, size_t dataLen); - } HRilCallReq; - - // Callback function pointers of the call module - static const HRilCallReq g_callReqOps = { - .GetCallList = ReqGetCallList, // Obtain the call list. - .Dial = ReqDial, // Make a call. - .Hangup = ReqHangup, // Disconnect a call. - .Reject = ReqReject, // Reject a call. - .Answer = ReqAnswer, // Answer a call. - }; - - // Service request structure - typedef struct { - const HRilCallReq *callOps; // Pointer to the structure of call service requests - const HRilSimReq *simOps; // Pointer to the structure of SIM card service requests - const HRilSmsReq *smsOps; // Pointer to the structure of SMS and MMS service requests - const HRilDataReq *dataOps; // Pointer to the structure of cellular data service requests - const HRilNetworkReq *networkOps; // Pointer to the structure of network search service requests - const HRilModemReq *modemOps; // Pointer to the structure of modem service requests - } HRilOps; - - // Service request APIs - HRilOps g_hrilOps = { - .callOps = &g_callReqOps, // API for call service requests - .simOps = &g_simReqOps, // API for SIM card service requests - .smsOps = &g_smsReqOps, // API for SMS and MMS service requests - .networkOps = &g_networkReqOps, // API for cellular data service requests - .dataOps = &g_dataReqOps, // API for network search service requests - .modemOps = &g_modemReqOps, // API for modem service requests - }; - ``` - - -### Debugging and Verification - -1. Use the [hdc\_std](https://gitee.com/openharmony/docs/blob/master/en/device-dev/subsystems/subsys-toolchain-hdc-guide.md#preparations) tool to connect to a debugging device. Then, run the following command to send the generated **libril\_vendor.z.so** library file to the **/system/lib/** directory of the device. For details about how to integrate a library file, see [Integrating Modem Vendor Libraries](#section590mcpsimp). - - ``` - hdc_std file send libril_vendor.z.so /system/lib/ - ``` - -2. Reboot the debugging device. - - ``` - hdc_std shell sync - hdc_std shell reboot - ``` - -3. Run the **hdc\_std shell hilog** command to view the debug log, and check whether the **RilInitOps\(\)** function is successfully executed. The following debug log is for reference: - - ``` - 01-01 05:13:23.071 136 2319 D 00000/RilAdapterInit: [RilAdapterDispatch-(hril_hdf.c:55)] sbuf IPC obtain test success! - 01-01 05:13:23.071 136 2319 D 00000/RilAdapterInit: [LoadVendor-(hril_hdf.c:33)] RilInit rilInit start - 01-01 05:13:23.071 136 2319 D 00000/RilAdapterInit: [LoadVendor -(hril_hdf.c:45)] RilInit rilInit completed - ``` - - -## Responding to Modem Service Requests - -### When to Use - -After receiving a specific telephony service request, RIL Adapter calls the target function pointer obtained in modem vendor library initialization to send a specific service request to the vendor library. Then, the vendor library processes the request based on the request ID. - -### Available APIs - -The following table describes the APIs for responding to modem service requests, with the dial module as an example. - -**Table 2** APIs for responding to modem service requests - - - - - - - - - - - - - -

API

-

Description

-

void ReqDial(ReqDataInfo *requestInfo, const void *data, size_t dataLen);

-

Function: Processes number dial requests.

-

Input parameters:

-
  • requestInfo: request type
-
  • data: called number
-
  • dataLen: data length
-

Return value: none

-

void (*OnCallReport)(struct ReportInfo reportInfo, const void *data, size_t dataLen);

-

Function: Reports the execution result of a service request to RIL Adapter.

-

Input parameters:

-
  • reportInfo: request type
-
  • data: called number
-
  • dataLen: data length
-

Return value: none

-
- -### How to Develop - -1. Implement processing of dial requests in the **ReqDial\(\)** API. - - ``` - // Implement the API for processing dial requests. - void ReqDial(ReqDataInfo *requestInfo, const void *data, size_t dataLen) - { - HRilDial *pDial = NULL; - char cmd[MAX_BUFF_SIZE] = {0}; - const char *clir = NULL; - int ret; - int err = HRIL_ERR_SUCCESS; - struct ReportInfo reportInfo = {}; - ResponseInfo *pResponse = NULL; - if (data == NULL) { - TELEPHONY_LOGE("data is null!!!"); - err = HRIL_ERR_INVALID_PARAMETER; - reportInfo = CreateReportInfo(requestInfo, err, HRIL_RESPONSE, 0); - OnCallReport(reportInfo, NULL, 0); - return; - } - pDial = (HRilDial *)data; - switch (pDial->clir) { - case CALL_CLIR_INVOCATION: - clir = "I"; - break; /* invocation */ - case CALL_CLIR_SUPPRESSION: - clir = "i"; - break; /* suppression */ - case CALL_CLIR_SUBSCRIPTION_DEFUALT: - default: - clir = ""; - break; /* subscription default */ - } - (void)sprintf_s(cmd, MAX_BUFF_SIZE, "ATD%s%s;", pDial->address, clir); - ret = SendCommandLock(cmd, NULL, 0, &pResponse); // Send the AT command. - ...... - } - ``` - -2. After the modem executes the dial command, report the execution result to RIL Adapter via **OnCallReport\(\)**. - - ``` - ret = SendCommandLock(cmd, NULL, 0, &pResponse); - if (ret != 0 || (pResponse != NULL && pResponse->success == 0)) { - TELEPHONY_LOGE("ATD send failed"); - err = HRIL_ERR_GENERIC_FAILURE; - } - reportInfo = CreateReportInfo(requestInfo, err, HRIL_RESPONSE, 0); - OnCallReport(reportInfo, NULL, 0); // Invoke the callback function of the call service. - ``` - - -### Debugging and Verification - -1. Use the [hdc\_std](en-us_topic_0000001080478129.md#section05992022154916) tool to connect to a debugging device. Then, run the following command to send the generated **libril\_vendor.z.so** library file to the **/system/lib/** directory of the device. - - ``` - hdc_std file send libril_vendor.z.so /system/lib/ - ``` - -2. Reboot the debugging device. - - ``` - hdc_std shell sync - hdc_std shell reboot - ``` - -3. Run the **hdc\_std shell** command. Then, run the **./system/bin/ril\_adapter\_test** command, type **1**, and enter the phone number as prompted to test the call function. - - ``` - hdc_std shell - # ./system/bin/ril_adapter_test - ----> Test Enter --------->Call--------------------- - - 1----> RilUnitTest::OnRequestCallDialTest - 2----> RilUnitTest:: OnRequestCallHangupTest - 3----> RilUnitTest:: OnRequestCallAnswerTest - 4----> RilUnitTest::OnRequestCallGetCurrentCallsStatusTest - 5----> RilUnitTest::OnRequestRefusedCallTest - - 1 - ``` - -4. Open another terminal window, and run the **hdc\_std shell hilog** command. Then, view the log to check whether **ReqDial\(\)** is successfully executed. The following debug log is for reference: - - ``` - 01-01 05:27:27.419 136 408 D 02b01/Rilvendor: [SendCommandLock-(at_support.c:210)] SendCommandLock enter, cmd: ATD17620373527 - 01-01 05:27:27.419 136 408 D 02b01/Rilvendor: [SendCommandLock-(at_support.c:231)] SendCommandLock() command ATD17620373527 - 01-01 05:27:27.419 136 408 D 02b01/Rilvendor: [WriteATCommand-(channel.c:115)] WriteATCommand enter, cmd:ATD17620373527 - 01-01 05:27:27.421 136 187 D 02b01/Rilvendor: [ReadResponse-(channel.c:94)] g_bufferCur : - 01-01 05:27:27.421 136 187 D 02b01/Rilvendor: OK - 01-01 05:27:27.422 136 187 D 02b01/Rilvendor: [ProcessResponse-(at_support.c:144)] processLine line = OK - 01-01 05:27:27.422 136 187 D 02b01/Rilvendor: [ReadResponse-(channel.c:81)] ReadResponse enter - 01-01 05:27:27.422 136 187 D 02b01/Rilvendor: [ProcessLastResponse-(channel.c:37)] last data more than one line , FindEndOfLine g_bufferCur: - 01-01 05:27:27.422 136 187 E 02b01/Rilvendor: [ProcessLastResponse-(channel.c:39)] g_bufferCur endLine is null - 01-01 05:27:27.422 136 187 E 02b01/Rilvendor:^ORIG:1,0 - 01-01 05:27:27.422 136 408 E 02b01/Rilvendor: [SendCommandLock-(at_support.c:234)] processLine line = ^ORIG:1,0 - 01-01 05:27:27.422 136 408 E 02b01/Rilvendor: [SendCommandLock-(vendor_report.c:234)] enter to [^ORIG:1,0]: (null) - 01-01 05:27:27.422 136 408 E 02b01/Rilvendor: [SendCommandLock-(at_support.c:264)] err = 0, cmd:ADT17620373527 - ``` - - -## Reporting Modem Events - -### When to Use - -A modem node thread reads the messages reported by the modem cyclically, parses the messages into specific events, and then reports the events to RIL Adapter. - -### Available APIs - -The following table describes the API for reporting modem events. - -**Table 3** API for reporting modem events - - - - - - - - - - -

API

-

Description

-

void OnNotifyOps(const char *s, const char *smsPdu)

-

Function: Distributes the events reported by the modem.

-

Input parameters:

-
  • s: AT command prefix
-
  • smsPdu: PDU of the SMS message
-

Return value: none

-
- -### How to Develop - -1. Call **OnNotifyOps\(\)** in the g\_reader thread of the modem device node to parse reported modem events. On determining the command type, call **OnXxxReport\(\)** to report the parsed module events to the hril layer. - - ``` - // Parse the data reported by the modem as events proactively reported by the corresponding module. - void OnNotifyOps(const char *s, const char *smsPdu) - { - int ret = 0; - struct ReportInfo reportInfo = {0}; - reportInfo.error = HRIL_ERR_SUCCESS; - reportInfo.type = HRIL_NOTIFICATION; - if (GetRadioState() == HRIL_RADIO_POWER_STATE_UNAVAILABLE) { - return; - } - TELEPHONY_LOGD("enter to [%{public}s]:%{public}s", s, smsPdu); - // Determine the type of the proactively reported events based on the AT command. - if (ReportStrWith(s, "+CRING:") || ReportStrWith(s, "RING") || ReportStrWith(s, "IRING") || - ReportStrWith(s, "NO CARRIER") || ReportStrWith(s, "+CCWA") || ReportStrWith(s, "^CCALLSTATE") || - ReportStrWith(s, "^CEND") || ReportStrWith(s, "^CCWA")) { - reportInfo.notifyId = HNOTI_CALL_STATE_UPDATED; - OnCallReport(reportInfo, NULL, 0); - } else if (ReportStrWith(s, "+CMT:")) { - reportInfo.notifyId = HNOTI_SMS_NEW_SMS; - OnSmsReport(reportInfo, (void *)smsPdu, strlen(smsPdu)); - } - // Report the events of each module to the hril layer. - ... - } - ``` - - -1. Distribute the reported events from the **hril** layer to the Telephony Service layer. - - ``` - // Report the call status proactively. - int32_t HRilCall::CallStateUpdated( - int32_t slotId, int32_t notifyType, const HRilErrno e, const void *response, size_t responseLen) - { - struct HdfSBuf *dataSbuf = HdfSBufTypedObtain(SBUF_IPC); - if (serviceCallbackNotify_ == nullptr) { - TELEPHONY_LOGE("RilAdapter serviceCallbackNotify_ is null"); - HdfSBufRecycle(dataSbuf); - return HDF_FAILURE; - } - // Distribute events. - int32_t ret = serviceCallbackNotify_->dispatcher->Dispatch( - serviceCallbackNotify_, HNOTI_CALL_STATE_UPDATED, dataSbuf, nullptr); - if (ret != HDF_SUCCESS) { - HdfSBufRecycle(dataSbuf); - return HDF_FAILURE; - } - HdfSBufRecycle(dataSbuf); - return HDF_SUCCESS; - } - ``` - - -### Debugging and Verification - -1. Use the [hdc\_std](en-us_topic_0000001080478129.md#section05992022154916) tool to connect to a debugging device. Then, run the following command to send the generated **libril\_vendor.z.so** library file to the **/system/lib/** directory of the device. - - ``` - hdc_std file send libril_vendor.z.so /system/lib/ - ``` - -2. Reboot the debugging device. - - ``` - hdc_std shell sync - hdc_std shell reboot - ``` - -3. Run the **hdc\_std shell** command. Then, run the **./system/bin/ril\_adapter\_test** command, type **1**, and enter the phone number as prompted to test the call function. - - ``` - hdc_std shell - # ./system/bin/ril_adapter_test - ----> Test Enter --------->Call--------------------- - - 1----> RilUnitTest::OnRequestCallDialTest - 2----> RilUnitTest:: OnRequestCallHangupTest - 3----> RilUnitTest:: OnRequestCallAnswerTest - 4----> RilUnitTest::OnRequestCallGetCurrentCallsStatusTest - 5----> RilUnitTest::OnRequestRefusedCallTest - - 1 - ``` - -4. Open another terminal window, and run the **hdc\_std shell hilog** command. Then, view the log to check whether **OnNotifyOps\(\)** is successfully executed. The following debug log is for reference: - - ``` - 01-01 00:08:01.334 546 551 D 02b01/TelRilTest: [DialResponse-(tel_ril_call.cpp:280)] DialResponse --> radioResponseInfo->serial:2, radioResponseInfo->error:0 - 01-01 00:08:01.334 546 557 D 02b01/TelRilTest: [ProcessEvent-(tel_ril_test.cpp:1262)] TelRilTest::DemoHandler::ProcessEvent --> eventId:101 - 01-01 00:08:01.334 143 512 D 02b01/Rilvendor: [ReadResponse-(channel.c:93)] g_bufferCur : - 01-01 00:08:01.334 143 512 D 02b01/Rilvendor: ^ORIG:1,0 - 01-01 00:08:01.334 143 512 D 02b01/Rilvendor: [ReadResponse-(channel.c:108)] AT< ^ORIG:1,0 - 01-01 00:08:01.334 143 512 D 02b01/Rilvendor: [ProcessResponse-(at_support.c:137)] processLine line = ^ORIG:1,0 - 01-01 00:08:01.334 143 512 D 02b01/Rilvendor: [OnNotifyOps-(vendor_report.c:126)] enter to [^ORIG:1,0]:(null) - 01-01 00:08:01.335 143 512 W 02b01/Rilvendor: [OnNotifyOps-(vendor_report.c:167)] enter to is unrecognized command: ^ORIG:1,0 - 01-01 00:08:01.335 143 512 D 02b01/Rilvendor: [ProcessLastResponse-(channel.c:37)] last data more than one line , FindEndOfLine g_bufferCur: - 01-01 00:08:01.335 143 512 E 02b01/Rilvendor: [ProcessLastResponse-(channel.c:39)] g_bufferCur endLine is null - 01-01 00:08:01.336 143 512 D 02b01/Rilvendor: [ReadResponse-(channel.c:93)] g_bufferCur : - 01-01 00:08:01.336 143 512 D 02b01/Rilvendor: ^CCALLSTATE: 1,0,1 - 01-01 00:08:01.336 143 512 D 02b01/Rilvendor: [ReadResponse-(channel.c:108)] AT< ^CCALLSTATE: 1,0,1 - 01-01 00:08:01.336 143 512 D 02b01/Rilvendor: [ProcessResponse-(at_support.c:137)] processLine line = ^CCALLSTATE: 1,0,1 - 01-01 00:08:01.336 143 512 D 02b01/Rilvendor: [OnNotifyOps-(vendor_report.c:126)] enter to [^CCALLSTATE: 1,0,1]:(null) - 01-01 00:08:01.336 546 551 D 02b01/CoreService: [OnRemoteRequest-(tel_ril_manager.cpp:80)] RilManager OnRemoteRequest code:1001 - 01-01 00:08:01.336 546 551 D 02b01/CoreService: [NotifyObserver-(observer_handler.cpp:76)] handler->SendEvent:8 - ``` - - -### Development Examples - -- **Outgoing Call** - - The following figure shows the API calling for an outgoing call. - - **Figure 1** Time sequence of API calling for an outgoing call - - - ![](figure/en-us_image_0000001171507146.png) - - When an application initiates an outgoing call, RIL Adapter receives a call request, and the **hril** layer invokes the **ReqDial\(\)** function. In **ReqDial\(\)**, the data passed by the Telephony Service is encapsulated as an AT command and sent to the modem. After executing the dial command, the modem reports the execution result to RIL Adapter through **OnCallReport\(\)**. - - ``` - // Callback function pointer of the call module - static const HRilCallReq g_callReqOps = { - .GetCallList = ReqGetCallList, // Obtain the call list. - .Dial = ReqDial, // Make a call. - .Hangup = ReqHangup, // Disconnect a call. - .Reject = ReqReject, // Reject a call. - .Answer = ReqAnswer, // Answer a call. - }; - - // Service request APIs - HRilOps g_hrilOps = { - .callOps = &g_callReqOps, // API for call service requests - .simOps = &g_simReqOps, // API for SIM card service requests - .smsOps = &g_smsReqOps, // API for SMS and MMS service requests - .networkOps = &g_networkReqOps, // API for cellular data service requests - .dataOps = &g_dataReqOps, // API for network search service requests - .modemOps = &g_modemReqOps, // API for modem service requests - }; - - // Implement the API for processing dial requests. - void ReqDial(ReqDataInfo *requestInfo, const void *data, size_t dataLen) - { - HRilDial *pDial = NULL; - char cmd[MAX_BUFF_SIZE] = {0}; - const char *clir = NULL; - int ret; - int err = HRIL_ERR_SUCCESS; - struct ReportInfo reportInfo = {}; - ResponseInfo *pResponse = NULL; - if (data == NULL) { - TELEPHONY_LOGE("data is null!!!"); - err = HRIL_ERR_INVALID_PARAMETER; - reportInfo = CreateReportInfo(requestInfo, err, HRIL_RESPONSE, 0); - OnCallReport(reportInfo, NULL, 0); - return; - } - pDial = (HRilDial *)data; - switch (pDial->clir) { - case CALL_CLIR_INVOCATION: - clir = "I"; - break; /* invocation */ - case CALL_CLIR_SUPPRESSION: - clir = "i"; - break; /* suppression */ - case CALL_CLIR_SUBSCRIPTION_DEFUALT: - default: - clir = ""; - break; /* subscription default */ - } - (void)sprintf_s(cmd, MAX_BUFF_SIZE, "ATD%s%s;", pDial->address, clir); - ret = SendCommandLock(cmd, NULL, 0, &pResponse); // Send the AT command. - if (ret != 0) { - err = HRIL_ERR_CMD_SEND_FAILURE; - TELEPHONY_LOGE("ATD send failed"); - } else { - if (pResponse != NULL && pResponse->success == 0) { - TELEPHONY_LOGE("ReqDial return ERROR"); - err = HRIL_ERR_CMD_NO_CARRIER; - } - } - reportInfo = CreateReportInfo(requestInfo, err, HRIL_RESPONSE, 0); - OnCallReport(reportInfo, NULL, 0); // Invoke the callback function of the call service. - FreeResponseInfo(pResponse); - } - ``` - - -- **Incoming Call** - - The following figure shows the API calling of an incoming call. - - **Figure 2** Time sequence of API calling for an incoming call - - - ![](figure/en-us_image_0000001214727595.png) - - The **g\_reader** thread cyclically reads the messages reported by the modem. When the modem receives an incoming call event, it actively reports the information about the incoming call. - - The **g\_reader** thread calls **OnNotifyOps\(\)** to parse the reported information. If the parsed data reported by the modem starts with characters such as **+CRING** or **RING**, it indicates that an incoming call event exists. In this case, the event is reported to RIL Adapter through **OnCallReport\(reportInfo, NULL, 0\)**. - - ``` - // Parse the data reported by the modem as events proactively reported by the corresponding module. - void OnNotifyOps(const char *s, const char *smsPdu) - { - int ret = 0; - struct ReportInfo reportInfo = {0}; - reportInfo.error = HRIL_ERR_SUCCESS; - reportInfo.type = HRIL_NOTIFICATION; - if (GetRadioState() == HRIL_RADIO_POWER_STATE_UNAVAILABLE) { - return; - } - TELEPHONY_LOGD("enter to [%{public}s]:%{public}s", s, smsPdu); - // Determine the type of the proactively reported events based on the AT command. - if (ReportStrWith(s, "+CRING:") || ReportStrWith(s, "RING") || ReportStrWith(s, "IRING") || - ReportStrWith(s, "NO CARRIER") || ReportStrWith(s, "+CCWA") || ReportStrWith(s, "^CCALLSTATE") || - ReportStrWith(s, "^CEND") || ReportStrWith(s, "^CCWA")) { - reportInfo.notifyId = HNOTI_CALL_STATE_UPDATED; - OnCallReport(reportInfo, NULL, 0); // Invoke the callback function of the call service. - } else if (ReportStrWith(s, "+CMT:")) { - reportInfo.notifyId = HNOTI_SMS_NEW_SMS; - OnSmsReport(reportInfo, (void *)smsPdu, strlen(smsPdu)); - } - // add your codes - ...... - } - ``` - - -## Integrating Modem Vendor Libraries - -### Configuring Compilation Information - -Compile the modem vendor library into a dynamic library by using **BUILD.gn**. Upon startup, RIL Adapter loads the dynamic library to the system in dlopen mode and then initializes the library. For details about how to implement vendor library initialization, see [Initializing a Modem Vendor Library](#section211mcpsimp). The following is an example of **BUILD.gn**: - -``` -import("//build/ohos.gni") -RIL_ADAPTER = "//base/telephony" -ohos_shared_library("ril_vendor") { // Modem vendor library - sources = [ // Source files to compile - "at_call.c", - "at_data.c", - "xxx.c", - ] - include_dirs = [ // Header files - "$RIL_ADAPTER/ril_adapter/vendor/include", - "$RIL_ADAPTER/ril_adapter/interfaces/innerkits", - "include", - ] - deps = [ // Internal dependencies - "//drivers/adapter/uhdf2/osal:libhdf_utils", - "//base/telephony/core_service/utils:libtelephony_common", - ] - external_deps = [ "hilog:libhilog" ] // External dependencies - - part_name = "ril_adapter" // Part name - subsystem_name = "telephony" // Subsystem name -} -``` - -### Debugging and Verification - -1. Compile the code. -2. Check whether **libril\_vendor.z.so** exists in the **/out/{device_name}/telephony/ril\_adapter** directory. If yes, the integration is successful. Otherwise, correct the error and perform debugging and verification again. - diff --git a/en/device-dev/subsystems/telephony-service.md b/en/device-dev/subsystems/telephony-service.md deleted file mode 100644 index 8ea0cfbad4b42ca98c019c95a2b552028b3f4fca..0000000000000000000000000000000000000000 --- a/en/device-dev/subsystems/telephony-service.md +++ /dev/null @@ -1,41 +0,0 @@ -# Telephony Service - -## Introduction - -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 - -- 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 - -**Figure 1** RIL Adapter architecture - - -![](figure/en-us_image_0000001210683929.png) - -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 - -**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. - diff --git a/en/readme/driver-subsystem.md b/en/readme/driver-subsystem.md deleted file mode 100644 index 27f908a20f8cd114f7043946855762e4c52e9e29..0000000000000000000000000000000000000000 --- a/en/readme/driver-subsystem.md +++ /dev/null @@ -1,149 +0,0 @@ -# Driver Subsystem - -## Overview - -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. - -## Architecture - -The OpenHarmony driver framework adopts the primary/secondary mode and is developed based on the framework, model, competence library, and tool. - -**Figure 1** Driver subsystem architecture -![](figures/driver-subsystem-architecture.png "driver-subsystem-architecture") - -- Driver framework stored in the **framework/core** directory - - Loads and starts drivers. - - Deploys and expands the driver framework flexibly through the object manager. - -- Driver model stored in the **framework/model** directory - - Provides model-based driving capabilities, such as network device models. - -- Driver capability library stored in the **framework/ability** directory - - Provides basic driver models, such as the I/O communication model. - -- Driver tools stored in the **framework/tools** directory - - Provides tools for HDI API conversion, and driver configuration and driver compilation. - -- Driver APIs stored in the **lite/hdi** directory - - Provides standardized driver APIs. - -- Support stored in the **framework/support** directory - - Provides platform driver APIs and system APIs with normalized abstraction capabilities. - - -## Directory Structure - -``` -drivers -├── adapter # Adaptation code for differentiated platforms -├── framework # Core code of the HDF -└── peripheral # Peripheral driver code -``` - -## Use - -**Figure 2** Interaction between the driver and framework -![](figures/interaction-between-the-driver-and-framework.png "interaction-between-the-driver-and-framework") - -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. - -``` -int32_t SampleDriverBind(struct HdfDeviceObject *deviceObject) -{ - // TODO: Bind device service to device object. - // 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. - -``` -int32_t SampleDriverInit(struct HdfDeviceObject *deviceObject) -{ - // TODO: Init hardware or other resources here. - return HDF_SUCCESS; -} -``` - -**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. - -``` -void SampleDriverRelease(struct HdfDeviceObject *deviceObject) -{ - // Release all resources. - return; -} -``` - -## Installation - -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. - -**Figure 3** Driver installation -![](figures/driver-installation.png "driver-installation") - -## Repositories Involved - -**Driver subsystem** - -[drivers\_framework](https://gitee.com/openharmony/drivers_framework/blob/master/README.md) - -[drivers\_adapter](https://gitee.com/openharmony/drivers_adapter/blob/master/README.md) - -[drivers\_adapter\_khdf\_linux](https://gitee.com/openharmony/drivers_adapter_khdf_linux/blob/master/README.md) - -[drivers\_peripheral](https://gitee.com/openharmony/drivers_peripheral/blob/master/README.md) - diff --git a/en/release-notes/api-change/v3.1-LTS/js-apidiff-v3.1-LTS.md b/en/release-notes/api-change/v3.1-LTS/js-apidiff-v3.1-LTS.md deleted file mode 100644 index e40d1ab4846f6d898ce3f9cb16ae7cb6322e3393..0000000000000000000000000000000000000000 --- a/en/release-notes/api-change/v3.1-LTS/js-apidiff-v3.1-LTS.md +++ /dev/null @@ -1,14 +0,0 @@ -# JS API Diff - -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 | 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.|