本申请涉及系统软件技术，具体涉及一种对支撑层软件功能的访问方法及装置。本申请同时涉及一种对支撑层软件功能的升级方法及装置，以及一种对支撑层动态升级程序的管理方法及装置。
背景技术：
：：运行在移动设备上的系统软件升级通常采用ota(over-the-air)在线更新的方式，采用这种方式，移动设备软件开发方通常需要维护版本变更历史，为移动设备制作各个版本之间的全量和增量升级包并推送给使用移动设备的用户。其中，增量升级包要求软件开发方维护所有版本间的差异，并为各个版本提供差分升级包，然而由于移动设备上的系统软件发展变化迅速，用户在使用一段时间后，系统软件已经发布多个版本，通常难以匹配到最新版本和当前版本的差分包，只能更新全量包升级。因此获取全量升级包进行系统软件升级成为一种比较普遍采用的方式。移动设备的系统软件通常采用分层的结构，其中通常包括为应用程序提供服务的支撑层软件，支撑层软件由于承担了为应用程序构建运行环境，提供系统服务的重要职责，具有较强的升级需求。以移动操作系统android或者yunos为例，为应用程序提供服务的支撑层通常是指框架层(framework)，框架层包含开发应用程序所需的一系列组件，每个组件都可以实现一组功能(例如：与拨打电话相关的功能等)、并对外提供相应的功能接口(即api)。应用程序需要实现某一功能时可以根据需求访问框架层提供的功能接口，框架层则根据接收到的请求，执行当前已安装的框架层功能接口的实现代码。基于上述对支撑层功能接口的常规访问方式，为了使应用程序能够访问到升级后的支撑层软件功能，通常需要下载系统软件的全量升级包进行安装。在实际应用中存在以下情况：1)全量升级包的体积通常较大，在几百兆到几gb字节之间，经常出现因为移动设备存储空间不足导致下载更新失败的情况；2)不同移动设备软件开发方对框架层软件的修改存在较大差异，例如：功能接口数量、以及内部实现都可能不同，因此难以使用统一的系统软件更新版本对不同或者相同厂家的不同产品系列的支撑层软件功能进行升级。由此可见，由于传统ota方式存在上述问题，支撑层软件功能通常无法得到及时地升级，应用程序自然无法及时访问到升级后的支撑层软件功能，导致应用程序能够实现的功能受到限制，影响用户的使用体验。技术实现要素：本申请实施例提供一种对支撑层软件功能的访问方法和装置，以解决ota升级方式下，应用程序无法及时访问到升级后的支撑层软件功能，导致应用程序实现功能受限的问题。本申请实施例还提供一种对支撑层软件功能的升级方法和装置，以及一种对支撑层动态升级程序的管理方法和装置。本申请提供一种对支撑层软件功能的访问方法，包括：接收应用程序对支撑层功能接口的访问请求；执行对应于所述功能接口的升级代码；其中，包含所述升级代码的动态升级程序通过进程合并机制被预先注入到支撑层服务进程中，并且所述功能接口的功能实现代码被设置为所述升级代码。可选的，所述方法还包括：将所述升级代码的执行结果返回给所述应用程序。可选的，所述支撑层包括：框架层；所述支撑层功能接口包括：所述框架层中的组件提供的功能接口。可选的，包含所述升级代码的动态升级程序通过进程合并机制被注入到支撑层服务进程中，包括：在所述动态升级程序的配置文件中，指定运行所述动态升级程序的进程名称与所述支撑层服务进程一致；运行所述动态升级程序，以将其注入到所述支撑层服务进程中。可选的，所述功能接口的功能实现代码被设置为所述升级代码，是采用hook方式实现的。可选的，在执行对应于所述功能接口的升级代码的过程中，还包括：调用 在所述支撑层服务进程之外运行的功能扩展程序提供的功能扩展接口。可选的，对所述功能扩展接口的调用操作，是通过进程间通信机制实现的。可选的，所述动态升级程序，是在宿主系统中安装从服务端获取的、用于升级支撑层软件功能的动态升级软件包后生成的可执行程序。可选的，在执行对应于所述功能接口的升级代码的过程中，还包括：调用在所述支撑层服务进程之外动态加载运行的功能扩展程序提供的功能扩展接口；所述功能扩展程序，是在宿主系统中安装功能扩展软件包后生成的可执行程序，所述功能扩展软件包是从所述服务端获取所述动态升级软件包时一并获取的。相应的，本申请还提供一种对支撑层软件功能的访问装置，包括：访问请求接收单元，用于接收应用程序对支撑层功能接口的访问请求；升级代码执行单元，用于执行对应于所述功能接口的升级代码，其中，包含所述升级代码的动态升级程序通过进程合并机制被预先注入到支撑层服务进程中，并且所述功能接口的功能实现代码被设置为所述升级代码。可选的，所述装置还包括：执行结果返回单元，用于将所述升级代码执行单元的执行结果返回给所述应用程序。可选的，所述升级代码执行单元，具体用于执行对应于所述功能接口的升级代码，并在执行所述升级代码的过程中调用在支撑层服务进程之外运行的功能扩展程序提供的功能扩展接口。可选的，所述升级代码执行单元，具体用于通过进程间通信机制实现对所述功能扩展接口的调用。此外，本申请还提供一种对支撑层软件功能的升级方法，包括：运行包含升级代码的动态升级程序，并通过进程合并机制将所述动态升级程序注入到支撑层服务进程中；将支撑层待升级功能接口的功能实现代码设置为相应的升级代码。可选的，所述支撑层包括：框架层。可选的，所述运行包含升级代码的动态升级程序，并通过进程合并机制将 所述动态升级程序注入到支撑层服务进程中，采用如下方式实现：在所述动态升级程序的配置文件中，预先指定运行所述动态升级程序的进程名称与所述支撑层服务进程一致；运行所述动态升级程序，以将其注入到所述支撑层服务进程中。可选的，将支撑层待升级功能接口的功能实现代码设置为相应的升级代码的步骤，采用hook方式实现。可选的，所述方法由所述支撑层服务进程在系统初始化阶段触发执行。可选的，所述支撑层服务进程在系统初始化阶段通过如下方式触发本方法执行：所述动态升级程序预先向系统注册以下需求：接收系统初始化阶段的预设消息；所述支撑层服务进程在系统初始化阶段广播所述预设消息，并根据所述动态升级程序预先注册的所述需求、触发本方法执行。可选的，所述系统初始化阶段的预设消息包括：开机完成消息。可选的，所述方法还包括：启动在所述支撑层服务进程之外运行的、为所述动态升级程序提供功能扩展服务的功能扩展程序。可选的，在触发本方法执行之前，包括：向服务端发送软件包获取请求，请求获取用于升级支撑层软件功能的软件包；根据服务端提供的信息获取软件包，其中至少包括动态升级软件包；通过安装已获取的软件包，生成至少包括所述动态升级程序的可执行程序。可选的，在所述根据服务端提供的信息获取软件包的步骤中，获取的不仅包括所述动态升级软件包，还包括功能扩展软件包；所述通过安装已获取的安装包生成的可执行程序，不仅包括所述动态升级程序，还包括为所述动态升级程序提供功能扩展服务的功能扩展程序。相应的，本申请还提供一种对支撑层软件功能的升级装置，包括：升级代码注入单元，用于运行包含升级代码的动态升级程序，并通过进程合并机制将所述动态升级程序注入到支撑层服务进程中；升级代码替换单元，用于将支撑层待升级功能接口的功能实现代码设置为相应的升级代码。可选的，所述升级代码注入单元具体用于，在所述动态升级程序的配置文件中，预先指定运行所述动态升级程序的进程名称与支撑层服务进程一致；运行所述动态升级程序，以将其注入到所述支撑层服务进程中。可选的，所述升级代码替换单元，具体用于采用hook方式实现将支撑层待升级功能接口的功能实现代码设置为相应的升级代码。可选的，所述装置包括：触发工作单元，用于所述支撑层服务进程在系统初始化阶段触发所述升级代码注入单元工作。可选的，所述触发工作单元包括：接收消息注册子单元，用于所述动态升级程序预先向系统注册以下需求：接收系统初始化阶段的预设消息；消息广播子单元，用于所述支撑层服务进程在系统初始化阶段广播所述预设消息，并根据所述动态升级程序预先注册的所述需求、触发所述升级代码注入单元工作。可选的，所述装置还包括：功能扩展程序启动单元，用于启动在所述支撑层服务进程之外运行的、为所述动态升级程序提供功能扩展服务的功能扩展程序。可选的，所述装置还包括可执行程序生成单元；所述单元包括：软件包请求子单元，用于向服务端发送软件包获取请求，请求获取用于升级支撑层软件功能的软件包；软件包获取子单元，用于根据服务端提供的信息获取软件包，其中至少包括动态升级软件包；软件包安装子单元，用于通过安装已获取的软件包，生成至少包括所述动态升级程序的可执行程序。可选的，所述软件包获取子单元，具体用于根据服务端提供的信息获取动态升级软件包和功能扩展软件包；所述软件包安装子单元，具体用于通过安装已获取的软件包，生成所述动 态升级程序和功能扩展程序。此外，本申请还提供一种对支撑层动态升级程序的管理方法，包括：判断用于升级支撑层软件功能的动态升级程序是否与宿主系统兼容；若不兼容，则卸载所述动态升级程序。可选的，所述判断用于升级支撑层软件功能的动态升级程序是否与宿主系统兼容，包括：判断用所述动态升级程序包含的升级代码执行动态替换操作是否返回表征操作成功的结果，若否，则判定所述动态升级程序与宿主系统不兼容。可选的，所述判断用于升级支撑层软件功能的动态升级程序是否与宿主系统兼容，包括：根据所述动态升级程序的历史启动信息，判断由于用所述动态升级程序包含的升级代码执行动态替换操作、导致系统重启的状况是否满足预设条件，若满足，则判定所述动态升级程序与宿主系统不兼容。可选的，所述预设条件，包括：重启次数大于预设阈值。可选的，在所述判定所述动态升级程序与宿主系统不兼容之后，在卸载所述动态升级程序之前，包括：取消执行所述动态替换操作。可选的，所述卸载所述动态升级程序，包括：提示用户所述动态升级程序与宿主系统不兼容；并根据用户的指令卸载所述动态升级程序。可选的，所述动态升级程序，是在宿主系统中安装从服务端获取的动态升级软件包后生成的可执行程序；当所述判断用于升级支撑层软件功能的动态升级程序是否与宿主系统兼容的结果为不兼容时，还包括：收集并生成所述动态升级程序与宿主系统不兼容的相关日志信息，并将所述日志信息上传到所述服务端。可选的，当所述判断用于升级支撑层软件功能的动态升级程序是否与宿主系统兼容的结果为不兼容时，还包括：卸载为所述动态升级程序提供功能扩展服务的功能扩展程序。相应的，本申请还提供一种对支撑层动态升级程序的管理装置，包括：兼容性判断单元，用于判断用于升级支撑层软件功能的动态升级程序是否与宿主系统兼容；动态升级程序卸载单元，用于当所述兼容性判断单元的输出为不兼容时，卸载所述动态升级程序。可选的，所述兼容性判断单元，具体用于判断用所述动态升级程序包含的升级代码执行动态替换操作是否返回表征操作成功的结果，若否，则判定所述动态升级程序与宿主系统不兼容。可选的，所述兼容性判断单元，具体用于根据所述动态升级程序的历史启动信息，判断由于用所述动态升级程序包含的升级代码执行动态替换操作、导致系统重启的状况是否满足预设条件，若满足，则判定所述动态升级程序与宿主系统不兼容。可选的，所述动态升级程序卸载单元，包括：卸载提示子单元，用于提示用户所述动态升级程序与宿主系统不兼容；卸载执行子单元，用于根据用户的指令卸载所述动态升级程序。可选的，所述装置还包括：不兼容信息上传单元，用于当所述兼容性判断单元的输出为不兼容时，收集并生成所述动态升级程序与宿主系统不兼容的相关日志信息，并将所述日志信息上传到服务端；所述服务端是提供对应于所述动态升级程序的动态升级软件包的服务端。可选的，所述装置还包括：功能扩展程序卸载单元，用于当所述兼容性判断单元的输出为不兼容时，卸载为所述动态升级程序提供功能扩展服务的功能扩展程序。与现有技术相比，本申请具有以下优点：本申请提供的对支撑层软件功能的访问方法，在接收应用程序对支撑层功能接口的访问请求后，执行对应于所述功能接口的升级代码，其中，包含所述升级代码的动态升级程序通过进程合并机制被预先注入到支撑层服务进程中，并且所述功能接口的功能实现代码被设置为所述升级代码。采用上述方法，在接收应用程序对支撑层功能接口的访问请求后，没有按照常规方式执行所述功能接口的原实现代码，而是执行利用进程合并机制注入的升级代码，即，在没有采用传统ota方式进行系统软件升级的情况下，应用程序依然可以访问到升级后的支撑层软件功能，从而能够及时地为用户提供更为完善的功能，也可以相应提升用户的使用体验。附图说明图1是本申请的一种对支撑层软件功能的升级方法的实施例的流程图；图2是本申请的一种对支撑层软件功能的升级装置的实施例的示意图；图3是本申请的一种对支撑层软件功能的访问方法的实施例的流程图；图4是本申请实施例提供的支撑层服务进程接收应用程序访问请求后的处理过程示意图；图5是本申请的一种对支撑层软件功能的访问装置的实施例的示意图；图6是本申请的一种对支撑层动态升级程序的管理方法的实施例的流程图；图7是本申请的一种对支撑层动态升级程序的管理装置的实施例的示意图。具体实施方式在下面的描述中阐述了很多具体细节以便于充分理解本申请。但是，本申请能够以很多不同于在此描述的其它方式来实施，本领域技术人员可以在不违背本申请内涵的情况下做类似推广，因此，本申请不受下面公开的具体实施的限制。在本申请中，分别提供了一种对支撑层软件功的访问方法及装置，一种对支撑层软件功能的升级方法及装置，以及一种对支撑层动态升级程序的管理方法及装置。在下面的实施例中逐一进行详细说明。为了便于理解，首先描述本申请提供的一种对支撑层软件功能的升级方法的实施例。在描述本实施例的具体步骤之前，先对本技术方案以及动态升级程序的生成过程做简要的说明。本技术方案的核心在于：通过进程合并机制，将包含升级代码的动态升级程序注入到支撑层服务进程中，并在此基础上将支撑层相应功能接口的功能实 现代码设置为所述升级代码，从而实现了对支撑层软件功能的轻量、动态升级方式，应用程序则可以访问升级后的支撑层软件功能。与采用传统ota方式对系统软件升级相比较，本方法只需要通过进程合并、以及将相应功能接口的功能实现代码设置为升级代码，即可实现升级代码的动态加载，实现对支撑层软件功能的升级，从而在ota实施困难的情况下，提供了一种快捷的、轻量级的支撑层软件功能升级方法。本实施例所述的支撑层，通常是指在系统软件分层架构中为应用程序提供服务的软件层，其中包含一系列库、函数或者组件的集合，并且通过对外提供功能接口的方式对应用程序提供服务。应用程序需要实现某一系统功能时，可以访问支撑层提供的相应功能接口。以移动操作系统android或者yunos为例，为应用程序提供服务的支撑层可以是框架层(framework)，支撑层功能接口可以是框架层中的组件提供的功能接口。为了实现对支撑层软件功能的升级，在具体实施中，可以先从服务端获取动态升级软件包、并通过安装生成可执行的动态升级程序。具体实现可以是：向服务端发送软件包获取请求，请求获取用于升级支撑层软件功能的软件包；根据服务端提供的信息获取动态升级软件包；通过安装已获取的软件包生成可执行的动态升级程序。其中，所述服务端可以为云端。以在android操作系统中实施为例，服务端可以针对框架层待升级的功能接口生成相应的升级代码，并制作动态升级软件包，通常是后缀为apk的软件包；实施本方法的移动设备(例如：智能手机)可以按照一定的策略，例如定期，向服务端发送获取用于升级框架层软件功能的软件包的请求，所述请求中可以携带终端类型、原有软件包版本号等信息；服务端收到请求后，查询与终端信息匹配的、可供移动设备升级安装的动态升级软件包，并提示移动设备从相应的网站下载；移动设备根据服务端提供的信息下载并安装动态升级软件包，这样就生成了可执行的动态升级程序，该程序中包含了用于实现框架层某个或者某些功能接口的升级功能的升级代码。优选地，还可以从服务端获取功能扩展软件包、并安装生成为动态升级程序提供功能扩展服务的功能扩展程序。为了实现本技术方案，需要将动态升级程序注入到支撑层服务进程中，而支撑层服务进程在操作系统中通常起着维护应用程序执行环境的作用，为了保证支撑层服务进程的稳定运行，动态升级程序中可以仅包含需要执行动态替换的升级代码的最小集合，而将无需运行在支 撑层服务进程中的功能交由在支撑层服务进程之外运行的功能扩展程序实现，而动态升级程序提供的升级代码，则可以通过调用功能扩展程序提供的功能扩展接口、使用其提供的扩展服务，既可以实现所需功能，同时也最大限度地保证了支撑层的稳定运行。基于上述考虑，宿主设备在上述获取动态升级软件包的同时，可以一并获取功能扩展软件包，并且通过安装获取的软件包，生成动态升级程序、以及为动态升级程序提供功能扩展服务的功能扩展程序。至此，对本技术方案以及动态升级程序(和功能扩展程序)的生成过程进行了说明。在具体实施时，对于首次安装并生成动态升级程序的情况，可以随后执行以下提供的实施例中的步骤101与102，对于更新安装的情况，则可以提示用户重新启动系统，并在系统初始化过程中执行所述步骤101与102，从而实现支撑层软件功能的升级。下面以在系统初始化阶段实施本方法为例，对本申请提供的一种对支撑层软件功能的升级方法的实施例进行详细描述。参考图1，其为本申请的一种对支撑层软件功能的升级方法的实施例的流程图，所述方法包括如下步骤：步骤101、运行包含升级代码的动态升级程序，并通过进程合并机制将所述动态升级程序注入到支撑层服务进程中。在具体实施时，通常可以在实施本方法的系统(以下简称宿主系统)初始化的过程中实施本方法，例如可以由支撑层服务进程在初始化阶段触发本方法执行，从而可以在宿主系统的初始化阶段，就完成支撑层软件功能的动态升级，应用程序随后发起的对支撑层功能接口的访问请求，就可以访问到升级后的实现代码。下面以在采用android系统的移动设备上实施为例进行说明。动态升级程序可以通过访问配置文件等方式预先向系统注册以下需求：接收系统初始化阶段的预设消息；在移动设备启动后，android系统执行标准开机流程，依次启动引导程序(bootloader)，内核及框架层服务进程，框架层服务进程在初始化阶段可以广播所述预设消息，由于动态升级程序已经预先注册了接收所述预设消息的需求，因此框架层服务进程就会触发本方法的执行，运行动态升级程序，从而动态升级程序就可以接收到所述预设消息。这里所述预设消息通常是指框架层服务进程在系统启动阶段广播的消息，例如可以是开机完成消息，也可以是其他消息。本方法被触发执行后，首先执行本步骤：运行包含升级代码的动态升级程序，并通过进程合并机制将所述动态升级程序注入到支撑层服务进程中。所述进程合并机制是指，将多个独立的程序或者应用组件按照配置规则运行在同一操作系统进程的任务调度机制。目前，主流移动操作系统通常可以对程序或者应用组件的进程名称进行指定，从而可以让不同的程序或者应用组件运行在同一个进程中。以android移动操作系统为例，可以在配置文件(通常为androidmanifest.xml文件，也称为描述文件)中对程序或者应用组件运行的进程名称进行指定。为了便于理解，下面列举两个独立的系统组件的配置文件片段：系统组件1的配置文件片段：系统组件2的配置文件片段：其中，com.android.comp1和com.android.comp2为两个独立的系统组件，指定的进程名称相同，均为com.android.merged，那么在运行这两个系统组件时，系统会查找名称为com.android.merged的进程(如果没有则创建所述名称的进程)，并把这两个系统组件都运行在该进程中。基于上述原理，可以预先在所述动态升级程序的配置文件中，指定运行所述动态升级程序的进程名称与支撑层服务进程一致，那么在运行所述动态升级程序时，就可以通过进程合并机制，使得动态升级程序与支撑层服务进程运行在同一个进程空间中，即：将包含升级代码的动态升级程序注入到支撑层服务进程中，为后续步骤102进行动态替换做好准备。需要说明的是，为了避免上述进程合并机制被滥用，有的移动操作系统通常会为进程合并机制的实施设置一些约束条件，因此在具体实施时，除了在配 置文件中指定与支撑层服务进程相同的进程名称外，还可以执行额外的操作满足移动操作系统的约束条件，例如：动态升级程序与支撑层的数字签名一致，为动态升级程序指定的操作系统用户标识符(id)与支撑层相同等。本步骤通过进程合并机制、将包含升级代码的动态升级程序注入到支撑层服务进程中，不仅为后续执行动态替换操作做好准备，而且不会打破移动操作系统原有的完整性，能够为整个系统的安全运行提供有力保障。步骤102、将支撑层待升级功能接口的功能实现代码设置为相应的升级代码。执行步骤101后，包含升级代码的动态升级程序已经被注入到支撑层服务进程中，本步骤则将支撑层相应功能接口的功能实现代码设置为已注入的相应升级代码。所述动态升级程序中通常包含支撑层中待升级的若干个功能接口的升级代码，所述升级代码是对相应功能接口所实现功能进行升级的实现代码，通常是可执行代码，也可以称为目标代码。对于支撑层某个待升级功能接口来说，将其功能实现代码设置为动态升级程序中的相应升级代码后，当应用程序发起对该功能接口的访问请求后，支撑层就会执行升级代码，从而应用程序就可以访问到升级后的支撑层软件功能，即：实现了对支撑层软件功能的重新定义。将支撑层功能接口的功能实现代码设置为升级代码，从技术实现的角度可以采用代码替换或者重定向两种方式，在本实施例以及后续实施例中，将采用代码替换方式或者重定向方式、将功能接口的功能实现代码设置为相应升级代码的过程统称为动态替换。下面分别对这两种方式进行说明。(一)代码替换，即：将待升级功能接口的原实现代码直接替换为相应的升级代码。例如，原来实现所述功能接口的代码为a，动态升级程序中包含的相应升级代码为a′，那么本步骤可以用a′替换a，此后若接收到应用程序对所述功能接口的访问，实际执行的则是a′。(二)重定向，即：不执行代码替换操作，而是将对待升级功能接口的访问重定向到相应的升级代码。例如，可以修改用于存储所述功能接口的功能实现代码首地址的指针值，使得该指针指向动态升级程序中的相应升级代码，从而若接收到应用程序对所述功能接口的访问，将根据该指针的指向执行相应的升级代码。在具体实施时，上述重定向技术可以采用不同的方式实现，在本实施例中采用hook方式实现，以在android系统中实施为例，可以采用基于java层面的hook方式，利用虚拟机的特性以及java的反射机制实现重定向，也可以采用基于原生层面(native)的hook方式，通过解析elf(executableandlinkableformat—可执行连接格式)文件实现重定向。需要说明的是，本步骤的操作可以由支撑层服务进程执行，也可以由动态升级程序完成。在第二种情况下，动态升级程序不仅包含升级代码，还包含执行动态替换功能的代码，以在系统初始化阶段实施本方法为例，支撑层服务进程运行动态升级程序，并将动态升级程序合并运行到支撑层服务进程中，动态升级程序在接收到其预先注册的预设消息后，就可以执行动态替换操作：查找在动态升级程序中包含哪些功能接口的升级代码，并针对这些功能接口逐一进行动态替换，将功能实现代码设置为相应的升级代码。至此，通过上述步骤101-102，对本实施例提供的对支撑层软件功能的升级方法的实施方式进行了详细描述。需要说明的是，如果动态升级程序包含的升级代码在执行时需要访问功能扩展程序提供的功能扩展服务，并且在触发实施本方法之前已经安装生成了功能扩展程序，那么还可以启动在支撑层服务进程之外运行的功能扩展程序，例如：在不同于支撑层服务进程的独立进程中启动所述功能扩展程序。在具体实施时，启动功能扩展程序的时机是比较灵活的，只要能够为动态升级程序提供功能扩展服务就都是可以的。例如：功能扩展程序也可以预先注册需要接收到初始化阶段的预设消息，那么支撑层服务进程可以在初始化阶段启动功能扩展程序；或者在动态升级程序包含的升级代码需要访问功能扩展服务的情况下，通过ipc(inter-processcommunication—进程间通信机制)调用启动功能扩展程序；或者功能扩展程序按照定时器、网络状态变化等触发条件自行启动运行也是可以的。综上所述，本实施例提供的对支撑层软件功能的升级方法，没有采用传统ota方式对支撑层软件功能进行升级，而是将支撑层的待升级功能接口的升级代码包含在动态升级程序中，然后通过进程合并机制将升级代码注入到支撑层服务进程中、并通过动态替换实现了支撑层软件功能的升级，在ota实施困难的情况下，提供了一种轻量级的支撑层软件功能升级方法，从而能够及时、快 捷地升级支撑层软件功能，满足应用程序的访问需求。在上述的实施例中，提供了一种对支撑层软件功能的升级方法，与之相对应的，本申请还提供一种对支撑层软件功能的升级装置。请参看图2，其为本申请的一种对支撑层软件功能的升级装置的实施例的示意图。由于装置实施例基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。下述描述的装置实施例仅仅是示意性的。本实施例的一种对支撑层软件功能的升级装置，包括：升级代码注入单元201，用于运行包含升级代码的动态升级程序，并通过进程合并机制将所述动态升级程序注入到支撑层服务进程中；升级代码替换单元202，用于将支撑层待升级功能接口的功能实现代码设置为相应的升级代码。可选的，所述升级代码注入单元具体用于，在所述动态升级程序的配置文件中，预先指定运行所述动态升级程序的进程名称与支撑层服务进程一致；运行所述动态升级程序，以将其注入到所述支撑层服务进程中。可选的，所述升级代码替换单元，具体用于采用hook方式实现将支撑层待升级功能接口的功能实现代码设置为相应的升级代码。可选的，所述装置包括：触发工作单元，用于所述支撑层服务进程在系统初始化阶段触发所述升级代码注入单元工作。可选的，所述触发工作单元包括：接收消息注册子单元，用于所述动态升级程序预先向系统注册以下需求：接收系统初始化阶段的预设消息；消息广播子单元，用于所述支撑层服务进程在系统初始化阶段广播所述预设消息，并根据所述动态升级程序预先注册的所述需求、触发所述升级代码注入单元工作。可选的，所述装置还包括：功能扩展程序启动单元，用于启动在所述支撑层服务进程之外运行的、为所述动态升级程序提供功能扩展服务的功能扩展程序。可选的，所述装置还包括可执行程序生成单元；所述单元包括：软件包请求子单元，用于向服务端发送软件包获取请求，请求获取用于升 级支撑层软件功能的软件包；软件包获取子单元，用于根据服务端提供的信息获取软件包，其中至少包括动态升级软件包；软件包安装子单元，用于通过安装已获取的软件包，生成至少包括所述动态升级程序的可执行程序。可选的，所述软件包获取子单元，具体用于根据服务端提供的信息获取动态升级软件包和功能扩展软件包；所述软件包安装子单元，具体用于通过安装已获取的软件包，生成所述动态升级程序和功能扩展程序。此外，本申请还提供一种对支撑层软件功能的访问方法，在实施本方法之前，可以预先实施本申请提供的对支撑层软件功能的升级方法，实现对支撑层软件功能的升级，即：通过进程合并机制将包含升级代码的动态升级程序注入到支撑层服务进程中，并将相应功能接口的功能实现代码设置为所述升级代码。其中，所述动态升级程序，是在宿主系统中安装从服务端获取的、用于升级支撑层软件功能的动态升级软件包后生成的可执行程序。在完成对支撑层软件功能的升级后，当应用程序访问支撑层已升级的功能接口时，即可通过本申请提供的对支撑层软件功能的访问方法，执行对应于所述功能接口的升级代码。请参考图3，其为本申请的一种对支撑层软件功能的访问方法的实施例的流程图，本方法通常在支撑层服务进程中实施。本实施例与上述方法实施例步骤相同的部分不再赘述，下面重点描述不同之处。本实施例的一种对支撑层软件功能的访问方法包括如下步骤：步骤301、接收应用程序对支撑层功能接口的访问请求。在本实施例中所述支撑层功能接口是指已被升级的支撑层功能接口，即：其功能实现代码已被设置为动态升级程序包含的相应升级代码。当应用程序发起对所述功能接口的访问请求后，本步骤就可以接收到所述访问请求。以android系统为例，框架层中的每个组件都可以对外提供一个或者多个功能接口，当应用程序需要访问某个组件提供的功能能力(例如：拨打电话、获取imei号码等)时，可以发起对相应功能接口的访问请求，框架层服务进程就 可以接收到该访问请求。步骤302、执行对应于所述功能接口的升级代码。由于所述功能接口的功能实现代码已经被设置为相应的升级代码，因此本步骤执行的是对应于所述功能接口的升级代码，从而可以为应用程序提供升级后的支撑层软件功能。在具体实施时，在执行完本步骤之后还可以将所述升级代码的执行结果返回给所述应用程序。优选地，在执行对应于所述功能接口的升级代码的过程中，还包括：调用在所述支撑层服务进程之外运行的功能扩展程序提供的功能扩展接口。其中，所述功能扩展程序，是在宿主系统中安装功能扩展软件包后生成的可执行程序，所述功能扩展软件包是从所述服务端获取所述动态升级软件包时一并获取的。例如，所述功能接口的升级代码实现获取移动设备imei号码(移动设备国际识别码)的功能，为了提供安全性保障，还需要对请求方是否具有相应获取权限进行检查，而权限检查功能由在支撑层服务进程之外运行的功能扩展程序实现，在这种情况下，可以在所述升级代码中包含对功能扩展程序提供的权限检查接口的调用代码，那么本步骤在执行所述升级代码时，就可以相应地执行对权限检查接口的调用操作，并由功能扩展程序内部相应的功能扩展代码进行权限检查，升级代码则根据功能扩展程序返回的结果决定是否可以向应用程序提供imei号码并进行相应的处理。为了便于理解，此处以图示的方式给出一个具体的例子，请参见图4，其为支撑层服务进程接收应用程序访问请求后的处理过程示意图，在图4给出的实施方式中，预先采用重定向方式将功能接口1的功能实现代码设置为相应的升级代码。其中操作1代表支撑层服务进程接收应用程序对功能接口1的访问请求，操作2代表支撑层服务进程执行功能接口1的升级代码，操作3代表所述升级代码调用功能扩展程序提供的功能扩展接口1实现所需功能。上述给出了升级代码调用一个功能扩展接口的例子，在具体实施时，如果功能扩展程序提供的某一功能扩展接口无法满足升级代码的需要，升级代码还可以调用功能扩展程序提供的其他多个功能扩展接口，即访问功能扩展程序提供的多个功能实现，也可以调用其他进程或者组件提供的api。在具体实施时，升级代码对功能扩展程序提供的功能扩展接口的调用操作，可以利用ipc机制实现。如果功能扩展程序尚未启动，则可以通过ipc调用启 动功能扩展程序，然后再访问所需的功能扩展接口。采用上述访问功能扩展接口的优选实施方式，可以将一些复杂的、或者无法对运行稳定性做出准确评估的功能交由功能扩展程序完成，由于功能扩展程序在支撑层服务进程之外运行，因此支撑层既可以使用功能扩展程序提供的服务，又可以保证其自身的稳定运行。至此，通过上述步骤301-302对本实施例提供的、对支撑层软件功能的访问方法的实施方式进行了详细说明。通过上述描述可以看出，采用上述方法，由于在接收应用程序对支撑层功能接口的访问请求后，没有按照常规方式执行功能接口的原实现代码，而是执行利用进程合并机制注入并动态替换后的升级代码，即，在没有采用传统ota方式进行系统软件升级的情况下，应用程序依然可以访问到升级后的支撑层软件功能，从而能够及时地为用户提供更为完善的功能，也可以相应提升用户的使用体验。在上述的实施例中，提供了一种对支撑层软件功能的访问方法，与之相对应的，本申请还提供一种对支撑层软件功能的访问装置。请参看图5，其为本申请的一种对支撑层软件功能的访问装置的实施例的示意图。由于装置实施例基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。下述描述的装置实施例仅仅是示意性的。本实施例的一种对支撑层软件功能的访问装置，包括：访问请求接收单元501，用于接收应用程序对支撑层功能接口的访问请求；升级代码执行单元502，用于执行对应于所述功能接口的升级代码，其中，包含所述升级代码的动态升级程序通过进程合并机制被预先注入到支撑层服务进程中，并且所述功能接口的功能实现代码被设置为所述升级代码。可选的，所述装置还包括：执行结果返回单元，用于将所述升级代码执行单元的执行结果返回给所述应用程序。可选的，所述升级代码执行单元，具体用于执行对应于所述功能接口的升级代码，并在执行所述升级代码的过程中调用在支撑层服务进程之外运行的功能扩展程序提供的功能扩展接口。可选的，所述升级代码执行单元，具体用于通过进程间通信机制实现对所述功能扩展接口的调用。此外，本申请还提供一种对支撑层动态升级程序的管理方法。由于移动设备软件版本实现差异较大，用于升级支撑层软件功能的动态升级程序可能存在与宿主系统不兼容的问题，那么运行动态升级程序并执行动态替换操作后，可能导致宿主系统无法正常工作甚至无法正常启动。针对这一问题，本申请提出的对支撑层动态升级程序的管理方法，可以对兼容性进行检测、并在检测到不兼容时卸载动态升级程序，从而对本申请提出的支撑层软件功能轻量升级技术方案，提供了一种故障检测及恢复机制，是对该技术方案的有益补充。请参考图6，其为本申请提供的一种对支撑层动态升级程序的管理方法的实施例的流程图。本实施例与上述方法实施例步骤相同的部分不再赘述，下面重点描述不同之处。本实施例的一种对支撑层动态升级程序的管理方法包括如下步骤：步骤601、判断用于升级支撑层软件功能的动态升级程序是否与宿主系统兼容，若兼容，则执行步骤603，否则，执行步骤602。所述动态升级程序与宿主系统不兼容可以有不同的表现形式，因此判断是否不兼容也可以采用不同的方式，本实施例列举两种：1)判断用所述动态升级程序包含的升级代码执行动态替换操作是否返回表征操作成功的结果，若否，则判定所述动态升级程序与宿主系统不兼容。例如：在支撑层中不存在与升级代码对应的功能接口，或者，升级代码涉及的入口参数与原始实现代码涉及的入口参数不匹配，导致无法进行动态替换，此时动态替换操作都会返回失败结果，在这种情况下，虽然没有导致系统重启，也可以判定所述动态升级程序与宿主系统不匹配。2)根据所述动态升级程序的历史启动信息，判断由于用所述动态升级程序包含的升级代码执行动态替换操作、导致系统重启的状况是否满足预设条件，若是，则判定所述动态升级程序与宿主系统不兼容。在具体实施时，可以在动态升级程序的启动过程中，记录启动次数、并将动态升级程序的启动状态设置为正在启动；如果成功完成了动态替换操作，则可以设置动态升级程序的启动状态为启动成功，并记录此次启动成功的相关信息。采用上述方式记录的动态升级程序的历史启动信息，可以作为判断动态升级程序是否与宿主系统兼容的依据。由于动态升级程序通常在宿主系统的初始化阶段运行、并执行动态替换操作，因此可以在宿主系统的初始化阶段、尚未执行动态替换操作之前对兼容性做出判断，具体实现可以为：从已记录的历史启动信息中读取动态升级程序上一次的启动状态，如果所述启动状态为“正在启动”，则说明由于上一次执行动态替换操作导致了宿主系统的本次重启。如果由于执行动态替换操作导致系统重启的状况满足预设条件，则可以判定动态升级程序与宿主系统不兼容。例如：如果由于执行动态替换操作导致系统重启的次数大于预设阈值(例如：3次)，则可以判定动态升级程序与宿主系统不兼容。在具体实施时，在执行上述判断时，还可以综合考虑上述历史启动信息中记录的动态升级程序的启动总次数、启动成功的历史相关信息等，并且可以设置不同的预设条件。如果判断结果为：动态升级程序与宿主系统不兼容，可以取消执行动态替换操作，保证宿主系统能够正常启动并运行；否则，可以正常执行动态替换操作以实现对支撑层软件功能的升级。以上给出了判断动态升级程序与宿主系统的兼容性的两种方式，在具体实施也可以采用不同于上述方式的其他判断方式。如果判定动态升级程序与宿主系统不兼容，则转到步骤602执行。步骤602、卸载所述动态升级程序。执行到本步骤说明动态升级程序与宿主系统不兼容，在这种情况下，可以卸载动态升级程序。具体实现可以是：提示用户所述动态升级程序与宿主系统不兼容，并根据用户的指令卸载所述动态升级程序。如果宿主系统中安装了为动态升级程序提供扩展功能服务的功能扩展程序，那么在卸载动态升级程序的同时，还可以卸载功能扩展程序。此外，在具体实施时，如果步骤601的判定动态升级程序与宿主系统不兼容，还可以收集并生成记录不兼容状态的相关日志信息，并将所述日志信息上传到提供动态升级软件包(动态升级程序的安装包)的服务端。所述日志信息可以包括：动态替换失败原因，动态升级程序启动次数、失败现场的上下文信息等。服务端根据接收到的日志信息可以分析、定位故障原因，并在消除故障后制作新版本的动态升级软件包并提供给移动设备，以便移动设备能够成功升级支撑层软件功能。步骤603、保留所述动态升级程序。执行到本步骤说明动态升级程序与宿主系统兼容，因此可以保留所述动态升级程序，而不必执行卸载操作。至此，通过步骤601-603对本实施例提供的对支撑层动态升级程序的管理方法的实施方式进行了详细描述。通过上述描述可以看出，所述管理方法提供了一种针对动态升级程序的故障检测与恢复方法，在检测到动态升级程序与宿主系统不兼容时，可以通过卸载动态升级程序进行回退，保障宿主系统的正常运行。在上述的实施例中，提供了一种对支撑层动态升级程序的管理方法，与之相对应的，本申请还提供一种对支撑层动态升级程序的管理装置。请参看图7，其为本申请的一种对支撑层动态升级程序的管理装置的实施例的示意图。由于装置实施例基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。下述描述的装置实施例仅仅是示意性的。本实施例的一种对支撑层动态升级程序的管理装置，包括：兼容性判断单元701，用于判断用于升级支撑层软件功能的动态升级程序是否与宿主系统兼容；动态升级程序卸载单元702，用于当所述兼容性判断单元的输出为不兼容时，卸载所述动态升级程序；动态升级程序保留单元703，用于当所述兼容性判断单元的输出为兼容时，保留所述动态升级程序。可选的，所述兼容性判断单元，具体用于判断用所述动态升级程序包含的升级代码执行动态替换操作是否返回表征操作成功的结果，若否，则判定所述动态升级程序与宿主系统不兼容。可选的，所述兼容性判断单元，具体用于根据所述动态升级程序的历史启动信息，判断由于用所述动态升级程序包含的升级代码执行动态替换操作、导致系统重启的状况是否满足预设条件，若满足，则判定所述动态升级程序与宿主系统不兼容。可选的，所述动态升级程序卸载单元，包括：卸载提示子单元，用于提示用户所述动态升级程序与宿主系统不兼容；卸载执行子单元，用于根据用户的指令卸载所述动态升级程序。可选的，所述装置还包括：不兼容信息上传单元，用于当所述兼容性判断单元的输出为不兼容时，收 集并生成所述动态升级程序与宿主系统不兼容的相关日志信息，并将所述日志信息上传到服务端；所述服务端是提供对应于所述动态升级程序的动态升级软件包的服务端。可选的，所述装置还包括：功能扩展程序卸载单元，用于当所述兼容性判断单元的输出为不兼容时，卸载为所述动态升级程序提供功能扩展服务的功能扩展程序。本申请虽然以较佳实施例公开如上，但其并不是用来限定本申请，任何本领域技术人员在不脱离本申请的精神和范围内，都可以做出可能的变动和修改，因此本申请的保护范围应当以本申请权利要求所界定的范围为准。在一个典型的配置中，计算设备包括一个或多个处理器(cpu)、输入/输出接口、网络接口和内存。内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(ram)和/或非易失性内存等形式，如只读存储器(rom)或闪存(flashram)。内存是计算机可读介质的示例。1、计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd-rom)、数字多功能光盘(dvd)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括非暂存电脑可读媒体(transitorymedia)，如调制的数据信号和载波。2、本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。当前第1页12当前第1页12