File backup method and device, chip system and program product

Abstract

The invention provides a file backup method and device, a chip system and a program product, and relates to the technical field of terminals. In the method, at least one backup partition is added on the basis of an original partition, and the original partition and the at least one backup partition are used for storing the same file. And when the battery health state parameters are modified each time, the electronic equipment updates version numbers and contents of files in the original partition and the at least one backup partition. By additionally arranging at least one backup partition and regularly refreshing and repairing the file content according to the version number management and control strategy, multi-file backup is realized, so that the probability that the health state parameters of the battery are lost when the memory of the electronic equipment is seriously insufficient or abnormal shutdown and other abnormal problems occur is reduced, and the security of the file is improved.

Description

Technical Field

[0001] This application relates to the field of terminal technology, and in particular to a file backup method, device, chip system, and program product. Background Technology

[0002] Battery health is crucial for a device's battery life and overall user experience. After a certain period of use, a battery's chemical properties change, leading to a decline in battery health. This results in reduced energy storage capacity, faster battery drain, and slower charging speeds.

[0003] Currently, electronic devices store a file that records the battery's health status. This file allows for periodic checks of battery health and the implementation of necessary maintenance. However, when an electronic device experiences severe memory shortages or abnormal shutdowns, this file may be lost or corrupted. The inability of the electronic device to access the file can affect the assessment of battery health, potentially posing a risk to battery safety. Summary of the Invention

[0004] This application provides a file backup method, device, chip system, and program product to solve the problem that the loss or damage of files recording battery health status poses a risk to battery safety.

[0005] To achieve the above objectives, this application adopts the following technical solution:

[0006] Firstly, this application provides a file backup method. The method may include:

[0007] In response to the first event, update the battery health status parameters, and based on the battery health status parameters, update the version number and content of the backup files in each of at least two partitions, wherein the version number and content of the backup files in each partition are the same after the update; in response to the second event, read the version number and content of the backup files from each partition, and determine the battery health status based on the content of the backup files in the first target partition of at least two partitions, wherein the version number of the backup files in the first target partition is higher than the version number of the backup files in the other partitions of at least two partitions.

[0008] In the above scheme, at least one backup partition is added to the original partition. Both the original partition and the at least one backup partition are used to store the same files. Whenever the battery health status parameters are modified, the electronic device updates the version number and content of the files in the original partition and the at least one backup partition. By adding at least one backup partition and periodically refreshing and repairing file content according to a version number control strategy, multi-file backup is achieved. This reduces the probability of losing battery health status parameters when the electronic device experiences severe memory shortages or abnormal shutdowns, thus improving file security.

[0009] In one possible implementation, in response to the first event, updating the battery health status parameters and, based on the battery health status parameters, updating the version number and content of backup files in each of at least two partitions may include: in response to the first event, collecting battery health status parameters based on a battery health status parameter collection instruction, wherein the battery health status parameter collection instruction may include the types of battery health status parameters, and the number of collections and collection period for each type of battery health status parameter; collecting each type of battery health status parameter according to the number of collections and collection period for each type of battery health status parameter; and, when any type of battery health status parameter is updated, updating the version number and content of backup files in each of at least two partitions based on the updated battery health status parameters.

[0010] In the above scheme, when the battery health status parameters are modified, the electronic device can simultaneously update the version numbers and contents of files in multiple partitions based on the modified battery health status parameters, ensuring that the version numbers and contents of files in each partition remain consistent. This way, if files in some partitions are lost or corrupted, the electronic device can read the files that are not lost or corrupted from other partitions.

[0011] In one possible implementation, in response to the second event, reading the version number and content of the backup file from each partition, and determining the battery health status based on the content of the backup file in the first target partition (at least two partitions), may include: in response to the second event, reading the version number and content of the backup file from each partition; determining that the version number of the backup file in the first target partition is higher than the version number of the backup file in other partitions, wherein the content of the backup file in the first target partition may include updated battery health status parameters; and determining the battery health status based on the battery health status parameters of the backup file in the first target partition.

[0012] In the above scheme, the version number and content of the files in each partition are consistent. When the electronic device is severely short of memory or experiences abnormal shutdown or other abnormal problems, the backup files in some partitions may be lost or corrupted, while the backup files in other partitions may not be corrupted. At this time, the version read and write management module may read different version numbers and contents of the backup files from each partition. By taking the file with the highest version number as the trusted file, the reliability of the battery health status calculated based on the battery health status parameters of the trusted file can be guaranteed.

[0013] In one possible implementation, after determining that the version number of the backup file in the first target partition is higher than the version numbers of the backup files in other partitions, the method may further include: writing the version number and content of the backup file in the first target partition to the other partitions. Wherein, after writing the version number and content of the backup file in the first target partition to the other partitions, the version number of the backup files in each partition is the same and the content of the backup files is the same.

[0014] For example, determining that the version number of the backup file in the first target partition is higher than the version number of the backup file in other partitions may include: if the version number and content of the backup file are read only from the first target partition, then determining that the version number of the backup file in the first target partition is higher than the version number of the backup file in other partitions; if the version number and content of the backup file are read from each partition, then comparing the version number of the backup file in each partition and determining that the version number of the backup file in the first target partition is higher than the version number of the backup file in other partitions.

[0015] In the above scheme, after selecting the file in the target partition as the trusted file, the trusted file is copied to other partitions other than the target partition, so that the version number and content of the file in the first partition, the second partition and the third partition are the same, so that the file can be read normally when the problem occurs again.

[0016] In one possible implementation, the method may further include: receiving a power-on operation input by a user when the electronic device is powered off; in response to the power-on operation, reading the version number and content of the backup file from each partition, determining that the version number of the backup file in the second target partition is higher than the version numbers of the backup files in at least two other partitions, and writing the version number and content of the backup file in the second target partition to the other partitions. After writing the version number and content of the backup file in the second target partition to the other partitions, the version number and content of the backup files in each partition are the same.

[0017] In the above scheme, when an electronic device shuts down abnormally, backup files in some partitions may be lost or corrupted. During power-on initialization, the backup files in each partition are synchronized to ensure that the version number and content of each backup file are consistent. In this way, even if problems such as severe memory shortage occur during operation, the electronic device can still assess the battery health status based on the battery health status parameters of the backup files because some partitions still store backup files that have not been damaged or lost.

[0018] In one possible implementation, the first event and the second event are any one of the following: screen on / off event, power-on event, charger plug-in event, and battery level change event. The second event and the first event can be the same event or different events. In addition to writing or reading files from multiple partitions in response to event triggers, this application can also write or read files from multiple partitions at preset intervals.

[0019] In one possible implementation, at least two partitions may include a first partition, a second partition, and a third partition. The application layer of the electronic device provides file read / write paths for the first and second partitions, and the local service layer of the electronic device provides file read / write paths for the third partition. In another possible implementation, the file read / write paths for the first, second, and third partitions can all be located at the application layer.

[0020] In one possible implementation, battery health status parameters may include at least one of the following: battery capacity decay, battery internal resistance, battery self-discharge rate, battery temperature, and battery leakage parameters. As battery usage time increases, the following phenomena may occur: each charge and discharge cycle causes a slight decrease in battery capacity; the degree of capacity decay can be calculated based on the battery's maximum and current capacity; battery internal resistance refers to the battery's internal impedance, which gradually increases with usage time; the battery slowly discharges even when not in use; the higher the self-discharge rate, the faster the battery health declines; by monitoring the battery self-discharge rate, the battery's ability to retain charge can be assessed; temperature affects battery performance and lifespan; excessively high or low temperatures accelerate battery aging; and battery leakage may occur. It is understood that these battery health status parameters are merely illustrative and do not limit the scope of this application. In actual implementation, electronic devices can collect more types of battery health status parameters and calculate the battery health status based on these parameters.

[0021] Secondly, this application provides an apparatus comprising units for performing the method described in the first aspect above. This apparatus is adapted to perform the method described in the first aspect above, and a description of the units within this apparatus is provided in the description of the first aspect above; for brevity, it will not be repeated here.

[0022] Thirdly, this application provides an electronic device comprising: one or more processors, and a memory. The memory is coupled to the one or more processors and is used to store computer program code, the computer program code including computer instructions, wherein the one or more processors invoke the computer instructions to cause the electronic device to perform the methods provided by the first aspect and any possible implementation thereof.

[0023] Fourthly, this application provides a computer-readable storage medium. The computer-readable storage medium includes computer instructions. When executed on an electronic device, the computer instructions cause the electronic device to perform the method provided by the first aspect and any possible implementation thereof.

[0024] Fifthly, this application provides a computer program product. When the computer program product is run on a computer, it causes the computer to perform the method provided by the first aspect and any possible implementation thereof.

[0025] In a sixth aspect, this application provides a chip system applied to an electronic device, the chip system including one or more processors, the one or more processors being configured to invoke computer instructions to cause the electronic device to perform the methods provided in the first aspect and any possible implementation thereof.

[0026] It is understood that the beneficial effects achieved by the apparatus of the second aspect, the electronic device of the third aspect, the computer-readable storage medium of the fourth aspect, the computer program product of the fifth aspect, and the chip system of the sixth aspect provided above can be referred to as the beneficial effects of the first aspect and any possible implementation thereof, which will not be repeated here. Attached Figure Description

[0027] Figure 1 A schematic diagram of the hardware structure of the electronic device provided in the embodiments of this application;

[0028] Figure 2 A schematic diagram of the software structure of the electronic device provided in the embodiments of this application;

[0029] Figure 3 A schematic diagram of multiple partitions provided for embodiments of this application;

[0030] Figure 4 This is a schematic flowchart of a method for writing data to multiple partitions provided in an embodiment of this application;

[0031] Figure 5 A schematic diagram of the CC-CV charging method provided in the embodiments of this application;

[0032] Figure 6 This is one of the flowcharts illustrating a method for reading data from multiple partitions provided in an embodiment of this application;

[0033] Figure 7 This is a second schematic flowchart illustrating a method for reading data from multiple partitions according to an embodiment of this application.

[0034] Figure 8 A schematic diagram illustrating the display of battery health status in the settings interface, provided as an embodiment of this application;

[0035] Figure 9 This is one of the flowcharts illustrating a method for synchronizing files in each partition during initialization, as provided in an embodiment of this application.

[0036] Figure 10 This is a second schematic diagram of a method for synchronizing files in each partition during initialization, provided in an embodiment of this application. Detailed Implementation

[0037] The terms "first" and "second," etc., used in the specification and drawings of this application are used to distinguish different objects or different treatments of the same object, rather than to describe a specific order of objects. Furthermore, the terms "comprising" and "having," and any variations thereof, mentioned in the description of this application are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or units is not limited to the listed steps or units, but may optionally include other steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or devices. In the embodiments of this application, "multiple" includes two or more. In the embodiments of this application, words such as "in some embodiments," "exemplary," or "for example" are used to indicate examples, illustrations, or explanations. Additionally, the scenarios described in the embodiments of this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided by the embodiments of this application. Those skilled in the art will understand that as new scenarios emerge, the technical solutions provided by the embodiments of this application are also applicable to similar technical problems.

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

[0039] Battery state of health (SOH), also known as battery health or battery health index, is an important indicator of battery health. Typically, SOH is expressed as the percentage of energy released when the battery is fully charged and discharged at a certain rate to a cutoff voltage under standard conditions, relative to its nominal rated energy. It reflects the battery's actual performance and remaining lifespan. A higher percentage indicates better battery performance and a longer remaining lifespan. The percentage decreases with the number of charge-discharge cycles, usage environment, temperature, and other factors. Battery state of health is crucial for a device's battery life and overall user experience. After a certain period of use, the battery's chemical properties change, leading to a decline in battery state of health, resulting in reduced energy storage capacity, faster device power consumption, and slower charging speeds.

[0040] Currently, electronic devices store a file that records parameters related to battery health (hereinafter referred to as battery health parameters). This file allows for periodic checks of battery health and the implementation of necessary maintenance. However, when an electronic device experiences severe memory depletion or abnormal shutdowns, the battery health parameters in this file may be lost or corrupted. Since these parameters cannot be recovered after loss or damage, the electronic device cannot obtain accurate data, affecting its assessment of battery health and potentially posing a risk to battery safety.

[0041] In view of the above problems, this application provides a file backup method. In this method, at least one backup partition is added to the original partition, and the original partition and the at least one backup partition are used to store the same files. Whenever battery health status parameters are modified, the electronic device updates the version number and content of the files in the original partition and the at least one backup partition. By adding at least one backup partition and periodically refreshing and repairing file content according to a version number control strategy, multi-file backup is achieved. This reduces the probability of losing battery health status parameters when the electronic device experiences severe memory shortages or abnormal shutdowns, thus improving file security.

[0042] The file backup method provided in this application can be applied to various electronic devices equipped with batteries. In some embodiments, the electronic device may be a terminal device. A terminal device may also be called a user equipment (UE), mobile station (MS), mobile terminal (MT), etc., and is a device that provides voice or data connectivity to a user. Specifically, a terminal device includes a device that provides voice to a user, or a device that provides data connectivity to a user, or a device that provides both voice and data connectivity to a user. For example, it may include a handheld device with wireless connectivity or a processing device connected to a wireless modem. The terminal device can communicate with the core network via a radio access network (RAN), exchanging voice or data with the RAN, or interacting with the RAN for both voice and data. Terminal devices can be: mobile phones, tablets, laptops, PDAs, mobile internet devices (MIDs), wearable devices, in-vehicle devices, virtual reality (VR) devices, augmented reality (AR) devices, wireless terminals in industrial control, smart home devices, smart robots, workshop equipment, wireless terminals in autonomous driving, wireless terminals in remote surgery, wireless terminals in smart grids, wireless terminals in transportation safety, wireless terminals in smart cities, or wireless terminals in smart homes, and flight equipment, etc. Terminal devices can also be other devices with terminal functions; for example, a terminal device can also be a device that performs terminal functions in D2D communication. Terminal devices may also include vehicle-to-everything (V2X) terminal devices, machine-to-machine / machine-type communications (M2M / MTC) terminal devices, Internet of Things (IoT) terminal devices, light UEs, reduced-capacity user equipment, subscriber units, subscriber stations, mobile stations, remote stations, access points (APs), remote terminals, access terminals, user terminals, user agents, or user devices, and drone equipment, etc.This application does not impose any restrictions on the specific type of electronic device.

[0043] It should be noted that the electronic device may be a device or apparatus with a chip, or a device or apparatus with integrated circuits, or a chip, module or control unit in the device or apparatus shown above, and this application does not limit the specific.

[0044] For example, Figure 1 This is a schematic diagram of the hardware structure of an electronic device provided in an embodiment of this application.

[0045] like Figure 1 As shown, the electronic device 100 may include a processor 110, internal memory 120, buttons 130, sensor module 140, display screen 150, audio module 160, speaker 160A, receiver 160B, microphone 160C, headphone jack 160D, universal serial bus (USB) interface 170, charging management module 180, power management module 181, battery 182, etc.

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

[0047] Internal memory 120 can be used to store executable program code, including instructions. Processor 110 executes various functional applications and data processing of electronic device 100 by running the instructions stored in internal memory 120. Internal memory 120 may include a program storage area and a data storage area. The program storage area may store the operating system and at least one application program (APP) required for a given function. The data storage area may store configuration files for each APP, as well as data created during the use of electronic device 100.

[0048] Button 130 may include a power button, volume buttons, etc. Button 130 may 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.

[0049] The sensor module 140 may include various types of sensors, such as pressure sensors, gyroscope sensors, barometric pressure sensors, magnetic sensors, accelerometers, distance sensors, proximity sensors, fingerprint sensors, temperature sensors, touch sensors, ambient light sensors, and bone conduction sensors.

[0050] The display screen 150 may include a display panel for displaying various interfaces and images, etc.

[0051] Electronic device 100 can implement audio functions through an audio module 160, a speaker 160A, a receiver 160B, a microphone 160C, a headphone jack 160D, and an application processor. Examples include music playback and recording. The audio module 160 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 160 can also be used for encoding and decoding audio signals. In some embodiments, the audio module 160 can be located in the processor 110, or some functional modules of the audio module 160 can be located in the processor 110.

[0052] The charging management module 180 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 180 receives charging input from the wired charger via a USB interface 170. In some wireless charging embodiments, the charging management module 180 receives wireless charging input via the wireless charging coil of the electronic device 100. While charging the battery 182, the charging management module 180 can also supply power to the electronic device 100 via the power management module 181.

[0053] The power management module 181 connects the battery 182, the charging management module 180, and the processor 110. The power management module 181 receives input from the battery 182 and / or the charging management module 180, providing power to the processor 110, internal memory 120, external memory, display screen 150, camera, and wireless communication module, etc. The power management module 181 can also monitor battery capacity, battery cycle count, battery health status (leakage current, impedance) parameters, etc. In some other embodiments, the power management module 181 may also be located within the processor 110. In other embodiments, the power management module 181 and the charging management module 180 may be located in the same device.

[0054] It is understood that the structures illustrated in the embodiments of this application do not constitute a specific limitation on the electronic device 100. In other embodiments of this application, 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.

[0055] The software system of an electronic device 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 an electronic device.

[0056] Figure 2 This is a schematic diagram of the software structure of an electronic device according to an embodiment of this application. The layered architecture divides the software into several layers, each with a clear role and function. Layers communicate with each other through software interfaces. In some embodiments, the Android system's software layers are divided from top to bottom as follows: application layer, native service layer, and kernel layer, etc. Furthermore, for ease of understanding, Figure 2 The hardware layer of the electronic device is also shown.

[0057] It's important to note that Android is an operating system based on Linux. The development of upper-layer applications (such as the application layer and application framework layer) in Android is generally done using Java. Because some lower-level tasks (such as the kernel layer) are not easily implemented in Java, tasks involving local services, link libraries, or hardware drivers are usually implemented using C programs, which run in system libraries. These system libraries include interfaces for Java to call C++ code.

[0058] The application layer, also known as the application package layer, can include a series of applications and application packages, such as the Smart Charge application. Additionally, the application layer can provide read / write paths for partition files, such as the read / write paths for partition 1 and partition 2. The Smart Charge application can be used to enable or disable low-power mode, manage battery health, monitor battery level, monitor battery temperature, monitor screen usage activity, and monitor battery usage and power consumption ratios for various apps. As an example, the Smart Charge application can include a version read / write management module, a battery management module, and a parameter update module. The parameter update module modifies the battery health parameters according to a first preset cycle or triggered by a response event. The version read / write management module updates the version numbers and contents of files in the original partition and at least one backup partition (e.g., partition 1, partition 2, and partition 3) based on the battery health parameters modified by the parameter update module. The version read / write management module can also be used during electronic device operation to read files from the original partition and at least one backup partition, selecting the file with the highest version number (also known as the maximum version number) as the trusted file. The battery management module determines the charging parameters corresponding to the current battery state and controls the power management module to charge the battery according to these parameters. The specific functions of each module can be found in the description of the following embodiments. When these apps or application packages are run, they can access the various service modules provided by the framework layer through the application programming interface (API) and execute corresponding intelligent business processes.

[0059] The local service layer provides common local services and some linked libraries. This layer is characterized by being implemented in C or C++. The local service layer connects the upper layers and hardware drivers. In some embodiments, the local service layer can broadcast events reported by the kernel layer, enabling the application layer to scan for these broadcasts. For example, NativeService broadcasts events reported by the USB driver indicating that a charger has been plugged into a USB port, allowing smart charging applications to scan for these broadcasts and begin controlling battery charging and monitoring battery temperature and health.

[0060] In some embodiments, the local service layer can provide Hardware Interface Definition Language (HIDL) interfaces, such as a battery status interface and a parameter sending interface. The battery status interface is used to obtain the battery status from the underlying layer, and the parameter sending interface is used to send CV parameters to the underlying layer. Additionally, the application can provide read / write paths for partition files, for example, the read / write path for partition 3.

[0061] It should be noted that, Figure 2 This example uses HIDL interfaces for the battery status interface and parameter delivery interface, but it does not limit the scope of this application. In other embodiments, the battery status interface and parameter delivery interface can also be Android Interface Definition Language (AIDL) interfaces located at the application layer. HIDL and AIDL are two interface definition languages ​​used to define and implement interfaces between different layers in the Android system. Both interfaces specify methods, parameters, and return values ​​in their definition files, and both support remote procedure call (RPC) mechanisms, allowing method calls and data transfer between different processes. The difference between these two interfaces is that HIDL is mainly used in the hardware abstraction layer to provide interface definitions for communication with hardware devices; AIDL is mainly used in the application layer to define interfaces between application components. Furthermore, HIDL uses C++ syntax, allowing direct use of native C++ features such as pointers and references in interface definitions; AIDL uses Java-like syntax and supports some specific data types and tags. The choice of which interface definition language to use can be determined based on specific application scenarios, performance requirements, and development methods.

[0062] The kernel layer is the interface layer between hardware and software. It can contain various drivers. Drivers are configuration files written by hardware manufacturers for the operating system, containing information about the hardware devices. By adding drivers to the operating system, electronic devices can communicate with the corresponding hardware devices. For example, the kernel layer might include a USB driver for communicating with the USB chip and USB interface, a fuel gauge driver for communicating with the battery, and a parameter execution module for communicating with the power management module. The fuel gauge driver obtains data such as charging voltage, charging current, charging capacity, and battery health status parameters from the battery; the parameter execution module controls the power management module to charge the battery according to the CV parameters determined by the battery status acquisition and management module.

[0063] The hardware layer can include various hardware chips and functional modules, such as buttons (e.g., power button), USB interfaces, power management modules, and batteries. The power management module receives input from the battery and / or charging management module to power the processor, internal memory, external memory, display, camera, and wireless communication modules. It can also monitor battery capacity, battery cycle count, and battery health parameters. The battery can include cells, a battery protection board, and a fuel gauge chip. The fuel gauge chip collects the temperature of the battery protection board as the battery temperature, and collects the charging current and voltage values. The USB interface is a USB standard-compliant interface, such as Mini USB, MicroUSB, or USB Type-C. One approach is to connect the USB interface to a charger, which charges the electronic device. Another approach is to connect the USB interface to a peripheral device for data transfer between the electronic device and the peripheral device. As an example, the power management module can be located in a DSP, such as an advanced digital signal processor (ADSP).

[0064] It should be noted that although this application uses the Android system as an example for illustration, its basic principles are equally applicable to electronic devices based on operating systems such as iOS or Windows. Furthermore, Figure 2 The layers in the illustrated software structure and the components contained in each layer do not constitute a specific limitation on the electronic device. In other embodiments, the electronic device may include more layers than illustrated. Each layer may include more or fewer components than illustrated. Furthermore, the various functional modules described above may be combined into a single functional module, or a single functional module may consist of multiple functional modules.

[0065] The execution subject of the file backup method provided in this application embodiment can be the aforementioned electronic device, or a functional module and / or functional entity in the electronic device that can implement the file backup method. Furthermore, the solution of this application can be implemented by hardware and / or software, and can be determined according to actual usage requirements.

[0066] The following detailed embodiments illustrate how the technical solution of this application addresses the technical problem that files used to record battery health status may be lost or corrupted when an electronic device experiences severe memory shortage or abnormal shutdown, thus posing a risk to battery safety. These specific embodiments can be implemented independently or in combination. Similar or identical concepts or processes may not be described again in some embodiments.

[0067] For example, Figure 3 This is a schematic diagram of multiple partitions provided in an embodiment of this application.

[0068] A partition is a logical storage unit used to differentiate the permanent storage structure within an electronic device. Typically, each partition in an electronic device is used to store different types of data. Taking a mobile phone as an example, common partitions in an Android system include: a root (boot) partition, used to store the boot image file, containing files such as the Linux kernel, equivalent to a personal computer's basic input / output system (BIOS), used to initialize the hardware and software environment and boot the phone; a system partition, used to store the core files of the operating system and applications, including the Android user interface (UI) and pre-installed apps; a data partition, used to store user data and application private data, such as contacts, SMS messages, and application data; a cache partition, used to store temporary data to speed up system and application loading; and a recovery partition, used to store a small boot image file for troubleshooting and system recovery. Partitioning can improve phone responsiveness and performance, reduce conflicts and system crashes. Partitioning allows for better data management, such as separating applications, media files, and personal data for faster access. In addition, partitioning can prevent data loss or theft because different partitions can be set with different access permissions, thus effectively protecting sensitive data.

[0069] In this embodiment, the electronic device has at least two partitions, which can be understood as two different paths, both storing files used to record battery health status parameters. As an example, these at least two partitions can be common partitions of the electronic device, i.e., reusing traditional partitions to implement the file backup method provided in this embodiment. As another example, these at least two partitions can be newly added partitions distinct from traditional partitions, i.e., utilizing the newly added partitions to implement the file backup method provided in this embodiment. Furthermore, the size of each of the at least two partitions can be adjusted according to actual usage needs; for example, the sizes of the partitions can be the same or different.

[0070] Under normal circumstances, when the parameter update module modifies the battery health status parameters, the version read / write management module can simultaneously update the version numbers of at least two partitions (e.g., incrementing the version number by 1 with each update) and record the modified battery health status parameters in the file, thus ensuring that the version numbers and contents of the files in at least two partitions are identical. However, when the electronic device experiences severe memory shortages or abnormal shutdowns, backup files in some partitions may be lost or corrupted, while backup files in other partitions may remain intact. In this case, the electronic device can determine the battery health status based on the intact files.

[0071] like Figure 3 As shown, the electronic device's first, second, and third partitions are used to store backup files. The first partition is the original partition, while the second and third partitions are backup partitions. Backup files in the first partition are called the first backup file, those in the second partition are called the second backup file, and those in the third partition are called the third backup file. Under normal circumstances, the first, second, and third backup files have the same version number (e.g., all are Version 9.0), and their contents are also identical (e.g., all have a battery capacity degradation of 95%). When the electronic device experiences severe memory shortages or abnormal shutdowns, if the electronic device only reads the version number of the third backup file, or if the version number of the third backup file is higher than that of the first and second backup files, then it can be determined that the first and second backup files are lost or corrupted, while the third backup file is normal. The third backup file is then considered a trusted file. That is, the trustworthiness of the third backup file is greater than that of the first and second backup files. Subsequently, the electronic device can determine the battery health status based on the third backup file.

[0072] As an example, the backup file could be a JavaScript object notation (JSON) file.

[0073] Compared to using only one partition for file storage, which can easily lead to file loss, this application adds at least one backup partition to the original partition. Both the original partition and the at least one backup partition store the same files. By adding at least one backup partition, multiple file backups are achieved. This reduces the probability of losing battery health parameters when the electronic device experiences severe memory shortages or abnormal shutdowns, thus improving file security. It should be noted that... Figure 3This explanation uses a setup with three partitions (one primary partition and two backup partitions) as an example and does not limit the scope of this application. It is understood that the more partitions used to store backup files, the more backup files there are, and the lower the probability of losing battery health status parameters.

[0074] Referring to the description of the above embodiments, the version read / write management module has at least two functions: the first function is to update the version number and content of files in at least two partitions (including one original partition and at least one backup partition) based on the modified battery health status parameters when the parameter update module modifies them; the second function is to read files from the at least two partitions respectively during the operation of the electronic device and select the file with the highest version number as the trusted file. The specific implementation of these two functions will be illustrated below with reference to Embodiment 1 and Embodiment 2, using the storage of backup files through a first partition, a second partition, and a third partition as an example, where the first partition is the original partition and the second and third partitions are two newly added backup partitions.

[0075] Example 1:

[0076] In some embodiments, battery health status parameters can be used to characterize the battery's health status. For example, battery health status parameters may include, but are not limited to, battery capacity decay, battery internal resistance, battery self-discharge rate, battery temperature, and battery leakage parameters. As battery usage time increases, the following phenomena may occur: each charge and discharge cycle causes a slight decrease in battery capacity; the degree of capacity decay can be calculated based on the battery's maximum and current capacity; battery internal resistance refers to the battery's internal impedance, which gradually increases with usage time; the battery slowly discharges even when not in use; the higher the self-discharge rate, the faster the battery's health declines; by monitoring the battery's self-discharge rate, the battery's ability to retain charge can be assessed; temperature affects battery performance and lifespan; excessively high or low temperatures accelerate battery aging; and battery leakage may occur. It is understood that these battery health status parameters are merely illustrative and do not limit the scope of this application. In actual implementation, electronic devices can collect more types of battery health status parameters and calculate the battery health status based on these parameters.

[0077] In some embodiments, the version read / write management module can respond to a first event, triggering the parameter update module to obtain battery health status parameters. When the parameter update module modifies the battery health status parameters, the module updates the version numbers and contents of files in the first, second, and third partitions based on the modified battery health status parameters. The first event can be a preset event such as a screen on / off event, a power-on event, a charger plugging event, or a battery level change event.

[0078] In other embodiments, the version read / write management module can send instructions to the parameter update module to retrieve battery health status parameters according to a first preset cycle. When the parameter update module modifies the battery health status parameters, the version read / write management module can update the version numbers and contents of files in the first, second, and third partitions based on the modified battery health status parameters.

[0079] For example, Figure 4 This is a schematic flowchart illustrating a method for writing data to multiple partitions, as provided in an embodiment of this application.

[0080] like Figure 4 As shown, the method may include the following S01 to S10.

[0081] S01, the USB driver receives the user's command to plug the charger into the USB interface.

[0082] The electronic device provided in this application embodiment involves two states: a power-on state and a power-off state. The power-on state, also known as the on-state, refers to the power management module receiving input from the battery to power modules such as the processor, display, and internal memory, enabling these modules to operate normally. The power-off state, also known as the off state, refers to the power management module cutting off the battery's power supply to modules such as the processor, display, and internal memory, causing these modules to stop working. As an example, when the electronic device is in the power-on state, the USB driver receives an operation to plug a charger into the USB interface.

[0083] S02, the USB driver reports charging events to the smart charging application through the battery status interface.

[0084] In some embodiments, the charger is a wired charger, and the charging event is an event triggered by inserting the charger into a USB port. In other embodiments, the charger is a wireless charger, allowing the user to place an electronic device on it, thereby enabling the charging management module to acquire a charging event via the wireless charging coil of the electronic device.

[0085] The battery management module and version read / write management module of the smart charging application respectively acquire charging events.

[0086] On the one hand, after the battery management module obtains the charging event, it executes the following S03 to S04.

[0087] On the other hand, after the version read / write management module obtains the charging event, it executes the following S05 to S10.

[0088] S03, the battery management module sends charging parameters to the parameter execution interface through the parameter sending interface.

[0089] S04, the parameter execution interface notifies the power management module to charge the battery according to the charging parameters.

[0090] This explanation uses constant current and constant voltage (CC-CV) charging in electronic devices as an example. Electronic devices can use lithium-based batteries, such as lithium-ion batteries. Regarding CC-CV charging: because lithium batteries exhibit polarization (the instantaneous voltage is not the steady-state voltage), during the CC phase, the charging current is relatively large, resulting in a fast charging speed. After the charging voltage rises to the upper limit, a constant potential is maintained. Electrons in the external circuit react with lithium cations (Li+) at the negative electrode. As lithium intercalation occurs at the negative electrode, the number of active sites decreases, the number of electrons participating in the reaction decreases, and the current gradually decreases. When the current decreases to 0, polarization is eliminated, and the lithium battery is fully charged.

[0091] For example, Figure 5 This is a schematic diagram of the CC-CV charging method provided in an embodiment of this application. Figure 5 As shown, the CC-CV charging method typically involves two stages: the CC stage and the CV stage. In the CC stage, the electronic device charges at a constant current. As charging time increases, the charging voltage gradually rises. When the charging voltage reaches the cutoff voltage, the device enters the CV stage. In the CV stage, the electronic device charges at a constant voltage. As charging time continues, the charging current gradually decreases. When the charging current drops to the cutoff current value, charging is complete, and further charging stops. As an example, these constant current and constant voltage values ​​are preset and can be obtained by the battery management module from a preset path.

[0092] S05, in response to the charging event, the version read / write management module sends a battery health status parameter acquisition command to the parameter update module. The parameter update module then sends this battery health status parameter acquisition command to the fuel gauge driver via the battery status interface.

[0093] The above battery health status parameter acquisition command is used to instruct the acquisition of battery health status parameters.

[0094] In some embodiments, the above-mentioned battery health status parameter acquisition instruction may include:

[0095] ① Types of battery health status parameters.

[0096] For example, during the charging process, battery health status parameters may include: battery capacity decay, battery internal resistance, battery self-discharge rate, battery temperature, and battery leakage parameters.

[0097] ② The number of times and the collection period for each type of battery health status parameter.

[0098] Because the variation patterns of health status parameters differ for each type of battery, the number of times and the collection period for each parameter can vary. For example, each charge and discharge cycle causes a slight decrease in battery capacity, while the change in capacity decay during a single charge is relatively small. Therefore, it is permissible to calculate battery capacity decay only once during a single charge. Furthermore, during a single charge, the battery temperature may change at any time due to various factors such as environment, charging type, and charging time. Therefore, the battery temperature can be collected every preset interval (e.g., 10 seconds) during a single charge.

[0099] S06, in response to the battery health status parameter acquisition command, the fuel gauge drives the acquisition of battery health status parameters.

[0100] If the battery health status parameter acquisition instruction includes the number of acquisitions and the acquisition period for each type of battery health status parameter, then the fuel gauge driver can acquire the battery health status parameters according to the number of acquisitions and the acquisition period corresponding to each type of battery health status parameter.

[0101] It should be noted that the above embodiment is illustrated using the fuel gauge driver responsible for collecting battery health status parameters. It can be understood that in actual implementation, other modules can also be used to collect battery health status parameters.

[0102] S07, the fuel gauge driver returns battery health status parameters to the parameter update module through the battery status interface.

[0103] S08, the parameter update module determines whether the battery status parameters need to be updated.

[0104] If the battery status parameters returned by S07 are the same as the previously obtained battery status parameters, then there is no need to update the battery status parameters. If the battery status parameters returned by S07 are different from the previously obtained battery status parameters, then the battery status parameters need to be updated, and S09 below should be executed.

[0105] S09, the parameter update module sends the updated battery status parameters to the version read / write management module.

[0106] The battery status parameters sent by the parameter update module to the version read / write management module may include: the name / type of the battery status parameter and the value of the updated battery status parameter.

[0107] S10: The version read / write management module updates the version numbers and contents of files in the first, second, and third partitions based on the updated battery health status parameters. Specifically, the updated version numbers of files in the first, second, and third partitions are identical, and the contents of files in the new first, second, and third partitions are also identical.

[0108] In some embodiments, the version read / write management module can update the file version number according to a preset encoding rule each time the battery health status parameters are updated. For example, each time the file version number is updated, the version number is incremented by 1, 0.1, or 0.01.

[0109] In some embodiments, updating the contents of files in each partition includes: overwriting the original battery health status parameters with the updated battery health status parameters.

[0110] It should be noted that, Figure 4 This explanation uses the example of writing file version numbers and contents to multiple partitions in response to a charger insertion event, and does not limit the scope of this application. Referring to the description of the above embodiments, the electronic device may also write file version numbers and contents to multiple partitions in response to screen on / off events, power-on events, or battery level change events.

[0111] In the writing method provided in this application, when the parameter update module modifies the battery health status parameters, the version read / write management module can simultaneously update the version numbers and contents of files in multiple partitions based on the modified battery health status parameters, ensuring that the version numbers and contents of files in each partition remain consistent. Thus, when files in some partitions are lost or corrupted, the electronic device can read the files that are not lost or corrupted from other partitions.

[0112] Example 2:

[0113] In some embodiments, the version read / write management module can respond to a second event by reading files from the first, second, and third partitions respectively, and selecting the file with the highest version number as the trusted file. The second event can be the same as the first event, or it can be a different event. For example, the second event can be a preset event such as a screen on / off event, a power-on event, a charger plugging event, or a battery level change event.

[0114] In other embodiments, the version read / write management module can read files from the first partition, the second partition, and the third partition according to a second preset period, and select the file with the highest version number as the trusted file. The second preset period can be greater than or equal to the first preset period.

[0115] After the version read / write management module selects a file in the target partition as a trusted file, it can also copy the trusted file to other partitions besides the target partition, so that the version number and content of the files in the first partition, the second partition and the third partition are the same, which makes it easier to read the file normally next time.

[0116] For example, Figure 6 This is a schematic flowchart illustrating a method for reading data from multiple partitions, as provided in an embodiment of this application.

[0117] like Figure 6 As shown, the method may include the following steps S11 to S18.

[0118] S11, when the electronic device is powered on, the input driver receives the user's input to light up the screen.

[0119] The screen-on operation described above is the operation that triggers the electronic device to switch from a screen-off state to a screen-on state.

[0120] For example, screen-on operations can include pressing the power button on the electronic device, tapping the screen, shaking the electronic device, or using voice commands.

[0121] S12, the input driver reports the event corresponding to the screen-on operation (called the screen-on event) to the battery management module.

[0122] The aforementioned screen-on event is the event that triggers the electronic device to turn on its screen.

[0123] Taking the screen-on operation as an example, the corresponding event is the screen click event. After the input driver receives the screen click event, it writes the event to the corresponding input device node. Then, the input management service reads the event from the device node and passes it up layer by layer until it reaches the battery management module of the smart charging application.

[0124] S13, the battery management module instructs the version read / write management module to read the battery health status parameters.

[0125] S14, for multiple partitions, the version read / write management module reads backup files from each partition.

[0126] Specifically, the version read / write management module can read the version number and content of backup files from each partition.

[0127] Under normal circumstances, when the parameter update module modifies the battery health status parameters, the version read / write management module can simultaneously update the version number of each partition and record the modified battery health status parameters in the file, thus ensuring that the version number and content of the files in multiple partitions are identical. However, when the electronic device experiences severe memory shortages or abnormal shutdowns, backup files in some partitions may be lost or corrupted, while backup files in other partitions may remain intact. In this case, the version read / write management module may read different version numbers and contents of the backup files from each partition.

[0128] S15, the version read / write management module selects the file with the highest version number (such as the first backup file of the first partition) as the trusted file based on the version number of these files.

[0129] The first partition mentioned above is also called the first target partition.

[0130] For each of the first, second, and third partitions, the version read / write management module can determine whether the backup file has been successfully read. If it fails, it returns to continue reading the backup file. If it succeeds, it performs the following steps: After obtaining the files in each partition, it selects the file with the highest version number as the trusted file based on the version number of these files.

[0131] Let's take an electronic device with partition 1 and partition 2 as an example. Figure 7 As shown, after the version read / write management module reads the files in partition 1 and partition 2, the following steps can be performed:

[0132] The version read / write management module determines whether the condition "partition 1 = 1 && partition 2 = 1" is met. If so, the module copies the file with the highest version number (selecting the file with the highest version number from partitions 1 and 2) to the other partitions and returns the file with the highest version number to the battery management module. If the condition "partition 1 = 1 && partition 2 = 1" is not met, the module determines whether the condition "partition 1 = 1 && partition 2 = 0" is met.

[0133] If the condition "partition 1 = 1 && partition 2 = 0" is met, the version read / write management module copies the file from partition 1 to partition 2 and returns the file from partition 1 to the battery management module. If the condition "partition 1 = 1 && partition 2 = 0" is not met, the version read / write management module determines whether the condition "partition 1 = 0 && partition 2 = 1" is met.

[0134] If the condition "partition 1 = 0 && partition 2 = 1" is met, the version read / write management module copies the file from partition 2 to partition 1 and returns the file from partition 2 to the battery management module. If the condition "partition 1 = 0 && partition 2 = 1" is not met, the version read / write management module determines whether the condition "partition 1 = 0 && partition 2 = 0" is met, and then ends the determination process.

[0135] In the above steps, && is a logical operator representing logical AND; partition1=1 means partition1 has backup files, partition1=0 means partition1 does not have backup files, partition2=1 means partition2 has backup files, and partition2=0 means partition2 does not have backup files. It can be understood that when both partitions have files, the file with the highest version number can be selected as the trusted file by comparing version numbers; when one partition has no files and the other has files, that file can be directly selected as the trusted file; when neither partition has files, it is impossible to determine a trusted file.

[0136] S16, the version read / write management module returns the trusted file to the battery management module.

[0137] S17, the battery management module determines the battery health status based on this trusted file.

[0138] The aforementioned trusted file records the latest battery health status parameters obtained by the electronic device. The trusted file has a higher degree of trust than other files. Therefore, the battery management module makes a comprehensive judgment on the battery health status based on the battery health status parameters in the trusted file.

[0139] As an example, battery health status can be divided into four levels: Average, Normal, Good, and Excellent. "Average" indicates low battery health, which may require replacement; "Normal" indicates the battery is usable, but its range is reduced; "Good" indicates the battery is in good condition and its range is still strong; and "Excellent" indicates the battery is in superb condition, with range approaching that of a new battery.

[0140] In some embodiments, after the battery management module determines the battery health status, it can display the battery health status to the user in the user interface to help the user understand the battery's range and determine whether the battery needs to be replaced.

[0141] For example, Figure 8 This is a schematic diagram illustrating the display of battery health status in the settings interface, provided as an embodiment of this application. When a user wants to view the battery health status, they can open the Settings app and click the Battery option. Figure 8 As shown, the battery settings interface displays the remaining battery power, performance mode, low power mode, battery usage, and more battery settings options. Users can click on "More Battery Settings" to access the device's additional battery settings interface. This interface displays the battery's health status, which helps users plan usage time and charging schedules based on the battery's health level, thereby extending battery life. For example, users can determine whether to enable features such as smart charging mode and smart peak capacity, according to their needs.

[0142] In other embodiments, after the battery management module determines the battery health status, the electronic device can display the battery health status to the user in the form of a notification message or a floating window if the battery health status meets certain preset conditions. For example, when the battery health status is average, the electronic device can display a notification message such as "The current battery health is low, please replace the battery in time."

[0143] S18, the version read / write management module writes the version number and content of the trusted file to the second and third partitions.

[0144] Before the version number and content of the trusted file are written to the second and third partitions, there are no backup files stored in the second and third partitions, or the versions of the backup files in the second and third partitions are lower than the version of the trusted file. After the version number and content of the trusted file are written to the second and third partitions, the version number and content of the backup files in the first, second, and third partitions are the same.

[0145] In the reading method provided in this application, the version numbers and contents of files in each partition are consistent. However, when an electronic device experiences severe memory shortages or abnormal shutdowns, backup files in some partitions may be lost or corrupted, while those in others may remain intact. In such cases, the version read / write management module may read different version numbers and contents of backup files from each partition. By selecting the file with the highest version number as the trusted file, the reliability of the battery health status calculated based on the battery health status parameters of that trusted file can be guaranteed. Furthermore, after selecting files in the target partition as trusted files, copying these trusted files to other partitions besides the target partition ensures that the version numbers and contents of files in the first, second, and third partitions are identical, facilitating normal file retrieval should the problem recur.

[0146] The above examples, exemplified by Embodiment 1 and Embodiment 2, introduced two functions of the version read / write management module: The first function is to update the version numbers and contents of files in at least two partitions based on the modified battery health status parameters when the parameter update module modifies them; the second function is to read files from these at least two partitions during electronic device operation and select the file with the highest version number as the trusted file. In addition, the version read / write management module also has the function of synchronizing files across partitions during initialization.

[0147] The following example, using Embodiment 3, illustrates the specific implementation of this function.

[0148] Example 3:

[0149] For example, Figure 9This is a schematic flowchart illustrating a method for synchronizing files across partitions during initialization, as provided in an embodiment of this application. Figure 9 As shown, the method may include the following steps S19 to S24.

[0150] S19, when the electronic device is powered off, the input driver receives the power-on operation input by the user.

[0151] The aforementioned power-on operation is the action that triggers the electronic device to switch from a power-off state to a power-on state. For example, the power-on operation can be a long press of the power button on the electronic device by the user.

[0152] S20, the input driver reports the event corresponding to the power-on operation (called the power-on event) to the battery management module.

[0153] The aforementioned power-on event is the event that triggers the electronic device to power on, that is, the event that triggers the electronic device to turn on.

[0154] Taking a long press of the power button as an example of power-on operation, the corresponding event is the long press event of the power button. After the input driver receives the long press event of the power button, the input driver will write the event to the corresponding input device node. Then, the input management service will read the event from the device node and pass the event up layer by layer until it reaches the battery management module of the smart charging application.

[0155] It should be noted that S19 and S20 described above are illustrative examples of a smart charging application obtaining a power-on event based on a power-on operation, and do not limit this application. In some other embodiments, when an electronic device unexpectedly powers down due to a malfunction, the electronic device can restart according to default settings. In this case, the smart charging application can also obtain a power-on event. In still other embodiments, the user can set the electronic device to switch from a power-off state to a power-on state at a preset time point. When the system time reaches the preset time point, the electronic device powers on. In this case, the smart charging application can also obtain a power-on event. It is understood that the smart charging application can also obtain power-on events in other scenarios.

[0156] S21, the battery management module instructs the version read / write management module to read the battery health status parameters.

[0157] When an electronic device shuts down abnormally, backup files in some partitions may be lost or corrupted, while backup files in other partitions may remain intact. To enable the battery management module to read these backup files during operation, file synchronization can be achieved through the three partitions described below (S22 to S24) during the initialization process when the electronic device is powered on.

[0158] S22, for multiple partitions, the version read / write management module reads backup files from each partition.

[0159] Specifically, the version read / write management module can read the version number and content of backup files from each partition. However, in the event of an abnormal shutdown, the version number and content read by the version read / write management module from each partition may differ.

[0160] S23, the version read / write management module selects the file with the highest version number (such as the first backup file of the first partition) as the trusted file based on the version number of these files.

[0161] The first partition mentioned above is also called the second target partition.

[0162] For each of the first, second, and third partitions, the version read / write management module can determine whether the backup file has been successfully read. If it fails, it returns to continue reading the backup file. If it succeeds, it performs the following steps: After obtaining the files in each partition, it selects the file with the highest version number as the trusted file based on the version number of these files.

[0163] Let's take an electronic device configured with partitions 1, 2, and 3 as an example. Figure 10 As shown, after the version read / write management module reads the files in partitions 1, 2, and 3, the following steps can be performed:

[0164] The version read / write management module determines whether the following conditions are met: "Partition 1 = 1 && Partition 2 = 0 && Partition 3 = 0". If the conditions are met, the version read / write management module copies the files from partition 1 to partitions 2 and 3. If the conditions are not met, the version read / write management module determines whether the following conditions are met: "Partition 1 = 0 && Partition 2 = 1 && Partition 3 = 0".

[0165] If the condition "partition 1 = 0 && partition 2 = 1 && partition 3 = 0" is met, then the version read / write management module copies the files from partition 2 to partition 1 and partition 3. If the condition "partition 1 = 0 && partition 2 = 1 && partition 3 = 0" is not met, then the version read / write management module determines whether the condition "partition 1 = 0 && partition 2 = 0 && partition 3 = 1" is met.

[0166] If the condition "partition 1 = 0 && partition 2 = 0 && partition 3 = 1" is met, then the version read / write management module copies the file in partition 3 to partitions 1 and 2. If the condition "partition 1 = 0 && partition 2 = 0 && partition 3 = 1" is not met, then the version read / write management module searches for the file with the highest version number in partitions 1, 2, and 3, and copies the file with the highest version number to the other partitions.

[0167] In the above steps, && is a logical operator, representing logical AND; partition1=1 means partition1 has a backup file, partition1=0 means partition1 does not have a backup file, partition2=1 means partition2 has a backup file, partition2=0 means partition2 does not have a backup file, partition3=1 means partition3 has a backup file, partition3=0 means partition3 does not have a backup file. It can be understood that when at least two partitions have files, the file with the highest version number can be selected as the trusted file by comparing version numbers; when only one partition has a file, that file can be directly selected as the trusted file; when none of the three partitions have files, it is impossible to determine a trusted file.

[0168] S24, the version read / write management module writes the version number and content of the trusted file to the second and third partitions.

[0169] It should be noted that the difference between Embodiment 2 and Embodiment 3 is as follows: In Embodiment 2, the version read / write management module, in response to the second event or according to the second preset period, selects the file with the highest version number from the first partition, the second partition, and the third partition as a trusted file, and must return the trusted file to the battery management module so that the battery management module can comprehensively judge the battery health status based on the battery health status parameters in the trusted file; while in Embodiment 3, the version read / write management module selects the file with the highest version number from the first partition, the second partition, and the third partition as a trusted file during initialization to synchronize the files in each partition, but does not need to return the trusted file to the battery management module.

[0170] In the initialization method provided in this application, when the electronic device shuts down abnormally, backup files in some partitions may be lost or corrupted. During power-on initialization, the backup files of each partition are synchronized to ensure that the version number and content of each backup file are consistent. Thus, even if problems such as severe memory shortage occur during operation, the electronic device can still assess the battery health status based on the battery health status parameters of the backup files because some partitions still store backup files that have not been corrupted or lost.

[0171] This application also provides a computer-readable storage medium storing instructions thereon, which, when executed on a computer, cause the computer to perform some or all of the steps of any of the methods described above.

[0172] This application also provides a computer program product including instructions, which, when executed by a computer, performs some or all of the steps of any of the methods described above.

[0173] This application also provides a chip or chip system, which may include a processor. The chip may further include a memory (or storage module) and / or a transceiver (or communication module), or the chip may be coupled to a memory (or storage module) and / or a transceiver (or communication module), wherein the transceiver (or communication module) can be used to support the chip in wired and / or wireless communication, and the memory (or storage module) can be used to store a program. The processor can call the program to implement the operations performed by an electronic device or network device in any of the above method embodiments or any possible implementations of the method embodiments. The chip system may include the above-mentioned chip, or may include the above-mentioned chip and other discrete devices, such as a memory (or storage module) and / or a transceiver (or communication module).

[0174] The device provided in this application embodiment 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. A computer program product includes one or more computer instructions. When the computer instructions are loaded and executed on a computer, all or part of the flow or function according to the embodiments of this application is 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, 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 can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., high-density digital video discs (DVDs)), or semiconductor media (e.g., SSDs), etc.

[0175] It should be understood that the term "and / or" in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, the character " / " in this article generally indicates that the preceding and following related objects have an "or" relationship.

[0176] It should be understood that, in the embodiments of this application, the order of the above-mentioned processes does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0177] Those skilled in the art will recognize that the units and algorithm steps of the various examples 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.

[0178] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0179] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, 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 coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0180] 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.

[0181] 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.

[0182] The above are merely specific embodiments 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 file backup method, characterized in that, The method includes: In response to the first event, update the battery health status parameters, and based on the battery health status parameters, update the version number and content of the backup files in each of at least two partitions, wherein the version number of the backup files in each of the updated partitions is the same and the content of the backup files is the same; In response to the second event, the version number and content of the backup file are read from each partition, and the battery health status is determined based on the content of the backup file in the first target partition of the at least two partitions, wherein the version number of the backup file in the first target partition is higher than the version number of the backup file in the other partitions of the at least two partitions.

2. The method according to claim 1, characterized in that, In response to the second event, the version number and content of the backup file are read from each partition, and the battery health status is determined based on the content of the backup file in the first target partition of the at least two partitions, including: In response to the second event, the version number and content of the backup file are read from each of the partitions; It is determined that the version number of the backup file in the first target partition is higher than the version number of the backup file in the other partitions, and the content of the backup file in the first target partition includes the updated battery health status parameters; The battery health status is determined based on the battery health status parameters of the backup files in the first target partition.

3. The method according to claim 2, characterized in that, After determining that the version number of the backup file in the first target partition is higher than the version number of the backup file in the other partitions, the method further includes: Write the version number and content of the backup file in the first target partition to the other partitions; Specifically, after the version number and content of the backup file in the first target partition are written to the other partitions, the version number of the backup file in each partition is the same and the content of the backup file is the same.

4. The method according to claim 2, characterized in that, The step of determining that the version number of the backup file in the first target partition is higher than the version number of the backup file in the other partitions includes: If the version number and content of the backup file are read only from the first target partition, then it is determined that the version number of the backup file in the first target partition is higher than the version number of the backup file in the other partitions; If the version number and content of the backup file are read from each partition, the version number of the backup file in each partition is compared, and it is determined that the version number of the backup file in the first target partition is higher than the version number of the backup file in the other partitions.

5. The method according to claim 1, characterized in that, In response to the first event, the battery health status parameters are updated, and based on the battery health status parameters, the version number and content of the backup files in each of at least two partitions are updated, including: In response to the first event, battery health status parameters are collected based on the battery health status parameter collection instruction. The battery health status parameter collection instruction includes: the type of battery health status parameter, the number of times each type of battery health status parameter is collected, and the collection period. Collect the health status parameters for each type of battery according to the number of times and the collection period for each type of battery health status parameter; When any type of battery health status parameter is updated, based on the updated battery health status parameter, update the version number and content of the backup file in each of at least two partitions.

6. The method according to any one of claims 1 to 5, characterized in that, The method further includes: When the electronic device is powered off, it receives power-on input from the user. In response to the power-on operation, the version number and content of the backup file are read from each partition, and it is determined that the version number of the backup file in the second target partition is higher than the version number of the backup file in the other partitions of the at least two partitions. The version number and content of the backup file in the second target partition are then written to the other partitions. Specifically, after the version number and content of the backup file in the second target partition are written to the other partitions, the version number of the backup file in each partition is the same and the content of the backup file is the same.

7. The method according to any one of claims 1 to 6, characterized in that, The first event and the second event are any one of the following: screen on / off event, power-on event, charger plugging event, and battery level change event.

8. The method according to any one of claims 1 to 7, characterized in that, The at least two partitions include a first partition, a second partition, and a third partition. The application layer of the electronic device provides file read / write paths for the first partition and the second partition, and the local service layer of the electronic device provides file read / write paths for the third partition.

9. The method according to any one of claims 1 to 8, characterized in that, The battery health status parameters include at least one of the following: battery capacity decay, battery internal resistance, battery self-discharge rate, battery temperature, and battery leakage parameters.

10. An electronic device, characterized in that, The electronic device includes: one or more processors, and memory; The memory is coupled to the one or more processors, the memory being used to store computer program code, the computer program code including computer instructions, the one or more processors invoking the computer instructions to cause the electronic device to perform the method as described in any one of claims 1 to 9.

11. A chip system, characterized in that, The chip system is applied to an electronic device, the chip system including one or more processors, the one or more processors being used to invoke computer instructions to cause the electronic device to perform the method as described in any one of claims 1 to 9.

12. A computer program product, characterized in that, When the computer program product is run on a computer, it causes the computer to perform the method as described in any one of claims 1 to 9.

Images