HK1247691B - Application program updating method, device and equipment - Google Patents

Description

Application program upgrade method, device and equipment

Technical Field

This specification relates to the field of software upgrade technology, and in particular to application program upgrade methods, devices, and equipment.

Background Art

With the development of mobile communication technology, in order to meet user needs or improve the functions of software products, it is necessary to upgrade the applications (Application, APP) installed in the terminal so that the upgraded application has better performance than the old version and obtains an optimized effect.

In the Android system, when a new version of the program installation package is detected, if the user confirms to upgrade, the new version of the program installation package can be used to overwrite the installation. Therefore, it is particularly important to provide a solution for upgrading applications without overwriting.

Summary of the Invention

To overcome the problems existing in the related art, this specification provides an application program upgrade method, apparatus, and device.

An application program upgrade method, the method being applied to a target application program, the method comprising:

When the target application is started, if a new version of the target application is installed, obtaining an upgrade file required for the upgrade based on the new version of the target application;

Creating a directory for the upgrade file in a writable storage area, and storing the upgrade file in the created directory;

Build a new loader to replace the old one;

The upgrade file is loaded from the directory using the newly constructed loader.

Optionally, the upgrade file includes an executable file and a resource file, and the upgrade file required for the upgrade obtained based on the new version program installation package includes:

Extracting an executable file from the new version program installation package;

The new version program installation package is used as a resource file.

Optionally, the executable file includes an executable code file and a dynamic link library, and the executable code file, dynamic link library, and resource file are stored in different directories respectively.

Optionally, the constructed loader inherits from DexClassLoader, and the construction of a new loader to replace the old loader includes:

Construct a loader that inherits from DexClassLoader; obtain the directory path of the upgrade file based on the created directory, and pass the directory path to the constructed loader; based on the constructed loader, modify the attribute values of ClassLoader and Resources in the LoadedAPK class to obtain a new loader for replacing the old loader.

Optionally, obtaining the upgrade file required for the upgrade based on the new version program installation package includes:

The legitimacy of the new version program installation package is verified, and if the verification passes, the upgrade file required for the upgrade is obtained based on the new version program installation package.

Optionally, the method further includes: if the verification fails, clearing the new version program installation package.

Optionally, before constructing the new loader, the method further includes:

If the upgrade file fails to be stored, the upgrade file is deleted.

An application program upgrade device, the device being applied to a target application program, comprising:

A file acquisition module is configured to obtain an upgrade file required for the upgrade based on a new version of the target application program installation package when the target application program is started;

An information storage module, configured to create a directory for the upgrade file in a writable storage area and store the upgrade file in the created directory;

Loader construction module, used to build new loaders to replace old loaders;

The information loading module is used to load the upgrade file from the directory using the constructed new loader.

Optionally, the upgrade file includes an executable file and a resource file, and the file acquisition module is used to:

Extracting an executable file from the new version program installation package;

The new version program installation package is used as a resource file.

Optionally, the executable file includes an executable code file and a dynamic link library, and the executable code file, dynamic link library, and resource file are stored in different directories respectively.

Optionally, the constructed loader inherits from DexClassLoader, and the loader construction module is used to:

Construct a loader that inherits from DexClassLoader; obtain the directory path of the upgrade file based on the created directory, and pass the directory path to the constructed loader; based on the constructed loader, modify the attribute values of ClassLoader and Resources in the LoadedAPK class to obtain a new loader for replacing the old loader.

A computer device comprising:

processor;

a memory for storing processor-executable instructions;

Wherein, the processor is configured to:

When the target application is started, if a new version of the target application is installed, obtaining an upgrade file required for the upgrade based on the new version of the target application;

Creating a directory for the upgrade file in a writable storage area, and storing the upgrade file in the created directory;

Build a new loader to replace the old one;

The upgrade file is loaded from the directory using the newly constructed loader.

The technical solutions provided by the embodiments of this specification may have the following beneficial effects:

By applying the embodiments of this specification, during the startup process of the target application, if a new version of the program installation package of the target application is obtained, the upgrade file required for the upgrade can be obtained based on the new version of the program installation package, a directory can be created for the upgrade file in the writable storage area, and the upgrade file can be stored in the created directory. In addition, a new loader can be dynamically constructed to replace the old loader, so that the upgrade file can be loaded from the created directory using the constructed new loader, thereby realizing application upgrade without user confirmation or overwriting installation, thereby improving the installation rate of the new version of the program installation package.

It should be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present disclosure.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the specification and, together with the description, serve to explain the principles of the specification.

FIG1 is a flowchart of a method for upgrading an application program according to an exemplary embodiment of the present specification.

FIG2 is a flowchart of another application program upgrade method according to an exemplary embodiment of this specification.

FIG3 is a class diagram of an application program upgrade method according to an exemplary embodiment of this specification.

FIG4 is a hardware structure diagram of the computer device where the application program upgrading device of this specification is located.

FIG5 is a block diagram of an application program upgrading device according to an exemplary embodiment of this specification.

DETAILED DESCRIPTION

Exemplary embodiments will be described in detail herein, with examples illustrated in the accompanying drawings. In the following description, when referring to the drawings, identical numerals in different figures represent identical or similar elements unless otherwise indicated. The embodiments described in the following exemplary embodiments are not intended to represent all embodiments consistent with this specification. Rather, they are merely examples of apparatus and methods consistent with certain aspects of this specification, as detailed in the appended claims.

The terms used in this specification are for the purpose of describing specific embodiments only and are not intended to limit this specification. As used in this specification and the appended claims, the singular forms "a," "an," "the," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and/or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items.

It should be understood that although the terms first, second, third, etc. may be used in this specification to describe various information, such information should not be limited to these terms. These terms are merely used to distinguish information of the same type from one another. For example, first information may also be referred to as second information, and similarly, second information may also be referred to as first information without departing from the scope of this specification. Depending on the context, the term "if" as used herein may be interpreted as "when," "when," or "in response to determining."

An application upgrade can be an update from a lower version to a higher version. Since higher versions often fix some vulnerabilities (bugs) in lower versions or add more features compared to lower versions, the updated application often has better performance than the original version, achieves optimized results, and users can have a better experience. When installing an application on an Android device for the first time, it is installed directly. When a new version is pushed to an Android device, the latest APP is often downloaded first, and then the APP Installer is jumped to for overwriting the installation. Based on the game between the terminal and the user, each update requires user confirmation before it can be overwritten and installed, that is, it can be overwritten and installed only after receiving the confirmation upgrade instruction. In view of this, it is particularly important to provide a solution that can automatically upgrade the application without overwriting.

The embodiments of this specification can be applied to electronic devices that require application upgrades. The electronic device can be any electronic device that can run software, and the electronic device can be a handheld electronic device or other electronic device. For example, it can be a cellular phone, a media player, or other handheld portable device, a slightly smaller portable device such as a wristwatch or pendant, or other wearable or miniaturized device, gaming equipment, a tablet computer, a notebook computer, a computer integrated into a computer display, or other electronic equipment.

This specification provides an application upgrade method, which can be applied in a target application. Part of the process of the method can be shown with reference to Figure 1. Figure 1 is a flowchart of an application upgrade method shown in this specification according to an exemplary embodiment. The method may include steps 101, 102, 103 and 104.

In step 101, when the target application is started, if a new version program installation package of the target application is obtained, an upgrade file required for the upgrade is obtained based on the new version program installation package.

In step 102, a directory is created for the upgrade file in a writable storage area, and the upgrade file is stored in the created directory.

In step 103, a new loader is constructed to replace the old loader.

In step 104, the upgrade file is loaded from the directory using the constructed new loader.

Among them, Android APP can run in an independent space, that is, it can run in a separate process. If you need to start the application, the Android system can create a new process for the application and start it. This process will continue to run until it is killed by the system. At present, Android often uses the PathClassLoader class as the default class loader of Android. PathClassLoader can load class files from the file system. PathClassLoade itself inherits from BaseDexClassLoader. PathClassLoade can only load Apk (AndroidPackage, that is, Android installation package) files that have been installed in the Android system, that is, Apk files in the /data/app directory. Therefore, when there is a new version of the program installation package, the Apk file needs to be copied to the program directory to achieve overwriting installation.

This specification uses the old version of the app as the bootloader for the new version of the app. By replacing the app's native Application with a New Application, the replacement entry logic is implemented. The upgraded files obtained from the new version of the program installation package replace the executable files and resource files at runtime, thereby loading the new executable files and new resource files. Among them, the Android Application can serve as the program's entry point.

When the target application needs to be started, the system can create a new process for the target application. During the target application startup process, a new version installation package of the target application can be obtained. The new version installation package can be the complete installation package required to upgrade the application.

In one example, the current version identifier of the target application may be compared with the latest version identifier published online, and the new version application package of the target application may be downloaded based on the comparison result.

The version identifier can be a version number or other identifier that uniquely represents the version, allowing for easy version differentiation. For example, the version identifier can be a versionCode. The versionCode of a new version of the app installation package is greater than the versionCode of the currently installed app. This versionCode is typically specified in the app configuration file. The latest version identifier can be obtained proactively from the server by the execution end, or it can be obtained based on a push notification from the server.

In this example, the new version application package of the target application can be directly downloaded from the server based on the comparison result of the version identifiers, thereby improving the efficiency of obtaining the new version application package.

In another example, the server might only deliver an incremental upgrade package. This package addresses the differences and excludes the parts that are identical to the old version of the application. Therefore, the incremental upgrade package can be combined with the old version of the application to create a complete new version installation package.

It can be seen that downloading the incremental upgrade package from the Internet can reduce network transmission pressure because the incremental upgrade package is smaller than the complete program installation package (full installation package).

In some examples, it can be determined whether the new version program installation package is downloaded successfully. If successful, the upgrade file step required for the upgrade is obtained based on the new version program installation package. If unsuccessful, the downloaded file is deleted.

After obtaining the new version of the target application program installation package, the upgrade files required for the upgrade can be obtained based on the new version of the program installation package. The upgrade files may include executable files and resource files. Among them, the executable files may include executable code files and dynamic link libraries. For example, the executable code file may include the executable code of Android Dalvik/ARTruntime; the dynamic link library may be a dynamic link library generated by C or C++ language, etc.; the resource file may include accessible/renderable images, audio, video, resources and ID mapping files, etc. As an example, the executable file can be extracted from the new version of the program installation package. For example, the new version of the program installation package is decompressed, and then the executable file is extracted. As an example, the new version of the program installation package can be directly used as a resource file so that the old resources can be replaced with new resources later. The legal resource package in Android can be an APP file, so the new version of the program installation package can be directly used as a new resource package.

In some examples, to improve execution efficiency, obtaining the upgrade file required for the upgrade based on the new version of the program installation package may include optimizing the initial executable file obtained based on the new version of the program installation package to obtain an optimized executable file. The optimization process may include executing the initial executable file once to convert the initial executable file into an executable file with the highest execution efficiency on the current device. For example, by calling the dex2oat interface to convert the dex file into an oat file, execution efficiency is improved.

Furthermore, in the process of obtaining the upgrade file, the legitimacy of the new version of the program installation package can also be verified. If the verification is passed, the upgrade file required for the upgrade can be obtained based on the new version of the program installation package. When performing the legitimacy verification, if the new version of the program installation package is a compressed installation package, it can be decompressed first and then the legitimacy can be verified. The purpose of legitimacy verification is to ensure the security of the installation package. As an example, the package name and signature of the new version of the program installation package can be verified. For example, verify whether the package name and signature are consistent with the package name and signature of the currently installed APP, etc. The subsequent upgrade process will only be carried out if the new version of the program installation package is legal, thereby improving security.

Furthermore, if the verification fails, the new version of the program installation package is cleared. As can be seen, for illegal new version of the program installation package, it can be automatically cleared by verification. After clearing the new version of the program installation package, the files in the current version (old version) of the application can be loaded to run the current version of the application.

In some examples, after obtaining the upgrade file, the legitimacy of the upgrade file can also be verified. The integrity, signature and other information of the upgrade file can be verified to prevent the upgrade file from being tampered with. If the upgrade file does not meet the legitimacy verification (such as being tampered with), the upgrade file is cleared and the file in the current version (old version) application is loaded to run the current version of the application.

After obtaining the upgrade files required for the upgrade based on the new version of the program installation package, a directory can be created for the upgrade files in the writable storage area and the upgrade files can be stored in the created directory. For applications, some storage areas only have read permissions, while other storage areas have read and write permissions. In view of this, a directory can be created for the upgrade files in the writable storage area of the target application. Different directories are created for different types of upgrade files so that different types of upgrade files are stored in different directories. For example, the executable code files, dynamic link libraries, and resource files are stored in different directories respectively, so that different files can be loaded from different storage paths.

After storing the upgrade file in the created directory, the directory path of different upgrade files can be obtained. Therefore, the directory path of the current version of the executable file and the directory path of the resource file in the target application can be updated based on the directory path of each upgrade file, so that during subsequent loading, the executable file can be passed to ClassLoader according to the directory path of the executable file to replace the executable file with ClassLoader; the resource file can be passed to Resources according to the directory path of the resource file to replace the resource with Resources.

In this embodiment, a new loader can be constructed to replace the old loader. For example, a NewClassLoader inherited from DexClassLoader can be constructed to dynamically replace the PathClassLoader in the old APP. Therefore, the code logic execution can be hooked, including dex code and native code.

For example, a loader inherited from DexClassLoader is constructed; the directory path of the upgrade file is obtained based on the created directory, and the directory path is passed to the constructed loader. After the directory path is passed to the new loader, a new DexPathList can be constructed. Based on the constructed loader, the attribute values of ClassLoader and Resources in the LoadedAPK class are modified to obtain a new loader to replace the old loader, so that the executable file and resource file can be loaded from the directory using the constructed new loader during subsequent loading. This embodiment dynamically modifies the attribute values in the LoadedAPK class to facilitate the subsequent loading of executable files or resources, thereby loading the corresponding executable files or resources from the new directory path and realizing the replacement of executable files and resources.

It can be seen that this embodiment realizes the replacement of executable files by modifying the attribute value of Class Loader, and realizes resource replacement by modifying the attribute value of Resources, thereby realizing automatic upgrade through the application itself without user confirmation, which can not only improve the utilization rate of the new version program installation package, but also allow users to enjoy the high performance brought by the upgrade without any operation.

In some examples, when a target application is first installed, the target application's files are stored in a storage area to which the target application has only read permissions. However, for subsequent upgrades, the target application can distinguish between directory nodes based on the current version, storing upgrade files for different versions in different directories. In one example, upgrade files for different versions can be stored simultaneously to facilitate subsequent retrieval of upgrade files for older versions. In another example, upgrade files with versions lower than the current version can be cleared to conserve storage space. For example, if the target application is first installed with version 1.0, and the target application is upgraded from version 1.0 to version 2.0, the upgrade files can be stored in the 2.0 directory (it will be appreciated that the 2.0 directory can contain multiple subdirectories for storing different types of files). When loading files, the executable and resource files in the 2.0 directory are directly loaded. When the target application is upgraded from version 2.0 to version 3.0, the upgrade files can be stored in the 3.0 directory, and the executable and resource files in the 2.0 directory can be cleared. When loading files, the executable and resource files in the 2.0 directory are directly loaded.

After building a new loader, it can also determine whether operations such as storage and building are successful. If successful, it proceeds to the next step. If not, it clears the file and loads the current version of the application file. Furthermore, if successful, it can also perform file legitimacy verification to prevent information tampering. After verification, the newly built loader can be used to load the upgrade file from the directory, thereby loading new resources and new executable files.

The various technical features in the above embodiments can be combined arbitrarily as long as there is no conflict or contradiction between the combinations of features. However, due to space limitations, they are not described one by one. Therefore, the arbitrary combination of the various technical features in the above embodiments also falls within the scope of disclosure of this specification.

The following is an example of one of the combinations.

As shown in Figure 2, Figure 2 is a flowchart of another application upgrade method shown in this specification according to an exemplary embodiment. In this embodiment, the current version identifier of the target application can be compared with the latest version identifier released online. If it is determined based on the comparison result that there is a new version program installation package, the new version program installation package is downloaded (step 201). If the download fails, the file is cleared and the file of the current version (old APP) is loaded (step 202). If the download is successful, the upgrade file required for the upgrade is obtained based on the new version program installation package, a directory is created for the upgrade file in the writable storage area, and the upgrade file is stored in the created directory, and a new loader is constructed to replace the old loader (step 203). If the release process of step 203 fails, step 202 is executed. If the release is successful, security verification is performed (step 204), for example, to verify whether the upgrade file is complete, whether the signature is the same as the signature of the current version, etc. If the verification fails, step 202 is executed. If the verification is successful, the upgrade file is loaded from the created directory using the constructed new loader (step 205).

Accordingly, this specification also provides an example description in conjunction with a class diagram of one embodiment. As shown in FIG3 , FIG3 is a class diagram of an application program upgrade method according to an exemplary embodiment of this specification.

In this diagram, LoadedAPK, NewClassLoader, DeexClassLoader, BaseDexClassLoader, DexPathList, Element, and DexFile, etc. may be included.

LoadedApk: Represents an instance of the process during the running of the Android APP, including the executable file loader ClassLoader and the instance Resources for loading resources.

NewClassLoader: This represents the class loader for the upgraded app. It is a subclass of DexClassLoader and points to the executable file path of the new app. By constructing a new ClassLoader at runtime and modifying the mClassLoader and mResources properties in the LoadedAPK class, code logic and resources can be replaced during runtime to achieve the upgrade.

BaseDexClassLoader: The actual executable file loader of the Android runtime, it is the parent class of DexClassLoader. It finds and loads Java classes through findClass(String name) and finds static link libraries through findLibrary(String name), and these operations are all completed by the pathList attribute. BaseDexClassLoader delegates the findClass method to the findClass method of the pathList object. The pathList object is newly created in the constructor of NewDexClassLoader, and its type is DexPathList. It directly traverses the dexElements list and then loads the class by calling the loadClass() method on the element.dexFile object. If the return value is not null, it means that the class is loaded successfully and the Class object will be returned.

DexPathList: Contains the dexElements collection of DEX files and the nativeLibraryDirectories collection of dynamic link library file paths. It is the place where executable files are actually loaded. The dexElements list in the DexPathList object is the core of class loading. If a class can be successfully loaded, its dex will appear in the dex file corresponding to the dexElements.

Element: Contains the address file of the Dex file and the object dexFile that maps dex to memory.

DexFile: responsible for mapping the dex file to memory and executing the loading of Java classes.

It can be seen that this embodiment stores the executable files and resources obtained based on the new version of the program installation package in the created directory, and realizes automatic application upgrade without user confirmation by replacing the executable files and resources.

Corresponding to the aforementioned embodiment of the application program upgrading method, this specification also provides an embodiment of an application program upgrading apparatus and an electronic device to which the apparatus is applied.

The embodiments of the application program upgrade device of this specification can be applied to computer equipment. The device embodiments can be implemented by software, or by hardware or a combination of software and hardware. Taking software implementation as an example, as a device in a logical sense, it is formed by the processor of the computer device where it is located reading the corresponding computer program instructions in the non-volatile memory into the memory and running them. From the hardware level, as shown in Figure 4, it is a hardware structure diagram of the computer device where the application program upgrade device of this specification is located. In addition to the processor 410, memory 430, network interface 420, and non-volatile memory 440 shown in Figure 4, the computer device where the device 431 in the embodiment is located can generally include other hardware according to the actual function of the device, which will not be described in detail.

FIG5 is a block diagram of an application program upgrade device according to an exemplary embodiment of the present disclosure, wherein the device includes:

The file obtaining module 510 is configured to obtain an upgrade file required for the upgrade based on a new version of the program installation package if a new version of the program installation package of the target application is obtained when the target application is started.

The information storage module 520 is configured to create a directory for the upgrade file in the writable storage area and store the upgrade file in the created directory.

The loader construction module 530 is used to construct a new loader for replacing the old loader.

The information loading module 540 is used to load the upgrade file from the directory using the constructed new loader.

In an optional implementation, the upgrade file includes an executable file and a resource file, and the file obtaining module 510 is used to:

Extracting an executable file from the new version program installation package;

The new version program installation package is used as a resource file.

In an optional implementation, the executable file includes an executable code file and a dynamic link library, and the executable code file, dynamic link library, and resource file are stored in different directories respectively.

In an optional implementation, the loader construction module 530 is configured to:

Construct a loader that inherits from DexClassLoader; obtain the directory path of the upgrade file based on the created directory, and pass the directory path to the constructed loader; based on the constructed loader, modify the attribute values of ClassLoader and Resources in the LoadedAPK class to obtain a new loader for replacing the old loader.

In an optional implementation, the file obtaining module 510 is configured to:

The legitimacy of the new version program installation package is verified, and if the verification passes, the upgrade file required for the upgrade is obtained based on the new version program installation package.

In an optional implementation, the apparatus further includes a clearing module (not shown in FIG5 ) configured to:

If the verification fails, the new version program installation package is cleared.

In an optional implementation, before constructing the new loader, the apparatus further includes a clearing module (not shown in FIG5 ) configured to:

If the upgrade file fails to be stored, the upgrade file is deleted.

For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to the partial description of the method embodiments. The device embodiments described above are merely illustrative, wherein the modules described as separate components may or may not be physically separated, and the components displayed as modules may or may not be physical modules, that is, they may be located in one place, or they may be distributed on multiple network modules. Some or all of the modules may be selected according to actual needs to achieve the purpose of the scheme of this specification. A person of ordinary skill in the art can understand and implement it without paying any creative work.

Accordingly, an embodiment of this specification further provides a computer device, comprising: a processor; and a memory for storing processor-executable instructions; wherein the processor is configured to:

When the target application is started, if a new version of the target application is installed, obtaining an upgrade file required for the upgrade based on the new version of the target application;

Creating a directory for the upgrade file in a writable storage area, and storing the upgrade file in the created directory;

Build a new loader to replace the old one;

The upgrade file is loaded from the directory using the newly constructed loader.

The various embodiments in this specification are described in a progressive manner. Similar parts between the various embodiments can be referred to in conjunction with each other. Each embodiment focuses on the differences between the other embodiments. In particular, the device embodiments are generally similar to the method embodiments, so the description is relatively simple. For relevant parts, refer to the description of the method embodiments.

A computer storage medium, wherein program instructions are stored in the storage medium, and the program instructions include:

When the target application is started, if a new version of the target application is installed, obtaining an upgrade file required for the upgrade based on the new version of the target application;

Creating a directory for the upgrade file in a writable storage area, and storing the upgrade file in the created directory;

Build a new loader to replace the old one;

The upgrade file is loaded from the directory using the newly constructed loader.

The embodiments of this specification may take the form of a computer program product implemented on one or more storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) containing program code. Computer-usable storage media include permanent and non-permanent, removable and non-removable media, and information storage can be achieved by any method or technology. Information can be computer-readable instructions, data structures, program modules or other data. Examples of computer storage media include but are not limited to: phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, read-only compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices or any other non-transmission medium that can be used to store information that can be accessed by a computing device.

Other embodiments of the present invention will readily occur to those skilled in the art upon consideration of the present invention and practice of the invention claimed herein. This specification is intended to cover any variations, uses, or adaptations of the present invention that follow the general principles of this specification and include common knowledge or customary techniques in the art not claimed herein. The description and examples are to be considered as exemplary only, with the true scope and spirit of the present invention being indicated by the following claims.

It should be understood that the present description is not limited to the exact structure that has been described above and shown in the drawings, and that various modifications and changes may be made without departing from the scope thereof. The scope of the present description is limited only by the appended claims.

The above description is only a preferred embodiment of this specification and is not intended to limit this specification. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of this specification should be included in the scope of protection of this specification.

Claims (10)

1. An application upgrade method, the method being applied to a target application, the method comprising: When the target application starts, if a new version installation package of the target application is obtained, the upgrade files required for the upgrade are obtained based on the new version installation package; the upgrade files include executable files and resource files; the target application acts as the launch loader of the new version program, and replaces the program's entry logic by replacing the native Application with NewApplication; Create a directory for the upgrade files in the writable storage area, and store the upgrade files in the created directory; A loader inheriting from DexClassLoader is constructed and dynamically replaces the default class loader PathClassLoader during the execution of the target application, hooking the execution of the target application's code logic; the directory path of the upgrade file is obtained based on the created directory, and the directory path is passed to the constructed loader; based on the constructed loader, the attribute value of ClassLoader in the LoadedAPK class is modified to pass the executable file to the target application, and the attribute value of Resources is modified to pass the resource file to Resources, thus obtaining a new loader to replace the old loader; The newly constructed loader loads the upgrade files from the directory. 2. The method according to claim 1, wherein the upgrade file includes an executable file and resource files, and the upgrade file required for upgrading based on the new program installation package includes: Extract the executable file from the new version of the program installation package; The new program installation package is used as a resource file. 3. The method according to claim 2, wherein the executable file includes an executable code file and a dynamic link library, and the executable code file, the dynamic link library, and the resource file are stored in different directories. 4. The method according to any one of claims 1 to 3, wherein obtaining the upgrade file required for the upgrade based on the new program installation package includes: The new version of the program installation package is validated for legality. If the validation passes, the upgrade files required for the upgrade are obtained based on the new version of the program installation package. 5. The method according to claim 4, further comprising: If verification fails, the new version of the program installation package will be deleted. 6. The method according to any one of claims 1 to 3, wherein before constructing the new loader, the method further comprises: If the upgrade file fails to be stored, then the upgrade file will be deleted. 7. An application upgrade apparatus, the apparatus comprising: The file acquisition module is used to obtain the upgrade files required for the upgrade based on the new version installation package of the target application when the target application starts. The upgrade files include executable files and resource files. The target application acts as the launch loader of the new version program, replacing the original Application with New Application to replace the program's entry logic. The information storage module is used to create a directory for the upgrade file in the writable storage area and store the upgrade file in the created directory; The loader construction module is used to construct a loader that inherits from DexClassLoader and dynamically replace the default class loader PathClassLoader during the execution of the target application, and hook the code logic execution of the target application; obtain the directory path of the upgrade file based on the created directory, and pass the directory path to the constructed loader; modify the ClassLoader attribute value in the LoadedAPK class based on the constructed loader, pass the executable file to the target application, and modify the Resource attribute value, pass the resource file to Resource, to obtain a new loader for replacing the old loader; An information loading module is used to load upgrade files from the directory using the newly constructed loader. 8. The apparatus according to claim 7, wherein the upgrade file comprises an executable file and resource files, and the file acquisition module is configured to: Extract the executable file from the new version of the program installation package; The new program installation package is used as a resource file. 9. The apparatus according to claim 7, wherein the executable file includes an executable code file and a dynamic link library, and the executable code file, the dynamic link library, and the resource file are stored in different directories. 10. A computer device, comprising: processor; Memory used to store processor-executable instructions; The processor is configured to implement the method according to any one of claims 1 to 6.