Application hot update methods, devices, storage media and electronic devices

Abstract

This disclosure relates to a method, apparatus, storage medium, and electronic device for hot-updating applications. The method includes: starting a target application; creating a first object corresponding to an entry application class and initializing the attributes of the first object; loading a target class file, the target class file including the target application class, through a class loader; creating a second object corresponding to the target application class, and injecting the initialized attributes of the first object into the second object. The entry application class is a class registered with the operating system, while the target application class is a class not registered with the operating system. The entry application class is used to transfer calls to its own methods from the operating system to the target application class. This solution enables hot-updating of the target application class code without requiring modification of the target application class, making it applicable to large-scale applications.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and more specifically, to a method, apparatus, storage medium, and electronic device for hot-updating applications. Background Technology

[0002] Tinker is a hot-update framework for Android applications, and many applications with hot-update requirements integrate Tinker. Tinker supports dynamically distributing code, resource files, and library files, enabling application updates without reinstalling the application.

[0003] However, the Android system has a limitation on application class loading: custom target application classes that inherit from the base application class and their dependent classes can only be loaded by the system's default class loader, and cannot be loaded by a custom class loader. Therefore, Tinker's hot update solution cannot achieve hot update for this part of the code. Summary of the Invention

[0004] This summary section is provided to briefly introduce the concepts, which will be described in detail in the detailed description section below. This summary section is not intended to identify key or essential features of the claimed technical solution, nor is it intended to limit the scope of the claimed technical solution.

[0005] In a first aspect, this disclosure provides a method for hot-updating an application, including:

[0006] Start the target application, create a first object and initialize the properties of the first object, where the first object is the object corresponding to the entry application class;

[0007] The target class file, including the target application class, is loaded by a class loader.

[0008] Create a second object and inject the properties of the initialized first object into the second object, wherein the second object is the object corresponding to the target application class;

[0009] The entry application class is a class registered with the operating system, while the target application class is a class not registered with the operating system. The entry application class is used to transfer the operating system's calls to its own methods to the target application class.

[0010] Secondly, this disclosure provides an application hot update apparatus, comprising:

[0011] The object creation and initialization module is used to start the target application, create a first object and initialize the properties of the first object, where the first object is the object corresponding to the entry application class.

[0012] A class file loading module is used to load a target class file, which includes a target application class, via a class loader.

[0013] An object property injection module is used to create a second object and inject the properties of the initialized first object into the second object, wherein the second object is an object corresponding to the target application class;

[0014] The entry application class is a class registered with the operating system, while the target application class is a class not registered with the operating system. The entry application class is used to transfer the operating system's calls to its own methods to the target application class.

[0015] Thirdly, this disclosure provides a computer-readable medium having a computer program stored thereon, which, when executed by a processing device, implements the steps of the method described in the first aspect.

[0016] Fourthly, this disclosure provides an electronic device, comprising:

[0017] A storage device on which computer programs are stored;

[0018] A processing device for executing the computer program in the storage device to implement the steps of the method described in the first aspect.

[0019] In the technical solution of this disclosure embodiment, the entry application class is an application class registered with the Android system, while the target application class is an application class not registered with the system, which is a "pseudo" application class. The entry application class will act as a shell for the target application class, actively synchronizing the system's method calls to the target application class. Therefore, the lifecycle of the target application class will be managed by the entry application class. Since the target application class does not directly depend on the entry application class and it is not registered with the system, the target application class is allowed to be loaded through a custom class loader. Thus, the business code in the target application class and other classes that depend on the target application class can be hot-updated.

[0020] Overall, this technical solution combines shell design and attribute injection techniques to integrate the Tinker framework without modifying the original business code of the target application class. This allows the code of the target application class, which was originally not hot-updateable, to be hot-updateable without requiring any modification to the target application class, thus reducing the application integration cost and making this solution suitable for large-scale applications.

[0021] Other features and advantages of this disclosure will be described in detail in the following detailed description section. Attached Figure Description

[0022] The above and other features, advantages, and aspects of the embodiments of this disclosure will become more apparent from the accompanying drawings and the following detailed description. Throughout the drawings, the same or similar reference numerals denote the same or similar elements. It should be understood that the drawings are schematic, and the originals and elements are not necessarily drawn to scale. In the drawings:

[0023] Figure 1 This is a diagram illustrating how Tinker generates patch files using the differential algorithm;

[0024] Figure 2 This is a diagram illustrating the target terminal application patch file;

[0025] Figure 3 This is a diagram illustrating the loading of class files in the executable file before integrating Tinker;

[0026] Figure 4 This is a diagram illustrating the loading of class files within an executable file after integrating Tinker.

[0027] Figure 5 It is a modified class diagram for integrating Tinker into an application;

[0028] Figure 6 It is based on Figure 5 The modified class diagram illustrates the effect of the modification on the target application class.

[0029] Figure 7 This is a modified class diagram of integrating Tinker into an application, provided in an embodiment of this disclosure;

[0030] Figure 8 It is based on Figure 7 The modified class diagram provides a flowchart of the application's hot update method;

[0031] Figure 9 It is based on Figure 7 The modified class diagram illustrates the effect of the modification on the target application class.

[0032] Figure 10 This is a schematic diagram of an application hot update device provided in an embodiment of this disclosure;

[0033] Figure 11 This is a schematic diagram of an electronic device provided in an embodiment of this disclosure. Detailed Implementation

[0034] Embodiments of this disclosure will now be described in more detail with reference to the accompanying drawings. While some embodiments of this disclosure are shown in the drawings, it should be understood that this disclosure can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this disclosure. It should be understood that the accompanying drawings and embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of protection of this disclosure.

[0035] It should be understood that the steps described in the method embodiments of this disclosure may be performed in different orders and / or in parallel. Furthermore, the method embodiments may include additional steps and / or omit the steps shown. The scope of this disclosure is not limited in this respect.

[0036] The term "comprising" and its variations as used herein are open-ended inclusions, meaning "including but not limited to". The term "based on" means "at least partially based on". The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments". Definitions of other terms will be given in the description below.

[0037] It should be noted that the concepts of "first" and "second" mentioned in this disclosure are used only to distinguish different devices, modules or units, and are not used to limit the order of functions performed by these devices, modules or units or their interdependencies.

[0038] It should be noted that the terms "a" and "a plurality of" used in this disclosure are illustrative rather than restrictive, and those skilled in the art should understand that, unless otherwise expressly indicated in the context, they should be understood as "one or more".

[0039] The names of messages or information exchanged between multiple devices in the embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of such messages or information.

[0040] Tinker is a hot-update framework for Android applications. Tinker provides a differential algorithm to compare the differences between two different versions of an application to generate patch files. Figure 1 This diagram illustrates the generation of patch files using a differential algorithm, such as... Figure 1As shown, the process first obtains the original application and the target application to be updated. The original application includes a compiled first executable file, a first library file, and a first resource file. The target application includes a compiled second executable file, a second library file, and a second resource file. The first differential algorithm is an incremental comparison algorithm for executable files. Using the first differential algorithm, an executable file differential package is generated based on the first and second executable files. The second differential algorithm generates a library file differential package based on the first and second library files, and a resource file differential package based on the first and second resource files. After generating the executable file differential package, library file differential package, and resource file differential package respectively, they are packaged together to generate a patch file.

[0041] The above process can be performed on a cloud server. Once the cloud server generates the patch file for this hot update, it will distribute the patch file to the target terminal.

[0042] Figure 2 The diagram illustrates the application patch file for the target terminal. Tinker provides a scheme for patch file synthesis, and its implementation principle is... Figure 1 Tinker performs the reverse operation of the patch file generation process. After receiving the patch file, the target terminal merges the original application on the terminal with the remotely distributed patch file. During the merging process, the executable file differential package in the patch file is merged with the first executable file in the original application to generate a second executable file. The library file differential package in the patch file is merged with the first library file in the original application to generate a second library file. The resource file differential package in the patch file is merged with the first resource file in the original application to generate a second resource file. Thus, the target application is obtained based on the second executable file, the second library file, and the second resource file. Tinker modifies the startup path of the target application so that the operating system prioritizes loading class files from the second executable file in the target application, thereby achieving hot code updates.

[0043] Figure 3 This diagram illustrates the loading of class files from the executable file by the target terminal before integrating Tinker. It's important to note that the entry point for an application's startup is the application class (i.e., the Application class). The operating system loads the application class and its dependent classes from the executable file using the system's default class loader. This is Android's requirement for application class loading, and application developers cannot change this loading relationship from the application's perspective. Other classes in the executable file are also loaded by the system's default class loader by default, but Android also allows loading them using other custom class loaders. For example... Figure 3The system's default class loader is PathClassLoader, and the custom class loader is V1ClassLoader.

[0044] Figure 4 This diagram illustrates how class files are loaded from an executable file in a target terminal after integrating Tinker. After integrating Tinker, the target terminal needs to load class files from the merged second executable file. Therefore, a new custom class loader needs to be designed to load other classes from the merged second executable file. This new custom class loader is named V2ClassLoader. After creating the custom class loader V2ClassLoader to load other classes from the second executable file, the previous custom class loader V1ClassLoader is no longer used; it's equivalent to the previous classes V1 being hot-uploaded to classes V2. After loading, the functionality modified in the other classes is successfully applied to the target terminal.

[0045] It is important to note that after integrating Tinker, the application classes and their dependent classes in the target application are still loaded by the system's default class loader, PathClassLoader, and cannot be loaded by a custom class loader. Therefore, hot updates of this part of the code are still not possible after integrating Tinker.

[0046] The class loader for the application class and its dependent classes is determined by the system and cannot be modified by developers, which makes it impossible to hot update this part of the code. The following solution is introduced. This solution can enable hot updates of this part of the code as much as possible by migrating the code in the application class.

[0047] Figure 5 This diagram illustrates a modified class diagram for integrating Tinker into an application, with the left side showing the class diagram before Tinker integration and the right side showing the class diagram after Tinker integration. Figure 5 As shown in the class diagram on the left before integrating Tinker, both the base application class and the target application class belong to the application class.

[0048] The base application class is a native application class provided by the Android system. It's an interface class offered by the system for external extensions, and the system automatically creates one for each application at runtime. Additionally, developers can define their own application classes and inherit from this base application class when developing their applications. Specifically, a target application class is created that inherits from the base application class, and this target application class is registered in the system configuration file, allowing the system to call various methods within the target application class. In a specific embodiment, registration is done within the `<Application>` tag in the `AndroidManifest.xml` file. Simply add the "name" attribute to the `<Application>` tag and include the name of the created target application class.

[0049] To address the technical issue of the target application class's code not being able to be hot-updated. Figure 5 The modification approach for integrating Tinker on the right is to move the business logic out of the target application class and then move this business logic to a class that can be loaded by a custom class loader. The more parts are moved out, the more code can be hot-updated.

[0050] like Figure 5 The class diagram on the right, after integrating Tinker, shows that a large amount of business logic is extracted from the target application class and moved to the target application carrier class. The methods of this extracted business logic are then reimplemented in the target application carrier class. Tinker provides a scheduling application class and an intermediate scheduling interface. The scheduling application class is a custom application class provided by Tinker for external extension. The intermediate scheduling interface defines methods from the target application carrier class (such as attachBaseContext, onCreate, onTerminated, etc.), which the target application carrier class implements using the `implements` keyword. The scheduling application class encapsulates the logic for using the interface; by using the interface properties in the scheduling application class, the intermediate scheduling interface can be used to ultimately schedule and execute the corresponding methods in the target application carrier class.

[0051] For example, when the attachBaseContext() method is called from the scheduling application class, the intermediate scheduling interface with the interface name "ApplicationLike" will be used through the mApplicationLike property in the scheduling application class to directly access the attachBaseContext() method in the target application carrier class.

[0052] As can be seen from the diagram, this solution breaks the original inheritance relationship of the target application class, which originally inherited from the base application class, and now inherits from the scheduling application class.

[0053] Through the above solution, a large amount of business logic of the target application class is transferred to the target application carrier class for implementation. The target application carrier class is decoupled from the original target application class. That is, the target application carrier class does not need to be loaded through the system default class loader, but is allowed to be loaded through a custom class loader. Therefore, the business code that could not be hot-updated in the original target application class becomes hot-updable by moving it to the target application carrier class for implementation.

[0054] The above solutions are suitable for newly developed applications or applications with relatively simple business logic, but for large applications, the cost of modifying the target application class is too high. Figure 6 This diagram illustrates the effect of the solution on the target application class. It's understandable that large applications typically contain many classes, such as class A, class B, ..., class Z, all of which depend on the target application class. After integrating Tinker, a significant portion of the target application class's business logic has been moved to the target application carrier class. Therefore, all existing dependencies on this business logic need to be changed. For example, class Z, which originally depended on other attributes of the target application class, needs to depend on the target application carrier class after integrating Tinker. Such changes would be numerous in large applications, resulting in prohibitively high transformation costs.

[0055] Therefore, this disclosure provides an integration solution that does not require modification of the original target application class, which is suitable for integrating the Tinker framework into applications with a relatively large business scale, thereby enabling hot updates of the business code of the target application class without modifying the original target application class.

[0056] Figure 7 A modified class diagram for integrating Tinker into an application, as provided in an embodiment of this disclosure, is shown. Figure 7 In this context, the target application class is the original target application class of the application, that is, the original class used by the developer to design the code. The entry application class is the newly added application class. The entry application class inherits from the scheduling application class, the scheduling application class inherits from the base application class, and the target application class inherits from the base application class. In other words, the entry application class is a subclass of the scheduling application class, the scheduling application class is a subclass of the base application class, and the target application class is a subclass of the base application class.

[0057] It's important to note that the entry application class is a class registered with the Android system; that is, it needs to be registered in the AndroidManifest.xml file. The lifecycle of the entry application class is managed by the Android system. In the original design logic of the application, the target application class needs to be registered with the system. However, in this embodiment, it is no longer registered with the Android system, i.e., it is no longer registered in the AndroidManifest.xml file, becoming a "pseudo" application class. Therefore, the target application class loses its original function, and all its methods are no longer called by the system; they need to be actively called within the application.

[0058] The modified class diagram above also defines an intermediate scheduling interface, which the target application class needs to implement. The purpose of the intermediate scheduling interface is to serve as an interface exposed by the target application class for the scheduling application class to use. The scheduling application class can then schedule methods within the target application class through this exposed interface. It should be noted that since the methods defined in this intermediate scheduling interface already exist in the target application class, the target application class does not need to implement a new interface.

[0059] It is worth noting that the scheduling application class is an application class provided by Tinker for external use. The more complete its encapsulated functions, the lower the cost of external access. In this solution, the entry application class serves as the external access point for the scheduling application class. Since the scheduling application class has already implemented the logic for using the interface, the entry application class only needs to inherit from the scheduling application class and does not need to reimplement these logics, which can effectively reduce the development cost of the entry application class.

[0060] As can be seen from the modified class diagram above, this embodiment adds a shell consisting of an entry application class and a scheduling application class to the original target application class. The methods of the target application class are actively scheduled by the shell. When a method in the entry application class is scheduled by the Android system, it will be synchronously and actively scheduled to the corresponding method in the target application class, thereby implementing the original business logic. Furthermore, since the target application class does not directly depend on the scheduling application class and is not registered with the system, it is allowed to be loaded through the custom class loader V2ClassLoader. Therefore, the business code in the target application class and other classes that depend on it can be hot-updated. In addition, this solution does not require modification of the business logic of the target application class, making it particularly suitable for large-scale applications.

[0061] In a specific embodiment, when a method in the entry application class is called by the Android system, the entry application class will further call the method in the scheduling application class. When the method in the scheduling application class is called by the entry application class, the scheduling application class will further use a predefined intermediate scheduling interface. In the process of using the intermediate scheduling interface, the method in the target application class will be called through the intermediate scheduling interface, thereby transferring the Android system's call to its own method to the target application class.

[0062] For example: Since the entry application class registers with the system, when the system wants to call the attachBaseContext() method, it will first call this method from the entry application class. The entry application class will then synchronously call the above method in the scheduling application class. The scheduling application class will then use the intermediate scheduling interface named "ApplicationLike" through the mApplicationLike property to finally call the attachBaseContext() method in the target application class.

[0063] Understandably, before integrating Tinker, the lifecycle of the target application class is managed by the system because the target application class registers with the system; however, after integrating Tinker through the embodiments of this disclosure, the lifecycle of the target application class is managed by the entry application class because the entry application class registers with the system and the target application class does not register with the system, and the methods of the target application class need to be actively called by the entry application class.

[0064] according to Figure 7 The modified class diagram described herein provides a corresponding application hot update method in this embodiment. Figure 8 A flowchart illustrating the application's hot update method, which can be executed by the target terminal, is shown. Please refer to... Figure 8 The method includes:

[0065] S110, Start the target application, create a first object and initialize the properties of the first object, which is the object corresponding to the entry application class.

[0066] Specifically, the target terminal obtains the corresponding patch file, merges the original application with the patch file to obtain the target application, and then starts the target application. After starting the target application, an object corresponding to the entry application class, i.e., the first object, is automatically created, and the properties of the first object are initialized.

[0067] S120, the target class file, which includes the target application class, is loaded by the class loader.

[0068] Create a custom class loader and use it to load the target class file from the target application's executable file. This target class file contains the target application's classes. Additionally, the target class file includes other classes that depend on the target application's classes.

[0069] Optionally, the method further includes loading the entry application class, the scheduling application class, and the base application class using the system's default class loader. The entry application class, as an application class registered with the system, and its dependent classes are all loaded by the system-specified default class loader, PathClassLoader. It is important to note that the target application class does not directly depend on the entry application class, the scheduling application class, or the base application class; therefore, the target application class can be loaded using a custom class loader, V2ClassLoader.

[0070] S130, create a second object and inject the properties of the initialized first object into the second object, which is the object corresponding to the target application class.

[0071] After loading the target class file, reflection creates an object corresponding to the target application class, i.e., the second object, and injects the properties of the first object initialized in S110 into the second object. Reflection refers to the application obtaining internal information of any class during execution using the reflection API and being able to directly manipulate any corresponding internal properties and methods.

[0072] Understandably, after Figure 7 After the modification, because the target application class is no longer initialized by the Android system, the key properties in the target application class are not initialized. These key properties are shown in Table 1 below:

[0073]

[0074]

[0075] Table 1

[0076] Since the first object corresponding to the entry application class is actually initialized by the Android system, the above key attributes all exist in the first object. These key attributes need to be injected into the second object corresponding to the target application class at the appropriate time to ensure that the target application class can work normally as before.

[0077] In a specific embodiment, after the first object corresponding to the entry application class is created, the system will start calling the attachBaseContext() method in the entry application class. The system call to attachBaseContext() is the earliest point that can be intercepted during application startup. Therefore, when the system call to attachBaseContext() is detected, S120 is executed, which involves creating a custom class loader V2ClassLoader to load the target class file from the second executable file of the target application. The target class file includes the target application class and several other classes that depend on the target application class.

[0078] Once the target class file is loaded, reflection is used to actively create an object corresponding to the target application class, i.e., the second object. After the second object is created, it does not yet possess the `mBase` and `mLoadedApk` properties of the first object created by the system. Therefore, the values ​​of the `mBase` and `mLoadedApk` properties of the first object need to be injected into the second object. This injection step can be completed through reflection.

[0079] Therefore, in a specific embodiment, S130 includes: retrieving the mBase attribute of the first object using reflection, and assigning the value of the mBase attribute of the first object to the mBase attribute of the second object. S130 also includes: retrieving the mLoadedApk attribute of the first object using reflection, and assigning the value of the mLoadedApk attribute of the first object to the mLoadedApk attribute of the second object. Once the two key attributes, mBase and mLoadedApk, of the second object are injected with real values, the second object can be used normally as before.

[0080] In addition to the mBase and mLoadedApk properties, the second object also has several registered listener properties, including mComponentCallbacks, mActivityLifecycleCallbacks, and mAssistCallbacks. For the above registered listener properties, the registered listener function can be made to work normally by redirecting the registered listener request to the first object.

[0081] In the original logic of the application, listeners were registered through the object of the target application class. Taking the mComponentCallbacks property as an example, all listeners registered on mComponentCallbacks were bound to the mComponentCallbacks of the target application class. However, after integrating Tinker using this solution, the mComponentCallbacks in the target application class is no longer a real object. Therefore, the registration request for listeners needs to be forwarded to the mComponentCallbacks of the first object corresponding to the entry application class.

[0082] Therefore, this method also includes: after creating the second object, redirecting the registration listener requests for the second object's registration listener attribute to the same registration listener attribute of the first object. In this way, all registration listener requests for the second object of the target application class will be forwarded to the first object and bound to it, thus ensuring the normal operation of the application's registration listener function even if the target application class does not register with the system.

[0083] Figure 9 This diagram illustrates the modification effect of the technical solution provided in this embodiment. It is understood that large applications typically contain many classes, such as class A, class B, ..., class Z, all of which depend on the target application class. After integrating Tinker into the application to achieve hot updates using this technical solution, it merely adds a layer to the original target application class. The attributes and behaviors of the target application class remain the same as before, requiring no changes to the target application class or its dependencies. For example, class Z, which originally depended on other attributes of the target application class, still depends on those attributes. In other words, the dependencies between classes A and Z do not need to be modified. When the application is a large-scale application, this will significantly reduce the integration cost of large applications.

[0084] In summary, in the technical solution of this disclosure embodiment, the entry application class is an application class registered with the Android system, while the target application class is an application class not registered with the system, and is a "pseudo" application class. The entry application class will act as a shell for the target application class, actively synchronizing the system's method calls to the target application class. Therefore, the lifecycle of the target application class will be managed by the entry application class. Since the target application class does not directly depend on the entry application class and does not register with the system, the target application class is allowed to be loaded through a custom class loader. Thus, the business code in the target application class and other classes that depend on the target application class can be hot-updated.

[0085] Overall, this technical solution combines shell design and attribute injection techniques to integrate the Tinker framework without modifying the original business code of the target application class. This allows the code of the target application class, which was originally not hot-updateable, to be hot-updateable without requiring any modification to the target application class, thus reducing the application integration cost and making this solution suitable for large-scale applications.

[0086] Based on the same inventive concept, this disclosure provides an application hot update device, please refer to... Figure 10 The device 200 includes:

[0087] The object creation and initialization module 210 is used to start the target application, create a first object and initialize the properties of the first object, where the first object is the object corresponding to the entry application class.

[0088] Class file loading module 220 is used to load a target class file through a class loader, wherein the target class file includes a target application class;

[0089] The object property injection module 230 is used to create a second object and inject the properties of the initialized first object into the second object, wherein the second object is an object corresponding to the target application class;

[0090] The entry application class is a class registered with the operating system, while the target application class is a class not registered with the operating system. The entry application class is used to transfer the operating system's calls to its own methods to the target application class.

[0091] Optionally, the entry application class is a subclass of the scheduling application class, which in turn is a subclass of the base application class, and the target application class provides an implementation of the intermediate scheduling interface; the device further includes a method invocation module for:

[0092] When a method in the entry application class is called by the operating system, the method in the scheduling application class is called through the entry application class.

[0093] When the method in the calling application is called by the entry application class, the intermediate scheduling interface is used through the scheduling application class. During the use of the intermediate scheduling interface, the method in the target application class is called through the intermediate scheduling interface.

[0094] Optionally, the object property injection module 230 is used for:

[0095] Use reflection to obtain the mBase property of the first object;

[0096] Set the value of the mBase property of the second object to the value of the mBase property of the first object.

[0097] Optionally, the object property injection module 230 is used for:

[0098] Use reflection to obtain the mLoadedApk property of the first object;

[0099] Set the value of the mLoadedApk property of the second object to the value of the mLoadedApk property of the first object.

[0100] Optionally, the apparatus further includes a request redirection module, configured to redirect a registration listener request for a registration listener attribute of the second object to the same registration listener attribute of the first object after the second object is created.

[0101] Optionally, the device further includes: a class file default loading module, used to load the entry application class, the scheduling application class, and the base application class through the system default class loader.

[0102] Optionally, the device further includes: a target application merging module, used to obtain the original application and the corresponding patch file; merge the original application and the patch file to obtain the target application; wherein the patch file is generated in the following manner:

[0103] Obtain the original application and the target application, wherein the original application includes a first executable file, a first library file and a first resource file, and the target application includes a second executable file, a second library file and a second resource file;

[0104] Generate an executable file differential package based on the first executable file and the second executable file;

[0105] Generate a library file differential package based on the first library file and the second library file;

[0106] Generate a resource file differential package based on the first resource file and the second resource file;

[0107] The executable file differential package, the library file differential package, and the resource file differential package are packaged together to generate the patch file.

[0108] This disclosure also provides a computer-readable medium having a computer program stored thereon, which, when executed by a processing device, implements the steps of the application hot update method provided in this disclosure.

[0109] This disclosure also provides an electronic device, including:

[0110] A storage device on which computer programs are stored;

[0111] A processing device is configured to execute the computer program in the storage device to implement the steps of the application hot update method provided in the embodiments of this disclosure.

[0112] The following is for reference. Figure 11 The diagram illustrates a structural schematic of an electronic device (e.g., a target terminal in an embodiment of the present disclosure) 300 suitable for implementing embodiments of the present disclosure. The terminal device in the embodiments of the present disclosure may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (personal digital assistants), tablets, PMPs (portable multimedia players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 11 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments disclosed herein.

[0113] like Figure 11 As shown, the electronic device 300 may include a processing unit (e.g., a central processing unit, a graphics processing unit, etc.) 301, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 302 or a program loaded from a storage device 308 into a random access memory (RAM) 303. The RAM 303 also stores various programs and data required for the operation of the electronic device 300. The processing unit 301, ROM 302, and RAM 303 are interconnected via a bus 304. An input / output (I / O) interface 305 is also connected to the bus 304.

[0114] Typically, the following devices can be connected to I / O interface 305: input devices 306 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 307 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 308 including, for example, magnetic tapes, hard disks, etc.; and communication devices 309. Communication device 309 allows electronic device 300 to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 11 An electronic device 300 with various devices is shown; however, it should be understood that it is not required to implement or possess all of the devices shown. More or fewer devices may be implemented or possessed alternatively.

[0115] In particular, according to embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this disclosure include a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication device 309, or installed from storage device 308, or installed from ROM 302. When the computer program is executed by processing device 301, it performs the functions defined in the methods of embodiments of this disclosure.

[0116] It should be noted that the computer-readable medium described in this disclosure can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this disclosure, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in connection with an instruction execution system, apparatus, or device. In this disclosure, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wires, optical fibers, RF (radio frequency), etc., or any suitable combination thereof.

[0117] In some implementations, the target terminal and the cloud server can communicate using any currently known or future-developed network protocol such as HTTP (Hypertext Transfer Protocol), and can be interconnected with digital data communication (e.g., a communication network) of any form or medium to enable the cloud server to distribute patch files to the target terminal. Examples of communication networks include local area networks (“LANs”), wide area networks (“WANs”), the Internet (e.g., the Internet), and end-to-end networks (e.g., ad hoc end-to-end networks), as well as any currently known or future-developed networks.

[0118] The aforementioned computer-readable medium may be included in the aforementioned electronic device; or it may exist independently and not assembled into the electronic device.

[0119] The aforementioned computer-readable medium carries one or more programs. When the electronic device executes the aforementioned one or more programs, the electronic device causes the following: it starts a target application; creates a first object and initializes the attributes of the first object, wherein the first object is an object corresponding to an entry application class; loads a target class file through a class loader, wherein the target class file includes a target application class; creates a second object and injects the initialized attributes of the first object into the second object, wherein the second object is an object corresponding to the target application class; wherein the entry application class is a class registered with the operating system, the target application class is a class not registered with the operating system, and the entry application class is used to transfer calls to its own methods by the operating system to the target application class.

[0120] Computer program code for performing the operations of this disclosure can be written in one or more programming languages ​​or a combination thereof, including but not limited to object-oriented programming languages ​​such as JAVA.

[0121] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0122] The modules described in the embodiments of this disclosure can be implemented in software or in hardware. The name of a module does not necessarily limit the module itself; for example, an object attribute injection module can also be described as "a module that creates a second object and injects the attributes of an initialized first object into the second object."

[0123] The functions described above in this document can be performed, at least in part, by one or more hardware logic components. For example, exemplary types of hardware logic components that can be used, without limitation, include: Field Programmable Gate Arrays (FPGAs), Application-Specific Integrated Circuits (ASICs), Application Standard Products (ASSPs), System-on-Chip (SoCs), Complex Programmable Logic Devices (CPLDs), and so on.

[0124] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0125] According to one or more embodiments of this disclosure, Example 1 provides an application hot update method, including:

[0126] Start the target application, create a first object and initialize the properties of the first object, where the first object is the object corresponding to the entry application class;

[0127] The target class file, including the target application class, is loaded by a class loader.

[0128] Create a second object and inject the properties of the initialized first object into the second object, wherein the second object is the object corresponding to the target application class;

[0129] The entry application class is a class registered with the operating system, while the target application class is a class not registered with the operating system. The entry application class is used to transfer the operating system's calls to its own methods to the target application class.

[0130] According to one or more embodiments of this disclosure, Example 2 provides the method of Example 1, wherein the entry application class is a subclass of the scheduling application class, the scheduling application class is a subclass of the base application class, and the target application class provides an implementation of an intermediate scheduling interface; the method further includes:

[0131] When a method in the entry application class is called by the operating system, the method in the scheduling application class is called through the entry application class.

[0132] When the method in the calling application is called by the entry application class, the intermediate scheduling interface is used through the scheduling application class. During the use of the intermediate scheduling interface, the method in the target application class is called through the intermediate scheduling interface.

[0133] According to one or more embodiments of this disclosure, Example 3 provides the method of Example 1, wherein injecting the attributes of the initialized first object into the second object includes:

[0134] Use reflection to obtain the mBase property of the first object;

[0135] Set the value of the mBase property of the second object to the value of the mBase property of the first object.

[0136] According to one or more embodiments of this disclosure, Example 4 provides the method of Example 1, wherein injecting the attributes of the initialized first object into the second object includes:

[0137] Use reflection to obtain the mLoadedApk property of the first object;

[0138] Set the value of the mLoadedApk property of the second object to the value of the mLoadedApk property of the first object.

[0139] According to one or more embodiments of this disclosure, Example 5 provides the method of Example 1, further comprising:

[0140] After the second object is created, the registration listener request for the registration listener property of the second object is redirected to the same registration listener property of the first object.

[0141] According to one or more embodiments of this disclosure, Example 6 provides the method of Example 2, further comprising:

[0142] The entry application class, the scheduling application class, and the base application class are loaded using the system default class loader.

[0143] According to one or more embodiments of this disclosure, Example 7 provides the method of Example 1, the method further comprising:

[0144] Obtain the original application and its corresponding patch files;

[0145] The original application and the patch file are merged to obtain the target application;

[0146] The patch file is generated in the following way:

[0147] Obtain the original application and the target application, wherein the original application includes a first executable file, a first library file and a first resource file, and the target application includes a second executable file, a second library file and a second resource file;

[0148] Generate an executable file differential package based on the first executable file and the second executable file;

[0149] Generate a library file differential package based on the first library file and the second library file;

[0150] Generate a resource file differential package based on the first resource file and the second resource file;

[0151] The executable file differential package, the library file differential package, and the resource file differential package are packaged together to generate the patch file.

[0152] According to one or more embodiments of this disclosure, Example 8 provides an application hot update apparatus, comprising:

[0153] The object creation and initialization module is used to start the target application, create a first object and initialize the properties of the first object, where the first object is the object corresponding to the entry application class.

[0154] A class file loading module is used to load a target class file, which includes a target application class, via a class loader.

[0155] An object property injection module is used to create a second object and inject the properties of the initialized first object into the second object, wherein the second object is an object corresponding to the target application class;

[0156] The entry application class is a class registered with the operating system, while the target application class is a class not registered with the operating system. The entry application class is used to transfer the operating system's calls to its own methods to the target application class.

[0157] According to one or more embodiments of this disclosure, Example 9 provides the apparatus of Example 8, wherein the entry application class is a subclass of a scheduling application class, the scheduling application class is a subclass of a base application class, and an implementation of an intermediate scheduling interface is provided in the target application class; it also includes a method invocation module for:

[0158] When a method in the entry application class is called by the operating system, the method in the scheduling application class is called through the entry application class.

[0159] When the method in the calling application is called by the entry application class, the intermediate scheduling interface is used through the scheduling application class. During the use of the intermediate scheduling interface, the method in the target application class is called through the intermediate scheduling interface.

[0160] According to one or more embodiments of this disclosure, Example 10 provides the apparatus of Example 8, wherein the object property injection module is configured to: obtain the mBase property of the first object by reflection; and set the value of the mBase property of the second object to the value of the mBase property of the first object.

[0161] According to one or more embodiments of this disclosure, Example 11 provides the apparatus of Example 8, wherein the object property injection module is configured to: obtain the mLoadedApk property of the first object by reflection; and set the value of the mLoadedApk property of the second object to the value of the mLoadedApk property of the first object.

[0162] According to one or more embodiments of this disclosure, Example 12 provides the apparatus of Example 8, further comprising: a request redirection module, configured to redirect a registration listener request for a registration listener attribute of the second object to the same registration listener attribute of the first object after the second object is created.

[0163] According to one or more embodiments of this disclosure, Example 13 provides an apparatus of Example 9, further comprising: a class file default loading module for loading the entry application class, the scheduling application class, and the base application class via a system default class loader.

[0164] According to one or more embodiments of this disclosure, Example 14 provides the apparatus of Example 8, further comprising: a target application merging module, configured to obtain an original application and a corresponding patch file; merge the original application and the patch file to obtain a target application; wherein the patch file is generated in the following manner:

[0165] Obtain the original application and the target application, wherein the original application includes a first executable file, a first library file and a first resource file, and the target application includes a second executable file, a second library file and a second resource file;

[0166] Generate an executable file differential package based on the first executable file and the second executable file;

[0167] Generate a library file differential package based on the first library file and the second library file;

[0168] Generate a resource file differential package based on the first resource file and the second resource file;

[0169] The executable file differential package, the library file differential package, and the resource file differential package are packaged together to generate the patch file.

[0170] According to one or more embodiments of the present disclosure, Example 15 provides a computer-readable medium having a computer program stored thereon that, when executed by a processing device, implements the steps of the method described in any of Examples 1 to 7.

[0171] According to one or more embodiments of this disclosure, Example 16 provides an electronic device comprising:

[0172] A storage device on which computer programs are stored;

[0173] A processing device for executing the computer program in the storage device to implement the steps of the method described in any of Examples 1 to 7.

[0174] The above description is merely a preferred embodiment of this disclosure and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of this disclosure is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-described concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features disclosed in this disclosure that have similar functions.

[0175] Furthermore, while the operations are described in a specific order, this should not be construed as requiring these operations to be performed in the specific order shown or in a sequential order. In certain environments, multitasking and parallel processing may be advantageous. Similarly, while several specific implementation details are included in the above discussion, these should not be construed as limiting the scope of this disclosure. Certain features described in the context of individual embodiments may also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may also be implemented individually or in any suitable sub-combination in multiple embodiments.

[0176] Although the subject matter has been described using language specific to structural features and / or methodological logic, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or actions described above. Rather, the specific features and actions described above are merely illustrative forms of implementing the claims. Regarding the apparatus in the above embodiments, the specific manner in which the various modules perform their operations has been described in detail in the embodiments relating to the method, and will not be elaborated upon here.

Claims

1. An application hot update method, characterized in that, include: Start the target application, create a first object and initialize the properties of the first object, where the first object is the object corresponding to the entry application class; The target class file, including the target application class, is loaded by a class loader. Create a second object and inject the properties of the initialized first object into the second object, wherein the second object is an object corresponding to the target application class; wherein, injecting the properties of the initialized first object into the second object includes: using reflection to obtain the initialized key properties in the first object, and setting the value of the key properties to the value of the key properties in the first object; The entry application class is a class registered with the operating system, while the target application class is a class not registered with the operating system. The entry application class is used to transfer the operating system's calls to its own methods to the target application class.

2. The method of claim 1, wherein, The entry application class is a subclass of the scheduling application class, which in turn is a subclass of the base application class. The target application class provides an implementation of the intermediate scheduling interface. The method further includes: When a method in the entry application class is called by the operating system, the method in the scheduling application class is called through the entry application class. When the method in the calling application is called by the entry application class, the intermediate scheduling interface is used through the scheduling application class. During the use of the intermediate scheduling interface, the method in the target application class is called through the intermediate scheduling interface.

3. The method of claim 1, wherein, The process of retrieving initialized key attributes from the first object using reflection and setting the value of the key attribute to the value of the key attribute of the first object includes: Use reflection to obtain the mBase property of the first object; Set the value of the mBase property of the second object to the value of the mBase property of the first object.

4. The method according to claim 1, characterized in that, The process of retrieving initialized key attributes from the first object using reflection and setting the value of the key attribute to the value of the key attribute of the first object includes: Use reflection to obtain the mLoadedApk property of the first object; Set the value of the mLoadedApk property of the second object to the value of the mLoadedApk property of the first object.

5. The method according to claim 1, characterized in that, The method further includes: After the second object is created, the registration listener request for the registration listener property of the second object is redirected to the same registration listener property of the first object.

6. The method according to claim 2, characterized in that, The method further includes: The entry application class, the scheduling application class, and the base application class are loaded using the system default class loader.

7. The method according to claim 1, characterized in that, The method further includes: Obtain the original application and its corresponding patch files; The original application and the patch file are merged to obtain the target application; The patch file is generated in the following way: Obtain the original application and the target application, wherein the original application includes a first executable file, a first library file and a first resource file, and the target application includes a second executable file, a second library file and a second resource file; Generate an executable file differential package based on the first executable file and the second executable file; Generate a library file differential package based on the first library file and the second library file; Generate a resource file differential package based on the first resource file and the second resource file; The executable file differential package, the library file differential package, and the resource file differential package are packaged together to generate the patch file.

8. An application hot update device, characterized in that, include: The object creation and initialization module is used to start the target application, create a first object and initialize the properties of the first object, where the first object is the object corresponding to the entry application class. A class file loading module is used to load a target class file, which includes a target application class, via a class loader. An object property injection module is used to create a second object and inject the properties of the initialized first object into the second object, wherein the second object is an object corresponding to the target application class; wherein, injecting the properties of the initialized first object into the second object includes: retrieving the initialized key property in the first object using reflection, and setting the value of the key property to the value of the key property of the first object; The entry application class is a class registered with the operating system, while the target application class is a class not registered with the operating system. The entry application class is used to transfer the operating system's calls to its own methods to the target application class.

9. A computer-readable medium having a computer program stored thereon, characterized in that, When executed by the processing device, the program implements the steps of the method described in any one of claims 1-7.

10. An electronic device, characterized in that, include: A storage device on which computer programs are stored; A processing device for executing the computer program in the storage device to implement the steps of the method according to any one of claims 1-7.

Images