WO2015078166A1

WO2015078166A1 - 系统应用安装包加载处理方法、装置及终端

Info

Publication number: WO2015078166A1
Application number: PCT/CN2014/079294
Authority: WO
Inventors: 潘浩杰; 田琪星; 刘小锐
Original assignee: 中兴通讯股份有限公司
Priority date: 2013-11-28
Filing date: 2014-06-05
Publication date: 2015-06-04
Also published as: US20160378458A1; CN104679534B; CN104679534A

Abstract

本发明提供了一种系统应用安装包加载处理方法、装置及终端，该方法包括：采用的在对系统应用安装包更新处理之前，将该系统应用安装包重命名为系统应用安装备份包；判断采用系统应用安装更新包是否加载成功，其中，系统应用安装更新包为对系统应用安装备份包进行拷贝后的拷贝版本进行更新后获取的系统应用安装包；在判断结果为否的情况下，采用上述系统应用安装备份包进行加载处理，通过本发明，解决了相关技术中存在的当系统应用安装包进行拷贝生成备份文件出错时，造成的系统应用安装包中的数据异常，导致终端无法开机的问题，进而达到了提高系统稳定性和用户体验的效果。

Description

系统应用安装包加载处理方法、装置及终端技术领域本发明涉及通信领域，具体而言，涉及一种系统应用安装包加载处理方法、装置及终端。背景技术随着安卓 Android智能机的普及，与之配套的上层应用（application,简称为 APP) 开发也发展迅猛，网络上随时会提供海量的免费安卓安装包（Android Package, 简称为 APK) 进行下载和安装使用。在此背景下，用户在 Android智能手机终端上安装和卸载 APK已经成为智能手机使用中的一个重要场景。 Android系统中的应用程序包管理服务模块，就是专门针对该场景的功能模块，包管理服务（PACKAGER MANAGER SERVICE) 是在系统启动阶段由系统服务（SYSTEM SERVER) 启动的一个 JAVA层月艮务， ffljfe' S/system/framework system /app ,/data/app,/data/app-private目录下的 APK 文件，主要工作步骤如下：

1.建立 java层的 installer与 c层的 installd的套接字 socket联接，使得在上层的安装（install), 移除（remove), 优化（dexopt) 等功能最终由 installd在底层实现。

2.建立包控制（PackageHandler) 消息环，用于处理外部的 apk安装请求消息，如 adb install, packageinstaller安装 apk时会发送消息。

3.角牟析 /system/etc/permission 下 xml 文件 ( framework/base/data/etc/ ) , 包括 platform.xml和系统支持的各种硬件模块的 feature。 ( 1 ) 建立底层用户标识符（user ids) 和群组标识符（group ids) 同上层许可

(permissions) 之间的映射；可以指定一个权限与几个组 ID对应。当一个 APK被授予这个权限时，它也同时属于这几个组；

(2)给一些底层用户分配权限，如给壳（shell)授予各种 permission权限；把一个权限赋予一个用户身份证明（User Identification,简称为 UID)，当进程使用这个 UID 运行时，就具备了这个权限；

(3 ) 库（library), 系统增加的一些应用需要链接（link) 的扩展 jar库; (4) 特征（feature), 系统每增加一个硬件，都要添加相应的 feature.将解析结果方文入 mSystemPermissions,mSharedLibraries, mSettings.mPermissions,mAvailableFeatures 等几个集合中供系统查询和权限配置使用。

4.检查 /data/system/packages.xml是否存在，这个文件是在解析 apk时由 writeLP ( ) 创建的，里面记录了系统的 permissions, 以及每个安装包（apk) 的名称（name), 代码路径（codePath), 标识（flags), ts，版本（version), 用户标识符（uesrid)等信息，这些信息主要通过 apk的 AndroidManifest.xml解析获取，解析完 apk后将更新信息写入这个文件并保存到 flash，下次开机直接从里面读取相关信息添加到内存相关列表中。当有 apk升级，安装或删除时会更新这个文件。 5.检查 BootClassPath, mSharedLibraries 及 /system/framework下的 jar是否需要 dexopt, 需要的则通过 dexopt进行优化。

6. 启动 AppDirOb server 线禾呈监测 / system/framework, /system /app, /data/app,/data/app-private 目录的事件,主要监听增添（add) 和移除（remove) 事件。对于目录监听底层通过通报（inotify)机制实现， inotify是一种文件系统的变化通知机制，如文件增加、删除等事件可以立刻让用户态得知,它为用户态监视文件系统的变化提供了强大的支持。当有增添事件（add event)时调用 scanPackageLI (File , int ,int) 处理；当有移除事件（remove event) 时调用 removePackageLI ( ) 处理。

7.对于以上几个目录下的 apk 逐个解析，主要是解析每个 apk 的 AndroidMa-nifest.xml文件，处理 asset/res等资源文件，建立起每个 apk的配置结构信息，并将每个 apk的配置信息添加到全局列表进行管理。调用 installer.install ( ) 进行安装工作,检查 apk里的 dex文件是否需要再优化，如果需要优化则通过辅助工具 dexopt 进行优化处理；将解析出的组件（componet) 添加到 pkg的对应列表里；对 apk进行签名和证书校验,进行完整性验证。

8.将解析的每个 apk 的信息保存到 packages.xml 和 packages.list 文件里， packages.list记录了如下数据：安卓安装包名称（pkgName), 用户 ID (userld), 调试标记（debugFlag), 包的数据路径（dataPath)。从整个 Android应用程序包管理服务的工作流程可以看出，在每次进行应用安装或者卸载时，均会对每个发生变化 apk的 name, codePath, flags, ts,version,uesrid等信息进行更新，这些信息主要通过 apk的 AndroidManifest.xml解析获取，解析完 apk后将更新信息写入 Package.xml并保存到 flash, 下次开机直接从里面读取相关信息添加到内存相关列表中。在应用程序安装或卸载过程中，会对 Package.xml进行拷贝，重新生成备份文件。在此过程中，如果任何一个环节出错，尤其是在拷贝过程中产生数据丢失，将会导致 Package.xml 中的数据异常，在下次开机加载时失败，从而会引起手机无法开机。从网上反馈的信息看，有不少用户在使用 Android智能手机一段时间后，出现了手机无法开机的问题，实际分析故障机时也多次遇到， Package.xml数据异常导致无法正常开机，在此种情况下，只能到售后网点重新烧录手机软件版本才能恢复，但是带来的用户数据丢失时非常严重的问题。发明内容本发明提供了一种系统应用安装包加载处理方法及装置，以至少解决相关技术中存在的当系统应用安装包进行拷贝生成备份文件出错时，造成的系统应用安装包中的数据异常，导致终端无法开机的问题。根据本发明的一个方面，提供了一种系统应用安装包加载处理方法，包括：在对系统应用安装包更新处理之前，将所述系统应用安装包重命名为系统应用安装备份包；判断采用系统应用安装更新包是否加载成功，其中，所述系统应用安装更新包为对所述系统应用安装备份包进行拷贝后的拷贝版本进行更新后获取的系统应用安装包；在判断结果为否的情况下，采用所述系统应用安装备份包进行加载处理。优选地，在采用所述系统应用安装备份包进行加载处理之后，还包括：判断采用所述系统应用安装备份包加载是否成功；在判断结果为否的情况下，获取系统设备出厂第一次加载时的系统应用安装初始包和对系统应用安装包每次更新时与所述系统应用安装初始包所存在的差异部分；将所述系统应用安装初始包和所述差异部分合并为系统应用安装合并包；依据所述系统应用安装合并包进行加载处理。优选地，获取系统设备出厂第一次加载时的所述系统应用安装初始包包括：将系统设备出厂第一次加载时生成的系统应用安装初始包重命名为所述系统应用安装初始包。优选地，在依据所述系统应用安装合并包进行加载处理之后，还包括：判断依据所述系统应用安装合并包加载是否成功；在判断结果为否的情况下，通过扫描系统安装的应用生成系统应用安装扫描包；依据所述系统应用安装扫描包进行加载处理。优选地，在依据所述系统应用安装扫描包进行加载处理之后，还包括：判断依据系统应用安装扫描包加载是否成功；在判断结果为否的情况下，采用系统设备出厂第一次加载时生成的系统应用安装初始包进行加载处理。根据本发明的另一方面，提供了一种系统应用安装包加载处理装置，包括：重命名模块，设置为在对系统应用安装包更新处理之前，将所述系统应用安装包重命名为系统应用安装备份包；第一判断模块，设置为判断采用系统应用安装更新包是否加载成功，其中，所述系统应用安装更新包为对所述系统应用安装备份包进行拷贝后的拷贝版本进行更新后获取的系统应用安装包；第一加载模块，设置为在所述第一判断模块的判断结果为否的情况下，采用所述系统应用安装备份包进行加载处理。优选地，所述系统应用安装包加载处理装置还包括：第二判断模块，设置为判断采用所述系统应用安装备份包加载是否成功；获取模块，设置为在所述第二判断模块的判断结果为否的情况下，获取系统设备出厂第一次加载时的系统应用安装初始包和对系统应用安装包每次更新时与所述系统应用安装初始包所存在的差异部分；合并模块，设置为将所述系统应用安装初始包和所述差异部分合并为系统应用安装合并包；第二加载模块，设置为依据所述系统应用安装合并包进行加载处理。优选地，所述获取模块包括：重命名单元，设置为将系统设备出厂第一次加载时生成的系统应用安装初始包重命名为所述系统应用安装初始包。优选地，所述系统应用安装包加载处理装置还包括：第三判断模块，设置为判断依据所述系统应用安装合并包加载是否成功；生成模块，设置为在所述第三判断模块的判断结果为否的情况下，通过扫描系统安装的应用生成系统应用安装扫描包；第三加载模块，设置为依据所述系统应用安装扫描包进行加载处理。优选地，所述系统应用安装包加载处理装置还包括：第四判断模块，设置为判断依据系统应用安装扫描包加载是否成功；第四加载模块，设置为在判断结果为否的情况下，采用系统设备出厂第一次加载时生成的系统应用安装初始包进行加载处理。根据本发明的再一方面，提供了一种终端，包括上述任一项所述系统应用安装包加载处理装置。通过本发明，在对系统应用安装包更新处理之前，将所述系统应用安装包重命名为系统应用安装备份包；判断采用系统应用安装更新包是否加载成功，其中，所述系统应用安装更新包为对所述系统应用安装备份包进行拷贝后的拷贝版本进行更新后获取的系统应用安装包；在判断结果为否的情况下，采用所述系统应用安装备份包进行加载处理，解决了相关技术中存在的当系统应用安装包进行拷贝生成备份文件出错时，造成的系统应用安装包中的数据异常，导致终端无法开机的问题，进而达到了提高了系统稳定性和用户体验的效果。附图说明此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：图 1是根据本发明实施例的系统应用安装包加载处理方法的流程图；图 2是根据本发明实施例的系统应用安装包加载处理装置的结构框图；图 3是根据本发明实施例的系统应用安装包加载处理装置的优选结构框图一；图 4是根据本发明实施例的系统应用安装包加载处理装置的优选结构框图一中获取模块 34的结构框图；图 5是根据本发明实施例的系统应用安装包加载处理装置的优选结构框图二；图 6是根据本发明实施例的系统应用安装包加载处理装置的优选结构框图三；图 7是根据本发明实施例的终端 72的结构框图；图 8是根据本发明实施例的 Android应用程序包管理的容错方法的数据生成流程图；图 9是根据本发明实施例的 Android应用程序包管理的容错方法的数据使用的流程图。具体实施方式下文中将参考附图并结合实施例来详细说明本发明。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。在本实施例中提供了一种系统应用安装包加载处理方法，图 1是根据本发明实施例的系统应用安装包加载处理方法的流程图，如图 1所示，该流程包括如下步骤：步骤 S102, 在对系统应用安装包更新处理之前，将该系统应用安装包重命名为系统应用安装备份包；步骤 S104，判断采用系统应用安装更新包是否加载成功，其中，系统应用安装更新包为对系统应用安装备份包进行拷贝后的拷贝版本进行更新后获取的系统应用安装包；步骤 S106,在判断结果为否的情况下，采用该系统应用安装备份包进行加载处理。通过上述步骤，在对系统应用安装包更新处理之前，将该系统应用安装包重命名为系统应用安装备份包，然后对该系统应用安装备份包进行拷贝，再对拷贝的系统应用安装备份包进行更新，当系统应用更新的系统应用安装包加载失败时，采用系统应用安装备份包进行加载处理，由于系统应用安装备份包不是经过拷贝后生成的，因而有效地避免了备份拷贝出错的问题，解决了相关技术中存在的当系统应用安装包进行拷贝生成备份文件出错时，造成的系统应用安装包中的数据异常，导致终端无法开机的问题，提高了系统稳定性和用户体验。为了较好地实现上述处理方式的容错机制，可以在采用上述系统应用安装备份包进行加载处理之后，还可以判断采用上述系统应用安装备份包加载是否成功；在判断结果为否的情况下，获取系统设备出厂第一次加载时的系统应用安装初始包和对系统应用安装包每次更新时与该系统应用安装初始包所存在的差异部分；将该系统应用安装初始包和上述差异部分合并为系统应用安装合并包；依据该系统应用安装合并包进行加载处理。这样可以保证，在系统应用安装备份包加载失败时维持终端的正常开机和正常工作，系统应用安装合并包作为系统应用安装备份包的替补，可以很好的保证终端的正常使用。其中，获取系统设备出厂第一次加载时的系统应用安装初始包可以采用多种方式，例如，可以采用直接拷贝的方式，也可以采用较为安全的方式，例如，可以采用以下处理方式来实现：将系统设备出厂第一次加载时生成的系统应用安装初始包重命名为系统应用安装初始包，即该系统应用安装初始包是终端出厂第一次开机或者恢复出厂设置第一次开机时生成的最原始的系统应用安装包。为了实现更多维度地容错，在依据上述系统应用安装合并包进行加载处理之后，还可以：判断依据该系统应用安装合并包加载是否成功；在判断结果为否的情况下，通过扫描系统安装的应用生成系统应用安装扫描包；依据该系统应用安装扫描包进行加载处理。这种场景触发的概率很小，但是对于解决终端无法正常开机，无法正常工作的问题具有很好的效果，依据重新生成的系统应用安装扫描包能够实现一个更高纬度的容错机制。在上述机制均无法实现终端的开机时，为了保证用户的正常使用，较佳地，还可以采用以下处理：在依据上述系统应用安装扫描包进行加载处理之后，还包括：判断依据系统应用安装扫描包加载是否成功；在判断结果为否的情况下，采用系统设备出厂第一次加载时生成的系统应用安装初始包进行加载处理。使用该方法会使终端恢复到出厂设置的阶段，虽然会丢失所有的用户新增应用数据，但是可以保证手机处于可用状态，无需到售后网点升级版本，提高终端恢复正常工作的效率。在本实施例中还提供了一种系统应用安装包加载处理装置，该装置用于实现上述实施例及优选实施方式，已经进行过说明的不再赘述。如以下所使用的，术语"模块" 可以实现预定功能的软件和 /或硬件的组合。尽管以下实施例所描述的装置较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。图 2是根据本发明实施例的系统应用安装包加载处理装置的结构框图，如图 2所示，该装置包括重命名模块 22、第一判断模块 24和第一加载模块 26。下面对该系统应用安装包加载处理装置的结构框图进行说明。重命名模块 22，设置为在对系统应用安装包更新处理之前，将该系统应用安装包重命名为系统应用安装备份包；第一判断模块 24，连接至上述重命名模块 22，设置为判断采用系统应用安装更新包是否加载成功，其中，系统应用安装更新包为对系统应用安装备份包进行拷贝后的拷贝版本进行更新后获取的系统应用安装包；第一加载模块 26，连接至上述第一判断模块 24，设置为在上述第一判断模块 24的判断结果为否的情况下，采用上述系统应用安装备份包进行加载处理。图 3是根据本发明实施例的系统应用安装包加载处理装置的优选结构框图一，如图 3所示，该系统应用安装包加载处理装置的优选结构框图一除包括图 3所示的所有模块外，还包括：第二判断模块 32、获取模块 34、合并模块 36和第二加载模块 38，下面对该系统应用安装包加载处理装置的优选结构框图一进行说明。第二判断模块 32，连接至上述第一加载模块 26，设置为判断采用上述系统应用安装备份包加载是否成功；获取模块 34，连接至上述第二判断模块 32，设置为在上述第二判断模块的判断结果为否的情况下，获取系统设备出厂第一次加载时的系统应用安装初始包和对系统应用安装包每次更新时与该系统应用安装初始包所存在的差异部分；合并模块 36，连接至上述获取模块 34，设置为将上述系统应用安装初始包和上述差异部分合并为系统应用安装合并包；第二加载模块 38，连接至上述合并模块 36，设置为依据上述系统应用安装合并包进行加载处理。图 4是根据本发明实施例的系统应用安装包加载处理装置的优选结构框图一中获取模块 34的结构框图，如图 4所示，该获取模块 34包括重命名单元 42，下面对该获取模块 34进行说明。重命名单元 42，设置为将系统设备出厂第一次加载时生成的系统应用安装初始包重命名为系统应用安装初始包。图 5是根据本发明实施例的系统应用安装包加载处理装置的优选结构框图二，如图 5所示，该系统应用安装包加载处理装置的优选结构框图二除包括图 4所示的所有模块外，还包括：第三判断模块 52，生成模块 54和第三加载模块 56。下面对该系统应用安装包加载处理装置的优选结构框图二进行说明。第三判断模块 52，连接至上述第二加载模块 38，设置为判断依据上述系统应用安装合并包加载是否成功；生成模块 54，连接至上述第三判断模块 52，设置为在该第三判断模块 52的判断结果为否的情况下，通过扫描系统安装的应用生成系统应用安装扫描包；第三加载模块 56，连接至上述生成模块 54，设置为依据上述系统应用安装扫描包进行加载处理。图 6是根据本发明实施例的系统应用安装包加载处理装置的优选结构框图三，如图 6所示，该系统应用安装包加载处理装置的优选结构框图三除包括图 5所示的所有模块外，还包括第四判断模块 62和第四加载模块 64，下面对该系统应用安装包加载处理装置的优选结构框图三进行说明。第四判断模块 62，连接至上述第三加载模块 56，设置为判断依据系统应用安装扫描包加载是否成功；第四加载模块 64，连接至上述第四判断模块 62，设置为在判断结果为否的情况下，采用系统设备出厂第一次加载时生成的系统应用安装初始包进行加载处理。图 7是根据本发明实施例的终端 72的结构框图，如图 7所示，该终端 72包括上述任一项系统应用安装包加载处理装置 74。针对相关技术中存在的当系统应用安装包进行拷贝生成备份文件出错时，会造成系统应用安装包中的数据异常，导致终端无法开机的问题，在本实施例中，提出了一种系统应用安装包加载处理方法和装置以解决相关技术中存在的上述问题。下面以 Android系统的手机为例进行说明。为了解决由于在多次读写 Package.xml 中导致的数据异常，从而引起手机无法开机的问题，在本实施例中，提出了一种 Android应用程序包管理的容错方法及系统，针对 Package.xml 的整个操作流程新增了一套交叉多维度的容错保护机制，使手机 Flash上保存的 Package.xml不论处于什么状态，均能保证手机能正常开机使用。在每次 APK升级、安装或删除，需要对 Package.xml进行更新时，将原有的 Package.xml (即上述系统应用安装包）进行重命名为 Package_BackUP.xml (即上述系统应用安装备份包），下次开机时，先使用系统自带的 Package.xml进行内存加载启动，如果系统判断 Package.xml解析异常，导致系统无法正常开机，则使用 Package_BackUP.xml进行启动，确保手机能正常开机。如果自带的 Package.xml 能正常使用，那么在开机成功后就删除 Package—BackUP.xml, 等到下次有 APK升级、安装或删除时再次进行备份。该容错机制是 Android应用程序包管理的容错方法及系统的第一维容错保护措施，该措施的加入，可以大大降低由于频繁读取 Package.xml 出错，导致系统无法正常开机的概率。在本实施例还提出了一种优选的 Android应用程序包管理的容错方法，在手机出厂第一次开机或者恢复出厂设置第一次开机时，将生成的 Package.xml进行备份，重命名为 Packagejnit.xml (同上述系统应用安装初始包），作为原始文件保存，该文件一直存在于 data/system/下，开机成功后也不进行删除。每次 APK升级、安装或删除，对 Package.xml进行更新时，将更新内容单独存放一个文件 Package_Add.xml (同上述差异部分），此文件也一直存在于 /data/system/下，每次随系统的 Package.xml更新而更新，记录下所有与出厂时自带应用程序的差异。当 Package—BackUP.xml失效时，启动此场景下的容错机制，将 Package_Add.xml和 Package_Init.xml进行混合，生成新的 Package.xml (同上述系统应用安装合并包）供系统使用。为了实现系统应用安装包的更高纬度的容错，在本实施例中还提供了一种 Android 应用程序包管理的容错方案，即当上述容错机制仍然不起作用时，进入更高纬度的容错机制中，直接将 Package_BackUP.xml与 Package.xml删除，让系统重新全部扫描已经安装的应用，重新根据每个 apk的 name, code Path , flags, ts, version, user ID等信息，生成新的 Package.xml (同上述系统应用安装扫描包），此种场景触发的概率已经非常小，由于需要重新扫描已安装的所有应用信息，在此种场景下手机的开机时间会增加。当上述容错机制仍然不起作用时，在本实施例中还提出了一种 Android应用程序包管理的容错方案，直接使用 Packagejnit.xml作为默认配置文件启用，此时手机恢复到出厂设置的阶段。下面结合附图对本发明优选实施方式的 Android应用程序包管理的容错方案进行说明。图 8是根据本发明实施例的 Android应用程序包管理的容错方法的数据生成流程图，如图 8所示，该流程包括以下步骤：步骤 S802, 终端烧录完版本第一次开机或者是恢复出厂设置开机，在此场景下，数据（Data) 区为空。步骤 S804, 扫描 /system/framework,/system/app, /data/app, /data/app-private目录下的 APK文件，通过对 APK的 Android Manifest.xml 解析获取系统属性，每个 APK的包名，代码路径，标记，版本号等信息。步骤 S806, 通过解析出的信息，生成系统第一份 Package.xml文件。步骤 S808, 将第一份 Package.xml文件进行备份，拷贝到 data区下，重命名为 Package_init.xml，用于系统在出错情况下使用。步骤 S810, 在手机运行过程中，判断是否有 APK进行了升级，安装，卸载等操作，如果没有，该流程结束。如果有，进入 S812。步骤 S812，在 APK进行了升级，安装，卸载等操作时，需要对 Package.xml进行更新，在更新前，将原来 Data 分区中的 Package.xml 进行拷贝，重命名为 P ackage b ackUP. xml。步骤 S814，将新增的内容写入 Package—ADD.xml中，用以记录新增的 APK信息。步骤 S816, 数据生成过程结束。图 9是根据本发明实施例的 Android应用程序包管理的容错方法的数据使用的流程图。如图 9所示，该流程包括以下步骤：步骤 S902, 终端开机。步骤 S904, 系统读取 Package.xml, 加载应用安装信息，在此过程中，系统判定是否出现异常，如果正常，直接使用 Package.xml开机，无需使用容错机制。步骤 S906,当 Package.xml不能正常使用时，系统使用 Package_BackUP.xml开机。步骤 S908，系统判断是否能正常开机，如果正常，直接使用 Package—BackUP.xml 开机，如果非正常，进入 S910。步骤 S910，系统读取 Packagejnit.xml和 Package_ADD.xml，将两者进行 merge, 合并为新的 package.xml, 使用该配置进行开机。步骤 S912, 判断是否能正常开机。步骤 S914, 将 package.xml删除，让系统重新遍历所有的 APK程序，提取相关信息，重新生成 Package.xml开机，由于需要重新遍历所有的 APK，此时系统会有一段时间的处理过程。步骤 S916, 判断是否可以正常开机。步骤 S918, 如果还是不能正常开机，直接使用 Packagejnit.xml开机，此时会丢失所有的用户新增应用数据，但是在该极限条件下，可以保证手机处于可用状态，而无需到售后网点升级版本。步骤 S920, 开机流程结束。显然，本领域的技术人员应该明白，上述的本发明的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本发明不限制于任何特定的硬件和软件结合。以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。工业实用性如上所述，本发明实施例提供的一种系统应用安装包加载处理方法、装置及终端具有以下有益效果：解决了相关技术中存在的当系统应用安装包进行拷贝生成备份文件出错时，造成的系统应用安装包中的数据异常，导致终端无法开机的问题，进而达到了提高了系统稳定性和用户体验的效果。

Claims

权利要求书

1. 一种系统应用安装包加载处理方法，包括：在对系统应用安装包更新处理之前，将所述系统应用安装包重命名为系统应用安装备份包；

判断采用系统应用安装更新包是否加载成功，其中，所述系统应用安装更新包为对所述系统应用安装备份包进行拷贝后的拷贝版本进行更新后获取的系统应用安装包；

在判断结果为否的情况下，采用所述系统应用安装备份包进行加载处理。

2. 根据权利要求 1所述的方法，其中，在采用所述系统应用安装备份包进行加载处理之后，还包括：判断采用所述系统应用安装备份包加载是否成功；

在判断结果为否的情况下，获取系统设备出厂第一次加载时的系统应用安装初始包和对系统应用安装包每次更新时与所述系统应用安装初始包所存在的差异部分；

将所述系统应用安装初始包和所述差异部分合并为系统应用安装合并包；依据所述系统应用安装合并包进行加载处理。

3. 根据权利要求 2所述的方法，其中，获取系统设备出厂第一次加载时的所述系统应用安装初始包包括：

将系统设备出厂第一次加载时生成的系统应用安装初始包重命名为所述系统应用安装初始包。

4. 根据权利要求 2所述的方法，其中，在依据所述系统应用安装合并包进行加载处理之后，还包括：判断依据所述系统应用安装合并包加载是否成功；

在判断结果为否的情况下，通过扫描系统安装的应用生成系统应用安装扫描包；

依据所述系统应用安装扫描包进行加载处理。

5. 根据权利要求 4所述的方法，其中，在依据所述系统应用安装扫描包进行加载处理之后，还包括：判断依据系统应用安装扫描包加载是否成功；

在判断结果为否的情况下，采用系统设备出厂第一次加载时生成的系统应用安装初始包进行加载处理。

6. 一种系统应用安装包加载处理装置，包括：

重命名模块，设置为在对系统应用安装包更新处理之前，将所述系统应用安装包重命名为系统应用安装备份包；第一判断模块，设置为判断采用系统应用安装更新包是否加载成功，其中，所述系统应用安装更新包为对所述系统应用安装备份包进行拷贝后的拷贝版本进行更新后获取的系统应用安装包；

第一加载模块，设置为在所述第一判断模块的判断结果为否的情况下，采用所述系统应用安装备份包进行加载处理。

7. 根据权利要求 6所述的装置，其中，还包括：第二判断模块，设置为判断采用所述系统应用安装备份包加载是否成功；获取模块，设置为在所述第二判断模块的判断结果为否的情况下，获取系统设备出厂第一次加载时的系统应用安装初始包和对系统应用安装包每次更新时与所述系统应用安装初始包所存在的差异部分；

合并模块，设置为将所述系统应用安装初始包和所述差异部分合并为系统应用安装合并包；

第二加载模块，设置为依据所述系统应用安装合并包进行加载处理。

8. 根据权利要求 7所述的方法，其中，所述获取模块包括：重命名单元，设置为将系统设备出厂第一次加载时生成的系统应用安装初始包重命名为所述系统应用安装初始包。

9. 根据权利要求 7所述的装置，其中，还包括：第三判断模块，设置为判断依据所述系统应用安装合并包加载是否成功；生成模块，设置为在所述第三判断模块的判断结果为否的情况下，通过扫描系统安装的应用生成系统应用安装扫描包；第三加载模块，设置为依据所述系统应用安装扫描包进行加载处理。

10. 根据权利要求 9所述的装置，其中，还包括：第四判断模块，设置为判断依据系统应用安装扫描包加载是否成功；第四加载模块，设置为在判断结果为否的情况下，采用系统设备出厂第次加载时生成的系统应用安装初始包进行加载处理。

11. 一种终端，包括权利要求 6至 10中任一项所述的装置。