CN113867977A - 设备控制方法和设备 - Google Patents

Abstract

本申请提供一种设备控制方法和设备。第一设备向第一应用进程发送第一请求，第一应用进程对应于第一应用。第一设备响应于第一请求，向第一服务器发送第二请求，第一应用与第二应用关联。第一设备从第一服务器接收第二应用。第一应用进程向第二应用进程发送第三请求，第二应用进程对应于第二应用，第一应用进程和第二应用进程为不同的进程。第二应用进程向第二应用对应的服务器发送第四请求。第二应用进程从第二应用对应的服务器接收第一资源。第二应用进程向第一应用进程发送第一资源。第一设备基于第一资源，执行第一响应。从而，不仅减少了设备中应用的存储和运行空间，还降低了设备与第二应用对应服务器之间的对接成本。

Description

设备控制方法和设备

技术领域

本申请涉及通信技术领域，尤其涉及一种设备控制方法和设备。

背景技术

随着物联网的不断发展，硬件设备厂商不仅需要做好硬件，还需要考虑软件。以音箱为例，不仅需要做好如音箱的蓝牙、Wi-Fi网络连接等硬件，还需考虑如音箱的播放资源以及语言交互等软件。这对于软件开发能力较差的硬件设备厂商来说，服务端和客户端的开发成本均较大。如果集成其他厂商的软件能力，那么厂商间的对接和调试流程均较复杂，提高了成本。

发明内容

本申请提供一种设备控制方法和设备，通过第一应用与第二应用的依赖关系，第一设备可以安装第二应用，使得第一应用通过第二应用可向第二应用对应的服务器获取设备执行响应操作的资源。从而，不仅降低了第一设备中安装应用的存储空间和运行空间，降低了应用下载应用的流量消耗，还降低了设备厂商和应用厂商的对接成本。

第一方面，本申请提供一种设备控制方法，方法包括：第一设备向第一应用进程发送第一请求，其中，第一应用进程对应于第一应用，第一应用安装在第一设备中，第一请求用于请求第一设备执行第一响应的资源；第一设备响应于第一请求，向第一服务器发送第二请求，其中，第二请求用于请求获取第二应用，第一应用与第二应用关联；第一设备从第一服务器接收第二应用；第一应用进程向第二应用进程发送第三请求，其中，第二应用进程对应于第二应用，第一应用进程和第二应用进程为不同的进程，第三请求用于请求第一设备执行第一响应的资源；第二应用进程向第二应用对应的服务器发送第四请求，其中，第四请求用于请求第一设备执行第一响应的资源；第二应用进程从第二应用对应的服务器接收第一资源，其中，第一资源用于第一设备执行第一响应；第二应用进程向第一应用进程发送第一资源；第一设备基于第一资源，执行第一响应。

在一种可能的设计中，第一设备向第一服务器发送第二请求之前，方法还包括：第一设备基于包管理服务(Bundle Manager Service，BMS)不存在第二应用的标识，确定第二应用未安装在第一设备中，其中，BMS用于存储第一设备中已安装的应用的标识。

在一种可能的设计中，第一设备从第一服务器接收第二应用之后，还包括：第一设备将第二应用安装在第一设备中，并在BMS中存储第二应用的标识。

在一种可能的设计中，第一设备中存储有第一应用的配置文件，第一应用的配置文件中包含第二应用的标识；第二请求中携带有第二应用的标识。

在一种可能的设计中，方法还包括：第一设备响应于第一请求，向第一服务器发送第五请求，其中，第五请求用于请求获取第三应用，第一应用与第三应用关联；第一设备从第一服务器接收第三应用；第一应用进程向第三应用进程发送第六请求，其中，第三应用进程对应于第三应用，第一应用进程和第三应用进程为不同的进程，第六请求用于请求第一设备执行第一响应的资源；第三应用进程向第三应用对应的服务器发送第七请求，其中，第七请求用于请求第一设备执行第一响应的资源；第三应用进程从第三应用对应的服务器接收第二资源，其中，第二资源用于第一设备执行第一响应；第三应用进程向第一应用进程发送第二资源；第一设备基于第一资源和第二资源，执行第一响应。由此，第一设备中的一个应用可以关联多个应用，通过调用第二应用获取更多的资源，从而为第一设备执行操作提供了丰富的资源渠道。

在一种可能的设计中，第一设备从第二设备接收第一指令，第一设备与第二设备通信连接；第一设备响应于第一指令，向第一应用进程发送第一请求。

在一种可能的设计中，第一设备响应于用户的第一操作，向第一应用进程发送第一请求。

在一种可能的设计中，方法还包括：第一设备中的显示器显示第一应用的界面，第一应用的界面包括第一区域，第一区域显示的界面由第二应用提供。

在一种可能的设计中，方法还包括：第一设备释放第二应用的资源。由此，节省第一设备的内存开销。

在一种可能的设计中，方法还包括：第一应用进程停止调用第二应用进程。由此，第二应用进程可被其他应用调用，使得第二应用能够得到有效利用。

在一种可能的设计中，方法还包括：第一设备向第四应用进程发送第八请求，其中，第四应用进程对应于第四应用，第四应用安装在第一设备中，第四应用与第二应用关联，第八请求用于请求第一设备执行第二响应的资源；第四应用进程向第二应用进程发送第九请求，其中，第四应用进程和第二应用进程为不同的进程，第九请求用于请求第一设备执行第二响应的资源；第二应用进程向第二应用对应的服务器发送第十请求，其中，第十请求用于请求第一设备执行第二响应的资源；第二应用进程从第二应用对应的服务器接收第三资源，其中，第三资源用于第一设备执行第二响应；第二应用进程向第四应用进程发送第三资源；第一设备基于第三资源，执行第二响应。由此，第一设备中可以同时安装多个应用，且不同应用可以分别调用第二应用，从而通过第二应用分别获得响应的资源，使得第一设备可以执行不同的操作。

在一种可能的设计中，第一设备为音箱，第一应用为音箱FA应用，第二设备为音乐FA应用，第一服务器为FA云端服务器；方法具体为：所述音箱请求调用音箱FA进程，其中，所述音箱FA进程对应于所述音箱FA应用，所述音箱FA应用安装在所述音箱中；所述音箱判断所述音箱FA进程是否运行；在所述音箱FA进程未运行时，所述音箱调用所述音箱FA进程，并向所述音箱FA进程发送目标歌曲的标识；在所述音箱FA进程运行时，所述音箱向所述音箱FA进程发送目标歌曲的标识；所述音箱FA进程请求调用音乐FA进程；所述音箱判断BMS中是否存在所述音乐FA应用的标识，以确定所述音箱中是否存在所述音乐FA应用的bundle，其中，所述音乐FA进程对应于所述音乐FA应用，所述BMS中存储有与所述音箱FA应用关联的FA应用的标识；若所述BMS中不存在所述音乐FA应用的标识，则所述音箱的操作系统向所述FA云端服务器发送下载所述音乐FA应用请求，其中，所述下载音乐FA应用请求用于请求所述音乐FA应用的bundle，所述下载音乐FA应用请求中携带有所述音乐FA应用的标识；所述音箱的操作系统从所述FA云端服务器接收所述音乐FA应用的bundle；所述音箱的操作系统通过对所述音乐FA应用的bundle进行解包处理，将所述音乐FA应用安装在所述音箱中，且在所述BMS中存储所述音乐FA应用的标识，并继续判断所述BMS中是否存在所述音乐FA应用的标识，直至所述BMS中存在音乐FA应用的标识为止；若所述BMS中存在音乐FA应用的标识，则所述音箱FA进程调用所述音乐FA进程；所述音箱FA进程向所述音乐FA进程发送第一音乐资源请求，其中，第一音乐资源请求用于请求所述目标歌曲的音乐资源，所述第一音乐资源请求中携带有所述目标歌曲的标识；所述音乐FA进程向所述音乐FA应用对应的服务器发送第二音乐资源请求，其中，第二音乐资源请求用于请求所述目标歌曲的音乐资源，所述第二音乐资源请求中携带有所述目标歌曲的标识；所述音乐FA进程从所述音乐FA应用对应的服务器接收所述目标歌曲的音乐资源；所述音乐FA进程向所述音箱FA进程发送所述目标歌曲的音乐资源；所述音箱基于所述目标歌曲的音乐资源播放所述目标歌曲。

第二方面，本申请提供一种第一设备，包括：至少一个存储器和至少一个处理器；存储器用于存储程序指令；处理器用于调用存储器中的程序指令使得电子设备执行第一方面及第一方面任一种可能的设计中的设备控制方法。

第三方面，本申请提供一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器使得电子设备执行时实现第一方面及第一方面任一种可能的设计中的设备控制方法。

第四方面，本申请提供一种计算机程序产品，包括：执行指令，执行指令存储在可读存储介质中，电子设备的至少一个处理器可以从可读存储介质读取执行指令，至少一个处理器执行执行指令使得电子设备实现第一方面及第一方面任一种可能的设计中的设备控制方法。

附图说明

图1为本申请一实施例提供的一种通信系统的架构示意图；

图2为本申请一实施例提供的一种音箱的功能框图；

图3为本申请一实施例提供的一种音箱的功能框图；

图4为本申请一实施例提供的一种音箱的软件结构框图；

图5A-图5B为本申请一实施例提供的一种设备控制方法的系统架构图；

图5C为本申请一实施例提供的一种设备控制方法的信令流程图；

图6A为相关技术中音箱APP实体集成音乐厂商的SDK的流程示意图；

图6B为本申请一实施例提供的音箱FA虚拟集成音乐FA的流程示意图；

图7为本申请一实施例提供的一种设备控制方法的场景示意图；

图8A-图8D为本申请一实施例提供的一种人机交互界面示意图；

图9为本申请一实施例提供的一种设备控制方法的场景示意图；

图10A-图10D为本申请一实施例提供的一种人机交互界面示意图；

图11为本申请一实施例提供的一种设备控制方法的场景示意图；

图12A-图12B为本申请一实施例提供的一种人机交互界面示意图；

图13A-图13H为本申请一实施例提供的一种人机交互界面示意图；

图14为本申请一实施例提供的一种场景软件架构示意图；

图15为本申请一实施例提供的一种场景软件架构示意图；

图16A-图16B为本申请一实施例提供的一种人机交互界面示意图；

图17为本申请一实施例提供的一种场景软件架构示意图；

图18A-图18B为本申请一实施例提供的一种人机交互界面示意图；

图19为本申请一实施例提供的一种场景软件架构示意图。

具体实施方式

图1示出了本申请一实施例提供的一种通信系统的架构示意图。如图1所示，通信系统可以包括：第一设备101以及第二服务器102。第一设备101可以向第二服务器102请求服务资源，第二服务器102用于向第一设备101提供服务资源，从而使得第一设备101向用户提供相应的业务。

其中，第一设备101通常与第二服务器102属于不同的厂商。第一设备101可以包括：音箱、手机、平板电脑、可穿戴设备、车载设备、增强现实(augmented reality，AR)/虚拟现实(virtual reality，VR)设备、笔记本电脑、超级移动个人计算机(ultra-mobilepersonal computer，UMPC)、上网本、个人数字助理(personal digital assistant，PDA)、电视、智慧屏、高清电视、4K电视、投影仪等物联网(the internet of things，IOT)设备，本申请对第一设备101的具体类型不做限定。为了便于说明，本申请以第一设备101为音箱为例进行示意，第二服务器102可以为向音箱提供音乐资源的服务器。

在一些实施例中，继续结合图1，通信系统还可以包括：第三服务器103。音箱与第三服务器103连接，第三服务器103用于向音箱提供给如语音等转换服务和资源存储服务等。其中，第三服务器103与音箱通常属于同一个厂商。

例如，当音箱接收到用户的如语音操作、输入操作等形式的指令1时，音箱可以向第三服务器103发送指令1，第三服务器103将指令1转换为音箱能够识别的指令2，第三服务器103将指令2发送给音箱，使得音箱基于指令2执行相应操作。当然，音箱的内部也可以安装有如用于语音识别等转换模块。音箱可以利用转换模块将指令1转换为音箱能够识别的指令2，使得音箱基于指令2执行相应操作。

在另一些实施例中，继续结合图1，通信系统还可以包括：终端104。其中，终端104上可以装载能够与音箱进行通信的应用程序(application，APP)。终端104可以直接与音箱进行通信，也可以通过第三服务器103与音箱进行通信。终端104与音箱可以有线或者无线连接。例如，Wi-Fi直连、蓝牙连接或者ZigBee连接等，本申请对此不作限定。

例如，当用户采用终端104向音箱发送如语音操作、输入操作等形式的指令1时，终端104可以向第三服务器103发送指令1，第三服务器103将指令1转换为音箱能够识别的指令2，第三服务器103将指令2发送给音箱，使得音箱基于指令2执行相应操作。又如，终端104可以向音箱发送指令1，音箱通过自身的转换模块或者第三服务器103得到指令2，使得音箱基于指令2执行相应操作，此处涉及的音乐获取指令2的具体实现方式可参见前文描述，此处不做赘述。

图2示出了本申请一实施例提供的一种音箱的功能框图。在一些实施例中，如图2所示，音箱200可以包括一个或多个输入设备(input device)201，一个或多个输出设备(output device)202和一个或多个处理器(processor)203。其中，输入设备202可以检测各种类型的输入信号(可以简称：输入)，输出设备202可以提供各种类型的输出信息(可以简称：输出)。处理器203可以从一个或多个输入设备201处接收输入信号，响应于该输入信号，产生输出信息，通过一个或多个输出设备202输出。

在一些实施例中，一个或多个输入设备201可以检测各种类型的输入，并提供与检测到的输入相对应的信号(比如，输入信号)，然后一个或多个输入设备201可以将输入信号提供给一个或多个处理器203。在一些示例中，一个或多个输入设备201可以是包括任何能够检测输入信号的部件或组件。比如，输入设备201可以包括音频传感器(比如，一个或多个麦克风)，距离传感器、光学或视觉传感器(比如，摄像头，可见光传感器或不可见光传感器)，接近光传感器，触摸传感器，压力传感器，机械设备(比如，表冠，开关，按钮或按键等)，温度传感器，通信设备(比如，有线或无线通信装置)等，或者，输入设备201也可以是上述各种部件的一些组合。

在一些实施例中，一个或多个输出设备202可以提供各种类型的输出。比如，一个或多个输出设备202可以接收一个或多个信号(比如，由一个或多个处理器203提供的输出信号)，并提供与该信号对应的输出。在一些示例中，输出设备202可以包括用于提供输出的任何合适的部件或组件。比如，输出设备202可以包括音频输出设备(比如，一个或多个扬声器)，视觉输出设备(比如，一个或多个灯或显示器)，触觉输出设备，通信设备(比如，有线或无线通信设备)等等，或者，输出设备202还可以是上述各种部件的一些组合。

在一些实施例中，一个或多个处理器203可以耦合到输入设备201和输出设备202。处理器203可以与输入设备201和输出设备202之间通信。比如，一个或多个处理器203可以从输入设备201接收输入信号(比如，与输入设备201检测到的输入相对应的输入信号)。一个或多个处理器203可以解析接收到的输入信号以确定是否响应于该输入信号提供一个或多个对应的输出。若是，一个或多个处理器203可以向输出设备202发送输出信号，以提供输出。

可以理解的是，图2中示出的设备结构并不构成对音箱的具体限定。在另一些实施例中，音箱可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。图示的部件可以以硬件，软件或软件和硬件的组合实现。

图3示出了本申请一实施例提供的一种音箱的功能框图。在一些实施例中，如图3所示，音箱300可以包括：处理器301、存储器302、通信接口303、麦克风304、扬声器305等，这些部件可通过一根或多根通信总线或信号线(图中未示出)进行通信。

下面结合图3对音箱300的各个部件进行具体的介绍：

处理器301是音箱300的控制中心，利用各种接口和线路连接音箱300的各个部分，通过运行或执行存储在存储器302内的应用程序，以及调用存储在存储器302内的数据，执行音箱300的各种功能和处理数据。

在一些实施例中，处理器301可包括一个或多个处理单元，例如：处理器301可以包括应用处理器(application processor，AP)，调制解调处理器，图形处理器(graphicsprocessing unit，GPU)，图像信号处理器(image signal processor，ISP)，控制器，存储器，视频编解码器，数字信号处理器(digital signal processor，DSP)，基带处理器，和/或神经网络处理器(neural-network processing unit，NPU)等。其中，不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。其中，控制器可以是音箱300的神经中枢和指挥中心。控制器可以根据指令操作码和时序信号，产生操作控制信号，完成取指令和执行指令的控制。在另一些实施例中，处理器301中还可以设置存储器，用于存储指令和数据。在一些实施例中，处理器301中的存储器为高速缓冲存储器。该存储器可以保存处理器301刚用过或循环使用的指令或数据。如果处理器301需要再次使用该指令或数据，可从所述存储器中直接调用，避免了重复存取，减少了处理器301的等待时间，因而提高了系统的效率。处理器301可以运行本申请一些实施例提供的设备控制方法的软件代码/模块，实现控制音箱300的功能。

存储器302用于存储应用程序以及数据，处理器301通过运行存储在存储器302的应用程序以及数据，执行音箱300的各种功能以及数据处理。存储器302主要包括存储程序区以及存储数据区，其中，存储程序区可存储操作系统(Operating System，OS)、至少一个功能所需的应用程序(比如声音播放功能，语音采集功能等)；存储数据区可以存储根据使用音箱时所创建的数据(比如音频数据等)。此外，存储器302可以包括高速随机存取存储器(RAM)，还可以包括非易失存储器，例如磁盘存储器件、闪存器件或其他易失性固态存储器件等。在一些实施例中，存储器302中可以存储“唤醒词”等信息。在另一些实施例中，存储器302中还可以存储音频信息(比如，歌曲、相声、评书等)。并且，存储器302可以存储各种操作系统。上述存储器302可以是独立的，通过上述通信总线与处理器301相连接；存储器302也可以和处理器301集成在一起。

通信接口303可以为有线接口(例如以太网接口)或无线接口(例如蜂窝网络接口或使用无线局域网接口)，例如，通信接口303具体可用于与图1中的第二服务器102进行通信，还用于与如手机、电视等其他设备进行通信，还用于与图1中的第三服务器103进行通信。

在一些实施例中，通信接口303还可提供用户与音箱之间的音频电路。一方面，音频电路可将接收到的音频信号转换后的音频电信号，传输到扬声器305，由扬声器305转换为声音信号输出。另一方面，麦克风304将收集的声音信号(例如用户发出的语音)转换为电信号，由音频电路接收后转换为音频数据(或者语音数据)，再将音频数据输出，例如音箱将音频数据发送至图1中的第三服务器103或者图1中的第二服务器102等，或者将语音数据输出至存储器302以便进一步处理。

麦克风304，也称“话筒”，“传声器”，用于采集声音信号(比如采集用户发出的声音)，将声音信号转换为电信号。在一些实施例中，音箱300上可以设置一个或多个麦克风304，比如麦克风阵列。在另一些实施例中，麦克风304除了采集声音信号，还可以实现对声音信号降噪功能，或者还可以识别声音信号的来源、实现定向录音功能等。

扬声器305，也称“喇叭”，用于将音频电信号转换为声音信号。音箱300可以通过扬声器305播放音乐等声音信号。

在一些实施例中，麦克风304和扬声器305与处理器301耦合。比如，麦克风304接收到声音信号后，将声音信号或者由声音信号转换而成的音频电信号发送给处理器301。处理器301判断是否响应该声音信号或者音频电信号，若是，则输出相应的输出信号，比如通过扬声器305播放音乐。

另外，音箱300可以包含显示器306(或显示屏)，也可以不包含显示器306。显示器306，可以用于显示应用的显示界面，比如当前播放的歌曲等。显示器306包括显示面板。显示面板可以采用液晶显示屏(liquid crystal display，LCD)，有机发光二极管(organiclight-emitting diode，OLED)，有源矩阵有机发光二极体或主动矩阵有机发光二极体(active-matrix organic light emitting diode的，AMOLED)，柔性发光二极管(flexlight-emitting diode，FLED)，Miniled，MicroLed，Micro-oLed，量子点发光二极管(quantum dot light emitting diodes，QLED)等。在一些实施例中，显示器306中可以设置触摸传感器，形成触摸屏，本申请对此不做限定。触摸传感器用于检测作用于其上或附近的触摸操作。触摸传感器可以将检测到的触摸操作传递给处理器301，以确定触摸事件类型。处理器301可以通过显示器306提供与触摸操作相关的视觉输出。

另外，音箱300还可以包括给各个部件供电的电源装置307(比如电池和电源管理芯片)，电池可以通过电源管理芯片与处理器301逻辑相连，从而通过电源装置307实现管理充电、放电、以及功耗管理等功能。

另外，音箱300还可以包括传感器模块308，传感器模块308可以包括气压传感器、温度传感器等。在实际应用中，音箱300还可以包括更多或很少的传感器，或者使用其他具有相同或类似功能的传感器替换上述列举的传感器等等，本申请不做限定。

气压传感器，用于测量气压。在一些实施例中，处理器301可以与气压传感器耦合，通过气压传感器测得的气压值辅助计算，比如计算声音的衰减系数等。

温度传感器，用于检测温度。在一些实施例中，处理器301可以与温度传感器耦合，通过温度传感器测得的温度值辅助计算，比如计算声音的衰减系数等。

可以理解的是，图3中示出的设备结构并不构成对音箱的具体限定。在另一些实施例中，音箱可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。图示的部件可以以硬件，软件或软件和硬件的组合实现。

音箱的软件系统可以采用分层架构，事件驱动架构，微核架构，微服务架构，或云架构。本发明实施例以分层架构的Android系统为例，示例性说明音箱的软件结构。

图4示出了本申请一实施例提供的一种音箱的软件结构框图。

分层架构将软件分成若干个层，每一层都有清晰的角色和分工。层与层之间通过软件接口通信。在一些实施例中，将Android系统分为四层，从上至下分别为应用程序层，应用程序框架层，安卓运行时(Android runtime)和系统库，以及内核层。

应用程序层可以包括一系列应用程序包。

如图4所示，应用程序包可以包括相机，图库，日历，通话，地图，导航，WLAN，蓝牙，音乐，视频，游戏，购物，出行，即时通信(如短信息)，智能家居，设备控制等应用程序。

其中，智能家居应用可用于对具有联网功能的家居设备进行控制或管理。例如，家居设备可以包括电灯、电视和空调。又如，家居设备还可以包括防盗门锁、音箱、扫地机器人、插座、体脂秤、台灯、空气净化器、电冰箱、洗衣机、热水器、微波炉、电饭锅、窗帘、风扇、电视、机顶盒、门窗等。设备控制应用用于对单一设备进行控制或者管理。

另外，应用程序包还可以包括：主屏幕(即桌面)，负一屏，控制中心，通知中心，卡片应用，卡片服务应用等系统应用程序。

其中，负一屏，又可称为“-1屏”，是指在电子设备的主屏幕向右滑动屏幕，直至滑动至最左侧分屏的用户界面(user interface，UI)。例如，负一屏可以用于放置一些快捷服务功能和通知消息，比如全局搜索、应用程序某个页面的快捷入口(付款码、微信等)、即时信息及提醒(快递信息、支出信息、通勤路况、打车出行信息、日程信息等)及关注动态(足球看台、篮球看台、股票信息等)等。控制中心为电子设备的下拉消息通知栏，即当用户在电子设备上进行向下操作时电子设备所显示出的用户界面。通知中心为电子设备的上拉消息通知栏，即当用户在电子设备上进行向上操作时电子设备所显示出的用户界面。卡片服务应用，用于提供卡片服务，以支持卡片的UI显示、卡片在同设备中各个应用程序之间的分享以及卡片在跨设备之间的分享等。

应用程序框架层为应用程序层的应用程序提供应用编程接口(applicationprogramming interface，API)和编程框架。应用程序框架层包括一些预先定义的函数。

如图4所示，应用程序框架层可以包括窗口管理器，内容提供器，视图系统，电话管理器，资源管理器，通知管理器等。

窗口管理器用于管理窗口程序。窗口管理器可以获取显示屏大小，判断是否有状态栏，锁定屏幕，截取屏幕等。

内容提供器用来存放和获取数据，并使这些数据可以被应用程序访问。所述数据可以包括视频，图像，音频，拨打和接听的电话，浏览历史和书签，电话簿等。

视图系统包括可视控件，例如显示文字的控件，显示图片的控件等。视图系统可用于构建应用程序。显示界面可以由一个或多个视图组成的。例如，包括短信通知图标的显示界面，可以包括显示文字的视图以及显示图片的视图。

电话管理器用于提供音箱的通信功能。例如通话状态的管理(包括接通，挂断等)。

资源管理器为应用程序提供各种资源，比如本地化字符串，图标，图片，布局文件，视频文件等等。

通知管理器使应用程序可以在状态栏中显示通知信息，可以用于传达告知类型的消息，可以短暂停留后自动消失，无需用户交互。比如通知管理器被用于告知下载完成，消息提醒等。通知管理器还可以是以图表或者滚动条文本形式出现在系统顶部状态栏的通知，例如后台运行的应用程序的通知，还可以是以对话窗口形式出现在屏幕上的通知。例如在状态栏提示文本信息，发出提示音，音箱振动，指示灯闪烁等。

Android Runtime包括核心库和虚拟机。Android runtime负责安卓系统的调度和管理。

核心库包含两部分：一部分是java语言需要调用的功能函数，另一部分是安卓的核心库。

应用程序层和应用程序框架层运行在虚拟机中。虚拟机将应用程序层和应用程序框架层的java文件执行为二进制文件。虚拟机用于执行对象生命周期的管理，堆栈管理，线程管理，安全和异常的管理，以及垃圾回收等功能。

系统库可以包括多个功能模块。例如：表面管理器(surface manager)，媒体库(Media Libraries)，三维图形处理库(例如：OpenGL ES)，2D图形引擎(例如：SGL)等。

表面管理器用于对显示子系统进行管理，并且为多个应用程序提供了2D和3D图层的融合。

媒体库支持多种常用的音频，视频格式回放和录制，以及静态图像文件等。媒体库可以支持多种音视频编码格式，例如：MPEG4，H.264，MP3，AAC，AMR，JPG，PNG等。

三维图形处理库用于实现三维图形绘图，图像渲染，合成，和图层处理等。

2D图形引擎是2D绘图的绘图引擎。

内核层是硬件和软件之间的层。内核层至少包含显示驱动，摄像头驱动，音频驱动，传感器驱动。

下面结合捕获拍照场景，示例性说明音箱软件以及硬件的工作流程。

当触摸传感器180K接收到触摸操作，相应的硬件中断被发给内核层。内核层将触摸操作加工成原始输入事件(包括触摸坐标，触摸操作的时间戳等信息)。原始输入事件被存储在内核层。应用程序框架层从内核层获取原始输入事件，识别该输入事件所对应的控件。以该触摸操作是触摸单击操作，该单击操作所对应的控件为相机应用图标的控件为例，相机应用调用应用框架层的接口，启动相机应用，进而通过调用内核层启动摄像头驱动，通过摄像头193捕获静态图像或视频。

下面，对本申请中的部分用语进行解释说明，以便于本领域技术人员理解。

1、元能力(atomic ability，AA)：由开发人员开发，是实现单一功能的程序实体，无用户界面(user interface，UI)。且AA与系统服务(system service)存在依赖关系，AA之间不存在依赖关系。其中，系统服务可以包括但不限于：时钟服务(RTC)、连接管理器(WIFI、GSM调制解调器)、定位(GPS)、电源(PMIC)、传感器、通信(GSM调制解调器、WIFI、蓝牙)。

2、特性能力(feature ability，FA)：是通过调用AA和/或FA实现用户特性功能的程序实体。

3、业务FA(又称父FA(Parent FA))，以及服务FA(又称子FA(Child FA)或服务AA(又称子AA(Child AA))：均是程序实体。

业务FA可以虚拟集成服务FA和/或服务AA，使得业务FA与服务FA和/或服务AA之间可以实现数据通信。其中，业务FA采用双线程模型，即渲染线程(Render线程)和事物逻辑处理线程(Worker线程)。Render线程主要负责UI的渲染功能，Worker线程主要负责该UI中展示或操作的数据业务逻辑处理以及数据请求通信。

4、虚拟集成(virtual integration，VI)：开发人员开发业务FA时，需要在业务FA的虚拟集成管理模块配置文件(简称配置文件)中注册业务FA需要依赖的服务FA和/或服务AA。例如存储服务FA的标识(如包名)。

在设备上需要运行业务FA时，第一设备通过配置文件在设备的包管理服务中查找是否有正在运行的服务FA和/或服务AA。若没有，则第一设备可从FA云端服务器(如FA应用市场)中下载并启动服务FA和/或服务AA。其中，本申请提及的FA云端服务器即为第一服务器。

5、卡片和搜索框均是业务FA和服务FA呈现UI的一种方式。其中，卡片可以展示信息且具有跳转功能，例如用户点击播放器卡片中的歌曲A，可跳转到显示歌曲A的歌词的界面，也可以展示信息且具有点击事件触发的业务功能。例如，用户点击播放器卡片中的下一首操作按钮，可实现歌曲切换的功能。另外，卡片可以是开发人员自行开发，也可以从FA应用服务器中下载已有的卡片。

6、元能力管理服务(ability manager service，AMS)：主要负责ability(即FA和/或AA)的运行管理，可以包括ability实例栈的管理、ability生命周期的调度，窗口管理器(Window Manager)管理交互等。

7、包管理服务(bundle manager service，BMS)：主要负责各种资源包(如bundle)的安装，卸载，优化和查询等管理。

8、进程：是指操作系统给每一个应用程序分配的一块独立的内存工作空间。

下面，结合图5A-图10C，对音箱通过音箱FA实现歌曲播放的具体实现过程进行举例。

图5A-图5B示出了本申请一实施例提供的一种设备控制方法的系统架构图。图5C示出了本申请一实施例提供的一种设备控制方法的信令流程图。

如图5A和图5B所示，音乐厂商基于定义的FA/AA开发规范(或接口规范)，开发音乐FA(音乐FA即服务FA和/或服务AA)，并将音乐FA上传到FA云端服务器505中(对应于图5A中的步骤1)。

其中，本申请对FA/AA开发规范的具体实现方式不做限定。另外，音乐FA上传到图5A中的FA云端服务器505的信息可以包括但不限于：音乐FA的标识(如包名)、FA/AA版本号、是否可以虚拟集成、虚拟集成的授权许可方法、AA所需的用户权限、API及功能接口、是否支持数据同步联动以及数据同步联动接口、以及是否需要收费等说明文档。此处的数据同步联动指的是：音箱FA对应的数据(如页面逻辑数据、页面展示数据、图片资源数据等)随着音乐FA对应的数据的改变而改变，音乐FA对应的数据随着音箱FA对应的数据的改变而改变，即音箱FA对应的数据与音乐FA对应的数据保持同步。

需要说明的是，本申请涉及的音乐FA即音乐FA应用。

音箱厂商经与音乐厂商进行洽谈，达成商务合作。音箱厂商基于FA云端服务器505中上传的音乐FA，将音乐FA虚拟集成到音箱FA(音箱FA即业务FA。)

需要说明的是，本申请涉及的音箱FA即音箱FA应用。

其中，音箱FA虚拟集成音乐FA的具体实现过程可以理解为：开发人员在音箱FA的配置文件中注册音箱FA需要依赖的音乐FA，例如存储音乐FA的标识(如包名)。即，开发人员预先配置好音箱FA与音乐FA之间的依赖关系，而非将音乐FA的实体集成在音箱FA中。

下面，结合图6A和图6B，对相关技术中的音箱APP实体集成音乐厂商的SDK和本申请中的音箱FA虚拟集成音乐FA的具体实现过程进行介绍。

如图6A所示，相关技术中，从音箱APP的创建到运行的具体实现过程可以包括：步骤11-步骤15。

步骤11、在集成开发环境(integrated development environment，IDE)开发阶段，从音乐厂商的SDK服务器(如音乐厂商SDK官网)下载音乐厂商的SDK，并编写音箱APP的APP业务代码和SDK依赖配置文件。

步骤12、在IDE编译打包阶段，将APP业务代码、SDK依赖配置文件和音乐厂商的SDK进行编译打包处理，得到音箱APP。

步骤13、在应用上架阶段，在音箱厂商的APP云端服务器(如APP应用市场)上上架音箱APP。另外，音箱厂商的APP应用市场中还可以包括：聊天类APP(图6A中以wechat APP为例进行示意)和支付类APP(图6A以alipay APP为例进行示意)等。

步骤14、在应用下载使用阶段，音箱从音箱厂商的APP应用市场上下载音箱APP。另外，音箱还可以从音箱厂商的APP应用市场上下载wechat APP和alipay APP等。需要说明的是，从音箱APP下载音箱APP并不依赖于从音箱APP下载wechat APP和alipay APP等，从音箱APP下载wechat APP和alipay APP等，用于表明音箱还可以下载除了音箱APP之外的其他APP。

步骤15、在音箱APP运行阶段的进程视角，APP业务代码、SDK依赖配置文件和音乐厂商的SDK均运行在音箱APP进程中。

综上，相关技术中，音箱厂商需要独立开发自己的音箱APP，并需要实体集成音乐厂商的SDK，且将音箱APP安装在音箱中，导致音箱APP的数据包较大，占用较多的存储和运行空间。由于音乐厂商的SDK与音箱APP进程同属于一个进程，因此，音乐厂商的SDK无论使用与否都会占用存储空间。且音乐厂商的SDK的功能接口较多，对接流程和时间成本均较高。另外，音乐厂商的SDK无法单独运行。

如图6B所示，相关技术中，从音箱FA的创建到运行的具体实现过程可以包括：步骤21-步骤25。

步骤21、在IDE开发阶段，从FA云端服务器505(如FA应用市场)下载音乐FA，并编写音箱FA的FA业务代码和AA/FA依赖配置文件，使得音箱FA的开发人员通过对音乐FA的各个接口和功能进行调试，能够预览音箱FA展示的界面、获知和确认音乐FA中音乐FA实现的具体功能等。其中，在AA/FA依赖配置文件中注册有音乐FA的标识。

步骤22、在IDE编译打包阶段，将音乐FA的FA业务代码和AA/FA依赖配置文件进行编译打包处理，得到音箱FA。

步骤23、在FA上架阶段，在FA应用市场上上架音箱FA。另外，FA应用市场中还可以包括：聊天类FA(图6B中以wechat FA为例进行示意)、支付类FA(图6B中以alipay FA为例进行示意)和扫描类FA(图6B中以scan FA为例进行示意)等。

步骤24、在FA下载使用阶段，音箱从FA应用市场上下载音箱FA。另外，音箱还可以从FA应用市场上下载wechat FA、alipay FA和scan FA等。需要说明的是，从音箱APP下载音箱FA并不依赖于从音箱APPwechat FA、alipay FA和scan FA等，从音箱APPwechat FA、alipay FA和scan FA等，用于表明音箱还可以下载除了音箱FA之外的其他FA。

步骤25、在FA运行阶段的进程视角，音箱FA的FA业务代码和AA/FA依赖配置文件均运行在音箱FA进程中，音乐FA运行在音乐FA进程中，且音箱FA进程与音乐FA进程为不同的两个进程。其中，若音箱中未包含音乐FA，则音箱FA基于AA/FA依赖配置文件中注册有音乐FA的标识，从FA应用市场上依赖下载音乐FA。

综上，本申请中，音箱厂商基于上传的音乐FA，在音箱FA中存储音乐FA的标识，实现音箱FA虚拟集成音乐FA，并将音箱FA安装在音箱中，使得音箱FA的数据包较小，占用较小的存储和运行空间，较少了用户下载音箱FA时的流量消耗。

在音箱FA请求音乐厂商的音乐资源时，音箱FA通过虚拟集成的音乐FA，可以从音乐厂商的服务器(即第二服务器502)中获取到音乐资源(如歌曲的资源)，使得音箱基于音乐资源能够播放歌曲，还保障了音箱FA与音乐FA之间的数据同步联动，且通过音箱FA与音乐FA之间的数据同步联动远比音乐厂商的SDK的开发和对接成本低。

由于音箱FA进程与音乐FA进程为不同的两个进程，因此，音乐FA在音箱FA需要调用音乐FA时会占用存储空间，在音箱FA无需调用音乐FA时不会占用存储空间，降低了音箱FA运行时的存储内存和运行内存开销，有利于提升存储空间的使用率。

在音乐FA运行完成之后，音箱的操作系统可以根据内存资源等影响因素，管控并查杀音乐FA(对应于图5B中的步骤7)，即不仅可以监控音乐FA的运行情况等参数，进而及时获知是否可以调用音乐FA，还可以在无需音乐FA时释放音乐FA进程以及释放从FA应用市场上下载的音乐FA等相关资源，进而节省音箱的内存开销。

另外，音乐FA可独立运行，还可虚拟集成在除了音箱FA之外的其他FA中，使得音箱FA和其他FA能够分别调用音乐FA。需要说明的是，音箱FA和其他FA一般不能同时调用音乐FA，可基于调用策略确定音箱FA调用音乐FA和其他FA调用音乐FA的顺序。

基于前述描述，音箱厂商将虚拟集成有音乐FA的音箱FA安装在音箱501中(对应于图5A中的步骤2)，从而音箱501无需实体集成音乐厂商的SDK，通过音箱FA虚拟集成音乐FA，并能够实现音乐播放的功能。

下面，继续结合图5A-图5B，如图5C所示，本申请的设备控制方法的具体实现过程可以包括：步骤S101-S115。

S101、音箱501响应于用户的输入，(如调用startAbility()函数)请求启动音箱FA进程。其中，用户的输入用于表示用户向音箱501请求播放歌曲Love Story。需要说明的是，本申请提及的启动与调用的含义相同。

音箱FA进程对应于音箱FA应用，用于通过音乐FA从第二服务器502获取音乐资源，且基于音乐资源通过音箱501实现歌曲播放。

一般情况下，每首歌曲具有唯一的标识，即身份标识(identity document，ID)，如采用歌曲名称或者歌曲编号等表示形式。故，在一些实施例中，用户的输入可以携带有歌曲Love Story的标识。其中，本申请的用户的输入可以包括多种可行的实现方式，使得用户采用多种方式向音箱501请求播放歌曲Love Story。

下面，结合三种场景，对用户请求音箱播放歌曲Love Story的具体实现过程进行举例。

在一些实施例中，终端504装载有与音箱501进行通信的音箱FA。终端504通过与音箱FA之间的连接，可以向音箱FA发送用户的输入，也可以通过与第三服务器503的连接，借助第三服务器503向音箱FA发送用户的输入，本申请对此不做限定。

从而，音箱FA应用响应于用户的输入，可以确定出用户需求。其中，用户的输入可以采用点击、滑动、长按等至少一个操作进行表示，也可以采用语音、图片等输入进行表示，本申请对此不做限定。

图7示出了本申请一实施例提供的一种设备控制方法的场景示意图。图8A-图8D示出了本申请一实施例提供的一种人机交互界面示意图。图7-图8D中，以终端为手机以及终端与音箱蓝牙连接为例进行示意。

如图7所示，用户通过手机中的音箱FA向音箱请求播放歌曲Love Story，如手机向音箱发送歌曲Love Story的标识。其中，音箱FA 801的图标可以位于手机的桌面，也可以位于手机的通知中心，本申请对音箱FA 801的图标的具体位置、形状大小等参数不做限定。

以音箱FA 801的图标位于手机的桌面为例进行示意。手机的显示器显示如图8A所示的界面，该界面上显示有音箱FA 801的图标，用户在如图8A所示的界面上点击音箱FA801的图标。

其中，桌面应用响应于点击操作，调用startAbility()函数启动音箱FA进程，具体过程可以包括：步骤31-步骤37。

步骤31、Launcher进程通过IPC通信向system_server进程发起startAbility请求。

步骤32、system_server进程接到请求后，向zygote进程发送创建进程请求。

步骤33、zygote进程fork出新的子进程，即音箱FA进程。

步骤34、音箱FA进程向system_server进程发起attachApplication请求。

步骤35、system_server进程在收到请求后，进行一系列准备工作后，再通过IPC通信向音箱FA进程发送startAbility请求。

步骤36、音箱FA进程在接收到请求后向音箱FA进程中的主线程发送启动消息。

步骤37、音箱FA进程中的主线程在收到启动消息后，创建目标ability并回调ability的生命周期方法。

到此，音箱FA进程便正式启动起来，即音箱FA 801运行起来。此时，在一些实施例中，手机的显示器从如图8A所示的界面变为如图8B所示的音箱FA的界面，音箱FA的界面用于展示音箱FA。

其中，音箱FA的界面可以利用音乐FA的界面，也可以利用音箱FA的开发人员自行开发的界面，也可以利用前述两种实现方式，本申请对此不做限定。例如，图8B中，音箱FA的界面上显示有音箱FA的名称“AI华为音箱”、搜索框802、卡片A 803和卡片B 804。

搜索框802，用于通过接收用户输入的文字、图片、语音等，并利用自行开发的界面，显示对应的搜索结果。例如，图8B中，搜索框802中显示有搜索图标、文字“搜索”以及用于表示提供搜索资源的对象，如采用文字“QQ音乐和网易云音乐”表示。

卡片A 803，用于利用QQ音乐的排行榜的界面，向用户展示歌曲的排行榜。例如，卡片A 803中包含有QQ音乐的图标、文字“排行榜”、三首歌曲名称以及三首歌曲名以及每首歌曲的歌手名(此处不限于图8B所示的歌曲名称和歌手名)。

卡片B 804，用于利用网易云音乐的最近播放的界面，向用户展示播放情况。例如，卡片B 804中包含有网易云音乐的图标、文字“最近播放”、歌曲名称Dangerously、歌曲Dangerously的歌手名Charlie Puth、上一首图标的操作按钮、播放/暂停图标的操作按钮和下一首图标的操作按钮、加入收藏的操作按钮等。

用户在如图8B所示的界面上点击音箱FA的搜索框802并在搜索框802内输入LoveStory，手机的显示器显示如图8C所示的界面，该界面中包括搜索框802下拉菜单，用于向用户提供Love Story的搜索结果(如Love Story的来源和品质)。例如，在图8C所示的界面中显示有QQ音乐Love Story标准品质、QQ音乐Love StoryHQ高品质、网易云音乐Love Story标准品质、网易云音乐Love Story较高品质等搜索结果。

用户可以在图8C所示的界面上点击QQ音乐Love StoryHQ高品质这个搜索结果，使得手机向音箱发送播放来源于QQ音乐的HQ高品质的歌曲“Love Story”的请求。从而，音箱能够获知用户请求音箱播放歌曲Love Story的需求，显示如图8D所示。

在另一些实施例中，音箱501包含显示器5011。音箱501中装载有音箱FA，音箱FA响应于用户的输入，可以确定出用户需求。其中，用户的输入可以采用点击、滑动、长按等至少一个操作进行表示，也可以采用语音、图片等输入进行表示，本申请对此不做限定。

图9示出了本申请一实施例提供的一种设备控制方法的场景示意图。图10A-图10D示出了本申请一实施例提供的一种人机交互界面示意图。

如图9所示，用户通过音箱中的音箱FA应用向音箱请求播放歌曲Love Story，如音箱接收到歌曲Love Story的标识。以音箱FA 1001的图标位于音箱的桌面的上方为例进行示意。音箱的显示器显示如图10A所示的界面，该界面上显示有音箱FA 1001的图标，用户在如图10A所示的界面上点击音箱FA 1001的图标。

音箱的显示器从如图10A所示的界面变为如图10B所示的音箱FA的界面。其中，音箱FA的界面在音箱的显示器的界面可以与音箱FA的界面在手机的显示器的界面可以相同，也可以不同，本申请对此不做限定。为了便于说明，图10B所示的音箱FA的界面与图8B所示的音箱FA的界面的内容相同，界面布局不同。

用户在如图10B所示的界面上点击音箱FA的搜索框并在搜索框内输入LoveStory，音箱的显示器显示如图10C所示的界面，该界面中包括搜索框下拉菜单，用于向用户提供Love Story的搜索结果(如Love Story的来源和品质)。例如，在图10C所示的界面中显示有QQ音乐Love Story标准品质、QQ音乐Love StoryHQ高品质、网易云音乐Love Story标准品质、网易云音乐Love Story较高品质等搜索结果。

用户可以在图10C所示的界面上点击QQ音乐Love StoryHQ高品质这个搜索结果，使得音箱获知用户需要音箱播放来源于QQ音乐的HQ高品质的歌曲“Love Story”的请求。从而，音箱能够获知用户请求音箱播放歌曲Love Story的需求。

在另一些实施例中，音箱501具备语音识别的功能，可以识别出用户的语音输入，从而确定出用户需求。其中，本申请对语音输入的具体实现方式不做限定。例如，语音输入中包括唤醒音箱的关键词和请求音箱501进行操作的具体内容

其中，本申请对音箱501实现语音识别的具体实现方式不做限定。

例如，音箱501可以将用于语音识别的转换模块集成在音箱501中，由音箱501自身通过用于语音识别的转换模块对用户的语音输入进行语音识别。

又如，音箱501中的音箱FA与第三服务器503连接，音箱FA可以向第三服务器503发送用户的语音输入，由第三服务器503利用语音识别技术对语音输入进行识别，得到语音识别结果，第三服务器503再向音箱FA传输语音识别结果。

图11示出了本申请一实施例提供的一种设备控制方法的场景示意图。如图11所示，用户对音箱说：“小艺小艺”，使得音箱被唤醒。其中，“小艺小艺”为唤醒音箱的关键字。一般情况下，被唤醒前的音箱可以处于低功耗状态。在音箱被唤醒之后，音箱说：“我在”，使得用户确认音箱已被唤醒。用户接着对音箱说：“播放歌曲Love Story”。其中，“播放歌曲Love Story”为请求音乐进行操作的具体内容，即通知音箱执行播放的操作及通知音箱进行播放歌曲Love Story的标识。从而，音箱利用语音识别技术，基于用户的语音输入可以获知用户请求音箱播放歌曲Love Story的需求，如音箱识歌曲Love Story的标识。

另外，在音箱包含显示器时，音箱的显示器显示如图12A所示的界面，如该界面上显示有文字“播放歌曲Love Story”，从而音箱通过该界面向用户提示音箱的语音识别结果，使得用户确认该语音识别结果是否准确，方便及时做出修改。

需要说明的是，音箱501可以不限于上述几种方式获取到用户的输入。另外，音箱501的应用以及手机的其他应用启动音箱FA进程的过程具体可参见手机的桌面应用启动音箱FA进程的描述内容，此处不做赘述。

S102、音箱501的操作系统判断音箱FA进程是否正在运行。

本领域技术人员可以理解，当任意一个进程正在运行时，设备的操作系统会在进程列表中注册该进程的标识。故，音箱501的操作系统可以在进程列表中查询是否存在音箱FA进程的标识，来确定音箱FA进程是否正在运行。

若音箱FA进程没有正在运行，则执行步骤S103。若音箱FA进程正在运行，则执行步骤S104。

S103、音箱501如调用startAbility()函数启动音箱FA进程，并向音箱FA进程发送歌曲的标识。

在一些实施例中，音箱501启动音箱FA进程的具体实现过程可以包括：步骤41-步骤47。

步骤41、音箱501的操作系统进程通过IPC通信向system_server进程发起startAbility请求；

步骤42、system_server进程接到请求后，向zygote进程发送创建进程请求；

步骤43、zygote进程fork出新的子进程，即音箱FA进程；

步骤44、音箱FA进程向system_server进程发起attachApplication请求；

步骤45、system_server进程在收到请求后，进行一系列准备工作后，再通过IPC通信向音箱FA进程发送startAbility请求；

步骤46、音箱FA进程在接收到请求后向音箱FA进程中的主线程发送启动消息；

步骤47、音箱FA进程中的主线程在收到启动消息后，创建目标ability并回调ability的生命周期方法。

到此，音箱FA进程便正式启动起来。

S104、音箱501向音箱FA进程发送歌曲的标识。

S105、音箱FA进程如调用startAbility()函数请求启动音乐FA进程。

需要说明的是，音箱501的操作系统会实时检测各个进程的运行情况，因此，音箱501的操作系统可以检测到音箱FA进程请求启动音乐FA进程(对应于图5B中的步骤1)，进而，音箱501的操作系统可以执行步骤S106中的在BMS中查询音乐FA的标识。

S106、音箱501的操作系统判断BMS中是否存在音乐FA的标识(对应于图5B中的步骤2)，使得音箱501可以查询音箱本地(如音箱501的ROM、RAM等)是否存在音乐FA的bundle。其中，在服务FA或者服务AA安装到音箱501中时会在BMS中进行注册，如存储有服务FA的标识或者服务AA的标识，因此操作系统可通过BMS是有存在音乐FA，判断音响501中是否已安装音乐FA。

若BMS中不存在音乐FA的标识，则执行步骤S107-S109。若BMS中存在音乐FA的标识，则执行步骤S110-S115。

S107、音箱501的操作系统向FA云端服务器505发送下载音乐FA请求(对应于图5A中的步骤3，以及对应于图5B中的步骤3)。其中，下载音乐FA请求用于指示FA云端服务器505将音乐FA的bundle发送给音箱501。在一些实施例中，下载音乐FA请求中包括音乐FA的标识。

S108、FA云端服务器505基于下载音乐FA请求，向音箱501的操作系统发送音乐FA的bundle(对应于图5A中的步骤4，以及对应于图5B中的步骤4)。

S109、音箱501的操作系统通过对音乐FA的bundle进行解包处理，将音乐FA安装在音箱本地中，且在BMS中注册音乐FA(如存储音乐FA的标识)(对应于图5B中的步骤5)，并继续执行S106，直至BMS中存在音乐FA的标识(即音箱本地存在音乐FA的bundle)为止。其中，由于音箱501的操作系统可能会出现安装音乐FA失败的情况，导致BMS中未注册音乐FA，因此，音箱501的操作系统需要继续执行S106，确定音乐FA是否安装到音乐501中。

S110、音箱FA进程如调用startAbility()函数启动音乐FA进程(对应于图5B中的步骤6)。其中，由于音箱501本地存在音乐FA进程的bundle，因此，音箱FA进程可以顺利启动音乐FA进程。另外，音箱501的操作系统也可以向音箱FA进程通知音箱501本地存在音乐FA的bundle，使得音箱FA进程去启动音乐FA进程。

在一些实施例中，音箱FA进程启动音乐FA进程的具体实现过程可以包括：步骤51-步骤57。

步骤51、音箱FA进程通过IPC通信向system_server进程发起startAbility请求；

步骤52、system_server进程接到startAbility请求后，向zygote进程发送创建进程请求；

步骤53、zygote进程派生(fork)出新的子进程，即音乐FA进程。

步骤54、音乐FA进程向system_server进程发起attachApplication请求；

步骤55、system_server进程在收到attachApplication请求后，进行一系列准备工作后，再通过IPC通信向音乐FA进程发送startAbility请求；

步骤56、音乐FA进程在接收到请求后向音乐FA进程中的主线程发送启动消息；

步骤57、音乐FA进程中的主线程在收到启动消息后，创建目标ability并回调ability的生命周期方法。

到此，音乐FA进程便正式启动起来。

S111、音箱FA进程在音乐FA进程启动之后，向音乐FA进程发送第一音乐资源请求(对应于图5A中的步骤5)。其中，第一音乐资源请求用于向音乐FA请求歌曲Love Story的音乐资源。在一些实施例中，第一音乐资源请求中包括歌曲Love Story的标识。

S112、音乐FA进程向第二服务器501(即音乐FA对应的服务器)发送第二音乐资源请求(对应于图5A中的步骤6)。其中，第二音乐资源请求用于向音乐FA请求歌曲Love Story的音乐资源。在一些实施例中，第二音乐资源请求中包括歌曲Love Story的标识。

需要说明的是，第一音乐资源请求和第二音乐资源请求的实质内容相同，均用于向音乐FA请求歌曲Love Story的音乐资源，第一音乐资源请求和第二音乐资源请求的表示形式可以相同或者不同，本申请对此不做限定。

S113、第二服务器501向音乐FA进程发送音乐资源(对应于图5A中的步骤7)。在一些实施例中，音乐资源为与歌曲的标识对应的歌曲的资源。

S114、音乐FA进程向音箱FA进程发送该音乐资源(对应于图5A中的步骤8)。

S115、音箱FA进程基于该音乐资源播放歌曲Love Story。

继续结合图7的场景，在音箱播放歌曲Love Story的同时，音箱FA可以向终端返回歌曲播放通知。其中，歌曲播放通知用于向终端告知音箱播放歌曲Love Story以及播放进度等各种信息。从而，音箱FA在手机的显示器上的界面从如图8C所示变为如图8D所示。其中，图8C和图8D相比，在音箱FA的卡片B 804中，图8C中的歌曲名称Dangerously变为图8D中的歌曲名称Love Story，图8C中的歌曲Dangerously的歌手名Charlie Puth变为图8D中的歌曲名称Taylor Swift，图8C中的暂停图标的操作按钮变为图8D中的播放图标的操作按钮，音箱FA的界面中的其余部分未发生变化。

继续结合图9的场景，在音箱包含显示器时，音箱FA在音箱的显示器上的界面从如图10C所示变为如图10D所示。其中，图10C和图10D相比，在音箱FA的卡片B中，图10C中的歌曲名称Dangerously变为图10D中的歌曲名称Love Story，图10C中的歌曲Dangerously的歌手名Charlie Puth变为图10D中的歌曲名称Taylor Swift，图10C中的暂停图标的操作按钮变为图10D中的播放图标的操作按钮，音箱FA的界面中的其余部分未发生变化。

继续结合图11的场景，在音箱包含显示器时，音箱的显示器从如图12A所示的界面变为如图12B所示的界面。其中，该界面可以包括但限于：歌曲Love Story的歌曲名称、歌曲Love Story的歌手名Taylor Swift、歌曲歌词、上一首图标的操作按钮、播放/暂停图标的操作按钮和下一首图标的操作按钮、单曲循环图标的操作按钮、播放列表图标的操作按钮、歌曲播放进度条的操作按钮、歌曲起始时刻、歌曲终止时刻等。

综上，音箱厂商借助音箱FA虚拟集成音乐FA(即音箱FA与音乐FA之间的依赖关系)，可从音乐FA对应的服务器中获取音乐资源，并基于音乐资源实现歌曲播放的功能。

基于前述描述，音箱FA可以没有界面，也可以有界面。若音箱FA有界面，则开发人员或者用户可以利用音乐FA的界面来创建音箱FA，也可以自行开发新的界面来显示音箱FA，也可以利用前述两种方式来创建音箱FA，本申请对此不做限定。

下面，音箱FA的界面以图8B所示的界面为例，结合图13A-图13H，对开发人员或者用户在手机上创建音箱FA的具体实现方式进行举例。

图13A-图13H示出了本申请一实施例提供的一种人机交互界面示意图。图13A示出了手机桌面的界面，开发人员或者用户在手机桌面的界面上向右滑动，手机的显示器显示如图13B所示的手机的负一屏的界面。开发人员或者用户在负一屏的界面上点击创建小程序的卡片，手机的显示器显示如图13C所示的界面。开发人员或者用户在图13C所示的界面上点击音乐小程序的卡片，手机的显示器显示如图13D所示的界面。

其中，该界面上显示有文字“小程序名称”和用于文字“请输入小程序卡片名称”提示的输入框，方便开发人员或者用户为创建的音箱FA的界面命名。

其中，该界面还包括文字“添加音乐卡片”、文字“所有卡片”和选项1301，该选项1301中的卡片用于向用户展示音乐FA，此处的音乐FA可以是手机已从FA云端服务器(如FA应用市场)中下载的音乐FA，即已下载的音乐FA，也可以是手机可从FA云端服务器(如FA应用市场)中下载的音乐FA，即可下载的音乐FA。通常，不同卡片对应的音乐FA同属于一个音乐厂商时，同属于一个音乐厂商的不同卡片会集中显示，如布局在同一个圆角矩形框中；不同卡片对应的音乐FA属于不同的音乐厂商时不同的卡片会分开显示，如布局在不同的圆角矩形框中。

例如，该选项1301中有两个圆角矩形框，其中一个圆角矩形框包括卡片1、卡片2、卡片3和卡片4，另一个圆角矩形框包括卡片5、卡片6和卡片7。

其中，卡片1显示有卡片名称“QQ音乐我的收藏”、QQ音乐图标以及用于添加卡片1的操作按钮1302。卡片2显示有卡片名称“QQ音乐最近播放”、QQ音乐图标以及用于添加卡片2的操作按钮1302。卡片3显示有卡片名称“QQ音乐排行榜”、QQ音乐图标以及用于添加卡片3的操作按钮1302。卡片4显示有卡片名称“QQ音乐搜索框”、QQ音乐图标以及用于添加卡片4的操作按钮1302。卡片5显示有卡片名称“网易云音乐今日推荐”、网易云音乐图标以及用于添加卡片5的操作按钮1302，卡片6显示有卡片名称“网易云音乐最近播放”、网易云音乐图标以及用于添加卡片6的操作按钮1302。卡片7显示有卡片名称“网易云音乐搜索框”、网易云音乐图标以及用于添加卡片7的操作按钮1302。且卡片1、卡片2、卡片3、卡片4、卡片5、卡片6和卡片7中各自的操作按钮1302均以圆圈内包含加号的图标为例进行示意。

另外，该界面上还显示有用于添加新的卡片的操作按钮1303，以圆圈内包含加号的图标为例进行示意。若有新下载的卡片，则新下载的卡片会添加至选项1301中。

开发人员或者用户可以从如图13D所示的界面上选择已下载好的卡片，如卡片1、卡片2、卡片3、卡片4、卡片5、卡片6和卡片7中的至少一个，或者选择从FA云端服务器中新下载的卡片，或者选择已下载好的卡片以及从FA云端服务器中新下载的卡片。

若开发人员或者用户选择卡片3、卡片4、卡片6和卡片7，则手机的显示器显示如图13E所示的界面。其中，与图13D所示的界面不同的是：该界面新增了文字“已添加卡片”和选项1304，选项1304中的卡片为开发人员或者用户所选择的全部卡片(即卡片3、卡片4、卡片6和卡片7)，且选项1301中的卡片去除了选择的卡片(即去除了卡片3、卡片4、卡片6和卡片7，保留有了卡片1、卡片2和卡片5)。

开发人员或者用户可以在如图13E所示的界面上点击对勾图标，手机的显示器显示如图13F所示的界面，该界面用于向开发人员或者用户提供音箱FA的界面的预览。

例如，图13E所示的音箱FA的界面中，搜索框采用的是自行开发的界面进行显示，搜索框的搜索结果依赖于QQ音乐厂商的服务器和网易云音乐厂商的服务器。卡片A对应于卡片3，卡片A采用QQ音乐的排行榜的界面进行显示。卡片B对应于卡片6，卡片B采用网易云音乐的最近播放的界面进行显示。

从而，使得开发人员或者用户能够及时了解音箱FA的界面，还使得开发人员或者用户能够及时修改音箱FA的界面，如开发人员或者用户点击该界面上的向左箭头图标，则手机的显示器返回如图13E所示的界面，便于开发人员或者用户重新选择卡片。

开发人员或者用户可以在如图13F所示的界面上点击对勾图标，则音箱FA的界面可以显示在手机的负一屏的界面上，如图13G所示的音箱FA的界面续接在支付方式的卡片之后进行显示。若如图13G所示的音箱FA的界面无法全部显示，则开发人员或者用户在图13G所示的界面上向下滑动，使得音箱FA的界面如图13H所示在手机的显示器上显示完整。

在另一些实施例中，开发人员或者用户可以将第一设备中嵌入到第一应用的第一卡片拖拽到第一设备中的第二应用中。其中，第一应用和第二应用所显示的第一卡片的界面可以相同，也可以不同，本申请对此不做限定。例如，用户将显示在手机的负一屏中的音箱FA拖拽到手机的桌面中，使得桌面也能够显示音箱FA。从而，使得音箱FA具备丰富的显示渠道。

综上，开发人员可以制定出各种类型的音箱FA的界面，为用户提供了丰富的界面选择。用户也可以制定出各种类型的音箱FA的界面，实现了个性化界面的制定。另外，用户在需要使用音箱FA时，也可以从FA云端服务器(如FA应用市场)中下载音箱FA，并将音箱FA安装到终端或者音箱中，如图8A所示的音箱FA 801的图标或者图10A所示的音箱FA 1001的图标。

基于上述描述，继续结合图13H，下面介绍音箱FA的搜索框的搜索结果依赖QQ音乐厂商的服务器和网易云音乐厂商的服务器的具体实现过程。

图14示出了本申请一实施例提供的一种场景软件架构示意图。在音箱FA的搜索框有用户的输入(如Love Story)时，音箱FA进程基于用户的输入向QQ音乐的搜索框FA进程和网易云音乐的搜索框FA进程发送搜索请求(对应于图14中的步骤1)。

其中，QQ音乐的搜索框FA进程对应于QQ音乐的搜索框FA。网易云音乐的搜索框FA进程对应于网易云音乐的搜索框FA。且QQ音乐的搜索框FA是由QQ音乐厂商分布到FA云端服务器(如FA应用市场)中的服务FA。网易云音乐的搜索框FA是由网易云音乐厂商分布到FA云端服务器(如FA应用市场)中的服务FA。

QQ音乐的搜索框FA进程中的Worker线程通过解析搜索请求，向QQ音乐厂商的服务器发送数据请求((对应于图14中的步骤21)。QQ音乐厂商的服务器将搜索资源返回给QQ音乐的搜索框FA进程中的Worker线程(对应于图14中的步骤22)。QQ音乐的搜索框FA进程中的Worker线程将搜索资源进行逻辑处理，得到对应的搜索结果，如QQ音乐Love Story标准品质和QQ音乐Love StoryHQ高品质等。QQ音乐的搜索框FA进程中的Worker线程向音箱FA返回搜索结果(对应于图14中的步骤23)。

同样地，网易云音乐的搜索框FA进程中的Worker线程通过解析搜索请求，向网易云音乐厂商的服务器发送数据请求(对应于图14中的步骤31)。网易云音乐厂商的服务器将搜索资源返回给网易云音乐的搜索框FA进程中的Worker线程(对应于图14中的步骤32)。网易云音乐的搜索框FA进程中的Worker线程将搜索资源进行逻辑处理，得到对应的搜索结果，如网易云音乐Love Story标准品质和网易云音乐Love Story较高品质等。网易云音乐的搜索框FA进程中的Worker线程向音箱FA返回搜索结果(对应于图14中的步骤33)。

音箱FA进程中的Worker线程基于QQ音乐的搜索框FA进程返回的搜索结果和网易云音乐的搜索框FA进程返回的搜索结果，向音箱FA进程中的Render线程FA发送搜索数据。音箱FA进程中的Render线程对搜索数据进行渲染处理，使得手机的显示器显示如图8C所示的界面。其中，本申请对不同音乐厂商返回的搜索结果在该界面上的排列方式、位置布局、显示大小等参数不做限定。

需要说明的是，手机的显示器显示图10C的界面的具体实现方式可参见手机的显示器显示如图8C所示的界面的描述内容，本申请对此不做赘述。另外，由于用户的输入会引起音箱FA的界面发生变化，而无需音箱FA的界面发生跳转，因此，QQ音乐的搜索框FA和网易云音乐的搜索框FA可以为有UI的服务FA，也可以为无UI的服务FA，也可以为无UI的服务AA，本申请对此不做限定。

综上，音箱FA的搜索框依赖QQ音乐厂商的服务器和网易云音乐厂商的服务器所提供的搜索资源，可实现搜索结果的界面显示。除了依赖QQ音乐厂商的服务器和网易云音乐厂商的服务器所提供的搜索资源之外，音箱FA的搜索框还可以依赖音箱厂商的服务器提供搜索资源。

基于上述描述，卡片B可以在音箱FA的界面上可以发生内容变化，如卡片B的内容从图8C变化至图8D，或者从图10C变化至图10D。下面以音箱FA的界面为如图13H所示的界面为例，介绍界面跳转的具体实现过程。

图15示出了本申请一实施例提供的一种场景软件架构示意图。在音箱FA的卡片B上的操作按钮有用户的输入(如点击等操作)时，音箱FA进程基于用户的输入向网易云音乐的最近播放FA进程发送界面显示请求(对应于图15中的步骤1)。

网易云音乐的最近播放FA进程中的Worker线程通过解析界面显示请求，向网易云音乐厂商的服务器发送数据请求(对应于图15中的步骤2)。网易云音乐厂商的服务器将请求资源返回给网易云音乐的最近播放FA进程中的Worker线程(对应于图15中的步骤3)。网易云音乐的最近播放FA进程中的Worker线程将请求资源进行逻辑处理，得到对应的显示数据。网易云音乐的最近播放FA进程中的Worker线程向音箱FA进程中的Worker线程返回显示数据(对应于图15中的步骤4)。音箱FA进程中的Worker线程向音箱FA进程中的Render线程返回显示数据(对应于图15中的步骤5)。音箱FA中的Render线程对显示数据进行渲染处理，使得手机的显示器显示图8D或者图10D所示的界面。

需要说明的是，由于用户的输入需要音乐FA的界面跳转至卡片B的界面，因此，网易云音乐的最近播放FA为有UI的服务FA。

由于用户的输入会引起音箱FA的界面发生变化，而无需音箱FA的界面发生跳转，因此，QQ音乐的搜索框FA和网易云音乐的搜索框FA可以为有UI的服务FA，也可以为无UI的服务FA，也可以为无UI的服务AA，本申请对此不做限定。

需要说明的是，由于用户的输入会引起音箱FA的界面发生变化，而无需音箱FA的界面进行跳转，因此，网易云音乐的最近播放FA可以为服务FA(即可有UI)，也可以为服务AA(即可没有UI)，本申请对此不做限定。

综上，卡片B在音箱FA的界面上的内容依赖网易云音乐的最近播放FA所提供的资源，可实现卡片B在音箱FA的界面上的内容变化。

基于上述描述，音箱FA的界面可以跳转到卡片A的界面。下面，以音箱FA的界面为如图13H所示的界面为例，介绍界面跳转的具体实现过程。

图16A-图16B示出了本申请一实施例提供的一种人机交互界面示意图。用户在如图16A所示的界面上点击音箱FA的卡片A的空白处，手机的显示器跳转至如图16B所示的卡片A的界面，该界面用于向用户提供来源于QQ音乐的排行榜的音乐资源。例如，在图16B所示的界面中显示有文字“本周排行榜”、“精选每周热门排行”、播放全部的操作按钮、文字“共40首”以及歌曲列表(包括每首歌曲的歌曲名称和歌手名)等。从而，使得用户可以浏览到QQ音乐的排行榜中的歌曲。

图17示出了本申请一实施例提供的一种场景软件架构示意图。在音箱FA的卡片A上除操作按钮之外的区域有用户的输入时，音箱FA进程基于用户的输入向QQ音乐的排行榜FA进程发送界面跳转请求(对应于图17中的步骤1)。其中，QQ音乐的排行榜FA进程对应于QQ音乐的排行榜FA。QQ音乐的排行榜FA是由QQ音乐厂商分布到FA云端服务器(如FA应用市场)中的服务FA。

QQ音乐的排行榜FA进程中的Worker线程通过解析界面跳转请求，向QQ音乐厂商的服务器发送数据请求(对应于图17中的步骤2)。QQ音乐厂商的服务器将请求资源返回给QQ音乐的排行榜FA进程中的Worker线程(对应于图16中的步骤3)。QQ音乐的排行榜FA进程中的Worker线程将请求资源进行逻辑处理，得到对应的显示数据，如图16B所示的界面中的内容等。QQ音乐的排行榜FA进程中的Worker线程向QQ音乐的排行榜FA进程中的Render线程返回显示数据(对应于图17中的步骤4)。QQ音乐的排行榜FA中的Render线程对显示数据进行渲染处理，使得手机的显示器跳转到如图16B所示的卡片A的界面。

需要说明的是，由于用户的输入需要音箱FA的界面跳转至卡片A的界面，因此，QQ音乐的排行榜FA为有UI的服务FA。

综上，音箱FA的卡片A的界面依赖QQ音乐的排行榜FA所提供的资源，可实现音箱FA的界面到卡片A的界面的跳转。

基于上述描述，音箱FA的界面可以跳转到卡片B的界面。下面以音箱FA的界面为如图13H所示的界面为例，介绍界面跳转的具体实现过程。

图18A-图18B示出了本申请一实施例提供的一种人机交互界面示意图。用户在如图18A所示的界面上点击音箱FA的卡片B的空白处，手机的显示器跳转至如图18B所示的卡片B的界面，该界面用于向用户提供来源于网易云音乐的最近播放的音乐资源。例如，在图18B所示的界面中显示有歌曲Love Story的歌曲名称、歌曲Love Story的歌手名、歌曲LoveStory的歌词、上一首图标的操作按钮、播放/暂停图标的操作按钮和下一首图标的操作按钮、播放模式的操作按钮、最近播放列表的操作按钮等。从而，使得用户可以浏览到网易云音乐的最近播放中的歌曲。

图19示出了本申请一实施例提供的一种场景软件架构示意图。在音箱FA的卡片B上除操作按钮之外的区域有用户的输入时，音箱FA进程基于用户的输入向网易云音乐的最近播放FA进程发送界面跳转请求(对应于图19中的步骤1)。其中，网易云音乐的最近播放FA进程对应于网易云音乐的最近播放FA。网易云音乐的最近播放FA是由网易云音乐厂商分布到FA云端服务器(如FA应用市场)中的服务FA。

网易云音乐的最近播放FA进程中的Worker线程通过解析界面跳转请求，向网易云音乐厂商的服务器发送数据请求(对应于图19中的步骤2)。网易云音乐厂商的服务器将请求资源返回给网易云音乐的最近播放FA进程中的Worker线程(对应于图19中的步骤3)。网易云音乐的最近播放FA进程中的Worker线程将请求资源进行逻辑处理，得到对应的显示数据，如图18B所示的界面中的内容等。网易云音乐的最近播放FA进程中的Worker线程向网易云音乐的最近播放FA进程中的Render线程返回显示数据(对应于图19中的步骤4)。网易云音乐的最近播放FA中的Render线程对显示数据进行渲染处理，使得手机的显示器跳转到如图18B所示的卡片B的界面。

需要说明的是，由于用户的输入需要音乐FA的界面跳转至卡片B的界面，因此，网易云音乐的最近播放FA为有UI的服务FA。

综上，音箱FA的卡片B的界面依赖网易云音乐的最近播放FA所提供的资源，可实现音箱FA的界面到卡片B的界面的跳转。

基于前述的一些实施例，下面介绍本申请提供的设备控制方法。

示例性地，本申请提供一种设备控制方法。

本申请的设备控制方法可以包括：步骤S201-步骤S208。

S201、第一设备向第一应用进程发送第一请求，其中，第一应用进程对应于第一应用，第一应用安装在第一设备中，第一请求用于请求第一设备执行第一响应的资源。

本申请中，步骤S201可参见前文图5C所示的步骤S103或者S104的描述，第一设备参见前文的描述，第一应用参见前文提及的音箱FA的描述，第一应用参见前文提及的音箱FA进程的描述，第一应用参见前文提及的音箱FA进程的描述，此处不做赘述。其中，本申请对第一请求的具体实现方式不做限定。在一些实施例中，第一请求可以包括第二应用的标识。

S202、第一设备响应于第一请求，向第一服务器发送第二请求，其中，第二请求用于请求获取第二应用，第一应用与第二应用关联。

本申请中，步骤S202可参见前文图5C所示的步骤S107的描述，第二应用参见前文提及的音乐FA进程的描述，第二应用参见前文提及的音乐FA进程的描述，第二请求参见前文提及的下载音乐FA请求的描述，第一应用与第二应用关联可参见前文提及的音箱FA与音乐FA具有依赖关系或者音箱FA虚拟集成有音乐FA的描述，此处不做赘述。

S203、第一设备从第一服务器接收第二应用。

本申请中，第一设备从第一服务器接收第二应用，可以理解为：第一设备接收第二应用的bundle，使得第一设备基于第二应用的bundle将第二应用安装到第一设备中。其中，步骤S203可参见前文图5C所示的步骤S108和S109的描述，此处不做赘述。

S204、第一应用进程向第二应用进程发送第三请求，其中，第二应用进程对应于第二应用，第一应用进程和第二应用进程为不同的进程，第三请求用于请求第一设备执行第一响应的资源。

本申请中，步骤S204可参见前文图5C所示的步骤S110和S111的描述，第三请求参见前文提及的第一音乐资源请求的描述，第二应用进程参见前文提及的音乐FA进程的描述，此处不做赘述。需要说明的是，第二请求和第三请求的实质内容相同，均用于请求第一设备执行第一响应的资源，但表示形式可以相同或者不同，本申请对此不做限定。

S205、第二应用进程向第二应用对应的服务器发送第四请求，其中，第四请求用于请求第一设备执行第一响应的资源。

本申请中，步骤S205可参见前文图5C所示的步骤S112的描述，第四请求参见前文提及的第二音乐资源请求的描述，第二应用对应的服务器参见前文提及的第二服务器501的描述，此处不做赘述。

S206、第二应用进程从第二应用对应的服务器接收第一资源，其中，第一资源用于第一设备执行第一响应。

本申请中，步骤S206可参见前文图5C所示的步骤S113的描述，第一资源参见前文提及的音乐资源的描述，此处不做赘述。

S207、第二应用进程向第一应用进程发送第一资源。

本申请中，步骤S207可参见前文图5C所示的步骤S114的描述，此处不做赘述。

S208、第一设备基于第一资源，执行第一响应。

本申请中，步骤S208可参见前文图5C所示的步骤S114的描述，第一响应参见前文提及的播放歌曲Love Story的描述，此处不做赘述。

在一些实施例中，第一设备向第一服务器发送第二请求之前，本申请的设备控制方法还可以包括：第一设备基于包管理服务(Bundle Manager Service，BMS)不存在第二应用的标识，确定第二应用未安装在第一设备中，其中，BMS用于存储第一设备中已安装的应用的标识。从而，第一设备可以需要下载并安装第二设备，使得第一应用借助第二应用获取执行第一响应的资源。其中，上述实现过程具体可参见前文图5C所示的步骤S106-S109的描述，此处不做赘述。

在一些实施例中，第一设备从第一服务器接收第二应用之后，还可以包括：第一设备将第二应用安装在第一设备中，并在BMS中存储第二应用的标识。从而，第一设备可以确认第一设备中已安装有第二设备，方便第一应用借助第二应用获取执行第一响应的资源。其中，上述实现过程具体可参见前文图5C所示的步骤S106的描述，此处不做赘述。

在一些实施例中，第一设备中存储有第一应用的配置文件，第一应用的配置文件中包含第二应用的标识。第二请求中携带有第二应用的标识。本申请中，上述实现过程具体可参见前文描述，此处不做赘述。

在一些实施例中，本申请的设备控制方法还可以包括：步骤S301-S307。

S301、第一设备响应于第一请求，向第一服务器发送第五请求，其中，第五请求用于请求获取第三应用，第一应用与第三应用关联。

S302、第一设备从第一服务器接收第三应用。

S303、第一应用进程向第三应用进程发送第六请求，其中，第三应用进程对应于第三应用，第一应用进程和第三应用进程为不同的进程，第六请求用于请求第一设备执行第一响应的资源。

S304、第三应用进程向第三应用对应的服务器发送第七请求，其中，第七请求用于请求第一设备执行第一响应的资源。

S305、第三应用进程从第三应用对应的服务器接收第二资源，其中，第二资源用于第一设备执行第一响应。

S306、第三应用进程向第一应用进程发送第二资源。

S307、第一设备基于第一资源和第二资源，执行第一响应。

本申请中，第一设备中的第一应用可以同时虚拟集成第二应用和第三应用，即上述步骤S301-S307中的第一应用通过第三应用获取资源的过程具体可参见第一应用通过第二应用获取资源的描述，第二资源参见前文提及的音乐资源的描述，此处不做赘述。

在一些实施例中，第一设备从第二设备接收第一指令，第一设备与第二设备通信连接。第一设备响应于第一指令，向第一应用进程发送第一请求。本申请中，上述实现过程具体可参见前文图7-图8D所示的描述，第一指令可参见前文提及的用户的输入操作的描述，此处不做赘述。

在一些实施例中，第一设备响应于用户的第一操作，向第一应用进程发送第一请求。本申请中，上述实现过程具体可参见前文图9-图10D，以及图11-图12B所示的描述，用户的第一操作可参见前文提及的用户的输入操作的描述，此处不做赘述。

在一些实施例中，本申请的设备控制方法还可以包括：第一设备中的显示器显示第一应用的界面，第一应用的界面包括第一区域，第一区域显示的界面由第二应用提供。本申请中，上述实现过程具体可参见前文图13A-图13G所示的描述，此处不做赘述。

在一些实施例中，本申请的设备控制方法还可以包括：第一设备在满足预设条件的情况下，释放第二应用的资源，即第一设备可以终止第二应用进程，且释放第一设备的存储器中的第二应用的相关资源。其中，第一预设可以包括但限于：第二应用的占用空间比例是否超过预设比例，第一设备的剩余空间是否小于预设大小，第二应用中的应用数量是否超过预设数量，第二应用在未被调用的情况下的运行时长是否超过预设时长等。

在一些实施例中，本申请的设备控制方法还可以包括：第一应用进程停止调用第二应用进程，即第一应用进程不再启动第二应用进程，使得第二应用进程可以被其他进程调用。例如，第一设备可以对第一应用进程停止调用第二应用进程设置标识位。当标识位上的数值为预设数值时，第一设备可以确定第一应用进程已经停止调用第二应用进程。

在一些实施例中，本申请的设备控制方法还可以包括：步骤S401-S407。

S401、第一设备向第四应用进程发送第八请求，其中，第四应用进程对应于第四应用，第四应用安装在第一设备中，第四应用与第二应用关联，第八请求用于请求第一设备执行第二响应的资源。

S402、第四应用进程向第二应用进程发送第九请求，其中，第四应用进程和第二应用进程为不同的进程，第九请求用于请求第一设备执行第二响应的资源。

S403、第二应用进程向第二应用对应的服务器发送第十请求，其中，第十请求用于请求第一设备执行第二响应的资源。

S404、第二应用进程从第二应用对应的服务器接收第三资源，其中，第三资源用于第一设备执行第二响应。

S405、第二应用进程向第四应用进程发送第三资源。

S406、第一设备基于第三资源，执行第二响应。

本申请中，第一设备除了安装第一应用之外，还可以安装有第四应用，且第二应用和第四应用可分别调用第二应用。其中，步骤S401-S407中的第四应用通过第二应用实现第一设备执行第二响应的具体实现过程可参见前文中第一应用通过第二应用实现第一设备执行第一响应的具体实现过程的描述，此处不做赘述。

在一些实施例中，在第一设备为音箱，第一应用为音箱FA应用，第二设备为音乐FA应用，第一服务器为FA云端服务器的情况下，本申请的设备控制方法可以包括：步骤S501-步骤S513。

S501、音箱请求调用音箱FA进程，其中，音箱FA进程对应于音箱FA应用，音箱FA应用安装在音箱中。

S502、音箱判断音箱FA进程是否运行。

S503、在音箱FA进程未运行时，音箱调用音箱FA进程，并向音箱FA进程发送目标歌曲的标识。

S504、在音箱FA进程运行时，音箱向音箱FA进程发送目标歌曲的标识。

S505、音箱FA进程请求调用音乐FA进程。

S506、音箱判断BMS中是否存在音乐FA应用的标识，以确定音箱中是否存在音乐FA应用的bundle，其中，音乐FA进程对应于音乐FA应用，BMS中存储有与音箱FA应用关联的FA应用的标识。

S507、若BMS中不存在音乐FA应用的标识，则音箱的操作系统向FA云端服务器发送下载音乐FA应用请求，其中，下载音乐FA应用请求用于请求音乐FA应用的bundle，下载音乐FA应用请求中携带有音乐FA应用的标识。音箱的操作系统从FA云端服务器接收音乐FA应用的bundle。音箱的操作系统通过对音乐FA应用的bundle进行解包处理，将音乐FA应用安装在音箱中，且在BMS中存储音乐FA应用的标识，并继续判断BMS中是否存在音乐FA应用的标识，直至BMS中存在音乐FA应用的标识为止。

S508、若BMS中存在音乐FA应用的标识，则音箱FA进程调用音乐FA进程。

S509、音箱FA进程向音乐FA进程发送第一音乐资源请求，其中，第一音乐资源请求用于请求目标歌曲的音乐资源，第一音乐资源请求中携带有目标歌曲的标识。

S510、音乐FA进程向音乐FA应用对应的服务器发送第二音乐资源请求，其中，第二音乐资源请求用于请求目标歌曲的音乐资源，第二音乐资源请求中携带有目标歌曲的标识。

S511、音乐FA进程从音乐FA应用对应的服务器接收目标歌曲的音乐资源。

S512、音乐FA进程向音箱FA进程发送目标歌曲的音乐资源。

S513、音箱基于目标歌曲的音乐资源播放目标歌曲。

本申请中，步骤S501-S513的具体实现过程可参见前文描述，此处不做赘述。

示例性地，本申请还提供一种电子设备。该电子设备可以包括：至少一个存储器和至少一个处理器；存储器用于存储程序指令；处理器用于调用存储器中的程序指令使得第一设备执行前文实施例的设备控制方法。

示例性地，本申请还提供一种计算机程序产品，包括：执行指令，执行指令存储在可读存储介质中，电子设备的至少一个处理器可以从可读存储介质读取执行指令，至少一个处理器执行执行指令使得电子设备实现前文实施例的设备控制方法。

示例性地，本申请还提供一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器使得电子设备执行时实现前文实施例的设备控制方法。

在上述实施例中，全部或部分功能可以通过软件、硬件、或者软件加硬件的组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行计算机程序指令时，全部或部分地产生按照本申请实施例的流程或功能。计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。计算机指令可以存储在计算机可读存储介质中。计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质(例如，固态硬盘(solid state disk，SSD))等。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，该流程可以由计算机程序来指令相关的硬件完成，该程序可存储于计算机可读取存储介质中，该程序在执行时，可包括如上述各方法实施例的流程。而前述的存储介质包括：ROM或随机存储记忆体RAM、磁碟或者光盘等各种可存储程序代码的介质。

Claims (14)

1.一种设备控制方法，其特征在于，所述方法包括：

第一设备向第一应用进程发送第一请求，其中，所述第一应用进程对应于第一应用，所述第一应用安装在所述第一设备中，所述第一请求用于请求所述第一设备执行第一响应的资源；

所述第一设备响应于所述第一请求，向第一服务器发送第二请求，其中，所述第二请求用于请求获取第二应用，所述第一应用与所述第二应用关联；

所述第一设备从所述第一服务器接收所述第二应用；

所述第一应用进程向第二应用进程发送第三请求，其中，所述第二应用进程对应于所述第二应用，所述第一应用进程和所述第二应用进程为不同的进程，所述第三请求用于请求所述第一设备执行所述第一响应的资源；

所述第二应用进程向所述第二应用对应的服务器发送第四请求，其中，所述第四请求用于请求所述第一设备执行所述第一响应的资源；

所述第二应用进程从所述第二应用对应的服务器接收第一资源，其中，所述第一资源用于所述第一设备执行所述第一响应；

所述第二应用进程向所述第一应用进程发送所述第一资源；

所述第一设备基于所述第一资源，执行所述第一响应。

2.根据权利要求1所述的方法，其特征在于，所述第一设备向第一服务器发送第二请求之前，所述方法还包括：

所述第一设备基于包管理服务(Bundle Manager Service，BMS)不存在所述第二应用的标识，确定所述第二应用未安装在所述第一设备中，其中，所述BMS用于存储所述第一设备中已安装的应用的标识。

3.根据权利要求2所述的方法，其特征在于，所述第一设备从所述第一服务器接收所述第二应用之后，还包括：

所述第一设备将所述第二应用安装在所述第一设备中，并在所述BMS中存储所述第二应用的标识。

4.根据权利要求1-3任一项所述的方法，其特征在于，

所述第一设备中存储有所述第一应用的配置文件，所述第一应用的配置文件中包含所述第二应用的标识；所述第二请求中携带有所述第二应用的标识。

5.根据权利要求1-4任一项所述的方法，其特征在于，所述方法还包括：

所述第一设备响应于所述第一请求，向所述第一服务器发送第五请求，其中，所述第五请求用于请求获取第三应用，所述第一应用与所述第三应用关联；

所述第一设备从所述第一服务器接收所述第三应用；

所述第一应用进程向第三应用进程发送第六请求，其中，所述第三应用进程对应于所述第三应用，所述第一应用进程和所述第三应用进程为不同的进程，所述第六请求用于请求所述第一设备执行所述第一响应的资源；

所述第三应用进程向所述第三应用对应的服务器发送第七请求，其中，所述第七请求用于请求所述第一设备执行所述第一响应的资源；

所述第三应用进程从所述第三应用对应的服务器接收第二资源，其中，所述第二资源用于所述第一设备执行所述第一响应；

所述第三应用进程向所述第一应用进程发送所述第二资源；

所述第一设备基于所述第一资源和所述第二资源，执行所述第一响应。

6.根据权利要求1-5任一项所述的方法，其特征在于，

所述第一设备从第二设备接收第一指令，所述第一设备与所述第二设备通信连接；

所述第一设备响应于所述第一指令，向所述第一应用进程发送所述第一请求。

7.根据权利要求1-5任一项所述的方法，其特征在于，

所述第一设备响应于用户的第一操作，向所述第一应用进程发送所述第一请求。

8.根据权利要求1-7任一项所述的方法，其特征在于，所述方法还包括：

所述第一设备中的显示器显示所述第一应用的界面，所述第一应用的界面包括第一区域，所述第一区域显示的界面由所述第二应用提供。

9.根据权利要求1-8任一项所述的方法，其特征在于，所述方法还包括：

所述第一设备释放所述第二应用的资源。

10.根据权利要求1-9任一项所述的方法，其特征在于，所述方法还包括：

所述第一应用进程停止调用所述第二应用进程。

11.根据权利要求10所述的方法，其特征在于，所述方法还包括：

所述第一设备向第四应用进程发送第八请求，其中，所述第四应用进程对应于第四应用，所述第四应用安装在所述第一设备中，所述第四应用与所述第二应用关联，所述第八请求用于请求所述第一设备执行第二响应的资源；

所述第四应用进程向所述第二应用进程发送第九请求，其中，所述第四应用进程和所述第二应用进程为不同的进程，所述第九请求用于请求所述第一设备执行所述第二响应的资源；

所述第二应用进程向所述第二应用对应的服务器发送第十请求，其中，所述第十请求用于请求所述第一设备执行所述第二响应的资源；

所述第二应用进程从所述第二应用对应的服务器接收第三资源，其中，所述第三资源用于所述第一设备执行所述第二响应；

所述第二应用进程向所述第四应用进程发送所述第三资源；

所述第一设备基于所述第三资源，执行所述第二响应。

12.根据权利要求1-11任一项所述的方法，其特征在于，所述第一设备为音箱，所述第一应用为音箱FA应用，所述第二设备为音乐FA应用，所述第一服务器为FA云端服务器；所述方法具体为：

所述音箱请求调用音箱FA进程，其中，所述音箱FA进程对应于所述音箱FA应用，所述音箱FA应用安装在所述音箱中；

所述音箱判断所述音箱FA进程是否运行；

在所述音箱FA进程未运行时，所述音箱调用所述音箱FA进程，并向所述音箱FA进程发送目标歌曲的标识；

在所述音箱FA进程运行时，所述音箱向所述音箱FA进程发送目标歌曲的标识；

所述音箱FA进程请求调用音乐FA进程；

所述音箱判断BMS中是否存在所述音乐FA应用的标识，以确定所述音箱中是否存在所述音乐FA应用的bundle，其中，所述音乐FA进程对应于所述音乐FA应用，所述BMS中存储有与所述音箱FA应用关联的FA应用的标识；

若所述BMS中不存在所述音乐FA应用的标识，则所述音箱的操作系统向所述FA云端服务器发送下载所述音乐FA应用请求，其中，所述下载音乐FA应用请求用于请求所述音乐FA应用的bundle，所述下载音乐FA应用请求中携带有所述音乐FA应用的标识；所述音箱的操作系统从所述FA云端服务器接收所述音乐FA应用的bundle；所述音箱的操作系统通过对所述音乐FA应用的bundle进行解包处理，将所述音乐FA应用安装在所述音箱中，且在所述BMS中存储所述音乐FA应用的标识，并继续判断所述BMS中是否存在所述音乐FA应用的标识，直至所述BMS中存在音乐FA应用的标识为止；

若所述BMS中存在音乐FA应用的标识，则所述音箱FA进程调用所述音乐FA进程；

所述音箱FA进程向所述音乐FA进程发送第一音乐资源请求，其中，第一音乐资源请求用于请求所述目标歌曲的音乐资源，所述第一音乐资源请求中携带有所述目标歌曲的标识；

所述音乐FA进程向所述音乐FA应用对应的服务器发送第二音乐资源请求，其中，第二音乐资源请求用于请求所述目标歌曲的音乐资源，所述第二音乐资源请求中携带有所述目标歌曲的标识；

所述音乐FA进程从所述音乐FA应用对应的服务器接收所述目标歌曲的音乐资源；

所述音乐FA进程向所述音箱FA进程发送所述目标歌曲的音乐资源；

所述音箱基于所述目标歌曲的音乐资源播放所述目标歌曲。

13.一种第一设备，其特征在于，包括：至少一个存储器和至少一个处理器；

所述存储器用于存储程序指令；

所述处理器用于调用所述存储器中的程序指令使得所述电子设备执行权利要求1-12任一项所述的设备控制方法。

14.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器使得所述电子设备执行时实现权利要求1-12任一项所述的设备控制方法。

Images