CN115733884B - 请求的处理方法及相关装置 - Google Patents
请求的处理方法及相关装置 Download PDFInfo
- Publication number
- CN115733884B CN115733884B CN202110993034.5A CN202110993034A CN115733884B CN 115733884 B CN115733884 B CN 115733884B CN 202110993034 A CN202110993034 A CN 202110993034A CN 115733884 B CN115733884 B CN 115733884B
- Authority
- CN
- China
- Prior art keywords
- request
- response data
- data corresponding
- caller
- interface
- Prior art date
- Legal status (The legal status 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 status listed.)
- Active
Links
- 238000003672 processing method Methods 0.000 title abstract description 14
- 230000004044 response Effects 0.000 claims abstract description 336
- 238000000034 method Methods 0.000 claims abstract description 142
- 238000012545 processing Methods 0.000 claims description 141
- 230000010267 cellular communication Effects 0.000 claims description 129
- 238000004891 communication Methods 0.000 claims description 26
- 238000010295 mobile communication Methods 0.000 claims description 8
- 238000004590 computer program Methods 0.000 claims description 5
- 230000009467 reduction Effects 0.000 claims description 4
- 230000008569 process Effects 0.000 abstract description 47
- 239000010410 layer Substances 0.000 description 44
- 230000006870 function Effects 0.000 description 29
- 230000005540 biological transmission Effects 0.000 description 16
- 238000010586 diagram Methods 0.000 description 16
- 230000001413 cellular effect Effects 0.000 description 7
- 238000005516 engineering process Methods 0.000 description 5
- 238000013461 design Methods 0.000 description 4
- 239000000203 mixture Substances 0.000 description 3
- 230000001133 acceleration Effects 0.000 description 2
- 238000013528 artificial neural network Methods 0.000 description 2
- 210000000988 bone and bone Anatomy 0.000 description 2
- 238000011161 development Methods 0.000 description 2
- 230000007246 mechanism Effects 0.000 description 2
- 239000007787 solid Substances 0.000 description 2
- 230000001960 triggered effect Effects 0.000 description 2
- 208000033748 Device issues Diseases 0.000 description 1
- 230000008901 benefit Effects 0.000 description 1
- 230000033228 biological regulation Effects 0.000 description 1
- 230000015572 biosynthetic process Effects 0.000 description 1
- 238000004364 calculation method Methods 0.000 description 1
- 239000012792 core layer Substances 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000005538 encapsulation Methods 0.000 description 1
- 230000004927 fusion Effects 0.000 description 1
- 230000000977 initiatory effect Effects 0.000 description 1
- 230000004807 localization Effects 0.000 description 1
- 230000001537 neural effect Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 238000002360 preparation method Methods 0.000 description 1
- 238000009877 rendering Methods 0.000 description 1
- 238000000926 separation method Methods 0.000 description 1
- 230000011664 signaling Effects 0.000 description 1
- 239000004984 smart glass Substances 0.000 description 1
- 238000003786 synthesis reaction Methods 0.000 description 1
- 230000000007 visual effect Effects 0.000 description 1
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
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
技术领域
本申请涉及电子信息技术领域,尤其涉及一种请求的处理方法及相关装置。
背景技术
现有技术中,应用侧通常通过调用抽象层接口定义语言(HAL interfacedefinition 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)的开发工具包(SoftwareDevelopment Kit,SDK)应用程序接口(Application Programming Interface,API),然后AOSP SDKAPI又再调用电话管理器的服务(Telephony Service)接口,然后TelephonyService再调用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端,再由电话管理器内的TelephonyService、开发工具包,发送到短信息应用。本地的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、……telephonyn这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多媒体子系统(IPMultimedia 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,以及用户标识模块(subscriberidentification 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上的包括无线局域网(wirelesslocal 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可以用于连接外部存储卡,例如MicroSD卡,实现扩展电子设备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可以支持NanoSIM卡,MicroSIM卡,SIM卡等。同一个SIM卡接口295可以同时插入多张卡。SIM卡接口295也可以兼容外部存储卡。电子设备200通过SIM卡和网络交互,实现通话以及数据通信等功能。
另外,在上述部件之上,运行有操作系统。例如鸿蒙操作系统、iOS操作系统,Android操作系统,Windows操作系统等。在该操作系统上可以安装运行应用程序。在另一些实施例中,电子设备内运行的操作系统可以有多个。
参阅图3a,图3a为本申请实施例提出的一种请求的处理系统300。其中,请求的处理系统300用于执行第二设备和第一设备所下发的请求的处理。而在另一些实施例中,请求的处理系统300中第二设备和第一设备内部的操作系统可以处于同一个电子设备内,而下述对请求的处理系统300执行的第二设备和第一设备所下发的请求的处理过程,也可以适用于同一个电子设备中两个操作系统所下发的请求的处理过程。
在一些实施例中,本申请实施例公开的请求的处理系统300中第二设备的分层架构将软件分成若干个层,每一层都有清晰的角色和分工。层与层之间通过软件接口通信。在一些实施例中,将Android系统分为四层,从上至下分别为应用程序层,应用程序框架层,安卓运行时(Android runtime)和系统库,以及内核层。
应用程序层可以包括一系列应用程序包。如图3a所示,应用程序包可以包括相机,图库,日历,通话,地图,导航,WLAN,蓝牙,音乐,视频,短信息等应用程序。
应用程序框架层为应用程序层的应用程序提供应用编程接口(applicationprogramming 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),三维图形处理库(例如:OpenGLES),2D图形引擎(例如:SGL),硬件抽象层(Hardware Abstraction Layer,HAL),以及在HAL上的无线电接口层(Radio InterfaceLayer,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多媒体子系统(IPMultimedia 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参数的取值范围来说明请求所属的调用方。例如下述表一所示,调用方的标识与调用方对应的偏移值之间的关系可以设定为:当调用方的标识(ClientId)为1时,设定其对应的serial参数的取值范围为:0至offset value-1,当Client Id为2时,设定其对应的serial参数的取值范围为offset value至2*offsetvalue-1,当Client Id为N时,设定其对应的serial参数的取值范围为:(N-1)*offsetvalue到N*offset value–1。即当调用方的的标识为N时,其对应的请求中的serial参数需偏移(N-1)*offset value。其中,offset value是预设值,例如offset value可以预设为10000000。
表一
举例说明,第一设备内有一个电话管理器,它的调用方的标识被分配为是1,而第二设备有两个电话管理器,被第一设备分配的调用方的标识分别是2和3。当offsetvalue为10000000时,ClientId为1的电话管理器对应的serial参数的取值范围是0到9999999,即ClientId为1的电话管理器下发的请求的serial参数所需偏移的偏移值为0,而ClientId为2的电话管理器对应的取值范围是10000000到19999999,即ClientId为2的电话管理器下发的请求的serial参数所需偏移的偏移值为10000000,ClientId为3的电话管理器对应的取值范围是20000000到29999999,即ClientId为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至offsetvalue-1的范围,那么所属的调用方的标识为1。
在一些实施例中,还可以在识别出请求对应的响应数据所属的调用方之后,将识别结果与请求对应的响应数据进行对应存储。
S414、第一设备将属于第二设备的调用方的响应数据,返回至第二设备。
通过步骤S413的识别,第一设备识别出了部分请求对应的响应数据属于第一设备,部分请求对应的响应数据属于第二设备,能够区分开两个不同设备的请求对应的响应数据,然后从中选出第二设备的调用方的响应数据,返回到第二设备中。
在一些实施例中,可以是第一设备的分布式蜂窝通信模块将第二设备的调用方的响应数据,返回到第二设备的分布式蜂窝通信模块。
S415、第二设备针对第二设备的每一个请求对应的响应数据,将请求对应的响应数据中的处理后的serial参数,进行还原处理。
为了使得调用方能够识别出请求对应的响应数据,需要将在前述步骤中进行处理过的serial参数,进行还原处理。具体的,在前述实施例中进行了偏移了与调用方对应的偏移值的serial参数,此时可以减去偏移值,还原成原本的serial参数。举例说明,如表一所示,调用方的标识为2的serial参数进行了正偏移offsetvalue的处理,因此在步骤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被存储在上述存储器1103中,并被配置为被该一个或多个处理器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参数,进行还原处理。
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参数可用于说明所述请求所属的调用方。
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中任一项所述的请求的处理方法。
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202110993034.5A CN115733884B (zh) | 2021-08-25 | 2021-08-25 | 请求的处理方法及相关装置 |
PCT/CN2022/092926 WO2023024589A1 (zh) | 2021-08-25 | 2022-05-16 | 请求的处理方法及相关装置 |
EP22859937.9A EP4236260A4 (en) | 2021-08-25 | 2022-05-16 | REQUEST PROCESSING METHOD AND RELATED DEVICE |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202110993034.5A CN115733884B (zh) | 2021-08-25 | 2021-08-25 | 请求的处理方法及相关装置 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN115733884A CN115733884A (zh) | 2023-03-03 |
CN115733884B true CN115733884B (zh) | 2023-10-24 |
Family
ID=85290191
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202110993034.5A Active CN115733884B (zh) | 2021-08-25 | 2021-08-25 | 请求的处理方法及相关装置 |
Country Status (3)
Country | Link |
---|---|
EP (1) | EP4236260A4 (zh) |
CN (1) | CN115733884B (zh) |
WO (1) | WO2023024589A1 (zh) |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN111813724A (zh) * | 2020-05-20 | 2020-10-23 | 北京元心科技有限公司 | Hidl接口适配系统、方法及相应设备、存储介质 |
CN111880866A (zh) * | 2020-07-30 | 2020-11-03 | 广州华多网络科技有限公司 | 跨进程回调执行方法、装置、设备及存储介质 |
CN112969024A (zh) * | 2020-06-30 | 2021-06-15 | 华为技术有限公司 | 一种摄像头的调用方法、电子设备和摄像头 |
Family Cites Families (6)
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 |
CN105808320B (zh) * | 2016-03-11 | 2018-12-04 | 四川安嵌科技有限公司 | 基于Linux容器的设备虚拟化系统及方法 |
US10019298B2 (en) * | 2016-08-17 | 2018-07-10 | Google Llc | Middleware interface and middleware interface generator |
CN109669723B (zh) * | 2017-10-13 | 2023-06-13 | 斑马智行网络(香港)有限公司 | 硬件访问方法、装置、设备和机器可读介质 |
CN112769837B (zh) * | 2021-01-13 | 2023-07-04 | 北京洛塔信息技术有限公司 | 基于WebSocket的通信传输方法、装置、设备、系统及存储介质 |
-
2021
- 2021-08-25 CN CN202110993034.5A patent/CN115733884B/zh active Active
-
2022
- 2022-05-16 EP EP22859937.9A patent/EP4236260A4/en active Pending
- 2022-05-16 WO PCT/CN2022/092926 patent/WO2023024589A1/zh unknown
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN111813724A (zh) * | 2020-05-20 | 2020-10-23 | 北京元心科技有限公司 | Hidl接口适配系统、方法及相应设备、存储介质 |
CN112969024A (zh) * | 2020-06-30 | 2021-06-15 | 华为技术有限公司 | 一种摄像头的调用方法、电子设备和摄像头 |
CN111880866A (zh) * | 2020-07-30 | 2020-11-03 | 广州华多网络科技有限公司 | 跨进程回调执行方法、装置、设备及存储介质 |
Also Published As
Publication number | Publication date |
---|---|
EP4236260A1 (en) | 2023-08-30 |
WO2023024589A1 (zh) | 2023-03-02 |
CN115733884A (zh) | 2023-03-03 |
EP4236260A4 (en) | 2024-05-22 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN113630910B (zh) | 蜂窝通信功能的使用方法、相关装置及系统 | |
WO2021115038A1 (zh) | 一种应用数据处理方法及相关装置 | |
EP4102368A1 (en) | Cross-device application calling method and electronic device | |
EP2716096B1 (en) | Methods and apparatuses for lawful interception through a subscription manager | |
US20230054451A1 (en) | Communication Connection Method and Electronic Device | |
CN114741008B (zh) | 分布式跨设备协同方法、电子设备及通信系统 | |
CN113746777B (zh) | 安全访问数据的方法及电子设备 | |
US9112917B2 (en) | Controller system and method therefor | |
CN112825072B (zh) | 通信终端以及数据共享方法 | |
CN109151812A (zh) | 一号多终端同步解锁方法及装置 | |
CN115733884B (zh) | 请求的处理方法及相关装置 | |
WO2022233237A1 (zh) | 一种音频播放方法、装置和设备 | |
CN113642010B (zh) | 一种获取扩展存储设备数据的方法及移动终端 | |
CN114928898A (zh) | 建立基于WiFi直接连接的会话的方法和装置 | |
CN109032583B (zh) | 数据交互方法及装置 | |
CN116982042A (zh) | 灵活授权的访问控制方法、相关装置及系统 | |
CN114116072A (zh) | 一种共享库的复用方法及电子设备 | |
CN116033592B (zh) | 蜂窝通信功能的使用方法和装置 | |
CN114745495B (zh) | 图像生成方法、装置及存储介质 | |
WO2022247455A1 (zh) | 一种音频分流的方法及电子设备 | |
CN115878307A (zh) | 访问资源的方法及电子设备 | |
CN116800814A (zh) | 一种数据中继方法、服务器、终端设备及存储介质 | |
CN115510447A (zh) | 组件访问方法和装置、计算机可读存储介质以及芯片 | |
CN117014540A (zh) | 一种来电通知系统和电子设备 | |
CN116009742A (zh) | 一种跨设备文件显示方法、设备及系统 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
REG | Reference to a national code |
Ref country code: HK Ref legal event code: DE Ref document number: 40080487 Country of ref document: HK |
|
GR01 | Patent grant | ||
GR01 | Patent grant |