CN106020873B - 补丁包加载方法及装置 - Google Patents

Abstract

本发明公开了一种补丁包加载方法及装置，属于补丁包技术领域。所述方法包括：获取补丁包，补丁包中包括至少一个补丁类，补丁类用于替换原始应用程序中的待替换类，或，在原始应用程序中新增类；在原始应用程序的类加载路径之前插入补丁类的类加载路径；根据修改后的类加载路径所指示的加载顺序，对补丁类和所述原始应用程序进行类加载。本发明实施例解决了现有技术中利用补丁包进行漏洞修复时，需要对native进行修改，对于不同厂商生产的Android设备，将会引发兼容性问题，影响补丁成功率的问题；达到了在不对native进行修改的前提下，实现对原始应用程序中指定类的替换，从而避免了兼容性问题，提高了补丁成功率。

Description

补丁包加载方法及装置

技术领域

本发明实施例涉及补丁包技术领域，特别涉及一种补丁包加载方法及装置。

背景技术

随着智能设备的不断普及，各式各样的应用程序被广泛应用在智能设备中。当应用程序由于代码缺陷出现漏洞时，智能设备可以通过下载补丁包，并利用补丁包对漏洞进行修复。

以Android(安卓)设备为例，Android设备利用补丁包进行漏洞修复时，首先将待替换方法的类型修改为native(本地)，并将待替换方法的实现链接到Native Dispatch(本地调度)方法上。进一步的，Native Dispatch方法通过JNI(Java Native Interface，Java本地接口)回调Java端的处理方法，最终在该处理方法中调用before或after函数将待替换方法替换为补丁包中的方法。

在实现本发明实施例的过程中，发明人发现上述技术至少存在以下问题：

现有技术利用补丁包进行漏洞修复时，需要对native进行修改，对于不同厂商生产的Android设备，将会引发兼容性问题，影响补丁成功率。

发明内容

为了解决现有技术中利用补丁包进行漏洞修复时，需要对native进行修改，对于不同厂商生产的Android设备，将会引发兼容性问题，影响补丁成功率的问题，本发明实施例提供了一种补丁包加载方法及装置。所述技术方案如下：

根据本发明实施例的第一方面，提供一种补丁包加载方法，该方法包括：

获取补丁包，补丁包中包括至少一个补丁类，补丁类用于替换原始应用程序中的待替换类，或，在原始应用程序中新增类；

在原始应用程序的类加载路径之前插入补丁类的类加载路径；

根据修改后的类加载路径所指示的加载顺序，对补丁类和原始应用程序进行类加载。

根据本发明实施例的第二方面，提供一种补丁包加载装置，该装置包括：

第一获取模块，用于获取补丁包，补丁包中包括至少一个补丁类，补丁类用于替换原始应用程序中的待替换类，或，在原始应用程序中新增类；

第一插入模块，用于在原始应用程序的类加载路径之前插入补丁类的类加载路径；

第一加载模块，用于根据修改后的类加载路径所指示的加载顺序，对补丁类和原始应用程序进行类加载。

本发明实施例提供的技术方案带来的有益效果是：

通过获取补丁包中补丁类的类加载路径，并在原始应用程序的类加载路径之前插入该补丁类的类加载路径，使得在进行类加载时，优先对补丁类进行加载，从而实现对原始应用程序中待替换类的替换或在原始应用程序中新增类；解决了现有技术中利用补丁包进行漏洞修复时，需要对native进行修改，对于不同厂商生产的Android设备，将会引发兼容性问题，影响补丁成功率的问题；达到了在不对native进行修改的前提下，实现对原始应用程序中指定类的替换，从而避免了兼容性问题，提高了补丁成功率。

附图说明

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

图1示出了本发明一个实施例提供的补丁包加载方法的流程图；

图2A示出了本发明另一个实施例提供的补丁包加载方法的流程图；

图2B是图2A所示补丁包加载方法的实施示意图；

图2C是图2A所示补丁包加载方法所涉及的补丁资源加载过程的流程图；

图2D示出了本发明再一个实施例提供的补丁包加载方法的流程图；

图2E是图2D所示补丁包加载方法的实施示意图；

图3示出了本发明一个实施例提供的补丁包加载装置的结构方框图；

图4示出了本发明另一个实施例提供的补丁包加载装置的结构方框图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明实施方式作进一步地详细描述。

为了方便理解，下面对本发明实施例中出现的名词进行解释。

补丁包：用于修复应用程序中漏洞或错误的文件，通常情况下，补丁包的大小远小于应用程序APK(AndroidPackage，安卓安装包)的大小。现有的补丁包方案都是基于函数替换或函数hook(钩子)，通常用于对应用程序中的少量函数方法进行逻辑修改，并且在进行修改时，不允许对函数方法名、参数个数及顺序进行修改。

Dex(Dalvik VM executes，Dalvik执行)文件：Android平台上的可执行文件，文件后缀名为.dex。通常情况下，应用程序APK中包含一个Dex文件，该Dex文件中包含应用程序对应的所有类，且每个类中包含各自对应的函数方法，用于实现应用程序的各种功能。

Dexopt(Dex optimize，Dex优化)程序：用于在安装应用程序阶段，对应用程序APK中Dex文件包含的各个类进行校验优化，并生成Dex文件对应的Odex文件。应用程序运行过程中，Android虚拟机直接将该Odex文件载入内存并运行，从而提高应用程序启动速度。

本发明各个实施例提供的补丁包加载方法，用于Android设备中，该Android设备可以是安装有Android系统的智能手机、平板电脑、MP3播放器(Moving Picture ExpertsGroup Audio Layer III，动态影像专家压缩标准音频层面3)或MP4(Moving PictureExperts Group Audio Layer IV，动态影像专家压缩标准音频层面4)播放器等等。需要说明的是，该Android设备也可以是运行有Android虚拟机的个人计算机，本发明实施例并不对此进行限定。

为了方便描述，下述各个实施例以补丁包加载方法用于电子设备为例进行示意性说明。

现有的补丁包方案中，电子设备利用补丁包进行漏洞修复时，只能对应用程序中部分函数方法的逻辑进行修改(即方法级补丁)，无法实现大规模的函数方法甚至类替换。而本发明实施例提供的补丁包加载方法，在不对native进行修改的前提下，能够对应用程序中的类进行替换(即类级补丁)，避免了兼容性问题，实现大规模补丁。下面采用实施例进行示意性说明。

请参考图1，其示出了本发明一个实施例提供的补丁包加载方法的流程图，本实施例以该补丁包加载方法用于电子设备为例进行说明，该方法包括：

步骤101，获取补丁包，补丁包中包括至少一个补丁类，补丁类用于替换原始应用程序中的待替换类，或，在原始应用程序中新增类。

电子设备获取原始应用程序对应的补丁包，该补丁包可以是.apk格式的安装包文件。该补丁包中包含用于替换原始应用程序中待替换类的补丁类，和/或，新增到原始应用程序中的类。

比如，电子设备获取到的补丁包中包含类名为A的补丁类，若原始应用程序中包含类名为A的类，该补丁类即用于替换原始应用程序中类名为A的类；若原始应用程序中不包含类名为A的类，该补丁类即用于在原始应用程序中新增类名为A的类。

步骤102，在原始应用程序的类加载路径之前插入补丁类的类加载路径。

为了实现补丁类对原始应用程序中待替换类的替换(或在原始应用程序中新增类)，电子设备将补丁类的类加载路径插入原始应用程中各个类的类加载路径之前，使得进行类加载时，Android虚拟机能够优先对补丁类进行类加载。

步骤103，根据修改后的类加载路径所指示的加载顺序，对补丁类和原始应用程序进行类加载。

由于补丁类的类加载路径在原始应用程中各个类的类加载路径之前，电子设备中的Android虚拟机在进行类加载时，优先对补丁类进行加载，从而实现对待替换类的替换或在原始应用程序中新增类。

综上所述，本实施例提供的补丁包加载方法，通过获取补丁包中补丁类的类加载路径，并在原始应用程序的类加载路径之前插入该补丁类的类加载路径，使得在进行类加载时，优先对补丁类进行加载，从而实现对原始应用程序中待替换类的替换或在原始应用程序中新增类；解决了现有技术中利用补丁包进行漏洞修复时，需要对native进行修改，对于不同厂商生产的Android设备，将会引发兼容性问题，影响补丁成功率的问题；达到了在不对native进行修改的前提下，实现对原始应用程序中指定类的替换，从而避免了兼容性问题，提高了补丁成功率。

原始应用程序中的各个类包含在同一原始Dex文件中，相应的，补丁包中各个补丁类包含在同一补丁Dex文件中。为了实现对补丁类的优先加载，电子设备可以通过将补丁Dex文件的加载路径插入到原始Dex文件的加载路径之前来实现。下面采用一个实施例进行说明。

请参考图2A，其示出了本发明另一个实施例提供的补丁包加载方法的流程图，本实施例以该补丁包加载方法用于电子设备为例进行说明，该方法包括：

步骤201，获取补丁包，补丁包中包括至少一个补丁类，补丁类用于替换原始应用程序中的待替换类，或，在原始应用程序中新增类。

电子设备可以通过网络下载等方式获取原始应用程序对应的补丁包。该补丁包中包含至少一个补丁类，至少一个补丁类用于对原始应用程序中的某个特定类进行替换，或在原始应用程序中新增一个类。

其中，当该补丁类用于替换原始应用程序中的待替换类(该待替换类中的某一函数方法存在漏洞或错误)时，该补丁类的类名与该待替换类的类名相同，比如，当原始应用程序中类名为A的待替换类中某一函数方法存在错误时，用于替换该待替换类的补丁类的类名也为A。

当该补丁类用于指示在原始应用程序中新增一个类时，该补丁类的类名与原始应用程序中各个类的类名均不相同。比如，原始应用程序中包含4个类，4个类的类名分别为A、B、C和D。当需要通过补丁包向原始应用程序中新增一个类时，该补丁包中的补丁类需要采用除A、B、C和D以外的类名。

下述实施例中，以该补丁类用于替换原始应用程序中待替换类为例进行说明，并不对本发明构成限定。

步骤202，获取补丁类对应的Dex文件。

电子设备获取的补丁包采用APK格式，该补丁包中包含一个Dex文件，该Dex文件中即包含各个补丁类，相应的，电子设备中的Android虚拟机即通过该Dex文件加载补丁类。

电子设备获取到补丁包后，即获取补丁类对应的Dex文件。

步骤203，获取原始应用程序对应的Dex数组，Dex数组包括原始应用程序对应Dex文件中各个类的类加载路径。

原始应用程序也对应一个Dex文件，该Dex文件中包含原始应用程序中各个类，相应的，电子设备中的Android虚拟机即通过该Dex文件加载并运行原始应用程序中的各个类，从而实现原始应用程序的各个功能。而原始应用程序中各个类的类加载路径则采用Dex数组的形式进行存储(比如，Dex[5]表示该Dex数组中存储有原始应用程序中5个类的类加载路径)，方便Android虚拟机根据该Dex数组进行类加载。

电子设备获取到补丁包后，进一步获取原始应用程序对应的Dex数组，并对Dex数组和补丁类的类加载路径进行相应处理，实现补丁类对待替换类的替换。

步骤204，将补丁类对应的Dex文件的加载路径插入Dex数组之前。

Android framework进行类加载时，按照DexClassLoader中Dex数组的顺序依次进行查找，当查找到与待加载类同名的类时，即根据查找到的类对应的类加载路径(从Dex数组中获取)进行类加载。

利用这一类加载机制，电子设备获取到补丁类对应的Dex文件以及原始应用程序对应的Dex数组后，即将补丁类对应的Dex文件的加载路径插入Dex数组之前。

如图2B所示，电子设备获取到的补丁包中包含补丁Dex文件patch.dex，该补丁Dex文件中包含补丁类B_patch(用于替换原始应用程序中的B类，且补丁类B_patch与B类同名)，且原始应用程序对应的原始Dex文件为apk.dex，该原始Dex文件中包含A类、B类、C类和D类，且原始应用程序对应的Dex数组中包含A类、B类、C类和D类的类加载路径。为了将原始应用程序中的B类替换为补丁类B_patch，Android虚拟机将补丁类B_patch的加载路径插入原始应用程序对应的Dex数组之前，使得进行类加载时，Android虚拟机优先在补丁类B_patch中进行查找。

步骤205，进行类加载时，检测待加载类的类名与补丁类的类名是否相同。

Android虚拟机进行类加载时，即根据修改后的类加载路径所指示的加载顺序(B_patch-A-B-C-D)，优先检测待加载类的类名与补丁类的类名是否相同。

步骤206，若待加载类的类名与补丁类的类名相同，则对补丁类进行类加载。

当检测到待加载类的类名与补丁类的类名相同时，即对(补丁包对应的)Dex文件中包含的补丁类进行加载。

比如，结合图2B，当Android虚拟机需要对B类进行加载时，由于补丁包中补丁类B_patch与原始应用程序中B类同名，且补丁类B_patch的类加载路径在原始应用程序的类加载路径之前，因此，Android虚拟机对patch.dex中的补丁类B_patch进行类加载，而不对apk.dex中的B类进行加载，从而实现对原始应用程序中B类的替换。

步骤207，若待加载类的类名与补丁类的类名不同，则根据待加载类的类名在原始应用程序中查找匹配的类并进行类加载。

当检测到待加载类的类名与补丁类的类名不同时，Android虚拟机即根据原始应用程序对应Dex数组的顺序，在原始应用程序中查找匹配的类，并对查找到的类进行类加载。

比如，结合图2B，当Android虚拟机需要对类名为C的类进行加载时，由于补丁包中补丁类B_patch与C类不同名，因此，Android虚拟机根据待加载类的类名(即C)，在apk.dex中查找匹配的类。由于apk.dex中的C类与待加载类同名，因此，Android虚拟机从Dex数组中获取C类对应的类加载地址，并根据该类加载地址进行类加载。

综上所述，本实施例提供的补丁包加载方法，通过获取补丁包中补丁类的类加载路径，并在原始应用程序的类加载路径之前插入该补丁类的类加载路径，使得在进行类加载时，优先对补丁类进行加载，从而实现对原始应用程序中待替换类的替换或在原始应用程序中新增类；解决了现有技术中利用补丁包进行漏洞修复时，需要对native进行修改，对于不同厂商生产的Android设备，将会引发兼容性问题，影响补丁成功率的问题；达到了在不对native进行修改的前提下，实现对原始应用程序中指定类的替换，从而避免了兼容性问题，提高了补丁成功率。

本实施例中，当需要使用补丁类替换原始应用程序中的待替换类时，通过将补丁类的类加载路径插入原始应用程序的类加载路径之前，使得Android虚拟机进行类加载时，仅对补丁类进行加载，而不需要对原始应用程序中的待替换类进行加载，从而实现对原始应用程序中整个类的替换，相较于现有的方法级补丁，本实施例能够实现更大规模的补丁。

现有的补丁包方案中，补丁包只能用于进行方法级的补丁，且无法对应用程序中的资源进行增加或替换(比如替换原始应用程序中的某一图片)。而本发明实施例提供的补丁包加载方法则可以解决这一问题。在图2A的基础上，如图2C所示，上述步骤201之后，还可以包括如下步骤。

步骤208，获取补丁资源对应的资源加载路径。

电子设备获取到补丁包后，获取该补丁包中补丁资源的资源加载地址，该补丁资源即需要增加或进行替换资源。

步骤209，在原始应用程序的资源加载路径之前插入补丁资源的资源加载路径。

在一种可能的实施方式中，Android虚拟机通过AssetManager下的addAssetPath方法，将补丁资源对应的资源加载路径插入到原始应用程序的资源加载路径之前，使得在进行资源加载时，Android虚拟机优先对补丁资源进行加载。

需要说明的是，对于不同版本的Android系统，在原始应用程序的资源加载路径之前插入补丁资源的资源加载路径的方式不同。比如，在4.0-4.4版本的Android系统下，Android虚拟机通过AssetManager下的addAssetPath方法，将补丁包路径插在原始应用程序对应主包路径之后；在5.0以上版本的Android系统下，Android虚拟机通过AssetManager下的addAssetPath方法，将补丁包路径插在原始应用程序对应主包路径之前。

步骤210，根据修改后的资源加载路径所指示的加载顺序，对补丁资源和原始应用程序进行资源加载。

与类加载相似的，Android虚拟机根据修改后的资源加载路径所指示的加载顺序(先补丁资源，后原始应用程序对应的资源)，进行资源加载，从而实现在原始应用程序中增加资源，或，替换原始应用程序中的资源。

本实施例中，通过在原始应用程序的资源加载路径之前插入补丁资源的资源加载路径，使得Android虚拟机进行资源加载时，优先对补丁包中的补丁资源进行加载，从而实现向原始应用程序中增加资源或替换原始应用程序中的资源。

当电子设备中的Android虚拟机为Dalvik虚拟机时，Dalvik虚拟机安装应用程序时，会触发Dexopt程序对应用程序中各个类进行校验优化，当应用程序中的类与自身引用的类属于同于Dex文件时，Dexopt程序即使用预定标识对该类进行标记。

比如，应用程序对应的Dex文件中包含A类、B类、C类和D类，且A类引用了B类中的函数方法，B类引用了C类中的函数方法，C类引用了D类中的函数方法时，由于该Dex文件中各个类及其引用的类均属于同一Dex文件，Dexopt程序即使用CLASS_ISPREVERIFIED分别对A类、B类、C类和D类进行标记。

Dalvik虚拟机运行加载应用程序时，Dalvik虚拟机会对携带有预定标识的类进行检测，检测该类与其引用的类是否仍旧属于同一Dex文件(比如，检测A类及其引用的B类是否仍在同一Dex文件)，当该类与其引用的类仍旧属于同一Dex文件时，Dalvik虚拟机正常运行应用程序；当该类与其引用的类不属于同一Dex文件时，Dalvik虚拟机则认为存在非法操作，抛出异常，并停止运行应用程序。

结合图2B，原始应用程序对应的apk.dex中，包含A类、B类、C类和D类，且A类引用了B类中的函数方法。Dalvik虚拟机在安装原始应用程序时，由于A类和B类属于同一Dex文件，Dexopt程序对A类、B类、C类和D类均进行了标记，且Dalvik虚拟机运行原始应用程序时，由于加载的A类、B类、C类和D类均未发生变化，Dalvik虚拟机不会抛出异常，并正常运行应用程序。

当原始应用程序中的B类存在错误并需要使用补丁类B_patch进行替换时，A类引用的类由B类变为了补丁类B_patch，且补丁类B_patch与A类不在同一Dex文件中(A类在apk.dex中，B_patch在patch.dex中)，Dalvik虚拟机认为存在非法操作，抛出异常，并停止运行应用程序。为了避免这一问题的发生，在图2A的基础上，如图2D所示，步骤201之前，还包括如下步骤。

步骤211，添加预设引用类，原始应用程序中各个类均引用预设引用类，且预设引用类与原始应用程序中各个类不属于同一Dex文件。

在编译期，Dalvik虚拟机添加一个Dex文件，该Dex文件中包含预设引用类，而原始应用程序中各个类均引用该预设引用类。

比如，如图2E所示，Dalvik虚拟机添加一个名为hack.dex的Dex文件，该hack.dex中包含预设引用类Demo，且原始应用程序中各个类(A类、B类、C类和D类)均引用该Demo类。

需要说明的是，该预设引用类中可以不包含任何函数方法，即原始应用程序中的各个类只需要访问该预设引用类即可。

步骤212，安装原始应用程序时，通过Dexopt程序对原始应用程序中各个类进行校验优化。

Dalvik虚拟机安装原始应用程序时，触发Dexopt程序对原始应用程序中各个类进行校验优化，校验原始应用程序中各个类与其引用的类是否属于同一Dex文件。

步骤213，若原始应用程序中的类通过校验优化，则使用预定标识对通过校验优化的类进行标记。

由于原始应用程序中各个类均引用了预设引用类，且该预设引用类与原始应用程序中各个类不属于同一Dex文件，因此，Dexopt程序不再为原始应用程序中各个类分配预定标识。

比如，结合图2E，由于apk.dex中的A类、B类、C类和D类均引用了Demo类，且A类、B类、C类和D类属于apk.dex，Demo类属于hack.dex，因此，Dexopt程序无法使用预定标识对apk.dex中的各个类进行标记。

经过上述步骤211至步骤213，原始应用程序完成了安装。进一步的，当需要对原始应用程序中某一类进行替换时，电子设备获取补丁包，并通过上述步骤201至步骤207，对补丁包中的补丁类进行类加载。

比如，如图2E所示，当需要对原始应用程序中的B类进行替换时，虚拟机将补丁类B_patch插到原始应用程序对应apk.dex之前，使得进行类加载时，优先加载B_patch，实现对原始应用程序中B类的替换。

步骤214，完成类加载后，检测包含预定标识的类与自身所引用的类是否属于同一Dex文件。

完成类加载后，Dalvik虚拟机检测包含预定标识的类与自身所引用的类是否属于同一Dex文件。

由于添加了预设引用类，使得原始应用程序中各个引用类均引用了与其不在同一Dex文件中的类，因此在安装阶段，原始应用程序中各个类均未分配到预定标识。

步骤215，若包含预定标识的类与自身所引用的类不属于同一Dex文件，则抛出异常。

相应的，由于原始应用程序中各个类均未分配到预定标识，Dalvik虚拟机也无需再对包含预定标识的类进行检测，避免了因引用非本Dex的类而引起的异常，保证了应用程序的正常运行。

需要说明的是，当Android虚拟机为Dalvik虚拟机时，Dalvik虚拟机中存在通过Dexopt程序进行校验的过程，即需要执行上述步骤211至步骤215；但是当Android虚拟机为ART(Android runtime，安卓运行时间)虚拟机时，由于ART虚拟机采用编译运行机制，因此不存在上述校验过程，即当本发明实施例提供的补丁包加载方法用于运行ART虚拟机的电子设备时，无需执行上述步骤211至步骤215。

本实施例中，通过在原始应用程序中添加预设引用类，从而绕过Dexopt程序的标记过程，避免了因引用非本Dex的类而引起的异常，保证了应用程序的正常运行。

生成补丁包时，开发人员在原始应用程序的基础上，对原始应用程序进行修复后得到更新后应用程序，并通过分析更新后应用程序与原始应用程序之间的差异，从而生成补丁包，该补丁包中包括所述补丁类对应的Dex文件、补丁资源和补丁ARSC(AndroidResource，安卓资源)文件中的至少一种。

在一种可能的实施方式中，开发人员通过分析程序对原始应用程序和更新后应用程序进行分析，从而确定原始应用程序和更新后应用程序之间的差异类，该差异类包括函数方法发生变化的类和类名发生变化的类。比如，当原始应用程序中包含A类、B类和C类，而更新后应用程序中包含A’类、B类和D类时，即确定差异类为A’类和D类。需要说明的是，当类中增加或减少函数时，需要将其子类、子类的匿名内部类、调用新增函数及其子类的函数作为差异类一同打包到补丁包中。

对于获取补丁资源的方式，可以通过分析原始应用程序和更新后应用程序各自资源目录(未混淆的目录或混淆后的目录，比如，/res或/r)下资源文件的差异，并对分析出的差异资源进行保存。

对于生成补丁ARSC文件的方式，可以通过分析原始应用程序和更新后应用程序各自对应的ARSC文件格式，将其新增和修改部分重新组织成一个新的ARSC文件，作为补丁包的补丁ARSC文件。

最后，将补丁类对应的Dex文件、补丁资源和补丁ARSC文件整合打包，生成补丁包。

下述为本发明装置实施例，对于装置实施例中未详尽描述的细节，可以参考上述一一对应的方法实施例。

请参考图3，其示出了本发明一个实施例提供的补丁包加载装置的结构方框图。该补丁包加载装置通过硬件或者软硬件的结合实现成为Android设备的全部或者一部分。该补丁包加载装置包括：

第一获取模块301，用于获取补丁包，所述补丁包中包括至少一个补丁类，所述补丁类用于替换原始应用程序中的待替换类，或，在所述原始应用程序中新增类；

第一插入模块302，用于在所述原始应用程序的类加载路径之前插入所述补丁类的类加载路径；

第一加载模块303，用于根据修改后的类加载路径所指示的加载顺序，对所述补丁类和所述原始应用程序进行类加载。

综上所述，本实施例提供的补丁包加载装置，通过获取补丁包中补丁类的类加载路径，并在原始应用程序的类加载路径之前插入该补丁类的类加载路径，使得在进行类加载时，优先对补丁类进行加载，从而实现对原始应用程序中待替换类的替换或在原始应用程序中新增类；解决了现有技术中利用补丁包进行漏洞修复时，需要对native进行修改，对于不同厂商生产的Android设备，将会引发兼容性问题，影响补丁成功率的问题；达到了在不对native进行修改的前提下，实现对原始应用程序中指定类的替换，从而避免了兼容性问题，提高了补丁成功率。

请参考图4，其示出了本发明另一个实施例提供的补丁包加载装置的结构方框图。该补丁包加载装置通过硬件或者软硬件的结合实现成为Android设备的全部或者一部分。该补丁包加载装置包括：

第一获取模块401，用于获取补丁包，所述补丁包中包括至少一个补丁类，所述补丁类用于替换原始应用程序中的待替换类，或，在所述原始应用程序中新增类；

第一插入模块402，用于在所述原始应用程序的类加载路径之前插入所述补丁类的类加载路径；

第一加载模块403，用于根据修改后的类加载路径所指示的加载顺序，对所述补丁类和所述原始应用程序进行类加载。

可选地，所述第一插入模块402，包括：

第一获取单元402a，用于获取所述补丁类对应的Dex文件；

第二获取单元402b，用于获取所述原始应用程序对应的Dex数组，所述Dex数组包括所述原始应用程序对应Dex文件中各个类的类加载路径；

插入单元402c，用于将所述补丁类对应的Dex文件的加载路径插入所述Dex数组之前。

可选地，所述第一加载模块403，包括：

检测单元403a，用于检测待加载类的类名与所述补丁类的类名是否相同；

第一加载单元403b，用于若所述待加载类的类名与所述补丁类的类名相同，则对所述补丁类进行类加载；

第二加载单元403c，用于若所述待加载类的类名与所述补丁类的类名不同，则根据所述待加载类的类名在所述原始应用程序中查找匹配的类并进行类加载。

可选地，所述装置，包括：

校验模块404，用于安装所述原始应用程序时，通过Dexopt程序对所述原始应用程序中各个类进行校验优化；

标记模块405，用于若所述原始应用程序中的类通过校验优化，则使用预定标识对通过校验优化的类进行标记；

其中，所述通过校验优化的类与自身所引用的类属于同一Dex文件。

可选地，当所述原始应用程序中各个类之间存在引用关系时，

所述装置，包括：

添加模块406，用于添加预设引用类，所述原始应用程序中各个类均引用所述预设引用类，且所述预设引用类与所述原始应用程序中各个类不属于同一Dex文件；

所述校验模块404，还用于通过所述Dexopt程序对所述预设引用类以及所述原始应用程序中各个类进行校验优化。

可选地，所述装置，还包括：

检测模块407，用于完成类加载后，检测包含所述预定标识的类与自身所引用的类是否属于同一Dex文件；

异常抛出模块408，用于若包含所述预定标识的类与自身所引用的类不属于同一Dex文件，则抛出异常。

可选地，所述补丁包中包括补丁资源，所述装置，还包括：

第二获取模块409，用于获取所述补丁资源对应的资源加载路径；

第二插入模块410，用于在所述原始应用程序的资源加载路径之前插入所述补丁资源的资源加载路径；

第二加载模块411，用于根据修改后的资源加载路径所指示的加载顺序，对所述补丁资源和所述原始应用程序进行资源加载。

可选地，所述补丁包中包括所述补丁类对应的Dalvik执行Dex文件、补丁资源和补丁ARSC文件中的至少一种；

其中，所述补丁类通过分析所述原始应用程序和更新后应用程序之间的差异类生成；所述补丁资源通过分析所述原始应用程序和所述更新后应用程序各自对应的资源目录生成；所述补丁ARSC文件通过分析所述原始应用程序和所述更新后应用程序各自对应的ARSC文件生成。

综上所述，本实施例提供的补丁包加载装置，通过获取补丁包中补丁类的类加载路径，并在原始应用程序的类加载路径之前插入该补丁类的类加载路径，使得在进行类加载时，优先对补丁类进行加载，从而实现对原始应用程序中待替换类的替换或在原始应用程序中新增类；解决了现有技术中利用补丁包进行漏洞修复时，需要对native进行修改，对于不同厂商生产的Android设备，将会引发兼容性问题，影响补丁成功率的问题；达到了在不对native进行修改的前提下，实现对原始应用程序中指定类的替换，从而避免了兼容性问题，提高了补丁成功率。

本实施例中，当需要使用补丁类替换原始应用程序中的待替换类时，通过将补丁类的类加载路径插入原始应用程序的类加载路径之前，使得Android虚拟机进行类加载时，仅对补丁类进行加载，而不需要对原始应用程序中的待替换类进行加载，从而实现对原始应用程序中整个类的替换，相较于现有的方法级补丁，本实施例能够实现更大规模的补丁。

本实施例中，通过在原始应用程序的资源加载路径之前插入补丁资源的资源加载路径，使得Android虚拟机进行资源加载时，优先对补丁包中的补丁资源进行加载，从而实现向原始应用程序中增加资源或替换原始应用程序中的资源。

本实施例中，通过在原始应用程序中添加预设引用类，从而绕过Dexopt程序的标记过程，避免了因引用非本Dex的类而引起的异常，保证了应用程序的正常运行。

需要说明的是：上述实施例提供的补丁包加载装置，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将Android设备的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。另外，上述实施例提供的补丁包加载装置与补丁包加载方法实施例属于同一构思，其具体实现过程详见方法实施例，这里不再赘述。

应当理解的是，在本文中使用的，除非上下文清楚地支持例外情况，单数形式“一个”(“a”、“an”、“the”)旨在也包括复数形式。还应当理解的是，在本文中使用的“和/或”是指包括一个或者一个以上相关联地列出的项目的任意和所有可能组合。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。

以上所述仅为本发明的较佳实施例，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (9)

1.一种补丁包加载方法，其特征在于，所述方法包括：

分析原始应用程序和更新后应用程序各自资源目录下的资源文件的差异，得到差异资源；

当所述原始应用程序中各个类之间存在引用关系时，添加预设引用类，所述原始应用程序中各个类均引用所述预设引用类，且所述预设引用类与所述原始应用程序中各个类不属于同一Dex文件；

安装所述原始应用程序时，通过Dexopt程序对所述预设引用类以及所述原始应用程序中各个类进行校验优化；

若所述原始应用程序中的类通过校验优化，则使用预定标识对通过校验优化的类进行标记；其中，所述通过校验优化的类与自身所引用的类属于同一Dex文件；

根据所述差异资源获取补丁包，所述补丁包中包括至少一个补丁类，所述补丁类用于替换所述原始应用程序中的待替换类，或，在所述原始应用程序中新增类，所述补丁包是根据所述原始应用程序和所述更新后应用程序之间的差异类生成的，所述差异类包括函数方法发生变化的类，当所述差异类中增加或减少函数时，所述补丁包中包括子类、所述子类的匿名内部类、调用新增函数以及所述子类的函数中的至少一种，所述补丁包中包括补丁资源；

获取所述补丁资源对应的资源加载路径；

通过AssetManager下的addAssetPath方法，在所述原始应用程序的资源加载路径之前插入所述补丁资源的资源加载路径，其中，对于不同版本的Android系统，在原始应用程序的资源加载路径之前插入补丁资源的资源加载路径的方式不同；

根据修改后的资源加载路径所指示的加载顺序，对所述补丁资源和所述原始应用程序进行资源加载；

在所述原始应用程序的类加载路径之前插入所述补丁类的类加载路径，其中包括：获取所述补丁类对应的Dalvik执行Dex文件；获取所述原始应用程序对应的Dex数组，所述Dex数组包括所述原始应用程序对应Dex文件中各个类的类加载路径；将所述补丁类对应的Dex文件的加载路径插入所述Dex数组之前；并且，响应于所述补丁类为新增的类，确定所述补丁类的类名与所述原始应用程序中各个类的类名均不相同；响应于所述补丁类为替换的类，确定所述补丁类的类名与所述原始应用程序中待替换类的类名相同；

根据修改后的类加载路径所指示的加载顺序以及所述补丁类的类名，对所述补丁类和所述原始应用程序进行类加载。

2.根据权利要求1所述的方法，其特征在于，所述根据修改后的类加载路径所指示的加载顺序以及所述补丁类的类名，对所述补丁类和所述原始应用程序进行类加载，包括：

检测待加载类的类名与所述补丁类的类名是否相同；

若所述待加载类的类名与所述补丁类的类名相同，则对所述补丁类进行类加载；

若所述待加载类的类名与所述补丁类的类名不同，则根据所述待加载类的类名在所述原始应用程序中查找匹配的类并进行类加载。

3.根据权利要求1所述的方法，其特征在于，所述根据修改后的类加载路径所指示的加载顺序以及所述补丁类的类名，对所述补丁类和所述原始应用程序进行类加载之后，还包括：

完成类加载后，检测包含所述预定标识的类与自身所引用的类是否属于同一Dex文件；

若包含所述预定标识的类与自身所引用的类不属于同一Dex文件，则抛出异常。

4.根据权利要求1至3任一所述的方法，其特征在于，所述补丁包中包括所述补丁类对应的Dalvik执行Dex文件、补丁资源和补丁安卓资源ARSC文件中的至少一种；

其中，所述补丁类通过分析所述原始应用程序和更新后应用程序之间的差异类生成；所述补丁资源通过分析所述原始应用程序和所述更新后应用程序各自对应的资源目录生成；所述补丁ARSC文件通过分析所述原始应用程序和所述更新后应用程序各自对应的ARSC文件生成。

5.一种补丁包加载装置，其特征在于，所述装置包括：

第一获取模块，用于分析原始应用程序和更新后应用程序各自资源目录下的资源文件的差异，得到差异资源；根据所述差异资源获取补丁包，所述补丁包中包括至少一个补丁类，所述补丁类用于替换原始应用程序中的待替换类，或，在所述原始应用程序中新增类，所述补丁包是根据所述原始应用程序和所述更新后应用程序之间的差异类生成的，所述差异类包括函数方法发生变化的类，当所述差异类中增加或减少函数时，所述补丁包中包括子类、所述子类的匿名内部类、调用新增函数以及所述子类的函数中的至少一种，所述补丁包中包括补丁资源；获取所述补丁资源对应的资源加载路径；通过AssetManager下的addAssetPath方法，在所述原始应用程序的资源加载路径之前插入所述补丁资源的资源加载路径，其中，对于不同版本的Android系统，在原始应用程序的资源加载路径之前插入补丁资源的资源加载路径的方式不同；

第一插入模块，用于在所述原始应用程序的类加载路径之前插入所述补丁类的类加载路径，其中，响应于所述补丁类为新增的类，确定所述补丁类的类名与所述原始应用程序中各个类的类名均不相同；响应于所述补丁类为替换的类，确定所述补丁类的类名与所述原始应用程序中待替换类的类名相同；

第一加载模块，用于根据修改后的类加载路径所指示的加载顺序以及所述补丁类的类名，对所述补丁类和所述原始应用程序进行类加载；

所述第一插入模块，包括：

第一获取单元，用于获取所述补丁类对应的Dalvik执行Dex文件；

第二获取单元，用于获取所述原始应用程序对应的Dex数组，所述Dex数组包括所述原始应用程序对应Dex文件中各个类的类加载路径；

插入单元，用于将所述补丁类对应的Dex文件的加载路径插入所述Dex数组之前；

所述装置，还包括：

校验模块，用于安装所述原始应用程序时，通过Dex优化Dexopt程序对所述原始应用程序中各个类进行校验优化；

标记模块，用于若所述原始应用程序中的类通过校验优化，则使用预定标识对通过校验优化的类进行标记；

其中，所述通过校验优化的类与自身所引用的类属于同一Dex文件；

当所述原始应用程序中各个类之间存在引用关系时，所述装置，还包括：

添加模块，用于添加预设引用类，所述原始应用程序中各个类均引用所述预设引用类，且所述预设引用类与所述原始应用程序中各个类不属于同一Dex文件；

所述校验模块，还用于通过所述Dexopt程序对所述预设引用类以及所述原始应用程序中各个类进行校验优化。

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

检测单元，用于检测待加载类的类名与所述补丁类的类名是否相同；

第一加载单元，用于若所述待加载类的类名与所述补丁类的类名相同，则对所述补丁类进行类加载；

第二加载单元，用于若所述待加载类的类名与所述补丁类的类名不同，则根据所述待加载类的类名在所述原始应用程序中查找匹配的类并进行类加载。

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

检测模块，用于运行所述原始应用程序时，检测包含所述预定标识的类与自身所引用的类是否属于同一Dex文件；

异常抛出模块，用于若包含所述预定标识的类与自身所引用的类不属于同一Dex文件，则抛出异常。

8.根据权利要求5至7任一所述的装置，其特征在于，所述补丁包中包括所述补丁类对应的Dalvik执行Dex文件、补丁资源和补丁安卓资源ARSC文件中的至少一种；

其中，所述补丁类通过分析所述原始应用程序和更新后应用程序之间的差异类生成；所述补丁资源通过分析所述原始应用程序和所述更新后应用程序各自对应的资源目录生成；所述补丁ARSC文件通过分析所述原始应用程序和所述更新后应用程序各自对应的ARSC文件生成。

9.一种计算机可读存储介质，其特征在于，所述可读存储介质中存储有至少一条指令、至少一段程序、代码集或指令集，所述至少一条指令、至少一段程序、代码集或指令集由处理器加载并执行以实现如权利要求1至4任一项 所述的补丁包加载方法。

Images