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

Abstract

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

Description

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

技术领域

本发明涉及通信领域，具体而言，涉及一种系统应用安装包加载处理方法、装置及终端。

背景技术

随着安卓Android智能机的普及，与之配套的上层应用（application，简称为APP）开发也发展迅猛，网络上随时会提供海量的免费安卓安装包（Android Package，简称为APK）进行下载和安装使用。在此背景下，用户在Android智能手机终端上安装和卸载APK已经成为智能手机使用中的一个重要场景。Android系统中的应用程序包管理服务模块，就是专门针对该场景的功能模块，包管理服务（PACKAGER MANAGER SERVICE）是在系统启动阶段由系统服务（SYSTEM SERVER）启动的一个JAVA层服务，用来管理/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.启动AppDirObserver线程监测/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（userId），调试标记（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进行备份，重命名为Package_Init.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应用程序包管理的容错方案，直接使用Package_Init.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进行拷贝，重命名为Package_backUP.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，系统读取Package_init.xml和Package_ADD.xml，将两者进行merge，合并为新的package.xml，使用该配置进行开机。

步骤S912，判断是否能正常开机。

步骤S914，将package.xml删除，让系统重新遍历所有的APK程序，提取相关信息，重新生成Package.xml开机，由于需要重新遍历所有的APK，此时系统会有一段时间的处理过程。

步骤S916，判断是否可以正常开机。

步骤S918，如果还是不能正常开机，直接使用Package_init.xml开机，此时会丢失所有的用户新增应用数据，但是在该极限条件下，可以保证手机处于可用状态，而无需到售后网点升级版本。

步骤S920，开机流程结束。

显然，本领域的技术人员应该明白，上述的本发明的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本发明不限制于任何特定的硬件和软件结合。

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (9)

1.一种系统的package.xml文件加载处理方法，其特征在于，包括：

在对系统的package.xml文件更新处理之前，将所述系统的package.xml文件重命名为Package_BackUP.xml文件；

判断采用更新后的package.xml文件是否加载成功，其中，所述更新后的package.xml文件为对所述Package_BackUP.xml文件进行拷贝后的拷贝版本进行更新后获取的package.xml文件；

在判断结果为否的情况下，采用所述Package_BackUP.xml文件进行加载处理；

其中，在采用所述Package_BackUP.xml文件进行加载处理之后，所述方法还包括：判断采用所述Package_BackUP.xml文件加载是否成功；在判断结果为否的情况下，获取系统设备出厂第一次加载时的Package_Init.xml文件和对所述系统的package.xml文件每次更新时与所述Package_Init.xml文件所存在的差异部分；将所述Package_Init.xml文件和所述差异部分合并为合并后的新Package.xml文件；依据所述合并后的新Package.xml文件进行加载处理。

2.根据权利要求1所述的方法，其特征在于，获取系统设备出厂第一次加载时的所述Package_Init.xml文件包括：

将系统设备出厂第一次加载时生成的Package.xml文件重命名为所述Package_Init.xml文件。

3.根据权利要求1所述的方法，其特征在于，在依据所述合并后的新Package.xml文件进行加载处理之后，还包括：

判断依据所述合并后的新Package.xml文件加载是否成功；

在判断结果为否的情况下，通过扫描系统安装的应用生成扫描后的新Package.xml文件；

依据所述扫描后的新Package.xml文件进行加载处理。

4.根据权利要求3所述的方法，其特征在于，在依据所述扫描后的新Package.xml文件进行加载处理之后，还包括：

判断依据所述扫描后的新Package.xml文件加载是否成功；

在判断结果为否的情况下，采用系统设备出厂第一次加载时生成的Package.xml文件进行加载处理。

5.一种系统的package.xml文件加载处理装置，其特征在于，包括：

重命名模块，用于在对系统的package.xml文件更新处理之前，将所述系统的package.xml文件重命名为Package_BackUP.xml文件；

第一判断模块，用于判断采用更新后的package.xml文件是否加载成功，其中，所述更新后的package.xml文件为对所述Package_BackUP.xml文件进行拷贝后的拷贝版本进行更新后获取的package.xml文件；

第一加载模块，用于在所述第一判断模块的判断结果为否的情况下，采用所述Package_BackUP.xml文件进行加载处理；

第二判断模块，用于判断采用所述Package_BackUP.xml文件加载是否成功；

获取模块，用于在所述第二判断模块的判断结果为否的情况下，获取系统设备出厂第一次加载时的Package_Init.xml文件和对所述系统的package.xml文件每次更新时与所述Package_Init.xml文件所存在的差异部分；

合并模块，用于将所述Package_Init.xml文件和所述差异部分合并为合并后的新Package.xml文件；

第二加载模块，用于依据所述合并后的新Package.xml文件进行加载处理。

6.根据权利要求5所述的装置，其特征在于，所述获取模块包括：

重命名单元，用于将系统设备出厂第一次加载时生成的Package.xml文件重命名为所述Package_Init.xml文件。

7.根据权利要求5所述的装置，其特征在于，还包括：

第三判断模块，用于判断依据所述合并后的新Package.xml文件加载是否成功；

生成模块，用于在所述第三判断模块的判断结果为否的情况下，通过扫描系统安装的应用生成扫描后的新Package.xml文件；

第三加载模块，用于依据所述扫描后的新Package.xml文件进行加载处理。

8.根据权利要求7所述的装置，其特征在于，还包括：

第四判断模块，用于判断依据扫描后的新Package.xml文件加载是否成功；

第四加载模块，用于在判断结果为否的情况下，采用系统设备出厂第一次加载时生成的Package.xml文件进行加载处理。

9.一种终端，其特征在于，包括权利要求5至8中任一项所述的装置。