CN116668285B

CN116668285B - Method, device and storage medium for configuring system

Info

Publication number: CN116668285B
Application number: CN202211550681.XA
Authority: CN
Inventors: 陈超; 王艳召; 郝庆涛; 黄九林
Original assignee: Honor Device Co Ltd
Current assignee: Honor Device Co Ltd
Priority date: 2022-12-05
Filing date: 2022-12-05
Publication date: 2024-05-03
Anticipated expiration: 2042-12-05
Also published as: CN116668285A

Abstract

The application provides a method for configuring a system. By implementing the method, electronic equipment such as mobile phones and the like can acquire a system upgrade package with system information. When the upgrade package is used for upgrading the operating system of the electronic equipment, the electronic equipment can execute a remanufacturing operation according to a target standard in the upgrade package, and the standard of the electronic equipment is revised to the target standard so as to adapt to a new use scene. Therefore, the electronic equipment can finish the reform operation simultaneously in the process of system upgrading, and the problems of high hardware cost, large difficulty in deploying the reform authorization server and the like existing in the reform operation by the traditional reform tool are avoided.

Description

Method, device and storage medium for configuring system

Technical Field

The present application relates to the field of terminals, and in particular, to a method, an apparatus, and a storage medium for configuring a system.

Background

In the application scenario of the prior art, the user terminal needs to install an operating system to be usable by the user. For example, a mobile phone operating system (e.g., IOS system, android system) needs to be installed on the mobile phone to be used by the user. In the field of wireless communication, according to the location of a wireless communication device (such as a mobile phone) and the difference of accessed operators, an operating system of the wireless communication device needs to configure a corresponding standard (VC); for example all cn, cmcc cn, etc.

Generally, when an initial operating system is installed before a wireless communication device leaves a factory, a manufacturer installs an operating system configured with a corresponding system according to a sales area. However, in the actual application scenario, there is a case of changing the system. For example, after the equipment in zone A is sold out, the shipment from zone B is required. In this case, before the wireless communication device tuned from the area B is put into the area a, the manufacturer needs to modify the format B (format corresponding to the area B) originally configured in the wireless communication device into the format a (format corresponding to the area a) so that the wireless communication device can be used normally in the area a. Therefore, there is a need for a method of modifying the format of a wireless communication device that is capable of handling the modification requirements of the wireless communication device in a batch.

Disclosure of Invention

The application provides a method, equipment and storage medium for configuring a system. The method can be applied to wireless communication equipment such as mobile phones and the like. By implementing the method for configuring the system, wireless communication equipment such as a mobile phone and the like can finish the remanufacturing operation in the process of system upgrading, and the method is convenient and quick.

In a first aspect, the present application provides a method for configuring a system, which is applied to an electronic device, where a first storage block oem in the electronic device stores a first system, where the first system is a system currently used by the electronic device, the electronic device further includes a custom file, and the custom file also stores the first system, where the method includes: acquiring a first data packet, wherein the first data packet comprises upgrade data of a target operating system and a target system, and the target system is different from the first system; writing the target standard in the first data packet into a second storage block tmp of the electronic equipment; upgrading the operating system of the electronic equipment into a target operating system by utilizing the upgrading data of the target operating system in the first data packet; writing oem the target system cached in tmp; the first standard stored in the customized file is cleared, the customized file is written into a target standard in oem when the electronic equipment is started, and the starting refers to the starting after the clearing; wherein the purging occurs after upgrading the operating system of the electronic device to the target operating system.

By implementing the method provided in the first aspect, the electronic device can obtain the upgrade data of the target operating system and the target standard at the same time. Thus, in the process of upgrading the operating system of the electronic device to the target operating system by using the upgrading data of the target operating system, the electronic device can simultaneously modify the standard of the electronic device into the target standard by using the target standard.

Therefore, the electronic equipment can finish the reform operation simultaneously in the process of system upgrading, and the problems of high hardware cost, large difficulty in deploying the reform authorization server and the like existing in the reform operation by the traditional reform tool are avoided.

In some embodiments, in combination with the method provided in the first aspect, the custom file is in a user data partition Userdata of a memory of the electronic device, and the clearing of the custom file specifically includes: formatting Userdata.

By implementing the method provided by the embodiment, the electronic device can remove the custom file by using the method of formatting Userdata. In this way, the electronic device does not need to search for custom files specifically.

With reference to the method provided in the first aspect, in some embodiments, the method further includes: executing a restarting operation, and entering a recovery mode; the purging of custom files is done in the recovery mode.

By implementing the method provided by the embodiment, the electronic device can restart to enter the recovery mode, and the formatting Userdata and the removal of the custom file are realized through the function of restoring the factory setting provided by the recovery mode.

In some embodiments, the memory of the electronic device further comprises a system partition for storing system data related to an operating system of the electronic device; the system partition comprises a first static partition, a second static partition and a dynamic partition, and upgrades the operating system of the electronic device into a target operating system by utilizing upgrade data of the target operating system in the first data packet, and specifically comprises the following steps: writing upgrade data of a target operating system in a first data packet into a second static partition and a virtual dynamic partition in a state that the electronic equipment is started from the first static partition, wherein the virtual dynamic partition is a section of storage partition in Userdata; writing the upgrade data of the target operating system stored in the second static partition into the first static partition in a recovery mode; writing the upgrade data of the target operating system stored in the virtual dynamic partition into the dynamic partition in a recovery mode; writing oem the target format cached in tmp is done in recovery mode.

By implementing the method provided by the embodiment, the electronic equipment performs copy operation and merge operation of upgrading the operating system in the recovery mode. In combination with the above-mentioned reform in the reform mode, the electronic device can directly enter the reform mode when restarting for the first time, and the operations of upgrading the operating system and reform are completed in the reform mode, so that the restart for many times is avoided, the working modes (android mode and reform mode) of the electronic device are switched, the reform speed is improved, and the reform cycle is shortened.

With reference to the method provided in the first aspect, in some embodiments, the method further includes: configuring a first toolkit for a recovery mode of the electronic device; in the recovery mode, writing the upgrade data of the target operating system stored in the virtual dynamic partition into the dynamic partition, specifically including: and in the recovery mode, writing the upgrade data of the target operating system stored in the virtual dynamic partition into the dynamic partition by using the first tool kit.

By implementing the method provided by the embodiment, based on the preset first toolkit (namely the snapshot and snapuser), the electronic equipment can support copy operation and merge operation of upgrading the operating system in the recovery mode, so that the electronic equipment can directly enter the recovery mode when restarting for the first time, the operation of upgrading the operating system and the operation of remanufacturing are completed in the recovery mode, multiple restarting is avoided, the working modes (android mode and recovery mode) of the electronic equipment are switched, the remanufacturing speed is improved, and the remanufacturing period is shortened.

In some embodiments, in combination with the method provided in the first aspect, the electronic device is operated in the android mode before performing the restart operation and entering the recovery mode.

In combination with the method provided in the first aspect, in some embodiments, before performing the restart operation, the method further includes: writing a restore factory command; executing a restarting operation, and entering a recovery mode, wherein the method specifically comprises the following steps: and executing a restarting operation, and responding to the factory restoration command, and entering a recovery mode.

By implementing the method provided by the embodiment, the electronic device can instruct the electronic device to enter the recovery mode when restarting in a mode of writing the specific command, but not enter the android mode.

In combination with the method provided in the first aspect, in some embodiments, writing the restore factory command specifically includes: and writing a factory restoration command in a first path of the electronic memory, wherein the first path is a fixed mounting path for starting the electronic equipment.

By implementing the method provided by the embodiment, the electronic device can write the factory restoration command under the first path which is needed to be mounted when the electronic device is started, for example, under the condition of/cache/command. Thus, when the electronic equipment is restarted, the factory restoration command can be obtained when the first path is mounted, and the electronic equipment enters a recovery mode.

In combination with the method provided in the first aspect, in some embodiments, writing oem the target format cached in tmp, and upgrading the operating system of the electronic device to the target operating system by using the upgrade data of the target operating system in the first data packet is completed in the android mode; executing a restarting operation, and entering a recovery mode, wherein the method specifically comprises the following steps: executing restarting operation, and detecting that the first system stored in the customized file is inconsistent with the target system stored in oem during restarting; in response to the inconsistency, a recovery mode is entered.

By implementing the method provided by the embodiment, the electronic device can firstly restart to enter the android mode, and complete copy operation and merge operation of upgrading the operating system and reform operation. Then, when restarting again, the electronic device may trigger to enter a recovery mode by detecting that the target formats stored in oem of the custom file storage are inconsistent during restarting. At this time, the electronic device does not need to write a specific command, for example, the above-mentioned restore factory command, and controls the electronic device to enter the recovery mode.

In some embodiments, the operating system currently used by the electronic device is a presenter operating system, and the target operating system is a business machine operating system.

By implementing the method provided by the embodiment, the store demonstration product provided with the demonstration machine operating system can be modified in an OTA mode by adopting the modification method provided by the embodiment of the application, and is upgraded to the operating system corresponding to the new mode, and then is sold to consumers as a commercial product.

In a second aspect, the present application provides an electronic device comprising one or more processors and one or more memories; wherein the one or more memories are coupled to the one or more processors, the one or more memories being operable to store computer program code comprising computer instructions that, when executed by the one or more processors, cause the electronic device to perform the method as described in the first aspect and any possible implementation of the first aspect.

In a third aspect, the application provides a computer readable storage medium comprising instructions which, when run on an electronic device, cause the electronic device to perform a method as described in the first aspect and any possible implementation of the first aspect.

It will be appreciated that the electronic device provided in the second aspect and the computer storage medium provided in the third aspect are each configured to perform the method provided by the present application. Therefore, the advantages achieved by the method can be referred to as the advantages of the corresponding method, and will not be described herein.

Drawings

FIG. 1 is a partitioned representation of a memory of an electronic device 100 provided by an embodiment of the present application;

fig. 2 is a schematic diagram of a scenario in which a system is changed according to a system upgrade operation according to an embodiment of the present application;

FIG. 3 is a flowchart of an electronic device 100 for acquiring an upgrade and reform package and performing an upgrade and reform operation according to an embodiment of the present application;

FIG. 4 is a schematic diagram illustrating a change of a partition table of the electronic device 100 in an upgrade and remanufacturing process according to an embodiment of the present application;

FIG. 5 is a flowchart of another electronic device 100 according to an embodiment of the present application for obtaining an upgrade retrofit package and performing an upgrade retrofit operation;

FIG. 6 is a configuration diagram for a recovery mode according to an embodiment of the present application;

FIG. 7 is a diagram illustrating a change in partition table of the electronic device 100 during another upgrade and modification process according to an embodiment of the present application;

fig. 8 is a schematic structural diagram of an electronic device 100 according to an embodiment of the present application.

Detailed Description

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

The wireless communication device may be referred to as an electronic device 100. In the embodiment of the present application, the electronic device 100 may be a wireless communication device such as a mobile phone or a tablet computer. In other embodiments, the electronic device 100 may also be a desktop computer, a laptop computer, a handheld computer, a notebook computer, an ultra-mobile personal computer (UMPC), a netbook, a cellular telephone, a Personal Digital Assistant (PDA), an augmented reality (augmented reality, AR) device, a Virtual Reality (VR) device, an artificial intelligence (ARTIFICIAL INTELLIGENCE, AI) device, a wearable device, a vehicle-mounted device, a smart home device, and/or a smart city device, and the specific types of the electronic devices are not particularly limited by the embodiments of the present application.

Generally, when the electronic device 100 is installed with an initial operating system before leaving the factory, a manufacturer installs the operating system with a configured corresponding system according to its sales area. However, in the actual application scenario, there is a case of changing the system.

For example, after the equipment in zone A is sold out, the shipment from zone B is required. At this time, before the electronic device 100 modulated from the area B is put into the area a (target area), the manufacturer needs to modify the format B (format corresponding to the area B, for example, "All/cn") originally arranged in the electronic device 100 into the format a (format corresponding to the area a, for example, "cmcc/cn" or other formats different from "All/cn") so that the electronic device can be normally used in the area a. Therefore, a method for changing the system of the electronic device 100 is needed to process the modification requirements of the electronic device 100 in batch to improve the modification efficiency.

In some embodiments, the electronic device 100 may complete the remanufacturing by a dedicated remanufacturing tool. When the electronic device 100 is modified by a special modifying tool, a manufacturer needs to connect the electronic device 100 to be modified with the modifying tool one by one, and perform authorization verification to enable the modifying tool to have the authority to modify the standard of the electronic device 100, and then complete the modification by the modifying tool. The method has the problems of high hardware cost, large difficulty in deploying and remanufacturing the authorization server and the like.

In order to avoid the problems, the application provides a method for changing the system along with the upgrade operation of the system. By implementing the method, the electronic device 100 can acquire a system upgrade package with system information, which is called an upgrade remanufacturing package. While the operating system of the electronic device 100 is upgraded by using the upgrade and reform package, the electronic device 100 can modify its own system according to the system information in the upgrade and reform package, and complete reform along with the initialization operation in the startup process.

In this way, the electronic device 100 can complete the reform operation simultaneously in the process of system upgrade, so that the problems of high hardware cost, large difficulty in deploying the reform authorization server and the like existing in the reform operation by the traditional reform tool are avoided.

The electronic device 100 is provided with a memory. Data such as operating system, user data, etc. of the electronic device 100 may be stored in memory. The memory is provided with a partition table for describing partition deployment of the memory, and defining a starting address and a size of each partition. Taking the electronic device 100 adopting the android virtual a/B upgrade mode as an example, fig. 1 is a block diagram of the memory of the electronic device 100 according to the embodiment of the present application.

As shown in fig. 1, the memory of the electronic device 100 includes a base partition (Common), a system partition, and a user data partition (Userdata). The base partition is used to store system data that does not participate in operating system upgrades. The system partition is used for storing operating system data, and the operating system upgrading is to upgrade the data in the system partition. The user data partition is used for storing personal data of the user, such as APP installed by the user, pictures, documents, videos and the like stored by the user.

Under the virtual A/B architecture, the system partitions include a static partition (A), a static partition (B), and a dynamic partition (Super). Static partition (a) is typically used to store boot-up boot programs. The static partition (A) and the static partition (B) are corresponding in structure and store corresponding system image files. The static partition (a) and the static partition (B) sub-partition designations are distinguished from each other by the suffix_a_b. For example, the static partition (a) includes bootloader_a, boot_a, vendor_boot_a, dtbo_a, vbmeta_a; the static partition (B) includes bootloader_b, boot_b, vendor_boot_b, dtbo_b, vbmeta_b. The static partition (a) is also referred to as a first static partition, and the static partition (B) is also referred to as a second static partition. Dynamic partitioning (Super) is commonly used to store system operating programs. The dynamic partition includes a plurality of sub-partitions, such as system, system _ ext, product, version, preload, vendor, cust, odm.

The electronic device 100 is started from a static partition. For example, the electronic device 100 starts from the static partition (a): sequentially loading a basic partition (Common), a static partition (A) and a dynamic partition (Super); the electronic device 100 starts from the static partition (B): the base partition (Common), the static partition (B), and the dynamic partition (Super) are loaded in sequence.

The system information, such as All/cn, cmcc/cn, is stored in a separate sub-partition, such as Oeminfo sub-partition, in the base partition (Common). Typically, oeminfo child partitions include oem. The system recorded in oem is the formal system of the current electronic device 100. The current system of the electronic device 100 recorded in oem before modification is also referred to as the first system. Illustratively, the format recorded in oem of electronic device 100 is vc—1.Vc_1 is a system (system B) matching the region B where the electronic device 100 is located before shipment. During the remanufacturing process, the electronic device 100 may create a tmp in the Oeminfo sub-partition for recording a target format, such as format vc_2 (format a). oem and tmp are essentially a block of memory space for storing the system information.

In the process of starting the operating system, the electronic device 100 reads and loads oem the system information, and writes the system information into the custom file in the user data partition (Userdata) so as to be called in the running process of the operating system. Such as custom. For example, when region B enables electronic device 100, a custom. Bin file is written to the above-described standard VC_1.

Each time the electronic device 100 is started, the electronic device 100 detects oem whether the format information recorded in the custom file (custom. Bin) matches the format information. When there is no match, an error may occur in the operation of the electronic device 100. Therefore, when modifying the format of the electronic device 100, the electronic device 100 needs to modify the format information in oem and synchronously update the format information in the custom file (custom. Bin), so that the modified electronic device 100 can be started to operate normally. Therefore, after modifying the format vc_1 in oem to vc_2, the electronic device 100 also needs to update the format in the custom file (custom. Bin), and modify the format in the custom file (custom. Bin) from vc_1 to vc_2.

Fig. 2 is a schematic diagram of a scenario in which a system is changed according to a system upgrade operation according to an embodiment of the present application.

As shown in fig. 2, the system currently configured by the electronic device 100 is vc—1 (legacy), and the currently used operating system version is denoted as OS1.0 (old operating system).

After determining the target region, the developer can determine the system and operating system version matching the target region. For example, a developer may determine the format vc_2 (i.e., the target format, also referred to as the new format) that matches the target region, and the operating system OS2.0 (i.e., the target operating system, also referred to as the new operating system). The mapping relation exists between the region and the system, and meanwhile, the mapping relation exists between the system and the operating system. And the research staff can determine the target standard and the target operating system according to the mapping relation between the regions and the standard and the mapping relation between the standard and the operating system.

Then, the developer may construct an upgrade and reform package (i.e., a first data package) including the target standard (vc_2) for updating the standard and the operating system of the electronic device 100 based on the system upgrade package of the target operating system (OS 2.0). The upgrade kit may be stored in server a. Server a is also referred to as a bale server. In some examples, the beat server is a server cluster consisting of a plurality of servers.

In some examples, the developer may also establish a mapping relationship between regions, formats, and operating system versions in the beat server. After determining the target region, the clapping server can determine the target system and the target operating system according to the mapping relation (the mapping relation exists between the region and the system, and the mapping relation exists between the system and the operating system), and further, the clapping server can automatically generate an upgrading and remanufacturing bag containing the target system and the target operating system.

The electronic device 100 that needs to change the standard may obtain the upgrade and reform package from the package server and perform the upgrade and reform operation.

After the upgrade and reform package is obtained and the upgrade and reform operation is performed, the standard of the electronic device 100 may be updated to the target standard, and the operating system of the electronic device 100 may be upgraded to the target operating system. For example, after performing the upgrade and upgrade operations according to the upgrade and upgrade package (vc_2+os2.0), the standard of the electronic device 100 may be updated from vc_1 to vc_2, and the operating system may be upgraded from OS1.0 to OS2.0.

In the retrofit scenario in which the store demonstration device in region B is changed to a commercial device and the commercial device is delivered to region a for sale, the old operating system OS1.0 is the demonstration machine operating system, and the target operating system OS2.0 is the commercial machine operating system.

Fig. 3 is a flowchart of an electronic device 100 according to an embodiment of the present application for acquiring an upgrade and reform package and performing an upgrade and reform operation.

S101, preparing an upgrade and reform package.

One or more upgrade reform packages can be preset in the package beating server. The upgrade and reform package comprises standard information and operating system upgrade data.

The system information in the upgrade and reform package is stored in the root directory of the upgrade and reform package in the form of a target_vendor_counter. the content of the target_vendor_counter.mbn file indicates the target system.

The upgrade and reform package also includes operating system upgrade data (including static partition upgrade data and dynamic partition upgrade data). Static partition upgrade data such as boot up boot programs for the target operating system. The static partition upgrade data is used to upgrade the static partition of the electronic device 100. Dynamic partition upgrade data such as system run-time of the target operating system. The dynamic partition upgrade data is used to upgrade the dynamic partition of the electronic device 100. Referring to the description of fig. 2, the operating system upgrade data (i.e., the target operating system) in the upgrade and retrofit package matches the system information (target system) in the upgrade and retrofit package.

Fig. 4 is a schematic diagram illustrating a change of a partition table of the electronic device 100 in an upgrade and remanufacturing process according to an embodiment of the present application. The diagram (b) in fig. 4 may represent a data structure of the upgrade adaptation packet. Referring to fig. 4 (b), the upgrade kit may include VC, bootloader (2.0), boot (2.0), super, etc. partitions. The VC partition (target_binder_counter.mbn file) records the target standard vc_2 (e.g., "cmcc/cn"). Static partition upgrade data of the target operating system OS2.0 are recorded in Bootloader (2.0) and Boot (2.0). Dynamic partition upgrade data for the target operating system OS2.0 is recorded in the Super.

S102, obtaining an upgrade and reform package.

Initially, the electronic device 100 may boot from the static partition (a): the base partition (Common), the static partition (a), and the dynamic partition (Super) are loaded in sequence. The steps shown in S101 may be performed after the electronic device 100 is started, or may be performed before the electronic device 100 is started.

After startup, the electronic device 100 may obtain an operation upgrade retrofit package through a system Update agent module (update_apk_client). Update_apk_client is a tool preset in the electronic device 100 for acquiring system image data (e.g., OS2.0 image data) from a remote image source (e.g., a flash server).

Update_apk_client may periodically initiate a search for packets request to the packet server. Meanwhile, the update_apk_client can also initiate a packet search request based on user operation. In the embodiment of the present application, the packet search request may include format information. The packet shooting server can search the corresponding upgrading and reforming packet according to the system information in the packet searching request. For example, the packet search request may include the target standard vc_2. The packet capturing server can determine an upgrade and reform packet generated based on the standard VC_2 and the operating system OS2.0 according to the target standard VC_2.

Optionally, the packet search request may further include a version number of the operating system currently running on the electronic device 100, such as OS1.0. The clapping server may determine an upgrade reform package comprising an updated operating system version based on the operating system version number in the search request. For example, the ladle server may include: upgrade and reform packages generated based on the standard VC_2 and the operating system OS1.0 and upgrade and reform packages generated based on the standard VC_2 and the operating system OS 2.0. According to the indication information VC_2 in the packet searching request and the version number OS1.0 of the operating system currently running, the packet capturing server can determine an upgrade and reform packet corresponding to the operating system version OS2.0 from the two upgrade and reform packets.

The capture server may return a download address for the upgrade retrofit package to the electronic device 100. The electronic device 100 downloads the corresponding upgrade and reform package according to the download address returned by the package beating server.

S103, triggering Updata _engine to update.

S104, checking the upgrade and reform package.

The upgrade module (Updata _engine) may be a functional module preset in the electronic device 100 and storing upgrade and upgrade processing logic, and may be used to perform upgrade and upgrade operations. After the upgrade retrofit package is obtained, first, updata _engine may check the upgrade retrofit package. Specifically, verifying the upgrade remanufactured package includes verifying whether a digital signature of the upgrade remanufactured package is legal.

S105, writing the upgrade data of the operating system in the upgrade and remanufacturing packet: (1) Writing static partition upgrade data into the static partition (B); (2) Dynamic partition upgrade data is written to the virtual dynamic partition of Userdata.

When the upgrade and reform package passes the verification, updata _engine can upgrade the system partition by using the operating system upgrade data (static partition upgrade data and dynamic partition upgrade data) in the upgrade and reform package.

(1) Writing static partition upgrade data to static partition (B):

In the scenario of booting from static partition (A), updata _Engine may write static partition upgrade data in the upgrade retrofit package to static partition (B). The write operation has a case of write failure. When a write failure occurs, updata _engine interrupts the entire operating system upgrade operation, outputs an upgrade failure prompt to the user (e.g., displays a dialog box for upgrade failure), automatically re-upgrades or determines by the user whether to re-upgrade or abort the upgrade.

Updata _engine may perform a data check on the static partition (B) after performing the write operation to confirm whether the static partition upgrade data was successfully written to the static partition (B). Illustratively, in the scenario of an upgrade from OS1.0 to OS2.0, the upgrade retrofit package may contain the static partition upgrade data of OS2.0 and the hash value of the static partition upgrade data of OS 2.0. After performing the write operation, updata _engine may calculate the hash value of the data in the static partition (B) and determine whether the hash value of the data in the static partition (B) matches the hash value of the static partition upgrade data of OS2.0 recorded in the upgrade remanufacturing packet. If the operation is consistent, the writing is successful, and Updata _engine can perform subsequent operation system upgrading operation; if the data is inconsistent, the data writing fails and the upgrading fails.

Referring to Table 1, taking a static partition sub-partition boot as an example, an upgrade retrofit package from OS1.0 to OS2.0 may contain the following data:

TABLE 1

Project	Description of the invention
		Name:boot	Partition name, representing current data as upgrade data pointing to sub-partition boot
Start:12222	A data block start address indicating the start position of the upgrade data of the sub-partition boot
		size:2410	Data size, representing the size of upgrade data for a child partition boot
TargetHash:HASH12	Target hash value, hash value representing upgrade data of sub-partition boot of OS2.0

Updata _engine may read a fixed mount path, such as/dev/block/by-name/MIsc, from the Common partition to determine that electronic device 100 is currently booted from either static partition (a) or static partition (B). Then, based on the scene started from the static partition (a), updata _engine may determine the path of the child partition boot of the static partition (B), such as/dev/block/by-name/boot_b.

After determining the path of the sub-partition boot, updata _engine writes the upgrade data of the corresponding sub-partition boot in OS2.0 into the sub-partition boot_b, i.e. under the/dev/block/by-name/boot_b. After the write operation is completed, updata _engine may calculate the HASH value of the data written in the sub-partition boot_b (i.e., per dev/block/by-name/boot_b), determine whether the HASH value of the sub-partition boot_b matches the target HASH value (TARGETHASH: HASH 12). If the sub-partition boot upgrades of the static partition are consistent, the sub-partition boot of the static partition can be upgraded for the next static partition sub-partition; if not, the upgrade operation fails.

Updata _Engine can write the upgrade data of each static partition sub-partition contained in the upgrade and reform package into the corresponding sub-partition in the static partition (B) according to the writing and checking operations described above, and check whether the writing is correct. If the upgrade and update package does not contain upgrade data of a sub-partition of a certain static partition, updata _engine may synchronize data of a corresponding sub-partition in the static partition (a) to the sub-partition in the static partition (B). In the upgrading process, when one sub-partition has upgrading errors and hash check fails, the upgrading operation is interrupted and the upgrading fails; when all the sub-partitions are successfully upgraded, the static partition is successfully upgraded, and the subsequent steps can be executed.

Further, when a static partition fails to upgrade, the data of the static partition cannot be used to start the operating system smoothly. At this time, in order to avoid the static partition that fails to load an upgrade during the operating system startup process from causing an operating system startup error, the static partition may carry a status flag: may be activated or not. The electronic device 100 may first read the static partition status flag before loading the static partition data. When the status of the static partition is marked as bootable, the electronic device 100 loads the data of the static partition. Specifically, the status flags for the static partitions may be stored in metadata (/ matadata) of the Common partition.

Illustratively, before upgrading the static partition (B), updata _engine may mark the static partition (B) as not bootable, and after the static partition (B) is upgraded successfully, updata _engine may mark the static partition as bootable. Thus, if the static partition (B) fails to upgrade, the state of the static partition (B) may remain non-bootable. The electronic device 100 will not load the data of the static partition that failed the upgrade.

(2) Writing dynamic partition upgrade data to the virtual dynamic partition of Userdata:

Updata _Engine may create a virtual dynamic partition in the user data partition (Userdata) and write dynamic partition upgrade data in the upgrade adaptation package to the virtual dynamic partition. For example, in the scenario of an upgrade from OS1.0 to OS2.0, the upgrade package includes dynamic partition upgrade data for OS 2.0. After executing S104, updata _engine may create a virtual dynamic partition in Userdata. Then Updata _engine may write the upgrade data of the dynamic partition of OS2.0 into the created virtual dynamic partition.

Typically, during a system upgrade, there is overlap of data in the dynamic partition of the old operating system with data in the dynamic partition of the new operating system, i.e., portions of the data are identical. Thus, under the virtual A/B framework, dynamic partition (Super) upgrades may employ incremental upgrades. In particular, the virtual dynamic partition of user data partition (Userdata) may only store the dynamic partition upgrade data that is needed to be upgraded in the old operating system, rather than storing all of the dynamic partition data for the new operating system.

Taking the system sub-partition as an example, in OS1.0, the data in the system sub-partition can be divided into two parts, system1 and system 2. Wherein, syetem1 needs to be upgraded to system3 when upgrading from OS1.0 to OS2.0, and system2 does not need to be changed. At this point, the user data partition (Userdata) need only write to system3 to create a virtual dynamic partition.

Under the virtual A/B framework, updata _Engine may implement incremental upgrades of dynamic partitions (Super) through snapshot technology (snapshot). Specifically, updata _engine may use Copy-On-Write (COW) files in the virtual dynamic partition to save the upgrade data of the dynamic partition (Super). The virtual dynamic partition includes a plurality of COW files. One COW file corresponds to a child partition of one dynamic partition (Super). The naming of the COW file corresponds to the dynamic partition (Super) sub-partition to which it is directed. For example, a COW file for a system sub-partition is named system-COW-img.img.0000.

Updata _Engine after acquiring all the COW files in the upgrade adaptation package, an A/B partition flag may be attached to each COW file. For example, in a scenario that starts from a static partition (a) (dynamic partition (Super) loaded by the operating system currently running by electronic device 100 is dynamic partition (a)), the virtual dynamic partition created by Updata _engine in user data partition (Userdata) is for dynamic partition (B). At this point Updata _engine may attach a partition tag for the corresponding dynamic partition (B) to the COW file. For example, the COW file system-COW-img.img.0000 for the system sub-partition described above may be labeled as system_b-cow.img.0000.

The COW file includes a COW file map (snapshot map) of the COW file itself and upgrade data. The COW file map corresponds to a file map of a dynamic partition (Super) sub-partition to which the COW file is directed. A file map of a dynamic partition (Super) sub-partition is used to describe files in the current operating system (OS 1.0) and save addresses of the respective files. The COW file map in the virtual dynamic partition is used to describe the files in the target operating system (OS 2.0) and the save addresses of the respective files. The COW file map in the virtual dynamic partition may also indicate the correspondence of files in the target operating system (OS 2.0) to files in the pre-operating system (OS 1.0).

The Updata _engine can use the COW file to replace the corresponding file in the dynamic partition (Super) sub-partition based on the file map of the dynamic partition (Super) sub-partition and the COW file map, thereby realizing the upgrading of the dynamic partition (Super) data.

Referring to Table 2, taking a dynamic partition (Super) sub-partition system as an example, the file path and file map of the sub-partition system in the Super may be as follows:

TABLE 2

The value after the file name in Table 2 (e.g./system/app/A0. XXX:024010 ～ 024013 in 024010 ～ 024013) is the physical save address (block address) of the file in the system sub-partition of the dynamic partition (Super).

Assume that the data to be updated in the dynamic partition (Super) of the current operating system OS1.0 is/system/app/A2. XXX and/system/user/C2. XXX. Illustratively, the COW file in the virtual dynamic partition may be as shown in table 3:

TABLE 3 Table 3

Similarly, the values (e.g., 045033 ～ 045035 and 045036 ～ 045040) given after the file name in Table 3 are the physical storage addresses (block addresses) of the COW file/system/app/A2. XXX,/system/user/C2. XXX virtual dynamic partitions in the user data partition (Userdata).

The/system/app/a 2.Xxx,/system/user/c 2.Xxx in table 2 may be regarded as system1 and the other files in table 2 may be regarded as system2. The COW files (/ system/app/A2.XXX,/system/user/C2. XXX) in Table 3 may be regarded as system3.

After successfully writing the COW file to the virtual dynamic partition in Userdata, updata _engine may change the dropped state information in the metadata partition (/ metadata) of the base partition (Common) from "dropped (merge)" to "not dropped (wait for merge)". The landing status information is used to indicate whether there is a COW file currently that needs landing to a dynamic partition (Super). The drop status information contains an overall identification for the dynamic partition (Super) and a sub-partition identification for each sub-partition. All sub-partitions, collectively identified as "dropped" representing dynamic partitions (Super), do not need to be dropped; one or more sub-partitions, collectively identified as "no drop (wait for merge)" representing a dynamic partition (Super), need to perform a drop operation; the child partition identification "dropped" represents that the child partition does not need to perform a drop operation; the child partition identified as "no drop (wait for merge)" represents that the child partition needs to perform a drop operation.

S106: creating tmp-VC, and writing the tmp-VC into the target system VC_2.

Typically, the upgrade package downloaded by Updata _engine from the capture server does not include the system information. After completing S104 and S105, updata _engine may return status information of the completion of the upgrade operation to the update_apk_client.

In the embodiment of the present application, the electronic device 100 needs to change the system according to the system upgrade operation, so that Updata _engine needs to determine whether the upgrade package downloaded from the package server is used for modification after the upgrade package is acquired. Updata _Engine can determine whether to be used for remanufacturing according to whether the upgrade package contains system information. When determined for remanufacturing, updata _engine may create tmp-vc in the Oeminfo child partition and write the system information in the upgrade package into tmp-vc.

The upgrade and reform package exemplified by the embodiment of the application comprises upgrade data of the target operating system OS2.0 and the target standard VC_2. Thus, after the upgrade adaptation package is obtained, updata _engine may determine that the data is also used for adaptation. At this point Updata _engine may create tmp-VC in Oeminfo child partition and write the target format vc_2 to tmp-VC as described above.

The embodiment of the present application does not limit the sequence of executing steps S105 and S106 by the electronic device 100.

The diagram (a) in fig. 4 may represent a partition representation intent of the electronic device 100 before performing the upgrade reform operation (i.e., before performing steps S105, S106). At this time, the standard stored in oem of the electronic device 100 is legacy vc_1. In a state of being started from the static partition (a), the electronic device 100 operates on an operating system OS1.0 supported by the static partition (a) and the dynamic partition (Super). At this time, the recording format in custom file custom. Bin is consistent with oem, which is VC_1.

After writing the data (system information, operating system upgrade data) in the upgrade retrofit package, i.e., after performing steps S105, S106, the partition representation intent of the electronic device 100 may be as shown in fig. 4 (c). At this point, tmp is increased in the Oeminfo sub-partition. the tmp stores a new format vc_2. In the static partition (B), the boot_b and boot_b sub-partitions store static partition upgrade data of the operating system OS2.0, which are denoted as boot_b (2.0) and boot_b (2.0). Userdata have been added virtual dynamic partitions for storing dynamic partition upgrade data of operating System OS2.0, such as System (2.0).

S107: and returning the state information of finishing the upgrading.

When Updata _engine performs the upgrade operations shown in S104 to S106, the update_apk_client may monitor the progress of the upgrade operations shown in S104 to S106. The electronic device 100 may display a corresponding progress control according to the progress detected by the update_apk_client, for displaying the upgrade progress to the user.

After writing the data (system information, operating system upgrade data) in the upgrade remanufacturing packet, i.e. after executing steps S105, S106, updata _engine may return status information of the upgrade completion to the update_apk_client. Correspondingly, the progress control may instruct the user to show that the upgrade is complete.

S108: triggering a restart (first restart).

After receiving Updata _engine return status information to complete the upgrade, update_apk_client may trigger a restart (first restart). In an embodiment of the present application, preferably, the electronic device 100 may automatically enter the restart procedure after the restart is triggered. In other embodiments, the electronic device 100 may also determine whether to immediately restart based on user operation. For example, the electronic device 100 may display a pop-up window through a screen, prompting the user to immediately restart or restart later with a selection. If the user chooses to restart later, further, the user may specify the time of restart, e.g., 12 pm on the day. The electronic device 100 may enter a restart program when a restart time designated by a user arrives, and perform a restart operation.

When the electronic device 100 performs the first restart, it may be started from the static partition (B) and run the updated operating system, i.e., the target operating system OS2.0. At this time, the electronic device 100 operates in the Android mode. The status flag "bootable" of the static partition (B) recorded in the Common partition may indicate that the electronic device 100 is booted from the static partition (B). The "not-dropped" status information in metadata (/ metadata) in the Common partition may indicate that the electronic device 100 loads the static partition (B) and then loads the dynamic partition (Super) and the virtual dynamic partition using snapshot merge.

S109: is the system in check oem matched with the system in custom file (custom. Bin?

During the process of booting the operating system, if the format in oem does not match the format in the custom file (custom. Bin) of Userdata, an error may occur in the operation of the operating system.

Upon restart, the electronic device 100 may perform an initialization operation. The initialization module for executing the initialization operation includes a supervision initialization (cust_init) process. The cure_init may be used to detect whether the system in oem matches the system in custom file (custom. When there is a match, the electronic device 100 may proceed with a restart operation; when there is no match, the electronic device 100 may enter a factory reset (recovery) mode to perform a factory reset operation: a custom file (custom. Bin) is formatted. After formatting the custom file (custom. Bin), electronic device 100 may then update the custom file (custom. Bin) according to the new system in oem, thereby re-matching the system in oem with the system in the custom file (custom. Bin).

At the first restart, the format in oem is still legacy vc_1. At this time, the format recorded in the custom file (custom. Bin) in the user data partition (Userdata) is also the old version format (vc_1). At this point, the electronic device 100 may continue with a reboot operation.

S110: and executing a merge operation, and writing the COW file in the virtual dynamic partition into a dynamic partition (Super).

Referring to the introduction of S105, after writing dynamic partition upgrade data into the virtual dynamic partition of Userdata, updata _engine may change the disk-dropped status information in the metadata partition (/ metadata) of the base partition (Common) from "dropped (merge)" to "not dropped (wait for merge)", indicating that there is currently a COW file that needs to be dropped to the dynamic partition (Super).

Upon performing S110, updata _engine may determine to perform a landing operation (merge) according to the landing status information "no landing (wait for merge)". In the present specification, the landing operation means: in the process of upgrading an operating system, dynamic partition (Super) upgrading data (COW file) stored in a virtual dynamic partition on a user data partition (Userdata) are written into the dynamic partition (Super), so that the dynamic partition (Super) finishes the operation of data upgrading. Upon restarting after merge is completed, electronic device 100 may complete device boot by only loading the dynamic partition (Super), without loading the dynamic partition (Super) and the virtual dynamic partition.

Specifically, updata _engine may write the COW file of the virtual dynamic partition in the user data partition (Userdata) to a corresponding address in the dynamic partition (Super), so that all data in the dynamic partition (Super) is updated new version data.

Taking the sub-partition systems and COW files shown in table 2 and table 3 as examples in S105, updata _engine may write the upgrade data of the sub-partition systems in the virtual dynamic partition into the sub-partition systems in the dynamic partition (Super) when performing the merge operation. For example, updata _engine may obtain the COW file a2.Xxx according to address 045033 ～ 045035 and replace the data a2.Xxx to be updated at address 024018 ～ 024020, obtain the c2.Xxx according to address 045036 ～ 045040COW file and replace the data c2.Xxx to be updated at address 024036 ～ 024040.

After writing the COW file of the virtual dynamic partition to the corresponding address in the dynamic partition (Super), updata _engine may delete the COW file in the user data partition (Userdata) and return the corresponding storage space to the user data partition (Userdata). Meanwhile, updata _engine may change the disk-dropped state information in the metadata (/ metadata) of the base partition (Common) from "no disk for merge" to "dropped (merge)".

S111: and executing copy operation, and writing the data in the static partition (B) into the static partition (A).

The Updata _engine can sequentially write the data of each sub-partition in the static partition (B) into the corresponding sub-partition of the static partition (A) according to the addresses of the corresponding sub-partitions in the static partition (A) and the static partition (B), so that the data synchronization of the static partition (A) and the static partition (B) is completed.

In S110, the merge operation is performed on the operating system data in the dynamic partition (Super), and does not affect the operating system data in the virtual dynamic partition currently used for startup. In S111, copy operation is performed on the operating system data in the static partition (a) and does not affect the operating system data in the static partition (B) currently used for booting. Thus, the user can use the device normally during the entire operating system upgrade.

S112: the system information in tmp is written oem.

Updata _engine can write the new format vc_2 cached in tmp into oem. After writing oem, the formal standard of the electronic device 100 is updated to the new standard vc_2. Subsequently Updata _engine may clear tmp.

The graph (d) in fig. 4 may represent the partition representation intent of the electronic device 100 when the merge operation, copy operation, and reform operation are performed. For example, the COW file in System (2.0) in Userdata may be written to the sub-partition System (1.0) in the dynamic partition (Super) by a merge operation; the data in the bootloader_b in the static partition (B) can be written into the corresponding sub-partition bootloader_a (1.0) in the static partition (A) through copy operation; the data in boot_b in the static partition (B) can be written into the corresponding sub-partition boot_a (1.0) in the static partition (A) through copy operation; the new format vc_2 stored in tmp can be written to oem. After the merge operation, copy operation, and reform operation are performed, the partition representation intent of the electronic device 100 after tmp and virtual dynamic partition are cleared may be as shown in fig. 4 (e).

S113: triggering a restart (second restart).

After the merge operation, copy operation, and reform operation are all completed, updata _engine may trigger a restart (second restart). The embodiment of the present application does not limit the sequence in which the operations shown in S110, S111, S112 are performed by the electronic device 100. The electronic apparatus 100 may perform copy operation, or a remanufacturing operation, or the like first.

Preferably, the electronic device 100 may automatically enter a reboot procedure. After steps S110, S111 are performed, the data in the static partition (a) and the static partition (B) are mirror image data, i.e., coincide. The electronic device 100 may boot from either static partition (a) or static partition (B).

Referring to S109, at the time of restart, the electronic device 100 performs an initialization operation. During the initialization process, the supervisory initialization process cure_init detects oem whether the system in custom file (custom. Bin) matches.

S114: a restart (third restart) is triggered, entering the recovery mode.

Referring to fig. 4 (e), at the second restart, the format in oem is the new format vc_2, while the format recorded in the custom file (custom. Bin) in the user data partition (Userdata) is still the old format vc_1. At this point, cure_init may determine oem that the system in custom file (custom. Bin) does not match the system in custom file. Then, cure_init may trigger entry into the recovery mode.

S115: custom files (custom. Bin) are purged.

After entering the recovery mode, the electronic device 100 may resume the factory set operations. Upon restoring the factory settings, electronic device 100 may format Userdata the partition, i.e., clear all data for the current Userdata partition. At this point, the custom file (custom. Bin) in the Userdata partition is also purged.

The diagram (f) in fig. 4 may represent a partition representation intent of the electronic device 100 after performing the restore factory setting operation. At this point, the custom file (custom. Bin) in Userdata is empty.

After the execution of S115, the electronic apparatus 100 completes the system upgrade and the remanufacturing. The electronic device 100 can be put into a target area for sale. After the user in the target area purchases the electronic device 100, at power-on, the electronic device 100 may read oem the format information (adapted to the new format of the target area) and write the format information into a custom file (custom. Bin) in the user data partition (Userdata) so as to be invoked during the running process of the operating system.

By implementing the method shown in fig. 3, the electronic device 100 can complete the reform operation in the process of upgrading the operating system, so that the problems of high hardware cost, large difficulty in deploying the reform authorization server and the like existing in the process of reform by using the traditional reform tool are avoided.

But the method shown in fig. 3 needs to undergo 3 restarts, and the period of the whole upgrade and remanufacturing is longer. Meanwhile, when restarting for the first time, the electronic device 100 operates in the Android mode, and a user can perform any operation. This easily breaks the preset flow, resulting in a reform failure and an operating system update failure. For example, before S110 is performed, if it is detected that the user makes an operation to restore factory settings, the electronic device 100 immediately formats Userdata. At this time, the merge operation, copy operation, and reform operation shown in S110 to S112 are interrupted, and the electronic device 100 fails in reform and in operating system update.

In order to shorten the period of upgrading and modifying, and enhance the robustness of upgrading and modifying program, avoiding the interruption of upgrading and modifying, further avoiding the failure of modifying and the failure of updating the operating system, the embodiment of the application provides another method for modifying the system along with the upgrading operation of the system. Fig. 5 is a flowchart of another electronic device 100 according to an embodiment of the present application for acquiring an upgrade retrofit package and performing an upgrade retrofit operation.

S200. configure snapshot and snapuser.

Snapshot is a tool that associates physical and logical addresses. When performing the merge operation, the electronic device 100 may generate a file map of the COW file in the virtual dynamic partition and a file map of a sub-partition corresponding to the dynamic partition (Super) based on the snapshot. snapuser is a tool to compress and decompress the COW files, writing COW files in virtual dynamic partition to dynamic partition (Super).

In the prior art, the recovery mode does not support snapshot and snapuser. Therefore, the electronic device 100 needs to perform the merge operation in the Android mode without improving the structure of the recovery mode. This also results in the electronic device 100 needing to enter the Android mode for the first time, and implementing the merge operation and copy operation in the Android mode, so as to ensure that the operating system is successfully upgraded.

In an embodiment of the present application, a developer may configure snapshot and snapuser for the recovery mode, so that the electronic device 100 may perform the merge operation in the recovery mode. The snapshot and snapuser described above may be referred to as a first toolkit.

Specifically, as shown in fig. 6, a binary file such as recovery, factory _reset may be included under the system/bin/path of the recovery mode. The developer can write lib_snapshot_programs and lib_snapshot_ nobinder function libraries in the recovery file. The lib_snapshot_utels and lib_snapshot_ nobinder are used for realizing the snapshot in the recovery mode. Meanwhile, a developer can also create Snapuserd files under the system/bin and write configuration files Snap userd.rc in the recovery file. system/bin/under creation Snapuserd file and recovery file configuration file snapsuserrc are used to implement snapuser in recovery mode.

After configuring snapshot and snapuser, electronic device 100 may perform the merge operation in the recovery mode. In this way, the electronic device 100 may directly enter the recovery mode when rebooting for the first time, and perform the merge operation, copy operation, and reform operation in the recovery mode. The electronic device 100 may then immediately perform a restore factory setting operation, clearing the data in the user data partition (Userdata), and clearing the old format in the custom file (custom. Bin).

S201, the ladle server prepares to upgrade and reform the ladle.

S202, the electronic equipment 100 obtains an upgrade and reform package from a package beating server through an update_apk_client.

S203, triggering Updata _engine to update.

And S204, checking up data_engine update and reconstruction package.

S205.updata_engine writes the operating system upgrade data in the upgrade and upgrade package to the corresponding memory partition: (1) Writing static partition upgrade data into the static partition (B); (2) Dynamic partition upgrade data is written to the virtual dynamic partition of Userdata.

S206, creating tmpvc, and writing the target standard VC_2.

Specifically, the steps shown in S201 to S206 may refer to the descriptions of S101 to S106, and are not described herein. The embodiment of the application does not limit the sequence of the occurrence of the step S200 and the step S201.

S207, writing in a factory restoration command.

After determining that the upgrade package includes system information (i.e., the upgrade package is specifically an upgrade retrofit package), updata _engine may write a restore factory command in the specific path. The specific path is a fixed mounting path of the electronic device 100 when the electronic device is turned on. Thus, at power-on, the electronic device 100 may fixedly read the above-described factory restoration command.

Specifically, updata _engine may write a command in a particular path/cache/command (also referred to as the first path): "-wipe_data", "-reflection=change_ vcand _wipe_data". The command is a restore factory command.

S208, triggering a restart (first restart) to enter a recovery mode.

Similarly, when Updata _engine performs the upgrade operations shown in S204 to S206, the update_apk_client may monitor the progress of the upgrade operations shown in S204 to S206. The electronic device 100 may display a corresponding progress control according to the progress detected by the update_apk_client, for displaying the upgrade progress to the user.

After the upgrade operation is completed, and after the restore factory command is written, updata _engine may return status information to update_apk_client that the upgrade is completed. Correspondingly, the progress control may instruct the user to show that the upgrade is complete. Subsequently, update_apk_client may trigger a restart. In the method shown in fig. 5, this restart is the first restart after starting to perform the upgrade reform operation.

During the restart process, the electronic device 100 reads the command in the first path and executes the operation indicated by the command. At this time, the electronic apparatus 100 may read (S207) the restoration factory command written to the first path (/ cache/command) described above: "-wipe_data", "-reflection=change_ vcand _wipe_data". The factory restoration command is parsed, and the electronic device 100 may enter a recovery mode.

S209, performing merge operation, and writing the COW files in the virtual dynamic partition into the dynamic partition (Super).

Based on the snapshot and snapuser configured in the recovery mode, after entering the recovery mode, recovery may read metadata (metadata) in the dynamic partition (Super) and the COW file in the virtual dynamic partition using the snapshot, and then write the COW file in the virtual dynamic partition into the dynamic partition (Super) using snapuser, which may be described with reference to S110.

S210, executing copy operation, and writing data in the static partition (B) into the static partition (A).

S211, writing the system information in the tmp into oem.

The steps shown in S210 to S211 may refer to the descriptions of S111 to S112, and will not be repeated here.

S212, formatting userdata partition clears custom files (custom. Bin).

Since it is currently in the recovery mode, the electronic device 100 may immediately perform the operation of restoring the factory setting, formatting Userdata the partition, after performing the merge operation, copy operation, and reform operation, i.e., after performing S209 to S211. Custom files (custom. Bin) in Userdata partition are also purged together when formatting Userdata partition.

Fig. 7 is a schematic diagram illustrating a change of a partition table of the electronic device 100 in another upgrading and remanufacturing process according to an embodiment of the present application.

The diagram (a) in fig. 7 may represent the partition representation intent of the electronic device 100 before the upgrade modification operation is performed (i.e., before step S205 is performed). Fig. 7 (b) may show a schematic diagram of a data structure of the upgrade kit. Fig. 7 (c) may represent a partition representation intent of the electronic device 100 after the upgrade modification operation is performed. Fig. 7 (a) to (c) are referred to fig. 4 (a) to (c), and will not be described again here.

In the method shown in fig. 5, at the first restart (S208), the electronic device 100 may directly enter the recovery mode. In the recovery mode, the electronic device 100 may sequentially perform the merge operation, copy operation, reform operation, and formatting Userdata operation without switching before the recovery mode, the Android mode.

As shown in fig. 7, at the time of the first restart, the electronic device 100 may enter the recovery mode according to the restore factory command written in the startup procedure. Referring to fig. 7 (d), in the recovery mode, performing a merge operation, the electronic device 100 may write dynamic partition upgrade data in the virtual dynamic partition in Userdata into a dynamic partition (Super); executing copy operation, the electronic device 100 may synchronize static partition upgrade data stored in sub-partitions such as bootloader_b and boot_b in the static partition (B) into the static partition (a); the electronic device 100 may write oem the new system stored in tmp to update the system of the electronic device 100 by performing the reform operation. Finally, in the recovery mode, the electronic device 100 may then perform the formatting Userdata to purge Userdata all of the user data. At this point, custom file (custom. Bin) in Userdata is purged.

The diagram (e) in fig. 7 may represent a partition representation intent of the electronic device 100 after performing the restore factory setting operation. At this point, the custom file (custom. Bin) in Userdata is empty.

After S212 is completed, the electronic device 100 completes the system upgrade and the remanufacturing. The electronic device 100 can be put into a target area for sale. After the user in the target area purchases the electronic device 100, at power-on, the electronic device 100 may read oem the format information (adapted to the new format of the target area) and write the format information into a custom file (custom. Bin) in the user data partition (Userdata) so as to be invoked during the running process of the operating system.

Compared to the method shown in fig. 3, the method shown in fig. 5 may perform a merge operation, copy operation, reform operation, and restore factory operation in the recovery mode. The electronic device 100 does not need to be restarted for multiple times, which is beneficial to shortening the whole upgrade and reform period and improving the upgrade and reform speed. Meanwhile, the method and the device restart to enter the recovery mode, so that the operation of a user in the upgrading and reform operation process is limited, and reform failure and operating system update failure caused by interruption of the upgrading and reform flow by the user operation are avoided.

The electronic device 100 may include a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (universal serial bus, USB) interface 130, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, a sensor module 180, a display 194, and the like. Wherein the sensor module 180 may include a pressure sensor 180A, a touch sensor 180K, etc.

It should be understood that the illustrated structure of the embodiment of the present application does not constitute a specific limitation on the electronic device 100. In other embodiments of the application, electronic device 100 may include more or fewer components than shown, or certain components may be combined, or certain components may be split, or different arrangements of components. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

The processor 110 may include one or more processing units, such as: the processor 110 may include an application processor (application processor, AP), a modem processor, a graphics processor (graphics processing unit, GPU), an image signal processor (IMAGE SIGNAL processor, ISP), a controller, a video codec, a digital signal processor (DIGITAL SIGNAL processor, DSP), a baseband processor, and/or a neural-Network Processor (NPU), etc. Wherein the different processing units may be separate devices or may be integrated in one or more processors. The controller can generate operation control signals according to the instruction operation codes and the time sequence signals to finish the control of instruction fetching and instruction execution. A memory may also be provided in the processor 110 for storing instructions and data.

In some embodiments, the processor 110 may include one or more interfaces. The interfaces may include an integrated circuit (inter-INTEGRATED CIRCUIT, I2C) interface, an integrated circuit built-in audio (inter-INTEGRATED CIRCUIT SOUND, I2S) interface, a pulse code modulation (pulse code modulation, PCM) interface, a universal asynchronous receiver transmitter (universal asynchronous receiver/transmitter, UART) interface, a mobile industry processor interface (mobile industry processor interface, MIPI), a general-purpose input/output (GPIO) interface, a subscriber identity module (subscriber identity module, SIM) interface, and/or a universal serial bus (universal serial bus, USB) interface, among others.

Illustratively, the processor 110 may couple the touch sensor 180K through an I2C interface, causing the processor 110 to communicate with the touch sensor 180K through an I2C bus interface, implementing the touch functionality of the electronic device 100. The processor 110 communicates with a bluetooth module in the wireless communication module 160 through a UART interface to implement a bluetooth function. The MIPI interface includes a display serial interface (DISPLAY SERIAL INTERFACE, DSI). The processor 110 and the display 194 communicate via a DSI interface to implement the display functionality of the electronic device 100. The GPIO interface may be configured by software. The GPIO interface may be configured as a control signal or as a data signal. The GPIO interface may also be configured as an I2C interface, an I2S interface, a UART interface, an MIPI interface, etc.

The USB interface 130 is an interface conforming to the USB standard specification, and may specifically be a Mini USB interface, a Micro USB interface, a USB Type C interface, or the like. The USB interface 130 may be used to connect a charger to charge the electronic device 100, and may also be used to transfer data between the electronic device 100 and a peripheral device. In the embodiment of the present application, the electronic device 100 may be connected to a special modification tool through the USB interface 130 to modify the system of the electronic device 100.

It should be understood that the interfacing relationship between the modules illustrated in the embodiments of the present application is only illustrative, and is not meant to limit the structure of the electronic device 100. In other embodiments of the present application, the electronic device 100 may also employ different interfacing manners in the above embodiments, or a combination of multiple interfacing manners.

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

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

The mobile communication module 150 may provide a solution for wireless communication including 2G/3G/4G/5G, etc., applied to the electronic device 100. The mobile communication module 150 may include at least one filter, switch, power amplifier, low noise amplifier (low noise amplifier, LNA), etc. The mobile communication module 150 may receive electromagnetic waves from the antenna 1, perform processes such as filtering, amplifying, and the like on the received electromagnetic waves, and transmit the processed electromagnetic waves to the modem processor for demodulation. The mobile communication module 150 can amplify the signal modulated by the modem processor, and convert the signal into electromagnetic waves through the antenna 1 to radiate. In some embodiments, at least some of the functional modules of the mobile communication module 150 may be disposed in the processor 110. In some embodiments, at least some of the functional modules of the mobile communication module 150 may be provided in the same device as at least some of the modules of the processor 110.

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

The wireless communication module 160 may provide solutions for wireless communication including wireless local area network (wireless local area networks, WLAN) (e.g., wireless fidelity (WIRELESS FIDELITY, wi-Fi) network), bluetooth (BT), global navigation satellite system (global navigation SATELLITE SYSTEM, GNSS), frequency modulation (frequency modulation, FM), near field communication (NEAR FIELD communication, NFC), infrared (IR), etc., applied to the electronic device 100. The wireless communication module 160 may be one or more devices that integrate at least one communication processing module. The wireless communication module 160 receives electromagnetic waves via the antenna 2, modulates the electromagnetic wave signals, filters the electromagnetic wave signals, and transmits the processed signals to the processor 110. The wireless communication module 160 may also receive a signal to be transmitted from the processor 110, frequency modulate it, amplify it, and convert it to electromagnetic waves for radiation via the antenna 2.

In the embodiment of the present application, the electronic device 100 may obtain the upgrade and reform package from the package-beating server through the wireless communication functions provided by the antenna 1, the antenna 2, the mobile communication module 150, the wireless communication module 160, the modem processor and the baseband processor, so as to perform the upgrade and reform operation.

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

The display screen 194 is used to display images, videos, and the like. The display 194 includes a display panel. The display 194 includes a display panel. The display panel may employ a Liquid Crystal Display (LCD). The display panel may also be manufactured using organic light-emitting diodes (OLED), active-matrix organic LIGHT EMITTING diode (AMOLED), flexible light-emitting diodes (FLED), miniled, microled, micro-OLED, quantum dot LIGHT EMITTING diodes (QLED), or the like. In some embodiments, the electronic device may include 1 or N display screens 194, N being a positive integer greater than 1.

In the embodiment of the present application, the electronic device 100 may display a user interface through a GPU, a display screen 194, and a display function provided by an application processor, for example, a user interface for obtaining an upgrade and reform package, a user interface for displaying an upgrade progress in an upgrade and reform process, and the like, so as to enable a user to perform an upgrade and reform operation.

The internal memory 121 may include one or more random access memories (random access memory, RAM) and one or more non-volatile memories (NVM). The random access memory may be read directly from and written to by the processor 110, may be used to store executable programs (e.g., machine instructions) for an operating system or other on-the-fly programs, may also be used to store data for users and applications, and the like. The nonvolatile memory may store executable programs, store data of users and applications, and the like, and may be loaded into the random access memory in advance for the processor 110 to directly read and write.

In the embodiment of the present application, the memory corresponding to the partition table of the electronic device 100 shown in fig. 1 refers to the above-mentioned nonvolatile memory. Program codes such as system information, boot strap program, system running program, etc. of the electronic device 100 are stored in the nonvolatile memory. When the electronic device 100 is started up and operated, the electronic device 100 may load the program codes stored in the nonvolatile memory into the random access memory and then send the program codes to the processor 110 for execution, so as to implement the method for changing and modifying according to the system upgrading operation provided by the embodiment of the application.

The external memory interface 120 may be used to connect external non-volatile memory to enable expansion of the memory capabilities of the electronic device 100. The external nonvolatile memory communicates with the processor 110 through the external memory interface 120 to implement a data storage function.

The pressure sensor 180A is used to sense a pressure signal, and may convert the pressure signal into an electrical signal. In some embodiments, the pressure sensor 180A may be disposed on the display screen 194. When a touch operation is applied to the display screen 194, the electronic apparatus 100 detects the touch operation intensity according to the pressure sensor 180A. The electronic device 100 may also calculate the location of the touch based on the detection signal of the pressure sensor 180A.

The touch sensor 180K, also referred to as a "touch device". The touch sensor 180K may be disposed on the display screen 194, and the touch sensor 180K and the display screen 194 form a touch screen, which is also called a "touch screen". The touch sensor 180K is for detecting a touch operation acting thereon or thereabout. The touch sensor may communicate the detected touch operation to the application processor to determine the touch event type. Visual output related to touch operations may be provided through the display 194. In other embodiments, the touch sensor 180K may also be disposed on the surface of the electronic device 100 at a different location than the display 194.

In the embodiment of the present application, the electronic device 100 may detect user operations such as clicking, sliding, etc. of a user acting on a screen, obtain an upgrade and reform package, display an upgrade and reform progress, etc. through the touch detection capability provided by the touch sensor 180K.

The term "User Interface (UI)" in the description and claims of the present application and in the drawings is a media interface for interaction and information exchange between an application program or an operating system and a user, which enables conversion between an internal form of information and a form acceptable to the user. The user interface of the application program is a source code written in a specific computer language such as java, extensible markup language (extensible markup language, XML) and the like, the interface source code is analyzed and rendered on the terminal equipment, and finally the interface source code is presented as content which can be identified by a user, such as a control of pictures, words, buttons and the like. Controls (controls), also known as parts (widgets), are basic elements of a user interface, typical controls being a toolbar (toolbar), menu bar (menu bar), text box (text box), button (button), scroll bar (scrollbar), picture and text. The properties and content of the controls in the interface are defined by labels or nodes, such as XML pass < Textview >, < ImgView >, XML pass,

< VideoView > et al to specify controls contained by the interface. One node corresponds to a control or attribute in the interface, and the node is rendered into visual content for a user after being analyzed and rendered. In addition, many applications, such as the interface of a hybrid application (hybrid application), typically include web pages. A web page, also referred to as a page, is understood to be a special control embedded in an application interface, the web page being source code written in a specific computer language, such as hypertext markup language (hyper text markup language, HTML), cascading style sheets (CASCADING STYLE SHEETS, CSS), java script (JavaScript, JS), etc., the web page source code being loadable and displayable as user identifiable content by a browser or web page display component similar to the browser functionality. The specific content contained in a web page is also defined by tags or nodes in the web page source code, such as HTML defines the elements and attributes of the web page by < p >, < img >, < video >, < canvas >.

A commonly used presentation form of a user interface is a graphical user interface (graphic user interface, GUI), which refers to a graphically displayed user interface that is related to computer operations. It may be an interface element such as an icon, a window, a control, etc. displayed in a display screen of the electronic device, where the control may include a visual interface element such as an icon, a button, a menu, a tab, a text box, a dialog box, a status bar, a navigation bar, a Widget, etc.

As used in the specification of the present application and the appended claims, the singular forms "a," "an," "the," and "the" are intended to include the plural forms as well, unless the context clearly indicates to the contrary. It should also be understood that the term "and/or" as used in this disclosure refers to and encompasses any or all possible combinations of one or more of the listed items. As used in the above embodiments, the term "when …" may be interpreted to mean "if …" or "after …" or "in response to determination …" or "in response to detection …" depending on the context. Similarly, the phrase "at the time of determination …" or "if detected (a stated condition or event)" may be interpreted to mean "if determined …" or "in response to determination …" or "at the time of detection (a stated condition or event)" or "in response to detection (a stated condition or event)" depending on the context.

In the above embodiments, it may be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented in software, may be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When loaded and executed on a computer, produces a flow or function in accordance with embodiments of the present application, in whole or in part. The computer may be a general purpose computer, a special purpose computer, a computer network, or other programmable apparatus. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium, for example, the computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center by a wired (e.g., coaxial cable, fiber optic, digital subscriber line), or wireless (e.g., infrared, wireless, microwave, etc.). The computer readable storage medium may be any available medium that can be accessed by a computer or a data storage device such as a server, data center, etc. that contains an integration of one or more available media. The usable medium may be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid state disk), etc.

Those of ordinary skill in the art will appreciate that implementing all or part of the above-described method embodiments may be accomplished by a computer program to instruct related hardware, the program may be stored in a computer readable storage medium, and the program may include the above-described method embodiments when executed. And the aforementioned storage medium includes: ROM or random access memory RAM, magnetic or optical disk, etc.

Claims

1. A method for configuring a standard, applied to an electronic device, wherein a memory of the electronic device includes a base partition, a system partition and a user data partition, the base partition includes a first storage block oem, the oem stores a first standard therein, the user data partition also stores the first standard therein, the system partition includes a first static partition, a second static partition and a dynamic partition, and the electronic device is started from the first static partition, the method includes:

acquiring a first data packet, wherein the first data packet comprises upgrade data of a target operating system and a target system, and the target system is different from the first system;

Writing the static partition upgrade data in the upgrade data into the second static partition; applying for a second storage block tmp in the basic partition, and writing the target system into the tmp; writing a factory recovery command;

executing a restarting operation, and responding to the restarting command in the restarting process, and entering a restarting mode;

In the recovery mode, the dynamic partition upgrading data in the upgrading data is dropped to the system partition; writing the target system cached in the tmp into the oem; formatting the user data partition.

2. The method of claim 1, wherein prior to performing the reboot operation, the method further comprises:

The first tool snapshot and the second tool snapuser are configured,

The snapshot is used for associating a physical address and a logical address in the recovery mode, and the snapuser is used for copying files when the abbreviations are compressed and decompressed in the recovery mode;

The step of landing the dynamic partition upgrade data in the upgrade data to the system partition specifically includes:

And landing the dynamic partition upgrade data cached in the user data partition to the system partition by using the snapshot and snapuser.

3. The method of claim 1 or 2, wherein the electronic device is operated in an android mode prior to the performing of the reboot operation.

4. The method of claim 1, wherein the write recovery command specifically comprises: writing the recovery command under a first path of the memory, wherein the first path is a fixed mounting path for starting up the electronic equipment.

5. The method of claim 4, wherein the first path is specifically/cache/command.

6. The method of any of claims 1-5, wherein the operating system currently in use by the electronic device is a presenter operating system and the target operating system is a business machine operating system.

7. An electronic device comprising one or more processors and one or more memories; wherein the one or more memories are coupled to the one or more processors, the one or more memories for storing computer program code comprising computer instructions that, when executed by the one or more processors, cause the method of any of claims 1-6 to be performed.

8. A computer readable storage medium comprising instructions which, when run on an electronic device, cause the method of any one of claims 1-6 to be performed.