一种权限处理方法、装置、车载终端及可读存储介质

本申请属于信息处理技术领域，尤其涉及一种权限处理方法、装置、车载终端及可读存储介质。

目前，随着车载终端的蓬勃发展，车载终端的操作系统可安装的应用程序越来越多，而且车载终端中安装的应用程序可以提供的应用功能也越来越多，为了运行不同的应用功能，应用功能经常需要获取相关权限。

目前对于应用程序申请运行时权限的处理方式是会弹出提示框，通过用户在提示框中输入的应答信息来选择是否授权，但是在车载终端中，频繁的让用户去操作，不利于安全驾驶而且权限处理的效率不高。

本申请实施例提供一种权限处理方法、装置、车载终端及可读存储介质，能够解决目前权限处理的效率不高的问题。

第一方面，本申请实施例提供一种权限处理方法，该方法包括：

基于检测到目标应用程序的目标权限申请，获取目标应用程序的应用信息；

从预先获取的配置文件中，确定与应用信息匹配的授权规则；配置文件包括与多个应用程序一一对应的授权规则；

根据授权规则，对目标应用程序申请的目标权限进行处理。

第二方面，本申请实施例提供一种权限处理装置，该装置包括：

获取模块，用于基于检测到目标应用程序的目标权限申请，获取目标应用程序的应用信息；

确定模块，用于从预先获取的配置文件中，确定与应用信息匹配的授权规则；配置文件包括与多个应用程序一一对应的授权规则；

处理模块，用于根据授权规则，对目标应用程序申请的目标权限进行处理。

第三方面，本申请实施例提供了一种车载终端，该设备包括：处理器以及存储有计算机程序指令的存储器；处理器执行计算机程序指令时，实现如第一方面或者第一方面的任一可能实现方式中的方法。

第四方面，本申请实施例提供了一种可读存储介质，该计算机可读存储介质上存储有计算机程序指令，计算机程序指令被处理器执行时实现如第一方面或者第一方面的任一可能实现方式中的方法。

本申请实施例中，通过在检测到车载终端中的目标应用程序申请目标权限的情况下，获取目标应用程序的应用信息；从预先获取的包括与多个应用程序分别对应的授权规则的配置文件中，确定出与应用信息相匹配的授权规则，这里，能够快速准确地确定出与目标应用程序对应的授权规则；最后，根据授权规则，对目标应用程序申请的目标权限进行处理，能够针对目标应用程序应用所申请的目标权限自动地进行精确处理，无需用户在驾驶过程中进行答复确认，不仅能够保证安全性，还提升了权限处理的效率。

为了更清楚地说明本申请实施例的技术方案，下面将对本申请实施例中所需要使用的附图作简单的介绍，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本申请实施例提供的一种权限处理方法的流程图；

图2是本申请实施例提供的一种实现权限处理方法的流程图；

图3是本申请实施例提供的一种权限处理装置结构示意图；

图4是本申请实施例提供的一种电子设备的硬件结构示意图。

下面将详细描述本申请的各个方面的特征和示例性实施例，为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及具体实施例，对本申请进行进一步详细描述。应理解，此处所描述的具体实施例仅被配置为解释本申请，并不被配置为限定本申请。对于本领域技术人员来说，本申请可以在不需要这些具体细节中的一些细节的情况下实施。下面对实施例的描述仅仅是为了通过示出本申请的示例来提供对本申请更好的理解。

需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括……”限定的要素，并不排除在包括要素的过程、方法、物品或者设备中还存在另外的相同要素。

首先，对于本申请实施例涉及的技术术语进行介绍。

运行时权限，应用程序需要在运行时申请的权限。

包名，应用程序的名称，也是应用程序的识别信息。

签名，即数字签名，一种类似写在纸上的普通的物理签名，但是使用了公钥加密领域的技术实现，用于鉴别数字信息的方法。

安装来源，请求系统安装应用程序的执行者。

本申请实施例提供的权限处理方法至少可以应用于下述应用场景中，下面进行说明。

目前的移动设备操作系统，因其具有系统源码开放、硬件支持丰富、且不间断维护、第三方软件开发方便等明显优势，近年间得到迅速发展。随着车载终端的蓬勃发展，目前很多车机厂商都希望能在车载终端的系统中安装一些第三方应用程序。目前对于应用程序申请运行时权限的处理方式是会弹出提示框，提示给用户去选择，但是在车载终端中，频繁的让用户去操作，并不利于安全驾驶。

基于上述应用场景，下面对本申请实施例提供的权限处理方法进行详细说明。

图1为本申请实施例提供的一种权限处理方法的流程图。

如图1所示，该权限处理方法可以包括步骤110-步骤130，该方法应用于权限处理装置，具体如下所示：

步骤110，基于检测到目标应用程序的目标权限申请，获取目标应用程序的应用信息。

步骤120，从预先获取的配置文件中，确定与应用信息匹配的授权规则；配置文件包括与多个应用程序一一对应的授权规则。

步骤130，根据授权规则，对目标应用程序申请的目标权限进行处理。

本申请提供的权限处理方法中，通过在检测到车载终端中的目标应用程序申请目标权限的情况下，获取目标应用程序的应用信息；从预先获取的包括与多个应用程序分别对应的授权规则的配置文件中，确定出与应用信息相匹配的授权规则，这里，能够快速准确地确定出与目标应用程序对应的授权规则；最后，根据授权规则，对目标应用程序申请的目标权限进行处理，能够针对目标应用程序应用所申请的目标权限自动地进行精确处理，无需用户在驾驶过程中进行答复确认，不仅能够保证安全性，还提升了权限处理的效率。

下面，对步骤110-步骤130的内容分别进行描述：

步骤110，基于检测到目标应用程序的目标权限申请，获取目标应用程序的应用信息。

在车载终端检测到第三方的目标应用程序申请运行时的权限时，获取目标应用程序的应用信息。其中，目标权限申请用于申请目标应用程序运行时的目标权限。

例如，目标应用程序是音乐播放应用程序，目标应用程序的应用信息可以包括：目标应用程序的应用标识信息、目标应用程序的应用名称、目标应用程序的安装路径(如：如位于指定的目录路径的预置应用)、目标应用程序的安装来源(如：文件管理器或应用商店等)以及目标应用程序的签名信息(签名信息通常与应用程序的开发商相关)。

在一种可能的实施例中，在步骤120之前，还可以包括以下步骤：

获取配置文件；

配置文件包括：通用配置信息以及每个应用类别对应的授权规则；

其中，通用配置信息包括：应用类别与授权规则的对应关系、每个授权规则的优先级、以及补充授权规则；

应用类别包括：预设应用名称、预设安装路径、预设安装来源以及预设签名信息。

其中，配置文件可以包括：预置应用路径列表，包括至少一个预设应用路径，用于检查应用是否属于预设安装路径；

包名列表，包括至少一个预设包名，用于检查应用是否属于预设安装来源的应用；

签名应用列表，包括至少一个预设签名信息、用于检查应用是否属于预设签名信息；

预设应用名称列表，包括至少一个预设应用名称、用于检查应用是否属于预设应用名称；

其中，配置文件可以包括：应用类别与授权规则的对应关系；其中，每一类应用类别可以对应一套授权规则，可以用于确定授权规则属于适用于哪一类应用类别。

每个授权规则的优先级，用于当某个应用程序符合多种应用类别特性时，优先匹配哪一套授权规则，如“预设应用名称”的优先级最可以为最高的。

补充授权规则，用于处理未配置规则的权限的授权类别，即当所申请的权限无法匹配到具体的授权规则时，通过默认处理方式进行权限处理(比如允许授权或拒绝授权)。

每个应用类别对应的授权规则包括：授权规则。

授权规则，包含：允许授权、拒绝授权、部分授权；

每个应用类别对应的授权规则还可以包括权限信息集合，用于授权规则为“部分授权”时生效，权限信息集合的列表中每项元素用于判断对于指定权限是否允许授权，具体内容可以包括：权限名和该权限名授权类别(包含两种类别：允许授权、拒绝授权)。

在一种可能的实施例中，步骤120，具体可以包括以下步骤：

根据应用信息，确定目标应用程序对应的目标应用类别；

从配置文件中，确定与目标应用类别匹配的授权规则；配置文件中包括应用类别和授权规则的关联关系；应用类别包括目标应用类别。

基于配置文件，确定应用信息对应的目标文件类别；配置文件包括多组互相对应的应用信息和应用类别；应用类别包括所述目标应用类别。因此，可以根据应用信息在配置文件中查目标应用程序对应的目标应用类别。

在一种可能的实施例中，应用信息包括：目标应用程序的应用名称、目标应用程序的安装路径、目标应用程序的安装来源以及目标应用程序的签名信息；步骤120，具体可以包括以下步骤：

基于目标应用程序对应多个授权规则，获取目标应用程序对应的最高优先级对应的授权规则；

确定最高优先级对应的授权规则为与应用信息匹配的授权规则。

基于目标应用程序对应多个授权规则，则根据配置文件中的目标应用程序对应的每个授权规则的优先级，优先匹配优先级最高的规则类别，也就是目标优先级对应的授权规则，按照目标优先级对应的授权规则，对目标应用程序申请的目标权限进行处理。

示例性地，目标应用程序是音乐播放应用程序，应用信息是：由T开发商开发的，具有签名信息“T”,安装来源是应用商店，这时需要比较预设签名信息和预设安装来源的优先级，若预设签名信息优先级更高，则按照预设签名信息这类的应用类别对应的授权规则，对目标应用程序申请的目标权限进行处理。

在一种可能的实施例中，步骤120，具体可以包括以下步骤：

基于目标应用程序的名称与预设应用名称相匹配，确定预设应用名称对应的授权规则为与应用信息匹配的授权规则。

基于目标应用程序的名称与预设应用名称相匹配，无需进行优先级的比较，则直接根据预设应用名称对应的授权规则，对目标应用程序申请的目标权限进行处理。

预设应用名称对应的授权规则可以包括：应用列表，该列表中每个元素项为每一个预设包名的应用的授权规则。

每个应用名称对应的授权规则可以包括：用于匹配申请权限的应用包名，以及该应用名称的授权规则(包含三种类别：全部授权、全部拒绝、部分授权；

每个应用名称对应的授权规则中还可以包括权限信息集合，当授权规则为“部分授权”时生效，列表中每项元素用于判断对于指定权限是否允许授权，具体可以包括权限名对应的授权类别，即允许授权以及拒绝授权。

步骤130，根据授权规则，对目标应用程序申请的目标权限进行处理。

这里，通过根据授权规则，对目标应用程序申请的目标权限进行处理，即按照授权规则选择是否对应用进行授权，可以自动处理应用程序运行时权限，兼容性强且处理效率高。

在一种可能的实施例中，授权规则包括：允许授权以及拒绝授权，步骤130，具体可以包括以下步骤：

基于授权规则为允许授权，对目标权限进行授权处理；

基于授权规则为拒绝授权，拒绝对目标权限进行授权处理。

一方面，在授权规则为拒绝授权的情况下，拒绝对目标权限进行授权处理，可以不响应目标权限申请。

另一方面，在授权规则为拒绝授权的情况下，拒绝对目标权限进行授权处理，具体可以包括以下步骤：显示拒绝授权信息，拒绝授权信息用于描述对目标权限进行拒绝授权处理。

需要说明的是，本申请中涉及到的拒绝对目标权限进行授权处理的实施例均可以包括上述两个方面的实现方式。

根据匹配到的授权规则来选择对于本次授权申请是否允许授权；

另外，当未匹配到授权规则时，则依据补充授权规则选择是否授权，补充授权规则用于处理未配置规则的权限的授权类别的情况，即当所申请的权限无法匹配到具体的授权规则时，通过默认处理方式进行权限处理(比如允许授权或拒绝授权)。

在一种可能的实施例中，授权规则还包括：部分授权；目标权限包括多个子目标权限，步骤130，具体可以包括以下步骤：

基于授权规则为部分授权，获取权限规则中的权限信息集合；

根据权限信息集合对多个子目标权限分别进行处理；权限信息集合包括至少一个允许授权的预设权限标识。

授权规则，包含：允许授权、拒绝授权、部分授权；

对带有允许授权的预设权限标识的子目标权限进行授权处理，对带有拒绝授权的预设权限标识的子目标权限进行拒绝授权处理。

基于授权规则为部分授权，获取权限规则中的权限信息集合；权限信息集合的列表中每项元素用于判断对于指定权限是否允许授权，具体内容可以包括：权限名和该权限名的授权类别(包含两种类别：允许授权、拒绝授权)。然后根据权限信息集合对多个子目标权限分别进行处理。

示例性地，目标权限包括多个子目标权限，包括：请求存储的权限，以及请求获取用户信息的权限；基于授权规则为部分授权，根据权限信息集合对多个子目标权限分别进行处理。由此，配置文件中的授权规则可以细化到针对具体哪个应用程序授予哪些权限，能够针对任一应用所申请的任一权限进行精确处理，不仅能够保证授权过程中的安全性，还提升了应用授权的精确性。

其中，子目标权限与子目标权限标识对应；预设权限标识包括第一预设权限标识和第二预设权限标识，上述涉及到的根据权限信息集合对多个子目标权限分别进行处理的步骤中，具体可以包括以下步骤：

分别确定与第一预设标识和第二预设标识对应的第一子目标权限标识和第二子目标权限标识；

对第一子目标权限标识对应的第一子目标权限进行授权处理；

拒绝对第二子目标权限标识对应的第二子目标权限进行授权处理。

子目标权限与子目标权限标识对应；预设权限标识包括第一预设权限标识(用于表示允许授权)和第二预设权限标识(用于表示拒绝授权)；

示例性地，目标权限包括多个子目标权限，包括：请求存储的权限，请求自动联网的权限、请求定位的权限以及请求获取用户信息的权限；基于授权规则为部分授权，遍历子权限标识，确定与第一预设标识匹配的第一子目标权限标识，如：请求存储的权限的标识，请求自动联网的权限的标识；以及确定与第二预设标识匹配的第二子目标权限标识，如：请求定位的权限以及请求获取用户信息的权限。

对第一子目标权限标识对应的第一子目标权限进行授权处理，即对请求存储的权限进行授权处理，对请求自动联网的权限进行授权处理、拒绝对第二子目标权限标识对应的第二子目标权限进行授权处理，即拒绝对请求定位的权限进行授权处理，以及拒绝对请求获取用户信息的权限进行授权处理。

在一种可能的实施例中，在应用程序更新的情况下，获取应用程序更新后的应用信息；从配置文件中，确定出与更新后的应用信息相匹配的授权规则。

这里，无需提示用户手动授权，当应用更新升级后，可以继续根据应用程序更新后的应用信息从配置文件获取与更新后的应用信息相匹配的授权规则。

另外，本申请的实施例不仅可以应用于车载终端，也可以应用于其他电子设备(例如：电视、智能穿戴设备)。

综上，在本申请实施例中，通过在检测到车载终端中的目标应用程序申请目标权限的情况下，获取目标应用程序的应用信息；从预先获取的包括与多个应用程序分别对应的授权规则的配置文件中，确定出与应用信息相匹配的授权规则，这里，能够快速准确地确定出与目标应用程序对应的授权规则；最后，根据授权规则，对目标应用程序申请的目标权限进行处理，能够针对目标应用程序应用所申请的目标权限自动地进行精确处理，无需用户在驾驶过程中进行答复确认，不仅能够保证安全性，还提升了权限处理的效率。

基于上述图1所示的权限处理方法，本申请还提供了一种实现权限处理的方法，图2为本申请实施例提供的一种实现权限处理的方法的流程图。

如图2所示，该权限处理方法可以包括步骤210-步骤250，该方法应用于权限处理装置，具体如下所示：

步骤210，获取申请权限的应用信息(应用包名、安装文件路径、应用安装来源、应用签名信息)。

步骤220，根据应用信息在配置文件中查应用所属分类。

步骤230，当应用所属类别大于1个时，则根据配置文件中的优先级信息，优先匹配优先级高的规则类别。

步骤240，当最终匹配的类别为“预设包名的应用”类别时，则在应用列表中根据应用包名匹配授权规则。

步骤250，根据匹配到的授权规则，来选择对于本次授权申请是否允许授权。另外，当未匹配到授权规则时，则依据“未配置规则的权限的授权类别”选择是否授权。

由此，可以提供一套完整的、兼容的、不依赖于用户选择的自动授予符合某些预设条件的应用程序运行时权限的方案。在安卓系统中预置一份配置文件，在配置文件中将所有应用程序可以分为5类(预设包名的应用、预置应用、预设安装来源的应用、预设签名信息的应用、其它应用)。其中，安装来源可以为请求系统安装应用程序的执行者，特定包名的应用，可以是应用的包名为特定的名称的应用；预置应用，可以是应用安装文件位于指定目录路径的应用；特定安装来源的应用，可以为应用安装者的包名为特定名称的应用；特定签名的应用，可以为应用签名信息符合特定签名的应用。并对每一类应用程序的添加授权规则(允许授权、拒绝授权、部分授权)。修改安卓系统授权装置，该装置会收到应用程序的授权请求，并根据配置文件识别出该应用程序的所属类型，然后根据配置文件中预设类型的授权规则，来判断是否要直接授权或直接拒绝，以减少用户的操作。

基于上述图1所示的权限处理方法，本申请实施例还提供一种权限处理装置，如图3所示，该装置300可以包括：

获取模块310，用于基于检测到目标应用程序的目标权限申请，获取目标应用程序的应用信息。

确定模块320，用于从预先获取的配置文件中，确定与应用信息匹配的授权规则；配置文件包括与多个应用程序一一对应的授权规则。

处理模块330，用于根据授权规则，对目标应用程序申请的目标权限进行处理。

在一种可能的实现方式中，确定模块320，具体用于：

根据应用信息，确定目标应用程序对应的目标应用类别；

从配置文件中，确定与目标应用类别匹配的授权规则；配置文件中包括应用类别和授权规则的关联关系；应用类别包括目标应用类别。

在一种可能的实现方式中，应用信息包括：目标应用程序的应用名称、目标应用程序的安装路径、目标应用程序的安装来源以及目标应用程序的签名信息；确定模块320，具体用于：

基于目标应用程序对应多个授权规则，获取目标应用程序对应的最高优先级对应的授权规则；

确定最高优先级对应的授权规则为与应用信息匹配的授权规则。

在一种可能的实现方式中，确定模块320，具体用于：

基于目标应用程序的名称与预设应用名称相匹配，确定预设应用名称对应的授权规则为与应用信息匹配的授权规则。

在一种可能的实现方式中，授权规则包括：允许授权以及拒绝授权，处理模块330，具体用于：

基于授权规则为允许授权，对目标权限进行授权处理；

基于授权规则为拒绝授权，拒绝对目标权限进行授权处理。

在一种可能的实现方式中，授权规则还包括：部分授权；目标权限包括多个子目标权限，处理模块330，具体用于：

基于授权规则为部分授权，获取权限规则中的权限信息集合；

根据权限信息集合对多个子目标权限分别进行处理；权限信息集合包括至少一个允许授权的预设权限标识。

在一种可能的实现方式中，子目标权限与子目标权限标识对应；预设权限标识包括第一预设权限标识和第二预设权限标识，处理模块330，具体用于：

基于授权规则为部分授权，获取权限分别确定与第一预设标识和第二预设标识对应的第一子目标权限标识和第二子目标权限标识；

对第一子目标权限标识对应的第一子目标权限进行授权处理；

拒绝对第二子目标权限标识对应的第二子目标权限进行授权处理。

在一种可能的实现方式中，在应用程序更新的情况下，获取应用程序更新后的应用信息；

从配置文件中，确定出与更新后的应用信息相匹配的授权规则。

在一种可能的实现方式中，获取模块310，还用于：

获取配置文件；

配置文件包括：通用配置信息以及每个应用类别对应的授权规则；

其中，通用配置信息包括：应用类别与授权规则的对应关系、每个授权规则的优先级、以及补充授权规则；

应用类别包括：预设应用名称、预设安装路径、预设安装来源以及预设签名信息。

综上，在本申请实施例中，通过在检测到车载终端中的目标应用程序申请目标权限的情况下，获取目标应用程序的应用信息；从预先获取的包括与多个应用程序分别对应的授权规则的配置文件中，确定出与应用信息相匹配的授权规则，这里，能够快速准确地确定出与目标应用程序对应的授权规则；最后，根据授权规则，对目标应用程序申请的目标权限进行处理，能够针对目标应用程序应用所申请的目标权限自动地进行精确处理，无需用户在驾驶过程中进行答复确认，不仅能够保证安全性，还提升了权限处理的效率。

图4示出了本申请实施例提供的一种电子设备的硬件结构示意图。

在电子设备可以包括处理器401以及存储有计算机程序指令的存储器402。

具体地，上述处理器401可以包括中央处理器(CPU)，或者预设集成电路(Application Specific Integrated Circuit，ASIC)，或者可以被配置成实施本申请实施例的一个或多个集成电路。

存储器402可以包括用于数据或指令的大容量存储器。举例来说而非限制，存储器402可包括硬盘驱动器(Hard Disk Drive，HDD)、软盘驱动器、闪存、光盘、磁光盘、磁带或通用串行总线(Universal Serial Bus，USB)驱动器或者两个或更多个以上这些的组合。在合适的情况下，存储器402可包括可移除或不可移除(或固定)的介质。在合适的情况下，存储器402可在综合网关容灾设备的内部或外部。在预设实施例中，存储器402是非易失性固态存储器。在预设实施例中，存储器402包括只读存储器(ROM)。在合适的情况下，该ROM可以是掩模编程的ROM、可编程ROM(PROM)、可擦除PROM(EPROM)、电可擦除PROM(EEPROM)、电可改写ROM(EAROM)或闪存或者两个或更多个以上这些的组合。

处理器401通过读取并执行存储器402中存储的计算机程序指令，以实现图所示实施例中的任意一种权限处理方法。

在一个示例中，电子设备还可包括通信接口403和总线410。其中，如图4所示，处理器401、存储器402、通信接口403通过总线410连接并完成相互间的通信。

通信接口403，主要用于实现本申请实施例中各模块、装置、单元和/或设备之间的通信。

总线410包括硬件、软件或两者，将电子设备的部件彼此耦接在一起。举例来说而非限制，总线可包括加速图形端口(AGP)或其他图形总线、增强工业标准架构(EISA)总线、前端总线(FSB)、超传输(HT)互连、工业标准架构(ISA)总线、无限带宽互连、低引脚数(LPC)总线、存储器总线、道架构(MCA)总线、外围组件互连(PCI)总线、PCI-Express(PCI-X)总线、串行高级技术附件(SATA)总线、视频电子标准协会局部(VLB)总线或其他合适的总线或者两个或更多个以上这些的组合。在合适的情况下，总线410可包括一个或多个总线。尽管本申请实施例描述和示出了预设的总线，但本申请考虑任何合适的总线或互连。

该电子设备可以执行本申请实施例中的权限处理方法，从而实现结合图1至图2描述的权限处理方法。

另外，结合上述实施例中的权限处理方法，本申请实施例可提供一种计算机可读存储介质来实现。该计算机可读存储介质上存储有计算机程序指令；该计算机程序指令被处理器执行时实现图1至图2中的权限处理方法。

需要明确的是，本申请并不局限于上文所描述并在图中示出的预设配置和处理。为了简明起见，这里省略了对已知方法的详细描述。在上述实施例中，描述和示出了若干具体的步骤作为示例。但是，本申请的方法过程并不限于所描述和示出的具体步骤，本领域的技术人员可以在领会本申请的精神后，作出各种改变、修改和添加，或者改变步骤之间的顺序。

以上所述的结构框图中所示的功能块可以实现为硬件、软件、固件或者它们的组合。当以硬件方式实现时，其可以例如是电子电路、专用集成电路(ASIC)、适当的固件、插件、功能卡等等。当以软件方式实现时，本申请的元素是被用于执行所需任务的程序或者代码段。程序或者代码段可以存储在机器可读介质中，或者通过载波中携带的数据信号在传输介质或者通信链路上传送。“机器可读介质”可以包括能够存储或传输信息的任何介质。机器可读介质的例子包括电子电路、半导体存储器设备、ROM、闪存、可擦除ROM(EROM)、软盘、CD-ROM、光盘、硬盘、光纤介质、射频(RF)链路，等等。代码段可以经由诸如因特网、内联网等的计算机网络被下载。

还需要说明的是，本申请中提及的示例性实施例，基于一系列的步骤或者装置描述一些方法或系统。但是，本申请不局限于上述步骤的顺序，也就是说，可以按照实施例中提及的顺序执行步骤，也可以不同于实施例中的顺序，或者若干步骤同时执行。

以上所述，仅为本申请的具体实施方式，所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，上述描述的系统、模块和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。应理解，本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到各种等效的修改或替换，这些修改或替换都应涵盖在本申请的保护范围之内。