diff --git a/en/device-dev/subsystems/development-guidelines.md b/en/device-dev/subsystems/development-guidelines.md deleted file mode 100644 index 64a6bede8653025e29dd2331529177307e69ee4d..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/oem_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/oem_subsys_toolchain_hdc_guide.md b/en/device-dev/subsystems/oem_subsys_toolchain_hdc_guide.md deleted file mode 100644 index 3c72f79eac135f35b8e2a125cd3ede923fc3db05..0000000000000000000000000000000000000000 --- a/en/device-dev/subsystems/oem_subsys_toolchain_hdc_guide.md +++ /dev/null @@ -1,667 +0,0 @@ -# hdc\_std Usage Guidelines - -hdc\_std \(OpenHarmony Device Connector\) is a command line tool provided by OpenHarmony for debugging. With this tool, you can interact with real devices or simulators from a Windows or Linux OS. - -This section describes how to set up the hdc\_std environment and use its common commands. - -## Preparations - -**Obtaining hdc\_std:** - -Obtain **hdc\_std** from the **prebuilt** directory at [developtools\_hdc\_standard](https://gitee.com/openharmony/developtools_hdc_standard). - -**Example:** - -To obtain hdc\_std on Windows, obtain the executable file **hdc\_std.exe** from **prebuilt/windows** and place it in a directory on the disk. - -## Important Notes - -- If an exception occurs when you are using hdc\_std, run the **hdc\_std kill** command to kill the hdc\_std service or run the **hdc\_std start -r** command to restart the service process. -- If no device information is obtained after **hdc\_std list targets** is executed, use the task manager to check whether the **hdc.exe** process exists. If it exists, kill the process. - -## Option-related Commands - -The following commands are available: - -### -h/help -v/version - -Obtains hdc help and version information. - -**Table 1** Command description - - - - - - - - - -

Return Value

-

Description

-

Required information

-

hdc help or version information

-
- -Examples: - -hdc\_std -h / hdc\_std help - -hdc\_std -v / hdc\_std version - -### -t key - -Connects to a device with a specified key. - -**Table 2** Command description - - - - - - - - - - - - - - - -

Parameter

-

Description

-

key

-

Key that identifies the device. The value is in the IP address:Port number format or is a USB serial number.

-

Return Value

-

Description

-

1. error: device '***' not found

-

②Nothing to do...

-

1. The device does not exist.

-

2. The command appended to -t key does not exist.

-
- -Examples: - -This option must be used together with a specific operation command. The following uses the shell command as an example: - -**hdc\_std list targets** \(obtain device information\) - -**hdc\_std -t _key_ shell** \(replace _key_ with the device information obtained\) - ->![](../public_sys-resources/icon-note.gif) **NOTE:** ->You can connect to multiple devices from the device you use for development. Each device has a unique key. The key can be _IP address:Port number_ for a device connected through a network or the serial number for a device connected through USB. - -## Querying the Device List - -The following command is used to query the device list: - -### list targets\[-v\] - -Displays all the connected devices. - -**Table 3** Command description - - - - - - - - - - - - - - - -

Parameter

-

Description

-

-v

-

Prints detailed device information.

-

Return Value

-

Description

-

1. Device information

-

②[Empty]

-

1. A list of connected devices

-

2. No device information is found.

-
- -Examples: - -hdc\_std list targets - -hdc\_std list targets -v - -## Service Process Commands - -The following commands are available: - -### target mount - -Mounts a partition, such as **/system**, with the read and write permissions. - -**Table 4** Command description - - - - - - - - - - - - - - - -

Parameter

-

Description

-

None

-

None

-

Return Value

-

Description

-

①Mount finish

-

2. Returned information

-

1. Information returned when the operation is successful.

-

2. Information returned when the operation fails.

-
- -Example: - -hdc\_std target mount - -### smode \[off\] - -Grants the root permission to a background service process. The **off** option is used to revoke the granted permission. - -Examples: - -hdc\_std smode - -hdc\_std smode off - -### kill \[-r\] - -Stops a service process. - -**Table 5** Command description - - - - - - - - - - - - - - - -

Parameter

-

Description

-

-r

-

Triggers the service restart.

-

Return Value

-

Description

-

①Kill server finish

-

2. Error information

-

1. Information returned when the operation is successful.

-

2. The operation fails.

-
- -Example: - -hdc\_std kill - -### start \[-r\] - -Starts a service process. - -**Table 6** Command description - - - - - - - - - - - - - - - -

Parameter

-

Description

-

-r

-

Restarts the service process if it has started.

-

Return Value

-

Description

-

None

-

None

-
- -Examples: - -hdc\_std start - -## Network Commands - -The following commands are available: - -### tconn _host_\[:_port_\]\[-remove\] - -Connects to a device with a specified IP address and port number. - -**Table 7** Command description - - - - - - - - - - - - - - - - - - -

Parameter

-

Description

-

host[:port]

-

IP address and port number of the device to be connected

-

-remove

-

Disconnects from the specified device.

-

Return Value

-

Description

-

1. Error information

-

2. None

-

1. The operation fails.

-

2. The operation is successful.

-
- -Example: - -hdc\_std tconn 192.168.0.100:8710 - -### tmode usb - -Restarts the daemon process and connects to the device using USB. - -**Table 8** Command description - - - - - - - - - - - - - - - -

Parameter

-

Description

-

None

-

None

-

Return Value

-

Description

-

1. Error information

-

2. None

-

1. The operation fails.

-

2. The operation is successful.

-
- -Example: - -hdc\_std tmode usb - -### tmode port _port-number_ - -Restarts the daemon process and connects to the device over TCP. - -**Table 9** Command description - - - - - - - - - - - - - - - -

Parameter

-

Description

-

port-number

-

Port number used to connect to the device

-

Return Value

-

Description

-

1. Error information

-

2. None

-

1. The operation fails.

-

2. The operation is successful.

-
- -Example: - -hdc\_std tmode port 8710 - ->![](../public_sys-resources/icon-note.gif) **NOTE:** ->After this command is executed, the remote daemon process exits and restarts, and the TCP connection is enabled by default. If you do not include **port-number** in this command, a random port will be used to connect to the device. - -## File Commands - -The following commands are available: - -### file send _local remote_ - -Sends a file to a remote device. - -**Table 10** Command description - - - - - - - - - - - - - - - - - - -

Parameter

-

Description

-

local

-

Path of the file to send

-

remote

-

Destination path on the remote device

-

Return Value

-

Description

-

1. Error information

-

2. File transfer result

-

1. The operation fails.

-

2. The operation is successful.

-
- -Example: - -hdc\_std file send E:\\a.txt /data/local/tmp/a.txt - -### file recv \[-a\] _remote local_ - -Receives a file from a remote device. - -**Table 11** Command description - - - - - - - - - - - - - - - - - - - - - -

Parameter

-

Description

-

-a

-

File retention timestamp mode

-

local

-

Path on the local device to receive the file

-

remote

-

File path on the remote device

-

Return Value

-

Description

-

1. Error information

-

2. None

-

1. The operation fails.

-

2. The operation is successful.

-
- -Example: - -hdc\_std file recv /data/local/tmp/a.txt ./a.txt - -## App Commands - -The following commands are available: - -### install \[-r/-d/-g\] _package_ - -Installs the OpenHarmony application. - -**Table 12** Command description - - - - - - - - - - - - - - - - - - - - - - - - -

Parameter

-

Description

-

package

-

OpenHarmony application installation package

-

-r

-

Replaces an existing application.

-

-d

-

Allows downgraded installation.

-

-g

-

Grants permission dynamically

-

Return Value

-

Description

-

1. Error information

-

2. None

-

1. The operation fails.

-

2. The operation is successful.

-
- -Example: - -hdc\_std install _hwadmin.hap_ - -### uninstall \[-k\] _package_ - -Uninstalls the OpenHarmony application. - -**Table 13** Command description - - - - - - - - - - - - - - - - - - -

Parameter

-

Description

-

package

-

OpenHarmony application installation package

-

-k

-

Retains /data/cache.

-

Return Value

-

Description

-

1. Error information

-

2. None

-

1. The operation fails.

-

2. The operation is successful.

-
- -Example: - -hdc\_std uninstall _package_ - -## Debugging Commands - -The following commands are available: - -### hilog - -Obtains logs for debugging. - -**Table 14** Command description - - - - - - - - - - - - - - - -

Parameter

-

Description

-

None

-

None

-

Return Value

-

Description

-

Returned information

-

Obtained logs

-
- -Example: - -hdc\_std hilog - -### shell \[_command_\] - -Executes a command remotely or enters an interactive command environment. - -**Table 15** Command description - - - - - - - - - - - - - - - -

Parameter

-

Description

-

command

-

Command to be executed

-

Return Value

-

Description

-

Returned information

-

Execution result of the command

-
- -Examples: - -hdc\_std shell - -## Troubleshooting - -### hdc\_std Fails to Connect to a Device - -- **Symptom** - - **\[Empty\]** is displayed in the output after the **hdc\_std list targets** command is executed. - -- **Solutions** - 1. The device cannot be identified. - - Check whether **HDC Device** exists in the universal serial bus device of the device manager. If **HDC Device** does not exist, the device cannot be connected. In this case, remove and then insert the device or burn the latest image for the device. - - 2. hdc\_std works improperly. - - Run the **hdc kill** or **hdc start -r** command to kill or restart the hdc service. Then, run the **hdc list targets** command to check whether device information can be obtained. - - 3. hdc\_std does not match the device. - - If the latest image is burnt on the device, the latest hdc\_std version must be used. As hdc\_std is updated continuously, obtain hdc\_std of the latest version from the **developtools\_hdc\_standard** repository in the **prebuilt** directory. - - - -## hdc\_std Fails to Run - -- **Symptom** - - The **hdc\_std.exe** file does not run after being clicked. - -- **Solutions** - - **hdc\_std.exe** requires no installation. It can be directly used on a disk or added to environment variables. Open the cmd window and run the **hdc\_std** command to use **hdc\_std.exe**. diff --git a/en/device-dev/subsystems/oem_subsys_utils_des.md b/en/device-dev/subsystems/oem_subsys_utils_des.md deleted file mode 100644 index a4fce877812cad2542a191bf2bcd6335a93084ef..0000000000000000000000000000000000000000 --- a/en/device-dev/subsystems/oem_subsys_utils_des.md +++ /dev/null @@ -1,10 +0,0 @@ -# Utils Overview - -The Utils library stores common basic components of OpenHarmony. These basic components can be used by OpenHarmony service subsystems and upper-layer applications. - -The Utils library provides the following capabilities on different platforms: - -LiteOS Cortex-M \(Hi3861 platform\): KV store, file operations, IoT peripheral control, and system attribute dumping - -LiteOS Cortex-A \(Hi3516 or Hi3518 platform\): KV store, timer, JavaScript APIs for data and file storage, and system attribute dumping - diff --git a/en/device-dev/subsystems/oem_subsys_utils_faq.md b/en/device-dev/subsystems/oem_subsys_utils_faq.md deleted file mode 100644 index 0f1ed0e9f06e62e99e05c81ea78333f80bffd007..0000000000000000000000000000000000000000 --- a/en/device-dev/subsystems/oem_subsys_utils_faq.md +++ /dev/null @@ -1,20 +0,0 @@ -# Utils FAQ - -## 1. Failure in running the KV store on the LiteOS Cortex-A kernel \(Hi3516 or Hi3518\) due to incorrect path setting for the KV store - -**Problem** - -When the LiteOS Cortex-A kernel \(Hi3516 or Hi3518 platform\) directly calls the API provided by the KV store, the compiled executable program fails to run. - -**Possible Causes** - -The compiled executable program is run directly without being converted to an application using **AbilityKit** APIs. In this case, the Bundle Manager Service \(BMS\) cannot correctly set the path for storing application data during application installation. As a result, the KV store fails to run. - -**Solution** - -Call the **UtilsSetEnv** function of the KV store to set the data storage path. - -``` -UtilsSetEnv("/storage/com.huawei.kv"); -``` - diff --git a/en/device-dev/subsystems/oem_subsys_utils_guide.md b/en/device-dev/subsystems/oem_subsys_utils_guide.md deleted file mode 100644 index 1988c6b9c43fb96ab6cd04a24fb5148dc8a3648e..0000000000000000000000000000000000000000 --- a/en/device-dev/subsystems/oem_subsys_utils_guide.md +++ /dev/null @@ -1,284 +0,0 @@ -# Utils Development Guidelines - -## Available APIs - -**Table 1** APIs for file operations - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Function

-

Description

-

int UtilsFileOpen(const char* path, int oflag, int mode)

-

Opens or creates a file.

-

int UtilsFileClose(int fd)

-

Closes a file with a specified file descriptor.

-

int UtilsFileRead(int fd, char *buf, unsigned int len)

-

Reads a specified length of data from a file with the specified file descriptor and writes the data into the buffer.

-

int UtilsFileWrite(int fd, const char *buf, unsigned int len)

-

Writes a specified length of data into a file with the specified file descriptor.

-

int UtilsFileDelete(const char *path)

-

Deletes a specified file.

-

int UtilsFileStat(const char *path, unsigned int *fileSize)

-

Obtains the file size.

-

int UtilsFileSeek(int fd, int offset, unsigned int whence)

-

Adjusts the read and write position offset in a file.

-

int UtilsFileCopy(const char* src, const char* dest)

-

Copies the source file to a target file.

-

int UtilsFileMove(const char* src, const char* dest)

-

Moves the source file into a target file.

-
- -Sample code for file operations: - -``` -// Open a file and write data. -char fileName[] = "testfile"; -static const char def[] = "utils_file_operation implement."; -int fd = UtilsFileOpen(fileName, O_RDWR_FS | O_CREAT_FS | O_TRUNC_FS, 0); -printf("file handle = %d\n", fd); -int ret = UtilsFileWrite(fd, def, strlen(def)); -printf("write ret = %d\n", ret); - -// Adjust the position offset in the file. -ret = UtilsFileSeek(fd, 5, SEEK_SET_FS); -printf("lseek ret = %d\n", ret); - -// Read data and close the file. -char buf[64] = {0}; -int readLen = UtilsFileRead(fd, buf, 64); -ret = UtilsFileClose(fd); -printf("read len = %d : buf = %s\n", readLen, buf); - -// Obtain the file size. -int fileLen = 0; -ret = UtilsFileStat(fileName, &fileLen); -printf("file size = %d\n", fileLen); - -// Delete the file. -ret = UtilsFileDelete(fileName); -printf("delete ret = %d\n", ret); -``` - -**Table 2** APIs for KV store operations - - - - - - - - - - - - - - - - -

Function

-

Description

-

int UtilsGetValue(const char* key, char* value, unsigned int len)

-

Obtains the value matching a specified key from the file system or cache.

-

int UtilsSetValue(const char* key, const char* value)

-

Adds or updates the value matching a specified key in the file system or cache.

-

int UtilsDeleteValue(const char* key)

-

Deletes the value matching a specified key from the file system or cache.

-
- -Sample code for the KV store: - -``` -// Set the value matching the specified key. -char key[] = "rw.sys.version_100"; -char value[] = "Hello kv operation implement!"; -int ret = UtilsSetValue(key, value); -printf("UtilsSetValue set ret = %d\n", ret); - -// Obtain the value matching the specified key. -char temp[128] = {0}; -ret = UtilsGetValue(key, temp, 128); -printf("UtilsGetValue get ret = %d, temp = %s\n", ret, temp); - -// Delete the value matching the specified key. -ret = UtilsDeleteValue(key); -printf("UtilsDeleteValue delete ret = %d\n", ret); -``` - -## How to Develop - -### Developing a Native Application for the KV Store That Uses the LiteOS Cortex-A Kernel \(Hi3516 or Hi3518\) - -1. Develop the native application for the KV store using **AbilityKit** APIs. - - Write the user program by calling the APIs provided by the KV store and compile the **libLauncher.so** file. - - ``` - // Set the value matching the specified key. - char key[] = "rw.sys.version_100"; - char value[] = "Hello kv operation implement!"; - int ret = UtilsSetValue(key, value); - printf("UtilsSetValue set ret = %d\n", ret); - - // Obtain the value matching the specified key. - char temp[128] = {0}; - ret = UtilsGetValue(key, temp, 128); - printf("UtilsGetValue get ret = %d, temp = %s\n", ret, temp); - - // Delete the value matching the specified key. - ret = UtilsDeleteValue(key); - printf("UtilsDeleteValue delete ret = %d\n", ret); - ``` - - - Edit the **config.json** file as follows: - - ``` - { - "app": { - "bundleName": "com.huawei.launcher", - "vendor": "huawei", - "version": { - "code": 1, - "name": "1.0" - } - }, - "deviceConfig": { - "default": { - "reqSdk": { - "compatible": "zsdk 1.0.0", - "target": "zsdk 1.0.1" - }, - "keepAlive": false - }, - "smartCamera": { - "reqSdk": { - "compatible": "zsdk 1.0.0", - "target": "zsdk 1.0.1" - }, - "keepAlive": false - } - }, - "module": { - "package": "com.huawei.launcher", - "name": ".MyHarmonyAbilityPackage", - "deviceType": [ - "phone", "tv","tablet", "pc","car","smartWatch","sportsWatch","smartCamera" - ], - "distro": { - "deliveryWithInstall": true, - "moduleName": "Launcher", - "moduleType": "entry" - }, - "abilities": [{ - "name": "MainAbility", - "icon": "res/drawable/phone.png", - "label": "test app 1", - "launchType": "standard", - "type": "page" - }, - { - "name": "SecondAbility", - "icon": "res/drawable/phone.png", - "label": "test app 2", - "launchType": "standard", - "type": "page" - }, - { - "name": "ServiceAbility", - "icon": "res/drawable/phone.png", - "label": "test app 2", - "launchType": "standard", - "type": "service" - } - ] - } - } - ``` - - - Generate a HAP file. - - - Add resource files in the **res/drawable** directory based on the following directory structure. - - ![](figure/unnaming.png) - - - Compress the **libLauncher.so**, **config.json**, and resource files into a ZIP package and change the file name extension to **.hap**, for example, **Launcher.hap**. - -2. Connect the development board and send the command for installing the native KV store application to the board through the serial port. - - ``` - ./nfs/dev_tools/bin/bm install -p /nfs/Launcher.hap - ``` - -3. Send the command for running the native KV store application to the board through the serial port. - - ``` - ./nfs/dev_tools/bin/aa start -p com.huawei.launcher -n ServiceAbility - ``` - - -### Dumping System Attributes on the Platform That Uses the LiteOS Cortex-M Kernel - -1. Connect the development board and send the **AT+SYSPARA** command to the board through the serial port. - - ``` - AT+SYSPARA - ``` - - **Figure 1** Output of the system attribute dumping command for the LiteOS Cortex-M kernel - ![](figure/output-of-the-system-attribute-dumping-command-for-the-liteos-cortex-m-kernel.png "output-of-the-system-attribute-dumping-command-for-the-liteos-cortex-m-kernel") - - -### Dumping System Attributes on the Platform That Uses the LiteOS Cortex-A Kernel - -1. Connect the development board and run the **os\_dump --help** command in the **bin** directory to view the **os\_dump** help information. - - ``` - ./bin/os_dump --help - ``` - -2. Run the **os\_dump -l** command in the **bin** directory to view system modules that support attribute dumping. - - ``` - ./bin/os_dump -l - ``` - -3. Run the **os\_dump syspara** command in the **bin** directory to dump the current system attributes. - - ``` - ./bin/os_dump syspara - ``` - - **Figure 2** Output of the system attribute dumping command for the LiteOS Cortex-A kernel - ![](figure/output-of-the-system-attribute-dumping-command-for-the-liteos-cortex-a-kernel.png "output-of-the-system-attribute-dumping-command-for-the-liteos-cortex-a-kernel") - - diff --git a/en/device-dev/subsystems/subsys-dfx-hicollie-development.md b/en/device-dev/subsystems/subsys-dfx-hicollie.md similarity index 100% rename from en/device-dev/subsystems/subsys-dfx-hicollie-development.md rename to en/device-dev/subsystems/subsys-dfx-hicollie.md diff --git a/en/device-dev/subsystems/subsys-dfx-hisysevent-listening.md b/en/device-dev/subsystems/subsys-dfx-hisysevent-read.md similarity index 100% rename from en/device-dev/subsystems/subsys-dfx-hisysevent-listening.md rename to en/device-dev/subsystems/subsys-dfx-hisysevent-read.md diff --git a/en/device-dev/subsystems/subsys-dfx-hisysevent-query.md b/en/device-dev/subsystems/subsys-dfx-hisysevent-select.md similarity index 100% rename from en/device-dev/subsystems/subsys-dfx-hisysevent-query.md rename to en/device-dev/subsystems/subsys-dfx-hisysevent-select.md diff --git a/en/device-dev/subsystems/subsys-dfx-hisysevent-tool-usage.md b/en/device-dev/subsystems/subsys-dfx-hisysevent-tool.md similarity index 100% rename from en/device-dev/subsystems/subsys-dfx-hisysevent-tool-usage.md rename to en/device-dev/subsystems/subsys-dfx-hisysevent-tool.md diff --git a/en/device-dev/subsystems/subsys-dfx-hisysevent-logging.md b/en/device-dev/subsystems/subsys-dfx-hisysevent-write.md similarity index 100% rename from en/device-dev/subsystems/subsys-dfx-hisysevent-logging.md rename to en/device-dev/subsystems/subsys-dfx-hisysevent-write.md diff --git a/en/device-dev/subsystems/subsys-dfx-hitrace-development.md b/en/device-dev/subsystems/subsys-dfx-hitrace.md similarity index 100% rename from en/device-dev/subsystems/subsys-dfx-hitrace-development.md rename to en/device-dev/subsystems/subsys-dfx-hitrace.md 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. -