WO2023024589A1 - 请求的处理方法及相关装置 - Google Patents

请求的处理方法及相关装置 Download PDF

Info

Publication number
WO2023024589A1
WO2023024589A1 PCT/CN2022/092926 CN2022092926W WO2023024589A1 WO 2023024589 A1 WO2023024589 A1 WO 2023024589A1 CN 2022092926 W CN2022092926 W CN 2022092926W WO 2023024589 A1 WO2023024589 A1 WO 2023024589A1
Authority
WO
WIPO (PCT)
Prior art keywords
request
caller
response data
data corresponding
interface
Prior art date
Application number
PCT/CN2022/092926
Other languages
English (en)
French (fr)
Inventor
徐自翔
Original Assignee
荣耀终端有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 荣耀终端有限公司 filed Critical 荣耀终端有限公司
Priority to EP22859937.9A priority Critical patent/EP4236260A4/en
Publication of WO2023024589A1 publication Critical patent/WO2023024589A1/zh

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions

Definitions

  • the present application relates to the field of electronic information technology, and in particular to a request processing method and related devices.
  • the application side usually interacts with the modem processor (Modem) and its hardware abstraction layer (Hardware Abstraction Layer, HAL) layer by calling an abstraction layer interface definition language (HAL interface definition language, HIDL) interface.
  • HAL interface definition language HAL interface definition language
  • the HIDL interface has the implementation of the client (Client) and the server (Server).
  • the client refers to the party that calls the method through HIDL
  • the server refers to the party that implements the HIDL interface, accepts the call from the client and returns data.
  • the solution for sending a request from the application side to the modem processor (Modem) for processing is: when a caller on the application side sends a request, call the client end of the HIDL interface corresponding to the caller, and the caller sends The request will be processed on the server side of the HIDL interface on the HAL layer.
  • the server side of the HIDL interface will send the request to the Modem, and the Modem will process it to obtain the response data corresponding to the request.
  • the client end of the HIDL interface and the server end are bound one by one, and each server end of the HIDL interface is fixedly registered with a client end of the HIDL interface.
  • the server side of a HIDL interface can only receive the request sent by the client side of a HIDL interface and return the result to it. It does not support the server side of a HIDL interface to process the requests sent by the client side of multiple HIDL interfaces at the same time. Function.
  • the present application provides a request processing method and a related device, aiming to solve the problem that a server that does not support one HIDL interface simultaneously processes requests sent by multiple HIDL interface clients.
  • the present application discloses a request processing method applied to a first device.
  • the request processing method includes: sending requests from multiple callers to a service server of the first device interface. Wherein, the request carries information used to describe the caller to which the request belongs. Then receive the response data corresponding to each request returned by the server end of the first device interface. Wherein, the response data corresponding to the request carries information for describing the caller to which the request belongs. For the response data corresponding to each request, the caller to which the response data corresponding to the request belongs is identified according to the information carried in the response data corresponding to the request for describing the caller to which the request belongs. For the response data corresponding to each request, the response data corresponding to the request is returned to the caller to which the response data corresponding to the request belongs.
  • the caller to which the response data corresponding to the request belongs is identified, and then the response data corresponding to each request can be returned to the response
  • the caller to which the data belongs satisfies the requirement that the clients of multiple HIDL interfaces simultaneously process requests from multiple callers.
  • the first device interface is the HIDL interface of the first device, and after sending the requests of multiple callers to the service server of the first device interface, it also includes: passing through the HIDL interface of the first device The Server side of the interface sends each caller's request to the Modem of the first device. Each request is processed through the Modem of the first device, and response data corresponding to each request is obtained. Further, the response data corresponding to each request returned by the Modem through the Server side of the HIDL interface of the first device is received.
  • the first device interface may also be another type of interface, which is not limited.
  • the request of each caller is sent to the Modem of the first device through the Server end of the HIDL interface of the first device, including: calling the HIDL interface of the first device through the interface proxy module
  • the server side sends each caller's request to the Modem of the first device.
  • the interface proxy module pre-creates the proxy object of the Client side of the HIDL interface corresponding to each caller.
  • Receiving the response data corresponding to each request returned by the Modem through the Server end of the HIDL interface of the first device including: through the interface proxy module, receiving the Modem through the Server end of the HIDL interface of the first device, corresponding to each request returned response data.
  • the requests of the multiple callers include: the request of the caller of the first device, and/or the request of the caller of the second device.
  • the service server of the first device interface before sending the requests of multiple callers to the service server of the first device interface, it also includes: for each caller's request, according to the caller's identifier, the The serial parameter is processed so that the processed serial parameter in the request can be used to indicate the caller to which the request belongs.
  • the information used to describe the caller to which the request belongs is: the processed serial parameter in the request.
  • For the response data corresponding to each request before returning the response data corresponding to the request to the caller to which the response data corresponding to the request belongs, it also includes: for the response data corresponding to each request, return the processed response data in the response data corresponding to the request The serial parameter is restored.
  • the serial parameter in the request is processed according to the identifier of the caller, so that the processed serial parameter in the request can be used to describe the call to which the request belongs Party, including: for each request of the caller, according to the identification of the caller, offset the serial parameter in the request with the offset value corresponding to the caller, so that the processed serial parameter in the request can be used to indicate the request belongs to the caller.
  • the serial parameter after offset processing can be used to indicate the caller to which the request belongs.
  • the response data corresponding to each request identify the caller to which the response data corresponding to the request belongs according to the processed serial parameter in the response data corresponding to the request, including: for each request For the corresponding response data, match the processed serial parameters in the response data corresponding to the request with the value range of the serial parameters corresponding to each caller, and determine the matching caller as the one to which the response data corresponding to the request belongs. caller.
  • the information used to describe the caller to which the request belongs is: an identifier of the caller to which the request belongs.
  • Receiving the response data corresponding to each request returned by the server end of the first device interface includes: receiving the response data corresponding to each request returned by the server end of the first device interface through the client end of the first device interface.
  • the Client side of the first device interface is pre-set with a field for supporting the identification of each caller
  • the Server side of the first device interface is pre-set with a field for supporting the identification of each caller.
  • Both can support receiving request and response data carrying the identifier of the caller to which the request belongs.
  • the requests of multiple callers include: the request of the caller of the first device and the request of the caller of the second device
  • the requests of the multiple callers are sent to the second device.
  • the service server of a device interface it also includes: for each request of the caller of the first device, according to the identifier of the caller, the serial parameter in the request is processed, so that the processed serial parameter in the request is available To describe the caller to which the request belongs, or, for each request of the caller of the first device and the second device, process the serial parameter in the request according to the identifier of the caller, so that the processed serial parameter in the request Parameters can be used to say which caller the request belongs to.
  • the information used to describe the caller to which the request belongs is: the processed serial parameter in the request.
  • each response data corresponding to the request before returning the response data corresponding to the request to the caller to which the response data corresponding to the request belongs, it also includes: for each response data belonging to the first device Response data corresponding to the request corresponding to the request, restore the processed serial parameters in the response data corresponding to the request, or, for each response data corresponding to the request belonging to the first device and the second device, the corresponding Restore the processed serial parameter in the response data.
  • the serial parameter in the request is processed so that the processed serial parameter in the request can be used to describe the caller to which the request belongs, including: according to the identifier of the caller, the The serial parameter offset corresponds to the offset value of the caller, so that the processed serial parameter in the request can be used to describe the caller to which the request belongs.
  • the present application discloses another request processing method, which is applied to the second device.
  • the request processing method includes: sending the request of the caller of the second device to the first device, so that the first device sends the request to the first device.
  • the request of the caller of the second device is sent to the server end of the first device interface, and the response data corresponding to each request returned by the server end of the first device interface is received.
  • the request carries information used to describe the caller to which the request belongs.
  • the first device and the second device are in a connected state. Then receive the response data corresponding to each request belonging to the second device returned by the first device.
  • the caller to which the response data corresponding to the request belongs is identified by the first device according to the information carried in the response data corresponding to the request for describing the caller to which the request belongs. For the response data corresponding to each request, return the response data to the caller to which the response data belongs.
  • the second device can receive each The response data corresponding to the request belonging to the second device, and then for the response data corresponding to each request, the response data can be returned to the caller to which the response data belongs, so as to realize the processing of multiple calls of different devices through the server side of the first device interface Party's request.
  • the method before sending the request of the caller of the second device to the first device, the method further includes: receiving the request of the caller of the first device through an interface proxy module.
  • the interface proxy module pre-creates the proxy object of the client end of the HIDL interface corresponding to the caller of the first device, and the proxy object of the client end of the HIDL interface corresponding to the caller of the second device.
  • the method before sending the request of the caller of the second device to the first device, the method further includes:
  • the serial parameter in the request is processed according to the identifier of the caller, so that the processed serial parameter in the request can be used to describe the caller to which the request belongs.
  • each response data corresponding to the request before returning the response data to the caller to which the response data belongs, it also includes: for each response data corresponding to the request belonging to the second device, sending Restore the processed serial parameter in the response data corresponding to the request.
  • the serial parameter in the request is processed according to the identifier of the caller, so that the processed serial parameter in the request can be used to describe
  • the caller to which the request belongs includes: for each request of the caller of the second device, according to the identifier of the caller, offset the serial parameter in the request with the offset value corresponding to the caller, so that the processed The serial parameter of can be used to say which caller the request belongs to.
  • the second device if it has multiple callers, for each response data corresponding to the request, before returning the response data to the caller to which the response data belongs, it also includes: for each For the response data corresponding to a request, identify the caller to which the response data corresponding to the request belongs according to the information carried in the response data corresponding to the request and used to describe the caller to which the request belongs.
  • each response data corresponding to the request according to the processed serial parameter in the response data corresponding to the request, identify the caller to which the response data corresponding to the request belongs, including: for each For the response data corresponding to a request, match the processed serial parameter in the response data corresponding to the request with the value range of the serial parameter corresponding to each caller, and determine the matching caller as the response data corresponding to the request belongs to the caller.
  • the present application discloses an electronic device, including: one or more processors, memory, display screen, wireless communication module and mobile communication module.
  • the memory, the display screen, the wireless communication module and the mobile communication module are coupled with one or more processors, the memory is used to store computer program codes, the computer program codes include computer instructions, and when the one or more processors execute the computer instructions, the electronic device Execute the request processing method described in any one of the first aspect, or the request processing method described in any one of the second aspect.
  • the present application discloses a request processing device.
  • the request processing device includes: a processing unit, a storage unit, a display unit, and a transceiver unit.
  • the storage unit is used to store one or more programs; the processing unit Used to execute one or more programs.
  • One or more programs include instructions for executing the request processing method according to any one of the first aspect, or the request processing method according to any one of the second aspect.
  • Figure 1a is a schematic diagram of a software architecture of an electronic device
  • Figure 1b is a scenario diagram 1 of sharing a cellular communication capability
  • Figure 1c is a schematic diagram of the connection relationship of the HIDL interface inside the mobile phone a in the scene of Figure 1b;
  • Figure 1d is a second scenario of cellular communication capability sharing
  • Fig. 2a is the architecture diagram 1 of the request processing system disclosed in the present application.
  • Figure 2b is the second architecture diagram of the request processing system disclosed in this application.
  • Fig. 2c is a composition example diagram 1 of the electronic device disclosed in the present application.
  • Figure 3a is the third system architecture diagram of the request processing system disclosed in this application.
  • Fig. 3b is a schematic flowchart of a caller sending a request of a second device disclosed in the present application
  • Fig. 3c is a schematic flow diagram of a request issued by a caller of a first device disclosed in the present application
  • FIG. 3d is a schematic flow diagram of returning response data to the caller disclosed in the present application.
  • FIG. 4 is a first schematic flowchart of a request processing method disclosed based on the system of FIG. 3a;
  • FIG. 5a is a schematic diagram of a scenario for completing configuration of cellular communication capability sharing disclosed in the present application.
  • Fig. 5b is a schematic diagram of a scene of a response data returning device disclosed in the present application.
  • Fig. 5c is a schematic diagram of another response data returning device disclosed in the present application.
  • FIG. 6a is a second schematic flow diagram of a request processing method disclosed in this application.
  • FIG. 6b is a system architecture diagram inside the first device for executing FIG. 6a disclosed in the present application.
  • FIG. 7 is a schematic flow diagram III of a request processing method disclosed in this application.
  • FIG. 8 is a schematic flowchart 4 of a request processing method disclosed in the present application.
  • FIG. 9 is a schematic flow diagram five of a request processing method disclosed in the present application.
  • FIG. 10 is a schematic flow diagram VI of a request processing method disclosed in this application.
  • Fig. 11 is a composition example diagram 2 of the electronic device disclosed in the present application.
  • FIG. 12 is a schematic diagram of the composition of the request processing device disclosed in the present application.
  • words such as “exemplary” or “for example” are used as examples, illustrations or illustrations. Any embodiment or design scheme described as “exemplary” or “for example” in the embodiments of the present application shall not be interpreted as being more preferred or more advantageous than other embodiments or design schemes. Rather, the use of words such as “exemplary” or “such as” is intended to present related concepts in a concrete manner.
  • the caller on the application side initiates a request to call the client side of the HIDL interface corresponding to the caller, and the request initiated by the caller will be processed on the server side of the HIDL interface , that is, the Server side of the HIDL interface sends the request to the Modem, and the Modem processes the response data corresponding to the request, calls the Server side of the HIDL interface, and then the Server side of the HIDL interface returns the response data corresponding to the request to the Client side of the HIDL interface.
  • the client side of the HIDL interface is returned to the corresponding caller.
  • the application side refers to programs running on the application processor, such as programs in the application program layer and the application framework layer.
  • the caller is, for example, an application software (Application, App), a telephone manager (telephony) and the like.
  • the application layer of the application program is sent to the electric tube manager (Telephony) in the application program framework layer.
  • the request calls the Android Open Source Project (AOSP) development kit (Software Development Kit, SDK) application programming interface (Application Programming Interface, API) in the phone manager, and then the AOSP SDK API calls the phone Manager's service (Telephony Service) interface, and then Telephony Service calls the Client side of the HIDL interface, and then the Client side of the HIDL interface calls the Server side of the HIDL interface on the local system library, and then through the Server side of the HIDL interface, the The Request is sent to the supplier's radio interface layer (Vendor-RIL), and then sent by the Vendor-RIL to the local modem processor (Modem) for processing.
  • the Server side of the HIDL interface is on the RIL module on the HAL layer.
  • the local Modem obtains the response data (Response) corresponding to the request after processing, and then the Modem reports the Response to the Client side of the HIDL interface in the phone manager through the Server side of the Vendor-RIL and HIDL interfaces , and then sent to the short message application by the Telephony Service and the development kit in the phone manager.
  • the local Modem can also actively report the notification (Indication) to the phone manager by calling the server side of the HIDL interface, and then the phone manager continues to report the notification to the short message application.
  • the reporting process of the Indication may be the same as that of the Response, which will not be repeated here.
  • the request may also be other applications.
  • a server of a HIDL interface in an electronic device can only receive a Request sent by a client of a HIDL interface and return a corresponding Response thereto.
  • the server side of the HIDL interface can correspond to the request sent by the client of the HIDL interface one by one, so as to ensure that the response data corresponding to the request can be returned to the corresponding client of the HIDL interface
  • the Server side of each HIDL interface is fixedly registered with a Client side of the HIDL interface.
  • the present application provides an embodiment, by creating multiple Servers at the HAL layer of the electronic device, so that multiple devices can share the cellular capability, or different operating systems of the same device can use the cellular capability.
  • the HAL layer needs to establish a separate Server for each Client.
  • the different clients may be different operating systems located on the same device, or different devices.
  • mobile phone a is the first device, and mobile phones b and c are the second devices.
  • mobile phone b and mobile phone c want to share the cellular capabilities of mobile phone a
  • mobile phone a needs to establish Server terminals in the HAL layer for mobile phone b and mobile phone c respectively.
  • the first device in order to share the cellular capability, the first device will establish a server terminal for each second device or each operating system respectively.
  • the number of servers started on the first device is fixed in the code, and cannot be adjusted dynamically with the increase or decrease of shared devices.
  • the HAL layer needs to continuously adjust the code to support different numbers of clients. It is very inconvenient.
  • the first device mentioned in this application refers to an electronic device providing a Modem
  • the second device mentioned in this application refers to an electronic device using the Modem of the first device.
  • This application provides another embodiment, by carrying information describing the caller to which the request belongs in the request issued by the caller, to distinguish the caller to which each request belongs, and to realize the request issued by multiple callers , all call the Server side of the same HIDL interface through the interface proxy module for processing, and can return the response data corresponding to each request to the corresponding caller.
  • the proxy pattern is a design pattern used to provide additional access to the target object by creating a proxy object of the target object.
  • target object is a kind of interface, for example can be the Client end of HIDL interface, can be the Client end of the Radio HIDL interface in HIDL interface. Accessing the target object through the proxy object can provide additional functional operations through the proxy object without modifying the original target object, and expand the functions of the original target object.
  • the request mentioned in this embodiment of the present application may be a request sent to the Modem by the caller on the application side, for example, may be a request involved in a request for a cellular communication service.
  • cellular communication services such as calls, short messages, SIM card changes, call transfers, etc.
  • cellular communication services may be referred to as cellular communication services.
  • the embodiments provided in this application may be applicable to a scenario where multiple devices share cellular capabilities.
  • mobile phone b and mobile phone c can share the cellular capability of mobile phone a through the method provided by the embodiment of the present application.
  • the first device may be the mobile phone 11 in FIG. 1d.
  • the second device may be a tablet 12, smart glasses 13, a watch 14, a speaker 15, a smart screen 16, and a notebook computer 17 in FIG. 1d.
  • the embodiments provided in this application can enable the second device to share the cellular capability or modem of the first device at the same time.
  • the request processing method provided in the embodiment of the present application may also be applicable to a scenario where a single operating system in the first device uses one Modem. For example, in the same operating system, multiple independent communication services or applications can share a Modem.
  • the caller of the request can be distinguished by adding requester information in the request.
  • the requester information may be a serial (Serial) parameter, or may be a custom parameter or a newly added field.
  • the second device or the first device can distinguish the caller to which the request belongs through the serial parameter.
  • the interface proxy module may proxy clients of multiple HIDL interfaces.
  • the interface proxy module receives Requests issued by n callers of telephony1, telephony2, ... telephony n.
  • the relevant content of the interface proxy module receiving the Request can refer to the relevant descriptions of step S3013 in FIG. 3b, steps S3022 to S3023 in FIG. 3c, steps S407 to S408 in FIG. 4, and step S601 in FIG. 6a.
  • steps S3032 to S3034 in FIG. 3d and steps S413 to S418 in FIG. 4 For distinguishing the caller by the serial parameter, refer to the following descriptions of steps S3032 to S3034 in FIG. 3d and steps S413 to S418 in FIG. 4 .
  • the electronic device may also determine the calling party through a newly added field or a custom parameter.
  • the request sent by the caller such as Telephony
  • the request sent by the caller may carry a newly added field or parameter, and this field or parameter may be used to identify the identity of the caller.
  • the client end of the first device receives the request, it can identify the identity of the caller through the newly added field or parameter.
  • the process of receiving the Request by the client end of the HIDL interface reference may be made to the related description of step S601 in FIG. 6a.
  • the callers shown in FIG. 2a and FIG. 2b may be in the same operating system, or may be distributed in different operating systems.
  • the n calls may all be in the first device, or may be distributed among multiple different devices (that is, distributed among multiple second devices and the first device).
  • the caller can also be other types of callers such as IP Multimedia Subsystem (IP Multimedia Subsystem, IMS) applications.
  • IP Multimedia Subsystem IP Multimedia Subsystem, IMS
  • the embodiment of the present application does not limit the type of the interface, except for the HIDL interface, it may also be other types of first device interfaces.
  • the second device in the embodiment of the present application may be a mobile phone, a tablet computer, a desktop, a laptop, a notebook computer, an ultra-mobile personal computer (Ultra-mobile Personal Computer, UMPC), a handheld computer, a netbook , personal digital assistant (Personal Digital Assistant, PDA), wearable electronic devices, smart watches and other electronic devices
  • the first device is an electronic device with cellular communication capabilities such as a mobile phone and a smart watch watch. No special restrictions.
  • the second device in the embodiments of the present application refers to a device that uses the cellular communication capability of the first device
  • the first device refers to a device that has the cellular communication capability.
  • the structures of the second device and the first device can be shown in FIG. 2c, and the second device and the first device are collectively referred to as an electronic device 200 in FIG. 2c for introduction, and the electronic device 200 can include a processor 210, external memory interface 220, internal memory 221, universal serial bus (universal serial bus, USB) interface 230, charging management module 240, power management module 241, battery 242, antenna 1, antenna 2, mobile communication module 250, wireless Communication module 260, audio module 270, speaker 270A, receiver 270B, microphone 270C, earphone jack 270D, sensor module 280, button 290, motor 291, indicator 292, camera 293, display screen 294, and subscriber identification module (subscriber identification module , SIM) card interface 295 etc.
  • SIM subscriber identification module
  • the sensor module 280 may include a pressure sensor 280A, a gyro sensor 280B, an air pressure sensor 280C, a magnetic sensor 280D, an acceleration sensor 280E, a distance sensor 280F, a proximity light sensor 280G, a fingerprint sensor 280H, a temperature sensor 280J, a touch sensor 280K, and an ambient light sensor.
  • the structure shown in this embodiment does not constitute a specific limitation on the electronic device 200 .
  • the electronic device 200 may include more or fewer components than shown, or combine certain components, or separate certain components, or arrange different components.
  • the illustrated components can be realized in hardware, software or a combination of software and hardware.
  • the processor 210 may include one or more processing units, for example: the processor 210 may include an application processor (application processor, AP), a Modem, a graphics processing unit (graphics processing unit, GPU), an image signal processor (image signal processor) , ISP), controller, video codec, digital signal processor (digital signal processor, DSP), baseband processor, and/or neural network processor (neural-networkprocessing unit, NPU), etc. Wherein, different processing units may be independent devices, or may be integrated in one or more processors. For another example, in the embodiment of the present application, the processor 210 may execute the request processing method described in any one of the embodiments of the present application.
  • the controller may be the nerve center and command center of the electronic device 200 .
  • the controller can generate an operation control signal according to the instruction opcode and timing signal, and complete the control of fetching and executing the instruction.
  • a memory may also be provided in the processor 210 for storing instructions and data.
  • the charging management module 240 is configured to receive charging input from the charger.
  • the charger may be a wireless charger or a wired charger.
  • the charging management module 240 charges the battery 242 , it can also supply power to the electronic device through the power management module 241 .
  • the power management module 241 is used for connecting the battery 242 , the charging management module 240 and the processor 210 .
  • the power management module 241 receives the input from the battery 242 and/or the charging management module 240 to provide power for the processor 210 , the internal memory 221 , the display screen 294 , the camera 293 , and the wireless communication module 260 .
  • the wireless communication function of the electronic device 200 can be realized by the antenna 1, the antenna 2, the mobile communication module 250, the wireless communication module 260, the Modem 210A, and the baseband processor.
  • Antenna 1 and Antenna 2 are used to transmit and receive electromagnetic wave signals.
  • Each antenna in electronic device 200 may be used to cover a single or multiple communication frequency bands. Different antennas can also be multiplexed to improve the utilization of the antennas.
  • the mobile communication module 250 can provide wireless communication solutions including 2G/3G/4G/5G applied on the electronic device 200 .
  • Modem 210A may include a modulator and a demodulator. Wherein, the modulator is used for modulating the low-frequency baseband signal to be transmitted into a medium-high frequency signal. The demodulator is used to demodulate the received electromagnetic wave signal into a low frequency baseband signal.
  • Modem 210A may be a stand-alone device. In some other embodiments, the Modem 210A can be independent from the processor 210, and be set in the same device as the mobile communication module 250 or other functional modules. For example, in some embodiments of the present application, when the electronic device 200 is the second device shown in FIG. Modem 210A is provided to provide cellular communication capability to the second device.
  • the specific execution process and principle of Modem 210A can refer to any request processing method mentioned in the following embodiments of the application The related description of the Modem in the first device in the request processing system will not be repeated here.
  • the wireless communication module 260 can provide wireless local area networks (wireless local area networks, WLAN) (such as wireless fidelity (Wireless Fidelity, Wi-Fi) network), bluetooth (bluetooth, BT), global navigation satellite, etc. applied on the electronic device 200.
  • WLAN wireless local area networks
  • System global navigation satellite system, GNSS
  • frequency modulation frequency modulation, FM
  • near field communication technology near field communication, NFC
  • infrared technology infrared, IR
  • the electronic device 200 realizes the display function through the GPU, the display screen 294 , and the application processor.
  • the GPU is a microprocessor for image processing, and is connected to the display screen 294 and the application processor.
  • the display screen 294 is used to display images, videos and the like.
  • a series of graphical user interfaces can be displayed on the display screen 294 of the electronic device 200.
  • the electronic device 200 can realize the shooting function through the ISP, the camera 293 , the video codec, the GPU, the display screen 294 and the application processor.
  • Camera 293 is used to capture still images or video.
  • the external memory interface 220 can be used to connect an external memory card, such as a Micro SD card, to expand the storage capacity of the electronic device 200.
  • an external memory card such as a Micro SD card
  • the internal memory 221 may be used to store computer-executable program codes including instructions.
  • the processor 210 executes various functional applications and data processing of the electronic device 200 by executing instructions stored in the internal memory 221 .
  • the processor 210 executes various functional applications and data processing of the electronic device 200 by executing instructions stored in the internal memory 221 and/or instructions stored in a memory provided in the processor.
  • the electronic device 200 can realize the audio function through the audio module 270 , the speaker 270A, the receiver 270B, the microphone 270C, the earphone interface 270D, and the application processor. Such as music playback, recording, etc.
  • the electronic device 200 may also include a pressure sensor 280A, an air pressure sensor 280C, a gyro sensor 280B, a magnetic sensor 280D, an acceleration sensor 280E, a distance sensor 280F, a proximity light sensor 280G, an ambient light sensor 280L, a fingerprint sensor 280H, a temperature sensor 280J, Touch sensor 280K, bone conduction sensor 280M, key 290, motor 291, indicator 292, etc.
  • a pressure sensor 280A an air pressure sensor 280C, a gyro sensor 280B, a magnetic sensor 280D, an acceleration sensor 280E, a distance sensor 280F, a proximity light sensor 280G, an ambient light sensor 280L, a fingerprint sensor 280H
  • the SIM card interface 295 is used for connecting a SIM card.
  • the SIM card can be connected and separated from the electronic device 200 by inserting it into the SIM card interface 295 or pulling it out from the SIM card interface 295 .
  • the electronic device 200 may support 1 or N SIM card interfaces, where N is a positive integer greater than 1.
  • SIM card interface 295 can support Nano SIM card, Micro SIM card, SIM card etc. Multiple cards can be inserted into the same SIM card interface 295 at the same time.
  • the SIM card interface 295 is also compatible with external memory cards.
  • the electronic device 200 interacts with the network through the SIM card to implement functions such as calling and data communication.
  • an operating system runs on top of the above components.
  • Hongmeng operating system iOS operating system, Android operating system, Windows operating system, etc.
  • Applications can be installed and run on this operating system.
  • FIG. 3a is a request processing system 300 proposed by an embodiment of the present application.
  • the request processing system 300 is configured to process the requests issued by the second device and the first device.
  • the operating systems of the second device and the first device in the request processing system 300 may be in the same electronic device, and the second device and the first device executed by the request processing system 300 as follows
  • the processing process of the request sent by the device can also be applied to the processing process of the request sent by two operating systems in the same electronic device.
  • the layered architecture of the second device in the request processing system 300 disclosed in the embodiment of the present application divides the software into several layers, and each layer has a clear role and division of labor. Layers communicate through software interfaces.
  • the Android system is divided into four layers, which are respectively the application program layer, the application program framework layer, the Android runtime (Android runtime) and the system library, and the kernel layer from top to bottom.
  • the application layer can consist of a series of application packages.
  • the application package may include applications such as camera, gallery, calendar, call, map, navigation, WLAN, Bluetooth, music, video, and short message.
  • the application framework layer provides an application programming interface (application programming interface, API) and a programming framework for applications in the application layer.
  • the application framework layer includes some predefined functions. As shown in Figure 3a, the application framework layer may include window manager, content provider, view system, distributed cellular communication module 3011, phone manager 3012, distributed bus 3013, resource manager, notification manager, etc.
  • a window manager is used to manage window programs.
  • the window manager can get the size of the display screen, determine whether there is a status bar, lock the screen, capture the screen, etc.
  • Content providers are used to store and retrieve data and make it accessible to applications.
  • Said data may include video, images, audio, calls made and received, browsing history and bookmarks, phonebook, etc.
  • the view system includes visual controls, such as controls for displaying text, controls for displaying pictures, and so on.
  • the view system can be used to build applications.
  • a display interface can consist of one or more views.
  • a display interface including a text message notification icon may include a view for displaying text and a view for displaying pictures.
  • the phone manager 3012 is used to provide the cellular communication function of the second device. For example, the management of call status (including connected, hung up, etc.). For specific functions of the phone manager 3012 in this embodiment of the application, refer to the following description of the phone manager 3012 in the request processing system 300 .
  • the distributed cellular communication module 3011 is used to forward the cellular communication service request of the phone manager 3012 to the distributed cellular communication module 3022 of the first device.
  • the distributed cellular communication module 3011 of the second device includes: an interface proxy module 3011A. Based on the technology of the proxy mode mentioned above, the interface proxy module 3011A creates a proxy object for the client side of the HIDL interface in the second device, and the proxy object for the client side of the HIDL interface in the second device can be used to receive the second device and forward the request to the first device.
  • the proxy object facing the client side of the HIDL interface in the second device can be understood as a proxy object of the request interface, that is, all requests issued by the caller of the second device are received by the proxy object of the request interface.
  • the request issued by the caller of the second device received by the distributed cellular communication module 3011 of the second device also includes the identifier of the caller who issued the request, and the distribution of the second device
  • the cellular communication module 3011 performs offset processing on the sequence (serial) parameter in the request according to the identifier of the caller, and the offset-processed serial parameter in the request can indicate the corresponding caller of the request.
  • the distributed bus 3013 is used to establish a connection channel between the distributed cellular communication module 3011 of the second device and the distributed cellular communication module 3022 of the first device, and connect the distributed cellular communication module 3011 of the second device with the distributed cellular communication module 3011 of the first device. cellular communication module 3022 .
  • the distributed bus 3013 may be responsible for device discovery, self-connection, authentication management, etc. under the same account in a short distance, a local area network, or a far field. It can also be responsible for scheduling management of different channels, service quality experience evaluation, etc., transparent to the application layer. It can also be responsible for the maintenance of the channel and provide a low-power standby mechanism. It can also be responsible for the forwarding/response of control plane signaling (such as the request processing method mentioned in the following embodiments of the application and the request involved in the request processing system, and the response data corresponding to the request), and encryption encapsulation.
  • the resource manager provides various resources for the application, such as localized strings, icons, pictures, layout files, video files, and so on.
  • the core library consists of two parts: one part is the function function that the java language needs to call, and the other part is the core library of Android.
  • the application layer and the application framework layer run in virtual machines.
  • the virtual machine executes the java files of the application program layer and the application program framework layer as binary files.
  • the virtual machine is used to perform functions such as object life cycle management, stack management, thread management, security and exception management, and garbage collection.
  • a system library can include multiple function modules. For example: surface manager (surface manager), media library (Media Libraries), 3D graphics processing library (eg: OpenGL ES), 2D graphics engine (eg: SGL), hardware abstraction layer (Hardware Abstraction Layer, HAL), and in The radio interface layer (Radio Interface Layer, RIL) module on the HAL, etc.
  • the server side of the HIDL interface is also provided on the RIL module.
  • the surface manager is used to manage the display subsystem and provides the fusion of 2D and 3D layers for multiple applications.
  • the media library supports playback and recording of various commonly used audio and video formats, as well as still image files, etc.
  • the media library can support a variety of audio and video encoding formats, such as: MPEG4, H.264, H.265, H.266, VP9, MP3, AAC, AMR, JPG, PNG, etc.
  • the 3D graphics processing library is used to implement 3D graphics drawing, image rendering, compositing, and layer processing, etc.
  • 2D graphics engine is a drawing engine for 2D drawing.
  • the kernel layer is the layer between hardware and software.
  • the kernel layer includes at least a display driver, a camera driver, an audio driver, and a sensor driver.
  • the software layered architecture of the first device may refer to the software layered architecture of the second device, which will not be repeated here.
  • the first device also includes a modem processor 3021 , and the Modem 3021 is configured to process the received request, obtain response data corresponding to the request, and then send the response data corresponding to the request to the distributed cellular communication module 3022 .
  • the first device may also set up the distributed cellular communication module 3022 at the application framework layer of the first device.
  • the distributed communication module 3022 may also set an interface proxy module 3022A.
  • the interface proxy module 3022A may create a proxy object facing the client side of the HIDL interface in the first device. The proxy object facing the client end of the HIDL interface in the first device is used to receive response data corresponding to all requests sent by the server end of the HIDL interface of the first device.
  • the distributed cellular communication module 3022 can also receive the request of the second device and the request sent by the caller of the first device. It can be understood that the request of the second device received by the distributed cellular communication module 3022 may be a request processed by the interface proxy module of the second device, or an unprocessed request.
  • the distributed cellular communication module 3022 can identify the caller through the requester information. For a specific manner, reference may be made to the manners shown in FIG. 2a and FIG. 2b.
  • the principle and execution process of the distributed bus 3024 of the first device are the same as those of the distributed bus 3013 of the second device, which can be referred to here, and will not be repeated here.
  • the request for the cellular communication service of the second device is The processing procedure in the system of FIG. 3a may be: the second device executes step S3011 to trigger a request for a cellular communication service. Then step S3012 is executed, the second device sends the request for the cellular communication service to the local phone manager. In step S3013, the phone manager of the second device, as the caller, invokes the interface proxy module of the second device, and sends the cellular communication service request to the distributed cellular communication module of the second device.
  • the interface proxy module of the second device pre-creates the proxy object of the request interface, that is, the interface that the client end of the HIDL interface calls to the server end of the HIDL interface on behalf of the client end, which can also be considered as the request interface of the client end.
  • the client side of the HIDL interface sends the request and the response data corresponding to the received request is processed asynchronously, that is, it is not processed by the same interface.
  • the distributed cellular communication module of the second device performs offset processing on the serial parameter in the cellular communication service request, wherein the offset processed serial parameter in the request can indicate the corresponding caller of the request.
  • step S3011 to step S3014 can also refer to the part of step S401 to step S406 in FIG. 4 and the relevant content of step S601 in FIG. 6a.
  • step S3015 the distributed cellular communication module of the second device forwards the request for the cellular communication service to the distributed cellular communication module of the first device.
  • the execution process and principle of step S3015 can refer to the relevant content of step S407 in FIG. 4 .
  • the first device executes step S3016, the distributed cellular communication module of the first device sends the request for the cellular communication service to the Modem of the first device through the Server end of the HIDL interface, and the Modem of the first device performs the request for the cellular communication service Processing to obtain the response data corresponding to the request of the cellular communication service.
  • the processed request of the cellular communication service can distinguish the calling party to which the request belongs.
  • the transmission path of the request for the cellular communication service of the second device in the system in FIG. 3a may be shown by the solid arrow in FIG. 3a.
  • the requests issued by the first device and the second device may also be requests other than the request for the cellular communication service, and there is no limitation on the format and content of the request in this embodiment of the application.
  • the caller of the first device or the second device may be other callers except the phone manager, such as an IP Multimedia Subsystem (IP Multimedia Subsystem, IMS) application, and may also be the caller, Call the interface proxy module 3011A, and the transmission process of the request issued by the IP multimedia subsystem in the request processing system 300 can refer to the transmission process of the request issued by the phone manager 3012 in the request processing system 300, which is not described here Let me repeat.
  • IP Multimedia Subsystem IP Multimedia Subsystem
  • IMS IP Multimedia Subsystem
  • the processing process of the first device's cellular communication service request in the system of FIG. 3a may be: the first device executes step S3021 to trigger the cellular communication service request. Then step S3022 is executed, the first device sends the request of the cellular communication service to the local phone manager, and in step S3023, the phone manager of the first device, as the caller, invokes the interface proxy module of the first device to transfer the cellular communication service A request for communication service is sent to the distributed cellular communication module of the first device.
  • the interface proxy module of the first device pre-creates the proxy object of the request interface, that is, the interface that the Client end of the HIDL interface of the first device calls to the Server end of the HIDL interface on behalf of the first device, which can also be considered as the interface of the Client end of the first device. request interface.
  • the distributed cellular communication module of the first device performs offset processing on the serial parameter in the cellular communication service request, wherein the offset-processed serial parameter in the request can indicate the caller corresponding to the request.
  • step S3024 can refer to step S409 in FIG.
  • the first device executes step S3025, the distributed cellular communication module of the first device sends the request for the cellular communication service to the Modem of the first device through the Server end of the HIDL interface, and the Modem of the first device performs the request for the cellular communication service Processing to obtain the response data corresponding to the request of the cellular communication service.
  • steps S410 to S411 in FIG. 4 for the execution process and principle of step S3025, reference may be made to steps S410 to S411 in FIG. 4, and related content from steps S602 to S603 in FIG. 6a.
  • the transmission process of the cellular communication service request issued by the first device in the request processing system 300 is shown by the arrow of the solid line shown in FIG.
  • the request for the cellular communication service issued by the first device does not need to be sent to the distributed cellular communication module 3022 through the distributed bus.
  • the request may be as follows: In step S3031, the Modem of the first device calls back the response data corresponding to each request to the interface proxy module of the first device through the Server side of the HIDL interface.
  • the interface proxy module of the first device pre-creates the proxy object of the response interface, that is, the interface that the Server end of the HIDL interface acts as a callback to the Client end of the HIDL interface, which can also be considered as the response interface of the Client end.
  • the distributed cellular communication module of the first device identifies the caller to which the response data corresponding to the request belongs according to the offset-processed serial parameter in the response data corresponding to the request.
  • the execution process and principle of step S3032 can specifically refer to step S605 in FIG.
  • step S3033 if it is recognized that the caller to which the response data corresponding to the request belongs belongs to the second device, then step S3033 is performed; if it is recognized that the caller to which the response data corresponding to the request belongs is on the first device, then step S3034 is performed.
  • step S3033 the distributed cellular communication module of the first device restores the offset-processed serial parameter in the response data corresponding to the request, and then sends the response data corresponding to the request to the distributed cellular communication module of the second device.
  • the cellular communication module, the distributed cellular communication module of the second device returns the response data corresponding to the request to the phone manager of the second device.
  • step S3034 the distributed cellular communication module of the first device restores the offset-processed serial parameter in the response data corresponding to the request, and then returns the response data corresponding to the request to the phone management of the first device device.
  • step S3033 to step S3034 please refer to step S414 to step S418 in FIG. 4 and related content of step S606 in FIG. 6a.
  • the transmission path of the response data corresponding to the request of the second device and the first device can be shown as the dotted arrow in Fig. 3a: in step S3031, the Modem3021 of the first device passes each The response data corresponding to the request is called back to the interface proxy module 3022A of the first device. In step S3032, for the response data corresponding to each request, the distributed cellular communication module 3022 of the first device identifies the caller to which the response data corresponding to the request belongs according to the offset-processed serial parameter in the response data corresponding to the request .
  • step S3033 the distributed cellular communication module 3022 of the first device restores the offset-processed serial parameter in the response data corresponding to the request, and then sends the response data corresponding to the request to the distribution network of the second device.
  • the distributed cellular communication module 3011 of the second device returns the response data corresponding to the request to the phone manager 3012 of the second device, and the phone manager 3012 returns the response data corresponding to the request to the short message application .
  • step S3034 the distributed cellular communication module 3022 of the first device restores the offset-processed serial parameter in the response data corresponding to the request, and then returns the response data corresponding to the request to the phone of the first device.
  • the manager 3023, the phone manager 3023 of the first device returns the response data corresponding to the request to the short message application.
  • the communication connection can be established in a wired form, and the communication connection can also be established in a wireless form.
  • the difference in the way of establishing the communication connection between the second device and the first device does not affect the implementation of the embodiment of the present application.
  • the transmission process of the notification of the second device may be consistent with the transmission process of the response data of the second device, and the transmission process of the notification of the first device may also be consistent with the transmission process of the response data of the first device. I won't repeat them here.
  • the first device and the second device can process the request sent by the caller by setting up an interface proxy, for example, offsetting the serial value, so as to distinguish different callers.
  • an interface proxy for example, offsetting the serial value
  • the internal processing process of the request and response data in the phone manager in FIG. 3a can refer to the relevant part of the phone manager in FIG. 1a , and will not be repeated here.
  • the processing method of the request may specifically include the following steps:
  • the second device sends a socket (socket) connection request to the first device.
  • the socket connection request carries information used to describe each caller of the second device.
  • a connection relationship needs to be established between the second device and the first device, so the second device sends a socket connection request to the first device.
  • the caller of the second device is used to issue a request.
  • the request sent by the caller may be a request that needs to be processed by the Modem.
  • the second device sends the information of the caller that needs the modem of the first device to process the request in the socket connection request to the first device.
  • the calling party may be the phone manager 3012 in FIG. 3a, or may be an IMS or the like.
  • the second device needs to let the Modem of the first device process the requests issued by the two phone managers in the second device, so when sending a socket connection request to the first device Carries information for both phone managers.
  • the information used to describe each caller of the second device may be information specific to the caller, such as the address and name of each caller in the second device.
  • the distributed cellular communication module of the second device may use the socket of the second device to send a socket connection request to the distributed cellular communication module of the first device.
  • the socket connection request describes the socket of the first device to be connected, and indicates the address and port number of the socket of the first device, and the socket connection request also describes the socket of the second device itself.
  • the distributed cellular communication module of the second device may be as shown in Fig. 3a.
  • the protocol used can be specified, such as Transmission Control Protocol (Transmission Control Protocol, TCP), User Datagram Protocol (User Datagram Protocol, UDP) and the like.
  • TCP Transmission Control Protocol
  • UDP User Datagram Protocol
  • the first device before performing step S401, it may further include: the first device enables the sharing function of the cellular communication capability, the second device queries the devices in the network that enable the sharing function of the cellular communication capability, and then obtains all the enabled cellular communication capability sharing functions from the query. Among the devices with the communication capability sharing function, the first device is selected, and then the second device executes step S401.
  • the first device may enable the cellular communication capability sharing function in response to the user's operation.
  • the first device may enable the cellular communication capability sharing function through the distributed cellular communication module of the first device.
  • the distributed cellular communication module of the first device may be set at the application framework layer of the first device, as shown in the distributed cellular communication module 3022 shown in FIG. 3a.
  • the enabling of the cellular communication capability sharing function by the first device may be performed by one or more modules in the first device in cooperation.
  • the first device When the first device enables the cellular communication capability sharing function, the first device is in a state that can be discovered by other devices. When other devices discover the first device, they can know that the current cellular communication capability sharing function of the first device is enabled and can be discovered by other devices. The devices are shared and used, so that the second device can discover the first device and send a socket connection request to the first device.
  • the first device discoverable by other devices. For example, if the first device turns on Bluetooth, it can be discovered by other devices with Bluetooth enabled; A network (such as a wireless network) can be discovered by other devices in the near field network, a login account can be discovered by other devices under the account, and so on.
  • a network such as a wireless network
  • the first device establishes a connection with the second device in response to the socket connection request, and returns an identifier corresponding to each caller to the second device.
  • the socket connection request In response to the socket connection request, assign an identification corresponding to the caller to each caller specified in the socket connection request.
  • the identifier corresponding to the caller is unique and unique to the caller.
  • the identification may be an identification number.
  • the socket connection request carries information of two phone managers.
  • the first device assigns identification number 1 to one of the telephony managers and identification number 2 to the other telephony manager. It should be noted that the format and content of the identification are not limited in this embodiment of the application.
  • the rule for assigning the identifier to the caller by the first device may be set arbitrarily, and is not limited in this embodiment of the present application.
  • the first device has also pre-assigned an identifier corresponding to each caller in the first device.
  • the identifier assigned by the first device to each caller is unique. For example, there is one phone manager in the first device, and there are two phone managers in the second device.
  • the first device assigns the identification number of the phone manager of the first device to One phone manager has an identification number of 2 and the other phone manager has an identification number of 3.
  • the distributed cellular communication module of the first device after the distributed cellular communication module of the first device receives the socket connection request sent by the second device, it responds to the socket connection request, and then performs some authentication operations on the connection request.
  • the distributed cellular communication modules of the two devices establish a connection.
  • the distributed cellular communication module of the first device and the distributed cellular communication module of the second device may establish a connection through a distributed bus, and after the connection is established, the distributed bus may maintain the connection channel without disconnection.
  • the distributed bus can also be in a low-power standby mechanism, which is only in a working state when the distributed bus is required for sending work, and is in a low-power standby state at other times.
  • the distributed cellular communication module of the second device and the distributed cellular communication module of the first device may establish a connection through a distributed bus 3013 and a distributed bus 3024 as shown in FIG. 3 a .
  • the communication between the second device and the first device can be realized, and the first device can return the identification corresponding to each caller assigned to the second device to the second device through the distributed bus. in the device.
  • steps S401 to S402 are only an implementation manner of establishing a connection between the second device and the first device, and differences in specific ways of establishing a connection between the second device and the first device do not affect this The implementation of the application embodiment.
  • the second device may also send When the cellular communication capability sharing request is made, the information used to describe each caller of the second device is carried in the cellular communication capability sharing request and sent to the first device, and the first device responds to the cellular communication capability sharing request, and then the second device Each caller of the device is assigned an identifier corresponding to the caller, and then returns the identifier corresponding to each caller to the second device. It may also be that the second device sends information describing each caller of the second device to the first device after the connection between the second device and the first device is established, and the first device is responsible for each caller of the second device. The caller assigns an ID, and the first device returns the ID corresponding to each caller to the second device.
  • the first device to return the identifier corresponding to each caller of the second device to the second device.
  • the method for the first device to return the identifier corresponding to each caller of the second device to the second device No restrictions.
  • the second device creates a proxy object of the client end of the HIDL interface of the second device.
  • the proxy object at the client end of the HIDL interface of the second device is used to receive a request from the caller of the second device, and forward the request to the first device.
  • the process of executing step S403 may be: based on the above-mentioned technology of the proxy mode, creating a proxy object oriented to the client end of the HIDL interface.
  • the client end of the HIDL interface may be the client end of the RIL interface.
  • the created proxy object of the client side of the HIDL interface has all the functions of the client side of the original HIDL interface, and has expanded other functions.
  • the additional function operation is extended In this way, the proxy object at the client side of the HIDL interface of the second device can forward the request of the caller locally on the second device to the first device.
  • the proxy object of the client end of the HIDL interface of the second device forwards the request of the local caller of the second device to the distributed cellular communication module of the first device.
  • proxy mode refers to the relevant part of the proxy mode mentioned above, and will not be repeated here.
  • functions of the client side of the native HIDL interface please refer to the relevant part of the above-mentioned solution for sending requests from the application side to the Modem for processing, and will not repeat them here.
  • the second device uses the interface proxy module to create a proxy object facing the client side of the HIDL interface of the second device, where the interface proxy module may be the interface proxy module 3022A in FIG. 3a.
  • the second device After the second device creates a proxy object facing the client end of the HIDL interface of the second device, it can proxy the client end of the HIDL interface of the second device. Furthermore, when the caller of the second device sends a request, the sent request will be received by the proxy object of the Client side of the HIDL interface of the second device, and then forwarded to the first device, and then processed by the Modem of the first device , let the second device have a basic configuration capable of using the cellular communication capability of the first device.
  • creating the proxy object of the client side of the HIDL interface of the second device may be understood as creating a proxy object of the request interface of the second device.
  • the request interface of the second device is an interface called by the client end of the HIDL interface of the second device to the server end of the HIDL interface.
  • step S403 When there are multiple callers in the second device, when step S403 is executed, a client proxy object corresponding to the HIDL interface of each caller may be created, that is, a client end of the HIDL interface corresponding to all callers may be proxied.
  • the caller of the second device can change the instance of the client end of the HIDL interface called by the caller of the second device to be the proxy object of the client end of the HIDL interface of the second device created in step S403, so that subsequent requests after performing step S403 During the process, the caller may not call the client end of the original HIDL interface, but call the proxy object of the client end of the HIDL interface of the second device created in step S403.
  • step S403 the type and specific method of the interface proxied by the second device are not limited.
  • the first device can also create proxy objects of the client end of other types of interfaces.
  • the first device creates a proxy object of the client end of the HIDL interface of the first device.
  • the proxy object of the Client end of the HIDL interface of the first device is used to receive the request of the caller of the first device, and send the request of the caller of the first device to the Server end of the HIDL interface of the first device, and is also used for Receive the response data corresponding to the request called back by the server side of the HIDL interface of the first device.
  • the response data corresponding to the request of the server-side callback of the HIDL interface of the first device includes both the caller belonging to the first device and the caller belonging to the second device, that is, the response data corresponding to the request of all callers , are called back to the proxy object of the Client side of the HIDL interface of the first device through the Server side of the HIDL interface of the first device.
  • step S404 when there are multiple callers in the first device, when step S404 is executed, it may be to create a proxy object on the Client side of the HIDL interface corresponding to each caller in the first device, that is, it can proxy all callers in the first device to correspond to The client side of the HIDL interface.
  • step S404 the type and specific method of the interface proxied by the first device are not limited.
  • the first device can also create client-side proxy objects of other types of interfaces.
  • the process of executing step S404 may be, based on the design pattern of proxy mode, creating a proxy object oriented to the client end of the HIDL interface of the first device.
  • the client end of the HIDL interface may be the client end of the RIL interface.
  • the created proxy object of the client end of the HIDL interface of the first device has the function of the client end of the original HIDL interface of the first device, and can expand other functions.
  • proxy mode refers to the relevant part of the proxy mode mentioned above, and will not be repeated here.
  • functions of the client side of the native HIDL interface please refer to the relevant part of the above-mentioned solution for sending requests from the application side to the Modem for processing, and will not repeat them here.
  • creating the proxy object of the client side of the HIDL interface of the first device can be understood as creating a proxy object of the request interface and a proxy object of the response interface of the first device.
  • the client side of the HIDL interface is asynchronous call processing, that is, the interface that the client side receives the request and the interface that receives the response data are not the same interface, so when step S404 is executed, proxy objects for the request interface of the first device can be created respectively And the proxy object of the response interface.
  • the request interface of the first device is an interface called by the client end of the HIDL interface of the first device to the server end of the HIDL interface.
  • the request interface of the first device is the response interface of the first device, and the server end of the HIDL interface of the first device calls back to the client end of the HIDL interface.
  • the client instance of the HIDL interface invoked by the caller of the first device can be changed to be the proxy object of the client end of the HIDL interface of the first device created in step S404, so that subsequent requests after performing step S404 During the process, the caller may not call the original HIDL interface client, but call the proxy object of the first device's HIDL interface client created in step S404.
  • step S404 may be performed through an interface proxy module.
  • the interface proxy module may be shown as the interface proxy module 3022A shown in FIG. 3a.
  • both step S403 and step S404 can be performed by the interface proxy module, that is, the interface proxy module can create the client end of the HIDL interface corresponding to all callers in the first device and the second device, and proxy the first The client side of all HIDL interfaces in the device and the second device. And then the interface agent module can realize receiving all caller's requests by executing step S403 and step S404, and only send to Modem through the Server end of a HIDL interface of the first equipment, also realize receiving the request of the HIDL interface of this first equipment Response data corresponding to all caller requests sent by the server.
  • the interface proxy module may be partially set in the application framework layer of the first device, and partially set in the application framework layer of the second device.
  • the interface proxy module may include an interface proxy module 3011A and an interface proxy module 3022A as shown in FIG. 3a.
  • the timing of creating the proxy object of the first device may be in multiple manners.
  • step S404 may be created automatically after step S402 is executed, or the proxy object may be preset before leaving the factory. This embodiment of the present application does not limit it.
  • step S403 and step S404 the proxy objects of the client end of the HIDL interface of all the first device and the second device can be created, so that all requests can be processed through the server end of the HIDL interface of only one first device, And the response data corresponding to the request, that is, the client end that supports multiple callers corresponding to the HIDL interface, and the server end that calls the same HIDL interface.
  • steps S401 to S404 are equivalent to satisfying the requirement of processing all requests issued by the caller on the server side using a HIDL interface in the scenario of cellular communication sharing, the first device and the second device need Cooperate with the configuration work performed.
  • the second device has all the cellular communication capabilities of the first device. Subsequently, in the process of processing each request, the aforementioned steps S401 to S404 do not need to be repeatedly executed.
  • the interface displays a WIFI icon 50
  • the interface displays a WIFI icon 51 .
  • the mobile phone and the laptop establish a connection by accessing the same WIFI, and after the mobile phone and the laptop cooperate to complete steps S401 to S404, the 5G signal status of SIM card 1 and the 5G signal status of SIM card 2 on the mobile phone are shared with Notebook computer, the signal status displayed on the 5G signal status icon 52 of the SIM card 1 and the 5G signal status icon 53 of the SIM card 2 on the mobile phone is the same as that displayed on the 5G signal status icon 54 and the 5G signal status icon 55 of the notebook computer
  • the signal status of the mobile phone is consistent, and the laptop can obtain the signal status of the mobile phone synchronously.
  • steps S401 to S404 are only a configuration method for processing requests from multiple callers through the server side of a single HIDL interface of the first device, and there are other configuration methods that can be implemented. The difference does not affect the implementation of the embodiment of the present application.
  • the caller of the second device invokes the proxy object of the client end of the HIDL interface of the second device, and delivers the request of the caller to the proxy object of the client end of the HIDL interface of the second device.
  • the caller's request carries the caller's identifier, which is used to describe the caller to which the request belongs.
  • the identifier of the caller is allocated by the first device to the caller of the second device. For details, please refer to the relevant content mentioned in the aforementioned step S402, which will not be repeated here.
  • the caller of the second device invokes the proxy object of the client end of the HIDL interface corresponding to the caller, and transmits the request of the caller to the proxy object of the client end of the HIDL interface corresponding to the caller. Since in step S403, the proxy object of the client end of the HIDL interface of the second device has been created in advance, when any caller of the second device sends a request, the request can be sent to the client end of the HIDL interface of the second device.
  • the proxy objects that is, the proxy object at the client end of the HIDL interface of the second device receives requests from all callers of the second device.
  • the identifier of the caller may be carried in the caller's request, or may be a proxy object passed separately to the Client side of the HIDL interface.
  • the trigger method, generation method, specific request type, quantity, content, etc. of the caller's request can refer to the regulations of operating systems such as Android or IOS, which are not limited in this embodiment of the present application.
  • step S403 if step S403 is performed through the interface proxy module, an implementation manner of performing step S405 is: the caller of the second device calls the interface proxy module, and sends the caller's request to the interface proxy module.
  • the calling party may be the phone manager 3012 shown in FIG. 3a. As shown in FIG. 3011A issues a short message sending request.
  • the second device offsets the serial parameter in the caller's request by an offset value corresponding to the caller according to the identifier of the caller, so that the processed serial parameter in the request can be used to describe the caller to which the request belongs.
  • the request received by the proxy object of the Client side of the HIDL interface of the second device has a serial parameter, and the serial parameter represents the number of times the caller sends a request.
  • the serial parameter is consistent with the serial parameter in the response data corresponding to the request, so the caller can determine which request the received response data corresponds to through the serial parameter.
  • the serial parameter in the caller's request is increased by one compared with the serial parameter in the previous request, that is, the serial parameter in the caller's request It can indicate the number of times the caller sends the request.
  • the serial parameter in the request sent by the phone manager 3012 for the first time is 1, and the serial parameter in the second request sent by the phone manager 3012 becomes 1. 2...
  • the serial parameter in the request sent by the phone manager 3012 can reflect the number of requests sent by the phone manager 3012.
  • the processed serial parameter in the request mentioned in step S406 refers to the serial parameter after offset processing.
  • all the requests of the caller in step S405 can identify the caller to which the request belongs through the processed serial parameter. For example, if there are two phone managers in the second device, after the requests of the two phone managers are processed in step S406, it is possible to identify which caller the request belongs to by reading the processed serial parameter phone manager.
  • step S406 After the request of the caller of the first device processed in step S406 is processed by the Modem of the first device in the following steps, the response data corresponding to the request of the caller will still carry information related to The same serial parameter in step S406, so after the processing of step S406, the corresponding caller request can also be identified in the response data obtained subsequently.
  • a list between the identifiers of all callers and the offset values corresponding to the callers can be set in advance, so that the offset values corresponding to different callers are different from each other, and the serial parameter in the requests of different callers The range of values does not overlap with each other.
  • a list of all caller identifiers and offset values corresponding to the caller may be pre-stored in the second device and the first device. Wherein, all callers include both the caller of the second device and the caller of the first device.
  • the proxy object of the Client side of the HIDL interface of the second device uses the identifier of the caller to which the request belongs to find the offset value corresponding to the caller in the list, and then sends the caller's request The offset of the serial parameter in and the corresponding offset value of the caller.
  • the value ranges of the serial parameters in the requests of different callers are different, and the value range of each serial parameter corresponds to a caller, so the processed serial parameters in the request can be used Used to describe the caller to whom the request belongs.
  • the value range of the processed serial parameter may be used to indicate the caller to which the request belongs.
  • the relationship between the caller's identifier and the corresponding offset value of the caller can be set as follows: when the caller's identifier (Client Id) is 1, set the corresponding serial parameter The value range is: 0 to offset value-1.
  • the Client Id When the Client Id is 2, set the value range of the corresponding serial parameter from offset value to 2*offset value-1.
  • the Client Id is N, set The value range of the corresponding serial parameter is: (N-1)*offset value to N*offset value–1. That is, when the identifier of the caller is N, the serial parameter in the corresponding request needs to be offset by (N-1)*offset value.
  • offset value is a preset value, for example, offset value can be preset to 10000000.
  • the second device has two phone managers, and the caller IDs assigned by the first device are 2 and 1 respectively.
  • the offset value is 10000000
  • the value range of the serial parameter corresponding to the phone manager whose Client Id is 1 is 0 to 9999999, that is, the offset required for the serial parameter of the request issued by the phone manager whose Client Id is 1
  • the offset value is 0, and the value range corresponding to the phone manager with Client Id 2 is 10000000 to 19999999, that is, the offset value required for the serial parameter of the request issued by the phone manager with Client Id 2 is 10000000
  • the value range corresponding to the phone manager whose Client Id is 3 is 20000000 to 19999999, that is, the offset value required for the serial parameter of the request issued by the phone manager whose Client Id is 3 is 20000000. It can be seen from this that the offset values corresponding to the identifiers of different callers are different, which leads to requests issued by different call
  • the correspondence between the identifier of the caller and the offset value corresponding to the caller can be set freely, only after the serial parameter in the request of the caller is offset from the offset value corresponding to the caller, The caller to which the request belongs can be explained through the processed serial parameter in the request.
  • the difference in the setting rules of the offset value corresponding to the caller does not affect the implementation of the embodiment of the present application.
  • step S406 may be performed by an interface agent module.
  • the proxy object of the client side of the HIDL interface of the second device created by the interface proxy module can be extended with additional functions, so that the HIDL of the second device
  • step S406 may be performed.
  • the interface proxy module executing step S406 may be the interface proxy module 3011A as shown in FIG. 3a.
  • the second device forwards the request of the caller of the second device to the first device.
  • Step S407 is executed through the proxy object of the client end of the HIDL interface of the second device.
  • the caller's request forwarded in step S407 is a request processed in step S406, that is, the serial parameter in the request forwarded in step S407 can be used to describe the caller to which the request belongs.
  • the distributed cellular communication module of the second device may forward the request of the caller of the second device to the distributed cellular communication module of the first device.
  • the interface proxy module in the distributed cellular communication module of the second device may forward the caller's request to the interface proxy module of the first device.
  • the caller of the first device invokes the proxy object of the client end of the HIDL interface of the first device, and sends the request of the caller to the proxy object of the client end of the HIDL interface of the first device.
  • step S408 can be performed through the proxy object of the client end of the HIDL interface of the first device.
  • step S408 executed by the first device and step S405 executed by the second device there is no restriction on the order of execution between step S408 executed by the first device and step S405 executed by the second device, and the execution of step S408 and step S405 does not interfere with each other.
  • the first device executes the process of step S408, for details, please refer to the relevant content of the process of processing the request by the phone manager in FIG. 1a.
  • the first device offsets the serial parameter in the caller's request by an offset value corresponding to the caller according to the identifier of the caller, so that the processed serial parameter in the request can be used to describe the caller to which the request belongs.
  • the request processed by the first device in step S409 is only a request from the caller of the first device.
  • the specific execution principle and process please refer to the related content of step S406 performed by the second device.
  • the request processed by the first device in step S409 may be the request of the caller of the first device and the second device, that is, the offset processing of all requested serial parameters may be completed through step S409.
  • the second device may not perform step S406, and the second device forwards the request to step S409 through step S407, and then the first device processes it.
  • the request received by the first device from the second device needs to carry the identifier of the calling party, and then step S409 can be executed.
  • the first device sends each caller's request to the Modem of the first device through the Server end of the HIDL interface of the first device.
  • the request of each caller in step S410 includes not only the request forwarded by the second device to the first device in step S407, but also the request issued by the caller of the first device in step S408, that is, all The caller's request is sent to the Modem of the first device through the Server end of the same HIDL interface of the first device.
  • serial parameters in the request sent to the Modem of the first device in step S410 are all offset-processed, and can indicate the caller to which the request belongs.
  • the request of each caller may be sent to the Modem of the first device by calling the server end of the HIDL interface of the first device through the interface proxy module.
  • the request of the caller of the first device may be sent to the server side of the HIDL interface of the first device through the proxy object of the client side of the HIDL interface of the first device.
  • the request of the caller of the second device can be transparently transmitted to the Server end of the HIDL interface of the first device directly through the distributed cellular communication module of the second device.
  • the interface proxy module of the second device refer to the interface proxy module 3022A in FIG. 3a.
  • the distributed cellular communication module of the second device refer to the distributed cellular communication module 3022 of the second device in FIG. 3a.
  • the Modem of the first device processes and obtains response data corresponding to each request.
  • the response data corresponding to the request can be understood as the response result corresponding to the request, and there is a one-to-one correspondence between the response data corresponding to the request and the request.
  • the response data corresponding to the request may be result data for indicating whether the short message is sent successfully.
  • the response data corresponding to the request processed by the Modem still carries the serial parameter. It can be seen from the foregoing that after the processing of the foregoing steps, the serial parameter can be used to indicate the caller to which the request belongs. Therefore, through the response data corresponding to the request The serial parameter in can also know which caller it belongs to. Wherein, the modem processes the requests in the order in which the modem receives the requests.
  • the Modem of the first device returns the response data corresponding to each request to the proxy object of the Client end of the HIDL interface of the first device through the Server end of the HIDL interface.
  • the first device acts as a proxy for the client end of the HIDL interface of the first device, so the server end of the HIDL interface can call back the response data corresponding to each request to the client end of the HIDL interface of the first device.
  • the proxy object that is, the proxy object at the client end of the HIDL interface of the first device has received all the response data corresponding to the requests.
  • the interface proxy module of the first device may receive the response data corresponding to each request returned by the Modem of the first device through the Server end of the HIDL interface.
  • the interface proxy module of the first device may refer to the interface proxy module 3022A in FIG. 3a.
  • the first device For the response data corresponding to each request, the first device identifies the caller to which the response data corresponding to the request belongs according to the processed serial parameter in the response data corresponding to the request.
  • the processed serial parameter in the response data corresponding to the request is actually the serial parameter mentioned in the preceding steps that can be used to describe the caller to which the request belongs. Therefore, according to the processed serial parameter in the response data corresponding to the request, the caller to which the response data corresponding to the request belongs can be identified, and then the first device can know to which caller the response data corresponding to the request should be returned, Realize that there is a one-to-one correspondence between the request sent by the caller and the response data received.
  • the application side sends a request to the Modem for processing.
  • This scheme is to ensure that the response data corresponding to the request can Return to the caller corresponding to the Client of the HIDL interface.
  • the implementation uses the server side of the same HIDL interface to process the request.
  • the first device may execute step S413 through the interface agent module.
  • the interface proxy module 3022A shown in FIG. 3a For example, as shown in the interface proxy module 3022A shown in FIG. 3a.
  • additional function extensions may be performed on the client-side proxy object of the HIDL interface of the first device created on the interface proxy module 3022A, so that the interface proxy of the first device Module 3022A can execute step S413 through the proxy object of the client end of the HIDL interface of the first device.
  • an implementation of step S413 includes: for the response data corresponding to each request, the processed serial parameters in the response data corresponding to the request are respectively associated with the serial parameters corresponding to each caller The value range is matched, and the matched caller is determined as the caller to which the response data corresponding to the request belongs.
  • the serial parameter in the request is offset, so that requests from different callers belong to value ranges. For details, please refer to the relevant content in Table 1 above, which will not be repeated here.
  • the caller corresponding to the matched value range can be determined as the caller to which the response data corresponding to the request belongs. For example, as shown in Table 1, if the processed serial parameter in the response data corresponding to a certain request matches the range from 0 to offset value-1, then the identifier of the caller to which it belongs is 1.
  • the identification result and the response data corresponding to the request may be stored correspondingly.
  • the first device returns the response data belonging to the caller of the second device to the second device.
  • the first device recognizes that the response data corresponding to part of the request belongs to the first device, and the response data corresponding to part of the request belongs to the second device, and can distinguish the response data corresponding to the requests of two different devices, and then The response data of the caller of the second device is selected and returned to the second device.
  • the distributed cellular communication module of the first device may return the response data of the caller of the second device to the distributed cellular communication module of the second device.
  • the second device restores the processed serial parameter in the response data corresponding to the request.
  • the serial parameter is offset by the offset value corresponding to the caller, and at this time, the offset value can be subtracted to restore the original serial parameter.
  • the caller s serial parameter identified as 2 has been processed with a positive offset offset value, so in step S415, it is necessary to subtract the original offset offset value and restore it to the original serial The value of the parameter.
  • step S415 may be performed by an interface agent module.
  • the interface proxy module may be shown as the interface proxy module 3011A in FIG. 3a.
  • the second device when there are multiple callers inside the second device, before performing step S415, the second device needs to execute the response data corresponding to each request, according to the processed serial in the response data corresponding to the request parameter, the step of identifying the caller to which the response data corresponding to the request belongs, to identify which caller of the second device the response data corresponding to the request belongs to.
  • the execution principle and process of the second device performing this step refer to the relevant content of the first device performing step S413, and perform step S415 after identifying the caller to which the response data corresponding to each request belongs.
  • the second device returns each response data of the second device to the caller to which the response data belongs.
  • the second device can return the response data corresponding to each request to the caller to which the response data corresponding to the request belongs.
  • the caller implements a one-to-one correspondence between the request sent by the caller and the response data received.
  • the request of the phone manager in the notebook computer is to dial a certain mobile phone number in Shenzhen, Guangdong province, when the mobile phone will dial
  • the response data corresponding to the request of the phone (that is, the data being called) is returned to the notebook computer, and the phone manager of the notebook computer returns and displays it on the corresponding phone application interface of the notebook computer.
  • the call to the mobile phone number will be displayed on the phone application interface State, that is calling.
  • the response data of each request of the first device may be returned to the caller to which the response data corresponding to the request belongs through the proxy object of the client end of the HIDL interface of the second device.
  • it may be a distributed cellular communication module of the second device to perform step S416.
  • it may be a distributed cellular communication module of the second device to perform step S416.
  • the distributed cellular communication module 3011 of the second device returns the response data corresponding to the request to the phone manager 3012 in FIG. 3a.
  • the first device restores the processed serial parameter in the response data corresponding to the request.
  • step S417 performed by the first device
  • the first device may not only restore the response data of the caller of the first device, but also restore the response data of the second device After the restore process is also performed, step S414 is executed again, and the device returns to the second device.
  • step S416 only needs to be executed after step S413, and the execution of step S414 and step S415 does not have any impact on the execution of step S416.
  • the first device returns the response data of each request of the first device to the caller to which the response data corresponding to the request belongs.
  • the first device can return the response data corresponding to each request to the caller to which the response data corresponding to the request belongs after executing step S417.
  • Party to achieve a one-to-one correspondence between the request sent by the caller and the response data received. For example, as shown in Figure 5c, when the first device is a mobile phone and the second device is a computer, the local video APP on the mobile phone triggers a one-click login request.
  • the phone manager of the mobile phone After the phone manager of the mobile phone sends a one-click login request, the phone manager receives the The response data corresponding to the one-key login request, the response data is one-key login success, and the data of one-key login success of the phone manager is displayed on the video APP interface.
  • the response data of each request of the first device may be returned to the caller to which the response data corresponding to the request belongs through the proxy object of the client end of the HIDL interface of the first device.
  • it may be a distributed cellular communication module of the first device to perform step S415.
  • the distributed cellular communication module 3022 of the first device returns the response data corresponding to the request to the phone manager 3023 in FIG. 3a.
  • the transmission process of the notification of the second device may be consistent with the transmission process of the response data of the second device, and the transmission process of the notification of the first device may also be consistent with the transmission process of the response data of the first device, where No longer.
  • the information used to describe the caller to which the request belongs is the processed serial parameter. In other embodiments, it may also be other types of information such as the identifier of the caller.
  • This embodiment of the application does not As a limitation, it is only necessary that the request sent to the server side of the HIDL interface of the first device can carry information used to describe the caller to which the request belongs.
  • steps S412 to S418 are only an implementation of returning the response data corresponding to each request to the caller to which the response data belongs by identifying the caller to which the response data corresponding to each request belongs. Different from the type of information indicating the caller to which the request belongs, the process of identifying the caller to which the response data corresponding to each request belongs, and returning the response data corresponding to each request to the caller to which the response data belongs will also be corresponding different.
  • the embodiment of the present application can realize that the requests issued by the callers of multiple different devices can be sent through the same device in the scenario of cellular communication capability sharing.
  • the server end of the HIDL interface is sent to the Modem, and the response data of all callers can also be returned to each caller through the server end of the HIDL interface in the same device.
  • this embodiment of the present application can also be applied to the scenario where multiple operating systems in the first device share a Modem, or multiple operating systems in a single operating system of the same device A request sent by a caller.
  • this embodiment of the present application is applicable to processing requests from any multiple callers, and the multiple callers may belong to multiple devices and systems, or may belong to the same device or the same system.
  • the embodiment of the present application is also applicable to other scenarios where requests from multiple callers need to be processed through the server side of an interface, including but not limited to the cellular communication capability sharing scenario exemplified in the embodiment of the present application.
  • time for different callers to issue requests can be arbitrary. Multiple calls can issue requests at the same time, or each can issue requests at any time. The difference in the time for the caller to issue requests is not Affect the realization of the embodiment of the present application.
  • a field for supporting the identification of each caller is preset in the Client end of the HIDL interface in the first device, and the Server end of the HIDL interface is also preset for supporting The request processing method is executed by receiving the field of each caller’s identifier.
  • this application proposes another request processing method, which is applied to the first device, and may specifically include the following steps:
  • the caller's request carries the caller's identifier.
  • the client end of the HIDL interface is preset with a field for receiving the identifier of each caller.
  • the ClientIndex field is added to the Client side of the HIDL interface, and the implementation supports receiving the identification of each calling client.
  • the client side of the HIDL interface pre-sets a field for receiving the ID of each caller, it supports the carrying Requests with the caller's identity are processed further.
  • the caller's request carries the caller's identifier.
  • the Server side of the HIDL interface is preset with a field for receiving the identifier of each caller.
  • the ClientIndex field is added to the Server side of the HIDL interface to support receiving the identification of each calling client. Since the server end of the HIDL interface supports receiving the identifier of each caller, step S602 can be performed through the server end of the HIDL interface.
  • step S602 For the process and principle of performing step S602, reference may be made to the relevant content of the first device performing step S410 in FIG. 4 , which will not be repeated here.
  • the Modem of the first device processes and obtains response data corresponding to each request.
  • step S603 For the process and principle of performing step S603, reference may be made to the relevant content of the first device performing step S411 in FIG. 4 , which will not be repeated here.
  • the Modem of the first device returns the response data corresponding to each request to the Client end of the HIDL interface of the first device through the Server end of the HIDL interface of the first device.
  • step S604 For the process and principle of executing step S604, you can refer to the relevant content of the first device executing step S412 in Figure 4, but different from step S412, the response data corresponding to each request in step S604 is returned to the HIDL interface of the first device the client end of the first device, but what is returned in step S412 is the proxy object of the client end of the HIDL interface of the first device.
  • the Server end of the HIDL interface mentioned in step S604 and the Client end of the HIDL interface both support receiving the identification of each caller, they can also support the response corresponding to each request returned to the Client end of the HIDL interface of the first device
  • the data all carry the identity of the caller.
  • the caller to which the response data corresponding to each request belongs can be identified, so that in the case of multiple callers, only a pair of HIDL interface Server and The client side of the HIDL interface can make the request issued by the caller correspond to the received response data one by one.
  • step S605 may be executed by the interface agent module 3022A in FIG. 3a.
  • the interface proxy module 3022A please refer to the relevant content of the interface proxy module 3022A in FIG. 3a.
  • step S606 for the execution process and principle of step S606, reference may be made to step S417, which will not be repeated here.
  • the request processing method proposed in the embodiment of the present application is also applicable to the processing of the request of the multi-device caller.
  • the first device performs step S601 , the received requests from multiple callers come from multiple devices, including local ones of the first device and other second devices.
  • process of the first device sending the notification to the caller to which the notification belongs may be the same as the process of sending the response data to the caller to which the response data belongs, which will not be repeated here.
  • the application framework layer of the first device in FIG. 6b has a phone manager 601, a phone manager 602, and a phone manager 603 for these three callers, the client end 604 of the newly added HIDL interface is also set in the application program framework layer, and the server end 605 of the newly added HIDL interface is set on the system library.
  • step S602 to step S603 all requests issued by a plurality of telephony managers are sent to the Modem of the first equipment by the Server end 605 of HIDL interface again, by the second
  • the Modem of a device obtains the response data corresponding to each request.
  • step S604 to step S605 the Modem of the first device sends the response data corresponding to each request to the Server end 605 through the HIDL interface of the first device.
  • the Server end 605 of the HIDL interface of a device returns the response data corresponding to each request to the Client end 604 of the HIDL interface of the first device, and then for each response data corresponding to the request, according to the corresponding response data carried in the request
  • the identifier of the caller which identifies the caller to which the response data corresponding to each request belongs.
  • the Client 604 of the HIDL interface of the first device returns the response data 601B corresponding to the request belonging to the phone manager 601 to the phone manager 601, and returns the response data 602B corresponding to the request belonging to the phone manager 602 to the
  • the phone manager 602 returns the response data 603B corresponding to the request belonging to the phone manager 603 to the phone manager 603 .
  • the time when the phone manager 601, the phone manager 602, and the phone manager 603 issue the request can be arbitrary.
  • the interfaces in the first device involved in this application can be collectively referred to as the first device interface, and the newly added (or new Added) HIDL interface, also can be referred to as HIDL interface for short.
  • steps S401 to S404 in FIG. 4 are unnecessary steps.
  • steps S401 to S404 in FIG. 4 are unnecessary steps.
  • the request processing method in FIG. 6a it is not necessary to create a proxy object at the client end of the HIDL interface.
  • the offset of the serial parameter in FIG. 4 is only an implementation manner in which the request carries information for describing the caller to which the request belongs.
  • the identifier of the caller can also be used as the Information about the caller to which the request belongs. Therefore, there are many specific formats and contents of the request and the information carried in the response data corresponding to the request to describe the caller to which the request belongs, and there are many, which are not limited in this embodiment of the present application.
  • the embodiment of the present application also discloses a request processing method, which is applied to the first device, and specifically includes the following steps:
  • step S701 For the execution process and principle of step S701, please refer to the relevant content of steps S401 to S402, which will not be repeated here.
  • the multiple callers include: the caller of the first device and the multiple callers of the second device.
  • the request carries information to describe the caller to which the request belongs.
  • step S702 For the execution process and principle of step S702, please refer to the relevant content of steps S403 to S408, and the relevant content of steps S601 to S602, and will not be repeated here.
  • step S703 For the execution process and principle of step S703, please refer to the relevant content of step S412 and the relevant content of step S604, which will not be repeated here.
  • the HIDL interface mentioned in step S73 may also be other types of first device interfaces, which is limited in this application.
  • step S704 For the execution process and principle of step S704, please refer to the relevant content of step S413 and the relevant content of step S605, which will not be repeated here.
  • step S705 For the execution process and principle of step S705, please refer to the relevant content of step S414, which will not be repeated here.
  • step S706 For the execution process and principle of step S706, please refer to the relevant content of steps S417 to S418 and the relevant content of step S606, and will not be repeated here.
  • the embodiment of the present application also discloses a request processing method, which is applied to the second device, and specifically includes the following steps:
  • step S801 For the execution process and principle of step S801, please refer to the relevant content of steps S401 to S402, which will not be repeated here.
  • step S802 For the execution process and principle of step S802, please refer to the relevant content of step S403 to step S407, which will not be repeated here.
  • the response data carries the information of the caller to which it belongs.
  • step S803 For the execution process and principle of step S803, please refer to the relevant content of step S414, which will not be repeated here.
  • step S804 For the execution process and principle of step S804, please refer to the relevant content of steps S415 to S416 and the relevant content of step S606, and will not be repeated here.
  • the embodiment of the present application also discloses a request processing method for the request processing scenario of the caller of multiple different devices, which specifically includes the following steps:
  • the first device establishes a connection with the second device.
  • step S901 For the execution process and principle of step S901, please refer to the relevant content of steps S401 to S402, which will not be repeated here.
  • the second device forwards the request of the caller of the second device to the first device.
  • step S902 For the execution process and principle of step S902, please refer to the relevant content of step S403 to step S407, which will not be repeated here.
  • the first device sends the request of the caller of the first device and the request of the caller of the second device to the server end of the HIDL interface.
  • step S903 For the execution process and principle of step S903, please refer to the relevant content of steps S403 to S408 and the relevant content of steps S601 to S602, and will not be repeated here.
  • the HIDL interface mentioned in step S903 may also be another type of first device interface, which is not limited in this application.
  • the first device receives response data corresponding to each request returned by the server end of the HIDL interface.
  • step S904 For the execution process and principle of step S904, please refer to the relevant content of step S412 and the relevant content of step S604, which will not be repeated here.
  • the first device For the response data corresponding to each request, the first device identifies the caller to which the response data corresponding to each request belongs according to the information carried in the response data corresponding to the request and used to describe the caller to which the request belongs.
  • step S905 For the execution process and principle of step S905, please refer to the relevant content of step S413 and the relevant content of step S605, which will not be repeated here.
  • the first device returns the response data belonging to the caller of the second device to the second device.
  • step S906 For the execution process and principle of step S906, please refer to the relevant content of step S414, which will not be repeated here.
  • the second device returns each response data to the caller to which the response data belongs.
  • step S907 For the execution process and principle of step S907, please refer to the relevant content of steps S415 to S416 and the relevant content of step S606, and will not be repeated here.
  • the first device returns the response data belonging to the caller of the first device to the caller to which the response data belongs.
  • step S908 For the execution process and principle of step S908, please refer to the relevant content of steps S417 to S418 and the relevant content of step S606, and will not be repeated here.
  • the embodiment of the present application also discloses a request processing method, which is applied to the first device, and specifically includes the following steps:
  • the request carries information used to describe the caller to which the request belongs.
  • step S1001 For the execution process and principle of step S1001, please refer to the relevant content of steps S403 to S408 and the relevant content of steps S601 to S602, and will not be repeated here.
  • the HIDL interface mentioned in step S1001 may also be other types of first device interfaces, which is not limited in this application.
  • step S1002 For the execution process and principle of step S1002, please refer to the relevant content of step S412 and the relevant content of step S604, which will not be repeated here.
  • step S1003 For the execution process and principle of step S1003, please refer to the relevant content of step S413 and the relevant content of step S605, which will not be repeated here.
  • step S1004 For the execution process and principle of step S1004, please refer to the relevant content of steps S417 to S418 and the relevant content of step S606, and will not be repeated here.
  • Some embodiments of the present application also provide an electronic device.
  • processor 1102 processor 1102 ; memory 1103 ; and one or more computer programs 1104 , each of which may be connected via one or more communication buses 1105 .
  • the one or more computer programs 1104 are stored in the above-mentioned memory 1903 and are configured to be executed by the one or more processors 1102, the one or more computer programs 1104 include instructions, and the above-mentioned instructions can be used to perform as Various steps performed by the first device in the corresponding embodiment in FIG. 4 , various steps performed by the second device in the corresponding embodiment in FIG. 4 , and various steps in the corresponding embodiments in FIGS. 6 a to 10 .
  • FIG. 11 may also include other components such as a sensor module, an audio module, and a SIM card interface, which are not limited in this embodiment of the present application.
  • the electronic device shown in FIG. 11 further includes other components such as a sensor module, an audio module, and a SIM card interface, it may be the electronic device shown in FIG. 2c.
  • FIG. 12 shows a schematic diagram of a possible composition of a request processing device, and the request processing device can execute any of the method embodiments in the various method embodiments of the present application. steps performed by an electronic device.
  • the request processing device is an electronic device or a communication device that supports the electronic device to implement the method provided in the embodiment, for example, the communication device may be a chip system.
  • the device for processing the request may include: a processing unit 1201 , a display unit 1202 , and a transceiver unit 1203 .
  • the processing unit 1201 is a processing device for supporting a request to execute the method described in the embodiment of this application.
  • the processing unit 1201 is configured to execute or support the request processing means to execute various steps performed by the first device in the corresponding embodiment of FIG. 4 , various steps performed by the second device in the corresponding embodiment of FIG. 4 , and FIG. to the various steps performed in Figure 10.
  • the request processing device provided in the embodiment of the present application is used to execute the method in any of the above embodiments, so the same effect as the method in the above embodiment can be achieved.
  • This embodiment also provides a computer-readable storage medium, the computer-readable storage medium includes instructions, and when the above-mentioned instructions are run on the electronic device, the electronic device is made to execute the relevant method steps of the first device in FIG. 4 , To realize the method in the above embodiment, or execute the relevant method steps of the second device in FIG. 4 to realize the method in the above embodiment, or execute the relevant method steps in FIG. 6a to FIG. 10 to realize the above implementation method in the example.
  • the technical solution of this embodiment is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium
  • a computer device which may be a personal computer, a server, or a network device, etc.
  • a processor execute all or part of the steps of the method described in each embodiment.
  • the aforementioned storage medium includes: flash memory, mobile hard disk, read-only memory, random access memory, magnetic disk or optical disk, and other various media capable of storing program codes.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Telephonic Communication Services (AREA)
  • Computer And Data Communications (AREA)

Abstract

本申请公开了一种请求的处理方法及相关装置，涉及电子信息技术领域，目的在于满足一个HIDL接口的Server端同时处理多个HIDL接口的Client端下发的请求的需求。具体方案为：将多个调用方的请求，发送至第一设备接口的服务Server端。其中，请求中携带有用于说明请求所属的调用方的信息，然后接收第一设备接口的Server端返回的每一个请求对应的响应数据。其中，请求对应的响应数据中携带有用于说明请求所属的调用方的信息，进而针对每一个请求对应的响应数据，能够根据请求对应的响应数据中携带的用于说明请求所属的调用方的信息，识别请求对应的响应数据所属的调用方，将请求对应的响应数据返回至请求对应的响应数据所属的调用方。

Description

请求的处理方法及相关装置
本申请要求于2021年8月25日提交中国国家知识产权局、申请号为202110993034.5、发明名称为“请求的处理方法及相关装置”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及电子信息技术领域，尤其涉及一种请求的处理方法及相关装置。
背景技术
现有技术中，应用侧通常通过调用抽象层接口定义语言(HAL interface definition language，HIDL)接口与调制解调处理器(Modem)及其硬件抽象层(HardwareAbstraction Layer，HAL)层进行交互。HIDL接口具有客户(Client)端和服务(Server)端的实现，Client端是指通过HIDL调用方法的一方，Server端是指实现HIDL的接口，接受Client端的调用并返回数据的一方。
具体的，应用侧下发请求至调制解调处理器(Modem)处理的方案为：应用侧的一个调用方下发请求时,调用该调用方对应的HIDL接口的Client端，该调用方下发的请求，会在HAL层上的HIDL接口的Server端处理，HIDL接口的Server端将请求下发到Modem，由Modem处理得到请求对应的响应数据。然而，现有的应用侧下发请求给Modem处理的方案中，HIDL接口的Client端和Server端是一一绑定的，每一个HIDL接口的Server端均固定注册了一个HIDL接口的Client端，即一个HIDL接口的Server端仅能固定接收一个HIDL接口的Client端所下发的请求并向其返回结果，不支持一个HIDL接口的Server端同时处理多个HIDL接口的Client端下发的请求的功能。
发明内容
本申请提供了一种请求的处理方法及相关装置，目的在于解决不支持一个HIDL接口的Server端同时处理多个HIDL接口的Client端下发的请求的问题。
为了实现上述目的，本申请提供了以下技术方案：
第一方面，本申请公开了一种请求的处理方法，应用于第一设备，该请求的处理方法，包括：将多个调用方的请求，发送至第一设备接口的服务Server端。其中，请求中携带有用于说明请求所属的调用方的信息。然后接收第一设备接口的Server端返回的每一个请求对应的响应数据。其中，请求对应的响应数据中携带有用于说明请求所属的调用方的信息。针对每一个请求对应的响应数据，根据请求对应的响应数据中携带的用于说明请求所属的调用方的信息，识别请求对应的响应数据所属的调用方。针对每一个请求对应的响应数据，将请求对应的响应数据返回至请求对应的响应数据所属的调用方。
本申请实施例中，根据请求对应的响应数据中携带的用于说明请求所属的调用方的信息，识别请求对应的响应数据所属的调用方，进而能将每一个请求对应的响应数据返回至 响应数据所属的调用方，满足了多个HIDL接口的Client端同时处理多个调用方下发的请求的需求。
在一种可能的实现方式中，第一设备接口为第一设备的HIDL接口，将多个调用方的请求，发送至第一设备接口的服务Server端之后，还包括：通过第一设备的HIDL接口的Server端，将每一个调用方的请求发送到第一设备的Modem。通过第一设备的Modem对每一个请求进行处理，得到每一个请求对应的响应数据。进而接收Modem通过第一设备的HIDL接口的Server端，返回的每一个请求对应的响应数据。在另一些实施例中，第一设备接口也可以为其他类型的接口，对此不做限定。
在另一种可能的实现方式中，通过第一设备的HIDL接口的Server端，将每一个调用方的请求发送到第一设备的Modem，包括：通过接口代理模块调用第一设备的HIDL接口的Server端，将每一个调用方的请求发送到第一设备的Modem。其中，接口代理模块预创建了每一个调用方对应的HIDL接口的Client端的代理对象。接收Modem通过第一设备的HIDL接口的Server端，返回的每一个请求对应的响应数据，包括：通过接口代理模块，接收Modem通过第一设备的HIDL接口的Server端，返回的每一个请求对应的响应数据。
在另一种可能的实现方式中，多个调用方的请求，包括：第一设备的调用方的请求，和/或，第二设备的调用方的请求。
在另一种可能的实现方式中，将多个调用方的请求，发送至第一设备接口的服务Server端之前，还包括：针对每一个调用方的请求，根据调用方的标识，对请求中的serial参数进行处理，以使得请求中的处理后的serial参数可用于说明请求所属的调用方。其中，用于说明所述请求所属的调用方的信息为：请求中处理后的serial参数。针对每一个请求对应的响应数据，将请求对应的响应数据返回至请求对应的响应数据所属的调用方之前，还包括：针对每一个请求对应的响应数据，将请求对应的响应数据中的处理后的serial参数，进行还原处理。
在另一种可能的实现方式中，针对每一个调用方的请求，根据调用方的标识，对请求中的serial参数进行处理，以使得请求中的处理后的serial参数可用于说明请求所属的调用方，包括：针对每一个调用方的请求，根据调用方的标识，将请求中的serial参数偏移与调用方对应的偏移值，以使得请求中的处理后的serial参数可用于说明请求所属的调用方。
通过让请求中的serial参数偏移与调用方对应的偏移值，可以使得偏移处理后的serial参数可用于说明请求所属的调用方。
在另一种可能的实现方式中，针对每一个请求对应的响应数据，根据请求对应的响应数据中的处理后的serial参数，识别请求对应的响应数据所属的调用方，包括：针对每一个请求对应的响应数据，将请求对应的响应数据中的处理后的serial参数，分别与每一个调用方对应的serial参数取值范围进行匹配，并将匹配的调用方确定为请求对应的响应数据所属的调用方。
在另一种可能的实现方式中，用于说明所述请求所属的调用方的信息为：请求所属的调用方的标识。接收第一设备接口的Server端返回的每一个所述请求对应的响应数据，包括：通过第一设备接口的Client端，接收第一设备接口的Server端返回的每一个请求对应的响应数据。其中，第一设备接口的Client端中预设置了用于支持接收每一个调用方的标 识的字段，第一设备接口的Server端中预设置了用于支持接收每一个调用方的标识的字段。
由于第一设备接口的Client端中预设置了用于支持接收每一个调用方的标识的字段，第一设备接口的Server端中预设置了用于支持接收每一个调用方的标识的字段，因此均能够支持接收携带有请求所属的调用方的标识的请求以及响应数据。
在另一种可能的实现方式中，若多个调用方的请求，包括：第一设备的调用方的请求和第二设备的调用方的请求，则将多个调用方的请求，发送至第一设备接口的服务Server端之前，还包括：针对每一个第一设备的调用方的请求，根据调用方的标识，对请求中的serial参数进行处理，以使得请求中的处理后的serial参数可用于说明请求所属的调用方，或者，针对每一个第一设备和第二设备的调用方的请求，根据调用方的标识，对请求中的serial参数进行处理，以使得请求中的处理后的serial参数可用于说明请求所属的调用方。其中，用于说明请求所属的调用方的信息为：请求中处理后的serial参数。
在另一种可能的实现方式中，针对每一个所述请求对应的响应数据，将请求对应的响应数据返回至请求对应的响应数据所属的调用方之前，还包括：针对每一个属于第一设备的请求对应的响应数据，将请求对应的响应数据中的处理后的serial参数，进行还原处理，或者，针对每一个属于第一设备和第二设备的请求对应的响应数据，均将请求对应的响应数据中的处理后的serial参数，进行还原处理。
在另一种可能的实现方式中，对请求中的serial参数进行处理，以使得请求中的处理后的serial参数可用于说明请求所属的调用方，包括：根据调用方的标识，将请求中的serial参数偏移与调用方对应的偏移值，以使得请求中的处理后的serial参数可用于说明请求所属的调用方。
第二方面，本申请公开了另一种请求的处理方法，应用于第二设备，请求的处理方法，包括：发送第二设备的调用方的请求至第一设备，以使得第一设备将第二设备的调用方的请求，发送到第一设备接口的Server端，并接收第一设备接口的Server端返回的每一个请求对应的响应数据。其中，请求中携带有用于说明请求所属的调用方的信息。第一设备和第二设备处于连接状态。然后接收第一设备返回的每一个属于第二设备的请求对应的响应数据。其中，请求对应的响应数据所属的调用方由第一设备根据请求对应的响应数据中携带的用于说明请求所属的调用方的信息识别得到。针对每一个请求对应的响应数据，将响应数据返回至响应数据所属的调用方。
由于请求对应的响应数据所属的调用方由第一设备根据请求对应的响应数据中携带的用于说明请求所属的调用方的信息识别得到，因此第二设备能够接收到第一设备返回的每一个属于第二设备的请求对应的响应数据，进而可以针对每一个请求对应的响应数据，将响应数据返回至响应数据所属的调用方，实现通过第一设备接口的Server端处理不同设备的多个调用方的请求。
在一种可能的实现方式中，发送第二设备的调用方的请求至第一设备之前，还包括：通过接口代理模块接收第一设备的调用方的请求。其中，接口代理模块预创建了第一设备的调用方对应的HIDL接口的Client端的代理对象、以及第二设备的调用方对应的HIDL接口的Client端的代理对象。
在另一种可能的实现方式中，发送第二设备的调用方的请求至第一设备之前，还包括：
针对每一个第二设备的调用方的请求，根据调用方的标识，对请求中的serial参数进行处理，以使得请求中的处理后的serial参数可用于说明请求所属的调用方。
在另一种可能的实现方式中，针对每一个请求对应的响应数据，将响应数据返回至响应数据所属的调用方之前，还包括：针对每一个属于第二设备的请求对应的响应数据，将请求对应的响应数据中的处理后的serial参数，进行还原处理。
在另一种可能的实现方式中，针对每一个第二设备的调用方的请求，根据调用方的标识，对请求中的serial参数进行处理，以使得请求中的处理后的serial参数可用于说明请求所属的调用方，包括：针对每一个第二设备的调用方的请求，根据调用方的标识，将请求中的serial参数偏移与调用方对应的偏移值，以使得请求中的处理后的serial参数可用于说明请求所属的调用方。
在另一种可能的实现方式中，若第二设备有多个调用方，则针对每一个请求对应的响应数据，将响应数据返回至所述响应数据所属的调用方之前，还包括：针对每一个请求对应的响应数据，根据请求对应的响应数据中携带的用于说明请求所属的调用方的信息，识别请求对应的响应数据所属的调用方。
在另一种可能的实现方式中，针对每一个所述请求对应的响应数据，根据请求对应的响应数据中的处理后的serial参数，识别请求对应的响应数据所属的调用方，包括：针对每一个请求对应的响应数据，将请求对应的响应数据中的处理后的serial参数，分别与每一个调用方对应的serial参数取值范围进行匹配，并将匹配的调用方确定为请求对应的响应数据所属的调用方。
第三方面，本申请公开了一种电子设备，包括：一个或多个处理器、存储器、显示屏、无线通信模块以及移动通信模块。存储器、显示屏、无线通信模块以及移动通信模块与一个或多个处理器耦合，存储器用于存储计算机程序代码，计算机程序代码包括计算机指令，当一个或多个处理器执行计算机指令时，电子设备执行如第一方面中任一项所述的请求的处理方法，或者如第二方面中任一项所述的请求的处理方法。
第四方面，本申请公开了一种请求的处理装置，请求的处理装置包括：处理单元、存储单元、显示单元、收发单元，所述存储单元用于存储一个或多个程序；所述处理单元用于执行一个或多个程序。一个或多个程序包括指令，指令用于执行如第一方面中任一项所述的请求的处理方法，或者如第二方面中任一项所述的请求的处理方法。
附图说明
图1a为一种电子设备的软件架构示意图；
图1b为一种蜂窝通信能力共享场景图一；
图1c为图1b场景中的手机a内部的HIDL接口连接关系示意图；
图1d为一种蜂窝通信能力共享场景图二；
图2a为本申请公开的请求的处理系统的架构图一；
图2b为本申请公开的请求的处理系统的架构图二；
图2c为本申请公开的电子设备的组成示例图一；
图3a为本申请公开的请求的处理系统的系统架构图三；
图3b为本申请公开的一种第二设备的调用方下发请求的流程示意图；
图3c为本申请公开的一种第一设备的调用方下发请求的流程示意图；
图3d为本申请公开的一种响应数据返回至调用方的流程示意图；
图4为基于图3a的系统公开的一种请求的处理方法的流程示意图一；
图5a为本申请公开的一种完成蜂窝通信能力共享配置的场景示意图；
图5b为本申请公开的一种响应数据返回设备的场景示意图；
图5c为本申请公开的另一种响应数据返回设备的场景示意图；
图6a为本申请公开的一种请求的处理方法的流程示意图二；
图6b为本申请公开的用于执行图6a的第一设备内部的系统架构图；
图7为本申请公开的一种请求的处理方法的流程示意图三；
图8为本申请公开的一种请求的处理方法的流程示意图四；
图9为本申请公开的一种请求的处理方法的流程示意图五；
图10为本申请公开的一种请求的处理方法的流程示意图六；
图11为本申请公开的电子设备的组成示例图二；
图12为本申请公开的请求的处理装置的组成示意图。
具体实施方式
本申请说明书和权利要求书及附图说明中的术语“第一”、“第二”和“第三”等是用于区别不同对象，而不是用于限定特定顺序。
在本申请实施例中，“示例性的”或者“例如”等词用于表示作例子、例证或说明。本申请实施例中被描述为“示例性的”或者“例如”的任何实施例或设计方案不应被解释为比其它实施例或设计方案更优选或更具优势。确切而言，使用“示例性的”或者“例如”等词旨在以具体方式呈现相关概念。
为了下述各实施例的描述清楚简洁，首先给出一种应用侧下发请求给调制解调处理器(Modem)处理的方案的简要介绍：
当一个电子设备仅具有一个操作系统时，在该操作系统内部，应用侧的调用方发起请求，调用该调用方对应的HIDL接口的Client端，调用方发起的请求会在HIDL接口的Server端处理，即HIDL接口的Server端将请求发送给Modem，Modem处理得到请求对应的响应数据后，调用HIDL接口的Server端，然后HIDL接口的Server端将请求对应的响应数据返回给HIDL接口的Client端，HIDL接口的Client端再返回给对应的调用方。
其中，应用侧指的是运行在应用处理器上程序，例如应用程序层、应用框架层中的程序。调用方例如应用软件(Application，App)，电话管理器(telephony)等。
举例说明，以电子设备的电话管理器为调用方为例，如图1a中的虚线所示，当电子设备的应用程序层中的短信息应用触发了请求(Request)，该Request从电子设备本地的应用程序层下发到应用程序框架层中的电管管理器(Telephony)。请求调用电话管理器中的Android开放源代码项目(Android Open Source Project，AOSP)的开发工具包(Software Development Kit，SDK)应用程序接口(Application Programming Interface，API)，然后AOSP SDK API又再调用电话管理器的服务(Telephony Service)接口，然后Telephony  Service再调用HIDL接口的Client端，然后再由HIDL接口的Client端再调用本地系统库上的HIDL接口的Server端，然后通过HIDL接口的Server端将Request发送给供应商无线接口层(Vendor-RIL)，再由Vendor-RIL发送到本地的调制解调处理器(Modem)处理。其中，HIDL接口的Server端在HAL层上的RIL模块上。
如图1a的实线所示：本地的Modem处理后得到请求对应的响应数据(Response)，然后Modem将Response通过Vendor-RIL、HIDL接口的Server端上报至电话管理器中的HIDL接口的Client端，再由电话管理器内的Telephony Service、开发工具包，发送到短信息应用。本地的Modem还可以主动将通知(Indication)通过调用HIDL接口的Server端上报至电话管理器，然后电话管理器再继续将通知上报至短信息应用。其中，Indication的上报过程与Response可以是一样的，此处不再赘述。除了可以是图1a示出的短信息应用，也可以是其他的应用的request。
由前述内容可知，电子设备内的一个HIDL接口的Server端仅能固定接收一个HIDL接口的Client端所下发的Request并向其返回对应的Response。在电子设备内部，为了保障HIDL接口的Server端返回的请求对应的响应数据，能够与HIDL接口的Client下发的请求一一对应，以确保请求对应的响应数据能够返回到HIDL接口的Client所对应的调用方，每一个HIDL接口的Server端均固定注册了一个HIDL接口的Client端。
本申请提供了一种实施例，通过在电子设备的HAL层创建多个Server端，实现多个设备共享蜂窝能力，或者实现同一个设备的不同操作系统能使用蜂窝能力。例如，如图1c所示，HAL层需要针对每一个Client端单独建立一个Server端。其中不同的Client端可以是位于同一个设备的不同操作系统，也可以是不同的设备。
示例性的，如图1b所示，手机a为第一设备，手机b和c为第二设备。当手机b和手机c想要共享手机a的蜂窝能力时，手机a需要针对手机b和手机c分别在HAL层建立Server端。
由上述技术方案可知，为了共享蜂窝能力，第一设备会针对每一个第二设备，或者每一个操作系统分别建立Server端。而第一设备中启动的server端的数目是代码里固定配置的，不能随着共享设备的增加或者减少而动态调整，导致HAL层需要通过不断的调整代码来实现对不同数目的Client端的支持，使用起来非常不便。
其中，本申请中所提及的第一设备均指的是提供Modem的电子设备，本申请中提及的第二设备均指的是使用第一设备的Modem的电子设备。
本申请提供另一种实施例，通过在调用方下发的请求中携带用于说明请求所属的调用方的信息，来区分每一个请求所属的调用方，实现让多个调用方下发的请求，均通过接口代理模块调用同一个HIDL接口的Server端进行处理，并能够将每一个请求对应的响应数据分别返回到对应的调用方。
为了下述对本申请提出的请求的处理过程的实施例描述清楚，首先给出与本申请实施例相关技术的简要介绍：
代理模式是一种设计模式，用于通过创建目标对象的代理对象的方式，提供对目标对象额外的访问方式。其中，目标对象为一种接口，例如可以是HIDL接口的Client端，可 以是HIDL接口中的Radio HIDL接口的Client端。通过代理对象访问目标对象，可以在不修改原目标对象的前提下，通过代理对象提供额外的功能操作，扩展原目标对象的功能。
本申请实施例所提及的请求可以是应用侧的调用方下发至Modem的请求，例如，可以是蜂窝通信业务的请求中涉及到的请求。示例性的，所有与蜂窝通信相关的业务或者能力都可以称为蜂窝通信业务，例如通话、短信、SIM卡变更、呼叫转移等，都可以称为蜂窝通信业务。
本申请提供的实施例可以适用于多个设备共享蜂窝能力的场景。例如，如图1b所示，手机b和手机c可以通过本申请实施例提供的方法共享手机a的蜂窝能力。再例如，如图1d所示，第一设备可以为图1d中的手机11。第二设备可以为图1d中的平板12、智能眼镜13、手表14、音箱15、智能屏16、笔记本电脑17。本申请提供的实施例可以使第二设备可以同时共享第一设备的蜂窝能力，或者modem。
本申请实施例提供的请求的处理方法还可以适用于第一设备内单个操作系统使用一个Modem的场景。例如，在同一个操作系统中，多个独立的通信服务或者应用也可以共享使用一个Modem。
本申请实施例提出的实施例中，可以通过在请求中添加请求方信息，区分请求的调用方。其中，请求方信息可以是顺序(Serial)参数，也可以是自定义参数或者新增的字段。
在一些实施例中，第二设备，或者第一设备可以通过serial参数区分请求所属的调用方。例如，如2a所示，第一设备内可以只增加一个接口代理模块，接口代理模块可以代理多个HIDL接口的Client端。具体的，接口代理模块接收telephony1、telephony2、……telephony n这n个调用方下发的Request。其中，接口代理模块接收Request的相关内容具体可参阅图3b中的步骤S3013、图3c的步骤S3022至步骤S3023、图4的步骤S407至步骤S408、以及图6a的步骤S601的相关描述。通过serial参数区分调用方可以参考下述图3d中的步骤S3032至步骤S3034，以及图4中的步骤S413至步骤S418的相关描述。
在另一些实施例中，电子设备也可以通过新增字段或者自定义参数确定调用方。例如，如2b所示，调用方，例如Telephony发送的请求中可以携带新增的字段或者参数，这个字段或者参数可以用来识别调用方的身份。此时第一设备的Client端接收到该请求时，可以通过新增的字段或者参数识别调用方的身份。具体的，HIDL接口的Client端接收Request的过程可以参考图6a的步骤S601的相关描述。
其中，图2a和图2b所示出的调用方可以在同一个操作系统内，也可以分布在不同操作系统。这n个调用还可以都在第一设备内，还可以分布多个不同的设备(即分布在多个第二设备和第一设备)中。调用方除了可以如图2a所示的telephony，还可以是IP多媒体子系统(IP Multimedia Subsystem，IMS)应用等其他类型的调用方。且本申请实施例对于接口的类型也不做限制，除了可以是HIDL接口，也可以是其他类型的第一设备接口。
在一些实施例中，本申请实施例中的第二设备可以是手机、平板电脑、桌面型、膝上型、笔记本电脑、超级移动个人计算机(Ultra-mobile Personal Computer，UMPC)、手持计算机、上网本、个人数字助理(Personal Digital Assistant，PDA)、可穿戴电子设备、智能 手表等电子设备，第一设备为手机、智能通话手表等具有蜂窝通信能力的电子设备，本申请对上述电子设备的具体形式不做特殊限制。需要说明的是，本申请实施例中的第二设备均指的是使用第一设备的蜂窝通信能力的设备，而第一设备指的是具有蜂窝通信能力的设备。
在本申请实施例中，第二设备和第一设备的结构均可以如图2c所示，第二设备和第一设备在图2c中统称为电子设备200进行介绍，电子设备200可以包括处理器210，外部存储器接口220，内部存储器221，通用串行总线(universal serial bus，USB)接口230，充电管理模块240，电源管理模块241，电池242，天线1，天线2，移动通信模块250，无线通信模块260，音频模块270，扬声器270A，受话器270B，麦克风270C，耳机接口270D，传感器模块280，按键290，马达291，指示器292，摄像头293，显示屏294，以及用户标识模块(subscriber identification module，SIM)卡接口295等。其中传感器模块280可以包括压力传感器280A，陀螺仪传感器280B，气压传感器280C，磁传感器280D，加速度传感器280E，距离传感器280F，接近光传感器280G，指纹传感器280H，温度传感器280J，触摸传感器280K，环境光传感器280L，骨传导传感器280M等。
可以理解的是，本实施例示意的结构并不构成对电子设备200的具体限定。在另一些实施例中，电子设备200可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。图示的部件可以以硬件，软件或软件和硬件的组合实现。
处理器210可以包括一个或多个处理单元，例如：处理器210可以包括应用处理器(application processor，AP)，Modem，图形处理器(graphics processing unit，GPU)，图像信号处理器(image signal processor，ISP)，控制器，视频编解码器，数字信号处理器(digital signal processor，DSP)，基带处理器，和/或神经网络处理器(neural-networkprocessing unit，NPU)等。其中，不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。又例如，在本申请实施例中，处理器210可以执行本申请实施例任一所述的请求的处理方法。
其中，控制器可以是电子设备200的神经中枢和指挥中心。控制器可以根据指令操作码和时序信号，产生操作控制信号，完成取指令和执行指令的控制。
处理器210中还可以设置存储器，用于存储指令和数据。
充电管理模块240用于从充电器接收充电输入。其中，充电器可以是无线充电器，也可以是有线充电器。在一些实施例中，充电管理模块240为电池242充电的同时，还可以通过电源管理模块241为电子设备供电。
电源管理模块241用于连接电池242，充电管理模块240与处理器210。电源管理模块241接收电池242和/或充电管理模块240的输入，为处理器210，内部存储器221，显示屏294，摄像头293，和无线通信模块260等供电。
电子设备200的无线通信功能可以通过天线1，天线2，移动通信模块250，无线通信模块260，Modem210A以及基带处理器等实现。
天线1和天线2用于发射和接收电磁波信号。电子设备200中的每个天线可用于覆盖 单个或多个通信频带。不同的天线还可以复用，以提高天线的利用率。
移动通信模块250可以提供应用在电子设备200上的包括2G/3G/4G/5G等无线通信的解决方案。
Modem210A可以包括调制器和解调器。其中，调制器用于将待发送的低频基带信号调制成中高频信号。解调器用于将接收的电磁波信号解调为低频基带信号。在一些实施例中，Modem210A可以是独立的器件。在另一些实施例中，Modem210A可以独立于处理器210，与移动通信模块250或其他功能模块设置在同一个器件中。例如，在本申请的一些实施例中，当电子设备200为图3a示出的第二设备时，可以不具有Modem210A，而当电子设备200上述本申请实施例提及的第一设备时，需具有Modem210A，以向第二设备提供蜂窝通信能力。例如，在本申请实施例中，当电子设备200为图3a示出的第一设备时，Modem210A的具体执行过程和原理，可参见下述本申请实施例所提及的任一请求的处理方法和请求的处理系统中对第一设备中的Modem的相关描述，此处不再赘述。
无线通信模块260可以提供应用在电子设备200上的包括无线局域网(wireless local area networks，WLAN)(如无线保真(wireless fidelity，Wi-Fi)网络)，蓝牙(bluetooth，BT)，全球导航卫星系统(global navigation satellite system，GNSS)，调频(frequency modulation，FM)，近距离无线通信技术(near field communication，NFC)，红外技术(infrared，IR)等无线通信的解决方案。
电子设备200通过GPU，显示屏294，以及应用处理器等实现显示功能。GPU为图像处理的微处理器，连接显示屏294和应用处理器。
显示屏294用于显示图像，视频等。电子设备200的显示屏294上可以显示一系列图形用户界面(graphical user interface，GUI)。
电子设备200可以通过ISP，摄像头293，视频编解码器，GPU，显示屏294以及应用处理器等实现拍摄功能。
摄像头293用于捕获静态图像或视频。
外部存储器接口220可以用于连接外部存储卡，例如Micro SD卡，实现扩展电子设备200的存储能力。
内部存储器221可以用于存储计算机可执行程序代码，所述可执行程序代码包括指令。处理器210通过运行存储在内部存储器221的指令，从而执行电子设备200的各种功能应用以及数据处理。处理器210通过运行存储在内部存储器221的指令，和/或存储在设置于处理器中的存储器的指令，执行电子设备200的各种功能应用以及数据处理。
电子设备200可以通过音频模块270，扬声器270A，受话器270B，麦克风270C，耳机接口270D，以及应用处理器等实现音频功能。例如音乐播放，录音等。电子设备200还可以包括压力传感器280A，气压传感器280C，陀螺仪传感器280B，磁传传感器280D，加速度传感器280E，距离传感器280F，接近光传感器280G，环境光传感器280L，指纹传感器280H，温度传感器280J，触摸传感器280K，骨传导传感器280M，按键290，马达291，指示器292等。
SIM卡接口295用于连接SIM卡。SIM卡可以通过插入SIM卡接口295，或从SIM卡接口295拔出，实现和电子设备200的接触和分离。电子设备200可以支持1个或N个SIM 卡接口，N为大于1的正整数。SIM卡接口295可以支持Nano SIM卡，Micro SIM卡，SIM卡等。同一个SIM卡接口295可以同时插入多张卡。SIM卡接口295也可以兼容外部存储卡。电子设备200通过SIM卡和网络交互，实现通话以及数据通信等功能。
另外，在上述部件之上，运行有操作系统。例如鸿蒙操作系统、iOS操作系统，Android操作系统，Windows操作系统等。在该操作系统上可以安装运行应用程序。在另一些实施例中，电子设备内运行的操作系统可以有多个。
参阅图3a，图3a为本申请实施例提出的一种请求的处理系统300。其中，请求的处理系统300用于执行第二设备和第一设备所下发的请求的处理。而在另一些实施例中，请求的处理系统300中第二设备和第一设备内部的操作系统可以处于同一个电子设备内，而下述对请求的处理系统300执行的第二设备和第一设备所下发的请求的处理过程，也可以适用于同一个电子设备中两个操作系统所下发的请求的处理过程。
在一些实施例中，本申请实施例公开的请求的处理系统300中第二设备的分层架构将软件分成若干个层，每一层都有清晰的角色和分工。层与层之间通过软件接口通信。在一些实施例中，将Android系统分为四层，从上至下分别为应用程序层，应用程序框架层，安卓运行时(Android runtime)和系统库，以及内核层。
应用程序层可以包括一系列应用程序包。如图3a所示，应用程序包可以包括相机，图库，日历，通话，地图，导航，WLAN，蓝牙，音乐，视频，短信息等应用程序。
应用程序框架层为应用程序层的应用程序提供应用编程接口(application programming interface，API)和编程框架。应用程序框架层包括一些预先定义的函数。如图3a所示，应用程序框架层可以包括窗口管理器，内容提供器，视图系统，分布式蜂窝通信模块3011，电话管理器3012，分布式总线3013，资源管理器，通知管理器等。
窗口管理器用于管理窗口程序。窗口管理器可以获取显示屏大小，判断是否有状态栏，锁定屏幕，截取屏幕等。
内容提供器用来存放和获取数据，并使这些数据可以被应用程序访问。所述数据可以包括视频，图像，音频，拨打和接听的电话，浏览历史和书签，电话簿等。
视图系统包括可视控件，例如显示文字的控件，显示图片的控件等。视图系统可用于构建应用程序。显示界面可以由一个或多个视图组成的。例如，包括短信通知图标的显示界面，可以包括显示文字的视图以及显示图片的视图。
电话管理器3012用于提供第二设备的蜂窝通信功能。例如通话状态的管理(包括接通，挂断等)。电话管理器3012在本申请实施例中的功能具体可参见下述对请求的处理系统300中的电话管理器3012的描述。
分布式蜂窝通信模块3011用于将电话管理器3012的蜂窝通信业务的请求转发至第一设备的分布式蜂窝通信模块3022。第二设备的分布式蜂窝通信模块3011在本申请实施例中的功能具体可参见下述对请求的处理系统300中第二设备的分布式蜂窝通信模块3011的描述。例如，在一些实施例中，第二设备的分布式蜂窝通信模块3011中包括：接口代理模块3011A。基于前述提及的代理模式的技术，接口代理模块3011A上创建了面向第二设备中的HIDL接口的Client端的代理对象，面向第二设备中的HIDL接口的Client端的代理对象 可用于接收第二设备的调用方下发的请求，并将请求转发至第一设备。面向第二设备中的HIDL接口的Client端的代理对象可以理解为是请求接口的代理对象，即第二设备的调用方下发的请求都由该请求接口的代理对象接收。在一些实施例中，第二设备的分布式蜂窝通信模块3011所接收到的第二设备的调用方下发的请求中，还包括有下发该请求的调用方的标识，第二设备的分布式蜂窝通信模块3011根据调用方的标识，对请求中的次序(serial)参数进行偏移处理，请求中偏移处理后的serial参数能够说明请求对应的调用方。
第二设备的分布式蜂窝通信模块3011具体执行过程和原理可参见下述本申请实施例提及的请求的处理系统和请求的处理方法中相关描述，此处不再赘述。
分布式总线3013用于建立第二设备的分布式蜂窝通信模块3011和第一设备的分布式蜂窝通信模块3022的连接通道，连接第二设备的分布式蜂窝通信模块3011和第一设备的分布式蜂窝通信模块3022。在一些实施例中，分布式总线3013可以负责近距离、局域网、或者远场同账号下的设备发现、自连接、鉴权管理等。还可以负责不同通道的调度管理、服务质量体验评估等，对应用程序层透明。还可以负责通道的保持，提供低功耗待机机制。还可以负责控制面信令(例如下述本申请实施例提及的请求的处理方法以及请求的处理系统中涉及的请求、请求对应的响应数据)的转发/响应，以及加密封装等。
资源管理器为应用程序提供各种资源，比如本地化字符串，图标，图片，布局文件，视频文件等等。
核心库包含两部分：一部分是java语言需要调用的功能函数，另一部分是安卓的核心库。
应用程序层和应用程序框架层运行在虚拟机中。虚拟机将应用程序层和应用程序框架层的java文件执行为二进制文件。虚拟机用于执行对象生命周期的管理，堆栈管理，线程管理，安全和异常的管理，以及垃圾回收等功能。
系统库可以包括多个功能模块。例如：表面管理器(surface manager)，媒体库(Media Libraries)，三维图形处理库(例如：OpenGL ES)，2D图形引擎(例如：SGL)，硬件抽象层(Hardware Abstraction Layer，HAL)，以及在HAL上的无线电接口层(Radio Interface Layer，RIL)模块等。RIL模块上还提供有HIDL接口的Server端。
表面管理器用于对显示子系统进行管理，并且为多个应用程序提供了2D和3D图层的融合。
媒体库支持多种常用的音频，视频格式回放和录制，以及静态图像文件等。媒体库可以支持多种音视频编码格式，例如:MPEG4，H.264，H.265,H.266，VP9，MP3，AAC，AMR，JPG，PNG等。
三维图形处理库用于实现三维图形绘图，图像渲染，合成，和图层处理等。
2D图形引擎是2D绘图的绘图引擎。
内核层是硬件和软件之间的层。内核层至少包含显示驱动，摄像头驱动，音频驱动，传感器驱动。
继续参阅图3a，第一设备的软件分层架构可以参考第二设备的软件分层架构，在此不做赘述。第一设备还包括有调制解调处理器3021，Modem3021用于将接收到的请求进行处理，得到请求对应的响应数据，然后将请求对应的响应数据发送至分布式蜂窝通信模块3022。
在一些实施例中，参考第二设备的分布式蜂窝通信模块3011，第一设备也可以在第一设备的应用程序框架层设立分布式蜂窝通信模块3022。其中，分布式通信模块3022也可以设置接口代理模块3022A。代理模块的设立方式可以参考上述第二设备中接口代理模块3011A的设立方式，在此不再赘述。接口代理模块3022A上可以创建面向第一设备中的HIDL接口的Client端的代理对象。面向第一设备中的HIDL接口的Client端的代理对象用于接收第一设备的HIDL接口的Server端发送的所有请求对应的响应数据。同时，分布式蜂窝通信模块3022也可以接收第二设备的请求，以及第一设备的调用方下发的请求。可以理解的是，分布式蜂窝通信模块3022接收的第二设备的请求，可以是经过第二设备的接口代理模块处理过的请求，也可以是未处理过的请求。
在一些实施例中，当第一设备存在多个调用方时，分布式蜂窝通信模块3022可以通过请求方信息识别调用方。具体方式可以参考图2a和图2b所示的方式。
第一设备的分布式总线3024的原理和执行过程与第二设备的分布式总线3013一致，可参见，此处不再赘述。
在一些实施例中，当第一设备已向第二设备共享了自身的蜂窝通信能力(即共享了第一设备的Modem)时，如图3b所示，第二设备的蜂窝通信业务的请求在图3a的系统中的处理过程可以是：第二设备执行步骤S3011，触发蜂窝通信业务的请求。然后执行步骤S3012，第二设备将蜂窝通信业务的请求发送到本地的电话管理器中。在步骤S3013中，第二设备的电话管理器作为调用方，调用第二设备的接口代理模块，将蜂窝通信业务的请求发送到第二设备的分布式蜂窝通信模块。其中，第二设备的接口代理模块预先创建了请求接口的代理对象，即代理了HIDL接口的Client端向HIDL接口的Server端调用的接口，也可以认为是Client端的请求接口。需要说明的是，HIDL接口的Client端下发请求和接收请求对应的响应数据是异步处理的，即不是同一个接口处理的。在步骤S3014中，第二设备的分布式蜂窝通信模块对蜂窝通信业务的请求中的serial参数进行偏移处理，其中请求中偏移处理后的serial参数能够说明请求对应的调用方。其中，步骤S3011至步骤S3014的执行过程和原理也可参阅图4中的步骤S401至步骤S406部分、以及图6a中的步骤S601的相关内容。在步骤S3015中，第二设备的分布式蜂窝通信模块将蜂窝通信业务的请求转发到第一设备的分布式蜂窝通信模块中。其中，步骤S3015的执行过程和原理可以参阅图4中的步骤S407部分的相关内容。第一设备执行步骤S3016，第一设备的分布式蜂窝通信模块将蜂窝通信业务的请求通过HIDL接口的Server端，发送到第一设备的Modem，由第一设备的Modem对蜂窝通信业务的请求进行处理，得到蜂窝通信业务的请求对应的响应数据。其中，处理后的蜂窝通信业务的请求能够区别出请求所属的调用方。步骤S3016的执行过程和原理可参阅图4中的步骤S409至步骤S411、图6a示出的步骤S602至步骤S603、以及下述表一的相关内容。第二设备的蜂窝通信业务的请求在图3a的系统中的传输路径可以如图3a中的实线箭头所示。
在一些实施例中，第一设备和第二设备下发的也可以是除了蜂窝通信业务的请求之外的其他请求，本申请实施例中对于请求的格式、内容等不做任何限制。在另一些实施例中，第一设备或者第二设备的调用方可以是除了电话管理器外的其他的调用方，例如IP多媒体 子系统(IP Multimedia Subsystem，IMS)应用，也可以作为调用方，调用接口代理模块3011A，而IP多媒体子系统下发的请求在请求的处理系统300中的传输过程，可参考电话管理器3012下发的请求在请求的处理系统300中的传输过程，此处不再赘述。上层应用(即应用程序层和应用程序框架层)调用分布式蜂窝通信模块的方式有很多，本申请实施例对此不做限定。
在一些实施例中，如图3c所示，第一设备的蜂窝通信业务的请求在图3a的系统中的处理过程可以是：第一设备执行步骤S3021，触发蜂窝通信业务的请求。然后执行步骤S3022，第一设备将蜂窝通信业务的请求发送到本地的电话管理器中，在步骤S3023中，第一设备的电话管理器作为调用方，调用第一设备的接口代理模块，将蜂窝通信业务的请求发送到第一设备的分布式蜂窝通信模块。其中，第一设备的接口代理模块预先创建了请求接口的代理对象，即代理了第一设备的HIDL接口的Client端向HIDL接口的Server端调用的接口，也可以认为是第一设备的Client端的请求接口。其中，步骤S3021至步骤S3023的执行过程和原理可以参阅图4示出的步骤S404和步骤S408的相关内容。在步骤S3024中，第一设备的分布式蜂窝通信模块对蜂窝通信业务的请求中的serial参数进行偏移处理，其中，请求中的偏移处理后的serial参数能够说明请求对应的调用方。其中，步骤S3024的执行过程和原理可以参阅图4中的步骤S409，在另一种实施例中，第一设备的分布式蜂窝通信模块也可以是通过请求中的自定义参数或字段来区分请求所属的调用方，具体可以参阅图6a中的步骤S601的相关内容。第一设备执行步骤S3025，第一设备的分布式蜂窝通信模块将蜂窝通信业务的请求通过HIDL接口的Server端，发送到第一设备的Modem，由第一设备的Modem对蜂窝通信业务的请求进行处理，得到蜂窝通信业务的请求对应的响应数据。其中，步骤S3025的执行过程和原理可以参阅图4中的步骤S410至步骤S411，以及图6a的步骤S602至步骤S603的相关内容。
举例说明，第一设备下发的蜂窝通信业务的请求在请求的处理系统300中的传输过程如图3a示出的实线的箭头所示，具体可以参考第二设备的调用过程，区别在于，第一设备下发的蜂窝通信业务的请求不需要经过分布式总线发送至分布式蜂窝通信模块3022。
在一些实施例中，如图3d所示，第一设备的Modem处理得到第二设备的蜂窝通信业务的请求对应的响应数据，以及第一设备的蜂窝通信业务的请求对应的响应数据之后，请求对应的响应数据在图3a的系统中的处理过程可以是：步骤S3031中，第一设备的Modem通过HIDL接口的Server端，将每一个请求对应的响应数据回调至第一设备的接口代理模块。其中，第一设备的接口代理模块预先创建了响应接口的代理对象，即代理了HIDL接口的Server端向HIDL接口的Client端回调的接口，也可以认为是Client端的响应接口。步骤S3031的执行过程和原理具体可以是参阅图4中的S412，以及图6a的步骤S604的相关内容。在步骤S3032中，针对每一个请求对应的响应数据，第一设备的分布式蜂窝通信模块根据请求对应的响应数据中的偏移处理后的serial参数，识别请求对应的响应数据所属的调用方。其中，步骤S3032的执行过程和原理具体可以是参阅图6a的步骤S605、图4的S413、以及表一的相关内容。其中，若识别出请求对应的响应数据所属的调用方属于第二设备，则执行步骤S3033，若识别出请求对应的响应数据所属的调用方在第一设备，则执行步骤S3034。在步骤S3033中，第一设备的分布式蜂窝通信模块对请求对应的响应数 据中的偏移处理后的serial参数，进行还原处理，然后将请求对应的响应数据，发送至第二设备的分布式蜂窝通信模块，由第二设备的分布式蜂窝通信模块将请求对应的响应数据返回至第二设备的电话管理器。在步骤S3034中，第一设备的分布式蜂窝通信模块对请求对应的响应数据中的偏移处理后的serial参数，进行还原处理，然后将请求对应的响应数据，返回至第一设备的电话管理器。其中，步骤S3033至步骤S3034的执行过程和原理具体可以参阅图4中的步骤S414至步骤S418、以及图6a的步骤S606的相关内容。
举例说明，第二设备和第一设备的请求对应的响应数据的传输路径可以如图3a中的虚线的箭头所示：步骤S3031中，第一设备的Modem3021通过HIDL接口的Server端，将每一个请求对应的响应数据回调至第一设备的接口代理模块3022A。在步骤S3032中，针对每一个请求对应的响应数据，第一设备的分布式蜂窝通信模块3022根据请求对应的响应数据中的偏移处理后的serial参数，识别请求对应的响应数据所属的调用方。在步骤S3033中，第一设备的分布式蜂窝通信模块3022对请求对应的响应数据中的偏移处理后的serial参数，进行还原处理，然后将请求对应的响应数据，发送至第二设备的分布式蜂窝通信模块3011，由第二设备的分布式蜂窝通信模块3011将请求对应的响应数据返回至第二设备的电话管理器3012，电话管理器3012再将请求对应的响应数据返回至短信息应用。在步骤S3034中，第一设备的分布式蜂窝通信模块3022对请求对应的响应数据中的偏移处理后的serial参数，进行还原处理，然后将请求对应的响应数据，返回至第一设备的电话管理器3023，第一设备的电话管理器3023再将请求对应的响应数据返回至短信息应用。
需要说明的是，第二设备的分布式总线3013和第一设备的分布式总线3024之间建立通信连接的形式有很多，可以通过有线的形式建立通信连接，还可以通过无线的形式建立通信连接，第二设备和第一设备之间建立通信连接的方式的不同并不影响本申请实施例的实现。
还需要说明的是，第二设备的通知的传输过程可以与第二设备的响应数据的传输过程一致，第一设备的通知的传输过程也可以与第一设备的响应数据的传输过程一致，此处不再赘述。
本申请提供的这个实施例中，第一设备和第二设备可以通过设立接口代理的方式，对调用方发送的请求进行处理，例如进行偏移serial值，从而区别不同的调用方。这种方式的好处在于，第一设备不需要针对多个调用方分别设置不同的接口，从而有效节省资源。
其中，图3a中电话管理器内部处理请求和响应数据的过程可参见图1a中的电话管理器的相关部分，此处不再赘述。
基于图3a示出的请求的处理系统，下面将具体结合图4阐述本申请的实施例中第二设备和第一设备之间的请求的处理过程。
参阅图4，以第二设备和第一设备均为Android操作系统的电子设备为例，其中第二设备为蜂窝通信能力的需求方(或者说使用方)，第一设备为蜂窝通信能力的提供方，该请求的处理方法具体可以包括以下步骤：
S401、第二设备向第一设备发送套接字(socket)连接请求。
其中，socket连接请求中携带有用于说明第二设备的每一个调用方的信息。在第二设 备和第一设备共享第一设备的Modem的准备阶段，第二设备和第一设备之间首先需要建立连接关系，因此第二设备向第一设备发送socket连接请求。第二设备的调用方用于下发请求。调用方所下发的请求可以是需要Modem进行处理的请求。
在一些实施例中，第二设备将需要第一设备的Modem处理请求的调用方的信息，携带在socket连接请求中，发送到第一设备。调用方可以是图3a中的电话管理器3012，也可以是IMS等。例如，第二设备内有两个电话管理器，第二设备需要让第一设备的Modem处理第二设备中的两个电话管理器下发的请求，因此在向第一设备发送socket连接请求时携带两个电话管理器的信息。
在一些实施例中，用于说明第二设备的每一个调用方的信息可以是第二设备中的每一个调用方的地址、名称等调用方所特有的信息。
若想建立第二设备和第一设备之间的socket连接，至少需要一对socket，其中一个socket运行于第二设备(即蜂窝通信能力的使用方)，另一个运行于第一设备(即蜂窝通信能力的提供方)。
在一些实施例中，可以是第二设备的分布式蜂窝通信模块使用第二设备的socket向第一设备的分布式蜂窝通信模块提出socket连接请求。socket连接请求中描述了要连接的第一设备的套接字，指出第一设备的套接字的地址和端口号，socket连接请求也描述了第二设备自身的套接字。其中，第二设备的分布式蜂窝通信模块可以如图3a中的所示。
第二设备创建Socket连接请求时，可以指定使用的协议，例如发送控制协议(Transmission Control Protocol，TCP)、用户数据报协议(User Datagram Protocol，UDP)等。
在一些实施例中，在执行步骤S401之前，还可以包括：第一设备开启蜂窝通信能力共享功能，第二设备查询网络中开启蜂窝通信能力共享功能的设备，然后可从查询出的所有开启蜂窝通信能力共享功能的设备中，选取出第一设备，进而第二设备再执行步骤S401。在一些实施例中，第一设备可以响应于用户的操作，开启蜂窝通信能力共享功能。例如，第一设备可以通过第一设备的分布式蜂窝通信模块开启蜂窝通信能力共享功能。其中，第一设备的分布式蜂窝通信模块可以如图3a示出的分布式蜂窝通信模块3022所示，设置于第一设备的应用程序框架层。在另一些实施例中，第一设备开启蜂窝通信能力共享功能可以由第一设备中的一个或多个模块配合执行。
当第一设备开启蜂窝通信能力共享功能时，第一设备处于可被其他设备发现的状态，其他设备发现第一设备时可知道第一设备当前的蜂窝通信能力共享功能是开启的，能够被其他设备共享使用，进而第二设备可以发现第一设备，并向第一设备发送socket连接请求。
而使第一设备处于可被其他设备发现的状态的方式由很多，例如第一设备开启蓝牙可被开启蓝牙功能的其他设备发现、接入局域网可被局域网内的其他设备发现、接入近场网络(例如无线网络)可被近场网络中的其他设备发现、登录账号可被该账号下的其他设备发现等等。
S402、第一设备响应于socket连接请求，与第二设备建立连接，并向第二设备返回每一个调用方对应的标识。
响应于socket连接请求，向socket连接请求中所说明的每一个调用方分配调用方对应的标识。其中，调用方对应的标识是调用方唯一的，特有的。在一些实施例中，标识可以 是标识号。例如，socket连接请求中携带有两个电话管理器的信息。第一设备向其中一个电话管理器分配标识号为1，向另一个电话管理器分配标识号为2。需要说明的是，标识的格式、内容本申请实施例不限制。且第一设备向调用方分配标识的规则可以任意设定，本申请实施例不做限制。
在一些实施例中，第一设备还预先分配好了第一设备中的每一个调用方对应的标识。而第一设备为每一个调用方(不论是属于第二设备的还是第一设备的)所分配的标识都是特有的。例如，第一设备内有一个电话管理器，第二设备内有两个电话管理器，第一设备分配给第一设备的电话管理器的标识号为1，第二设备分配给第二设备的一个电话管理器的标识号为2，另一个电话管理器的标识号为3。
在一些实施例中，可以是第一设备的分布式蜂窝通信模块接收第二设备发送的socket连接请求之后，响应socket连接请求，然后进行一些对连接请求鉴权的操作，鉴权通过后与第二设备的分布式蜂窝通信模块建立连接。在一些实施例中，第一设备的分布式蜂窝通信模块与第二设备的分布式蜂窝通信模块可以通过分布式总线建立连接，建立连接之后，分布式总线可以维持连接通道不断开。分布式总线还可以处于低功耗待机机制，仅在需要分布式总线进行发送工作时处于工作状态，其他时刻处于低功耗的待机状态。示例性的，第二设备的分布式蜂窝通信模块和第一设备的分布式蜂窝通信模块可以通过如图3a示出的分布式总线3013和分布式总线3024建立连接。
与第二设备建立连接之后，第二设备和第一设备之间则可以实现通信，第一设备则可以将为第二设备分配的每一个调用方对应的标识，通过分布式总线返回到第二设备中。
需要说明的是，步骤S401至步骤S402仅仅是建立第二设备和第一设备之间的连接的一种实施方式，建立第二设备和第一设备之间的连接的具体方式的不同不影响本申请实施例的实现。
还需要说明的是，第二设备向第一设备发送用于说明第二设备的每一个调用方的信息的方式有很多，在另一些实施例中，也可以是第二设备向第一设备发送蜂窝通信能力共享请求时，将用于说明第二设备的每一个调用方的信息携带在蜂窝通信能力共享请求中发送给第一设备，第一设备响应于蜂窝通信能力共享请求，再为第二设备的每一个调用方分别分配调用方对应的标识，然后再将每一个调用方对应的标识返回到第二设备。也可以是第二设备在第二设备和第一设备建立连接之后，再将用于说明第二设备的每一个调用方的信息发送给第一设备，由第一设备为第二设备的每一个调用方分配标识，第一设备再返回每一个调用方对应的标识给第二设备。
第一设备向第二设备返回第二设备的每一个调用方对应的标识的方式有很多，本申请实施例对第一设备向第二设备返回第二设备的每一个调用方对应的标识的方式不做限制。
S403、第二设备创建第二设备的HIDL接口的Client端的代理对象。
在一些实施例中，第二设备的HIDL接口的Client端的代理对象用于接收第二设备的调用方的请求，将请求转发至第一设备。
具体的，执行步骤S403的过程可以是：基于前述提及的代理模式的技术，创建面向HIDL接口的Client端的代理对象。在一些实施例中，HIDL接口的Client端可以是RIL接口的Client端。创建的HIDL接口的Client端的代理对象具备原生的HIDL接口的Client 端的所有功能，且扩展了其他的功能，通过在创建面向第二设备的HIDL接口的Client端的代理对象时，扩展额外的功能操作的方式，可以实现让第二设备的HIDL接口的Client端的代理对象能够将第二设备本地的调用方的请求，转发至第一设备。示例性的，可以实现让第二设备的HIDL接口的Client端的代理对象将第二设备本地的调用方的请求，转发至第一设备的分布式蜂窝通信模块。
需要说明的是，有关代理模式的具体原理介绍可参见上述提及到的代理模式的相关部分，此处不再赘述。有关原生的HIDL接口的Client端的功能的详细介绍，可参见上述提及的应用侧下发请求给Modem处理的方案的相关部分，此处不再赘述。
在一些实施例中，第二设备通过接口代理模块创建面向第二设备的HIDL接口的Client端的代理对象，其中，接口代理模块可以为图3a中的接口代理模块3022A。
第二设备创建面向第二设备的HIDL接口的Client端的代理对象之后，即可代理第二设备的HIDL接口的Client端。进而当第二设备的调用方下发请求时，下发的请求都会由第二设备的HIDL接口的Client端的代理对象接收，然后再转发到第一设备，进而再通过第一设备的Modem进行处理，让第二设备具有能够使用第一设备的蜂窝通信能力的基础配置。
在一些实施例中，创建第二设备的HIDL接口的Client端的代理对象，可以理解为是创建第二设备的请求接口的代理对象。其中，第二设备的请求接口为第二设备的HIDL接口的Client端向HIDL接口的Server端调用的接口。
第二设备中可以有多个调用方，也可以仅有一个调用方，且第二设备的多个调用方所属的操作系统可以相同，也可以不同，本申请实施例中对此不做限制。
当第二设备内有多个调用方时，执行步骤S403时，可以是创建每一个调用方对应的HIDL接口的Client端的代理对象，即可以代理所有调用方对应的HIDL接口的Client端。
在一些实施例中，可以更改第二设备的调用方调用HIDL接口的Client端的实例为步骤S403所创建的第二设备的HIDL接口的Client端的代理对象，进而使得后续在执行步骤S403之后的请求的处理过程中，调用方可以不调用原生的HIDL接口的Client端，而是调用步骤S403所创建的第二设备的HIDL接口的Client端的代理对象。
需要说明的是，步骤S403中第二设备所代理的接口的类型和具体方式不做限定，第一设备除了可以创建HIDL接口的Client端的代理对象，也可以创建其他类型接口的Client端的代理对象。
S404、第一设备创建第一设备的HIDL接口的Client端的代理对象。
其中，第一设备的HIDL接口的Client端的代理对象用于接收第一设备的调用方的请求，并将第一设备的调用方的请求发送到第一设备的HIDL接口的Server端，还用于接收第一设备的HIDL接口的Server端回调的请求对应的响应数据。第一设备的HIDL接口的Server端回调的请求对应的响应数据既包括有属于第一设备的调用方的，也包括有属于第二设备的调用方的，即所有调用方的请求对应的响应数据，都通过第一设备的HIDL接口的Server端，回调给了第一设备的HIDL接口的Client端的代理对象。
其中，第一设备中可以有多个调用方，也可以仅有一个调用方，且第一设备的多个调用方所属的操作系统可以相同，也可以不同，本申请实施例中对调用方的数量，以及调用 方所属的操作系统等可以不做限制。当第一设备内有多个调用方时，执行步骤S404时，可以是创建第一设备中的每一个调用方对应的HIDL接口的Client端的代理对象，即可以代理第一设备中所有调用方对应的HIDL接口的Client端。
需要说明的是，步骤S404中第一设备所代理的接口的类型和具体方式不做限定，第一设备除了可以创建HIDL接口的Client端的代理对象，也可以创建其他类型接口的Client端的代理对象。
具体的，执行步骤S404的过程可以是，基于代理模式这一设计模式，创建面向第一设备的HIDL接口的Client端的代理对象。在一些实施例中，HIDL接口的Client端可以是RIL接口的Client端。创建的第一设备的HIDL接口的Client端的代理对象，具备第一设备原生的HIDL接口的Client端的功能，且可以扩展其他的功能。
需要说明的是，有关代理模式的具体原理介绍可参见上述提及到的代理模式的相关部分，此处不再赘述。有关原生的HIDL接口的Client端的功能的详细介绍，可参见上述提及的应用侧下发请求给Modem处理的方案的相关部分，此处不再赘述。
在一些实施例中，创建第一设备的HIDL接口的Client端的代理对象，可以理解为是创建第一设备的请求接口的代理对象和响应接口的代理对象。具体的，HIDL接口的Client端是异步调用处理，即Client端接收请求的接口与接收响应数据的接口不是同一个接口，因此执行步骤S404时，可以是分别创建第一设备的请求接口的代理对象和响应接口的代理对象。其中，第一设备的请求接口为第一设备的HIDL接口的Client端向HIDL接口的Server端调用的接口。第一设备的请求接口为第一设备的响应接口为第一设备的HIDL接口的Server端向HIDL接口的Client端回调的接口。
在一些实施例中，可以更改第一设备的调用方调用HIDL接口的Client端的实例为步骤S404所创建的第一设备的HIDL接口的Client端的代理对象，进而使得后续在执行步骤S404之后的请求的处理过程中，调用方可以不调用原生的HIDL接口的Client端，而是调用步骤S404所创建的第一设备的HIDL接口的Client端的代理对象。
在一些实施例中，可以是通过接口代理模块执行步骤S404。接口代理模块可以如图3a示出的接口代理模块3022A所示。
在一些实施例中，步骤S403和步骤S404都可以通过接口代理模块执行，即接口代理模块中可以创建第一设备和第二设备中的所有的调用方对应的HIDL接口的Client端，代理第一设备和第二设备中的所有HIDL接口的Client端。进而接口代理模块通过执行步骤S403和步骤S404，可以实现接收所有的调用方的请求，并仅通过第一设备的一个HIDL接口的Server端发送给Modem，还实现接收该第一设备的HIDL接口的Server端所发送的所有调用方的请求对应的响应数据。
在一些实施例中，接口代理模块可以部分设置于第一设备的应用框架层，部分设置于第二设备的应用框架层中。示例性的，接口代理模块可以包括如图3a示出的接口代理模块3011A和接口代理模块3022A。
在一些实施例中，第一设备的代理对象的创建时机可以有多种方式。例如，步骤S404也可以是在执行步骤S402之后自动触发创建的，也可以在出厂前就预设置代理对象。本申请实施例对此不做限定。
需要说明的是，触发执行步骤S403和步骤S404的方式有很多，本申请实施例对此不做限制。
由上述内容可知，通过步骤S403和步骤S404创建所有第一设备和第二设备的HIDL接口的Client端的代理对象，能够实现支持仅通过一个第一设备的HIDL接口的Server端，处理所有的请求，以及请求对应的响应数据，即支持多个调用方对应的HIDL接口的client端，调用同一个HIDL接口的Server端。
可以理解的是，步骤S401至步骤S404相当于是为了满足在蜂窝通信共享的场景下，具有使用一个HIDL接口的Server端处理所有调用方下发的请求的需求时，第一设备和第二设备需要配合执行的配置工作。通过步骤S401至步骤S404，第二设备具有了第一设备的所有的蜂窝通信能力。后续在每一个请求的处理过程中，都不需要重复执行前述步骤S401至步骤S404。
例如图5a所示，当第二设备为笔记本电脑，第一设备为手机时，手机连接WIFI后，界面展示WIFI图标50，笔记本电脑连接WIFI后，界面展示WIFI图标51。手机和笔记本电脑通过接入同一个WIFI建立连接，然后在手机和笔记本电脑配合执行完成步骤S401至步骤S404之后，手机上的SIM卡1的5G信号状态和SIM卡2的5G信号状态都共享给了笔记本电脑，手机上的SIM卡1的5G信号状态图标52和SIM卡2的5G信号状态图标53上展示的信号状态，与笔记本电脑上的5G信号状态图标54和5G信号状态图标55上展示的信号状态一致，笔记本电脑能同步获取手机上的信号状态。
需要说明的是，步骤S401至步骤S404仅仅是实现将多个调用方的请求通过第一设备的单个HIDL接口的Server端进行处理的一种配置方式，还存在有其他配置方式可以实现，配置方式的不同不影响本申请实施例的实现。
S405、第二设备的调用方调用第二设备的HIDL接口的Client端的代理对象，向第二设备的HIDL接口的Client端的代理对象下发调用方的请求。
其中，调用方的请求中携带有调用方的标识，用于说明请求所属的调用方。该调用方的标识由第一设备为第二设备的调用方进行分配得到，具体可参见前述步骤S402中提及的相关内容，此处不再赘述。
具体的，第二设备的调用方调用与该调用方对应的HIDL接口的Client端的代理对象，向调用方对应的HIDL接口的Client端的代理对象传入调用方的请求。由于步骤S403中，预先创建好了第二设备的HIDL接口的Client端的代理对象，因此第二设备的任一调用方下发请求时，都可以将请求发送到第二设备的HIDL接口的Client端的代理对象中，即第二设备的HIDL接口的Client端的代理对象接收了第二设备的所有调用方下发的请求。其中，调用方的标识可以是携带在调用方的请求中，也可以是单独传入HIDL接口的Client端的代理对象。调用方的请求的触发方式、生成方式、具体请求类型、数量、内容等可以参考安卓或者IOS等操作系统的规定，本申请实施例对此不做限定。
在一些实施例中，若通过接口代理模块执行了步骤S403，则执行步骤S405的一种实施方式为：第二设备的调用方调用接口代理模块，向接口代理模块下发调用方的请求。
在一些实施例中，调用方可以是图3a示出的电话管理器3012，如图3a所示，执行步骤S405的一种方式可以是：电话管理器3012调用接口代理模块3011A，向接口代理模块 3011A下发短信息发送请求。
S406、第二设备根据调用方的标识，将调用方的请求中的serial参数偏移与调用方对应的偏移值，以使得请求中的处理后的serial参数可用于说明请求所属的调用方。
具体的，步骤S405中通过第二设备的HIDL接口的Client端的代理对象所接收到的请求中，具有serial参数，serial参数代表着调用方发送请求的次数，针对每一个调用方的请求，请求中的serial参数，与请求对应的响应数据中的serial参数是一致的，由此调用方可以通过serial参数确定收到的响应数据是对应于哪一个请求的。针对每一个调用方，调用方每下发一次调用方的请求，调用方的请求中的serial参数相较于上一次下发的请求中的serial参数加一，即调用方的请求中的serial参数能够说明调用方下发请求的次数。举例说明，如图3a所示，第二设备的调用方为电话管理器3012时，电话管理器3012第一次下发的请求中serial参数为1，第二次下发的请求中serial参数变为2……以此类推，电话管理器3012下发的请求中的serial参数，能够反映出是电话管理器3012第几次下发的请求。
其中，步骤S406中提及的请求中的处理后的serial参数，指的是进行偏移处理后的serial参数。通过执行步骤S406的处理，步骤S405中所有的调用方的请求就能够通过处理后的serial参数识别出该请求所属的调用方。例如，如果第二设备内有两个电话管理器，这两个电话管理器的请求在经过步骤S406的处理之后，可以通过读取处理后的serial参数，识别出请求所属的调用方是哪一个电话管理器。需要说明的是，进过步骤S406处理之后的第一设备的调用方的请求，在下述步骤中被第一设备的Modem处理之后，该调用方请求对应的响应数据中，仍然还会携带有与步骤S406中一致的serial参数，因此在经过步骤S406的处理之后，后续得到的调用方请求对应的响应数据中，同样也可以识别出所属的调用方。
在一些实施例中，可以预先设置好所有调用方的标识与调用方对应的偏移值之间的列表，以使得不同调用方对应的偏移值互不相同，不同调用方的请求中serial参数的取值范围也互不重合。所有的调用方的标识与调用方对应的偏移值之间的列表可以预先存储到第二设备和第一设备内。其中，所有的调用方既包括了第二设备的调用方也包括了第一设备的调用方。当第二设备的HIDL接口的Client端的代理对象接收到调用方的请求时，则利用该请求所属的调用方的标识，在列表中查找调用方对应的偏移值，然后再将调用方的请求中的serial参数偏移与调用方对应的偏移值。由于在进行偏移处理后，不同的调用方的请求中的serial参数所属的取值范围是不同的，每一个serial参数的取值范围对应一个调用方，因此请求中的处理后的serial参数可用于说明请求所属的调用方。
示例性的，可以通过处理后的serial参数的取值范围来说明请求所属的调用方。例如下述表一所示，调用方的标识与调用方对应的偏移值之间的关系可以设定为：当调用方的标识(Client Id)为1时，设定其对应的serial参数的取值范围为：0至offset value-1，当Client Id为2时，设定其对应的serial参数的取值范围为offset value至2*offset value-1，当Client Id为N时，设定其对应的serial参数的取值范围为：(N-1)*offset value到N*offset value–1。即当调用方的的标识为N时，其对应的请求中的serial参数需偏移(N-1)*offset value。其中，offset value是预设值，例如offset value可以预设为10000000。
表一
Figure PCTCN2022092926-appb-000001
举例说明，第一设备内有一个电话管理器，它的调用方的标识被分配为是1，而第二设备有两个电话管理器，被第一设备分配的调用方的标识分别是2和3。当offset value为10000000时，Client Id为1的电话管理器对应的serial参数的取值范围是0到9999999，即Client Id为1的电话管理器下发的请求的serial参数所需偏移的偏移值为0，而Client Id为2的电话管理器对应的取值范围是10000000到19999999，即Client Id为2的电话管理器下发的请求的serial参数所需偏移的偏移值为10000000，Client Id为3的电话管理器对应的取值范围是20000000到19999999，即Client Id为3的电话管理器下发的请求的serial参数所需偏移的偏移值为20000000。由此可以看出，不同调用方的标识所对应的偏移值是不同的，进而导致不同调用方下发的请求，在经过步骤S406的处理之后，可以使得请求中的处理后的serial参数能够说明请求所属的调用方。
需要说明的是，调用方的标识与调用方对应的偏移值之间的对应关系可以自由设定，只需使得调用方的请求中的serial参数偏移与调用方对应的偏移值之后，能够通过请求中的处理后的serial参数说明请求所属的调用方即可。调用方对应的偏移值的设定规则的不同，也不影响本申请实施例的实现。
还需要说明的是，根据调用方的标识，对请求中的serial参数进行处理的方式有很多，除了通过偏移处理的方式之外，还可以通过其他的运算规则对serial参数进行其他的计算处理，对调用方的请求中的serial参数的处理方式的不同并不影响本申请实施例的实现，只需使得请求中的处理后的serial参数可用于说明请求所属的调用方即可。
在一些实施例中，可以通过接口代理模块执行步骤S406。示例性的，可以基于前述代理模式的技术基础，在执行步骤S403时，对接口代理模块所创建的第二设备的HIDL接口的Client端的代理对象，扩展额外的功能，以使得第二设备的HIDL接口的Client端的代理对象在接收到第二设备的调用方的请求时，可以执行步骤S406。其中，执行步骤S406的接口代理模块可以是如图3a中的接口代理模块3011A。
S407、第二设备将第二设备的调用方的请求，转发至第一设备。
由步骤S403的相关内容可知，第二设备所创建的第二设备的HIDL接口的Client端的 代理对象，能够实现将接收到的所有调用方的请求，转发至第一设备，因此，第二设备能够通过第二设备的HIDL接口的Client端的代理对象，执行步骤S407。其中，步骤S407中转发的调用方的请求，是经过步骤S406处理之后的请求，即步骤S407中转发的请求中的serial参数是可用于说明请求所属的调用方的。
在一些实施例中，可以是第二设备的分布式蜂窝通信模块将第二设备的调用方的请求，转发至第一设备的分布式蜂窝通信模块。示例性的，可以是通过第二设备的分布式蜂窝通信模块中的接口代理模块，将调用方的请求，转发至第一设备的接口代理模块。具体可参见图3a中的相关描述，此处不再赘述。
S408、第一设备的调用方调用第一设备的HIDL接口的Client端的代理对象，向第一设备的HIDL接口的Client端的代理对象下发调用方的请求。
由于步骤S404中预先创建了第一设备的HIDL接口的Client端的代理对象，因此能够通过第一设备的HIDL接口的Client端的代理对象执行步骤S408。
其中，第一设备执行步骤S408的执行过程和原理可以参考第二设备执行步骤S405的相关内容，此处不再赘述。
需要说明的是，第一设备执行步骤S408与第二设备执行的步骤S405之间不存在执行先后顺序的限制，步骤S408与步骤S405的执行之间互不干涉。
第一设备执行步骤S408的过程，具体可以参阅图1a中的电话管理器处理请求的过程的相关内容。
S409、第一设备根据调用方的标识，将调用方的请求中的serial参数偏移与调用方对应的偏移值，以使得请求中的处理后的serial参数可用于说明请求所属的调用方。
在一些实施例中，步骤S409中第一设备所处理的请求仅是来自第一设备的调用方的请求，具体的执行原理和过程，可以参考第二设备执行步骤S406的相关内容。
在另一些实施例中，步骤S409中第一设备所处理的请求可以是第一设备和第二设备的调用方的请求，即所有请求的serial参数的偏移处理可以都通过步骤S409完成。具体的，第二设备可以不执行步骤S406，第二设备在通过步骤S407将请求转发到步骤S409之后，再由第一设备进行处理。其中，第一设备接收到的来自第二设备的请求中需携带有调用方的标识，进而才可执行步骤S409。
S410、第一设备将每一个调用方的请求，通过第一设备的HIDL接口的Server端发送到第一设备的Modem。
其中，步骤S410中的每一个调用方的请求，既包括有步骤S407中第二设备转发到第一设备的请求，也包括了步骤S408中的第一设备的调用方下发的请求，即所有调用方的请求，都是通过第一设备的同一个HIDL接口的Server端发送到第一设备的Modem。
需要说明的是，步骤S410中发送到第一设备的Modem的请求中的serial参数都是经过偏移处理后的，都能够说明请求所属的调用方。
在一些实施例中，可以是通过接口代理模块将每一个调用方的请求，通过调用第一设备的HIDL接口的Server端，发送到第一设备的Modem中。在另一些实施例中，可以是通过第一设备的HIDL接口的Client端的代理对象，将第一设备的调用方的请求发送到第一设备的HIDL接口的Server端。而第二设备的调用方的请求则可以直接通过第二设备的分 布式蜂窝通信模块透传到第一设备的HIDL接口的Server端。第二设备的接口代理模块可以参见图3a中的接口代理模块3022A。第二设备的分布式蜂窝通信模块可参见图3a中的第二设备的分布式蜂窝通信模块3022。
S411、第一设备的Modem处理得到每一个请求对应的响应数据。
针对每一个请求，请求对应的响应数据可以理解为是请求对应的响应结果，请求对应的响应数据，和请求之间是一一对应的。举例说明，例如请求为短信发送请求，那么该请求对应的响应数据可以是用于说明短信是否发送成功的结果数据。其中，Modem处理后的请求对应的响应数据中依然还携带有serial参数，由前述内容可知，在经过前述步骤的处理，serial参数可用于说明请求所属的调用方，因此，通过请求对应的响应数据中的serial参数也可知道所属的调用方。其中，Modem对请求的处理顺序为Modem接收到请求的顺序。
需要说明的是，请求对应的响应数据的格式和内容具体可以参考安卓或者IOS等操作系统的规定，本申请实施例在此不做限定。
S412、第一设备的Modem通过HIDL接口的Server端，将每一个请求对应的响应数据返回至第一设备的HIDL接口的Client端的代理对象。
通过前述步骤S404中的内容可知，第一设备代理了第一设备的HIDL接口的Client端，因此HIDL接口的Server端可以将每一个请求对应的响应数据回调至第一设备的HIDL接口的Client端的代理对象，即第一设备的HIDL接口的Client端的代理对象接收了所有的请求对应的响应数据。
在一些实施例中，可以是通过第一设备的接口代理模块，接收、第一设备的Modem通过HIDL接口的Server端所返回的每一个请求对应的响应数据。其中，第一设备的接口代理模块可以参见图3a中的接口代理模块3022A。
S413、第一设备针对每一个请求对应的响应数据，根据请求对应的响应数据中的处理后的serial参数，识别请求对应的响应数据所属的调用方。
其中，请求对应的响应数据中的处理后的serial参数其实就是前述步骤中提及的可用于说明请求所属的调用方的serial参数。因此，根据请求对应的响应数据中的处理后的serial参数，能够识别出请求对应的响应数据所属的调用方，进而第一设备就能够知道应该将请求对应的响应数据返回给哪一个调用方，实现让调用方所发送的请求和接收到的响应数据是一一对应的。
在前述的应用侧下发请求给Modem处理的方案的简要介绍中可知，该方案是通过每一个HIDL接口的Server端均固定注册了一个HIDL接口的Client端的方式，来保障请求对应的响应数据能够返回到HIDL接口的Client所对应的调用方。而本申请实施例中，通过请求对应的响应数据中的处理后的serial参数，识别请求对应的响应数据所属的调用方的方式，确保请求对应的响应数据能够返回到发起请求的调用方中，实现使用同一个HIDL接口的Server端来处理请求。
在一些实施例中，第一设备可以通过接口代理模块执行步骤S413。例如图3a示出的接口代理模块3022A所示。示例性的，可以是在第一设备执行步骤S404时，对在接口代理模块3022A上创建的第一设备的HIDL接口的Client端的代理对象，进行额外的功能扩展，以使得第一设备的接口代理模块3022A，能够通过第一设备的HIDL接口的Client端 的代理对象，执行步骤S413。
在一些实施例中，执行步骤S413的一种实施方式，包括：针对每一个请求对应的响应数据，将请求对应的响应数据中的处理后的serial参数，分别与每一个调用方对应的serial参数取值范围进行匹配，并将匹配的调用方确定为请求对应的响应数据所属的调用方。具体的，在前述步骤的一些实施例中，对请求中的serial参数进行了偏移处理，以使得不同调用方的请求所属的取值范围。具体可参见上述表一相关内容，此处不再赘述。由于第一设备内部存有调用方的标识和serial参数的对应关系，因此通过将请求对应的响应数据中的处理后的serial参数，分别与每一个调用方对应的serial参数取值范围进行匹配，即可将匹配到的取值范围对应的调用方，确定为请求对应的响应数据所属的调用方。例如表一所示，如果某个请求对应的响应数据中的处理后的serial参数，匹配了0至offset value-1的范围，那么所属的调用方的标识为1。
在一些实施例中，还可以在识别出请求对应的响应数据所属的调用方之后，将识别结果与请求对应的响应数据进行对应存储。
S414、第一设备将属于第二设备的调用方的响应数据，返回至第二设备。
通过步骤S413的识别，第一设备识别出了部分请求对应的响应数据属于第一设备，部分请求对应的响应数据属于第二设备，能够区分开两个不同设备的请求对应的响应数据，然后从中选出第二设备的调用方的响应数据，返回到第二设备中。
在一些实施例中，可以是第一设备的分布式蜂窝通信模块将第二设备的调用方的响应数据，返回到第二设备的分布式蜂窝通信模块。
S415、第二设备针对第二设备的每一个请求对应的响应数据，将请求对应的响应数据中的处理后的serial参数，进行还原处理。
为了使得调用方能够识别出请求对应的响应数据，需要将在前述步骤中进行处理过的serial参数，进行还原处理。具体的，在前述实施例中进行了偏移了与调用方对应的偏移值的serial参数，此时可以减去偏移值，还原成原本的serial参数。举例说明，如表一所示，调用方的标识为2的serial参数进行了正偏移offset value的处理，因此在步骤S415中，就需要减去原本偏移的offset value，还原为原本的serial参数的值。
在一些实施例中，可以通过接口代理模块执行步骤S415。示例性的，接口代理模块可以如图3a中的接口代理模块3011A所示。
在一些实施例中，当第二设备内部有多个调用方时，在执行步骤S415前，第二设备需执行针对每一个请求对应的响应数据，根据请求对应的响应数据中的处理后的serial参数，识别请求对应的响应数据所属的调用方的步骤，以识别请求对应的响应数据是属于第二设备的哪一个调用方。而第二设备执行该步骤的执行原理和过程，可参考第一设备执行步骤S413的相关内容，在识别出每一个请求对应的响应数据所属的调用方之后，再执行步骤S415。
S416、第二设备将第二设备的每一个响应数据返回至响应数据所属的调用方。
由于步骤S416之前的步骤中，已经识别出了每一个响应数据所属的调用方，因此第二设备在执行步骤S415之后，即可将每一个请求对应的响应数据返回至请求对应的响应数据所属的调用方，实现让调用方发出的请求和接收到的响应数据之间是一一对应的。举例说 明，如图5b所示，当第一设备为手机，第二设备为笔记本电脑时，笔记本电脑中的电话管理器的请求为拨打某一个广东省深圳市的手机号时，当手机将拨打电话的请求对应的响应数据(即正在呼叫的数据)返回到笔记本电脑中，由笔记本电脑的电话管理器返回并展示到笔记本电脑对应的电话应用界面，电话应用界面上会呈现拨打手机号的呼叫状态，即正在呼叫。
在一些实施例中，可以通过第二设备的HIDL接口的Client端的代理对象将第一设备的每一个请求的响应数据返回至请求对应的响应数据所属的调用方。
在一些实施例中，可以是第二设备的分布式蜂窝通信模块执行步骤S416。示例性的，可以参阅图3a中第二设备的分布式蜂窝通信模块3011将请求对应的响应数据返回到电话管理器3012的相关内容。
S417、第一设备针对每一个属于第一设备的调用方的响应数据，将请求对应的响应数据中的处理后的serial参数，进行还原处理。
其中，第一设备执行步骤S417的执行原理和过程，可以参考第二设备执行S415的过程，此处不再赘述。
在一些实施例中，若第二设备中仅有一个调用方，那么第一设备也可以不仅仅是对第一设备的调用方的响应数据进行还原处理，还可以是对第二设备的响应数据也一起进行了还原处理之后，再执行步骤S414，返回到第二设备中。
需要说明的是，步骤S416的执行顺序只需在步骤S413之后执行即可，步骤S414和步骤S415的执行不对步骤S416的执行具有任何影响。
由前述内容可知，无论是第一设备还是第二设备执行对请求对应的响应数据中的处理后的serial参数，进行还原处理时，需保障已经知道响应数据所属的调用方，当前仅当确定了响应数据的调用方之后，才可进行还原处理，在确保已经识别出响应数据所属的调用方之后，执行还原处理的是第一设备还是第二设备可以不做限制。
S418、第一设备将第一设备的每一个请求的响应数据返回至请求对应的响应数据所属的调用方。
由于前述步骤已经识别出了第一设备的每一个响应数据所属的调用方，因此第一设备在执行步骤S417之后，即可将每一个请求对应的响应数据返回至请求对应的响应数据所属的调用方，实现让调用方发出的请求和接收到的响应数据之间是一一对应的。例如图5c所示，当第一设备为手机，第二设备为电脑时，手机本地的视频APP触发一键登录请求，手机的电话管理器下发一键登录请求之后，电话管理器又收到了一键登录请求对应的响应数据，响应数据为一键登录成功，电话管理器一键登录成功的数据展示到了视频APP界面。
在一些实施例中，可以通过第一设备的HIDL接口的Client端的代理对象将第一设备的每一个请求的响应数据返回至请求对应的响应数据所属的调用方。
在一些实施例中，可以是第一设备的分布式蜂窝通信模块执行步骤S415。示例性的，可以参阅图3a中第一设备的分布式蜂窝通信模块3022将请求对应的响应数据返回到电话管理器3023的相关内容。
需要说明的是，第二设备的通知的传输过程可以与第二设备的响应数据的传输过程一 致，第一设备的通知的传输过程也可以与第一设备的响应数据的传输过程一致，此处不再赘述。
在本申请实施例中，用于说明请求所属的调用方的信息是处理后的serial参数，在其他实施例中，也可以是调用方的标识等其他类型的信息，对此本申请实施例不做限制，只需发送到第一设备的HIDL接口的Server端的请求中，能够携带有用于说明请求所属的调用方的信息即可。
同样的，步骤S412至步骤S418也仅仅是实现通过识别每一个请求对应的响应数据所属的调用方，将每一个请求对应的响应数据返回至响应数据所属的调用方的一种实施方式，携带有用于说明请求所属的调用方的信息的类型的不同，实现识别每一个请求对应的响应数据所属的调用方，将每一个请求对应的响应数据返回至响应数据所属的调用方的过程也会相应的不同。
综上所述，参照上述步骤S405至步骤S418的内容，本申请实施例在蜂窝通信能力共享场景下，能够实现让多个不同设备的调用方所下发的请求，都通过同一个设备内的HIDL接口的Server端发送到Modem，又能让所有调用方的响应数据也都通过同一个设备内的HIDL接口的Server端返回到各个调用方中。
在另一些实施例中，参照前述图4的执行原理和过程，本申请实施例还可以适用于第一设备内多操作系统共享使用一个Modem的场景，或者同一个设备的单个操作系统内的多个调用方下发的请求。
可以理解的是，本申请实施例适用于任意的多调用方的请求的处理，多调用方可以属于多个设备，多个系统，也可以属于同一个设备，同一个系统。
更进一步的，参照前述图4的执行原理和过程，也可以在其他的应用场景下，实现将多个不同设备的调用方所下发的请求，都发送到同一个设备内的其他类型的接口的Server端，又再通过该接口的Server端，将所有调用方的响应数据返回到各个调用方中。即本申请实施例也可适用于其他的需要让多个调用方的请求都通过一个接口的Server端进行处理的场景，包括但不限于本申请实施例所示例的蜂窝通信能力共享场景。
还需要说明的是，不同调用方下发请求的时间都可以是任意的，多个调用可以同时下发请求，也可以各自在任意时间下发请求，调用方下发请求的时间的不同并不影响本申请实施例的实现。
在一些实施例中，还可以通过在第一设备中的HIDL接口的Client端中预设置了用于支持接收每一个调用方的标识的字段，HIDL接口的Server端中也预设置了用于支持接收每一个调用方的标识的字段的方式，来执行请求的处理方法，具体的，参阅图6a，本申请提出了另一种请求的处理方法，应用于第一设备，具体可以包括以下步骤：
S601、通过HIDL接口的Client端，接收多个调用方的请求。
其中，调用方的请求中携带有调用方的标识。HIDL接口的Client端中预设置了用于支持接收每一个调用方的标识的字段。例如，HIDL接口的Client端内增加了ClientIndex字段，实现支持接收每一个调用方Client的标识。
当调用方的请求中携带有请求所属的调用方的标识传入HIDL接口的Client端时，由于HIDL接口的Client端预设置了用于支持接收每一个调用方的标识的字段，因此支持对携带有调用方的标识的请求进行后续的处理。
S602、将多个调用方的请求，通过HIDL接口的Server端发送到第一设备的Modem。
其中，调用方的请求中携带有调用方的标识。HIDL接口的Server端中预设置了用于支持接收每一个调用方的标识的字段。例如，HIDL接口的Server端内增加了ClientIndex字段，实现支持接收每一个调用方Client的标识。由于HIDL接口的Server端支持接收每一个调用方的标识，因此能够通过HIDL接口的Server端执行步骤S602。
执行步骤S602的过程和原理，可以参考第一设备执行图4中的步骤S410的相关内容，此处不再赘述。
S603、第一设备的Modem处理得到每一个请求对应的响应数据。
执行步骤S603的过程和原理，可以参考第一设备执行图4中的步骤S411的相关内容，此处不再赘述。
S604、第一设备的Modem通过第一设备的HIDL接口的Server端，将每一个请求对应的响应数据返回至第一设备的HIDL接口的Client端。
执行步骤S604的过程和原理，可以参考第一设备执行图4中的步骤S412的相关内容，但区别于步骤S412，步骤S604中每一个请求对应的响应数据，是返回至第一设备的HIDL接口的Client端，但步骤S412返回的是第一设备的HIDL接口的Client端的代理对象。
S605、针对每一个请求对应的响应数据，根据请求对应的响应数据中携带的调用方的标识，识别每一个请求对应的响应数据所属的调用方。
由于步骤S604中提及的HIDL接口的Server端以及HIDL接口的Client端，都支持接收每一个调用方的标识，因此也能够支持返回至第一设备的HIDL接口的Client端的每一个请求对应的响应数据，都携带有调用方的标识。
进而就可以根据请求对应的响应数据中携带的调用方的标识，识别每一个请求对应的响应数据所属的调用方，实现在多个调用方的情况下，只使用一对HIDL接口的Server端和HIDL接口的Client端，就能够令调用方下发的请求与接收到的响应数据一一对应。
在另一些实施例中，步骤S605可以通过图3a中的接口代理模块执3022A执行。接口代理模块3022A的相关描述可参阅图3a中的接口代理模块3022A相关内容。
S606、针对每一个请求对应的响应数据，将请求对应的响应数据返回至请求对应的响应数据所属的调用方。
其中，步骤S606的执行过程和原理可参考步骤S417，此处不再赘述。
需要说明的是，本申请实施例所提出的请求的处理方法，同样适用于多设备的调用方的请求的处理，在多设备的调用方的请求的处理场景下，第一设备在执行步骤S601时，接收到的多个调用方的请求就来自多个设备，既包括有第一设备本地的，也包括其他第二设备的。
还需要说明的是，第一设备将通知发送至通知所属调用方的过程可以与将响应数据发送至响应数据所属调用方的过程一致，此处不再赘述。
示例性的，以多调用方都在同一个设备为例，如图6b所示，图6b中的第一设备的应用程序框架层上有电话管理器601、电话管理器602、以及电话管理器603这三个调用方，应用程序框架层中还设置有新增的HIDL接口的Client端604，系统库上新增的HIDL接口的Server端605。示例性的，图6b示出的第一设备执行图6a的请求的处理方法的具体过程为：在步骤S601中，电话管理器601的请求601A、电话管理器602的请求602A以及电话管理器603的请求603A都下发到了HIDL接口的Client端604，步骤S602至步骤S603中，多个电话管理器下发的所有的请求又通过HIDL接口的Server端605发送给第一设备的Modem，由第一设备的Modem得到每一个请求对应的响应数据，在步骤S604至步骤S605中，第一设备的Modem将每一个请求对应的响应数据都发送到通过第一设备的HIDL接口的Server端605，第一设备的HIDL接口的Server端605又将每一个请求对应的响应数据返回至第一设备的HIDL接口的Client端604，然后针对每一个请求对应的响应数据，根据请求对应的响应数据中携带的调用方的标识，识别每一个请求对应的响应数据所属的调用方。在步骤S606中，第一设备的HIDL接口的Client端604将属于电话管理器601的请求对应的响应数据601B返回到了电话管理器601，将属于电话管理器602的请求对应的响应数据602B返回到了电话管理器602，将属于电话管理器603的请求对应的响应数据603B返回到了电话管理器603。其中，电话管理器601、电话管理器602以及电话管理器603下发请求的时间都可以是任意的。
需要说明的是，为了描述更为简洁，本申请中涉及的第一设备中的接口(例如HIDL接口)可以统称为第一设备接口，而本申请实施例提及的新增加的(或者说新增的)HIDL接口，也可以简称为HIDL接口。
由上述图4和图6a的相关内容可知，图4中的步骤S401至步骤S404是非必要步骤，例如当多个调用方是同一个电子设备中的，即可不需要建立两个设备之间连接，又例如，当采用图6a执行请求的处理方法，也不需要创建HIDL接口的Client端的代理对象。并且，图4中对serial参数进行偏移，仅仅是使得请求中携带有用于说明请求所属的调用方的信息的一种实施方式，在图6a中，还可以使用调用方的标识作为用于说明请求所属的调用方的信息。因此，请求、以及请求对应的响应数据中携带的用于说明请求所属的调用方的信息的具体格式、内容等有很多，本申请实施例不做限制。
参阅图7，基于上述内容，针对多个不同设备的调用方的请求的处理场景，本申请实施例还公开了一种请求的处理方法，应用于第一设备，具体包括以下步骤：
S701、与第二设备建立连接。
步骤S701的执行过程和原理可参见步骤S401至S402的相关内容，此处不再赘述。
S702、将多个调用方的请求发送到HIDL接口的Server端。
其中，多个调用方，包括：第一设备的调用方和第二设备的多个调用方。请求中携带有用于说明请求所属的调用方的信息。
步骤S702的执行过程和原理可参见步骤S403至步骤S408的相关内容、以及步骤S601至步骤S602的相关内容，此处不再赘述。
S703、接收通过HIDL接口的Server端返回的每一个请求对应的响应数据。
步骤S703的执行过程和原理可参见步骤S412的相关内容以及步骤S604的相关内容，此处不再赘述。其中，步骤S73提及的HIDL接口也可以是其他类型的第一设备接口，本申请对此限制。
S704、针对每一个请求对应的响应数据，根据请求对应的响应数据中携带的用于说明请求所属的调用方的信息，识别每一个请求对应的响应数据所属的调用方。
步骤S704的执行过程和原理可参见步骤S413的相关内容以及步骤S605的相关内容，此处不再赘述。
S705、将属于第二设备的调用方的响应数据，返回至第二设备。
步骤S705的执行过程和原理可参见步骤S414的相关内容，此处不再赘述。
S706、将属于第一设备的调用方的响应数据，返回至响应数据所属的调用方。
步骤S706的执行过程和原理可参见步骤S417至S418的相关内容以及步骤S606的相关内容，此处不再赘述。
参阅图8，基于上述内容，针对多个不同设备的调用方的请求的处理场景，本申请实施例还公开了一种请求的处理方法，应用于第二设备，具体包括以下步骤：
S801、与第一设备建立连接。
步骤S801的执行过程和原理可参见步骤S401至S402的相关内容，此处不再赘述。
S802、将第二设备的调用方的请求，转发至第一设备。
步骤S802的执行过程和原理可参见步骤S403至步骤S407的相关内容，此处不再赘述。
S803、接收第一设备返回的第二设备的调用方的响应数据。
其中，响应数据中携带有所属的调用方的信息。
步骤S803的执行过程和原理可参见步骤S414的相关内容，此处不再赘述。
S804、将每一个响应数据返回至响应数据所属的调用方。
步骤S804的执行过程和原理可参见步骤S415至步骤S416的相关内容以及步骤S606的相关内容，此处不再赘述。
参阅图9，基于上述内容，针对多个不同设备的调用方的请求的处理场景，本申请实施例还公开了一种请求的处理方法，具体包括以下步骤：
S901、第一设备和第二设备建立连接。
步骤S901的执行过程和原理可参见步骤S401至S402的相关内容，此处不再赘述。
S902、第二设备将第二设备的调用方的请求，转发至第一设备。
步骤S902的执行过程和原理，可参见步骤S403至步骤S407的相关内容，此处不再赘述。
S903、第一设备将第一设备的调用方的请求和第二设备的调用方的请求，发送到HIDL接口的Server端。
步骤S903的执行过程和原理可参见步骤S403至步骤S408的相关内容以及步骤S601至步骤S602的相关内容，此处不再赘述。其中，步骤S903提及的HIDL接口也可以是其他类型的第一设备接口，本申请不做限制。
S904、第一设备接收通过HIDL接口的Server端返回的每一个请求对应的响应数据。
步骤S904的执行过程和原理可参见步骤S412的相关内容以及步骤S604的相关内容，此处不再赘述。
S905、第一设备针对每一个请求对应的响应数据，根据请求对应的响应数据中携带的用于说明请求所属的调用方的信息，识别每一个请求对应的响应数据所属的调用方。
步骤S905的执行过程和原理可参见步骤S413的相关内容以及步骤S605的相关内容，此处不再赘述。
S906、第一设备将属于第二设备的调用方的响应数据，返回至第二设备。
步骤S906的执行过程和原理可参见步骤S414的相关内容，此处不再赘述。
S907、第二设备将每一个响应数据返回至响应数据所属的调用方。
步骤S907的执行过程和原理可参见步骤S415至步骤S416的相关内容以及步骤S606的相关内容，此处不再赘述。
S908、第一设备将属于第一设备的调用方的响应数据，返回至响应数据所属的调用方。
步骤S908的执行过程和原理可参见步骤S417至S418的相关内容以及步骤S606的相关内容，此处不再赘述。
参阅图10，基于上述内容，针对同一个设备内的多个调用方的请求的处理场景，本申请实施例还公开了一种请求的处理方法，应用于第一设备，具体包括以下步骤：
S1001、将多个调用方的请求，发送到HIDL接口的Server端。
其中，请求中携带有用于说明请求所属的调用方的信息。
步骤S1001的执行过程和原理可参见步骤S403至步骤S408的相关内容以及步骤S601至步骤S602的相关内容，此处不再赘述。其中，步骤S1001提及的HIDL接口也可以是其他类型的第一设备接口，本申请不做限制。
S1002、接收通过HIDL接口的Server端返回的每一个请求对应的响应数据。
步骤S1002的执行过程和原理可参见步骤S412的相关内容以及步骤S604的相关内容，此处不再赘述。
S1003、针对每一个请求对应的响应数据，根据请求对应的响应数据中携带的用于说明请求所属的调用方的信息，识别每一个请求对应的响应数据所属的调用方。
步骤S1003的执行过程和原理可参见步骤S413的相关内容以及步骤S605的相关内容，此处不再赘述。
S1004、针对每一个请求对应的响应数据，将请求对应的响应数据返回至所述请求对应的响应数据所属的调用方。
步骤S1004的执行过程和原理可参见步骤S417至S418的相关内容以及步骤S606的相关内容，此处不再赘述。
本申请的一些实施例还提供了一种电子设备，如图11所示，该电子设备可以包括：触摸屏1101，其中，所述触摸屏1101可以包括触敏表面1106和显示屏1107；一个或多个处理器1102；存储器1103；以及一个或多个计算机程序1104，上述各器件可以通过一个或多 个通信总线1105连接。其中该一个或多个计算机程序1104被存储在上述存储器1903中，并被配置为被该一个或多个处理器1102执行，该一个或多个计算机程序1104包括指令，上述指令可以用于执行如图4相应实施例中第一设备执行的各个步骤、如图4相应实施例中第二设备执行的各个步骤、如图6a至图10中相应实施例中的各个步骤。当然，图11所示的电子设备还可以包括如传感器模块、音频模块以及SIM卡接口等其他器件，本申请实施例对此不做任何限制。当图11所示的电子设备还包括如传感器模块、音频模块以及SIM卡接口等其他器件时，其可以为图2c所示的电子设备。
在采用对应各个功能划分各个功能模块的情况下，图12示出了请求的处理装置的一种可能的组成示意图，该请求的处理装置能执行本申请各方法实施例中任一方法实施例中电子设备所执行的步骤。如图12所示，所述请求的处理装置为电子设备或支持电子设备实现实施例中提供的方法的通信装置，例如该通信装置可以是芯片系统。该请求的处理装置可以包括：处理单元1201、显示单元1202和收发单元1203。
其中，处理单元1201，用于支持请求的处理装置执行本申请实施例中描述的方法。例如，处理单元1201，用于执行或用于支持请求的处理装置执行如图4相应实施例中第一设备执行的各个步骤、如图4相应实施例中第二设备执行的各个步骤、图6a至图10执行的各个步骤。
需要说明的是，上述方法实施例涉及的各步骤的所有相关内容均可以援引到对应功能模块的功能描述，在此不再赘述。
本申请实施例提供的请求的处理装置，用于执行上述任意实施例的方法，因此可以达到与上述实施例的方法相同的效果。
本实施例还提供了一种计算机可读存储介质，该计算机可读存储介质中包括指令，当上述指令在电子设备上运行时，使得该电子设备执行图4中第一设备的相关方法步骤，以实现上述实施例中的方法，或者执行图4中第二设备的相关方法步骤，以实现上述实施例中的方法，又或者，执行图6a至图10中的相关方法步骤，以实现上述实施例中的方法。
通过以上的实施方式的描述，所属领域的技术人员可以清楚地了解到，在本实施例所提供的几个实施例中，应该理解到，所揭露的系统，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。
基于这样的理解，本实施例的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器执行各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：快闪存储器、移动硬盘、只读存储器、随机存取存储器、磁碟或者光盘等各种可以存储程序代码的介质。

Claims (20)

  1. 一种请求的处理方法，其特征在于，应用于第一设备，所述请求的处理方法，包括：
    将多个调用方的请求，发送至第一设备接口的服务Server端；其中，所述请求中携带有用于说明所述请求所属的调用方的信息；
    接收所述第一设备接口的Server端返回的每一个所述请求对应的响应数据；其中，所述请求对应的响应数据中携带有用于说明所述请求所属的调用方的信息；
    针对每一个所述请求对应的响应数据，根据所述请求对应的响应数据中携带的用于说明所述请求所属的调用方的信息，识别所述请求对应的响应数据所属的调用方；
    针对每一个所述请求对应的响应数据，将所述请求对应的响应数据返回至所述请求对应的响应数据所属的调用方。
  2. 根据权利要求1所述的请求的处理方法，其特征在于，所述第一设备接口为第一设备的抽象层接口定义语言HIDL接口，所述将多个调用方的请求，发送至第一设备接口的服务Server端之后，还包括：
    通过所述第一设备的HIDL接口的Server端，将每一个所述调用方的请求发送到第一设备的调制解调处理器Modem；
    通过所述第一设备的Modem对每一个所述请求进行处理，得到每一个所述请求对应的响应数据；
    所述接收所述第一设备接口的Server端返回的每一个所述请求对应的响应数据，包括：
    接收所述Modem通过第一设备的HIDL接口的Server端，返回的每一个请求对应的响应数据。
  3. 根据权利要求2所述的请求的处理方法，其特征在于，所述通过所述第一设备的HIDL接口的Server端，将每一个所述调用方的请求发送到第一设备的Modem，包括：
    通过接口代理模块调用第一设备的HIDL接口的Server端，将每一个调用方的请求发送到第一设备的Modem；其中，所述接口代理模块预创建了每一个调用方对应的HIDL接口的客户Client端的代理对象；
    所述接收所述Modem通过第一设备的HIDL接口的Server端，返回的每一个请求对应的响应数据，包括：
    通过所述接口代理模块，接收所述Modem通过第一设备的HIDL接口的Server端，返回的每一个请求对应的响应数据。
  4. 根据权利要求1至3任一所述的请求的处理方法，其特征在于，所述多个调用方的请求，包括：所述第一设备的调用方的请求，和/或，所述第二设备的调用方的请求。
  5. 根据权利要求4所述的请求的处理方法，其特征在于，所述将多个调用方的请求，发送至第一设备接口的服务Server端之前，还包括：
    针对每一个调用方的请求，根据调用方的标识，对请求中的顺序serial参数进行处理，以使得所述请求中的处理后的serial参数可用于说明所述请求所属的调用方；其中，所述用于说明所述请求所属的调用方的信息为：所述请求中处理后的serial参数；
    所述针对每一个所述请求对应的响应数据，将所述请求对应的响应数据返回至所述请 求对应的响应数据所属的调用方之前，还包括：
    针对每一个所述请求对应的响应数据，将所述请求对应的响应数据中的处理后的serial参数，进行还原处理。
  6. 根据权利要求5所述的请求的处理方法，其特征在于，所述针对每一个调用方的请求，根据调用方的标识，对所述请求中的serial参数进行处理，以使得所述请求中的处理后的serial参数可用于说明所述请求所属的调用方，包括：
    针对每一个调用方的请求，根据调用方的标识，将所述请求中的serial参数偏移与所述调用方对应的偏移值，以使得所述请求中的处理后的serial参数可用于说明所述请求所属的调用方。
  7. 根据权利要求6所述的请求的处理方法，其特征在于，所述针对每一个所述请求对应的响应数据，根据所述请求对应的响应数据中携带的用于说明所述请求所属的调用方的信息，识别所述请求对应的响应数据所属的调用方，包括：
    针对每一个所述请求对应的响应数据，将所述请求对应的响应数据中的处理后的serial参数，分别与每一个调用方对应的serial参数取值范围进行匹配，并将匹配的调用方确定为所述请求对应的响应数据所属的调用方。
  8. 根据权利要求1或2所述的请求的处理方法，其特征在于，所述用于说明所述请求所属的调用方的信息为：所述请求所属的调用方的标识；
    所述接收所述第一设备接口的Server端返回的每一个所述请求对应的响应数据，包括：
    通过第一设备接口的Client端，接收所述第一设备接口的Server端返回的每一个所述请求对应的响应数据；其中，所述第一设备接口的Client端中预设置了用于支持接收每一个调用方的标识的字段；所述第一设备接口的Server端中预设置了用于支持接收每一个调用方的标识的字段。
  9. 根据权利要求4所述的请求的处理方法，其特征在于，若所述多个调用方的请求，包括：所述第一设备的调用方的请求和所述第二设备的调用方的请求，则所述将多个调用方的请求，发送至第一设备接口的服务Server端之前，还包括：
    针对每一个第一设备的调用方的请求，根据所述调用方的标识，对请求中的serial参数进行处理，以使得所述请求中的处理后的serial参数可用于说明所述请求所属的调用方，或者，针对每一个第一设备和第二设备的调用方的请求，根据所述调用方的标识，对请求中的serial参数进行处理，以使得所述请求中的处理后的serial参数可用于说明所述请求所属的调用方；其中，所述用于说明所述请求所属的调用方的信息为：所述请求中处理后的serial参数。
  10. 根据权利要求9所述的请求的处理方法，其特征在于，所述针对每一个所述请求对应的响应数据，将所述请求对应的响应数据返回至所述请求对应的响应数据所属的调用方之前，还包括：
    针对每一个属于第一设备的所述请求对应的响应数据，将所述请求对应的响应数据中的处理后的serial参数，进行还原处理，或者，针对每一个属于第一设备和第二设备的所述请求对应的响应数据，均将所述请求对应的响应数据中的处理后的serial参数，进行还原处理。
  11. 根据权利要求10所述的请求的处理方法，其特征在于，所述对请求中的serial参数进行处理，以使得所述请求中的处理后的serial参数可用于说明所述请求所属的调用方，包括：
    根据所述调用方的标识，将所述请求中的serial参数偏移与所述调用方对应的偏移值，以使得所述请求中的处理后的serial参数可用于说明所述请求所属的调用方。
  12. 一种请求的处理方法，其特征在于，应用于第二设备，所述请求的处理方法，包括：
    发送第二设备的调用方的请求至第一设备，以使得第一设备将所述第二设备的调用方的请求，发送到第一设备接口的Server端，并接收所述第一设备接口的Server端返回的每一个所述请求对应的响应数据；其中，所述请求中携带有用于说明所述请求所属的调用方的信息；所述第一设备和所述第二设备处于连接状态；
    接收第一设备返回的每一个属于第二设备的所述请求对应的响应数据；其中，所述请求对应的响应数据所属的调用方根据所述请求对应的响应数据中携带的用于说明所述请求所属的调用方的信息识别得到；
    针对每一个所述请求对应的响应数据，将所述响应数据返回至所述响应数据所属的调用方。
  13. 根据权利要求12所述的请求的处理方法，其特征在于，所述发送第二设备的调用方的请求至第一设备之前，还包括：
    通过接口代理模块接收第一设备的调用方的请求；其中，所述接口代理模块预创建了第一设备的调用方对应的HIDL接口的Client端的代理对象、以及第二设备的调用方对应的HIDL接口的Client端的代理对象。
  14. 根据权利要求12所述的请求的处理方法，其特征在于，所述发送第二设备的调用方的请求至第一设备之前，还包括：
    针对每一个第二设备的调用方的请求，根据所述调用方的标识，对请求中的serial参数进行处理，以使得所述请求中的处理后的serial参数可用于说明所述请求所属的调用方。
  15. 根据权利要求14所述的请求的处理方法，其特征在于，所述针对每一个所述请求对应的响应数据，将所述响应数据返回至所述响应数据所属的调用方之前，还包括：
    针对每一个属于第二设备的所述请求对应的响应数据，将所述请求对应的响应数据中的处理后的serial参数，进行还原处理。
  16. 根据权利要求14所述的请求的处理方法，其特征在于，所述针对每一个第二设备的调用方的请求，根据所述调用方的标识，对请求中的serial参数进行处理，以使得所述请求中的处理后的serial参数可用于说明所述请求所属的调用方，包括：
    针对每一个第二设备的调用方的请求，根据所述调用方的标识，将所述请求中的serial参数偏移与所述调用方对应的偏移值，以使得所述请求中的处理后的serial参数可用于说明所述请求所属的调用方。
  17. 根据权利要求14所述的请求的处理方法，其特征在于，若所述第二设备有多个调用方，则所述针对每一个所述请求对应的响应数据，将所述响应数据返回至所述响应数据所属的调用方之前，还包括：
    针对每一个所述请求对应的响应数据，根据所述请求对应的响应数据中携带的用于说明所述请求所属的调用方的信息，识别所述请求对应的响应数据所属的调用方。
  18. 根据权利要求17所述的请求的处理方法，其特征在于，所述针对每一个所述请求对应的响应数据，根据所述请求对应的响应数据中携带的用于说明所述请求所属的调用方的信息，识别所述请求对应的响应数据所属的调用方，包括：
    针对每一个所述请求对应的响应数据，将所述请求对应的响应数据中的处理后的serial参数，分别与每一个调用方对应的serial参数取值范围进行匹配，并将匹配的调用方确定为所述请求对应的响应数据所属的调用方。
  19. 一种电子设备，其特征在于，包括：一个或多个处理器、存储器、显示屏、无线通信模块以及移动通信模块；
    所述存储器、所述显示屏、所述无线通信模块以及所述移动通信模块与所述一个或多个处理器耦合，所述存储器用于存储计算机程序代码，所述计算机程序代码包括计算机指令，当所述一个或多个处理器执行所述计算机指令时，所述电子设备执行如权利要求1至11中任一项所述的请求的处理方法，或者，如权利要求12至18中任一项所述的请求的处理方法。
  20. 一种请求的处理装置，其特征在于，所述请求的处理装置包括：处理单元、存储单元、显示单元、收发单元，所述存储单元用于存储一个或多个程序；所述处理单元用于执行所述一个或多个程序；所述一个或多个程序包括指令，所述指令用于执行如权利要求1至11中任一项所述的请求的处理方法，或者，如权利要求12至18中任一项所述的请求的处理方法。
PCT/CN2022/092926 2021-08-25 2022-05-16 请求的处理方法及相关装置 WO2023024589A1 (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP22859937.9A EP4236260A4 (en) 2021-08-25 2022-05-16 REQUEST PROCESSING METHOD AND RELATED DEVICE

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202110993034.5 2021-08-25
CN202110993034.5A CN115733884B (zh) 2021-08-25 2021-08-25 请求的处理方法及相关装置

Publications (1)

Publication Number Publication Date
WO2023024589A1 true WO2023024589A1 (zh) 2023-03-02

Family

ID=85290191

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/092926 WO2023024589A1 (zh) 2021-08-25 2022-05-16 请求的处理方法及相关装置

Country Status (3)

Country Link
EP (1) EP4236260A4 (zh)
CN (1) CN115733884B (zh)
WO (1) WO2023024589A1 (zh)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105808320A (zh) * 2016-03-11 2016-07-27 四川安嵌科技有限公司 基于Linux容器的设备虚拟化系统及方法
US20180052723A1 (en) * 2016-08-17 2018-02-22 Google Inc. Middleware Interface and Middleware Interface Generator
CN109669723A (zh) * 2017-10-13 2019-04-23 阿里巴巴集团控股有限公司 硬件访问方法、装置、设备和机器可读介质
CN112769837A (zh) * 2021-01-13 2021-05-07 北京洛塔信息技术有限公司 基于WebSocket的通信传输方法、装置、设备、系统及存储介质
CN112969024A (zh) * 2020-06-30 2021-06-15 华为技术有限公司 一种摄像头的调用方法、电子设备和摄像头

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5159261B2 (ja) * 2007-11-12 2013-03-06 インターナショナル・ビジネス・マシーンズ・コーポレーション セッションを管理する技術
US8996657B2 (en) * 2010-09-01 2015-03-31 Canon Kabushiki Kaisha Systems and methods for multiplexing network channels
CN111813724B (zh) * 2020-05-20 2023-06-30 北京元心科技有限公司 Hidl接口适配系统、方法及相应设备、存储介质
CN111880866B (zh) * 2020-07-30 2024-03-12 广州方硅信息技术有限公司 跨进程回调执行方法、装置、设备及存储介质

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105808320A (zh) * 2016-03-11 2016-07-27 四川安嵌科技有限公司 基于Linux容器的设备虚拟化系统及方法
US20180052723A1 (en) * 2016-08-17 2018-02-22 Google Inc. Middleware Interface and Middleware Interface Generator
CN109669723A (zh) * 2017-10-13 2019-04-23 阿里巴巴集团控股有限公司 硬件访问方法、装置、设备和机器可读介质
CN112969024A (zh) * 2020-06-30 2021-06-15 华为技术有限公司 一种摄像头的调用方法、电子设备和摄像头
CN112769837A (zh) * 2021-01-13 2021-05-07 北京洛塔信息技术有限公司 基于WebSocket的通信传输方法、装置、设备、系统及存储介质

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP4236260A4

Also Published As

Publication number Publication date
EP4236260A4 (en) 2024-05-22
CN115733884B (zh) 2023-10-24
EP4236260A1 (en) 2023-08-30
CN115733884A (zh) 2023-03-03

Similar Documents

Publication Publication Date Title
WO2023000969A1 (zh) 蜂窝通信功能的使用方法、相关装置及系统
WO2021115038A1 (zh) 一种应用数据处理方法及相关装置
US20230054451A1 (en) Communication Connection Method and Electronic Device
CN114741008B (zh) 分布式跨设备协同方法、电子设备及通信系统
KR102050379B1 (ko) 호 이동을 위한 방법 및 장치
CN114584613A (zh) 一种推送消息的方法、消息推送系统及电子设备
KR102133514B1 (ko) 전자 장치의 상태 메시지 서비스 제공 방법 및 그 전자 장치
CN115766851A (zh) 设备注册方法、装置、移动终端和存储介质
CN114845035B (zh) 一种分布式拍摄方法，电子设备及介质
CN114765614B (zh) 一种访问局域网服务设备的方法及电子设备
WO2023024589A1 (zh) 请求的处理方法及相关装置
CN114666395B (zh) 双系统网络共享的方法及装置
CN116056076B (zh) 通信系统、方法及电子设备
CN112825072A (zh) 通信终端以及数据共享方法
EP4287048A1 (en) Login authentication method and electronic device
US20230289432A1 (en) Application Data Transmission Method, User Equipment, and System
CN116033592B (zh) 蜂窝通信功能的使用方法和装置
WO2023035885A1 (zh) 通信方法及电子设备
WO2024104122A1 (zh) 分享方法、电子设备及计算机存储介质
WO2023143560A1 (zh) 设备选择的方法以及装置
CN117478682A (zh) 建立点对点通道的方法、设备及协同工作系统
CN117499780A (zh) 一种拍照方法、电子设备及协同工作系统
CN117640579A (zh) 通信方法、系统、电子设备、计算机程序产品及存储介质
CN115878307A (zh) 访问资源的方法及电子设备
CN113891310A (zh) 协作通信方法、用户设备及系统

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22859937

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2022859937

Country of ref document: EP

Effective date: 20230524

NENP Non-entry into the national phase

Ref country code: DE