CN116668285A - Method, device and storage medium for configuring system - Google Patents
Method, device and storage medium for configuring system Download PDFInfo
- Publication number
- CN116668285A CN116668285A CN202211550681.XA CN202211550681A CN116668285A CN 116668285 A CN116668285 A CN 116668285A CN 202211550681 A CN202211550681 A CN 202211550681A CN 116668285 A CN116668285 A CN 116668285A
- Authority
- CN
- China
- Prior art keywords
- partition
- electronic device
- operating system
- upgrade
- data
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000000034 method Methods 0.000 title claims abstract description 104
- 238000005192 partition Methods 0.000 claims description 371
- 230000003068 static effect Effects 0.000 claims description 117
- 238000011084 recovery Methods 0.000 claims description 70
- 230000015654 memory Effects 0.000 claims description 36
- 230000004044 response Effects 0.000 claims description 6
- 238000004590 computer program Methods 0.000 claims description 5
- 238000010926 purge Methods 0.000 claims description 4
- 230000008569 process Effects 0.000 abstract description 29
- 238000013475 authorization Methods 0.000 abstract description 6
- 238000004891 communication Methods 0.000 description 29
- 238000010586 diagram Methods 0.000 description 16
- 238000012986 modification Methods 0.000 description 12
- 230000004048 modification Effects 0.000 description 12
- 230000008859 change Effects 0.000 description 10
- 238000010295 mobile communication Methods 0.000 description 10
- 230000006870 function Effects 0.000 description 9
- 238000013507 mapping Methods 0.000 description 8
- 238000012545 processing Methods 0.000 description 8
- 230000006978 adaptation Effects 0.000 description 6
- 238000001514 detection method Methods 0.000 description 5
- 229920001621 AMOLED Polymers 0.000 description 4
- 238000010009 beating Methods 0.000 description 4
- 238000005516 engineering process Methods 0.000 description 3
- 230000000007 visual effect Effects 0.000 description 3
- 238000013473 artificial intelligence Methods 0.000 description 2
- 238000013528 artificial neural network Methods 0.000 description 2
- 230000003190 augmentative effect Effects 0.000 description 2
- 238000013500 data storage Methods 0.000 description 2
- 239000004973 liquid crystal related substance Substances 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 239000000047 product Substances 0.000 description 2
- 239000002096 quantum dot Substances 0.000 description 2
- 230000001960 triggered effect Effects 0.000 description 2
- 238000012795 verification Methods 0.000 description 2
- 230000009286 beneficial effect Effects 0.000 description 1
- 238000004364 calculation method Methods 0.000 description 1
- 230000001413 cellular effect Effects 0.000 description 1
- 238000006243 chemical reaction Methods 0.000 description 1
- 239000003795 chemical substances by application Substances 0.000 description 1
- 239000013065 commercial product Substances 0.000 description 1
- 239000000835 fiber Substances 0.000 description 1
- 238000001914 filtration Methods 0.000 description 1
- 230000010354 integration Effects 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 238000002715 modification method Methods 0.000 description 1
- 230000002093 peripheral effect Effects 0.000 description 1
- 230000036316 preload Effects 0.000 description 1
- 230000005855 radiation Effects 0.000 description 1
- 238000002407 reforming Methods 0.000 description 1
- 238000009877 rendering Methods 0.000 description 1
- 238000011160 research Methods 0.000 description 1
- 239000004065 semiconductor Substances 0.000 description 1
- 238000004904 shortening Methods 0.000 description 1
- 239000007787 solid Substances 0.000 description 1
- 238000000638 solvent extraction Methods 0.000 description 1
- 230000005236 sound signal Effects 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/0803—Configuration setting
- H04L41/0813—Configuration setting characterised by the conditions triggering a change of settings
- H04L41/082—Configuration setting characterised by the conditions triggering a change of settings the condition being updates or upgrades of network functionality
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Stored Programmes (AREA)
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
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, and the like.
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 an actual application scenario, there is a case where the system is changed. 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, 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 the target format cached in tmp into oem; the method comprises the steps of clearing a first standard stored in a customized file, writing the customized file into a target standard in oem when the electronic equipment is started, wherein starting refers to starting after 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 combination with the method provided in the first aspect, in some embodiments, the method for clearing the custom file includes: formatting Userdata.
By implementing the method provided by the embodiment, the electronic device can remove the custom file by formatting the 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 functions of restoring factory settings provided by the recovery mode are used for formatting Userdata and clearing the custom file.
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 the upgrade data of the target operating system in the 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 the 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 modifying in the recovery mode is completed, multiple restarting is avoided, the working modes (android mode and recovery mode) of the electronic equipment are switched, the modifying speed is improved, and the modifying 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 some embodiments, the method provided in the first aspect writes oem the target format cached in tmp, and upgrades the operating system of the electronic device to the target operating system using the upgrade data of the target operating system in the first data packet, which is done 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 when 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 the recovery mode by detecting that the target formats stored in oem of the custom file store are inconsistent when 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 (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, with embodiments of the application not being particularly limited as to the particular type of electronic device.
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 an actual application scenario, there is a case where the system is changed.
For example, after the equipment in zone A is sold out, the shipment from zone B is required. In this case, 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 in the base partition (Common), such as the oemiinfo sub-partition. Typically, the oemiinfo sub-partition includes oem. The system recorded in oem is the formal system of the current electronic device 100. The current system of the electronic apparatus 100 recorded in oem before the modification is also referred to as a 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. In the remanufacturing process, the electronic device 100 may create a tmp in the oemiinfo 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 the system information in oem, and writes the system information into a custom file in a 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 whether the format information recorded in oem matches the format information in a custom file (custom. 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 format 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 the Updata_engine to update.
S104, checking the upgrade and reform package.
The upgrade module (updata_engine) is a functional module preset in the electronic device 100 and storing upgrade and modification processing logic, and may be used to perform upgrade and modification operations. After obtaining the upgrade re-package, first, the updata_engine may check the upgrade re-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) And writing the dynamic partition upgrade data into the virtual dynamic partition of the Userdata.
When the upgrade and reform package passes the verification, the 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 adaptation package to static partition (B). The write operation has a case of write failure. When a write failure occurs, the 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.
The 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 is 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, the updata_engine may calculate a hash value of the data in the static partition (B) and determine whether the hash value of the data in the static partition (B) is consistent with the hash value of the static partition upgrade data of OS2.0 recorded in the upgrade adaptation packet. If the two types of information are consistent, the writing is successful, and the 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 |
The Updata_Engine may read a fixed mount path, such as/dev/block/by-name/MIsc, from the Common partition to determine that the electronic device 100 is currently booting from either static partition (A) or static partition (B). Then, based on the scenario 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, the Updata_engine writes the upgrade data of the corresponding sub-partition boot in the OS2.0 into the sub-partition boot_b, namely under the/dev/block/by-name/boot_b. After the write operation is completed, the 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), and determine whether the HASH value of the sub-partition boot_b is consistent with 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.
The updata_engine can write the upgrade data of each static partition sub-partition contained in the upgrade and update 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, the 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 partition may be stored in metadata (/ matadata) of the Common partition.
Illustratively, the updata_engine may mark the static partition (B) as not bootable before upgrading the static partition (B), and the updata_engine may mark the static partition as bootable after the static partition (B) is upgraded successfully. 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 the dynamic partition upgrade data into a virtual dynamic partition of Userdata:
the updata_engine may create a virtual dynamic partition in a user data partition (Userdata) and write dynamic partition upgrade data in an 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, the updata_engine may create a virtual dynamic partition in Userdata. The updata_engine may then 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, a virtual dynamic partition of a user data partition (Userdata) may only store dynamic partition upgrade data that needs to be upgraded in the old operating system, rather than storing all 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, when upgrading from OS1.0 to OS2.0, system1 needs to be upgraded to system3, and system2 does not need to be changed. At this point, the user data partition (Userdata) only needs to write to system3 to create a virtual dynamic partition.
Under the virtual A/B framework, updata_Engine can implement incremental upgrades of dynamic partitions (Super) through snapshot technology (snapshot). Specifically, the Updata_Engine may use Copy-On-Write (COW) files in the virtual dynamic partition to save 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.
After all the COW files in the upgrade remanufacturing package are acquired, an a/B partition mark can 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 the electronic device 100 is dynamic partition (a)), a virtual dynamic partition created by updata_engine in the user data partition (Userdata) is for dynamic partition (B). At this time, the updata_engine may attach a partition flag corresponding to the 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).
Based on the file map of the dynamic partition (Super) sub-partition and the COW file map, the updata_engine can use the COW file to replace the corresponding file in the dynamic partition (Super) sub-partition subsequently, so that the upgrade of the dynamic partition (Super) data is realized.
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 given after the file name in Table 2 (e.g., 024010 ~ 024013 in/system/app/A0. XXX: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 by the file names in Table 3 are the physical storage addresses (block addresses) of the COW files/systems/apps/A2.XXX,/systems/users/C2. XXX, which are 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.
In general, the upgrade package downloaded from the beat server by updata_engine does not include system information. After completing S104 and S105, the 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 after obtaining the upgrade package, the updata_engine needs to determine whether the upgrade package downloaded from the package server is used for modification. The updata_engine can determine whether to be used for remanufacturing according to whether the upgrade package contains system information. After determining to reform, the updata_engine may create tmp-vc in the oemiinfo sub-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 acquiring the upgrade adaptation packet, updata_engine may determine that the data is also used for adaptation. At this time, the updata_engine may create tmp-VC in the oemiinfo sub-partition and write the target format vc_2 to the tmp-VC.
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 the 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 added to the oemiinfo 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). Virtual dynamic partitions are newly added in Userdata, and are used for storing dynamic partition upgrade data of the operating System OS2.0, for example, a System (2.0).
S107: and returning the state information of finishing the upgrading.
When the Updata_Engine performs the upgrade operations shown in S104-S106, the update_apk_client may monitor the progress of the upgrade operations shown in S104-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, the updata_engine may return status information of completing the upgrade 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 status information that the update_engine returns to complete the upgrade, the 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: detect whether or not the format in oem matches the format 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. cure_init can be used to detect if the format in oem matches the format 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 custom file (custom. Bin) according to the new format in oem, thereby re-matching the format in oem with the format in 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 the dynamic partition upgrade data into the virtual dynamic partition of 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)", indicating that there is currently a COW file that needs to be dropped to the dynamic partition (Super).
Upon performing S110, according to the drop state information "no drop (wait for merge)", updata_engine may determine to perform a drop (merge) operation. In the present specification, the landing operation means: in the upgrading process of the 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 data upgrading operation. 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, the updata_engine may write the COW file of the virtual dynamic partition in the user data partition (Userdata) to the 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 an example in S105, when performing the merge operation, updata_engine may write upgrade data of the sub-partition systems in the virtual dynamic partition into the sub-partition systems in the dynamic partition (Super). For example, updata_engine may obtain COW file a2.Xxx according to address 045033 ~ 045035 and replace data a2.Xxx to be updated at address 024018 ~ 024020, obtain c2.Xxx according to address 045036 ~ 045040COW file and replace 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), the updata_engine may delete the COW file in the user data partition (Userdata) and restore the corresponding storage space to the user data partition (Userdata). Meanwhile, updata_engine may change the disk-dropped state information in 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), and 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 in oem.
The updata_engine may write the new format vc_2 cached in tmp into oem. After the writing oem, the formal system of the electronic device 100 is updated to the new system 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 can be written into sub-partition System (1.0) in dynamic partition (Super) by 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, the 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 whether the system in oem matches the system in custom file (custom.
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, and 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 that the format in oem does not match the format in custom file (custom. 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 can format the Userdata 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 the format information in oem (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.
However, the method shown in fig. 3 requires 3 restarts, and the period of the entire upgrade remanufacturing is long. 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, configuring 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. The snapuser is a tool for compressing and decompressing the COW file and writing the COW file in the virtual dynamic partition into the 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 a merge operation in the recovery mode. The above-described snapshot and snapuser may be referred to as a first toolkit.
Specifically, as shown in fig. 6, the system/bin/path of the recovery mode may include a binary file such as recovery, factory _reset. The developer can write lib_snapshot_programs and lib_snapshot_nonbinder function libraries in the recovery file. The lib_snapshot_units and lib_snapshot_nonbinder are used for realizing snapshot in the recovery mode. Meanwhile, a researcher can also create a Snapeuse file under the system/bin/and write a configuration file Snapeuse.rc in the recovery file. The system/bin/lower creates a snapsused file and a recovery file configuration file snapsused. Rc for implementing snapuser in recovery mode.
After configuring the snapshot and snapuser, the electronic device 100 may perform a 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. Then, the electronic device 100 may immediately perform a factory reset operation, clear data in the user data partition (Userdata), and clear old standard in the custom file (custom.
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 the Updata_Engine to update and reform.
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) And writing the dynamic partition upgrade data into the virtual dynamic partition of the Userdata.
S206, creating tmpvc, and writing the tmpvc into a target system 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 the standard information (i.e., the upgrade package is specifically an upgrade remanufacturing package), the updata_engine may write a restore factory command in a 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, the updata_engine may write a command in a specific path/cache/command (also referred to as a 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 the Updata_Engine performs the upgrade operations shown in S204-S206, the update_apk_client may monitor the progress of the upgrade operations shown in S204-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 factory restore command is written, the updata_engine may return status information to the 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, the recovery may read metadata (metadata) in the dynamic partition (Super) and the COW file in the virtual dynamic partition (Super) by using the snapshot, and then write the COW file in the virtual dynamic partition into the dynamic partition (Super) by using the snapuser, which may be described specifically 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 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, and format the Userdata partition after performing the merge operation, copy operation, and reform operation, i.e., after performing S209 to S211. Custom files (custom. Bins) in the Userdata partition are also purged together when the Userdata partition is formatted.
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 a merge operation, copy operation, a reform operation, and an operation of formatting Userdata 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 a 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 apparatus 100 may write the new system stored in tmp to oem to update the system of the electronic apparatus 100 by performing the remanufacturing operation. Finally, in the recovery mode, the electronic device 100 may immediately perform an operation of formatting Userdata, and remove all user data of Userdata. At this point, the 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 the format information in oem (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.
Fig. 8 is a schematic structural diagram of an electronic device 100 according to an embodiment of the present application.
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 (neural-network processing unit, 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 wireless communication technology (near field communication, NFC), infrared technology (IR), etc., as 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 (liquid crystal display, LCD). The display panel may also be manufactured using organic light-emitting diode (OLED), active-matrix organic light-emitting diode (AMOLED) or active-matrix organic light-emitting diode (active-matrix organic light emitting diode), flexible light-emitting diode (FLED), mini, micro-OLED, quantum dot light-emitting diode (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 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 picture, characters, buttons and the like. Controls (controls), also known as parts (widgets), are basic elements of a user interface, typical controls being toolbars (toolbars), menu bars (menu bars), text boxes (text boxes), buttons (buttons), scroll bars (scrollbars), pictures and text. The properties and content of the controls in the interface are defined by labels or nodes, such as XML passing < Textview >, < ImgView >, XML passing,
Nodes such as < VideoView > specify controls included in 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 program interface, which is 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., and which can be loaded and displayed as user-recognizable content by a browser or web page display component similar to the browser's 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 the user interface is a graphical user interface (graphic user interface, GUI), which refers to a user interface related to computer operations that is displayed in a graphical manner. 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 (12)
1. A method for configuring a standard, applied to an electronic device, wherein a first storage block oem in the electronic device stores a first standard, the first standard is a standard currently used by the electronic device, the electronic device further includes a custom file, and the custom file also stores the first standard, 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 into a second storage block tmp of the electronic equipment;
upgrading the operating system of the electronic equipment into the target operating system by utilizing the upgrading data of the target operating system;
Writing the target system cached in the tmp into the oem;
clearing the first standard stored in the customized file, wherein the customized file is written into the target standard in the oem when the electronic equipment is started, and the starting refers to starting after clearing;
wherein the purging occurs after the upgrading of the operating system of the electronic device to the target operating system.
2. The method of claim 1, wherein the custom file is stored in a user data partition Userdata of a memory of the electronic device, and the clearing the first standard stored in the custom file specifically comprises: formatting the Userdata.
3. The method according to claim 1 or 2, characterized in that the method further comprises: executing a restarting operation, and entering the recovery mode; the purging of custom files is done in the recovery mode.
4. The method of claim 3, wherein 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 includes a first static partition, a second static partition and a dynamic partition,
The upgrading the operating system of the electronic device to the target operating system by using the upgrading data of the target operating system in the first data packet specifically includes:
writing the upgrade data of the target operating system in the first data packet into the second static partition and a virtual dynamic partition in a state that the electronic device is started from the first static partition, wherein the virtual dynamic partition is a section of storage partition in the Userdata;
writing the upgrade data of the target operating system stored in the second static partition into the first static partition in the recovery mode; writing the upgrade data of the target operating system stored in the virtual dynamic partition into the dynamic partition in the recovery mode;
the writing of the target format cached in the tmp into the oem is completed in the recovery mode.
5. The method according to claim 4, wherein the method further comprises:
configuring a first toolkit for a recovery mode of the electronic device;
writing the upgrade data of the target operating system stored in the virtual dynamic partition into the dynamic partition in the recovery mode, wherein the method specifically comprises the following steps: 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 pack.
6. The method of claim 4 or 5, wherein the electronic device is operated in an android mode prior to performing a reboot operation to enter the recovery mode.
7. The method of any of claims 3-6, wherein prior to performing the restart operation, the method further comprises: writing a restore factory command; the executing the restarting operation, entering the recovery mode specifically includes: and executing a restarting operation, and responding to the factory restoration command, and entering the recovery mode.
8. The method of claim 7, wherein the writing a restore factory command specifically comprises: and writing the 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.
9. The method of claim 3, wherein the writing the target format cached in the tmp to the oem and the upgrading the operating system of the electronic device to the target operating system using the upgrade data of the target operating system in the first data packet are accomplished in the android mode;
The executing the restarting operation, entering the recovery mode specifically includes:
executing a restarting operation, and detecting that the first standard stored in the customized file is inconsistent with the target standard stored in the oem when restarting; in response to the inconsistency, a recovery mode is entered.
10. The method of any of claims 1-9, 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.
11. 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-10 to be performed.
12. A computer readable storage medium comprising instructions which, when run on an electronic device, cause the method of any one of claims 1-10 to be performed.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202211550681.XA CN116668285B (en) | 2022-12-05 | 2022-12-05 | Method, device and storage medium for configuring system |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202211550681.XA CN116668285B (en) | 2022-12-05 | 2022-12-05 | Method, device and storage medium for configuring system |
Publications (2)
Publication Number | Publication Date |
---|---|
CN116668285A true CN116668285A (en) | 2023-08-29 |
CN116668285B CN116668285B (en) | 2024-05-03 |
Family
ID=87717773
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202211550681.XA Active CN116668285B (en) | 2022-12-05 | 2022-12-05 | Method, device and storage medium for configuring system |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN116668285B (en) |
Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20180314832A1 (en) * | 2017-05-01 | 2018-11-01 | Kabushiki Kaisha Toshiba | Information processing apparatus and computer readable storage medium |
CN110543321A (en) * | 2019-09-06 | 2019-12-06 | 深圳市英博超算科技有限公司 | OTA (over the air) upgrading method, device, terminal and computer readable storage medium |
CN112423288A (en) * | 2020-10-28 | 2021-02-26 | 深圳市广和通无线股份有限公司 | Dialing analysis method and device, computer equipment and storage medium |
CN114489813A (en) * | 2021-07-30 | 2022-05-13 | 荣耀终端有限公司 | Method, equipment and storage medium for configuring operating system |
CN114661322A (en) * | 2022-03-11 | 2022-06-24 | 荣耀终端有限公司 | Upgrading method of operating system, electronic equipment and storage medium |
WO2022227974A1 (en) * | 2021-04-26 | 2022-11-03 | 深圳Tcl新技术有限公司 | Subtitle processing method, apparatus and device and storage medium |
-
2022
- 2022-12-05 CN CN202211550681.XA patent/CN116668285B/en active Active
Patent Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20180314832A1 (en) * | 2017-05-01 | 2018-11-01 | Kabushiki Kaisha Toshiba | Information processing apparatus and computer readable storage medium |
CN110543321A (en) * | 2019-09-06 | 2019-12-06 | 深圳市英博超算科技有限公司 | OTA (over the air) upgrading method, device, terminal and computer readable storage medium |
CN112423288A (en) * | 2020-10-28 | 2021-02-26 | 深圳市广和通无线股份有限公司 | Dialing analysis method and device, computer equipment and storage medium |
WO2022227974A1 (en) * | 2021-04-26 | 2022-11-03 | 深圳Tcl新技术有限公司 | Subtitle processing method, apparatus and device and storage medium |
CN114489813A (en) * | 2021-07-30 | 2022-05-13 | 荣耀终端有限公司 | Method, equipment and storage medium for configuring operating system |
CN114661322A (en) * | 2022-03-11 | 2022-06-24 | 荣耀终端有限公司 | Upgrading method of operating system, electronic equipment and storage medium |
Non-Patent Citations (1)
Title |
---|
丁正庭;: "微机控制通用式机车信号", 中国铁路, no. 01 * |
Also Published As
Publication number | Publication date |
---|---|
CN116668285B (en) | 2024-05-03 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US9262153B2 (en) | Firmware update discovery and distribution | |
US9301164B2 (en) | Method, system, and terminal for performing system update between mobile communication terminals | |
US8719810B2 (en) | Program upgrade system and method for over the air-capable mobile terminal | |
US9110761B2 (en) | Resource data structures for firmware updates | |
US9235404B2 (en) | Firmware update system | |
US20220100490A1 (en) | Firmware updating method, and electronic apparatus and storage media for same | |
US8560822B1 (en) | Pre-boot operating environment | |
CN115543368B (en) | Operating system upgrading method and electronic equipment | |
US20140109071A1 (en) | Method for updating operating system and handheld electronic apparatus | |
US20170026421A1 (en) | Apparatus and method for supporting back-up and restore of environment for performing a function | |
US9110678B1 (en) | Automated BIOS enhancements and upgrades | |
CN113672296B (en) | Custom application switching method, switching device, electronic equipment and storage medium | |
KR102516583B1 (en) | Electronic device and method for controling update thereof | |
CN116048628B (en) | Equipment starting method and electronic equipment | |
CN110515671B (en) | Initialization method, initialization device, terminal device and readable storage medium | |
CN111433747A (en) | Virtual memory for loading an operating system | |
CN114385251A (en) | Operating system booting method, system, terminal and storage medium based on memory | |
CN116668285B (en) | Method, device and storage medium for configuring system | |
CN116719670B (en) | Data processing method, electronic device and readable storage medium | |
US20150212866A1 (en) | Management system for service of multiple operating environments, and methods thereof | |
CN115951920A (en) | Mobile equipment upgrading method and device, storage unit and mobile equipment | |
WO2024119895A1 (en) | Operating system upgrade method, device, and storage medium | |
CN111381892A (en) | Data processing method, device, equipment and machine readable medium | |
CN113721959A (en) | Information processing method and device and electronic equipment | |
CN110134456B (en) | Method, apparatus, device and storage medium for managing operating system |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |