Data backup method and electronic device

Abstract

Embodiments of the present application provide a data backup method and device, the method comprising: a first device obtaining a proxy repair authorization for a second device, the proxy repair authorization being used for the first device to perform proxy repair on the second device, the second device being a device to be repaired and the second device being unable to boot; the first device backing up user data in a data partition of the second device based on the proxy repair authorization, for example, copying a data file containing the user data from the data partition of the second device, or copying a binary image of the data partition; and the first device performing proxy repair on the second device after completing backup of the user data of the second device. Thus, the probability of loss of user data in the data partition in a repair scenario can be reduced; even in the case of damage to the data partition, the user data that has not been lost can be backed up, loss of user data is reduced, and user loss is reduced.

Description

Technical Field

[0001] This application relates to the field of computers, and more specifically, to a data backup method and an electronic device. Background Technology

[0002] With the continuous development of electronic technology, mobile phones and other terminals have become indispensable smart devices in people's daily lives. Once the device malfunctions and cannot be turned on, if the user has not backed up their data beforehand, even if the system is repaired, the repaired system may be restored to factory settings, which could result in the complete loss of user data and cause serious losses to the user.

[0003] Therefore, how to back up user data when a mobile phone cannot be turned on is a technical problem that urgently needs to be solved. Summary of the Invention

[0004] This application provides a data backup method and electronic device, which reduces the probability of user data loss in data partitions during repair scenarios and reduces user losses.

[0005] In a first aspect, embodiments of this application provide a data backup method, which may include: a first device obtaining a proxy repair authorization for a second device, the proxy repair authorization being used by the first device to perform proxy repair on the second device, the second device being the device to be repaired and unable to power on; the first device backing up user data in the data partition of the second device based on the proxy repair authorization; and the first device performing proxy repair on the second device after completing the backup of the user data of the second device.

[0006] Based on the above scheme, the first device first obtains proxy repair authorization from the second device to be repaired. Based on this proxy repair authorization, the first device can back up user data in the data partition of the second device in proxy repair mode, and then perform proxy repair on the second device. Therefore, by obtaining proxy repair authorization for the second device and entering proxy repair mode, the first device completes the backup of the second device's user data, reducing the probability of user data loss during the repair process and minimizing user losses.

[0007] Optionally, the first device may obtain proxy repair authorization for the second device to be repaired in the following ways: the first device obtains proxy repair authorization for the second device to be repaired based on the trust relationship between the first device and the second device.

[0008] In the above process, when the second device is intact, the first device can establish a trust relationship with the second device. After establishing the trust relationship, the first device can obtain the first device's authorization to repair the second device. Therefore, when the second device is damaged, the first device has already obtained the authorization to repair the second device and can be used to repair the second device.

[0009] Optionally, the trust relationship between the first device and the second device may be established based on the following: the authorization information of the second device, the power-on password of the second device, and the associated accounts of the first device and the second device.

[0010] In the above process, the first device and the second device establish a trust relationship through authorization information. This authorization information can be, for example, an authorization code generated from a user-defined password, or authorization information generated based on the device's hardware information. Alternatively, the first device can also establish a trust relationship with the second device through a power-on password. This power-on password can be, for example, a facial recognition password, a fingerprint recognition password, or a numeric password. Furthermore, the first device can also establish a trust relationship through an associated account with the second device. The first and second devices can have associated accounts, or they can be two devices with associated accounts. This associated account can be, for example, bound to the same account, or a main account and a sub-account. The methods for establishing a trust relationship between the first and second devices are simple and diverse, and convenient for users to operate.

[0011] Optionally, the first device may also obtain a proxy repair authorization for the second device to be repaired by requesting a temporary proxy repair authorization for the second device from the server.

[0012] In the above process, if the second device did not establish a trust relationship with the first device before it was damaged, the first device can also obtain a proxy repair authorization for the second device by applying for temporary authorization from the server, thereby realizing the proxy repair of the second device by the first device.

[0013] Optionally, in response to a user's input, the first device sends an access request for the second device's data partition to the second device. The access request carries an access password, which is a password entered by the user, used to access the second device's data partition.

[0014] In the above process, the first device sends an access request to the second device's data partition, thereby obtaining access rights to the second device's data partition, which can be used by the first device to access the second device's data partition.

[0015] Optionally, the first device backs up the user data in the data partition of the second device, including the first device copying a data file containing the user data from the data partition of the second device.

[0016] During the above process, the first device copies data files from the user partition of the second device, thereby completing the backup of user data, preventing user data loss during the repair process, and reducing user losses.

[0017] Optionally, the first device backs up the user data in the data partition of the second device, including: the first device copies a binary image of the data partition of the second device to back up the user data, the binary image including the complete original binary data of the data partition of the second device.

[0018] During the above process, the first device copies the binary image of the data partition of the second device for backup, so that even if the data partition data file is damaged, the user data can be backed up and restored by backing up the binary image.

[0019] Optionally, the first device performs proxy repair on the second device, including: the first device obtaining an upgrade package; the first device sending the upgrade package to the second device; the first device triggering the second device to enter repair mode, whereby the upgrade package is used by the second device to perform system repair in repair mode.

[0020] During the above process, the first device obtains an upgrade package, which can be used to repair the system of the second device. The first device sends the upgrade package to the second device, triggering the second device to enter repair mode, enabling the second device to complete the system repair and reduce user losses.

[0021] Optionally, the first device performs proxy repair on the second device, including: the first device obtaining an upgrade package, which is used for system repair of the second device; the first device parsing the upgrade package to obtain a minimum repair system; the first device image the minimum repair system onto the second device; and the first device triggering the second device to enter proxy repair mode, whereby the minimum repair system is used by the second device to perform system repair in proxy repair mode.

[0022] In the above process, if the second device cannot enter the repair mode, the first device can perform proxy repair on the second device in the proxy repair mode, so that the second device can also complete the system repair of the second device through the first device even if the second device cannot enter the repair mode on its own.

[0023] Optionally, the first device obtains the upgrade package, including: the first device sending a request to the first server for the first device to authorize the proxy repair of the second device, as well as device information of the first device and the second device, the device information including a version identifier and a device identifier, to obtain an authorization file from the first server, the authorization file being used to instruct the first device to authorize the proxy repair of the second device; the first device obtaining a list of version files from the second server based on the authorization file and the device information; and the first device downloading the upgrade package from the third server based on the list of version files.

[0024] In the above process, the first device obtains the upgrade package from the third server based on the version file list, which reduces the risk of the downloaded upgrade package version being incompatible.

[0025] Optionally, the first device downloads an authentication file from the second server based on the upgrade package. The authentication file is used to authenticate the second device during system repair.

[0026] In the above process, the first device obtains the authentication file from the second server based on the downloaded upgrade package. The second server then sends the authentication file to the first device. This authentication file not only ensures the integrity and correctness of the upgrade package, but can also be used to authenticate the second device during system repair, thereby enabling system repair.

[0027] Secondly, embodiments of this application provide a data backup method, comprising: a microcontroller unit (MCU) of a second device receiving an access request from a first device, the access request being used to request access to the data partition of the second device, the access request carrying an access password, the second device being a device to be repaired, and the second device being unable to power on; the first device being a device used to perform proxy repair on the second device; the MCU of the second device requesting to read the password pre-stored in the security partition of the second device through a port between itself and the application processor (AP) of the second device; the MCU of the second device verifying the access password based on the password in the security partition; and the MCU of the second device accepting the access request from the first device if the access password is successfully verified.

[0028] Based on the above scheme, after the MCU of the second device receives the access request from the first device, it can read the password of the security partition of the second device through the port between the MCU and the AP, thereby verifying the access request. After successful verification, the second device can allow the first device to access the access, and the first device obtains access rights. The port between the MCU and the AP realizes the communication connection between the two. Through this port, the MCU can access the AP security partition, thereby enabling the first device to obtain access rights.

[0029] Thirdly, this application provides a data backup apparatus, including a processor, which is configured to execute the data backup method in the first aspect and any possible implementation thereof.

[0030] The device may further include a memory for storing instructions and data. The memory is coupled to the processor, and when the processor executes the instructions stored in the memory, it can implement the method described in the first aspect above. The device may also include a communication interface for communicating with other devices; exemplaryly, the communication interface may be a transceiver, circuit, bus, module, or other type of communication interface.

[0031] Optionally, the data backup device is an electronic device.

[0032] Optionally, the data backup device is a chip or chip system configured in an electronic device.

[0033] Fourthly, this application provides a data backup device, including an application processor (AP) and a microcontroller unit (MCU), wherein the MCU is used to execute the data backup method described in the second aspect.

[0034] Optionally, the data backup device is an electronic device.

[0035] Optionally, the data backup device is a chip or chip system configured in an electronic device.

[0036] Fifthly, this application provides a data backup apparatus for implementing the methods in the first and second aspects and any possible implementation of the first and second aspects.

[0037] In a sixth aspect, this application provides a computer-readable storage medium including instructions that, when executed on a computer, cause the computer to implement the methods of the first to second aspects and any possible implementation of the first to second aspects.

[0038] In a seventh aspect, this application provides a computer program product comprising: a computer program (also referred to as code or instructions) that, when the computer program is run, causes a computer to perform the methods of the first aspect and the second aspect, as well as any possible implementation of the first and second aspects. Attached Figure Description

[0039] Figure 1 This is a schematic diagram of the structure of an electronic device applicable to the embodiments of this application;

[0040] Figure 2 This is a schematic diagram of the specific structure of the electronic device applicable to the embodiments of this application;

[0041] Figure 3 This is a schematic flowchart of the data backup method provided in the embodiments of this application;

[0042] Figure 4 This is a schematic diagram of the electronic device communication connection for the data backup method provided in this application embodiment;

[0043] Figure 5 This is a schematic diagram of the electronic device communication connection for the data backup method provided in this application embodiment;

[0044] Figure 6 This is a schematic diagram of the electronic device connection provided in the embodiments of this application;

[0045] Figure 7 This is a user operation diagram provided in the embodiments of this application;

[0046] Figure 8 This is a schematic flowchart of the first device authorization check provided in an embodiment of this application;

[0047] Figure 9 This is a schematic diagram illustrating the backup of user data provided in an embodiment of this application;

[0048] Figure 10 This is a schematic diagram of the first device application authorization document provided in an embodiment of this application;

[0049] Figure 11 This is a schematic diagram illustrating the first device obtaining the authentication file and downloading the upgrade package according to an embodiment of this application;

[0050] Figure 12 This is a schematic diagram of the second device data block device provided in the embodiments of this application;

[0051] Figure 13 This is a schematic flowchart illustrating the system repair provided in the embodiments of this application;

[0052] Figure 14 This is a schematic flowchart illustrating the repair of a second device by a first device as provided in an embodiment of this application. Detailed Implementation

[0053] The technical solutions in this application will now be described with reference to the accompanying drawings.

[0054] The methods provided in this application can be applied to electronic devices such as mobile phones, tablets, wearable devices, in-vehicle devices, augmented reality (AR) / virtual reality (VR) devices, netbooks, personal digital assistants (PDAs), and distributed devices. This application does not limit the specific type of electronic device.

[0055] Furthermore, the methods described in this application embodiment can support operating environments such as Android operating system (OS), Harmony OS, and IoT operating systems (such as Lite OS). This application embodiment does not impose any limitations on these environments.

[0056] For example, Figure 1 A schematic diagram of the structure of the electronic device 100 is shown. For example... Figure 1 As shown, the electronic device 100 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, a headphone jack 170D, a sensor module 180, buttons 190, a motor 191, an indicator 192, a camera 193, a display screen 194, and a subscriber identification module (SIM) card interface 195, etc. The sensor module 180 may include a pressure sensor 180A, a gyroscope sensor 180B, a barometric pressure sensor 180C, a magnetic sensor 180D, an accelerometer sensor 180E, a distance sensor 180F, a proximity sensor 180G, a fingerprint sensor 180H, a temperature sensor 180J, a touch sensor 180K, an ambient light sensor 180L, a bone conduction sensor 180M, etc.

[0057] It is understood that the structure illustrated in this application does not constitute a specific limitation on the electronic device 100. In other embodiments, the electronic device 100 may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0058] Processor 110 may include one or more processing units, such as an AP, MCU, modem processor, graphics processing unit (GPU), image signal processor (ISP), controller, memory, video codec, digital signal processor (DSP), baseband processor, and neural network processing unit (NPU). Different processing units may be independent devices or integrated into one or more processors.

[0059] The application processor outputs sound signals through the audio module 170 (such as the speaker 170A) or displays images or videos through the display screen 194.

[0060] The controller can be the nerve center and command center of the electronic device 100. The controller can generate operation control signals according to the instruction opcode and timing signals to complete the control of fetching and executing instructions.

[0061] The processor 110 may also include a memory for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory. This memory can store instructions or data that the processor 110 has just used or that are used repeatedly. If the processor 110 needs to use the instruction or data again, it can retrieve it directly from the memory. This avoids repeated accesses, reduces the waiting time of the processor 110, and thus improves the efficiency of the system.

[0062] The processor 110 can execute different operations by executing instructions to achieve different functions. These instructions may be, for example, instructions pre-stored in the memory before the device leaves the factory, or instructions read from the application (APP) after the user installs a new application during use. This application embodiment does not limit them in any way.

[0063] In some embodiments, the processor 110 may include one or more interfaces. Interfaces may include an inter-integrated circuit (I2C) interface, an inter-integrated circuit sound (I2S) interface, a secure digital input and output (SDIO) interface, a pulse code modulation (PCM) interface, a universal asynchronous receiver / transmitter (UART) interface, a universal synchronous asynchronous receiver / transmitter (USART) 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.

[0064] The I2C interface is a bidirectional synchronous serial bus, including a serial data line (SDA) and a serial clock line (SCL). In some embodiments, the processor 110 may include multiple I2C buses. The processor 110 can couple to the touch sensor 180K, charger, flash, camera 193, etc., through different I2C bus interfaces. For example, the processor 110 can couple to the touch sensor 180K through the I2C interface, enabling the processor 110 and the touch sensor 180K to communicate through the I2C bus interface, thereby realizing the touch function of the electronic device 100.

[0065] The I2S interface can be used for audio communication. In some embodiments, the processor 110 may include multiple I2S buses. The processor 110 can be coupled to the audio module 170 via the I2S bus to enable communication between the processor 110 and the audio module 170. In some embodiments, the audio module 170 can transmit audio signals to the wireless communication module 160 via the I2S interface to enable the function of answering phone calls through a Bluetooth headset.

[0066] The PCM interface can 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 can be coupled via the PCM bus interface. In some embodiments, the audio module 170 can also transmit audio signals to the wireless communication module 160 via the PCM interface, enabling the function of answering phone calls through a Bluetooth headset. Both the I2S interface and the PCM interface can be used for audio communication.

[0067] The UART interface is a universal serial data bus used for asynchronous communication. This bus can be a bidirectional communication bus. It converts the data to be transmitted between serial and parallel communication. In some embodiments, the UART interface is typically used to connect the processor 110 and the wireless communication module 160. For example, the processor 110 communicates with the Bluetooth module in the wireless communication module 160 via the UART interface to implement Bluetooth functionality. In some embodiments, the audio module 170 can transmit audio signals to the wireless communication module 160 via the UART interface to enable music playback through Bluetooth headphones.

[0068] The MIPI interface can be used to connect the processor 110 to peripheral devices such as the display screen 194 and the camera 193. The MIPI interface includes a camera serial interface (CSI) and a display serial interface (DSI). In some embodiments, the processor 110 and the camera 193 communicate via the CSI interface to enable the electronic device 100 to capture images. The processor 110 and the display screen 194 communicate via the DSI interface to enable the electronic device 100 to display images.

[0069] The GPIO interface can be configured via software. It can be configured as a control signal or a data signal. In some embodiments, the GPIO interface can be used to connect the processor 110 to a camera 193, a display screen 194, a wireless communication module 160, an audio module 170, a sensor module 180, etc. The GPIO interface can also be configured as an I2C interface, an I2S interface, a UART interface, a MIPI interface, etc.

[0070] USB port 130 is a USB standard compliant interface, specifically a Mini USB port, Micro USB port, USB Type-C port, etc. USB port 130 can be used to connect a charger to charge electronic device 100, and can also be used for data transfer between electronic device 100 and peripheral devices. It can also be used to connect headphones for audio playback. This interface can also be used to connect other electronic devices, such as AR devices.

[0071] It is understood that the interface connection relationships between the modules illustrated in this application are merely illustrative and do not constitute a structural limitation on the electronic device 100. In other embodiments, the electronic device 100 may also employ different interface connection methods or combinations of multiple interface connection methods as described in the above embodiments.

[0072] The charging management module 140 receives charging input from a charger. The charger can be a wireless charger or a wired charger. In some wired charging embodiments, the charging management module 140 receives charging input from the wired charger via the USB interface 130. In some wireless charging embodiments, the charging management module 140 receives wireless charging input via the wireless charging coil of the electronic device 100. While charging the battery 142, the charging management module 140 can also supply power to the electronic device via the power management module 141.

[0073] The power management module 141 connects 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 charging management module 140, providing power to the processor 110, internal memory 121, external memory, display screen 194, camera 193, and wireless communication module 160. The power management module 141 can also monitor parameters such as battery capacity, battery cycle count, and battery health status (leakage current, impedance). In some other embodiments, the power management module 141 may be located within the processor 110. In other embodiments, the power management module 141 and the charging management module 140 may be located in the same device.

[0074] The wireless communication function of electronic device 100 can be implemented through antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, modem processor, and baseband processor.

[0075] Antenna 1 and antenna 2 are used to transmit and receive electromagnetic wave signals. Each antenna in electronic device 100 can be used to cover one or more communication frequency bands. Different antennas can also be multiplexed to improve antenna utilization. For example, antenna 1 can be multiplexed as a diversity antenna for a wireless local area network. In some other embodiments, the antennas can be used in conjunction with tuning switches.

[0076] The mobile communication module 150 can provide solutions for wireless communication, including 2G / 3G / 4G / 5G, applied to the electronic device 100. The mobile communication module 150 may include at least one filter, switch, power amplifier, low noise amplifier (LNA), etc. The mobile communication module 150 can receive electromagnetic waves via antenna 1, and perform filtering, amplification, and other processing on the received electromagnetic waves before transmitting them to a modem processor for demodulation. The mobile communication module 150 can also amplify the signal modulated by the modem processor and convert it into electromagnetic waves for radiation via antenna 1. In some embodiments, at least some functional modules of the mobile communication module 150 may be housed in the processor 110. In some embodiments, at least some functional modules of the mobile communication module 150 and at least some modules of the processor 110 may be housed in the same device.

[0077] The modem processor may include a modulator and a demodulator. The modulator modulates the low-frequency baseband signal to be transmitted into a mid-to-high frequency signal. The demodulator demodulates the received electromagnetic wave signal into a low-frequency baseband signal. The demodulator then transmits the demodulated low-frequency baseband signal to the baseband processor for processing. After processing by the baseband processor, the low-frequency baseband signal is transmitted to the application processor. The application processor outputs sound signals through an audio device (not limited to speaker 170A, receiver 170B, etc.) or displays images or videos through the display screen 194. In some embodiments, the modem processor may be a separate device. In other embodiments, the modem processor may be independent of the processor 110 and may be housed in the same device as the mobile communication module 150 or other functional modules.

[0078] The wireless communication module 160 can provide solutions for wireless communication applications on the electronic device 100, including wireless local area networks (WLANs), such as wireless fidelity (Wi-Fi), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), and infrared (IR) technologies. The wireless communication module 160 can be one or more devices integrating at least one communication processing module. The wireless communication module 160 receives electromagnetic waves via antenna 2, performs frequency modulation and filtering of the electromagnetic wave signals, and sends the processed signal to processor 110. The wireless communication module 160 can also receive signals to be transmitted from processor 110, perform frequency modulation and amplification, and convert them into electromagnetic waves for radiation via antenna 2.

[0079] In some embodiments, antenna 1 of electronic device 100 is coupled to mobile communication module 150, and antenna 2 is coupled to wireless communication module 160, enabling electronic device 100 to communicate with networks and other devices via wireless communication technology. The wireless communication technology may include Global System for Mobile Communications (GSM), General Packet Radio Service (GPRS), Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), Time-Division Code Division Multiple Access (TD-SCDMA), Long Term Evolution (LTE), 5th Generation (5G) communication system, BT, GNSS, WLAN, NFC, FM, and / or IR technologies, etc. The GNSS may include the Global Positioning System (GPS), GNSS, the BeiDou Navigation Satellite System (BDS), the Quasi-Zenith Satellite System (QZSS), and / or satellite-based augmentation systems (SBAS).

[0080] Electronic device 100 can implement display functions through a GPU, a display screen 194, and an application processor. The GPU is a microprocessor for image processing, connected to the display screen 194 and the application processor. The GPU is used to perform mathematical and geometric calculations and for graphics rendering. Processor 110 may include one or more GPUs, which execute program instructions to generate or modify display information.

[0081] The display screen 194 is used to display images, videos, etc. The display screen 194 includes a display panel. The display panel may be a liquid crystal display (LCD), an organic light-emitting diode (OLED), an active-matrix organic light-emitting diode (AMOLED), a flexible light-emitting diode (FLED), a mini LED, a micro LED, a micro-OLED, a quantum dot light-emitting diode (QLED), etc. In some embodiments, the electronic device 100 may include one or more display screens 194.

[0082] Electronic device 100 can perform shooting functions through ISP, camera 193, video codec, GPU, display 194 and application processor.

[0083] The ISP (Image Signal Processor) is used to process data fed back from the camera 193. For example, when taking a picture, the shutter is opened, and light is transmitted through the lens to the camera's photosensitive element. The light signal is converted into an electrical signal, and the camera's photosensitive element transmits the electrical signal to the ISP for processing, transforming it into an image visible to the naked eye. The ISP can also perform algorithmic optimization of image noise, brightness, and skin tone. The ISP can also optimize parameters such as exposure and color temperature of the shooting scene. In some embodiments, the ISP can be set in the camera 193.

[0084] Camera 193 is used to capture still images or videos. An object is projected onto a photosensitive element by generating an optical image through the lens. The photosensitive element can be a charge-coupled device (CCD) or a complementary metal-oxide-semiconductor (CMOS) phototransistor. The photosensitive element converts the light signal into an electrical signal, which is then passed to an ISP for conversion into a digital image signal. The ISP outputs the digital image signal to a DSP for processing. The DSP converts the digital image signal into image signals in standard RGB, YUV, or other formats. In some embodiments, the electronic device 100 may include one or more cameras 193.

[0085] Digital signal processors (DSPs) are used to process digital signals. Besides digital image signals, they can also process other digital signals. For example, when electronic device 100 selects a frequency, the DSP can perform Fourier transforms on the frequency energy.

[0086] Video codecs are used to compress or decompress digital video. Electronic device 100 may support one or more video codecs. Thus, electronic device 100 can play or record videos in various encoding formats, such as Moving Picture Experts Group (MPEG) 1, MPEG 2, MPEG 3, MPEG 4, etc.

[0087] The external storage interface 120 can be used to connect an external memory card, such as a Micro SD card, to expand the storage capacity of the electronic device 100. The external memory card communicates with the processor 110 through the external storage interface 120 to perform data storage functions. For example, music, video, and other files can be saved on the external memory card.

[0088] Internal memory 121 can be used to store computer executable program code, which includes instructions. Processor 110 executes various functional applications and data processing of electronic device 100 by running the instructions stored in internal memory 121. Internal memory 121 may include a program storage area and a data storage area. The program storage area may store the operating system, at least one application program required for a function (such as sound playback, image playback, etc.), etc. The data storage area may store data created during the use of electronic device 100 (such as audio data, phonebook, etc.). Furthermore, internal memory 121 may include high-speed random access memory and may also include non-volatile memory, such as at least one disk storage device, flash memory device, universal flash storage (UFS), etc.

[0089] Electronic device 100 can implement audio functions through audio module 170, such as speaker 170A, receiver 170B, microphone 170C, and headphone jack 170D, as well as application processor, such as music playback and recording.

[0090] The audio module 170 is used to convert digital audio information into analog audio signals for output, and also to convert analog audio input into digital audio signals. The audio module 170 can also be used for encoding and decoding audio signals. In some embodiments, the audio module 170 may be located in the processor 110, or some functional modules of the audio module 170 may be located in the processor 110.

[0091] The speaker 170A, also known as a "loudspeaker," is used to convert audio electrical signals into sound signals. The electronic device 100 can listen to music or make hands-free calls through the speaker 170A.

[0092] The receiver 170B, also known as the "earpiece," is used to convert audio electrical signals into sound signals. When the electronic device 100 answers a telephone call or voice message, the receiver 170B can be brought close to the ear to listen to the voice.

[0093] Microphone 170C, also known as a "microphone" or "voice transducer," is used to convert sound signals into electrical signals. When making a phone call or sending a voice message, the user can speak by bringing their mouth close to microphone 170C, inputting the sound signal into microphone 170C. Electronic device 100 may have at least one microphone 170C. In some embodiments, electronic device 100 may have two microphones 170C, which, in addition to collecting sound signals, can also perform noise reduction. In other embodiments, electronic device 100 may also have three, four, or more microphones 170C, which can collect sound signals, reduce noise, identify the sound source, and perform directional recording, etc.

[0094] The 170D headphone jack is used to connect wired headphones. The 170D headphone jack can be a USB 130 interface or a 3.5mm Open Mobile Terminal Platform (OMTP) standard interface, a CTIA (Cellular Telecommunications Industry Association of the USA) standard interface.

[0095] Button 190 includes a power button, volume buttons, etc. Button 190 can be a mechanical button or a touch button. Electronic device 100 can receive button input and generate key signal inputs related to user settings and function control of electronic device 100. For example, in this embodiment, the user can realize the screen sleep and screen wake-up functions by pressing or touching the power button 190.

[0096] Motor 191 can generate vibration alerts. Motor 191 can be used for incoming call vibration alerts or for touch vibration feedback. For example, different vibration feedback effects can correspond to touch operations performed on different applications (such as taking photos, playing audio, etc.). Motor 191 can also correspond to different vibration feedback effects for touch operations performed on different areas of the display screen 194. Different application scenarios (such as time reminders, receiving messages, alarm clocks, games, etc.) can also correspond to different vibration feedback effects. The touch vibration feedback effect can also be customized.

[0097] Indicator 192 can be an indicator light, used to indicate charging status, power changes, or to indicate messages, missed calls, notifications, etc.

[0098] The SIM card interface 195 is used to connect a SIM card. The SIM card can be inserted into or removed from the SIM card interface 195 to make contact with and separate from the electronic device 100. The electronic device 100 can support one or more SIM card interfaces. The SIM card interface 195 can support Nano SIM cards, Micro SIM cards, SIM cards, etc. Multiple cards can be inserted into the same SIM card interface 195 simultaneously. The multiple cards can be of the same or different types. The SIM card interface 195 can also be compatible with different types of SIM cards. The SIM card interface 195 can also be compatible with external memory cards. The electronic device 100 interacts with the network through the SIM card to realize functions such as calls and data communication. In some embodiments, the electronic device 100 uses an eSIM, i.e., an embedded SIM card. The eSIM card can be embedded in the electronic device 100 and cannot be separated from the electronic device 100.

[0099] It is understood that the structure illustrated in this application does not constitute a specific limitation on the electronic device 100. In other embodiments, the electronic device 100 may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0100] The software system of electronic device 100 can adopt a layered architecture, event-driven architecture, microkernel architecture, microservice architecture, or cloud architecture. This application uses the layered architecture Android system as an example to illustrate the software structure of electronic device 100. This application does not limit the type of operating system of the electronic device. For example, Android system, HarmonyOS, etc.

[0101] To better understand the embodiments of this application, the following first combines... Figure 2 The structure of the electronic device applicable to the data backup method provided in this application will be described in more detail.

[0102] like Figure 2As shown, the electronic device 200 may include an MCU, an AP, main memory, slave memory, a first port, a second port, a controller, a wireless communication module (such as a wireless fidelity (WIFI) module or a Bluetooth module), and other peripheral modules. The MCU and AP can achieve wired connection to external devices through the first port or wireless connection through the wireless communication module. The MCU can communicate with the AP via interfaces such as SDIO, GPIO, I2S, or USART. Both the AP and the MCU can access the main memory.

[0103] The MCU can act as a slave processor, responsible for security verification, port management, and main memory management in abnormal scenarios. Furthermore, the MCU has read-only access to the AP security partition.

[0104] It should be noted that a read-only AP secure partition can be understood as follows: a secure partition can be a region located in the main memory, used to store data that needs to be kept confidential, such as power-on passwords, fingerprint data, and facial recognition data. The secure partition is typically controlled by the AP; for example, when an application requests to use data in the secure partition, the AP can control the reading, and the read / write process requires encryption and decryption by the system. In this embodiment, the MCU has read-only access to the AP secure partition, meaning that the MCU can achieve read-only access to the secure partition through the AP. For simplicity, descriptions of similar situations are omitted below.

[0105] Main memory can be used to store programs and data. The MCU can be authorized to access main memory, but only in block device mode to obtain the remaining space of the user partition and read / write the remaining space at the end of the block device. Optionally, a controller is also provided between the main memory and the MCU. Alternatively, the controller can also be integrated into the MCU.

[0106] The storage device can be used to store secure backup information such as AP dynamic encryption keys.

[0107] The first port is a shared port for the MCU and AP, through which the MCU and AP communicate with the outside world.

[0108] The second port is the communication port between the MCU and the AP, used to establish a communication connection between the two.

[0109] It should be understood that Figure 2 The structure shown can be applied to either the first device or the second device described below. This application does not limit the scope of the embodiments.

[0110] Under normal circumstances, the access point (AP) can read data from main memory. This main memory may include a system partition, a boot partition, a recovery partition, a data partition, and a miscellaneous (misc) partition. If the boot partition is damaged, causing the electronic device to fail to boot, it will need to be repaired. However, the repaired system may be restored to factory settings. If the user has not backed up their data beforehand, all user data may be lost, resulting in significant financial loss.

[0111] To address the aforementioned issues, this application provides a data backup method. In response to a user's operation, a first device establishes a communication connection with a second device. After establishing the connection, the first device obtains authorization for proxy repair of the second device. This authorization is used by the first device to perform proxy repair on the second device. Based on this authorization, the first device backs up the user data in the data partition of the second device. After the backup is complete, the first device initiates proxy repair on the second device, thereby completing the rescue backup of the user data in the data partition of the second device.

[0112] Before introducing the embodiments of this application, the terms used in this application will be explained first.

[0113] 1. First device: A functional electronic device, such as a mobile phone or tablet. In this embodiment, the first device can be used to perform proxy repair on the second device in proxy repair mode.

[0114] 2. Secondary device: Electronic devices that cannot be turned on, or bricked electronic devices. For example, mobile phones, tablets, etc.

[0115] 3. First Port: Shared port of the MCU and AP. Specifically, the MCU and AP in the same electronic device can share the first port, and either the MCU or the AP can use this first port to communicate with external devices. A specific command is required to trigger the switch of the first port from being used by the AP to being used by the MCU, or vice versa.

[0116] It should be noted that the use of the MCU's first port to communicate with external devices requires strict control. This port should, in principle, only be used for device-to-device (D2D) connections, such as connections between electronic devices like mobile phones, PCs, and tablets. Furthermore, the command debugging window should not be open in non-R&D debugging scenarios.

[0117] 4. Second Port: A logical port used to establish communication between the MCU and the AP. The second port has the capability for forced loading and debugging interaction. For example, the MCU can access the AP's security partition through the second port.

[0118] 5. Update Package: In some operating systems, such as Android, update packages can be used for system upgrades or repairs. Update packages are downloaded from servers, such as over-the-air (OTA) technology servers. When a terminal device needs a system upgrade or repair, it can first enter recovery mode and then use the update package to perform the upgrade or repair. It should be understood that in some cases, an update package may also be called a repair package, repair upgrade package, etc. This application does not limit its naming.

[0119] The data backup method provided in the embodiments of this application will be described in detail below with reference to the accompanying drawings. It should be understood that the data backup method provided in the embodiments of this application can be applied not only to scenarios where the second device cannot be powered on, but also to scenarios where the second device can be powered on but cannot enter repair mode. The embodiments of this application do not limit this application in this regard.

[0120] Figure 3 This is a schematic flowchart illustrating the data backup method provided in an embodiment of this application. It should be understood that... Figure 3 The method 300 shown can be executed when a communication connection is established between the first device and the second device.

[0121] One possibility is that when the second device's AP can be recognized and perform normal data communication with the external network through the first port, or in other words, when the second device can perform normal data communication, it can enter fastboot mode but cannot enter repair mode. The first device's AP can connect to the second device's AP, enabling communication between the two devices.

[0122] like Figure 4 As shown, the AP of the first device can connect to the port #2 of the second device (i.e., the first port of the first device) through port #1 (i.e., the first port of the first device) and then communicate with the AP of the second device.

[0123] Another possibility is that if the first port on the AP side of the second device does not respond, it will also be unable to enter fast startup mode or repair mode. The AP of the first device can be connected to the MCU of the second device to realize the communication connection between the first and second devices.

[0124] It should be understood that the first port on the AP side not responding can specifically mean that the system partition supporting the operation of the AP side is damaged, the AP side system cannot operate normally, and cannot support normal functions such as listening to the first port and transmitting data.

[0125] like Figure 5 As shown, the AP of the first device can connect to the port #2 of the second device (i.e., the first port of the first device) via port #1 (i.e., the first port of the first device), and then communicate with the MCU of the second device. The MCU of the second device communicates with the AP via port #3 (i.e., the second port of the second device).

[0126] Figure 3 The method 300 shown may include S301 to S306, which are described below. Figure 3 Each step in the process will be explained in detail. It should be understood that... Figure 3 The actions performed by the first device in the illustrated process can, for example, be performed by the AP within the first device. Furthermore, Figure 3 The first device and the second device shown can satisfy at least one of the following: the first device and the second device are devices of the same brand; the first device and the second device have the same operating system, such as Android or HarmonyOS; and the first device and the second device are devices of the same type, such as mobile phones or tablets.

[0127] S301, The first device obtains authorization to repair the second device.

[0128] It should be understood that the first device may obtain access to the second device after obtaining authorization to perform proxy repair on the second device, so as to access the second device and perform proxy repair on the second device.

[0129] One possibility is that the first device had already obtained proxy repair authorization when the second device was in good working order. For example, when the second device was in good working order, it connected to the first device and established a trust relationship with it.

[0130] When the second device is in good working order, it can connect to the first device wirelessly or via a wired connection. The second device can connect to the first device wirelessly via methods such as Wi-Fi or Bluetooth, or via a wired connection. This application does not limit this approach.

[0131] Figure 6 (a) in the diagram is a schematic of a first device and a second device connected wirelessly. When the second device is in good working order, the first device and the second device can respectively activate their wireless communication modules to achieve communication connection.

[0132] For example, the first device and the second device establish a communication connection via a Wi-Fi module. The second device turns on its Wi-Fi hotspot, and the first device connects to the second device's Wi-Fi signal, thus enabling the communication connection between the first device and the second device.

[0133] Alternatively, the first and second devices can each enable their Bluetooth modules and establish a communication connection through Bluetooth pairing.

[0134] It should be understood that using a WIFI module or a Bluetooth module to achieve communication connection are merely two possible implementation methods and should not constitute any limitation on this application.

[0135] Figure 6 (b) is a schematic diagram of a first device and a second device connected via a wired connection. The first port of the second device establishes a communication connection with the first port of the first device via a wired connection.

[0136] Figure 6 In case b), the AP of the second device cannot connect to external devices through the first port. In this case, the second device can connect to the MCU of the first device through the first port, and the MCU can connect to the AP of the first device through the first port, thereby establishing a communication connection between the first device and the second device. It should be understood that... Figure 6 The connection relationship shown in b) is... Figure 5 The connections shown are similar, and for the sake of simplicity, they will not be described again here.

[0137] Figure 6 Although not shown in the text, it can be understood that when the second device's AP can connect to an external device through the first port, the first device and the second device can also connect through a similar connection. Figure 4 The connection method described above enables communication.

[0138] The first and second devices can establish a trust relationship after the connection is completed. The first and second devices can establish a trust relationship through "device interoperability".

[0139] For ease of understanding and explanation, the following example illustrates how the first device obtains proxy repair authorization from the second device. It is understood that, using the same method described below, the second device can also obtain proxy repair authorization from the first device.

[0140] For example, the methods of "device cooperation" may include, but are not limited to, the following:

[0141] Method 1: Establish a trust relationship through authorization information. This authorization information can be, for example, an authorization code generated from a user-defined password, or authorization information generated based on the device's hardware information. This application does not limit this approach.

[0142] For example, the authorization codes of the first and second devices generated by the user-defined password can be pre-stored in the slave memory of the first and second devices, respectively. After the first and second devices shake hands, the authorization codes of the two devices can be matched. If the match is successful, authorization is automatically granted.

[0143] For example, the first device can handshake with the second device based on hardware information such as the second device's serial number (SN), and the first device can automatically authorize the second device after the handshake. It should be understood that the SN is only one example of hardware information; this hardware information can also be other information that can be used to uniquely identify a device. Embodiments in this application include, but are not limited to, this.

[0144] As an example, the MCU of the second device can read the serial number of the second device. Based on the connection relationship between the first and second devices, the second device can send the serial number to the first device through the first port.

[0145] Method 2: Establish a trust relationship through a power-on password. This power-on password can be, for example, a facial recognition method, fingerprint recognition, or numeric password.

[0146] For example, after the first device enters the authorization check, the user can enter the power-on password of the second device to obtain authorization.

[0147] Method 3: Establishing a trust relationship through linked accounts. The first device and the second device can have linked accounts, or in other words, they are two devices with linked accounts. The linked accounts can be, for example, bound to the same account, or a main account and a sub-account. These accounts can be, for example, device accounts, or mobile phone numbers. This application is not limited in this respect. For example, the first device and the second device can be two devices with the same account; or, for example, the first device's account is the main account and the second device's account is the sub-account; or, for example, the first device's account is the sub-account and the second device's account is the main account, and so on. For simplicity, these are not listed here. The first device can check whether it has a linked account with the second device; if so, the second device can obtain authorization.

[0148] Another possibility is that the first device obtains proxy repair authorization when the second device fails. The first device can request temporary proxy repair authorization for the second device from a server (such as an authorization server).

[0149] For example, the first device may provide the authorization server with authentication information of the first device and the second device to request the authorization server to evaluate whether to grant the first device temporary proxy repair permissions for the second device. This authentication information may be, for example, information used for public key infrastructure (PKI) verification, such as, but not limited to, public keys, digital certificates, and digital signatures.

[0150] One possible implementation is that, after the first device is connected to the second device, the first port of the first device (e.g., Figure 4 or Figure 5 The second device can be detected via port #1. Based on this, the first device can display an "Authorization Check" button via the user interface (UI), such as... Figure 7 As shown. The user can click this button to trigger an authorization check on the first device. In response to the user's action, the first device enters the authorization check.

[0151] Figure 8 The specific process of the first device performing the authorization check is shown. For example... Figure 8 As shown, the first device first determines whether a trust relationship has been established with the second device. If the second device has established a trust relationship with the first device, the authorization check passes, and the first device obtains authorization to repair the second device. If the second device has not established a trust relationship with the first device, the first device can establish a trust relationship by executing the methods described in "Device Assistance," such as verifying the second device's authorization information or entering its power-on password. If the verification passes, the authorization check passes, and the first device obtains authorization to repair the second device. If the verification fails, the authorization check also fails, and the first device can request temporary authorization to repair the second device from the authorization server. It can be understood that the first device establishing a trust relationship with the second device through "Device Assistance" requires the second device to be able to power on normally. If the second device cannot power on normally, it is equivalent to failing both the verification and the authorization check, and the first device can directly request temporary authorization to repair the second device from the authorization server. If the server allows temporary authorization, the first device obtains authorization to repair the second device.

[0152] S302. The first device backs up the user data in the data partition of the second device based on the agent repair authorization.

[0153] The second device can be decrypted in proxy repair mode to access its data partition.

[0154] After obtaining authorization to repair the data partition of the second device, the first device can gain access to the data partition of the second device and then back up the user data in the data partition of the second device.

[0155] Optionally, access to the data partition of the second device can also be obtained through password verification. For example, after obtaining authorization to repair the data partition through the agent, the first device can prompt the user to enter a password to decrypt the data partition of the second device via a user interface. The password entered by the user can be determined through the connection relationship between the first and second devices (see above). Figure 4 or Figure 5 The connection relationship shown is sent to the second device. For example, in... Figure 4 Under the connection shown, the second device's AP verifies the entered password; Figure 5 In the connection method shown, the MCU of the second device can read the AP security partition of the second device and verify the password entered by the user. If the verification is successful, the first device can obtain access to the data partition of the second device; if the verification fails, the first device cannot obtain access to the data partition of the second device. Furthermore, the first device can also prompt the user to enter personal verification information through the user interface for verification by the second device. This personal verification information may include, for example, the device's personal password or personal account.

[0156] For example, in response to a user's input, the first device sends an access request for the second device's data partition to the second device. The MCU of the second device receives the access request from the first device and requests to read the password pre-stored in the second device's security partition through a second port between the second device and the second device's AP. Based on the password, the MCU verifies the access password. If the verification is successful, the access request from the first device is accepted.

[0157] Understandably, the access request sent by the first device to the second device carries an access password, which is a password entered by the user and used to access the data partition of the second device.

[0158] It should be noted that the access password and the power-on password used to establish the trust relationship can be the same or different; this application embodiment does not limit this. If they are the same password, entering the power-on password during the trust relationship establishment process grants access to the data partition of the second device, and password verification can be performed again before backup; this application embodiment does not limit this either.

[0159] The backup of user data in the data partition of the second device by the first device can be achieved in the following two possible ways:

[0160] One possible implementation is that the first device can copy data files from the data partition of the second device. These data files could be, for example, images, music, videos, or other user-visible data files. It should be understood that a file system can organize associated user data into files; therefore, these data files can include user data, or in other words, the data file is a form of user data presented to the user.

[0161] The second possible implementation is that the first device can copy a binary image of the second device's data partition. This binary image refers to a binary image of the second device's data partition, which includes not only user-visible data files but also user-invisible system files. In other words, copying the binary image of the second device's data partition is equivalent to copying the complete original binary data of the second device's data partition. Specifically, the complete original binary data of the data partition can refer to a single, contiguous block of binary data stored within the data partition. The process of the first device copying the binary image of the second device's data partition to its local storage is essentially storing an identical copy of the second device's data partition in the first device's storage area.

[0162] To facilitate distinction and understanding, the following text combines... Figure 9 This will illustrate two implementation methods: file backup and binary image backup. Figure 9 This is a schematic diagram illustrating the backup of user data provided in an embodiment of this application. It should be understood that... Figure 9 To facilitate differentiation, the data in each partition of the first device is labeled A, and the data in each partition of the second device is labeled B.

[0163] For example, the MCU of the second device can activate the data partition of the second device after completing the verification, and mount the data partition to the first device as an external storage device. It should be understood that mounting the data partition to the first device as an external storage device can mean attaching the data partition to a folder in Linux, thus associating the data partition with that directory. Accessing the folder is equivalent to accessing the data partition. Figure 9 As shown, the data partition of the second device is essentially a part of the first device. Therefore, the first device can access the data partition of the second device. Users can copy data files from the second device's data partition to the first device by operating on the first device, thus backing up user data on the second device. This example corresponds to the first possible implementation of user data backup described above.

[0164] In another example, after the MCU of the second device completes the verification, the first device can read the data partition of the first device and copy the binary image of the data partition of the second device to the first device, thus completing the backup of the user data of the second device. Figure 9 As shown, a binary image of the data partition of the second device is copied to the storage area of ​​the first device. This example corresponds to the second possible implementation of user data backup described above.

[0165] It's understandable that binary image backup differs from file backup. Binary image backup doesn't require mounting the data partition of the second device to the first device. A binary image is a complete backup of the data partition of the second device. Copying the binary image of the second device's data partition to the first device requires the file system to process the binary image to create files visible to the user. Therefore, even if the data partition of the second device is damaged, or if files on the second device's data partition are missing, user data can still be backed up using a binary image. However, it's understandable that in the event of data partition damage, some user data may be lost, and this lost data may not be able to be backed up.

[0166] S303. The first device obtains an upgrade package, which is used to perform proxy repair on the second device.

[0167] After the first device completes the backup of the user data of the second device, it can obtain the upgrade package from the server and complete the proxy repair of the second device based on the upgrade package.

[0168] For example, the first device obtaining the upgrade package may specifically include: the first device obtaining an authorization file, the first device obtaining a filelist of version files, and the first device downloading the upgrade package and authentication file. The authorization file obtained by the first device is used to obtain authorization for proxy repair of the second device; this authorization file can be used to subsequently obtain the filelist of version files. The filelist of version files can be used to determine the version of the upgrade package to be downloaded. The upgrade package can be used to perform system repair on the second device. The authentication file can be used for authentication during the repair process of the second device.

[0169] The following will describe, with reference to the accompanying drawings, the process by which the first device obtains the authorization file, the list of version files, and downloads the upgrade package and authentication file.

[0170] Figure 10 This is a schematic diagram of the first device application authorization document provided in the embodiments of this application.

[0171] For example, the first device may request an authorization file from an authorization server (i.e., an example of a first server). This authorization server may be provided by the device manufacturer, for example.

[0172] like Figure 10 As shown, after obtaining authorization for proxy repair from the second device, the first device can send a proxy repair authorization application from the first device to the second device, along with its own device information and the second device's device information, to the authorization server for review and approval. This device information may include, but is not limited to, version identifiers and device identifiers. It should be understood that the version identifier indicates the device's version, and the device identifier identifies the device, and may include, for example, a device serial number. The authorization server can perform public key infrastructure (PKI) verification on the device information and authenticate the proxy repair authorization application. If the PKI verification and authentication are successful, the authorization server can issue an authorization file to the first device. This authorization file is unique and may include both the first and second device's device information. Furthermore, this authorization file is directional and is used only for proxy repair of the second device by the first device.

[0173] Figure 11 This is a schematic diagram illustrating the first device obtaining the authentication file and downloading the upgrade package, as provided in the embodiments of this application.

[0174] For example, the first device can obtain an authentication file from a packet search server (i.e., an example of a second server) and download an upgrade package from an OTA server (i.e., an example of a third server). The packet search server and the OTA server can be provided by the device manufacturer, for example.

[0175] like Figure 11 As shown, the first device obtains a list of version files from the packet search server based on the authorization file and the device information of the second device. Specifically, the first device obtains the authorization file, that is, it obtains the authorization for the first device to repair the second device. Based on this authorization, the first device can read the device information of the second device, construct a request message (for ease of distinction and explanation, for example, referred to as the first request message) and send it to the packet search server, such as... Figure 11 As shown in ①.

[0176] Optionally, the first request message includes device information of the second device. Further optionally, the first request message also includes an authorization file obtained by the first device. The device information of the second device may include, but is not limited to, a version identifier and a device identifier.

[0177] After receiving the first request message, the packet search server verifies the device information of the second device. If the verification passes and an upgrade version is found available for the second device, the packet search server can then send a list of version files to the first device. Figure 11As shown in ② in the example, this version file list records the OTA server address and the version information of the upgrade package, such as the package name, size, and version number of the upgrade package.

[0178] The first device can locate the OTA server based on the OTA server address, and construct a request message (for ease of distinction and explanation, let's call it the second request message) based on the upgrade package version information in the version file list, such as the version identifier (ID), and send it to the OTA server. Figure 11 As shown in ③, the OTA server can send the corresponding upgrade package to the first device based on this second request message, such as... Figure 11 As shown in ④. The first device can also send a request message (for ease of distinction and explanation, for example, referred to as the third request message) to the packet search server based on the upgrade package to request the packet search server to issue the authentication file for the second device.

[0179] Thus, the first device obtains the upgrade package used to repair the second device.

[0180] It should be noted that the upgrade package downloaded by the first device from the OTA server can be one or more upgrade packages. This application does not limit the number of upgrade packages downloaded by the first device from the OTA server. For example, if the version file list received by the first device from the package search server includes version identifiers of multiple (e.g., three) upgrade packages, the first device can construct a request message based on the version identifier of each upgrade package to download the corresponding upgrade package from the OTA server.

[0181] It should be understood that the authorization server, packet search server, and OTA server used in the above process can be multiple independent physical devices, or they can be integrated into a single physical device. This application does not constitute any limitation in this regard. It is understood that the authorization server, packet search server, and OTA server are merely distinctions based on different functions and should not constitute any limitation on the specific form of the devices. Furthermore, the names of the servers are merely illustrative and should not constitute any limitation on this application. This application does not limit the specific names of the servers. For example, an OTA server can also be called a packet download server.

[0182] It should also be understood that the method by which the first device obtains the upgrade package is not limited to the one described above. For example, the first device can submit its device information and the device information of the second device to the server. Based on the device information of the second device, the server sends the authentication file and the upgrade package that matches the version of the second device to the first device, and the first device can then obtain the upgrade package to repair the second device.

[0183] After obtaining the upgrade package, the first device can save it for subsequent proxy repair of the second device. The first device can store the upgrade package locally or on the second device; this embodiment does not limit this.

[0184] One possibility is that the first device can access the second device's data block device. In this case, the first device can directly store the upgrade package into the second device's data block device, for example, by placing it at the end of the second device's data block device.

[0185] Figure 12 This is a schematic diagram of the second device data block device provided in an embodiment of this application. Figure 12 As shown, the upgrade package and authentication file can be stored in binary form at the end of the data block device of the second device.

[0186] Another possibility is that the first device cannot access the second device's data block device. In this case, the first device can store the upgrade package as a file in its own storage device, such as its main memory.

[0187] It is understandable that the damage to the data partition of the second device is determined based on the data header data. Therefore, when the first device can access the data block device of the second device, even if the data partition of the second device is damaged, placing the upgrade package at the end of the data block device can still ensure the storage of the upgrade package.

[0188] S304. The first device performs proxy repair on the second device.

[0189] The first device can use the upgrade package obtained above to perform proxy repair on the second device. It should be noted that the proxy repair of the second device by the first device can be performed either when the second device can enter repair mode on its own, or when the second device cannot enter repair mode on its own. This application embodiment does not limit this.

[0190] It should be noted that regardless of whether the second device can enter repair mode on its own, the second device is in a state where it cannot be powered on normally.

[0191] One possibility is that the second device can enter repair mode on its own. For example, if the system image of the second device is corrupted and needs to enter repair mode for system repair, the first device can trigger the second device to enter repair mode and perform system repair in proxy repair mode.

[0192] For example, the first device can display a "Proxy Repair" button to the user through a user interface. The user can click the proxy repair button on the first device to trigger the second device to enter repair mode. Responding to the user's action, after entering proxy repair mode, the first device can send a command to the second device to enter repair mode through its connection with the second device. Based on this command, the second device enters system repair mode.

[0193] Figure 13 This is a schematic flowchart illustrating the system repair provided in the embodiments of this application.

[0194] like Figure 13 As shown, in response to the triggering of the first device, the second device begins the upgrade.

[0195] First, the second device parses the upgrade command.

[0196] For example, in response to a triggering action by the first device, such as the instruction to enter repair mode sent by the first device as described above, the AP of the second device can write an upgrade command to the misc partition, the second device restarts, and can read and parse the upgrade command from the misc partition to enter repair mode.

[0197] It should be understood that if the AP of the second device can communicate with the outside through the first port, the first device can send a command to the AP of the second device to make the AP of the second device directly enter the repair mode; if the AP of the second device cannot communicate with the outside through the first port, the first device can send an upgrade command to the MCU of the second device, and the LiteOS in the MCU will trigger the AP to enter the repair mode.

[0198] After parsing, the second device begins authentication. The second device can perform authentication based on a pre-obtained authentication file. If authentication fails, the upgrade fails, and the second device cannot complete the repair. If authentication succeeds, it begins verifying the upgrade package signature. This verification can include checking the correctness and integrity of the upgrade package. If both correctness and integrity checks pass, the signature verification succeeds; if either fails, the signature verification fails. If the signature verification fails, the upgrade fails. If the signature verification succeeds, the second device begins version checking to verify if the upgrade package version matches the second device. If the version check fails, the upgrade fails. If the version check passes, the second device processes the partition table and initiates a binary upgrade. The binary upgrade can include parsing the upgrade package data, writing the partition image sequentially, and verifying the partition image. After the binary upgrade is complete, the version number of the second device will be updated. After the update, the second device's upgrade is successful. Thus, the upgrade is complete, and the repair of the second device is finished.

[0199] It is understood that an upgrade specifically refers to upgrading a device from one version to a higher version, such as upgrading from a basic version to a higher version. In the embodiments of this application, system repair can refer to upgrading a device from a damaged state to a normal state, and therefore can also be called an upgrade.

[0200] It should be understood that Figure 13 The illustrated process is merely one possible implementation of system repair by the second device and should not be construed as limiting this application in any way. In a specific implementation, the second device may, for example, execute... Figure 13 The system can be repaired by performing some or all of the steps. A second device can also perform the removal... Figure 13 The system repair can be achieved through a process other than that shown. This application does not limit this process. For details regarding the specific process of the second device performing system repair, please refer to the prior art; for the sake of brevity, it will not be described in detail here.

[0201] Another possibility is that the second device cannot enter repair mode. In this case, the first device performs proxy repair on the second device in proxy repair mode.

[0202] Figure 14 This illustrates the specific process of the first device acting as a proxy to repair the second device from the perspective of the equipment. For example... Figure 14 As shown, in response to a user action, the first device begins to execute the following steps.

[0203] Step 1401: The first device enters the proxy repair mode.

[0204] Step 1402: The first device triggers the second device's AP to enter the forced loading mode via a command.

[0205] For example, the first device can display a "Proxy Repair" button to the user through a user interface. The user can click the proxy repair button on the first device to trigger the second device to enter forced loading mode. Responding to the user's action, after entering proxy repair mode, the first device can send a command to the second device to enter forced loading mode through its connection with the second device. The second device's access point (AP) can then enter forced loading mode based on this command.

[0206] Step 1403: The first device parses the upgrade package and forcibly loads the repair minimal system image onto the second device. The repair minimal system can refer to an image upgrade package capable of supporting normal startup in repair mode, specifically including the most basic modules necessary for repair mode to run. In other words, the second device can enter repair mode based on this repair minimal system. For example, the repair minimal system may include, but is not limited to, a preloader, a fast startup module, a partition table (ptable), and a repair module.

[0207] Step 1404: The first device triggers the second device to enter the proxy repair mode.

[0208] For example, after the first device parses the upgrade package, it can send a command to the second device to enter the proxy repair mode through the connection relationship with the second device, and the second device can enter the proxy repair mode based on the command.

[0209] Step 1405: The second device writes the upgrade package and authentication file to the data block device. The second device can obtain the upgrade package and authentication file from the first device and then write them to the data block device.

[0210] Step 1406: The second device enters repair mode. It should be understood that the operations performed by the second device in repair mode can be referred to in conjunction with the above text. Figure 13 For a more detailed description, please refer to other existing technologies that can be used to implement system repair. For the sake of brevity, further details are omitted here.

[0211] S305. The second device checks whether the data partition is complete.

[0212] After the first device completes the proxy repair for the second device, the second device can check whether the repaired data partition of the second device is complete. It should be understood that the header of the data partition contains data describing the partition information, such as partition size, starting address, and number of blocks. After the first device completes the proxy repair for the second device, the second device's file system can read the data partition based on this partition information. If an error occurs during the read, it indicates that the data partition is damaged or incomplete; if the read is successful, it indicates that the data partition is complete and correct.

[0213] If the data partition of the second device is complete, the second device does not need to obtain the backed-up user data from the first device. Optionally, the second device can send a first message to the first device to notify the first device that the backed-up user data does not need to be returned. Based on this first message, the first device can clear the locally stored backed-up user data. If the data partition of the second device is incomplete, S306 can be executed, and the second device can obtain the backed-up user data through interaction with the first device. For example, the second device can send a second message to the first device to request the backed-up user data, and the first device can return the backed-up user data to the second device based on the second message.

[0214] It is understandable that, based on the different methods of backing up user data mentioned above, the backed-up data can be files, such as pictures, music, documents, videos, etc., or it can be a binary image. The first device can also return the backed-up user data to the second device in the following two possible ways:

[0215] The first possible implementation is that the first device, in proxy repair mode, copies the backed-up files to the data partition of the second device, thus completing the return of user data.

[0216] The second possible implementation is that, in proxy repair mode, the second device erases the data partition, the first device loads the backed-up data partition image onto the second device, and the second device starts a single image upgrade to complete the restoration of the data partition.

[0217] It should be understood that the first message and the second message listed above may be the same message, and the first device may determine whether the backed-up user data needs to be returned through different instructions; the first message and the second message may also be different messages, and this application embodiment does not limit this.

[0218] The data backup method provided in this application involves a first device obtaining a proxy repair authorization from a second device to be repaired. Based on this proxy repair authorization, the first device can access the data partition of the second device regardless of whether the second device can be powered on, thereby enabling the backup of user data in the data partition. Therefore, the probability of user data loss in the data partition during repair scenarios can be reduced; even if the data partition is damaged, unlost user data can still be backed up, minimizing data loss. Overall, this reduces user losses.

[0219] It is understood that the above description, in conjunction with several accompanying figures, outlines the specific process of the data backup method provided in this application. These figures are merely examples, and not every step in the figures is necessarily required; for example, some steps can be skipped. Furthermore, the execution order of each step is not fixed and is not limited to what is shown in the figures. The execution order of each step should be determined by its function and internal logic.

[0220] It should also be understood that each step of the above method can be completed by integrated logic circuits in the processor's hardware or by instructions in software form. The steps of the method disclosed in the embodiments of this application can be directly implemented by a hardware processor, or by a combination of hardware and software modules in the processor. The software modules can reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. This storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method. To avoid repetition, detailed descriptions are not provided here.

[0221] This application also provides an electronic device, which may include a memory and a processor. The memory may be used to store computer programs; the processor may be used to invoke the computer programs stored in the memory, causing the electronic device to execute... Figure 3 The method executed by the first device or the method executed by the second device in the illustrated embodiment.

[0222] This application also provides a computer program product, the computer program product comprising: a computer program (also referred to as code or instructions), which, when executed, causes an electronic device to perform... Figure 3 The method executed by the first device or the method executed by the second device in the illustrated embodiment.

[0223] This application also provides a computer-readable storage medium storing a computer program (also referred to as code or instructions). When the computer program is executed by a computer or processor, it causes an electronic device to perform... Figure 3 The method executed by the first device or the method executed by the second device in the illustrated embodiment.

[0224] It should be understood that the processor in the embodiments of this application can be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method embodiments can be completed by the integrated logic circuits in the processor's hardware or by instructions in software form. The processor can be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules can be located in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. This storage medium is located in memory, and the processor reads the information in the memory and, in conjunction with its hardware, completes the steps of the above method.

[0225] It should also be understood that the memory in the embodiments of this application can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous linked dynamic random access memory (SLDRAM), and direct rambus RAM (DR RAM). It should be noted that the memory used in the systems and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0226] The terms “unit”, “module”, etc., used in this specification may be used to refer to computer-related entities, hardware, firmware, combinations of hardware and software, software, or software in execution.

[0227] Those skilled in the art will recognize that the various illustrative logical blocks and steps described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application. In the several embodiments provided in this application, it should be understood that the disclosed apparatus, devices, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the shown or discussed mutual couplings or direct couplings or communication connections may be through some interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.

[0228] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0229] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0230] In the above embodiments, the functions of each functional unit can be implemented entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions (programs). When the computer program instructions (programs) are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, 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.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available media may be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., DVDs), or semiconductor media (e.g., solid-state disks, SSDs), etc.

[0231] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0232] It should be understood that the module division in the embodiments of this application is illustrative and only represents a logical functional division. In actual implementation, there may be other division methods. Furthermore, the functional modules in the various embodiments of this application can be integrated into a single processor, exist as separate physical entities, or be integrated into a single module. The integrated modules described above can be implemented in hardware or as software functional modules.

[0233] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A data backup method, characterized in that, include: The first device obtains a proxy repair authorization for the second device. The proxy repair authorization is used by the first device to perform proxy repair on the second device, which is the device to be repaired and cannot be powered on. Based on the agent repair authorization, the first device initiates access to user data in the data partition of the second device; wherein, the access is verified through the microcontroller unit (MCU) of the second device, and the MCU reads the verification information pre-stored in the security partition of the second device through the communication port between the application processor (AP) of the second device and the MCU to complete the verification; After successful verification, the first device backs up the user data in the data partition of the second device; The first device performs proxy repair on the second device.

2. The method as described in claim 1, characterized in that, The first device obtains authorization for proxy repair of the second device to be repaired, including: The first device obtains authorization to perform proxy repair on the second device to be repaired based on the trust relationship between the first device and the second device.

3. The method as described in claim 2, characterized in that, The trust relationship is established based on one of the following: the authorization information of the second device, the power-on password of the second device, and the associated accounts of the first device and the second device.

4. The method as described in claim 1, characterized in that, The first device obtains authorization for proxy repair of the second device to be repaired, including: The first device requests a temporary proxy repair authorization for the second device from the first server.

5. The method as described in claim 1, characterized in that, The method further includes: In response to a user's input, the first device sends an access request to the second device for the data partition of the second device. The access request carries an access password, which is the password entered by the user, and is used to access the data partition of the second device.

6. The method as described in claim 1, characterized in that, The first device backs up user data in the data partition of the second device, including: Based on the agent repair authorization, the first device copies a data file from the data partition of the second device to back up the user data, the data file containing the user data.

7. The method as described in claim 1, characterized in that, The first device backs up user data in the data partition of the second device, including: Based on the agent repair authorization, the first device copies a binary image of the data partition of the second device to back up the user data. The binary image includes the complete original binary data of the data partition of the second device.

8. The method as described in claim 1, characterized in that, The first device performs proxy repair on the second device, including: The first device obtains an upgrade package, which is used for system repair of the second device; The first device sends the upgrade package to the second device; The first device triggers the second device to enter repair mode, and the upgrade package is used by the second device to perform system repair in the repair mode.

9. The method as described in claim 1, characterized in that, The first device performs proxy repair on the second device, including: The first device obtains an upgrade package, which is used for system repair of the second device; The first device parses the upgrade package to obtain the minimum system required for repair; The first device mirrors the repair minimal system to the second device; The first device triggers the second device to enter the proxy repair mode, and the repair minimum system is used by the second device to perform system repair in the proxy repair mode.

10. The method as described in claim 8 or 9, characterized in that, The first device obtains the upgrade package, including: The first device sends a proxy repair authorization application for the second device to the first server, along with device information of the first device and device information of the second device. The device information includes a version identifier and a device identifier, in order to obtain an authorization file from the first server. The authorization file is used to instruct the first device to authorize the proxy repair of the second device. The first device obtains a list of version files from the second server based on the authorization file and the device information of the second device; The first device downloads the upgrade package from the third server based on the version file list.

11. The method as described in claim 8 or 9, characterized in that, The method further includes: The first device downloads an authentication file from the second server based on the upgrade package. The authentication file is used to authenticate the second device during the system repair.

12. A data backup method, characterized in that, include: The microcontroller unit (MCU) of the second device receives an access request from the first device. The access request requests access to the data partition of the second device and carries an access password. The second device is a device to be repaired and cannot be powered on. The first device is a device used to perform proxy repair on the second device; The MCU of the second device requests to read the password pre-stored in the security partition of the second device through the communication port between the MCU and the application processor (AP) of the second device. The MCU of the second device verifies the access password based on the password in the security partition; If the access password is successfully verified, the MCU of the second device accepts the access request from the first device.

13. An electronic device, characterized in that, The electronic device includes at least one processor for executing a computer program to cause the electronic device to perform the following operations: Obtain a proxy repair authorization for the second device, the proxy repair authorization being used by the electronic device to perform proxy repair on the second device, the second device being the device to be repaired, and the second device being unable to power on; Based on the agent repair authorization, an access to user data in the data partition of the second device is initiated; wherein, the access is verified through the microcontroller unit (MCU) of the second device, and the MCU reads the pre-stored verification information in the security partition of the second device through the communication port between the application processor (AP) of the second device and the MCU to complete the verification; After successful verification, the user data in the data partition of the second device is backed up; Perform proxy repair on the second device.

14. The electronic device as claimed in claim 13, characterized in that, The at least one processor is configured to execute a computer program, causing the electronic device to perform the following operations: Based on the trust relationship with the second device, obtain authorization for proxy repair of the second device.

15. The electronic device as claimed in claim 14, characterized in that, The trust relationship is established based on one of the following: the authorization information of the second device, the power-on password of the second device, and the associated account between the electronic device and the second device.

16. The electronic device as claimed in claim 13, characterized in that, The at least one processor is configured to execute a computer program, causing the electronic device to perform the following operations: Request the first server for temporary proxy repair authorization for the second device.

17. The electronic device as claimed in claim 13, characterized in that, The at least one processor is configured to execute a computer program, causing the electronic device to perform the following operations: In response to a user's input, the electronic device sends an access request to the second device for the data partition of the second device. The access request carries an access password, which is the password entered by the user, and is used to access the data partition of the second device.

18. The electronic device as claimed in claim 13, characterized in that, The at least one processor is configured to execute a computer program, causing the electronic device to perform the following operations: A data file containing the user data is copied from the data partition of the second device to back up the user data.

19. The electronic device as claimed in claim 13, characterized in that, The at least one processor is configured to execute a computer program, causing the electronic device to perform the following operations: A binary image of the data partition of the second device is copied to back up the user data, the binary image including the complete original binary data of the data partition of the second device.

20. The electronic device as claimed in claim 13, characterized in that, The at least one processor is configured to execute a computer program, causing the electronic device to perform the following operations: Obtain the upgrade package, which is used for system repair of the second device; Send the upgrade package to the second device; The second device is triggered to enter repair mode, and the upgrade package is used by the second device to perform system repair in the repair mode.

21. The electronic device as claimed in claim 13, characterized in that, The at least one processor is configured to execute a computer program, causing the electronic device to perform the following operations: Obtain the upgrade package, which is used for system repair of the second device; Parse the upgrade package to obtain the minimum system required for repair; Image the repaired minimal system onto the second device; The second device is triggered to enter the proxy repair mode, and the repair minimum system is used by the second device to perform system repair in the proxy repair mode.

22. The electronic device as claimed in claim 20 or 21, characterized in that, The at least one processor is configured to execute a computer program, causing the electronic device to perform the following operations: Sending a request for the electronic device to authorize the proxy repair of the second device to the first server, along with device information of the electronic device and the second device, the device information including a version identifier and a device identifier, to obtain an authorization file from the first server, the authorization file being used to instruct the electronic device to authorize the proxy repair of the second device; Based on the authorization file and the device information of the second device, obtain a list of version files from the second server; Based on the aforementioned list of version files, the upgrade package is downloaded from a third server.

23. The electronic device as claimed in claim 20 or 21, characterized in that, The at least one processor is configured to execute a computer program, causing the electronic device to perform the following operations: Based on the upgrade package, an authentication file is downloaded from the second server. The authentication file is used to authenticate the second device during the system repair.

24. An electronic device, characterized in that, It includes an application processor (AP) and a microcontroller unit (MCU); the MCU is used to execute computer programs to perform the following operations: The system receives an access request from a first device, the access request being used to request access to the data partition of the electronic device, the access request carrying an access password; the electronic device is a device to be repaired and cannot be powered on, and the first device is a device used to perform proxy repair on the electronic device; Request to read the password pre-stored in the security partition of the electronic device through the communication port with the AP; The access password is verified based on the password in the secure partition; If the access password is successfully verified, the access request from the first device is accepted.

25. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it causes the electronic device to perform the method as described in any one of claims 1 to 12.

26. A computer program product, characterized in that, Includes a computer program that, when run, causes the computer to perform the method as described in any one of claims 1 to 12.

Images