TW201500916A - Method and device for software repair - Google Patents

Abstract

A method for software repair is provided. The method includes: determining whether a major program has faults in software according to eigenvalues of the major program; if the major program has faults, acquiring a pre-backup major program and related information of the major program; repairing the major program by the pre-backup major program and the related information of the major program; and performing the repaired major program. A device for software repair is also provided.

Description

Software repair method and device

The present invention relates to computer application technology, and in particular to a software repair method and apparatus.

In the operating system platform, users are often provided with more and more functions by installing a large number of softwares, which brings great convenience to the user. At the same time, however, the user cannot run the installed software, and the installed software needs to be repaired.

The traditional software repair is realized by accessing the server through the Internet, downloading and obtaining the corresponding installation package, and it takes a lot of traffic, and the software can not be repaired without leaving the Internet. In view of this, how to carry out software repair in the case of leaving the Internet is one of the purposes of the development of this case.

In order to solve the problems of the prior art, an object of the present invention is to provide a software repair method, which includes determining whether a main program of a software is damaged according to a feature value of a main program of the software, and if so, acquiring a main program backed up by the main program and a main program. Relational message; repair the broken main program through the pre-backed main program and the relationship information of the main program; and run the repaired main program.

In an embodiment of the present invention, the software repair method further includes: if the main program of the software is not damaged according to the feature value of the main program, the main program of the software is run. formula.

In an embodiment of the present invention, the foregoing software repair method further includes: performing scan verification on the software running file through the running of the main program, obtaining an abnormal running file; and repairing the abnormal running file.

An object of the present invention is to provide a software repair device including a main program determination module, a message acquisition module, a main program repair module, and a repair operation module. The main program judging module is configured to judge whether the main program of the software is damaged according to the characteristic value of the main program of the software, and if so, notify the message acquiring module; the message obtaining module is configured to obtain the pre-backed main program and the main program. Relationship message; the main program repair module is used to repair the damaged main program through the pre-backup main program and the relationship information of the main program; the repair operation module is used to run the repaired main program.

In an embodiment of the present invention, the software repairing apparatus further includes a main program running module, configured to run the main program of the software according to the characteristic value of the main program to determine that the main program of the software is not damaged.

In an embodiment of the invention, the software repairing device further includes a scan verification module and a running file repair module. The scan verification module is configured to scan and verify the running file of the software through the running of the main program to obtain an abnormal running file; and the running file repairing module is used to repair the abnormal running file.

It is an object of the present invention to provide a computer readable storage medium storing one or more instruction segments executable by a computer such that one or more processing units perform the software repair method as described above.

The above and other objects, features and advantages of the present invention will become more <RTIgt;

10, 20, 30‧‧‧ software repair device

90‧‧‧Mobile phones

110‧‧‧Main program judgment module

130‧‧‧Message Acquisition Module

150‧‧‧Main program repair module

170‧‧‧Repair operation module

190‧‧‧Main program running module

210‧‧‧Backup module

310‧‧‧Scan verification module

311‧‧‧Feature acquisition unit

313‧‧‧Consistency judgment unit

315‧‧‧File Positioning Unit

317‧‧‧File Operations Unit

330‧‧‧Run file repair module

331‧‧‧Relational information acquisition unit

333‧‧‧Search unit

335‧‧‧Replacement unit

910‧‧‧RF circuit

920‧‧‧ memory

930‧‧‧Input unit

931‧‧‧Touch panel

932‧‧‧Other input devices

940‧‧‧Display unit

941‧‧‧ display panel

950‧‧‧ sensor

960‧‧‧Optical circuit

961‧‧‧Speaker

962‧‧‧Microphone

970‧‧‧Wireless Compatibility Certification Module

980‧‧‧ processor

990‧‧‧Power supply

S110, S130, S150, S170, S190‧‧‧ flow steps of the software repairing method in an embodiment of the present invention

S210, S230‧‧‧ flow steps of the software repairing method in an embodiment of the present invention

S211, S213, S215, S217‧‧ In the embodiment of the present invention, the running file of the software is triggered to scan and verify the running file of the software, and the process step of the abnormal running file method is obtained.

S231, S233, S235‧‧‧ Method flow steps for repairing an abnormal running file in an embodiment of the present invention

1 is a flow chart of a software repairing method according to an embodiment of the present invention; FIG. 2 is a flowchart of a software repairing method according to an embodiment of the present invention; and FIG. 3 is a running file of the software running by the running of the main program in FIG. FIG. 4 is a flowchart of a method for repairing an abnormal operation file in FIG. 2; FIG. 5 is a schematic structural diagram of a software restoration device according to an embodiment of the present invention; FIG. 7 is a schematic structural view of a software repairing apparatus according to an embodiment of the present invention; FIG. 8 is a schematic structural view of the scan verifying module of FIG. 7; FIG. FIG. 10 is a schematic structural diagram of a terminal for operating a software repairing device according to an embodiment of the present invention; FIG.

The above and other technical contents, features and advantages of the present invention will be apparent from the following detailed description of the preferred embodiments. The directional terms mentioned in the following embodiments, such as up, down, left, right, front or back, etc., are only directions referring to the additional drawings. Therefore, the directional terminology used is for the purpose of illustration and not limitation.

Please refer to FIG. 1. FIG. 1 is a flowchart of a software repairing method according to an embodiment of the present invention. In the embodiment, the software repairing method may include the following steps: Step S110: determining whether the software main program is damaged according to the feature value of the main program, and if yes, proceeding to step S130, and if no, proceeding to step S190. In this embodiment, when the software is operated by the operation of the trigger software, the feature value of the main program and the feature value corresponding to the main program stored in the local program are acquired, and then the feature value of the main program is determined and stored locally. Whether the eigenvalues of the program are consistent. If they are not consistent, the main program is not executable. The main program of the software is damaged. The main program needs to be repaired. If the main program can run, run the main program of the software directly. Step S190) is sufficient.

Step S130, acquiring a pre-backup main program and a relationship information of the main program. In this embodiment, since the main program is inoperable due to the damage of the main program, the relationship between the main program backed up locally and the main program is obtained. The relationship information of the main program will include the directory information and the installation file structure information of the main program when the software is installed. The directory information of the main program indicates where the main program is placed during installation, and the installation file is installed. The structure message is used to indicate whether the software will generate files in the main program-related directory during installation and whether the generated files need to be registered with the system.

In step S150, the damaged main program is repaired through the pre-backed main program and the relationship information of the main program. In this embodiment, according to the relationship information of the main program, the directory corresponding to the main program when the software is installed is obtained, so as to obtain the placement position of the main program when the software is installed, and the damaged main program is replaced by the placement position. The obtained pre-backed main program, at this time, the software main program will be restored to the state at the time of installation.

Step S170, running the repaired main program.

In step S190, the main program of the software is run.

In this embodiment, if it is determined that the main program of the software is not damaged, it is not necessary to perform any repair on the main program, and the main program can be directly run.

In an embodiment of the present invention, before the step S110, the method further includes: backing up the main program and the running file obtained after the installation, and the feature values and relationship information corresponding to the main program and the running file.

In this embodiment, when the software installation in the operating system platform is completed, all the initial information of the software and the relationship information are collected and stored locally to complete the backup of the software, wherein the collected data includes the main program obtained after installation and The other files that are different from the main program are the running files. The collected relationship information is the directory information and the installation file structure information generated after the installation. The directory information generated after the installation is used to indicate the directory tree structure generated after the installation. The directory tree structure can be used to know where a file is placed; the installation file structure message is used to identify which directories will generate the file, and whether the generated file needs to be registered with the system.

Referring to FIG. 2, FIG. 2 is a flowchart of a software repairing method according to an embodiment of the present invention. In the embodiment, the software repairing method further includes: Step S210: triggering a scan of the running file of the software by running the main program. Check, get an abnormal running file. In this embodiment, the running file of the software is scanned to verify whether the running file of the software is correct, and then an abnormal running file is obtained, and the abnormal running file may be damaged, missing, and redundant.

In step S230, the abnormal running file is repaired. In this embodiment, the abnormal running file is repaired through the locally backed up data and the relationship information, so that the abnormal running files obtained by the scan verification are all repaired, and the local repair of the software is realized, thereby ensuring the order of the software. The operation makes it possible for the user to successfully repair the abnormal software even if the user cannot connect to the Internet.

As shown in FIG. 3, in an embodiment of the present invention, the step S210 may include: Step S211: Acquire a feature value corresponding to the running file and a feature value backed up locally. In this embodiment, the feature value backed up locally is the feature value of the correct running file corresponding to the running file that is backed up when the software is installed, and may be the message digest value of the correct running file, for example, the hash value (HASH value). ); it can also be a value calculated by the message digest algorithm such as the size, creation date, and signature of the running file. Correspondingly, the feature value backed up locally will be the same as the feature value corresponding to the running file. That is, the feature values backed up locally and the feature values corresponding to the running file will be in the form of feature values, or may be in other forms.

In step S213, it is determined whether the feature value corresponding to the running file and the feature value backed up locally are consistent. If not, the process proceeds to step S215, and if yes, the process proceeds to step S217. In this embodiment, it is determined whether the running file is abnormal according to the feature value, that is, the feature value of the running file and the feature value corresponding to the correct running file backed up locally are consistently judged to obtain the feature value and backed up. The running file of the local correct running file corresponding to the feature value is not consistent, and the running file is an abnormal running file.

In step S215, the abnormal running file is located. In this embodiment, an abnormal running file is located in a plurality of running files, so as to directly repair the abnormal running file.

In step S217, the running file is run. In this embodiment, if there is no abnormality in the running file, the running file can be directly run without any repair.

As shown in FIG. 4, in an embodiment of the present invention, the foregoing step S230 may include: Step S231, acquiring a relationship message where an abnormal running file is located. In this embodiment, after the abnormal running file is obtained, the software of the running file that needs to be repaired in order to be sequentially run needs to be repaired. Corresponding relationship information is obtained according to the directory where the abnormal running file is located.

Step S233, searching for a local backup running file according to the relationship information. In this embodiment, since the abnormal running files are mostly damaged, missing, or redundant, the correct running files and the correct running files when the software is installed are in the same directory, that is, the abnormal running files. And the correct running file is placed in the same location, according to the relationship message will be able to locally find the running file of the local backup corresponding to the abnormal running file.

In step S235, the abnormal running file is replaced by the obtained running file. In this embodiment, the location of the abnormal running file is obtained according to the relationship information, and the abnormal running file is replaced with the found running file according to the location of the abnormal running file, thereby completing the repair of the abnormal running file.

In addition, if the running file is missing, the relationship information of the missing running file is obtained, and then the backup running file is obtained according to the directory in the relationship message, and the missing running file is restored and restored through the backup running file to make the software Even if the running file is missing, the local recovery can be smoothly performed, which ensures the smooth running of the software.

In the above software repair method, the software is monitored to obtain an abnormal main program or a running file, and an abnormal running file is identified according to the characteristic value of the local backup. The local backup is performed to repair the abnormal program or running file. You can accurately identify the abnormal main program or running file without accessing the Internet, and then repair the damaged software through local backup.

Please refer to FIG. 5. FIG. 5 is a schematic structural diagram of a software repairing apparatus according to an embodiment of the present invention. In the embodiment, the software repairing apparatus 10 includes a main program determining module 110, a message acquiring module 130, and a main program repairing module. 150. The repair operation module 170 and the main program execution module 190.

The main program determining module 110 can be configured to determine whether the main program of the software is damaged according to the feature value of the main program. If yes, notify the message obtaining module 130, and if not, notify the main program running module 190.

In this embodiment, when the software is operated by the operation of the trigger software, the main program determining module 110 acquires the feature value of the main program and the feature value corresponding to the main program stored in the local program, and then determines the feature value of the main program and Whether the eigenvalues corresponding to the main program stored in the locality are consistent. If they are not consistent, the main program is not executable. The main program of the software is damaged. The main program needs to be repaired. If the main program can be run, notify the main program. The program running module 190 can directly run the main program of the software.

The message acquisition module 130 can be used to obtain a pre-backed main program and a relationship information of the main program. In this embodiment, the main program is inoperable due to the damage of the main program, so the message acquisition module 130 will obtain the relationship information of the main program backed up locally and the main program. The relationship information of the main program will include the directory information and the installation file structure information of the main program when the software is installed. The directory information of the main program indicates where the main program is placed during installation, and the file structure is installed. The message is used to indicate whether the software will generate files in the main program-related directory during installation and whether the generated files need to be registered with the system.

The main program repair module 150 can be used to repair the damaged main program through the pre-backed main program and the relationship information of the main program. In this embodiment, the main program repair module has 150 roots. According to the relationship information of the main program, the software corresponding to the main program is installed in the directory corresponding to the main program to obtain the location of the main program when the software installation is completed, and the damaged main program is replaced with the obtained pre-backed main program according to the placement position. At this time, the main program of the software will be restored to the state at the time of installation.

The repair run module 170 can be used to run the repaired main program. The main program running module 190 is configured to run the software main program without determining that the main program of the software is not broken by triggering the operation of the software running. In this embodiment, if it is determined that the main program of the software is not damaged, no repair of the main program is required, and the main program running module 190 directly runs the main program.

Referring to FIG. 6 , in an embodiment of the present invention, the software repair device 20 may include a backup module 210 in addition to the module of the software repair device 10 , and the backup module 210 may be used for backup and installation. The main program and the run file, as well as the feature values and relationship information corresponding to the main program and the run file.

In this embodiment, when the software installation in the operating system platform is completed, the backup module 210 collects all the initial data and relationship information of the software, and stores it locally to complete the backup of the software, wherein the backup module 210 collects The data includes the main program obtained after installation and other files different from the main program, that is, the running file; the relationship information collected by the backup module 210 is the directory information and the installation file structure information generated after the installation, and is generated after the installation. The directory message is used to indicate the directory tree structure generated after installation. The directory tree structure can be used to know the location where a file is placed. The installation file structure message is used to identify which directories will generate files, and whether the generated files need to be registered with the system. .

As shown in FIG. 7 , in an embodiment of the present invention, the software repair device 30 includes a scan verification module 310 and a running file repair module 330 in addition to the module of the software repair device 20 .

The scan verification module 310 can be used to trigger a line scan verification on the running file of the software through the running of the main program, and obtain an abnormal running file. In this embodiment, the scan verification module 310 scans the running file of the software to verify whether the software running file is correct, and thus obtains An abnormal running file has occurred, and the abnormal running file may be damaged, missing, and redundant.

The run file repair module 330 can be used to repair an abnormal run file. In this embodiment, the running file repair module 330 repairs the abnormal running file through the locally backed up data and the relationship message, so that the abnormal running files obtained by the scan verification are all repaired, and the local repair of the software is realized. In addition, the sequential operation of the software is ensured, so that the user can smoothly repair the abnormal software even if the user cannot connect to the Internet.

As shown in FIG. 8, in an embodiment of the present invention, the scan verification module 310 includes a feature acquisition unit 311, a consistency determination unit 313, a file location unit 315, and a file execution unit 317.

The feature obtaining unit 311 can be configured to acquire the feature value corresponding to the running file and the feature value backed up locally. In this embodiment, the feature value backed up locally is the feature value of the correct running file corresponding to the running file that is backed up when the software is installed, and may be the message digest value of the correct running file, for example, the hash value (HASH value). ); it can also be a value calculated by the message digest algorithm such as the size, creation date, and signature of the running file. Correspondingly, the feature value backed up locally will be the same as the feature value corresponding to the running file. That is, the feature values backed up locally and the feature values corresponding to the running file will be in the form of feature values, or may be in other forms.

The consistency determining unit 313 can be configured to determine whether the feature value corresponding to the running file is consistent with the feature value backed up locally, and if not, notify the file positioning unit 315, and if so, notify the file running unit 317. In this embodiment, the consistency determining unit 313 determines whether the running file is abnormal according to the feature value, that is, performs consistency judgment on the feature value of the running file and the feature value corresponding to the correct running file backed up locally, to obtain a consistency judgment. The running file is an abnormal running file with the feature value that is inconsistent with the feature value corresponding to the correct running file stored in the local.

The file location unit 315 can be used to locate an abnormal running file. This implementation In the example, the file locating unit 315 locates an abnormal running file in a plurality of running files, so as to directly repair the abnormal running file.

The file execution unit 317 can be used to run the run file. In this embodiment, if there is no abnormality in the running file, the file running unit 317 can directly run the running file, and no repair is needed.

As shown in FIG. 9, in an embodiment of the present invention, the running file repair module 330 includes a relationship information acquiring unit 331, a searching unit 333, and a replacing unit 335.

The relationship information obtaining unit 331 can be configured to acquire a relationship message in which the abnormal running file is located. In this embodiment, after the abnormal running file is obtained, the software of the running file that needs to be repaired in order to be sequentially run needs to be repaired. The relationship information obtaining unit 331 obtains a corresponding relationship message based on the directory in which the abnormal running file is located.

The searching unit 333 can be configured to find a running file of the local backup according to the relationship information. In this embodiment, since the abnormal running files are mostly damaged, missing, or redundant, the correct running files and the correct running files when the software is installed are in the same directory, that is, the abnormal running files. And the correct running file is placed in the same location, the searching unit 333 will be able to locally find the running file of the local backup corresponding to the abnormal running file according to the relationship message.

The replacement unit 335 can be used to replace the abnormal running file to find the obtained running file. In this embodiment, the replacing unit 335 obtains the location of the abnormal running file according to the relationship message, and replaces the abnormal running file with the found running file according to the location of the abnormal running file, thereby completing the abnormal running file. repair. In addition, if the replacement unit 335 monitors that the running file is missing, the relationship information of the missing running file is obtained, and then the backup running file is obtained according to the directory in the relationship message, and the missing running file is restored and restored through the backup running file. In order to make the software recover smoothly even if the running file is missing in the software, the smooth running of the software is guaranteed.

In the above software repair device, the software is monitored to know that an abnormality has occurred. The main program or the running file identifies an abnormal running file according to the characteristic value of the local backup, and repairs the abnormal program or the running file through the local backup performed, and can accurately identify the abnormal main program without accessing the Internet path or Run the file, and then repair the damaged software through local backup.

The software repair method and device determine whether the main program of the software is damaged according to the characteristic value of the main program, and if it is determined that the main program of the software is damaged, the pre-backed main program and the relationship information of the main program are obtained, The main program of the backup and the relationship information of the main program repair the damaged main program, and finally run the repaired main program. At this time, the software can be repaired without leaving the Internet, and no traffic is required.

A person skilled in the art can understand that all or part of the process of implementing the above embodiment method can be completed by using a computer program to instruct related hardware, and the program can be stored in a computer readable storage medium. The program, when executed, may include the flow of an embodiment of the methods as described above. The storage medium may be a magnetic disk, a optical disk, a read-only memory (ROM), or a random access memory (RAM).

An embodiment of the present invention further provides a terminal for operating a software repairing device. As shown in FIG. 10, for the convenience of description, only parts related to the embodiment of the present invention are shown. For details not disclosed, refer to the present invention. Example method section. The terminal may be any terminal device including a mobile phone, a tablet computer, a PDA (Personal Digital Assistant), a POS (Point of Sales), a vehicle-mounted computer, and the terminal is a mobile phone as an example: FIG. It is a schematic structural diagram of a terminal that runs a software repairing device in an embodiment of the present invention. Referring to FIG. 10, the terminal, such as the mobile phone 90, may include: a radio frequency (RF) circuit 910, a memory 920, an input unit 930, a display unit 940, a sensor 950, an audio circuit 960, and a wireless compatibility authentication. (wireless fidelity, WiFi) module 970, processor 980, and power supply 990 and other components. Those skilled in the art can understand that the structure of the mobile phone shown in FIG. 10 does not constitute a limitation on the mobile phone, and may include more or less than the illustration. Parts, or combinations of parts, or different parts.

The following describes the components of the mobile phone in detail with reference to FIG. 10: the RF circuit 910 can be used for receiving and transmitting signals during the transmission or reception of a message or a call, and in particular, after receiving the downlink message of the base station, the processor 980 processes the signal. In addition, the design of the uplink data is sent to the base station. Generally, RF circuits include, but are not limited to, an antenna, at least one amplifier, a transceiver, a coupler, a Low Noise Amplifier (LNA), a duplexer, and the like. In addition, the RF circuit 910 can also communicate with the network and other devices via wireless communication. The above wireless communication may use any communication standard or protocol, including but not limited to Global System of Mobile communication (GSM), General Packet Radio Service (GPRS), Code Division Multiple Access (Code Division). Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), Long Term Evolution (LTE), e-mail, Short Messaging Service (SMS), and the like.

The memory 920 can be used to store software programs and modules. The processor 980 executes various software applications and data processing of the mobile phone by running software programs and modules stored in the memory 920. The memory 920 may mainly include a storage program area and a storage data area, wherein the storage program area may store an operating system, an application required for at least one function (such as a sound playing function, an image playing function, etc.); and the storage data area may be Stores data created based on the use of the phone (such as audio data, phone book, etc.). In addition, memory 920 can include high speed random access memory, and can also include non-volatile memory, such as at least one disk memory device, flash memory device, or other volatile solid state memory device.

The input unit 930 can be configured to receive an input digit or character message and to generate a key signal input related to user settings and function control of the handset 90. Specifically, the input unit 930 may include a touch panel 931 and other input devices 932. The touch panel 931, also referred to as a touch screen, can collect touch operations on or near the user (such as the user using a finger, a stylus, or the like on the touch panel 931 or touching Control panel 931 attached Near operation), and drive the corresponding connecting device according to a preset program. Optionally, the touch panel 931 can include two parts: a touch detection device and a touch controller. Wherein, the touch detection device detects the touch orientation of the user, detects a signal from the touch operation, and transmits a signal to the touch controller; the touch controller receives the touch message from the touch detection device and converts it into a contact coordinate, The processor 980 is again sent and can receive commands from the processor 980 and execute them. In addition, the touch panel 931 can be implemented in various types such as resistive, capacitive, infrared, and surface acoustic waves. In addition to the touch panel 931, the input unit 930 may also include other input devices 932. Specifically, other input devices 932 may include, but are not limited to, one or more of a physical keyboard, function keys (such as volume control buttons, switch buttons, etc.), trackballs, mice, joysticks, and the like.

The display unit 940 can be used to display a message input by the user or a message provided to the user and various function tables of the mobile phone. The display unit 940 can include a display panel 941. Alternatively, the display panel 941 can be configured in the form of a liquid crystal display (LCD), an organic light-emitting diode (OLED), or the like. Further, the touch panel 931 can cover the display panel 941. When the touch panel 931 detects a touch operation on or near the touch panel 931, the touch panel 931 transmits to the processor 980 to determine the type of the touch event, and then the processor 980 according to the touch event. The type provides a corresponding visual output on display panel 941. Although the touch panel 931 and the display panel 941 are used as two independent components to implement the input and input functions of the mobile phone in FIG. 10, in some embodiments, the touch panel 931 and the display panel 941 may be integrated. Realize the input and output functions of the phone.

The handset 90 can also include at least one sensor 950, such as a light sensor, motion sensor, and other sensors. Specifically, the light sensor may include an ambient light sensor and a proximity sensor, wherein the ambient light sensor may adjust the brightness of the display panel 941 according to the brightness of the ambient light, and the proximity sensor may move to the mobile phone to When the ear is closed, the display panel 941 and/or the backlight are turned off. As a kind of motion sensor, the accelerometer sensor can detect the magnitude of acceleration in all directions (usually three axes). When it is still, it can detect the magnitude and direction of gravity. It can be used to identify the gesture of the mobile phone (such as horizontal and vertical screen). Switching, related games, magnetometer attitude calibration), vibration recognition related work Can (such as pedometer, tap), etc.; other sensors such as gyroscopes, barometers, hygrometers, thermometers, infrared sensors, etc., which can be configured on the mobile phone, will not be described here.

The audio circuit 960, the speaker 961, and the microphone 962 can provide an audio interface between the user and the mobile phone. The audio circuit 960 can transmit the received electrical signal converted to the audio data to the speaker 961, and is converted into a sound signal output by the speaker 961. On the other hand, the microphone 962 converts the collected sound signal into an electrical signal, and the audio circuit 960 is used by the audio circuit 960. After receiving, the data is converted into audio data, and then processed by the audio data output processor 980, sent to the mobile phone 910 via the RF circuit 910, or output to the memory 920 for further processing.

WiFi is a short-range wireless transmission technology, and the mobile phone 90 can explain the user to send and receive emails, browse web pages, and access streaming media through the WiFi module 970, which provides wireless broadband Internet access for users. Although FIG. 10 shows the WiFi module 970, it can be understood that it does not belong to the essential configuration of the mobile phone 90, and may be omitted as needed within the scope of not changing the essence of the invention.

The processor 980 is a control center of the mobile phone 90. The various parts of the entire mobile phone are connected by various interfaces and lines, by running or executing software programs and/or modules stored in the memory 920, and calling the memory 920. Data, perform various functions of the mobile phone and process data to monitor the mobile phone as a whole. Optionally, the processor 980 may include one or more processing units; preferably, the processor 980 may integrate an application processor and a modem processor, where the application processor mainly processes the operating system, the user interface, and the application. Etc. The modem processor primarily handles wireless communications. It will be appreciated that the above described modem processor may also not be integrated into the processor 980.

The handset 90 also includes a power source 990 (such as a battery) that supplies power to the various components. Preferably, the power source can be logically coupled to the processor 980 via a power management system to manage charging, discharging, and power management functions through the power management system. Although not shown, the mobile phone 900 may further include a camera, a Bluetooth module, and the like, and details are not described herein.

In the embodiment of the present invention, the processor 980 included in the terminal further has the following Function: judging whether the main program of the software is damaged according to the characteristic value of the main program, if yes, acquiring the pre-backed main program and the relationship information of the main program; repairing the damaged main program through the pre-backed main program and the relationship information of the main program; Run the repaired main program. Further, by triggering the operation of the software to determine that the main program of the software is not broken, the main program of the software is run.

Further, the method further comprises: scanning and verifying the running file of the software through the running of the main program, obtaining an abnormal running file; and repairing the abnormal running file.

Further, the running of the main program is triggered to scan and verify the running file of the software, and the step of obtaining the abnormal running file includes: obtaining the feature value corresponding to the running file and the feature value backed up locally; determining the corresponding file of the running file Whether the feature value is consistent with the feature value backed up locally, and if not, the abnormal operation file is located.

Further, the step of repairing the abnormal running file includes: obtaining a relationship message of the abnormal running file; searching for the local backup running file according to the relationship message; and replacing the abnormal running file to find the obtained running file.

Further, before the step of determining whether the main program of the software is damaged by the operation of the trigger software, the method further includes: backing up the main program and the running file obtained after the installation, and the feature value and relationship information corresponding to the main program and the running file.

While the present invention has been described in its preferred embodiments, the present invention is not intended to limit the invention, and the present invention may be modified and modified without departing from the spirit and scope of the invention. The scope of protection is subject to the definition of the scope of the patent application.

S110, S130, S150, S170, S190‧‧‧ flow steps of the software repairing method in an embodiment of the present invention

Claims (13)

A software repair method includes: determining whether the main program of the software is damaged according to a characteristic value of a main program of a software, and if so, acquiring a pre-backed main program and a relationship information of the main program; The main program and the relationship information of the main program fix the broken main program; and run the repaired main program. The software repairing method according to claim 1, further comprising: running the main program of the software, if it is determined that the main program of the software is not broken according to the characteristic value of the main program. According to the software repairing method of claim 1 or 2, the method further comprises: scanning and verifying a running file of the software through the running of the main program, obtaining an abnormal running file; and repairing the abnormality Running file. According to the software repairing method of claim 3, the running file of the software is triggered to scan and verify the running file of the software, and the abnormal running file is obtained, including: obtaining the corresponding file of the running file The feature value and the feature value backed up locally; and determining whether the feature value corresponding to the running file is consistent with the feature value backed up locally, and if not, positioning the abnormal running file. According to the software repairing method of claim 3, the repairing the abnormal running file includes: obtaining a relationship message of the abnormal running file; and finding a running file of the local backup according to the relationship message; The run file that replaces the exception is the run file obtained by the lookup. The software repairing method according to the first aspect of the invention, wherein, before determining whether the main program of the software is damaged according to the characteristic value of the main program of the software, the method further comprises: backing up the main program obtained after installation and A running file, and the feature value and relationship information corresponding to the main program and the running file. A software repairing device includes: a main program judging module for judging whether a main program of the software is damaged according to a feature value of a main program of a software; and a message obtaining module, if the main program judging module judges The main program of the software is broken, and the message acquisition module is notified, and the message acquisition module is configured to acquire a pre-backed main program and a relationship information of the main program; a main program repair module is configured to The backed up main program and the relationship information of the main program fix the broken main program; and a repair running module for running the repaired main program. The software repairing device according to claim 7, further comprising: a main program running module, configured to determine, according to the characteristic value of the main program, that the main program of the software is not damaged, and run the main body of the software Program. The software repairing device of claim 7 or 8, further comprising: a scan verification module, configured to scan and scan a running file of the software through the running of the main program, to obtain a An abnormal running file; and a running file repair module for repairing the running file of the exception. The software repairing device of claim 9, wherein the scan verification module comprises: a feature acquisition unit, configured to acquire a feature value corresponding to the operation file and a feature value backed up locally; a determination unit, configured to determine whether the feature value corresponding to the running file is consistent with the feature value backed up locally; and a file positioning unit, configured to locate the running file of the abnormality, wherein, if the consistency is determined The unit determines that the feature value corresponding to the running file is inconsistent with the feature value backed up locally, and notifies the file positioning unit. According to the device of claim 9, wherein the running file repairing module comprises: a relational message acquiring unit, configured to acquire a relationship message of the abnormal running file; and a searching unit for using the relationship The message finds the running file of the local backup; and a replacement unit is used to replace the running file of the exception as the running file obtained by the search. The device of claim 7, further comprising: a backup module, configured to back up the main program and a running file obtained after the installation, and the feature values corresponding to the main program and the running file. Relationship message. A computer readable storage medium storing one or a plurality of instruction segments executable by a computer, such that one or more processing units perform the software restoration method according to any one of claims 1 to 6.