@@ -374,7 +374,7 @@ For details about how to obtain the source code of OpenHarmony, see [Source Cod
...
@@ -374,7 +374,7 @@ For details about how to obtain the source code of OpenHarmony, see [Source Cod
For details about how to join in the OpenHarmony community, see [OpenHarmony Community](https://gitee.com/openharmony/community/blob/master/README.md).
For details about how to join in the OpenHarmony community, see [OpenHarmony Community](https://gitee.com/openharmony/community/blob/master/README.md).
For details about how to contribute, see [Contribution](https://gitee.com/openharmony/docs/blob/master/en/contribute/contribution.md).
For details about how to contribute, see [How to Contribute](https://gitee.com/openharmony/docs/blob/master/en/contribute/how-to-contribute.md).
If an application is targeted for users and markets in different regions with different languages and time zones, it is necessary for you to provide localized versions to ensure good experience for your users.
If an application is targeted for users and markets in different regions with different languages and time zones, it is necessary for you to provide localized versions to ensure good experience for your users.
## Initializing a Modem Vendor Library<a name="section211mcpsimp"></a>
### When to Use<a name="section213mcpsimp"></a>
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<a name="section811343241215"></a>
The following table describes the API for initializing a modem vendor library.
**Table 1** API for initializing a modem vendor library
<tdclass="cellrowborder"valign="top"width="50%"headers="mcps1.2.3.1.2 "><pid="p239mcpsimp"><aname="p239mcpsimp"></a><aname="p239mcpsimp"></a>Function: Provides an entry for running a modem vendor library.</p>
<pid="p240mcpsimp"><aname="p240mcpsimp"></a><aname="p240mcpsimp"></a><strongid="b164737479278"><aname="b164737479278"></a><aname="b164737479278"></a>reportOps</strong>: Specifies the pointer to the event callback function, which is passed by RIL Adapter.</p>
<pid="p241mcpsimp"><aname="p241mcpsimp"></a><aname="p241mcpsimp"></a>Return result: function pointer of the service request API.</p>
</td>
</tr>
</tbody>
</table>
### How to Develop<a name="section51031144122"></a>
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.
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.
.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<a name="section5351151517132"></a>
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
## Responding to Modem Service Requests<a name="section295mcpsimp"></a>
### When to Use<a name="section297mcpsimp"></a>
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<a name="section9503155219134"></a>
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
<aname="ul1676502416411"></a><aname="ul1676502416411"></a><ulid="ul1676502416411"><li><strongid="b1576510240416"><aname="b1576510240416"></a><aname="b1576510240416"></a>data</strong>: called number</li></ul>
<aname="ul842034134114"></a><aname="ul842034134114"></a><ulid="ul842034134114"><li><strongid="b1542193411415"><aname="b1542193411415"></a><aname="b1542193411415"></a>dataLen</strong>: data length</li></ul>
<tdclass="cellrowborder"valign="top"width="50.160000000000004%"headers="mcps1.2.3.1.2 "><pid="p328mcpsimp"><aname="p328mcpsimp"></a><aname="p328mcpsimp"></a>Function: Reports the execution result of a service request to RIL Adapter.</p>
<aname="ul18380115494513"></a><aname="ul18380115494513"></a><ulid="ul18380115494513"><li><strongid="b83808549457"><aname="b83808549457"></a><aname="b83808549457"></a>data</strong>: called number</li></ul>
<aname="ul118421156184517"></a><aname="ul118421156184517"></a><ulid="ul118421156184517"><li><strongid="b48421056144519"><aname="b48421056144519"></a><aname="b48421056144519"></a>dataLen</strong>: data length</li></ul>
OnCallReport(reportInfo, NULL, 0); // Invoke the callback function of the call service.
```
### Debugging and Verification<a name="section10207938171413"></a>
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---------------------
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:
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<a name="section191193791518"></a>
The following table describes the API for reporting modem events.
<tdclass="cellrowborder"valign="top"width="48%"headers="mcps1.2.3.1.2 "><pid="p423mcpsimp"><aname="p423mcpsimp"></a><aname="p423mcpsimp"></a>Function: Distributes the events reported by the modem.</p>
<aname="ul678053915191"></a><aname="ul678053915191"></a><ulid="ul678053915191"><li><strongid="b14780173912196"><aname="b14780173912196"></a><aname="b14780173912196"></a>s</strong>: AT command prefix</li></ul>
<aname="ul206343434192"></a><aname="ul206343434192"></a><ulid="ul206343434192"><li><strongid="b65891958173518"><aname="b65891958173518"></a><aname="b65891958173518"></a>smsPdu</strong>: PDU of the SMS message</li></ul>
### How to Develop<a name="section16394112401512"></a>
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.
### Debugging and Verification<a name="section16999174401516"></a>
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---------------------
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 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<a name="section33444350167"></a>
-**Outgoing Call**
The following figure shows the API calling for an outgoing call.
**Figure 1** Time sequence of API calling for an outgoing call<a name="fig494mcpsimp"></a>
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.
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<a name="fig556mcpsimp"></a>
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.
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**:
### Debugging and Verification<a name="section620mcpsimp"></a>
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.
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.
