WO2019042256A1 - Method and apparatus for starting electronic device, and computer readable storage medium - Google Patents

Method and apparatus for starting electronic device, and computer readable storage medium Download PDF

Info

Publication number
WO2019042256A1
WO2019042256A1 PCT/CN2018/102528 CN2018102528W WO2019042256A1 WO 2019042256 A1 WO2019042256 A1 WO 2019042256A1 CN 2018102528 W CN2018102528 W CN 2018102528W WO 2019042256 A1 WO2019042256 A1 WO 2019042256A1
Authority
WO
WIPO (PCT)
Prior art keywords
snapshot
setting
electronic
valid
snapshots
Prior art date
Application number
PCT/CN2018/102528
Other languages
French (fr)
Chinese (zh)
Inventor
张学谦
Original Assignee
西安中兴新软件有限责任公司
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Priority to CN201710751262.5A priority Critical patent/CN109460258A/en
Priority to CN201710751262.5 priority
Application filed by 西安中兴新软件有限责任公司 filed Critical 西安中兴新软件有限责任公司
Publication of WO2019042256A1 publication Critical patent/WO2019042256A1/en

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/4401Bootstrapping
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/445Program loading or initiating

Abstract

A method and apparatus for starting an electronic device, and a computer readable storage medium, which relate to technologies for starting mobile broadband business (MBB) devices. The method for starting an electronic device comprises: determining that an MBB device is not started for a first time (100); and according to a recently-recorded user setting operation, selecting effective snapshots to perform starting (200), the effective snapshots comprising an effective running snapshot, an effective kernel snapshot and an effective boot program snapshot.

Description

Method, device and computer readable storage medium for starting electronic device Technical field

This application relates to, but is not limited to, mobile broadband (MBB) device startup technology.

Background technique

At present, many products, such as User Friendly Interface (UFI), Customer Premise Equipment (CPE) and other in-vehicle modules, are equipped with operating systems for implementing complex applications. Among them, simple operating systems such as There is no storage management for uclinux, complex operating systems such as android based on full Linux. With the support of powerful functions and the complexity of supporting services, the operating system has become larger and larger, and its startup has become slower and slower. For current UFI, CPE and other products, the average startup time may be as long as ten seconds, and for android phones, TVs and other products, the startup time will become longer with the use time.

In some cases, the quick start-up approach for various operating systems is primarily to improve startup time by optimizing boot order, tailoring unnecessary kernel components, optimizing code, or by adding hardware. For example, implementing a fast boot of an operating system in a Windows 8 or Windows 10 system essentially wakes up the computer from special hibernation, in which the computer consumes a small amount of power to store hibernation information in its memory.

However, in some cases, the quick start has the following problems:

1. Although the quick start is achieved by cutting the kernel and optimizing the startup process, unnecessary startup steps can be reduced to the utmost extent, but when the modules necessary for the device are encountered, there is no room for optimization and no optimization.

2. In some cases, the quick start still needs to maintain a certain power supply, and it is not suitable for the cold start scenario of the device.

Summary of the invention

The invention discloses a method for starting an electronic device, comprising: when the electronic device is not started for the first time, selecting a valid snapshot to start according to a last recorded setting operation, the valid snapshot includes: a valid running snapshot, effective Kernel snapshots and valid bootstrap snapshots.

Also disclosed herein is an apparatus for starting an electronic device, comprising: a storage unit, a recording setting operation; and a processing unit, when the electronic device is not first started, selecting a valid snapshot according to a setting operation of a last record in the storage unit To initiate, the valid snapshots include: a valid run snapshot, a valid kernel snapshot, and a valid bootstrap snapshot.

Also disclosed herein is a computer apparatus comprising a processor and a memory; the memory for storing computer instructions, the processor for operating the memory stored computer instructions to implement the electronic device startup method described above .

Also disclosed herein is a computer readable storage medium storing one or more programs, the one or more programs being executable by one or more processors to implement the above The method of starting the electronic device.

DRAWINGS

Figure 1 is a flow chart of system startup in some cases;

2 is a flowchart of a method for starting an electronic device according to an embodiment of the present application;

3 is a schematic diagram of a snapshot of each key point captured and stored before the electronic device is shipped from the factory according to an embodiment of the present application;

4 is a flowchart of a method of implementing a quick start of an electronic device in accordance with an embodiment of the present application;

FIG. 5 is a schematic diagram of a principle of local management and remote management of device snapshots according to an embodiment of the present application; FIG.

6 is a schematic diagram of data comparison using the startup method of the electronic device provided in the present application and, in some cases, the process startup;

FIG. 7 is a schematic structural diagram of an apparatus for starting an electronic device according to an embodiment of the present application.

Detailed ways

In order to make the objects, technical solutions and advantages of the present application more clear, the technical solutions of the present application will be further described in detail below with reference to specific embodiments. It should be noted that the features in the embodiments and the embodiments of the present application may be combined with each other arbitrarily without conflict.

Figure 1 is a flow chart of system startup in some cases.

As shown in FIG. 1 , the general process of starting the electronic device mainly includes: Step 101 to Step 104.

At step 101, after the device is powered on, the Central Processing Unit (CPU) chip automatically reads the first instruction from a specific address and executes the instruction. This is the automatic behavior of the hardware. In general, the CPU will read the first instruction from memory address 0, and the program file will be stored at memory address 0. In this way, the CPU chip starts executing code.

At step 102, the bootstrap is launched. Usually you need to start a bootloader before starting the operating system. The role of the bootloader is to find the location of the operating system file on the storage device and then copy the operating system files into memory. In general, operating system files are compressed and saved to flash memory in order to save space. After the boot program finds the kernel, it passes control parameters to the kernel to control how the operating system starts, such as setting the baud rate of the serial port, whether to allow debugging, and where to find the root file system.

At step 103, the operating system begins to take over, and the operating system will fully initialize various peripherals, such as a serial port, a network port, a WiFi chip, an LCD screen, and the like. After the hardware initialization is completed, the initialization of the software running environment is started, for example, setting a multi-process environment and preparing to start the user program. The user program is started by a special process Init of the operating system, so the startup of the Init process indicates that the initialization of the operating system is completed.

At step 104, the start of the user process begins. In this process, a lot of synchronization work is required to complete, and it takes a certain amount of time. For example, there are two process user identification (Subscriber Identification Module, sim) module processes and a dialing process. The dialing process needs to wait for the sim module process to correctly acquire the sim card state before using these state processes to operate on the network. In other words, these two processes have dependencies. In general, the higher the upper level of the process, the more processes need to wait. For example, in order to operate a device on a Web Site User Interface (webUI), all processes must be initialized before the webUI can be used normally.

The VMware virtual machine has a snapshot function. Based on this function, different levels of snapshots can be saved for different stages of device startup. That is, copy the memory status at a certain moment in the device startup phase to flash or In other storage media. Since the memory of the electronic device is generally small, the memory snapshot is relatively small even if it is not compressed, and the snapshot can be considered as not increasing the system load. This way, different levels of snapshots can be selected at system startup based on configuration (including default configuration and user configuration) and needs. For the normal operation of the user after the device is started, it is indicated that the operation result of different operation types will cause the snapshot to fail, and then the snapshot of the previous phase is selected to start, so as to minimize the startup time.

This embodiment provides a method for starting an electronic device. As shown in FIG. 2, the method includes step 100 and step 200.

At step 100, it is determined that the electronic device (taking the MBB device as an example) is not started for the first time.

At step 200, a valid snapshot is selected based on the most recently recorded user setup operation, the valid snapshot including a valid run snapshot, a valid kernel snapshot, and a valid bootstrap snapshot.

If it is determined that the MBB device is started for the first time by the user, it is started using the running snapshot of the factory default storage. Thereafter, when the MBB device receives the user-initiated setting operation, it also classifies the record setting operation. It should be noted that the factory default storage includes kernel snapshots and boot snapshots in addition to running snapshots.

After the steps 100 and 200 are started, when the MBB device receives the user-initiated setting operation, the setting operation is also classified and recorded for the selection of the snapshot that is valid at the next startup. The classification of the setup operations covered in this article includes at least one of the following: a setup operation that has no effect on any snapshots; a setup operation that only affects running snapshots; a setup operation that affects kernel snapshots; and a boot A program snapshot has an affected set operation.

The process of selecting a running snapshot stored in an MBB device as a valid snapshot is as follows.

When the last recorded setting operation is classified into a setting operation that has no effect on any snapshot, the running snapshot stored in the electronic device is selected as a valid snapshot to start.

When the last recorded user setting operation is a setting operation that only affects the running of the snapshot, the running snapshot stored in the MBB device is invalid. In this case, the stored upper level snapshot (ie, the kernel snapshot) is a valid snapshot and can be started according to the kernel snapshot. After startup, you also need to restore the user record operation of the last record, and then grab the memory snapshot during normal operation (that is, copy the RAM state at a certain moment in the normal operation of the device to the specified storage medium, as this A snapshot of the time of the memory) and update it to a running snapshot.

When the last recorded user setting operation is a setting operation that affects the kernel snapshot, the kernel snapshot is invalid, and the next level snapshot (that is, the running snapshot) is also invalid, and the upper level snapshot (ie, the boot program snapshot) is a valid snapshot. Therefore, you can start by following the bootloader snapshot. In addition, after the boot program is started and the user program is started, it is necessary to capture the memory snapshot at this time (that is, copy the RAM state at a certain time after the boot program of the device is started and before the user program is started to the specified storage medium, As a snapshot of the memory at this moment) and update it to a kernel snapshot, when the device is idle after the user program starts, the user record operation of the last record is restored, the memory snapshot at this time is captured and updated to run the snapshot.

When the last recorded user setting operation is a setting operation that affects the boot program snapshot, all snapshots are invalid and are started according to the normal process. Then, after the boot program of the MBB device is running normally and the operating system is not running, grab a snapshot of the memory at this time (that is, copy the RAM state at a certain time after the boot program of the device is running normally and the operating system is not running). Go to the specified storage medium, as a snapshot of the memory at this moment) and update it as a bootstrapping snapshot. After the bootloader starts and before the user program starts, grab the memory snapshot at this time and update it to the kernel snapshot. When the device is idle after the user program is started, the user record operation of the last record is restored, and the memory snapshot at this time is captured and updated to run the snapshot.

In addition to the above operations, the MBB device can also provide various snapshot management functions for the user, including uploading each snapshot stored locally by the MBB device to the remote end, and managing all snapshots stored locally or remotely stored by the MBB device. Specifically, the snapshot management operation may include, but is not limited to, the following operations: creating a new snapshot, deleting a snapshot, updating a snapshot, and selecting to initiate a snapshot.

When a user initiates a new snapshot operation, the newly created snapshot can include a run snapshot, a kernel snapshot, and a bootstrap snapshot.

The specific implementation of the above method will be described below with reference to the accompanying drawings.

First, the MBB device (and the operating system of the device is the Linux operating system) is taken as an example to describe the implementation process of various types of snapshots stored in the factory by default.

Before the MBB device leaves the factory, all required snapshots (including the factory default storage run snapshot used for the first boot, as well as the factory default stored kernel snapshot, bootloader snapshot, etc.) need to be pre-fetched at the factory. The process of obtaining these snapshots is shown in Figure 3. It includes the following operations: First, take a snapshot of the point at several key points of the startup process, for example, after the boot program runs normally and the operating system is not running. Memory snapshot bootloader snapshot at this point (the bootloader information is included in the bootloader snapshot); then, after the Linux operating system is started and the user program is started, the kernel snapshot is taken; then, before the user program starts, the device is cut off before the device is started. , grab the last run snapshot (running the snapshot includes information about the running state). These snapshots can all be saved in persistent storage such as flash memory.

Next, the startup process of the MBB device when the MBB device is booted by the user after shipment from the factory will be described.

When the user starts the MBB device for the first time, after starting up with the running snapshot of the factory default storage, the user can set and use each configuration parameter. These setting actions (for example, changing the password, modifying the wifi access password, modifying the APN, receiving the text message, etc.) are limited and the effect is fixed, so the system records each setting operation of the user and classifies the settings. For example, the A setting may modify the kernel, causing kernel snapshot invalidation to be unavailable; and the B setting may only modify a file configuration without affecting any snapshots at all. Therefore, the user settings can be mainly divided into the following four categories: the first category has no effect on any snapshot; the second category only affects the running snapshot; the third category has an impact on the kernel snapshot; and the fourth category, Has an impact on the bootstrap snapshot.

In general, most user operations have no effect on each snapshot, only a few operations affect the kernel (that is, affect kernel snapshots), and almost no operational pairs affect the bootloader. Each time the user's settings are logged, the new record will overwrite the old record. These records will be used as the basis for selecting snapshots at the next startup of the device.

In this way, for the non-first time user to start the MBB device, the appropriate snapshot can be selected according to the above user operation record. In general, bootstrapping snapshots and kernel snapshots of the operating system are not affected. In this case, you can use an existing kernel snapshot (that is, the kernel snapshot is a valid snapshot), and after the MBB device resumes booting, the device is The user resets all its preferences (that is, after the MBB device resumes booting, the snapshots can be used to restore the previous user settings in the order in which the users are set). When the device is idle, it also regenerates the normal working snapshot (that is, runs the snapshot) to overwrite the original snapshot. This process is shown in Figure 4.

In an embodiment, in order to facilitate the user to use this quick start function, the user can be allowed to create one or more snapshots of his own and select the snapshot to be started by default. In addition, the device manufacturer can also push the appropriate one or more snapshots for the user according to his own needs, so that the user can select.

Additionally, the above method can manage device snapshots locally or remotely. Remote management uploads a snapshot of the MBB device to the remote end according to user operations. Alternatively, the MBB device accepts a user-initiated snapshot management operation, and the snapshot management operation may include managing a snapshot stored locally by the MBB device and managing the remotely stored snapshot. You can also perform local coverage on the snapshot of the device, that is, the latest remote or local snapshot is overwritten by the snapshot stored locally on the MBB device according to user operations, as shown in Figure 5.

By adopting the above-described scheme for starting an electronic device based on the snapshot technology, the time spent mainly lies in two points: the size of the snapshot file and the reading speed of the snapshot file. Therefore, if the MBB device supports high-speed DMA, the recovery speed of the snapshot can be greatly accelerated, that is, the startup speed of the device is greatly accelerated.

FIG. 6 is a schematic diagram of data comparison using the startup method of the electronic device provided in the present application and, in some cases, the process startup.

It should be noted that the technical solution of the present application is applicable to the occasions of starting various MBB devices, and is particularly suitable for starting a device with sufficient flash capacity and a large operating system (such as an Android system).

The embodiment of the present application also provides an apparatus for quickly starting an electronic device, such as an MBB device. As shown in FIG. 7, the device mainly includes a storage unit and a processing unit.

The storage unit is configured to record a user setting operation.

In an embodiment, the storage unit is configured to: when the user-initiated setting operation is received after the MBB device is started, the classification setting operation may be used for the selection of the snapshot that is valid at the next startup.

The classification operations involved in this article include the following categories: setting operations that have no effect on any snapshots; setting operations that only affect running snapshots; setting operations that affect kernel snapshots; and impact on bootstrap snapshots Set the operation.

Specifically, when the storage unit records the user setting operation, the method of overwriting the record may be adopted, that is, the last record is replaced with the latest record.

The processing unit is configured to start by selecting a valid snapshot according to the last recorded user setting operation in the storage unit when the MBB device is not first started, the valid snapshot is a valid running snapshot, a valid kernel snapshot, and a valid boot program. Snapshot.

In addition, the processing unit is set to start using the factory default stored running snapshot when the MBB device is first booted. In one embodiment, the factory default store has a kernel snapshot and a bootstrap snapshot in addition to the run snapshot. For the process of storing various snapshots by default, the MBB device can be referred to the corresponding content in the foregoing method embodiments, and details are not described herein again.

The processing unit selects a valid snapshot to start according to the last recorded user setting operation as follows: when the last recorded user setting operation is classified into a setting operation that has no effect on any snapshot, the operation stored in the MBB device is selected. The snapshot is started as a valid snapshot; when the last recorded user setting operation is classified into a setting operation that only affects the running snapshot, the kernel snapshot stored in the MBB device is selected as a valid snapshot to be started, and after startup Restore the user record operation of the last record, and capture the memory snapshot at this time (ie, the device restores the user settings and copies the RAM state at a certain moment in normal operation to the specified storage medium as a memory snapshot at this moment). And update it to a running snapshot; when the last recorded user setting operation is classified into a setting operation that affects the kernel snapshot, select the bootstrap snapshot stored in the MBB device as a valid snapshot to start and start at the boot program. After the user program starts, grab the memory at this time. Photo (a copy of the RAM state at a certain point in time after the device's boot program is started and before the user program is started to the specified storage medium as a snapshot of the memory at that moment) and update it to a kernel snapshot, which is started in the user program When the device is idle, the user record operation of the last record is restored, the memory snapshot at this time is captured and updated to the running snapshot; when the user record operation of the last record is classified as a setting operation that affects the boot program snapshot, All snapshots are invalid, and are started according to the normal process. After the boot program of the MBB device runs normally and the operating system is not running, the memory snapshot at this time is captured (that is, after the boot program of the device is running normally and the operating system is not running) A momentary RAM state is copied to the specified storage medium, as a snapshot of the memory at this moment) is updated to a bootloader snapshot. After the bootloader is started and the user program is started, the memory snapshot at this time is captured and updated. For kernel snapshots, restore the most recently logged user when the device is idle after the user program is started Operation is set, at this time the memory snapshot fetch and snapshot update operation.

In addition to the above operations, the above device may also upload a snapshot, manage the snapshot locally or remotely, and locally overwrite the snapshot of the device. For example, the processing unit of the device may upload a snapshot of the MBB device to the remote end according to the user operation, and may also receive a snapshot management operation initiated by the user to manage the snapshot. The object of the snapshot management operation includes all snapshots stored locally by the MBB device. And all snapshots stored remotely. Snapshot management operations include at least creating new snapshots, deleting snapshots, updating snapshots, and selecting to initiate snapshots.

According to the above embodiment, the state of the virtual machine at any time can be saved as a snapshot (that is, the memory snapshot is captured by the VMware virtual machine snapshot function at a certain moment as a running snapshot or a kernel snapshot or a boot snapshot at the moment). In this way, the next time you start the virtual machine, you can start directly from the snapshot, and immediately restore to the last snapshot. For example, half of the game, half of the songs, half of the process, etc., can be returned perfectly. Moreover, recovery with snapshots is extremely fast, much faster than performing a virtual machine to perform operations.

The embodiment of the present application further provides a computer device, including a processor and a memory;

The memory is for storing computer instructions, and the processor is configured to execute the computer instructions stored in the memory to implement the method for starting the electronic device.

Since the method for starting the electronic device has been described in detail in the embodiment of the present application, the implementation process of the method is not repeatedly described herein.

The embodiment of the present application further provides a computer readable storage medium storing one or more programs, the one or more programs being executable by one or more processors to implement the above The method of starting the electronic device.

Since the method for starting the electronic device has been described in detail in the embodiment of the present application, the implementation process of the method is not repeatedly described herein.

One of ordinary skill in the art will appreciate that all or a portion of the steps described above can be accomplished by a program that instructs the associated hardware, such as a read-only memory, a magnetic or optical disk, and the like. All or part of the steps of the above embodiments may also be implemented using one or more integrated circuits. Correspondingly, each module/unit in the foregoing embodiment may be implemented in the form of hardware or in the form of a software function module. This application is not limited to any specific combination of hardware and software.

The above is only an exemplary embodiment of the present application, and is not intended to limit the scope of the present application. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present application are intended to be included within the scope of the present application.

Claims (12)

  1. A method for starting an electronic device includes the following steps:
    When the electronic device is not started for the first time, the valid snapshot is selected according to the last recorded setting operation, and the valid snapshot includes: a valid running snapshot, a valid kernel snapshot, and a valid boot program snapshot.
  2. The method of claim 1 further comprising the steps of:
    When the electronic device is first booted, it is started using a running snapshot of the factory default storage.
  3. The method of claim 1 or 2, further comprising the steps of:
    After the electronic device is started, when the setting operation is received, the setting operation is classified and recorded for the selection of the snapshot that is valid at the next startup, and the classification of the setting operation includes at least one of the following items:
    a setting operation that has no effect on any snapshots;
    Only set operations that have an impact on running snapshots;
    Set operations that affect kernel snapshots; and
    A set operation that affects the bootstrap snapshot.
  4. The method of claim 3, wherein
    When the last recorded setting operation is classified into a setting operation that has no effect on any snapshot, the running snapshot stored in the electronic device is selected as a valid snapshot to start;
    The last recorded setting operation is classified into the setting operation that only affects the running snapshot. The kernel snapshot stored in the electronic device is selected as a valid snapshot to start, and the setting operation of the last record is restored after the startup, and the operation is fetched. The memory snapshot at this time is updated to run the snapshot;
    When the last recorded setting operation is classified into a setting operation that affects the kernel snapshot, the boot program snapshot stored in the electronic device is selected as a valid snapshot to be started, and after the boot program is started and the user program is started, the crawl is performed. The memory snapshot at this time and update it to a kernel snapshot. When the device is idle after the user program starts, restore the last record setting operation, grab the memory snapshot at this time and update it to the running snapshot;
    When the last recorded setting operation is classified into a setting operation that affects the boot program snapshot, all the snapshots are invalid, and are started according to the normal process. After the boot program of the electronic device runs normally and the operating system is not running, the current time is grabbed. Snapshot of the memory and update it to a bootstrap snapshot. After the bootloader starts and before the user program starts, capture the memory snapshot at this time and update it to a kernel snapshot. When the device is idle after the user program starts, it will be restored to the last time. A recorded set operation that grabs a snapshot of the memory at this point and updates it to a run snapshot.
  5. The method of claim 4 further comprising the steps of:
    The electronic device accepts a snapshot management operation, and performs corresponding processing according to the snapshot management operation.
    The object of the snapshot management operation includes all snapshots stored locally by the electronic device and all snapshots stored by the remote end.
  6. A device for starting an electronic device, comprising:
    a storage unit configured to record a setting operation;
    a processing unit, configured to: when the electronic device is not first started, select a valid snapshot according to a last recorded setting operation in the storage unit, where the valid snapshot includes: a valid running snapshot, effective Kernel snapshots and valid bootstrap snapshots.
  7. The apparatus of claim 6 wherein
    The processing unit is further configured to initiate using the factory default stored running snapshot when the electronic device is first booted.
  8. The apparatus according to claim 6 or 7, wherein
    The storage unit is further configured to: when the setting operation is received after the electronic device is started, classify and record the setting operation for selection of a snapshot that is valid at the next startup, and the classification of the setting operation includes the following items At least one of:
    a setting operation that has no effect on any snapshots;
    Only set operations that have an impact on running snapshots;
    Set operations that affect kernel snapshots; and
    A set operation that affects the bootstrap snapshot.
  9. The apparatus of claim 8, wherein the processing unit is further configured to initiate a selection of a valid snapshot based on a last recorded setting operation by:
    When the last recorded setting operation is classified into a setting operation that has no effect on any snapshot, the running snapshot stored in the electronic device is selected as a valid snapshot to start;
    The last recorded setting operation is classified into the setting operation that only affects the running snapshot. The kernel snapshot stored in the electronic device is selected as a valid snapshot to start, and the setting operation of the last record is restored after the startup, and the operation is fetched. The memory snapshot at this time is updated to run the snapshot;
    When the last recorded setting operation is classified into a setting operation that affects the kernel snapshot, the boot program snapshot stored in the electronic device is selected as a valid snapshot to be started, and after the boot program is started and the user program is started, the crawl is performed. The memory snapshot at this time and update it to a kernel snapshot. When the device is idle after the user program starts, restore the last record setting operation, grab the memory snapshot at this time and update it to the running snapshot;
    When the last recorded setting operation is classified into a setting operation that affects the boot program snapshot, all the snapshots are invalid, and are started according to the normal process. After the boot program of the electronic device runs normally and the operating system is not running, the current time is grabbed. Snapshot of the memory and update it to a bootstrap snapshot. After the bootloader starts and before the user program starts, capture the memory snapshot at this time and update it to a kernel snapshot. When the device is idle after the user program starts, it will be restored to the last time. A recorded set operation that grabs a snapshot of the memory at this point and updates it to a run snapshot.
  10. The device according to claim 9, wherein
    The processing unit is further configured to accept a snapshot management operation, and perform corresponding processing according to the snapshot management operation;
    The objects of the snapshot management operation include all snapshots stored locally by the electronic device, and all snapshots stored remotely.
  11. A computer device comprising a processor and a memory;
    The memory is for storing computer instructions for executing the computer instructions stored in the memory to implement the method of booting an electronic device according to any one of claims 1 to 5.
  12. A computer readable storage medium storing one or more programs, the one or more programs being executable by one or more processors to implement any one of claims 1 to 5. The method of starting the electronic device described in the item.
PCT/CN2018/102528 2017-08-28 2018-08-27 Method and apparatus for starting electronic device, and computer readable storage medium WO2019042256A1 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN201710751262.5A CN109460258A (en) 2017-08-28 2017-08-28 A kind of method and device starting electronic equipment
CN201710751262.5 2017-08-28

Publications (1)

Publication Number Publication Date
WO2019042256A1 true WO2019042256A1 (en) 2019-03-07

Family

ID=65526228

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2018/102528 WO2019042256A1 (en) 2017-08-28 2018-08-27 Method and apparatus for starting electronic device, and computer readable storage medium

Country Status (2)

Country Link
CN (1) CN109460258A (en)
WO (1) WO2019042256A1 (en)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101916201A (en) * 2010-08-06 2010-12-15 中兴通讯股份有限公司 Android-based mobile terminal cold-boot method and device
CN102207881A (en) * 2011-07-07 2011-10-05 电子科技大学 Quick operation system start-up method based on Android
CN103309740A (en) * 2013-06-05 2013-09-18 腾讯科技(深圳)有限公司 Program starting method, device and equipment
CN105260271A (en) * 2015-11-18 2016-01-20 浪潮(北京)电子信息产业有限公司 HDFS snapshot implementation method and system
CN106095439A (en) * 2016-06-12 2016-11-09 联想(北京)有限公司 A kind of information processing method and electronic equipment

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101916201A (en) * 2010-08-06 2010-12-15 中兴通讯股份有限公司 Android-based mobile terminal cold-boot method and device
CN102207881A (en) * 2011-07-07 2011-10-05 电子科技大学 Quick operation system start-up method based on Android
CN103309740A (en) * 2013-06-05 2013-09-18 腾讯科技(深圳)有限公司 Program starting method, device and equipment
CN105260271A (en) * 2015-11-18 2016-01-20 浪潮(北京)电子信息产业有限公司 HDFS snapshot implementation method and system
CN106095439A (en) * 2016-06-12 2016-11-09 联想(北京)有限公司 A kind of information processing method and electronic equipment

Also Published As

Publication number Publication date
CN109460258A (en) 2019-03-12

Similar Documents

Publication Publication Date Title
US20190171430A1 (en) Preinstalled Application Management Method for Mobile Terminal and Mobile Terminal
US20190332489A1 (en) Selective Processing of File System Objects for Image Level Backups
US20200233729A1 (en) Managing applications for power conservation
US10114630B2 (en) Management of software and operating system updates required for the process of creating a virtual machine facsimile of an existing physical or virtual machine
US20190265961A1 (en) Software installation onto a client using existing resources
US8719497B1 (en) Using device spoofing to improve recovery time in a continuous data protection environment
US10242023B2 (en) Programming model for synchronizing browser caches across devices and web services
US10684744B2 (en) Launching applications on an electronic device
US9146839B2 (en) Method for pre-testing software compatibility and system thereof
US9317299B2 (en) Method and device for cold starting android mobile terminal
JP4740238B2 (en) Method, software, and device for using application state history information when restarting an application
US7698698B2 (en) Method for over-the-air firmware update of NAND flash memory based mobile devices
JP4066325B2 (en) User data backup method
CN102567042B (en) Method and system for managing multiple software images with relocation of boot blocks
CN100385386C (en) Display picture during period of leading and turn-off computer
EP2840495B1 (en) Container-based processing method and apparatus
US8533304B2 (en) Remotely deploying and automatically customizing workstation images
JP5681465B2 (en) Information processing system, information processing apparatus, preparation method, program, and recording medium
US5269022A (en) Method and apparatus for booting a computer system by restoring the main memory from a backup memory
JP5911504B2 (en) Software image upgrade based on streaming technology
AU2014374256B2 (en) Systems and methods for improving snapshot performance
AU685476B2 (en) File name detecting methd for use with operating system
CN102207881B (en) Quick operation system start-up method based on Android
US9081639B2 (en) System and method for remotely re-imaging a computer system
US8930769B2 (en) Managing operating system deployment failure

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18852015

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase in:

Ref country code: DE