应用的启动控制方法、装置和加固应用安装包的装置与流程

本发明涉及计算机技术领域，具体涉及一种应用的启动控制方法、装置和加固应用安装包的装置。

背景技术：

通常情况下，应用的启动都是由用户主动发出启动指令来控制应用启动的，但是这不利于多应用间的交互。例如，用户启动了购物应用进行购物，当需要进行付款时，需要启动支付应用来完成支付，这就需要用户再发出启动支付应用的指令，非常不便。因此现有技术在应用的开发过程中，针对该应用可能需要交互的其他应用，在安装包中写入相应的其他应用的启动方法，从而在该应用运行过程中可以启动其他应用。但是，这种方法的可拓展性差，当需要交互的应用发生变更时，开发人员需要开发该应用的新版本，在新版本中写入新增应用的启动方法或删除已有应用的启动方法，用户还需要重新安装新版本的应用，对开发人员和用户而言都十分麻烦。

技术实现要素：

鉴于上述问题，提出了本发明以便提供一种克服上述问题或者至少部分地解决上述问题的应用的启动控制方法、装置和加固应用安装包的装置。

依据本发明的一个方面，提供了一种应用的启动控制方法，包括：

当所述第一应用在智能终端上启动后，所述应用启动控制插件接收服务器发送的启动第二应用的指令；所述应用启动控制插件是所述第一应用中的插件；

所述应用启动控制插件根据所述启动第二应用的指令在所述智能终端上启动第二应用。

可选地，所述根据所述启动第二应用的指令在所述智能终端上启动第二应用包括：

根据所述启动第二应用的指令确定对应的启动逻辑；其中，所述应用启动控制插件中预先配置有一个或多个启动逻辑；

根据确定的启动逻辑启动第二应用。

可选地，所述应用启动控制插件中预先配置的每一个启动逻辑与系统中的一类组件相对应。

可选地，所述应用启动控制插件中预先配置有与如下一种或多种组件对应的启动逻辑：Activity组件、Service组件、BroadcastReceiver组件、ContentProvider组件。

可选地，所述启动第二应用的指令中包含与第二应用对应的组件名称；

所述根据所述启动第二应用的指令确定对应的启动逻辑包括：根据与第二应用对应的组件名称，确定与该组件对应的启动逻辑。

可选地，所述启动第二应用的指令中包含启动第二应用所需的验证信息；

所述根据确定的启动逻辑启动第二应用进一步包括：将所述验证信息发送给第二应用进行验证。

可选地，所述验证信息包括如下中的一种或多种：Action信息、类型信息、数据信息、参数信息、组件信息。

可选地，所述应用启动控制插件中还预先配置有Intent构造逻辑；

所述将所述验证信息发送给指定应用进行验证包括：根据所述Intent构造逻辑，将所述验证信息构造为Intent对象；

将所述Intent对象发送给第二应用进行验证。

可选地，该方法进一步包括：

当第一应用启动时，所述应用启动控制插件判断该第一应用是否是受其他应用的控制而启动，若是，记录启动该第一应用的其他应用的名称，反馈给服务器。

依据本发明的另一方面提供了一种应用的启动控制装置，其中，该装置是第一应用中的插件，包括：

接收单元，适于当所述第一应用在智能终端上启动后，接收服务器发送的启动第二应用的指令；

执行单元，适于根据所述启动第二应用的指令在所述智能终端上启动第二应用。

可选地，该装置进一步包括：

存储单元，适于存储预先配置的一个或多个启动逻辑；

所述执行单元，适于根据所述启动第二应用的指令确定对应的启动逻辑；根据确定的启动逻辑启动第二应用。

可选地，所述存储单元中预先配置的每一个启动逻辑与系统中的一类组件相对应。

可选地，所述存储单元中预先配置有与如下一种或多种组件对应的启动逻辑：Activity组件、Service组件、BroadcastReceiver组件、ContentProvider组件。

可选地，所述启动第二应用的指令中包含与第二应用对应的组件名称；

所述执行单元，适于根据与第二应用对应的组件名称，确定与该组件对应的启动逻辑。

可选地，所述启动第二应用的指令中包含启动第二应用所需的验证信息；

所述执行单元，还适于将所述验证信息发送给第二应用进行验证。

可选地，所述验证信息包括如下中的一种或多种：Action信息、类型信息、数据信息、参数信息、组件信息。

可选地，所述存储单元，还适于存储预先配置的Intent构造逻辑；

所述执行单元，还适于根据所述Intent构造逻辑，将所述验证信息构造为Intent对象；将所述Intent对象发送给第二应用进行验证。

可选地，所述执行单元，进一步适于在第一应用启动时，判断该第一应用是否是受其他应用的控制而启动，若是，记录启动该第一应用的其他应用的名称，反馈给服务器。

依据本发明的又一方面，提供了一种加固应用安装包的装置，包括：

打包单元，适于将如上述任一项所述的应用启动控制装置打包到应用的安装包中。

由上述可知，本发明的技术方案，当第一应用在智能终端上启动后，可以由其中的应用启动控制插件接收服务器发送的启动第二应用的指令，根据该指令完成对第二应用的启动。该技术方案可以在不对应用安装包进行多次修改的情况下，通过接收服务器发送的不同指令启动不同的其他应用，减少了开发成本，也提高了用户体验。

上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1示出了根据本发明一个实施例的一种应用的启动控制方法的流程示意图；

图2示出了根据本发明一个实施例的一种应用的启动控制装置的结构示意图；以及

图3示出了根据本发明一个实施例的一种加固应用安装包的装置的结构示意图。

具体实施方式

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

图1示出了根据本发明一个实施例的一种应用的启动控制方法的流程示意图，如图1所示，该方法包括：

步骤S110，当第一应用在智能终端上启动后，应用启动控制插件接收服务器发送的启动第二应用的指令；应用启动控制插件是第一应用中的插件。

步骤S120，应用启动控制插件根据启动第二应用的指令在智能终端上启动第二应用。

可见，图1所示的方法，当第一应用在智能终端上启动后，可以由其中的应用启动控制插件接收服务器发送的启动第二应用的指令，根据该指令完成对第二应用的启动。该技术方案可以在不对应用安装包进行多次修改的情况下，通过接收服务器发送的不同指令启动不同的其他应用，减少了开发成本，也提高了用户体验。

在本发明的一个实施例中，图1所示的方法中，根据启动第二应用的指令在智能终端上启动第二应用包括：根据启动第二应用的指令确定对应的启动逻辑；其中，应用启动控制插件中预先配置有一个或多个启动逻辑；根据确定的启动逻辑启动第二应用。

在本实施例中，应用启动控制插件中预先可以配置一个或多个启动逻辑，这是由于不同的应用所支持的启动逻辑是不同的。概括地说，现有技术中，支持被其他应用启动的应用往往会被配置为通过指定组件的启动而启动。以安卓系统为例，指定组件通常包括以下四类：Activity组件、Service组件、BroadcastReceiver组件、ContentProvider组件，因此在本发明的一个实施例中，应用启动控制插件中预先配置有与以上四种组件中的一种或多种对应的启动逻辑。例如调用startActivity方法启动Activity组件，调用startService方法启动Service组件，调用startBroadcastReceiver方法启动Broadcast Receiver组件，在ContentResolver.insert或ContentResolver.update这两个函数的参数中传入ContentProvider来启动ContentProvider组件，这样服务器可以通过发送的启动第二应用的指令来确定对应的启动逻辑。

举例而言，在本发明的一个实施例中，上述方法中，启动第二应用的指令中包含与第二应用对应的组件名称；根据启动第二应用的指令确定对应的启动逻辑包括：根据与第二应用对应的组件名称，确定与该组件对应的启动逻辑。

例如，服务器侧配置有第一应用可启动的多个应用的配置文件，服务器可以根据配置文件对应生成启动应用的指令。例如，第二应用对应的组件为Activity组件，那么配置文件中就保存有第二应用依赖于Activity组件启动而被控制启动的信息。对应地，第一应用的应用启动控制插件中预先配置有与Activity组件对应的启动逻辑，这样，服务器生产的启动第二应用的指令中就包含Activity组件这一基本名称。更为简便地，服务器和应用启动控制插件可以约定组件代号，例如Activity组件的代号为0，Service组件的代号为1，BroadcastReceiver组件的代号为2，ContentProvider组件的代号为3那么服务器只需要在下发的启动第二应用的指令中配置组件参数＝0，第一应用的应用启动控制插件就可以根据该组件参数就可以确定使用与Activity组件对应的启动逻辑。然而在安卓系统中，各应用对应的Activity组件、Service组件、Broadcast Receiver组件、ContentProvider组件都是从系统继承来的，为进行区分，每个应用对应的Activity组件、Service组件、Broadcast Receiver组件、ContentProvider组件的名称是不同的，因此启动第二应用的指令中还要包括第二应用对应的组件具体的名称，通过基本名称确定组件的类别，以及通过具体名称确定组件。

在本发明的一个实施例中，上述方法中，启动第二应用的指令中包含启动第二应用所需的验证信息；根据确定的启动逻辑启动第二应用进一步包括：将验证信息发送给第二应用进行验证。

在实际应用中，第一应用的运营方往往是和第二应用的运营方通过预先的沟通确定应用是否可进行交互。例如，微信支付仅支持京东而不支持淘宝(仅作举例)，那么淘宝就不能启动微信支付。因此在本实施例中，一个应用是否可以被其他应用启动还需要其他应用发送的验证信息，验证通过时才会被启动，

具体地，验证信息可以包括如下中的一种或多种：Action信息、类型信息、数据信息、参数信息、组件信息。例如，第二应用在没有接收到指定Action时会拒绝被其他应用启动。

由于服务器下发的启动第二应用的指令中，验证信息是以字符串的形式表现的，因此还需要将其构造为可被识别的对象。因此在本发明的一个实施例中，上述方法中，应用启动控制插件中还预先配置有Intent构造逻辑；将验证信息发送给指定应用进行验证包括：根据Intent构造逻辑，将验证信息构造为Intent对象；将Intent对象发送给第二应用进行验证。在安卓系统中，Intent机制可以协助应用间的交互与通讯，Intent负责对应用中一次操作的动作、动作涉及数据、附加数据进行描述，安卓系统则根据此Intent的描述，负责找到对应的组件，将Intent传递给调用的组件，并完成组件的调用。上述提到的Action信息等验证信息都可以作为Intent对象的一个属性。Action信息是指Intent要完成的动作；数据(Data)信息是执行动作的URI和MIME类型，不同的Action有不同的Data数据指定；类型(Category)信息是一个执行动作Action的附加信息；；组件(Component)信息指定Intent的目标组件的类名称。

在本发明的一个实施例中，图1所示的方法进一步包括：当第一应用启动时，应用启动控制插件判断该第一应用是否是受其他应用的控制而启动，若是，记录启动该第一应用的其他应用的名称，反馈给服务器。

应用运营方可以通过查看该应用被其他应用启动的情况，来开展与其他应用运营方的合作。例如，应用A经常被应用B控制启动，而很少被应用C控制启动，那么应用A的运营方就可以加强与应用B的运营方的合作，并与应用C的运营方探讨如何改进应用功能以加强合作等。

下面一个例子示出了应用A启动应用B的完整流程：

应用A的安装包中包含应用启动控制插件，应用A安装到智能终端并启动后，当启动控制插件接收到服务器发送的启动应用B的指令时，从中提取出验证信息，将其按构造逻辑构造为Intent对象，以及根据启动应用B的指令中的组件名称确定调用该组件的方法，将构造的Intent对象传递给系统，调用已确定的方法使得该组件被启动，从而启动应用B。应用B在启动后，记录应用A的名称并反馈给服务器。

图2示出了根据本发明一个实施例的一种应用的启动控制装置的结构示意图，该装置是第一应用中的插件，如图2所示，应用的启动控制装置200包括：

接收单元210，适于当第一应用在智能终端上启动后，接收服务器发送的启动第二应用的指令。

执行单元220，适于根据启动第二应用的指令在智能终端上启动第二应用。

可见，图2所示的装置，通过各单元的相互配合，当第一应用在智能终端上启动后，可以由其中的应用启动控制插件接收服务器发送的启动第二应用的指令，根据该指令完成对第二应用的启动。该技术方案可以在不对应用安装包进行多次修改的情况下，通过接收服务器发送的不同指令启动不同的其他应用，减少了开发成本，也提高了用户体验

在本发明的一个实施例中，图2所示的装置进一步包括：存储单元230，适于存储预先配置的一个或多个启动逻辑；执行单元220，适于根据启动第二应用的指令确定对应的启动逻辑；根据确定的启动逻辑启动第二应用。

在本发明的一个实施例中，上述装置中，存储单元230中预先配置的每一个启动逻辑与系统中的一类组件相对应。

在本发明的一个实施例中，上述装置中，存储单元230中预先配置有与如下一种或多种组件对应的启动逻辑：Activity组件、Service组件、BroadcastReceiver组件、ContentProvider组件。

在本发明的一个实施例中，上述装置中，启动第二应用的指令中包含与第二应用对应的组件名称；执行单元220，适于根据与第二应用对应的组件名称，确定与该组件对应的启动逻辑。

在本发明的一个实施例中，上述装置中，启动第二应用的指令中包含启动第二应用所需的验证信息；执行单元220，还适于将验证信息发送给第二应用进行验证。

在本发明的一个实施例中，上述装置中，验证信息包括如下中的一种或多种：Action信息、类型信息、数据信息、参数信息、组件信息。

在本发明的一个实施例中，上述装置中，存储单元230，还适于存储预先配置的Intent构造逻辑；执行单元220，还适于根据Intent构造逻辑，将验证信息构造为Intent对象；将Intent对象发送给第二应用进行验证。

在本发明的一个实施例中，上述装置中，执行单元220，进一步适于在第一应用启动时，判断该第一应用是否是受其他应用的控制而启动，若是，记录启动该第一应用的其他应用的名称，反馈给服务器。

需要说明的是，上述装置实施例的具体实施方式与前述对应方法实施例的具体实施方式相同，在此不在赘述。

图3示出了根据本发明一个实施例的一种加固应用安装包的装置的结构示意图，如图3所示，加固应用安装包的装置300包括：

打包单元310，适于将如上述任一实施例中的应用启动控制装置打包到应用的安装包中。

综上所述，本发明的技术方案，当第一应用在智能终端上启动后，可以由其中的应用启动控制插件接收服务器发送的启动第二应用的指令，根据该指令完成对第二应用的启动。该技术方案可以在不对应用安装包进行多次修改的情况下，通过接收服务器发送的不同指令启动不同的其他应用，减少了开发成本，也提高了用户体验。

需要说明的是：

在此提供的算法和显示不与任何特定计算机、虚拟装置或者其它设备固有相关。各种通用装置也可以与基于在此的示教一起使用。根据上面的描述，构造这类装置所要求的结构是显而易见的。此外，本发明也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本发明的内容，并且上面对特定语言所做的描述是为了披露本发明的最佳实施方式。

在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本发明的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。

类似地，应当理解，为了精简本公开并帮助理解各个发明方面中的一个或多个，在上面对本发明的示例性实施例的描述中，本发明的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本发明要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如下面的权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本发明的单独实施例。

本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。

此外，本领域的技术人员能够理解，尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。例如，在下面的权利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。

本发明的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器(DSP)来实现根据本发明实施例的启动控制装置和加固应用安装包的装置中的一些或者全部部件的一些或者全部功能。本发明还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序(例如，计算机程序和计算机程序产品)。这样的实现本发明的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。

应该注意的是上述实施例对本发明进行说明而不是对本发明进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本发明可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。

本发明的实施例公开了A1、一种应用的启动控制方法，其中，该方法包括：

当所述第一应用在智能终端上启动后，所述应用启动控制插件接收服务器发送的启动第二应用的指令；所述应用启动控制插件是所述第一应用中的插件；

所述应用启动控制插件根据所述启动第二应用的指令在所述智能终端上启动第二应用。

A2、如A1所述的方法，其中，所述根据所述启动第二应用的指令在所述智能终端上启动第二应用包括：

根据所述启动第二应用的指令确定对应的启动逻辑；其中，所述应用启动控制插件中预先配置有一个或多个启动逻辑；

根据确定的启动逻辑启动第二应用。

A3、如A2所述的方法，其中，

所述应用启动控制插件中预先配置的每一个启动逻辑与系统中的一类组件相对应。

A4、如A3所述的方法，其中，

所述应用启动控制插件中预先配置有与如下一种或多种组件对应的启动逻辑：Activity组件、Service组件、BroadcastReceiver组件、ContentProvider组件。

A5、如A3所述的方法，其中，

所述启动第二应用的指令中包含与第二应用对应的组件名称；

所述根据所述启动第二应用的指令确定对应的启动逻辑包括：根据与第二应用对应的组件名称，确定与该组件对应的启动逻辑。

A6、如A2所述的方法，其中，

所述启动第二应用的指令中包含启动第二应用所需的验证信息；

所述根据确定的启动逻辑启动第二应用进一步包括：将所述验证信息发送给第二应用进行验证。

A7、如A6所述的方法，其中，

所述验证信息包括如下中的一种或多种：Action信息、类型信息、数据信息、参数信息、组件信息。

A8、如A6所述的方法，其中，所述应用启动控制插件中还预先配置有Intent构造逻辑；

所述将所述验证信息发送给指定应用进行验证包括：根据所述Intent构造逻辑，将所述验证信息构造为Intent对象；

将所述Intent对象发送给第二应用进行验证。

A9、如A1所述的方法，其中，该方法进一步包括：

当第一应用启动时，所述应用启动控制插件判断该第一应用是否是受其他应用的控制而启动，若是，记录启动该第一应用的其他应用的名称，反馈给服务器。

本发明的实施例还公开了B10、一种应用的启动控制装置，其中，该装置是第一应用中的插件，包括：

接收单元，适于当所述第一应用在智能终端上启动后，接收服务器发送的启动第二应用的指令；

执行单元，适于根据所述启动第二应用的指令在所述智能终端上启动第二应用。

B11、如B10所述的装置，其中，该装置进一步包括：

存储单元，适于存储预先配置的一个或多个启动逻辑；

所述执行单元，适于根据所述启动第二应用的指令确定对应的启动逻辑；根据确定的启动逻辑启动第二应用。

B12、如B11所述的装置，其中，

所述存储单元中预先配置的每一个启动逻辑与系统中的一类组件相对应。

B13、如B12所述的装置，其中，

所述存储单元中预先配置有与如下一种或多种组件对应的启动逻辑：Activity组件、Service组件、BroadcastReceiver组件、ContentProvider组件。

B14、如B12所述的装置，其中，

所述启动第二应用的指令中包含与第二应用对应的组件名称；

所述执行单元，适于根据与第二应用对应的组件名称，确定与该组件对应的启动逻辑。

B15、如B11所述的装置，其中，

所述启动第二应用的指令中包含启动第二应用所需的验证信息；

所述执行单元，还适于将所述验证信息发送给第二应用进行验证。

B16、如B14所述的装置，其中，

所述验证信息包括如下中的一种或多种：Action信息、类型信息、数据信息、参数信息、组件信息。

B17、如B14所述的装置，其中，

所述存储单元，还适于存储预先配置的Intent构造逻辑；

所述执行单元，还适于根据所述Intent构造逻辑，将所述验证信息构造为Intent对象；将所述Intent对象发送给第二应用进行验证。

B18、如B10所述的装置，其中，

所述执行单元，进一步适于在第一应用启动时，判断该第一应用是否是受其他应用的控制而启动，若是，记录启动该第一应用的其他应用的名称，反馈给服务器。

本发明的实施例还公开了C19、一种加固应用安装包的装置，其中，该装置包括：

打包单元，适于将如B10-B18中任一项所述的应用启动控制装置打包到应用的安装包中。