CN110633090B

CN110633090B - Patch method, related device and system

Info

Publication number: CN110633090B
Application number: CN201910750576.2A
Authority: CN
Inventors: 任文杰; 尹永宏; 李英伟
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2019-08-14
Filing date: 2019-08-14
Publication date: 2022-04-12
Anticipated expiration: 2039-08-14
Also published as: CN110633090A; WO2021027630A9; WO2021027630A1

Abstract

The application discloses a patch method, which can dynamically load patch files in the running environment of a compiler, ensure the running efficiency, improve the speed of patch downloading and reduce the occupation of network resources. According to the method, the server can generate a dynamic differential file based on an original installation package file and a changed new installation package file, the dynamic differential file is subjected to staticizing to generate a differential file, and the differential file is sent to the electronic equipment, so that the electronic equipment can dynamically load the differential file, and the coupling relation between classes is decoupled.

Description

Patch method, related device and system

Technical Field

The present application relates to the field of computer technologies, and in particular, to a patching method, a related device, and a system.

Background

The running of the current android package (apk) is implemented on a virtual machine. Android currently executes Java code in an Android Runtime (ART) manner, and the method has a defect of low operation efficiency.

Aiming at the defect, a new compiler is produced, and the compiler can statically change the code of the apk, so that the relevant code form is machine code, and the machine code is directly run during running. The method can greatly improve the running efficiency of the code, but simultaneously sacrifices the dynamicity of the code.

That is, when the terminal detects a software update, the full amount of patches (i.e., the entire apk) need to be downloaded to update the software. This can result in slow download, network resource usage, etc.

Disclosure of Invention

The embodiment of the application provides a patch method, which can dynamically load patch files in a new compiler environment, ensure the running efficiency, improve the speed of patch downloading, and reduce the occupation of network resources.

In a first aspect, an embodiment of the present application provides a patching method, where the method is performed by an electronic device, and the method includes: the method comprises the steps that the electronic equipment receives a differential file sent by a server, wherein the differential file is a file generated based on an original installation package and a changed installation package, the differential file is a file generated according to a file changed in the original installation package, the differential file is a binary file, and the differential file comprises one or more classes; and the electronic equipment loads a target class, wherein the target class is any one of the one or more classes.

The embodiment of the application can pack the modified files into the slice dso file in the running environment of a new compiler, and the slice dso decouples the coupling relationship between classes, so that the running speed of the APP can be ensured, the downloading speed of the patch can be increased, and the occupation of network resources is reduced.

In a possible implementation manner, the loading, by the electronic device, the target class includes: loading the differential file, wherein one or more classes contained in the differential file respectively comprise relocation marks; creating a first class loader, wherein the first class loader is used for loading one or more classes contained in the differential file; under the condition of uncertain symbol link, searching the target class by adopting the first class loader; under the condition that the target class is found, removing a relocation mark contained in the target class, and updating a mapping table, wherein the mapping table contains one or more loaded classes and parameters corresponding to the classes, and the parameters corresponding to the classes comprise at least one of the following items: the file where the class is located, the class loader for loading the class, and the relocation marker of the class.

The embodiment of the present application may use the relocation flag to control dso file dynamic loading during mapping positioning.

Possibly, the differential file may also include relocation flags.

Possibly, the first type of loader described above may also include a relocation flag.

In a possible implementation manner, the loading, by the electronic device, the target class further includes: and under the condition of determining the symbol link, searching the target class by using an original class loader of the electronic equipment, wherein the original class loader of the electronic equipment is a class loader other than the first class loader.

In a possible implementation manner, after the electronic device loads the target class, the method further includes: the target class is loaded again.

In a possible implementation manner, the reloading the target class includes: detecting user operation for reloading the target class; responding to the user operation, and inquiring whether a parameter corresponding to the target class exists in a first record table; if yes, executing the function corresponding to the target class; if not, the step of loading the target class to the electronic equipment is executed again.

According to the embodiment of the application, the parameters corresponding to the loaded classes can be stored in the first record table, whether the parameters corresponding to the classes exist in the first record table is firstly inquired when the target classes are loaded again in the running period, if yes, the functions of realizing response by the classes can be directly used, and the running efficiency of the APP is improved.

In a possible implementation manner, the reloading the target class includes: detecting a segment fault instruction; and executing the step of loading the target class of the electronic equipment again based on the segment error instruction.

According to the method and the device, an exception protection mechanism is added, the trigger factor information for triggering the target class to be reloaded can be recorded after the class is passively triggered to be reloaded, and the next time of re-triggering can be avoided.

In a second aspect, an embodiment of the present application provides a patching method, which is performed by an electronic device, and includes: the method comprises the steps that electronic equipment receives a first file sent by a server, wherein the first file is generated based on an original installation package and a changed installation package, the first file is a file changed in the original installation package, the first file is a binary file, and the first file comprises one or more classes; the electronic device loads a target class, where the target class is any one of all classes included in the first file and the second file, the second file is a dynamic file, and the second file includes one or more classes.

The method and the device for repairing the problems in the electronic equipment can be suitable for a new scenario that a compiler and a JVM are in mixed operation, the problem repairing class after binarization can be issued to the electronic equipment through a small decoupled differential packet, the interpretation codes are repaired through the slice patch, and the slice patch can be not coupled with the existing interpretation codes, so that the operation rate of the APP can be guaranteed, the downloading speed of the patch can be increased, and the occupation of network resources is reduced.

In a possible implementation manner, the loading, by the electronic device, the target class includes: loading the first file by adopting a first compiler, searching whether the target class exists in one or more classes included in the first file, and loading the target class if the target class exists; and loading the second file by adopting a virtual machine, searching whether the target class exists in one or more classes included in the second file, and if so, loading the target class. Wherein the first compiler is the new compiler.

In the embodiment of the application, a new dynamic loading mechanism for compiler analysis is used for analyzing the class in the slice patch during operation, and an interpreter is used for analyzing the interpretation code for the class outside the slice patch, so that the problem on the electronic equipment side is repaired. In addition, for the apk of the dex class, the repair of the slice class is supported without performing instrumentation operation on an apk source code, namely only the repaired class is issued.

In a possible implementation manner, the loading the first file by using a first compiler, and searching whether the target class exists in one or more classes included in the first file, where if the target class exists, the loading the target class includes: loading the first file, wherein one or more classes contained in the first file respectively comprise relocation marks; creating a first class loader, wherein the first class loader is used for loading one or more classes contained in the first file; under the condition of uncertain symbol link, searching the target class by adopting the first class loader; under the condition that the target class is found, removing a relocation mark contained in the target class, and updating a mapping table, wherein the mapping table contains one or more loaded classes and parameters corresponding to the classes, and the parameters corresponding to the classes comprise at least one of the following items: the file where the class is located, the class loader where the class is loaded, and the relocation marker of the class.

Possibly, the differential file may also include relocation flags.

In a possible implementation manner, the loading the first file by using the first compiler, searching whether the target class exists in one or more classes included in the first file, and if so, loading the target class further includes: and under the condition of determining the symbol link, searching the target class by using the original class loader of the first compiler, wherein the original class loader of the first compiler is a class loader other than the first class loader.

In a possible implementation manner, the loading the first file by using the first compiler, searching whether the target class exists in one or more classes included in the first file, and after loading the target class if the target class exists, the method further includes: the target class is loaded again.

In a possible implementation manner, the reloading the target class includes: detecting user operation for reloading the target class; responding to the user operation, and inquiring whether a parameter corresponding to the target class exists in a first record table; if yes, executing the function corresponding to the target class; if not, the step of loading the first file by adopting the first compiler is executed again.

In a possible implementation manner, the reloading the target class includes: detecting a segment fault instruction; and based on the segment error instruction, executing the step of loading the first file by adopting the first compiler again.

In a third aspect, an embodiment of the present application provides a patching method, where the method is performed by a server, and the method includes: the server is based on the original installation package and the changed installation package to form a differential file, the differential file is generated according to the changed file in the original installation package, the differential file is a binary file, and the differential file comprises one or more classes; and the server transmits the difference file to the electronic equipment so that the electronic equipment loads a target class, wherein the target class is any one of the one or more classes.

The embodiment of the application can enable the electronic equipment to pack the modified files into the dso sliced files in the running environment of the new compiler, and the slice dso decouples the coupling relation between the classes, so that the running speed of the APP can be ensured, the downloading speed of the patch can be increased, and the occupation of network resources is reduced.

In a fourth aspect, an embodiment of the present application provides a patching method, where the method is performed by a server, and the method includes: the method comprises the steps that a server generates a first file based on an original installation package and a changed installation package, wherein the first file is generated according to a file changed in the original installation package, the first file is a binary file, and the first file comprises one or more classes; the server sends the first file to the electronic device so that the electronic device loads a target class, wherein the target class is any one of all classes contained in the first file and a second file, the second file is a dynamic file, and the second file comprises one or more classes.

The method and the device for repairing the problems of the electronic equipment can enable the electronic equipment to be suitable for a new scene in which a compiler and a JVM (Java virtual machine) are mixed to operate, the classes for repairing the problems after binarization can be issued to the electronic equipment through small decoupled differential packets, the interpretation codes are repaired by using the slice patches, and the slice patches can be not coupled with the existing interpretation codes, so that the operating speed of the APP can be ensured, the downloading speed of the patches can be increased, and the occupation of network resources is reduced.

In a fifth aspect, an embodiment of the present application provides an electronic device, where the electronic device includes: one or more processors, memory, receivers, transmitters; the memory, the transmitter, the receiver, and the one or more processors; the memory is configured to store a computer program code, where the computer program code includes instructions, and when the one or more processors execute the instructions, the electronic device executes a patching method provided by the first aspect of the embodiment of the present application or any implementation manner of the first aspect.

In a sixth aspect, an embodiment of the present application provides an electronic device, where the electronic device includes: one or more processors, memory, receivers, transmitters; the memory, the transmitter, the receiver, and the one or more processors; the memory is configured to store a computer program code, and the computer program code includes instructions, and when the one or more processors execute the instructions, the electronic device executes a patching method provided by the second aspect of the embodiment of the present application or any implementation manner of the second aspect.

In a seventh aspect, an embodiment of the present application provides a server, where the server includes: one or more processors, memory, receivers, transmitters; the memory, the transmitter, the receiver, and the one or more processors; the memory is configured to store computer program code, and the computer program code includes instructions, and when the one or more processors execute the instructions, the server executes the patching method provided by the third aspect of the embodiment of the present application.

In an eighth aspect, an embodiment of the present application provides a server, where the server includes: one or more processors, memory, receivers, transmitters; the memory, the transmitter, the receiver, and the one or more processors; the memory is configured to store computer program code, and the computer program code includes instructions, and when the one or more processors execute the instructions, the server executes the patching method provided by the fourth aspect of the embodiment of the present application.

In a ninth aspect, an embodiment of the present application provides a communication system, including: an electronic device and a server, wherein the electronic device may be the electronic device described in the fifth aspect, and the server may be the server described in the seventh aspect.

In a tenth aspect, an embodiment of the present application provides a communication system, including: the electronic device may be the electronic device described in the sixth aspect, and the server may be the server described in the eight aspects.

In an eleventh aspect, an embodiment of the present application provides a computer storage medium, which includes computer instructions, and when the computer instructions are executed on an electronic device, the electronic device is caused to execute a patching method as provided in the first aspect or any one implementation manner of the first aspect.

In a twelfth aspect, embodiments of the present application provide a computer storage medium, which includes computer instructions, when the computer instructions are executed on an electronic device, cause the electronic device to execute the patching method provided by the second aspect or any one of the implementation manners of the second aspect.

In a thirteenth aspect, embodiments of the present application provide a computer storage medium, which includes computer instructions, when the computer instructions are executed on a server, cause the server to execute the patching method as provided in the third aspect.

In a fourteenth aspect, embodiments of the present application provide a computer storage medium including computer instructions, which, when executed on an electronic device, cause a server to perform the patching method as provided in the fourth aspect.

In a fifteenth aspect, embodiments of the present application provide a computer program product, which when run on a computer, causes the computer to execute the patching method as provided in the first aspect or any one of the implementations of the first aspect.

In a sixteenth aspect, embodiments of the present application provide a computer program product, which when run on a computer, causes the computer to execute the patching method as provided by the second aspect or any one of the implementations of the second aspect.

In a seventeenth aspect, the present application provides a computer program product, which when run on a computer, causes the computer to execute the patching method as provided in the third aspect.

In an eighteenth aspect, embodiments of the present application provide a computer program product, which when run on a computer, causes the computer to execute the patching method as provided in the fourth aspect.

It is to be understood that the computer storage medium of the eleventh aspect or the computer program product of the fifteenth aspect provided above is used to execute the patching method provided by the first aspect. Therefore, the beneficial effects achieved by the method can refer to the beneficial effects in the corresponding method, and are not described herein again.

It is to be understood that the computer storage medium of the twelfth aspect or the computer program product of the sixteenth aspect provided above is used to execute the patching method provided by the second aspect. Therefore, the beneficial effects achieved by the method can refer to the beneficial effects in the corresponding method, and are not described herein again.

It is to be understood that the computer storage medium of the thirteenth aspect or the computer program product of the seventeenth aspect provided above is used to execute the patching method provided by the third aspect. Therefore, the beneficial effects achieved by the method can refer to the beneficial effects in the corresponding method, and are not described herein again.

It is to be understood that the computer storage medium of the fourteenth aspect or the computer program product of the eighteenth aspect provided above is used to execute the patching method provided by the fourth aspect. Therefore, the beneficial effects achieved by the method can refer to the beneficial effects in the corresponding method, and are not described herein again.

Drawings

Fig. 1 is a schematic diagram of an architecture of a communication system to which the present application relates;

FIG. 2 is a schematic diagram of a user interface for updating software using patches on the electronic device side;

FIG. 3 is a schematic diagram illustrating that a patch is used for repairing a vulnerability in an Android operating system;

FIG. 4 is a diagram illustrating a parent delegation mechanism in a conventional virtual machine operating environment;

FIG. 5 is a schematic diagram illustrating the manner in which a compiler loads classes in the present application;

FIG. 6 is a diagram illustrating the behavior of apk runtime dso in memory after compiler staticization in the present application;

FIG. 7 is a diagram illustrating dso operation in memory after dynamic load repair according to an embodiment of the present application;

fig. 8 is a schematic diagram of an dso file for generating a difference according to an embodiment of the present application;

fig. 9 is a schematic flowchart of a patching method according to an embodiment of the present application;

fig. 10 is a schematic flowchart of a process of loading a target class on an electronic device side according to an embodiment of the present application;

fig. 11 is a flowchart illustrating a detailed implementation of jni.findclass;

FIG. 12 is a flowchart illustrating a specific implementation of reloading a target class in the case of active addressing;

FIG. 13 is a flowchart illustrating a specific implementation of reloading a target class in the case of passive addressing;

FIG. 14 is a diagram illustrating how dex runs in memory during apk pre-staticizing according to the prior art;

fig. 15 is a schematic diagram illustrating a state in which the apk runtime dso and dex run in the memory after dynamic loading according to the second embodiment of the present application;

fig. 16 is a schematic loading diagram of a difference file according to a second embodiment of the present application;

fig. 17 is a schematic flowchart of loading a target class on an electronic device side according to a second embodiment of the present application;

FIG. 18 is a schematic diagram of a server according to the present application;

FIG. 19 is a schematic diagram of an electronic device provided in the present application;

fig. 20 is a schematic structural diagram of another communication system and related devices provided in the present application;

fig. 21 is a schematic diagram of a software architecture for validating a patch according to the present application.

Detailed Description

The technical solutions in the embodiments of the present application will be described in detail and clearly with reference to the accompanying drawings.

The terminology used in the following embodiments of the present application is for the purpose of describing particular embodiments only and is not intended to be limiting of the present application.

Fig. 1 illustrates a communication system to which the present application relates. As shown in fig. 1, the communication system may include a server 11 and an electronic device 13, and the electronic device 13 and the server 11 may communicate with each other through a network 12 (e.g., the internet). A software developer may generate a patch (patch) of software on the server 11. For example, patch C may be generated by comparing the differences of the new version A and the old version B. The electronic device 13 may download the patch C from the server 11 through the network 12, combine the patch C with the old version B stored locally to obtain a new version a, and finally install the new version a to upgrade the software from the old version B to the new version a.

Upon detection of a new version, the electronic device 13 may provide the user interfaces exemplarily shown in fig. 2, such as the user interface 21 to the user interface 23, in order for the user to understand the software update process. The user interface 21 may be used, among other things, to present the new version to the user, along with information about the patch, such as the version number of the new version (e.g., 9.0.0.17), the size of the patch (e.g., 5.76MB), the update log, and the version number of the current version (e.g., 9.0.0.15). The user interface 22 may be used to present the user with the download progress of the patch. The user interface 23 may be used to present the new version of the installation process to the user.

If the software already has multiple old versions, the software developer may generate patches separately for the multiple old versions. The electronic device may download the corresponding patch from an old version already in place. For example, for the new version a, the server 11 generates a plurality of patches corresponding to the old versions B1, B2, B3 respectively: patch C1, patch C2, patch C3. If the old version that the electronic device 13 has locally is B1, the electronic device 13 may download the patch C1 from the server 11 to upgrade from the old version B1 to the new version A. If the old version that the electronic device 13 has locally is B2, the electronic device 13 may download the patch C2 from the server 11 to upgrade from the old version B2 to the new version A.

Patches generated on the server 11 may be used to fix one or more software bugs or may be used to add one or more new product features or functions. For example, in the Android operating system, as shown in fig. 3, the patch C may include one or more bug fixing codes such as a fixing Application (APP), an application framework (application framework), a kernel (kernel), and a hardware driver (hardware driver). Patch C may also include implementation code for newly added product features or functionality.

Next, a parent delegation mechanism applied to a Java Virtual Machine (JVM) execution environment in the prior art is described. As shown in fig. 4, in the parent delegation mechanism, if a request for loading a class (class) is received, the system searches whether the class is loaded from the application class loader, the extended class loader, and the start class loader in sequence, and if so, the class does not need to be loaded again. If not, the system loads the class by adopting a starting class loader, an extension class loader and an application class loader in sequence. Each class loader loads classes under the corresponding directory, and the specific correspondence is shown in fig. 4. The launch class loader in FIG. 4 may be a parent class loader of the extended class loader, and the extended class loader may be a parent class loader of the application class loader. That is, the application class loader may be a child class loader of the extended class loader, and the extended class loader may be a child class loader of the startup class loader.

Next, the procedure of loading classes by the compiler in the present application is described. Hereinafter, the compiler in the present application will be simply referred to as a compiler. As shown in FIG. 5, the process of a compiler loading classes may include the following steps:

s101: dso are loaded.

S102: the compiler determines the run address into memory.

S103：loadClass()。

S104：forName()。

S105：JNI.findClass()。

Specifically, dso is a file with format dso, and a file with format dso is a file in binary format. The load dso is to load the binary file with the format of dso into the memory.

Specifically, the compiler determines the run address, i.e., the symbolic reference of a certain class, into memory.

Specifically, loadClass () is used to load the class into the compiler. Loading a class is to find the bytecode file corresponding to the class. The class obtained after loadClass () is a class that is not connected.

Specifically, forName () may be used to load and initialize a class into a compiler. Initializing the class is to perform corresponding initialization action on the class. The class resulting after forName () is the class after initialization has been completed.

Specifically, in a possible case, after S103 and S104, a class that needs to be loaded cannot be found, S105, that is, the class is found in the jni. Class bytecode, which may be specifically loaded by a subclass loader according to name or location, is then converted to class using a defineClass.

It is appreciated that the parent and child class loaders in a compiler environment may be different from the JVM runtime environment mentioned in FIG. 4. The parent class loader and child class loader shown in FIG. 4 should not be construed as limiting the present application.

The patching method provided by the application will be described in two use scenarios.

Scene one: scenario where the compiler runs.

For this scenario, the operation mode of the apk runtime dso in the memory after the staticization in the prior art is described first, and then the operation mode of the dynamic load repair dso in the memory provided in this embodiment of the present application is described.

FIG. 6 is a diagram illustrating the behavior of the apk runtime dso in memory after the compiler is statically configured. As shown in FIG. 6, the format of the statically-stated file may be. dso, and the. dso file is a binary file. dso the file may contain one or more elements (elements), each element corresponding to a class, such as class1.dso, class2.dso, class3.dso, etc., shown in FIG. 6.

Fig. 7 is a schematic diagram illustrating an operation form dso in the memory after dynamic load repair according to an embodiment of the present application. As shown in fig. 7, dso after dynamic load repair may include a difference file hot. dso and files class1.dso, class2.dso, class3.dso, etc. before dynamic load repair.

Next, a generation process of the difference file hot. Dso generation process of the differential file hotfix can be realized on the server side.

As shown in fig. 8, the server may generate a dynamic differential file hot. The dynamic differential file hot. Then, after the dynamic differential file hot.

The patching method provided by the first embodiment of the present application is described next with reference to fig. 6 to 8.

As shown in fig. 9, the patching method may include at least the following steps:

s201: the server generates a dynamic differential file based on the first file and the second file.

S202: and the server staticizes the dynamic differential file to generate a differential file.

S203: and the server sends the difference file to the electronic equipment.

S204: the electronic device loads the target class.

Specifically, the first file is the original installation package file, that is, old. The second file is the new installation package file after the change, new. The dynamic differential file is hot fix. dex in fig. 8, and the differential file is hot fix. dso in fig. 8. The specific processes of S201-S203 may refer to the description in fig. 8, which is not described herein again.

Specifically, S204 may specifically include the processes of loading the dso file into the memory, creating a class loader, loading a class, initializing a class, searching a class, and the like.

Next, how to load the target class after the electronic device receives the difference file sent by the server is described in detail.

FIG. 10 illustrates a process for an electronic device to load a target class. As shown in FIG. 10, the process of loading the target class may include at least the following steps:

s301: and loading the differential file sent by the server.

Specifically, the differential file sent by the server is a statically-stated binary file. And loading the differential file sent by the loading server into the memory.

Specifically, a relocation (relocation) flag may be added to one or more classes contained in the differential file, respectively. The relocation flag may be a variable in the mapping relationship data structure corresponding to each class in the mapping table. The mapping relationship data structure may also include other variables, such as a file corresponding to the class, a class loader to load the class, etc.

S302: a first class loader is created.

In particular, the first class loader may be used to load classes contained in the differential file described above. The target loaded by the first type loader is the path of the differential file stored in the memory.

The relocation marker is not limited to be added to one or more classes contained in the differential file, and in a specific implementation, the relocation marker may also be added to the differential file, or the relocation marker may be added to the first class loader, which is not limited in this embodiment of the present application.

S303：loadClass()。

S304：forName()。

Specifically, reference is made to the aforementioned S103-S104 in S303-S304, which are not described herein.

S305: it is determined whether symbolic linking is determined. If yes, go to step S308, otherwise, go to step S306.

In particular, a symbolic link is a symbolic reference, which is a string containing the name of the referenced content and possibly some other information about this referenced item. This information may uniquely identify a class, field, method.

After initialization, there may be two outcomes, either a deterministic symbol link or an indeterminate symbol link. S306 is performed without determining symbol concatenation, and S308 is performed with determining symbol concatenation.

S306：JNI.findClass()。

Specifically, under the condition that symbolic link is not determined, a first class loader is adopted to load the target class under the corresponding directory of the loader.

Specifically, the specific implementation steps of S306 can be seen in fig. 11. As shown in fig. 11, the step may specifically include:

s401: and searching a target class.

Specifically, the class included in the directory corresponding to the first class loader may be searched according to the name of the class.

S402: and setting the relevance of the target class.

Specifically, after the target class is found, the target class is associated with the corresponding symbol reference.

S403: the relocation flag is removed.

In particular, the relocation flag may be a variable in the data structure. After the target class is found by the first class loader, the variable can be removed, namely, the relocation mark is removed, which indicates that the target class is loaded, and the target class can be directly used next time without loading again.

S404: and updating the mapping table.

Specifically, the mapping table may include one or more loaded classes and parameters corresponding to the classes. Wherein the parameter corresponding to the class may include at least one of: the file where the class is located, a class loader for loading the class, a relocation mark of the class and the like.

Specifically, the dynamically loaded differential file hot. The hot patch scene can be divided into real-time effect and restart effect. In a real-time effective scene, the mapping table can update the mapping relationship of the existing class. In the effective restarting scene, after the APP is restarted, the previous mapping relation completely disappears, and a new mapping relation is reestablished. And the newly downloaded dso file is inserted into the forefront of the defagments, i.e. the new mapping table is completely different from the original mapping table.

Illustratively, the electronic device loads an a.dso file from which all class parse files can be obtained. In a certain service scenario, a new class needs to be resolved, which is not defined in a.dso. Which is defined in b.dso downloaded from the server at this time. Only if the b.dso file is downloaded can the code of the new class be parsed, triggering relocation of the class.

Illustratively, the electronic device loads an a.dso file and a b.dso file, the b.dso is unloaded from the element in a certain service scene, and the loading and repositioning of the new b.dso file are triggered when the electronic device accesses the class in the b.dso file again.

S307: the target class is loaded again.

Specifically, the situation of reloading the target class can be divided into two types: one is user active triggering and the other is system passive triggering. The process of reloading the target class in these two cases will be described later with reference to fig. 12 and 13, respectively, and will not be described in detail here.

S308：JNI.findClass()。

Specifically, in the case of determining symbolic links, other class loaders within the compiler, except for the first class loader, are employed to load the target class under its corresponding directory. Specifically, the target class may be loaded sequentially from the parent class loader to the corresponding directory of the child class loader.

The process of reloading the target class in the case of a user active trigger is described next with reference to fig. 12.

As shown in fig. 12, the process may include the following steps:

s501: a user action to reload the target class is detected.

Specifically, the user operation may be, but is not limited to, a touch operation on a certain control in a user interface of a certain APP.

S502: and responding to the user operation, and inquiring whether the parameters corresponding to the target class exist in the hash table.

Specifically, if the parameter corresponding to the target pair exists in the hash table, it may be determined that the target class has been loaded. If the class is determined to be loaded, the class can be directly called to execute the function corresponding to the class without reloading, and the running speed is increased. The hash table may also be referred to as a first record table. The parameter corresponding to the target class may be, for example, a file where the class is located, a class loader that loads the class, a relocation flag of the class, and the like.

S503: if not, the step of loading the differential file sent by the server is executed again.

Specifically, if it is determined that the class is not loaded, the step of loading the differential file sent by the server, i.e., S301, may be performed again.

If an exception occurs in the above process, the result of exception failure can be output.

The process of reloading the target class in the case of a passive triggering of the system is described next with reference to fig. 13.

As shown in fig. 13, the process may include the following steps:

s601: a segment fault instruction is detected.

S602: and based on the error instruction, the step of loading the differential file sent by the server is executed again.

In particular, the segment fault instruction may be an address fault triggered instruction. After S301 is executed again based on the error-interrupting instruction, the positioning information may be updated to the relocation flag, and the trigger factor information triggering reloading of the target class is recorded, so that next re-triggering may be avoided.

The embodiment of the application can pack modified files into the dso slice files in the running environment of the compiler, the slice dso decouples the coupling relation between classes, and in the mapping and positioning process, the relocation marker is used for controlling the dynamic loading of the dso files, so that the running speed of the APP can be ensured, the patch downloading speed can be increased, and the occupation of network resources is reduced.

Scene two: a scenario where a compiler runs mixed with a JVM.

For this scenario, the operation mode of dex in the memory during apk operation before the staticization in the prior art will be described first, and then the operation mode of dso loaded in the memory provided in the second embodiment of the present application will be described.

FIG. 14 is a diagram illustrating the operation of the apk runtime dex in the memory before the staticizing in the prior art. As shown in fig. 14, the file format before the staticizing may be.

Fig. 15 exemplarily shows a morphological schematic diagram that the apk runtime dso and dex run in the memory after dynamic loading according to the second embodiment of the present application. The apk runtime as shown in FIG. 15 may include a difference file hot. dso and the files before staticizing, class1.dex, class2.dex, class3.dex, etc.

The process of generating the hot fix. dso may refer to fig. 8, and is not described herein again.

Fig. 16 is a schematic view illustrating loading of a differential file according to a second embodiment. Dso may be loaded by a compiler as shown in fig. 16. Further, the files before the staticization, class1.dex, class2.dex, class3.dex, etc., may be loaded by the android virtual machine.

Next, a process of loading the target class on the electronic device side according to the second embodiment of the present application will be described with reference to the first embodiment and fig. 16.

As shown in fig. 16, the electronic device side loading the target class may include at least the following steps:

s701: whether the file is dso is judged, if yes, S702 is executed, and if not, S706 is executed.

S702: the compiler determines that the file is a hot-patch feature and does not perform symbol positioning.

S703: the compiler loads the target class.

S704: and the android virtual machine loads the target class.

Specifically, the compiler can process dso files, the processing process can include S702-S703, the android virtual machine can process non-dso files, and the processing process can include S704.

Specifically, the process of loading the target class by the compiler may refer to the related description of fig. 10 in the first embodiment, which is not described herein again.

In particular, the process of loading the target class by the android virtual machine is consistent with the prior art and is not detailed here.

The method provided by the application can be suitable for a scene in which a compiler and a JVM (JVM) are operated in a mixed mode, the class of the repair problem after binarization can be issued to the electronic equipment in a small decoupled differential packet, the interpretation code is repaired by using the slice patch, the slice patch can be not coupled with the existing interpretation code, a dynamic loading mechanism analyzed by the compiler is used for analyzing the class in the slice patch during operation, the interpretation code is analyzed by using the interpreter for the class outside the slice, and the problem on the side of the electronic equipment is repaired. In addition, for the apk of the dex class, the repair of the slice class is supported without performing instrumentation operation on an apk source code, namely only the repaired class is issued.

The related devices provided by the embodiments of the present application are described below with reference to the accompanying drawings based on the same technical concept.

Fig. 18 shows a schematic diagram of a structure of the server 60. The server 60 may be the server 11 in the communication system shown in fig. 1. As shown in fig. 18, the server 60 includes: one or more processors 601, a transmitter 607, a receiver 609, and a processor 601 and a memory 605 coupled thereto. These components may be connected by a bus 603 or otherwise, and FIG. 18 illustrates a connection by bus 603. Wherein:

transmitter 607 may be used to transmit signals output by processor 601. For example, transmitter 607 may transmit the patch generated by processor 601 to electronic device 70. For the description of the patch, reference may be made to the foregoing description, and the description is not repeated here. The receiver 609 may be used for the server 60 to receive signals transmitted by other devices (e.g., the electronic device 70), process the received signals, and output the processed signals to the processor 601. For example, the receiver 609 may receive a patch download request transmitted by the electronic device 70. In some embodiments, the transmitter 607 and the receiver 609 may be considered a wireless modem. In the server 60, the number of the transmitter 607 and the receiver 609 may be one or more.

The memory 605 is coupled to the processor 601 for storing various software programs and/or sets of instructions. In particular implementations, memory 605 may include high-speed random access memory and may also include non-volatile memory, such as one or more magnetic disk storage devices, flash memory devices, or other non-volatile solid-state storage devices. The memory 605 may store an operating system (hereinafter, referred to as a system), such as an embedded operating system like uCOS, VxWorks, RTLinux, or the like. The memory 605 may also store a network communication program that may be used to communicate with one or more additional devices, one or more terminal devices, and one or more network devices.

The processor 601 may be used to read and execute computer readable instructions. Specifically, the processor 601 may be configured to call a program stored in the memory 605, for example, an implementation program of the patch method provided by one or more embodiments of the present application on the server 60 side, and execute instructions contained in the program.

It should be noted that the server 60 shown in fig. 18 is only one implementation manner of the present application, and in practical applications, the server 60 may also include more or less components, and is not limited herein.

Fig. 19 shows a schematic structural diagram of the electronic device 70. The electronic device 70 may be the electronic device 13 in the communication system shown in fig. 1. As shown in fig. 19, the electronic device 70 may include a processor 110, an external memory interface 120, an internal memory 121, a Universal Serial Bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, an earphone interface 170D, a sensor module 180, a button 190, a motor 191, an indicator 192, a camera 193, a display screen 194, a Subscriber Identity Module (SIM) card interface 195, and the like. The sensor module 180 may include a pressure sensor 180A, a gyroscope sensor 180B, an air pressure sensor 180C, a magnetic sensor 180D, an acceleration sensor 180E, a distance sensor 180F, a proximity light sensor 180G, a fingerprint sensor 180H, a temperature sensor 180J, a touch sensor 180K, an ambient light sensor 180L, a bone conduction sensor 180M, and the like.

It is to be understood that the illustrated structure of the embodiment of the present invention does not specifically limit the electronic device 70. In other embodiments of the present application, the electronic device 70 may include more or fewer components than shown, or combine certain components, or split certain components, or a different arrangement of components. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

Processor 110 may include one or more processing units, such as: the processor 110 may include an Application Processor (AP), a modem processor, a Graphics Processing Unit (GPU), an Image Signal Processor (ISP), a controller, a video codec, a Digital Signal Processor (DSP), a baseband processor, and/or a neural-Network Processing Unit (NPU), etc. The different processing units may be separate devices or may be integrated into one or more processors.

The controller can generate an operation control signal according to the instruction operation code and the timing signal to complete the control of instruction fetching and instruction execution.

A memory may also be provided in processor 110 for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory. The memory may hold instructions or data that have just been used or recycled by the processor 110. If the processor 110 needs to reuse the instruction or data, it can be called directly from the memory. Avoiding repeated accesses reduces the latency of the processor 110, thereby increasing the efficiency of the system.

In some embodiments, processor 110 may include one or more interfaces. The interface may include an integrated circuit (I2C) interface, an integrated circuit built-in audio (I2S) interface, a Pulse Code Modulation (PCM) interface, a universal asynchronous receiver/transmitter (UART) interface, a Mobile Industry Processor Interface (MIPI), a general-purpose input/output (GPIO) interface, a Subscriber Identity Module (SIM) interface, and/or a Universal Serial Bus (USB) interface, etc.

The I2C interface is a bi-directional synchronous serial bus that includes a serial data line (SDA) and a Serial Clock Line (SCL). In some embodiments, processor 110 may include multiple sets of I2C buses. The processor 110 may be coupled to the touch sensor 180K, the charger, the flash, the camera module 193, etc. through different I2C bus interfaces. For example: the processor 110 may be coupled to the touch sensor 180K via an I2C interface, such that the processor 110 and the touch sensor 180K communicate via an I2C bus interface to implement the touch functionality of the electronic device 70.

The I2S interface may be used for audio communication. In some embodiments, processor 110 may include multiple sets of I2S buses. The processor 110 may be coupled to the audio module 170 via an I2S bus to enable communication between the processor 110 and the audio module 170. In some embodiments, the audio module 170 may communicate audio signals to the wireless communication module 160 via the I2S interface, enabling answering of calls via a bluetooth headset.

The PCM interface may also be used for audio communication, sampling, quantizing and encoding analog signals. In some embodiments, the audio module 170 and the wireless communication module 160 may be coupled by a PCM bus interface. In some embodiments, the audio module 170 may also transmit audio signals to the wireless communication module 160 through the PCM interface, so as to implement a function of answering a call through a bluetooth headset. Both the I2S interface and the PCM interface may be used for audio communication.

The UART interface is a universal serial data bus used for asynchronous communications. The bus may be a bidirectional communication bus. It converts the data to be transmitted between serial communication and parallel communication. In some embodiments, a UART interface is generally used to connect the processor 110 with the wireless communication module 160. For example: the processor 110 communicates with a bluetooth module in the wireless communication module 160 through a UART interface to implement a bluetooth function. In some embodiments, the audio module 170 may transmit the audio signal to the wireless communication module 160 through a UART interface, so as to realize the function of playing music through a bluetooth headset.

The MIPI interface may be used to connect the processor 110 with the peripheral devices such as the display screen 194 and the camera module 193. The MIPI interface includes a Camera Serial Interface (CSI), a Display Serial Interface (DSI), and the like. In some embodiments, the processor 110 and the camera module 193 communicate via a CSI interface to implement the camera function of the electronic device 70. The processor 110 and the display screen 194 communicate via the DSI interface to implement the display function of the electronic device 70.

The GPIO interface may be configured by software. The GPIO interface may be configured as a control signal and may also be configured as a data signal. In some embodiments, a GPIO interface may be used to connect the processor 110 with the camera module 193, the display screen 194, the wireless communication module 160, the audio module 170, the sensor module 180, and the like. The GPIO interface may also be configured as an I2C interface, an I2S interface, a UART interface, a MIPI interface, and the like.

The USB interface 130 is an interface conforming to the USB standard specification, and may specifically be a Mini USB interface, a Micro USB interface, a USB Type C interface, or the like. The USB interface 130 may be used to connect a charger to charge the electronic device 70, and may also be used to transmit data between the electronic device 70 and peripheral devices. And the earphone can also be used for connecting an earphone and playing audio through the earphone. The interface may also be used to connect other electronic devices, such as AR devices and the like.

It should be understood that the connection relationship between the modules according to the embodiment of the present invention is only illustrative, and is not limited to the structure of the electronic device 70. In other embodiments of the present application, the electronic device 70 may also adopt different interface connection manners or a combination of multiple interface connection manners in the above embodiments.

The charging management module 140 is configured to receive charging input from a charger. The charger may be a wireless charger or a wired charger. In some wired charging embodiments, the charging management module 140 may receive charging input from a wired charger via the USB interface 130. In some wireless charging embodiments, the charging management module 140 may receive a wireless charging input through a wireless charging coil of the electronic device 70. The charging management module 140 may also supply power to the electronic device through the power management module 141 while charging the battery 142.

The power management module 141 is used to connect the battery 142, the charging management module 140 and the processor 110. The power management module 141 receives input from the battery 142 and/or the charge management module 140, and supplies power to the processor 110, the internal memory 121, the display 194, the camera 193, the wireless communication module 160, and the like. The power management module 141 may also be used to monitor parameters such as battery capacity, battery cycle count, battery state of health (leakage, impedance), etc. In some other embodiments, the power management module 141 may also be disposed in the processor 110. In other embodiments, the power management module 141 and the charging management module 140 may be disposed in the same device.

The wireless communication function of the electronic device 70 may be implemented by the antenna 1, the antenna 2, the mobile communication module 150, the wireless communication module 160, a modem processor, a baseband processor, and the like.

The

antennas

1 and 2 are used for transmitting and receiving electromagnetic wave signals. Each antenna in the electronic device 70 may be used to cover a single or multiple communication bands. Different antennas can also be multiplexed to improve the utilization of the antennas. For example: the antenna 1 may be multiplexed as a diversity antenna of a wireless local area network. In other embodiments, the antenna may be used in conjunction with a tuning switch.

The mobile communication module 150 may provide a solution including 2G/3G/4G/5G wireless communication applied on the electronic device 70. The mobile communication module 150 may include at least one filter, a switch, a power amplifier, a Low Noise Amplifier (LNA), and the like. The mobile communication module 150 may receive the electromagnetic wave from the antenna 1, filter, amplify, etc. the received electromagnetic wave, and transmit the electromagnetic wave to the modem processor for demodulation. The mobile communication module 150 may also amplify the signal modulated by the modem processor, and convert the signal into electromagnetic wave through the antenna 1 to radiate the electromagnetic wave. In some embodiments, at least some of the functional modules of the mobile communication module 150 may be disposed in the processor 110. In some embodiments, at least some of the functional modules of the mobile communication module 150 may be disposed in the same device as at least some of the modules of the processor 110.

The modem processor may include a modulator and a demodulator. The modulator is used for modulating a low-frequency baseband signal to be transmitted into a medium-high frequency signal. The demodulator is used for demodulating the received electromagnetic wave signal into a low-frequency baseband signal. The demodulator then passes the demodulated low frequency baseband signal to a baseband processor for processing. The low frequency baseband signal is processed by the baseband processor and then transferred to the application processor. The application processor outputs a sound signal through an audio device (not limited to the speaker 170A, the receiver 170B, etc.) or displays an image or video through the display screen 194. In some embodiments, the modem processor may be a stand-alone device. In other embodiments, the modem processor may be provided in the same device as the mobile communication module 150 or other functional modules, independent of the processor 110.

The wireless communication module 160 may provide a solution for wireless communication applied to the electronic device 70, including Wireless Local Area Networks (WLANs) (e.g., wireless fidelity (Wi-Fi) networks), bluetooth (bluetooth, BT), Global Navigation Satellite System (GNSS), Frequency Modulation (FM), Near Field Communication (NFC), Infrared (IR), and the like. The wireless communication module 160 may be one or more devices integrating at least one communication processing module. The wireless communication module 160 receives electromagnetic waves via the antenna 2, performs frequency modulation and filtering processing on electromagnetic wave signals, and transmits the processed signals to the processor 110. The wireless communication module 160 may also receive a signal to be transmitted from the processor 110, perform frequency modulation and amplification on the signal, and convert the signal into electromagnetic waves through the antenna 2 to radiate the electromagnetic waves.

In some embodiments, antenna 1 of electronic device 70 is coupled to mobile communication module 150 and antenna 2 is coupled to wireless communication module 160 so that electronic device 70 can communicate with networks and other devices through wireless communication techniques. The wireless communication technology may include global system for mobile communications (GSM), General Packet Radio Service (GPRS), code division multiple access (code division multiple access, CDMA), Wideband Code Division Multiple Access (WCDMA), time-division code division multiple access (time-division code division multiple access, TD-SCDMA), Long Term Evolution (LTE), LTE, BT, GNSS, WLAN, NFC, FM, and/or IR technologies, etc. The GNSS may include a Global Positioning System (GPS), a global navigation satellite system (GLONASS), a beidou navigation satellite system (BDS), a quasi-zenith satellite system (QZSS), and/or a Satellite Based Augmentation System (SBAS).

The electronic device 70 implements display functions via the GPU, the display screen 194, and the application processor. The GPU is a microprocessor for image processing, and is connected to the display screen 194 and an application processor. The GPU is used to perform mathematical and geometric calculations for graphics rendering. The processor 110 may include one or more GPUs that execute program instructions to generate or alter display information.

The display screen 194 is used to display images, video, and the like. The display screen 194 includes a display panel. The display panel may adopt a Liquid Crystal Display (LCD), an organic light-emitting diode (OLED), an active-matrix organic light-emitting diode (active-matrix organic light-emitting diode, AMOLED), a flexible light-emitting diode (FLED), a miniature, a Micro-oeld, a quantum dot light-emitting diode (QLED), and the like. In some embodiments, the electronic device 70 may include 1 or N display screens 194, with N being a positive integer greater than 1.

The electronic device 70 may implement a shooting function through the ISP, the camera 193, the video codec, the GPU, the display screen 194, the application processor, and the like.

The ISP is used to process the data fed back by the camera 193. For example, when a photo is taken, the shutter is opened, light is transmitted to the camera photosensitive element through the lens, the optical signal is converted into an electrical signal, and the camera photosensitive element transmits the electrical signal to the ISP for processing and converting into an image visible to naked eyes. The ISP can also carry out algorithm optimization on the noise, brightness and skin color of the image. The ISP can also optimize parameters such as exposure, color temperature and the like of a shooting scene. In some embodiments, the ISP may be provided in camera 193.

The camera 193 is used to capture still images or video. The object generates an optical image through the lens and projects the optical image to the photosensitive element. The photosensitive element may be a Charge Coupled Device (CCD) or a complementary metal-oxide-semiconductor (CMOS) phototransistor. The light sensing element converts the optical signal into an electrical signal, which is then passed to the ISP where it is converted into a digital image signal. And the ISP outputs the digital image signal to the DSP for processing. The DSP converts the digital image signal into image signal in standard RGB, YUV and other formats. In some embodiments, the electronic device 70 may include 1 or N cameras 193, N being a positive integer greater than 1.

The digital signal processor is used for processing digital signals, and can process digital image signals and other digital signals. For example, when the electronic device 70 selects a frequency bin, the digital signal processor is used to perform fourier transform or the like on the frequency bin energy.

Video codecs are used to compress or decompress digital video. The electronic device 70 may support one or more video codecs. In this way, the electronic device 70 may play or record video in a variety of encoding formats, such as: moving Picture Experts Group (MPEG) 1, MPEG2, MPEG3, MPEG4, and the like.

The NPU is a neural-network (NN) computing processor that processes input information quickly by using a biological neural network structure, for example, by using a transfer mode between neurons of a human brain, and can also learn by itself continuously. Applications such as intelligent recognition of the electronic device 70 can be realized through the NPU, for example: image recognition, face recognition, speech recognition, text understanding, and the like.

The external memory interface 120 may be used to connect an external memory card, such as a Micro SD card, to extend the memory capability of the electronic device 70. The external memory card communicates with the processor 110 through the external memory interface 120 to implement a data storage function. For example, files such as music, video, etc. are saved in an external memory card.

The internal memory 121 may be used to store computer executable program code, which includes instructions. The internal memory 121 may include a program storage area and a data storage area. The storage program area may store an operating system, an application program (such as a sound playing function, an image playing function, etc.) required by at least one function, and the like. The data storage area may store data created during use of the electronic device 70 (e.g., audio data, phone book, etc.), and the like. In addition, the internal memory 121 may include a high-speed random access memory, and may further include a nonvolatile memory, such as at least one magnetic disk storage device, a flash memory device, a universal flash memory (UFS), and the like. The processor 110 executes various functional applications of the electronic device 70 and data processing by executing instructions stored in the internal memory 121 and/or instructions stored in a memory provided in the processor.

The electronic device 70 may implement audio functions via the audio module 170, the speaker 170A, the receiver 170B, the microphone 170C, the headphone interface 170D, and the application processor. Such as music playing, recording, etc.

The audio module 170 is used to convert digital audio information into an analog audio signal output and also to convert an analog audio input into a digital audio signal. The audio module 170 may also be used to encode and decode audio signals. In some embodiments, the audio module 170 may be disposed in the processor 110, or some functional modules of the audio module 170 may be disposed in the processor 110.

The speaker 170A, also called a "horn", is used to convert the audio electrical signal into an acoustic signal. The electronic apparatus 70 can listen to music through the speaker 170A, or listen to a handsfree call.

The receiver 170B, also called "earpiece", is used to convert the electrical audio signal into an acoustic signal. When the electronic device 70 receives a call or voice information, it can receive voice by placing the receiver 170B close to the ear of the person.

The microphone 170C, also referred to as a "microphone," is used to convert sound signals into electrical signals. When making a call or transmitting voice information, the user can input a voice signal to the microphone 170C by speaking the user's mouth near the microphone 170C. The electronic device 70 may be provided with at least one microphone 170C. In other embodiments, the electronic device 70 may be provided with two microphones 170C to achieve noise reduction functions in addition to collecting sound signals. In other embodiments, the electronic device 70 may further include three, four or more microphones 170C to collect sound signals, reduce noise, identify sound sources, perform directional recording, and so on.

The headphone interface 170D is used to connect a wired headphone. The headset interface 170D may be the USB interface 130, or may be a 3.5mm open mobile electronic device platform (OMTP) standard interface, a cellular telecommunications industry association (cellular telecommunications industry association of the USA, CTIA) standard interface.

The pressure sensor 180A is used for sensing a pressure signal, and converting the pressure signal into an electrical signal. In some embodiments, the pressure sensor 180A may be disposed on the display screen 194.

The gyro sensor 180B may be used to determine the motion attitude of the electronic device 70. In some embodiments, the angular velocity of electronic device 70 about three axes (i.e., the x, y, and z axes) may be determined by gyroscope sensor 180B. The gyro sensor 180B may be used for photographing anti-shake. Illustratively, when the shutter is pressed, the gyro sensor 180B detects a shake angle of the electronic device 70, calculates a distance to be compensated for by the lens module according to the shake angle, and allows the lens to counteract the shake of the electronic device 70 through a reverse movement, thereby achieving anti-shake. The gyroscope sensor 180B may also be used for navigation, somatosensory gaming scenes.

The air pressure sensor 180C is used to measure air pressure.

The magnetic sensor 180D includes a hall sensor. The electronic device 70 may detect the opening and closing of the flip holster using the magnetic sensor 180D.

The acceleration sensor 180E can detect the magnitude of acceleration of the electronic device 70 in various directions (typically three axes). The magnitude and direction of gravity can be detected when the electronic device 70 is stationary. The method can also be used for recognizing the posture of the electronic equipment, and is applied to horizontal and vertical screen switching, pedometers and other applications.

A distance sensor 180F for measuring a distance. The electronic device 70 may measure the distance by infrared or laser.

The proximity light sensor 180G may include, for example, a Light Emitting Diode (LED) and a light detector, such as a photodiode. The electronic device 70 can utilize the proximity light sensor 180G to detect that the user holds the electronic device 70 close to the ear for talking, so as to automatically turn off the screen to achieve the purpose of saving power. The proximity light sensor 180G may also be used in a holster mode, a pocket mode automatically unlocks and locks the screen.

The ambient light sensor 180L is used to sense the ambient light level. The electronic device 70 may adaptively adjust the brightness of the display screen 194 based on the perceived ambient light level. The ambient light sensor 180L may also be used to automatically adjust the white balance when taking a picture. The ambient light sensor 180L may also cooperate with the proximity light sensor 180G to detect whether the electronic device 70 is in a pocket to prevent inadvertent contact.

The fingerprint sensor 180H is used to collect a fingerprint. The electronic device 70 may utilize the collected fingerprint characteristics to unlock the fingerprint, access the application lock, take a photograph of the fingerprint, answer an incoming call with the fingerprint, and so on.

The temperature sensor 180J is used to detect temperature.

The touch sensor 180K is also called a "touch device". The touch sensor 180K may be disposed on the display screen 194, and the touch sensor 180K and the display screen 194 form a touch screen, which is also called a "touch screen". The touch sensor 180K is used to detect a touch operation applied thereto or nearby. The touch sensor can communicate the detected touch operation to the application processor to determine the touch event type. Visual output associated with the touch operation may be provided through the display screen 194. In other embodiments, the touch sensor 180K may be disposed on a surface of the electronic device 70 at a different position than the display screen 194.

The bone conduction sensor 180M may acquire a vibration signal.

The keys 190 include a power-on key, a volume key, and the like. The keys 190 may be mechanical keys. Or may be touch keys. The electronic device 70 may receive a key input, and generate a key signal input related to user setting and function control of the electronic device 70.

The motor 191 may generate a vibration cue. The motor 191 may be used for incoming call vibration cues, as well as for touch vibration feedback.

Indicator 192 may be an indicator light that may be used to indicate a state of charge, a change in charge, or a message, missed call, notification, etc.

The SIM card interface 195 is used to connect a SIM card. The SIM card can be brought into and out of contact with the electronic device 70 by being inserted into the SIM card interface 195 or by being pulled out of the SIM card interface 195.

The electronic device 70 may display a user interface for downloading patches and updating software, as exemplarily shown in fig. 2, via the display screen 194. The electronic device 70 may detect a touch operation in each user interface through the touch sensor 180K, such as a click operation in each user interface (e.g., a touch operation on an icon, a double-click operation), an upward or downward sliding operation in each user interface, or an operation of performing a circle-making gesture, and so on. In some embodiments, the electronic device 70 may detect a motion gesture performed by the user holding the electronic device 70, such as shaking the electronic device, through the gyroscope sensor 180B, the acceleration sensor 180E, and so on. In some embodiments, the electronic device 70 may detect the non-touch gesture operation through the camera module 193 (e.g., 3D camera, depth camera).

The electronic device 70 may download the patch from the server 60 through the mobile communication module 150 or the wireless communication module 160 to update the software.

Referring to fig. 20, fig. 20 shows a wireless communication system 100 according to an embodiment of the present application, and a server 80 and an electronic device 90 in the wireless communication system 100. The server 80 may be the server in the foregoing method embodiment, and the electronic device 90 may be the electronic device in the foregoing method embodiment. The server 80 may comprise means or functions for performing the functions referred to by the server in the above-described method embodiments. The electronic device 90 may comprise means or functions related to the electronic device (means) for performing the above-described method embodiments. The aforementioned functions or modules or units or means (means) may be implemented by software, or by hardware executing corresponding software.

As shown in fig. 20, the server 80 may include: a communication unit 801 and a processing unit 803. Wherein:

the processing unit 803 may be configured to generate a difference file based on the original installation package and the changed installation package. The differential file is a file generated according to a file changed in an original installation package, the differential file is a binary file, and the differential file comprises one or more classes.

The communication unit 801 may be configured to send the difference file to the electronic device 90 to enable the electronic device 90 to load a target class, where the target class is any one of one or more classes in the difference file.

As shown in fig. 20, the electronic device 90 may include: a communication unit 901 and a processing unit 903. Wherein:

the communication unit 901 may be configured to receive the differential file sent by the server 80, and reference may be specifically made to the description of S203, which is not described herein again.

The processing unit 903 may be configured to load a target class, where the target class is any one of the one or more classes, and refer to the related description of S204 specifically, which is not described herein again.

Referring to fig. 21, fig. 21 is a software architecture for validating a patch provided by an embodiment of the present application, and a server and an electronic device in the software architecture. The server may be the server in the foregoing method embodiment, and the electronic device may be the electronic device in the foregoing method embodiment. The server may comprise means or functions for performing the functions referred to by the server in the above-described method embodiments. The electronic device may comprise means or functions related to the electronic device for performing the above described method embodiments. The aforementioned functions or modules or units or means (means) may be implemented by software, or by hardware executing corresponding software.

As shown in fig. 21, the server may include a patch capture tool, a patch archive, and a patch release. Wherein:

the patch package shooting tool is a script operated by the server background, and packs the patch files into a compressed file, and the overall layout of each file in the compressed file is peculiar to the patch package.

And the patch package filing is used for placing the patch package to a specified filing address after the patch package is taken out by the patch taking tool, and is used for obtaining the patch package by a subsequent server.

And the patch package release is used for the server to issue the patch file to the electronic equipment.

The electronic device may include patch package download, a patch engine, patch package upgrade, and patch partitioning. Wherein:

the patch package is downloaded to receive the patch file issued by the server.

The patch package upgrading refers to the operation that after a user searches for a patch package on a mobile phone and confirms that the user agrees to download the patch package, a patch engine downloads, verifies and installs the patch package.

The patch engine encapsulates business logic of various types of patches, including the functions of checking patch files, enabling the patches to take effect, cancelling abnormal patches and the like.

The patch partition is an address space on the hard disk of the electronic equipment, and the binary patch image in the patch package can be burned into the partition.

An embodiment of the present application also provides a computer-readable storage medium including one or more program codes, the one or more programs including instructions, which when executed by a processor in a server, the server performs the server-side patching method described in the above embodiment.

An embodiment of the present application also provides a computer-readable storage medium including one or more program codes, the one or more programs including instructions, which when executed by a processor in an electronic device, cause the electronic device to perform the patch method on the electronic device side described in the above-mentioned embodiment.

An embodiment of the present application also provides a computer program product comprising computer executable instructions stored in a computer readable storage medium; the computer executable instructions may be read by at least one processor of the server from a computer readable storage medium, and execution of the computer executable instructions by the at least one processor causes the server to implement the server-side patching method described in the above embodiments.

An embodiment of the present application also provides a computer program product comprising computer executable instructions stored in a computer readable storage medium; the at least one processor of the electronic device may read the computer executable instructions from the computer readable storage medium, and the execution of the computer executable instructions by the at least one processor causes the electronic device to implement the patch method on the electronic device side described in the above embodiments.

In the above embodiments, all or part of the implementation may be realized by software, hardware, firmware or any combination thereof. When implemented using a software program, may take the form of a computer program product, either entirely or partially. The computer program product includes one or more computer instructions. When loaded and executed on a computer, cause the processes or functions described in accordance with the embodiments of the application to occur, in whole or in part.

The computer may be a general purpose computer, a special purpose computer, a network of computers, or other programmable device. The computer instructions may be stored in a computer readable storage medium or transmitted from one computer readable storage medium to another, for example, from one website site, computer, server, or data center to another website site, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, Digital Subscriber Line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.). The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device, such as a server, a data center, etc., that incorporates one or more of the available media. The usable medium may be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid state disk (ssd)), among others.

Through the above description of the embodiments, it is clear to those skilled in the art that, for convenience and simplicity of description, the foregoing division of the functional modules is merely used as an example, and in practical applications, the above function distribution may be completed by different functional modules according to needs, that is, the internal structure of the device may be divided into different functional modules to complete all or part of the above described functions.

In the several embodiments provided in the present application, it should be understood that the disclosed apparatus and method may be implemented in other ways. For example, the above-described device embodiments are merely illustrative, and for example, the division of the modules or units is only one logical functional division, and there may be other divisions when actually implemented, for example, a plurality of units or components may be combined or may be integrated into another device, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or units, and may be in an electrical, mechanical or other form.

The units described as separate parts may or may not be physically separate, and parts displayed as units may be one physical unit or a plurality of physical units, that is, may be located in one place, or may be distributed in a plurality of different places. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment.

In addition, functional units in the embodiments of the present application may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into one unit. The integrated unit can be realized in a form of hardware, and can also be realized in a form of a software functional unit.

The integrated unit, if implemented in the form of a software functional unit and sold or used as a stand-alone product, may be stored in a readable storage medium. Based on such understanding, the technical solutions of the embodiments of the present application may be essentially or partially contributed to by the prior art, or all or part of the technical solutions may be embodied in the form of a software product, where the software product is stored in a storage medium and includes several instructions to enable a device (which may be a single chip, a chip, or the like) or a processor (processor) to execute all or part of the steps of the methods described in the embodiments of the present application. And the aforementioned storage medium includes: various media capable of storing program codes, such as a usb disk, a removable hard disk, a Read-only memory (ROM), a Random Access Memory (RAM), a magnetic disk, or an optical disk.

The above description is only an embodiment of the present application, but the scope of the present application is not limited thereto, and any changes or substitutions within the technical scope of the present disclosure should be covered by the scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims

1. A patching method, the method comprising:

the electronic equipment receives a differential file in a format of dso sent by a server, wherein the differential file is a file generated based on an original installation package and a changed installation package, the differential file is a file generated according to a file changed in the original installation package, the differential file is a binary file, and the differential file comprises one or more classes;

the electronic equipment loads a target class, wherein the target class is any one of the one or more classes; the electronic equipment loads the target class and comprises the following steps: loading the differential file, wherein one or more classes contained in the differential file respectively comprise relocation marks; creating a first class loader for loading one or more classes contained in the difference file.

2. The method of claim 1, wherein the electronic device loading a target class further comprises:

under the condition of uncertain symbol linkage, searching the target class by adopting the first class loader;

under the condition that the target class is found, removing a relocation mark contained in the target class, and updating a mapping table, wherein the mapping table contains one or more loaded classes and parameters corresponding to the classes, and the parameters corresponding to the classes comprise at least one of the following items: the file where the class is located, a class loader for loading the class, and a relocation marker for the class.

3. The method of claim 2, wherein the electronic device loading a target class further comprises:

and under the condition that the symbol link is determined, searching the target class by adopting an original class loader of the electronic equipment, wherein the original class loader of the electronic equipment is other class loaders except the first class loader.

4. The method of any of claims 1-3, wherein after the electronic device loads the target class, the method further comprises: the target class is loaded again.

5. The method of claim 4, wherein said reloading said target class comprises:

detecting a user operation for reloading the target class;

responding to the user operation, and inquiring whether a parameter corresponding to the target class exists in a first record table;

if yes, executing the function corresponding to the target class;

if not, the step of loading the electronic equipment into the target class is executed again.

6. The method of claim 4, wherein said reloading said target class comprises:

detecting a segment fault instruction;

and based on the section error instruction, the step of loading the target class by the electronic equipment is executed again.

7. A patching method, the method comprising:

the method comprises the steps that electronic equipment receives a first file sent by a server, wherein the first file is generated based on an original installation package and a changed installation package, the first file is a file changed in the original installation package, the first file is a binary file, and the first file comprises one or more classes;

the electronic equipment loads a target class, wherein the target class is any one of all classes contained in the first file and the second file, the second file is a dynamic file and comprises one or more classes, and the server generates a differential file in a format of dso based on the first file and the second file; the electronic equipment loads the target class and comprises the following steps: loading the first file by adopting a first compiler, searching whether the target class exists in one or more classes included in the first file, and loading the target class if the target class exists; the loading of the target class comprises: loading the differential file, wherein one or more classes contained in the differential file respectively comprise relocation marks; creating a first class loader for loading one or more classes contained in the difference file.

8. The method of claim 7, wherein the electronic device loading a target class further comprises:

and loading the second file by adopting a virtual machine, searching whether the target class exists in one or more classes included in the second file, and loading the target class if the target class exists.

9. The method of claim 8, wherein loading the first file with the first compiler, finding whether the target class exists in one or more classes included in the first file, and if so, loading the target class further comprises:

under the condition that the target class is found, removing a relocation mark contained in the target class, and updating a mapping table, wherein the mapping table contains one or more loaded classes and parameters corresponding to the classes, and the parameters corresponding to the classes comprise at least one of the following items: the file where the class is located, the class loader where the class is loaded, and the relocation marker for the class.

10. The method of claim 9, wherein loading the first file with the first compiler, finding whether the target class exists in one or more classes included in the first file, and if so, loading the target class further comprises: and under the condition that the symbolic link is determined, searching the target class by adopting an original class loader of the first compiler, wherein the original class loader of the first compiler is other class loaders except the first class loader.

11. The method according to any one of claims 8-10, wherein the loading the first file with the first compiler, finding whether the target class exists in one or more classes included in the first file, and after loading the target class if the target class exists, the method further comprises: the target class is loaded again.

12. The method of claim 11, wherein said reloading said target class comprises:

detecting a user operation for reloading the target class;

if yes, executing the function corresponding to the target class;

and if not, executing the step of loading the first file by adopting the first compiler again.

13. The method of claim 11, wherein said reloading said target class comprises:

detecting a segment fault instruction;

and based on the segment error instruction, executing the step of loading the first file by adopting the first compiler again.

14. A patching method, the method comprising:

the server generates a differential file in a format of dso based on an original installation package and a changed installation package, wherein the differential file is a file generated according to a file changed in the original installation package, the differential file is a binary file, and the differential file comprises one or more classes;

the server sends the difference file to the electronic equipment so as to enable the electronic equipment to load a target class, wherein the target class is any one of the one or more classes; the electronic equipment loads the target class and comprises the following steps: loading the differential file, wherein one or more classes contained in the differential file respectively comprise relocation marks; creating a first class loader for loading one or more classes contained in the difference file.

15. A patching method, the method comprising:

the method comprises the steps that a server generates a first file based on an original installation package and a changed installation package, wherein the first file is generated according to a file changed in the original installation package, the first file is a binary file, and the first file comprises one or more classes;

the server sends the first file to an electronic device so as to enable the electronic device to load a target class, wherein the target class is any one of all classes contained in the first file and a second file, the second file is a dynamic file and comprises one or more classes, and the server generates a differential file in a format of dso based on the first file and the second file; the electronic equipment loads the target class and comprises the following steps: loading the differential file, wherein one or more classes contained in the differential file respectively comprise relocation marks; creating a first class loader for loading one or more classes contained in the difference file.

16. An electronic device, characterized in that the electronic device comprises: one or more processors, memory, receivers, transmitters;

the memory, the transmitter, the receiver, and the one or more processors are coupled; the memory is configured to store computer program code comprising instructions which, when executed by the one or more processors, cause the electronic device to perform the patching method of any of claims 1-6 or claims 7-13.

17. A server, characterized in that the server comprises: one or more processors, memory, receivers, transmitters;

the memory, the transmitter, the receiver, and the one or more processors are coupled; the memory for storing computer program code comprising instructions which, when executed by the one or more processors, cause the server to perform the patching method as claimed in claim 14 or 15.

18. A computer storage medium comprising computer instructions which, when run on an electronic device, cause the electronic device to perform the patching method of any of claims 1-6 or claims 7-13.

19. A computer storage medium comprising computer instructions which, when run on a server, cause the server to perform the patching method of claim 14 or 15.