CN112073446B

CN112073446B - Dual-system OTA parallel upgrading method and system

Info

Publication number: CN112073446B
Application number: CN201910498722.7A
Authority: CN
Inventors: 周晓磊; 董娜; 王之奎; 李春超
Original assignee: Hisense Visual Technology Co Ltd
Current assignee: Hisense Visual Technology Co Ltd
Priority date: 2019-06-10
Filing date: 2019-06-10
Publication date: 2022-09-30
Anticipated expiration: 2039-06-10
Also published as: CN112073446A

Abstract

The application discloses a method and a system for parallel upgrading of a dual-system OTA, which comprise the following steps: after the first hardware system and the second hardware system simultaneously enter a Recovery mode, the first hardware system and the second hardware system synchronously enter a verification mode, namely the first hardware system verifies the first OTA upgrade packet and the second hardware system verifies the second OTA upgrade packet. After the verification is completed, the second hardware system generates an installation instruction and sends the installation instruction to the first hardware system, so that the first hardware system and the second hardware system synchronously enter an installation mode, and the second hardware system also installs the second OTA upgrade package while the first hardware system installs the first OTA upgrade package. And when the installation is finished, the first hardware system and the second hardware system are synchronously restarted. Therefore, the method and the system provided by the implementation can realize the OTA parallel upgrade of the dual systems, and the dual systems can simultaneously enter the verification mode, synchronously enter the installation mode and restart simultaneously, so that the upgrade efficiency of the dual systems is improved, the upgrade time is not prolonged, and the user experience is improved.

Description

Dual-system OTA parallel upgrading method and system

Technical Field

The present application relates to the field of communications technologies, and in particular, to a method and a system for parallel upgrading of a dual-system OTA.

Background

With the continuous development of communication technology, terminal devices such as computers, smart phones and social televisions have become more and more popular. The system built in the terminal device is usually an open source system, and due to the continuous change of the use requirement, the system built in the same terminal device often needs to be continuously upgraded.

There are many forms of system upgrades, typically Over-the-Air Technology (OTA) upgrades. For the terminal device, an Android system, an IOS system or other operating systems are generally installed. The Android system has a Recovery upgrading function, and the Android system OTA can upgrade system data in a Recovery mode.

With the increasing demand of the user on the application experience, the requirements on various performance indexes of the operating system are increased, and it becomes possible to set a dual system or multiple systems on the terminal device. When upgrading is performed in an OTA manner under a dual-system architecture, the conventional method generally employs a serial upgrading manner, that is, first, one system is upgraded, and then, after the system finishes the upgrading operation, the other system is upgraded.

However, when the serial mode is adopted for upgrading, the upgrading time of the double-system upgrading is double that of the single system, and the upgrading efficiency is low. And if one system is upgraded successfully and the other system is upgraded unsuccessfully, versions of the two systems are inconsistent, and normal operation of the display device is affected.

Disclosure of Invention

The application provides a dual-system OTA parallel upgrading method and system, which aim to solve the problem of low upgrading efficiency when a serial mode is adopted to upgrade dual systems.

In a first aspect, the application provides a dual-system OTA parallel upgrading method, which includes the following steps:

under the condition that the first hardware system and the second hardware system simultaneously enter a Recovery mode, the first hardware system verifies the first OTA upgrade package, and the second hardware system verifies the second OTA upgrade package; the first OTA upgrade package is used for upgrading a first hardware system, and the second OTA upgrade package is used for upgrading a second hardware system;

under the condition that the first hardware system and the second hardware system are verified successfully respectively, the second hardware system generates an installation instruction and sends the installation instruction to the first hardware system;

according to the installation instruction, the first hardware system starts to be installed according to the first OTA upgrade package, and the second hardware system starts to be installed according to the second OTA upgrade package;

under the condition that the first hardware system and the second hardware system are installed successfully respectively, the second hardware system generates a restart instruction and sends the restart instruction to the first hardware system;

and according to the restart instruction, the first hardware system and the second hardware system carry out restart operation.

Optionally, the method further comprises:

according to the upgrading instruction, the first hardware system and the second hardware system write upgrading marks respectively;

restarting the first hardware system and the second hardware system according to the upgrading mark, wherein the first hardware system and the second hardware system respectively enter a Recovery mode;

after the second hardware system enters a Recovery mode, sending a query instruction to the first hardware system; the query instruction is used for querying whether the first hardware system successfully enters a Recovery mode;

and if the second hardware system receives a successful entering result returned by the first hardware system according to the query instruction, the first hardware system verifies the first OTA upgrading packet, and the second hardware system verifies the second OTA upgrading packet.

Optionally, the method further comprises:

if the second hardware system receives an unsuccessful entry result returned by the first hardware system according to the query instruction, querying whether the first hardware system has the OTA upgrade package of the current version;

if the instruction does not exist, the second hardware system generates an exit instruction and sends the exit instruction to the first hardware system, so that the first hardware system and the second hardware system exit a Recovery mode;

if yes, sending a BCB information writing instruction to the first hardware system;

Receiving a BCB information writing success result returned by the first hardware system according to the BCB information writing instruction, and sending a restarting instruction to the first hardware system so that the first hardware system is restarted after the BCB information is written in;

after the first hardware system is restarted, the second hardware system generates a new query instruction, sends the new query instruction to the first hardware system, and queries whether the first hardware system successfully enters a Recovery mode;

and if the second hardware system receives a successful entering result returned by the first hardware system according to the new query instruction, the first hardware system verifies the first OTA upgrading packet, and the second hardware system verifies the second OTA upgrading packet.

Optionally, the generating, by the second hardware system, an installation instruction to send to the first hardware system when the first hardware system and the second hardware system are verified successfully respectively includes:

judging whether the first hardware system verifies the first OTA upgrade package, and whether the second hardware system verifies the second OTA upgrade package;

if the second hardware system successfully verifies the second OTA upgrade package and the first hardware system completes the verification of the first OTA upgrade package, the second hardware system and the first hardware system respectively enter a synchronization mode;

In the synchronous mode, the second hardware system generates a checking result query instruction and sends the checking result query instruction to the first hardware system;

and if the second hardware system receives a verification success result returned by the first hardware system according to the verification result query instruction, the second hardware system generates an installation instruction and sends the installation instruction to the first hardware system.

Optionally, the method further comprises:

if the second hardware system fails to verify the second OTA upgrade package, generating a verification state query instruction and sending the verification state query instruction to the first hardware system;

and when the second hardware system receives a result in the check state returned by the first hardware system according to the check state query instruction, generating an exit instruction, and sending the exit instruction to the first hardware system to enable the first hardware system to enter an exit mode.

Optionally, the generating, by the second hardware system, a restart instruction and sending the restart instruction to the first hardware system when the first hardware system and the second hardware system are successfully installed respectively includes:

judging whether the installation process of installing the second OTA upgrade package by the second hardware system is successful or not, and whether the installation process of installing the first OTA upgrade package by the first hardware system is completed or not;

If the second hardware system successfully installs the second OTA upgrade package and the first hardware system completes the installation of the first OTA upgrade package, the second hardware system and the first hardware system respectively enter a synchronization mode;

in the synchronous mode, the second hardware system generates an installation result query instruction and sends the installation result query instruction to the first hardware system;

if the second hardware system receives an installation success result returned by the first hardware system according to the installation result query instruction, an exit instruction is generated and sent to the first hardware system;

and according to the exit instruction, after the first hardware system and the second hardware system enter an exit mode, the second hardware system generates a restart instruction and sends the restart instruction to the first hardware system.

Optionally, the method further comprises:

if the second hardware system fails to install the second OTA upgrade package, generating an installation state query instruction, and sending the installation state query instruction to the first hardware system;

when the second hardware system receives a result which is returned by the first hardware system according to the installation state query instruction and is in the installation state, a waiting instruction is generated to wait for the first hardware system to be installed;

And if the first hardware system finishes the installation of the first OTA upgrade package within the waiting time threshold according to the waiting instruction, the second hardware system generates an exit instruction and sends the exit instruction to the first hardware system, so that the first hardware system enters an exit mode.

Optionally, the method further comprises:

and in the process of installing the second OTA upgrade package by the second hardware system, the installation progress of the first hardware system and the installation progress of the second hardware system are displayed on the same progress bar, and the progress bar is displayed by the second hardware system.

Optionally, the display mode of the progress bar includes:

if the target progress value required to be displayed by the progress bar is an odd number, checking the installation progress of the first hardware system by the progress bar;

when the installation progress of the first hardware system reaches a target progress value, displaying the target progress value on the progress bar;

if the target progress value required to be displayed by the progress bar is an even number, checking the installation progress of a second hardware system by the progress bar;

and when the installation progress of the second hardware system reaches a target progress value, displaying the target progress value on the progress bar.

Optionally, the method further comprises:

if the installation progress of the first hardware system does not reach the target progress value, waiting for a period of time, and then checking the installation progress of the first hardware system;

and within the waiting time threshold, if the progress bar does not acquire the installation progress of the first hardware system, judging that the first hardware system is abnormally installed.

In a second aspect, the present application further provides a dual-system OTA parallel upgrade system, including: the system comprises a first hardware system and a second hardware system, wherein the second hardware system is connected with the first hardware system through a serial port or a network cable; the first and second hardware systems are respectively configured to perform the steps of:

According to the installation instruction, the first hardware system starts to be installed according to a first OTA upgrade package, and the second hardware system starts to be installed according to a second OTA upgrade package;

Optionally, the first hardware system and the second hardware system are further configured to perform the following steps, respectively:

if the second hardware system receives an unsuccessful entry result returned by the first hardware system according to the query instruction, querying whether the first hardware system has an OTA upgrade patch of the current version;

after the first hardware system is restarted, the second hardware system generates a new query instruction, sends the new query instruction to the first hardware system and queries whether the first hardware system successfully enters a Recovery mode;

judging whether the installation process of installing the second OTA upgrade patch by the second hardware system is successful or not, and judging whether the installation process of installing the first OTA upgrade patch by the first hardware system is completed or not;

Compared with the prior art, the technical solutions proposed in the exemplary embodiments of the present application have the following beneficial effects: after the first hardware system and the second hardware system simultaneously enter the Recovery mode, synchronously enter the verification mode, namely the first hardware system verifies the first OTA upgrade package and the second hardware system verifies the second OTA upgrade package. After the verification is completed, the second hardware system generates an installation instruction and sends the installation instruction to the first hardware system, so that the first hardware system and the second hardware system synchronously enter an installation mode, and the second hardware system also installs the second OTA upgrade package while the first hardware system installs the first OTA upgrade package. And when the installation is finished, the first hardware system and the second hardware system are synchronously restarted. Therefore, the method and the system provided by the implementation can realize the OTA parallel upgrade of the dual systems, and the dual systems can simultaneously enter the verification mode, synchronously enter the installation mode and restart simultaneously, so that the upgrade efficiency of the dual systems is improved, the upgrade time is not prolonged, and the user experience is improved.

Drawings

In order to more clearly describe the technical solution of the present application, the drawings required to be used in the embodiments will be briefly described below, and it is obvious for those skilled in the art to obtain other drawings without inventive labor.

Fig. 1 is a schematic diagram illustrating an operation scenario between a display device and a control apparatus according to an embodiment;

fig. 2 is a block diagram exemplarily showing a hardware configuration of a control apparatus according to the embodiment;

fig. 3 is a block diagram exemplarily showing a hardware configuration of a hardware system in the display device according to the embodiment;

fig. 4 is a block diagram illustrating a hardware architecture of the display device according to fig. 3;

fig. 5 is a diagram exemplarily showing a functional configuration of a display device according to the embodiment;

fig. 6a schematically shows a configuration of a software system in a display device according to an embodiment;

fig. 6b schematically shows a configuration of an application in a display device according to an embodiment;

FIG. 7 is a diagram illustrating a user interface in a display device according to an embodiment;

fig. 8 is a diagram illustrating a communication manner of a dual system according to an embodiment;

FIG. 9 is a flow diagram illustrating a simultaneous upgrade between system N and system A according to an embodiment;

fig. 10 illustrates a flow diagram of a dual system OTA parallel upgrade method according to an embodiment;

fig. 11 illustrates an overall data flow diagram of a dual system OTA parallel upgrade method according to an embodiment;

FIG. 12 is a flow diagram illustrating a dual system OTA parallel upgrade method according to another embodiment;

FIG. 13 is a data flow diagram that illustrates exception handling logic in accordance with the check phase in an embodiment;

FIG. 14 is a flow diagram illustrating a dual system OTA parallel upgrade method according to yet another embodiment;

FIG. 15 is a flow diagram that illustrates a method for a dual system to enter an upgrade phase in parallel, according to an embodiment;

FIG. 16 is a flow diagram illustrating a method for a dual system to enter a restart phase in parallel, according to an embodiment;

FIG. 17 is a flow diagram illustrating a method of failure handling logic for an installation phase in accordance with an embodiment;

FIG. 18 is a data flow diagram that illustrates a progress bar display in accordance with an embodiment;

FIG. 19 is a flow chart illustrating a method of progress bar display according to an embodiment;

fig. 20 is a block diagram illustrating an architecture of a dual-system OTA parallel upgrade system according to an embodiment;

FIG. 21 is a flow diagram illustrating a factory reset trigger in accordance with an embodiment;

fig. 22 is a block diagram illustrating a configuration of a system for restoring factory settings in parallel by two systems according to an embodiment;

fig. 23 is a flowchart illustrating a method for factory settings restoration in parallel by two systems according to an embodiment;

FIG. 24 is a timing flow diagram that illustrates a method for dual system parallel factory reset in accordance with an embodiment;

FIG. 25 is a flow chart illustrating a method for dual system concurrent factory reset according to another embodiment;

FIG. 26 is a flow diagram that illustrates a method for handling a dual system parallel factory reset exception, according to an embodiment;

FIG. 27 is a flow diagram that illustrates a method for handling a dual system parallel factory reset exception, according to another embodiment;

FIG. 28 is a flow diagram illustrating a method for handling a dual system parallel factory reset exception according to yet another embodiment;

fig. 29 is a block diagram illustrating a configuration of a processing apparatus for concurrently restoring factory setting exceptions for two systems according to an embodiment;

FIG. 30 is a diagram illustrating communication interactions between dual systems according to an embodiment;

FIG. 31 is a flow diagram illustrating a method for dual system synchronization to enter recovery mode in accordance with an embodiment;

FIG. 32 is a data flow diagram illustrating a method of dual system synchronization entering recovery mode in accordance with an embodiment;

FIG. 33 is a flow diagram illustrating a method according to one implementation of dual system synchronization into recovery mode, in accordance with an embodiment;

FIG. 34 illustrates a flow diagram of a method according to another implementation of the dual system synchronization into recovery mode in an embodiment;

fig. 35 is a block diagram illustrating an apparatus for entering a recovery mode in synchronization with a dual system according to an embodiment.

Detailed Description

To make the objects, technical solutions and advantages of the exemplary embodiments of the present application clearer, the technical solutions in the exemplary embodiments of the present application will be clearly and completely described below with reference to the drawings in the exemplary embodiments of the present application, and it is obvious that the described exemplary embodiments are only a part of the embodiments of the present application, but not all the embodiments.

For the convenience of users, various external device interfaces are usually provided on the display device to facilitate connection of different peripheral devices or cables to implement corresponding functions. When a high-definition camera is connected to an interface of the display device, if a hardware system of the display device does not have a hardware interface of a high-pixel camera receiving the source code, data received by the camera cannot be displayed on a display screen of the display device.

Furthermore, due to the hardware structure, the hardware system of the conventional display device only supports one path of hard decoding resources, and usually only supports video decoding with a resolution of 4K at most, so when a user wants to perform video chat while watching a network television, the user needs to use the hard decoding resources (usually GPU in the hardware system) to decode the network video without reducing the definition of the network video screen, and in this case, the user can only process the video chat screen by using a general-purpose processor (e.g. CPU) in the hardware system to perform soft decoding on the video.

The soft decoding is adopted to process the video chat picture, so that the data processing burden of a CPU (central processing unit) can be greatly increased, and when the data processing burden of the CPU is too heavy, the picture is blocked or unsmooth. Further, due to the data processing capability of the CPU, when the CPU performs soft decoding on the video chat screen, multi-channel video calls cannot be generally implemented, and when a user wants to perform video chat with multiple other users in the same chat scene, access is blocked.

In view of the above aspects, to overcome the above drawbacks, the present application discloses a dual hardware system architecture to implement multiple channels of video chat data (at least one channel of local video).

The concept to which the present application relates will be first explained below with reference to the drawings. It should be noted that the following descriptions of the concepts are only for the purpose of facilitating understanding of the contents of the present application, and do not represent limitations on the scope of the present application.

The term "module," as used in various embodiments of the present application, may refer to any known or later developed hardware, software, firmware, artificial intelligence, fuzzy logic, or combination of hardware and/or software code that is capable of performing the functionality associated with that element.

The term "remote control" as used in the embodiments of the present application refers to a component of an electronic device (such as the display device disclosed in the present application) that is capable of wirelessly controlling the electronic device, typically over a short distance. The component may typically be connected to the electronic device using infrared and/or Radio Frequency (RF) signals and/or bluetooth, and may also include functional modules such as WiFi, wireless USB, bluetooth, motion sensors, etc. For example: the hand-held touch remote controller replaces most of the physical built-in hard keys in the common remote control device with the user interface in the touch screen.

The term "gesture" as used in the embodiments of the present application refers to a user behavior used to express an intended idea, action, purpose, or result through a change in hand shape or an action such as hand movement.

The term "hardware system" used in the embodiments of the present application may refer to a physical component having computing, controlling, storing, inputting and outputting functions, which is formed by a mechanical, optical, electrical and magnetic device such as an Integrated Circuit (IC), a Printed Circuit Board (PCB) and the like. In various embodiments of the present application, a hardware system may also be referred to as a motherboard (or chip).

Fig. 1 is a schematic diagram illustrating an operation scenario between a display device and a control apparatus according to an embodiment. As shown in fig. 1, a user may operate the display apparatus 200 through the control device 100.

The control device 100 may be a remote controller 100A, which can communicate with the display device 200 through an infrared protocol communication, a bluetooth protocol communication, a ZigBee (ZigBee) protocol communication, or other short-range communication, and is used to control the display device 200 in a wireless or other wired manner. The user may input a user instruction through a key on a remote controller, voice input, control panel input, etc., to control the display apparatus 200. Such as: the user can input a corresponding control command through a volume up/down key, a channel control key, up/down/left/right moving keys, a voice input key, a menu key, a power on/off key, etc. on the remote controller, to implement the function of controlling the display device 200.

The control apparatus 100 may also be a smart device, such as a mobile terminal 100B, a tablet computer, a notebook computer, etc., which may communicate with the display device 200 through a Local Area Network (LAN), a Wide Area Network (WAN), a Wireless Local Area Network (WLAN), or other networks, and implement control of the display device 200 through an application program corresponding to the display device 200.

For example, the mobile terminal 100B and the display device 200 may each have a software application installed thereon, so that connection communication between the two can be realized through a network communication protocol, and the purpose of one-to-one control operation and data communication can be further realized. Such as: a control instruction protocol can be established between the mobile terminal 100B and the display device 200, a remote control keyboard is synchronized to the mobile terminal 100B, and the function of controlling the display device 200 is realized by controlling a user interface on the mobile terminal 100B; the audio and video content displayed on the mobile terminal 100B may also be transmitted to the display device 200, so as to implement a synchronous display function.

As shown in fig. 1, the display apparatus 200 may also perform data communication with the server 300 through various communication means. In various embodiments of the present application, the display device 200 may be allowed to be communicatively coupled to the server 300 via a local area network, a wireless local area network, or other network. The server 300 may provide various contents and interactions to the display apparatus 200.

Illustratively, the display device 200 receives software Program updates, or accesses a remotely stored digital media library, by sending and receiving information, and Electronic Program Guide (EPG) interactions. The servers 300 may be a group or groups, and may be one or more types of servers. Other web service contents such as a video on demand and an advertisement service are provided through the server 300.

The display device 200 may be a liquid crystal display, an oled (organic Light Emitting diode) display, a projection display device, or an intelligent television. The particular display device type, size, resolution, etc. are not limiting, and those skilled in the art will appreciate that the display device 200 may be modified in performance and configuration as desired.

The display apparatus 200 may additionally provide an intelligent network tv function that provides a computer support function in addition to the broadcast receiving tv function. Examples include a web tv, a smart tv, an Internet Protocol Tv (IPTV), and the like.

As shown in fig. 1, a camera may be connected or disposed on the display device, and is used to present a picture taken by the camera on a display interface of the display device or other display devices, so as to implement interactive chat between users. Specifically, the picture shot by the camera can be displayed on the display device in a full screen mode, a half screen mode or any optional area.

As an optional connection mode, the camera is connected with the display rear shell through the connecting plate, is fixedly installed in the middle of the upper side of the display rear shell, and can be fixedly installed at any position of the display rear shell as an installable mode, so that an image acquisition area is ensured not to be shielded by the rear shell, for example, the display orientation of the image acquisition area is the same as that of the display equipment.

As another alternative connection mode, the camera is connected to the display rear shell through a connection board or other conceivable connector, the camera is capable of lifting, the connector is provided with a lifting motor, when a user wants to use the camera or an application program wants to use the camera, the camera is lifted out of the display, and when the camera is not needed, the camera can be embedded in the rear shell to protect the camera from being damaged.

As an embodiment, the camera adopted in the present application may have 1600 ten thousand pixels, so as to achieve the purpose of ultra high definition display. In actual use, cameras higher or lower than 1600 ten thousand pixels may also be used.

After the camera is installed on the display device, the contents displayed by different application scenes of the display device can be fused in various different modes, so that the function which cannot be realized by the traditional display device is achieved.

Illustratively, a user may conduct a video chat with at least one other user while watching a video program. The presentation of the video program may be as a background frame over which a window for video chat is displayed. The function is called 'chat while watching'.

Optionally, in a scene of "chat while watching", while watching a live video or a network video, performing at least one path of video chat across terminals.

In another example, a user may conduct a video chat with at least one other user while entering learning from an educational application. For example, a student may be able to remotely interact with a teacher while learning content in an educational application. Vividly, the function can be called as 'chatting while learning'.

In another example, a user conducts a video chat with a player entering a card game while playing the game. For example, a player may enable remote interaction with other players when entering a gaming application to participate in a game. Figuratively, this function may be referred to as "watch while playing".

Optionally, the game scene is fused with the video picture, the portrait in the video picture is scratched and displayed in the game picture, and the user experience is improved.

Optionally, in the motion sensing game (such as ball hitting, boxing, running and dancing), the posture and the motion of the human body, the limb detection and tracking and the detection of the key point data of the human skeleton are obtained through the camera, and then the detection is fused with the animation in the game, so that the game of the scenes such as sports and dancing is realized.

In another example, a user may interact with at least one other user in a karaoke application in video and voice. Vividly, this function can be called "sing while watching". Preferably, when at least one user enters the application in a chat scenario, multiple users can jointly complete recording of a song.

In another example, a user may turn on a camera locally to take pictures and videos, figurative, which may be referred to as "looking into the mirror".

In other examples, more or less functionality may be added. The function of the display device is not particularly limited in the present application.

Fig. 2 is a block diagram schematically showing a hardware configuration of the control apparatus 100 according to the embodiment. As shown in fig. 2, the control device 100 includes a controller 110, a communicator 130, a user input/output interface 140, a memory 190, and a power supply 180.

The control apparatus 100 is configured to control the display device 200, and to receive an input operation command from a user, and to convert the operation command into a command recognizable and responsive to the display device 200, thereby mediating interaction between the user and the display device 200. Such as: the user operates the channel up/down key on the control device 100, and the display device 200 responds to the channel up/down operation.

In some embodiments, the control device 100 may be a smart device. Such as: the control apparatus 100 may install various applications for controlling the display device 200 according to user's demands.

In some embodiments, as shown in fig. 1, the mobile terminal 100B or other intelligent electronic device may function similar to the control apparatus 100 after installing an application for manipulating the display device 200. Such as: a user may implement the functions of controlling the physical keys of apparatus 100 by installing applications, various function keys or virtual buttons of a graphical user interface that may be provided on mobile terminal 100B or other intelligent electronic device.

The controller 110 includes a processor 112, a RAM113 and a ROM114, a communication interface, and a communication bus. The controller 110 is used to control the operation of the control device 100, as well as the internal components and communications between them, as well as external and internal data processing functions.

The communicator 130 enables communication of control signals and data signals with the display apparatus 200 under the control of the controller 110. Such as: the received user input signal is transmitted to the display apparatus 200. The communicator 130 may include at least one of a WIFI module 131, a bluetooth module 132, an NFC module 133, and the like.

A user input/output interface 140, wherein the input interface includes at least one of a microphone 141, a touch pad 142, a sensor 143, a key 144, and the like. Such as: the user can realize a user instruction input function through actions such as voice, touch, gesture, pressing, and the like, and the input interface converts the received analog signal into a digital signal and converts the digital signal into a corresponding instruction signal, and sends the instruction signal to the display device 200.

The output interface includes an interface that transmits the received user instruction to the display apparatus 200. In some embodiments, the interface may be an infrared interface or a radio frequency interface. Such as: when the infrared signal interface is used, the user input instruction needs to be converted into an infrared control signal according to an infrared control protocol, and the infrared control signal is sent to the display device 200 through the infrared sending module. The following steps are repeated: when the rf signal interface is used, a user input command needs to be converted into a digital signal, and then the digital signal is modulated according to the rf control signal modulation protocol and then transmitted to the display device 200 through the rf transmitting terminal.

In some embodiments, the control device 100 includes at least one of a communicator 130 and an output interface. The communicator 130 is configured in the control device 100, such as: the modules of WIFI, bluetooth, NFC, etc. may send the user input command to the display device 200 through the WIFI protocol, or the bluetooth protocol, or the NFC protocol code.

And a memory 190 for storing various operation programs, data and applications for driving and controlling the control apparatus 100 under the control of the controller 110. The memory 190 may store various control signal commands input by a user.

And a power supply 180 for providing operational power support to the components of the control device 100 under the control of the controller 110. A battery and associated control circuitry.

A hardware configuration block diagram of a hardware system in the display device 200 according to the embodiment is exemplarily shown in fig. 3.

When a dual hardware system architecture is adopted, the structural relationship of the hardware system can be shown in fig. 3. For convenience of description, one hardware system in the dual hardware system architecture is referred to as a first hardware system or a system, a chip, and the other hardware system is referred to as a second hardware system or N system, N chip. The chip A comprises a controller of the chip A and various modules connected with the controller of the chip A through various interfaces, and the chip N comprises a controller of the chip N and various modules connected with the controller of the chip N through various interfaces. The a-chip and the N-chip may each have a separate operating system installed therein, so that there are two separate but interrelated subsystems in the display apparatus 200.

As shown in fig. 3, the a chip and the N chip may be connected, communicated and powered through a plurality of different types of interfaces. The interface type of the interface between the a chip and the N chip may include a General-purpose input/output (GPIO) interface, a USB interface, an HDMI interface, a UART interface, and the like. One or more of these interfaces may be used for communication or power transfer between the a-chip and the N-chip. For example, as shown in fig. 3, in the dual hardware system architecture, the N chip may be powered by an external power source (power), and the a chip may not be powered by the external power source but by the N chip.

In addition to the interface for connecting with the N chip, the a chip may further include an interface for connecting other devices or components, such as an MIPI interface for connecting a Camera (Camera) shown in fig. 3, a bluetooth interface, and the like.

Similarly, in addition to the interface for connecting with the N chip, the N chip may further include an VBY interface for connecting with a display screen tcon (timer Control register), and an i2S interface for connecting with a power Amplifier (AMP) and a Speaker (Speaker); and an IR/Key interface, a USB interface, a Wifi interface, a bluetooth interface, an HDMI interface, a Tuner interface, and the like.

The dual hardware system architecture of the present application is further described below with reference to fig. 4. It should be noted that fig. 4 is only an exemplary illustration of the dual hardware system architecture of the present application, and does not represent a limitation of the present application. In actual practice, both hardware systems may contain more or less hardware or interfaces as desired.

A block diagram of the hardware architecture of the display device 200 according to fig. 3 is exemplarily shown in fig. 4. As shown in fig. 4, the hardware system of the display device 200 may include an a chip and an N chip, and a module connected to the a chip or the N chip through various interfaces.

The N-chip may include a tuner demodulator 220, a communicator 230, an external device interface 250, a controller 210, a memory 290, a user input interface, a video processor 260-1, an audio processor 260-2, a display 280, an audio output interface 270, and a power supply. The N-chip may also include more or fewer modules in other embodiments.

The tuning demodulator 220 is configured to perform modulation and demodulation processing such as amplification, mixing, resonance and the like on a broadcast television signal received in a wired or wireless manner, so as to demodulate an audio/video signal carried in a frequency of a television channel selected by a user and additional information (e.g., an EPG data signal) from a plurality of wireless or wired broadcast television signals. Depending on the broadcast system of the television signal, the signal path of the tuner 220 may be various, such as: terrestrial broadcasting, cable broadcasting, satellite broadcasting, internet broadcasting, or the like; according to different modulation types, the signal can be adjusted in a digital modulation mode or an analog modulation mode; and depending on the type of television signal being received, tuner demodulator 220 may demodulate analog and/or digital signals.

The tuner demodulator 220 is also operative to respond to the user selected television channel frequency and the television signals carried thereby, in accordance with the user selection and as controlled by the controller 210.

In other exemplary embodiments, the tuner/demodulator 220 may be in an external device, such as an external set-top box. In this way, the set-top box outputs television audio/video signals after modulation and demodulation, and the television audio/video signals are input into the display device 200 through the external device interface 250.

The communicator 230 is a component for communicating with an external device or an external server according to various communication protocol types. For example: the communicator 230 may include a WIFI module 231, a bluetooth communication protocol module 232, a wired ethernet communication protocol module 233, and other network communication protocol modules such as an infrared communication protocol module or a near field communication protocol module.

The display apparatus 200 may establish a connection of a control signal and a data signal with an external control apparatus or a content providing apparatus through the communicator 230. For example, the communicator may receive a control signal of the remote controller 100A according to the control of the controller.

The external device interface 250 is a component for providing data transmission between the N-chip controller 210 and the a-chip and other external devices. The external device interface may be connected with an external apparatus such as a set-top box, a game device, a notebook computer, etc. in a wired/wireless manner, and may receive data such as a video signal (e.g., moving image), an audio signal (e.g., music), additional information (e.g., EPG), etc. of the external apparatus.

The external device interface 250 may include: a High Definition Multimedia Interface (HDMI) terminal 251, a Composite Video Blanking Sync (CVBS) terminal, such as any one or more of an AV interface 252, an analog or digital component terminal 353, a Universal Serial Bus (USB) terminal 254, a Red Green Blue (RGB) terminal (not shown in the figure), and the like. The number and type of external device interfaces are not limited by this application.

The controller 210 controls the operation of the display device 200 and responds to the user's operation by running various software control programs (e.g., an operating system and/or various application programs) stored on the memory 290.

As shown in fig. 4, the controller 210 includes a read only memory RAM214, a random access memory ROM213, a graphics processor 216, a CPU processor 212, a communication interface 218, and a communication bus. The RAM214, the ROM213, the graphic processor 216, the CPU processor 212, and the communication interface 218 are connected via a bus.

A ROM213 for storing instructions for various system boots. If the display device 200 is powered on upon receipt of the power-on signal, the CPU processor 212 executes a system boot instruction in the ROM and copies the operating system stored in the memory 290 to the RAM214 to start running the boot operating system. After the start of the operating system is completed, the CPU processor 212 copies the various application programs in the memory 290 to the RAM214, and then starts running and starting the various application programs.

A graphics processor 216 for generating various graphics objects, such as: icons, operation menus, user input instruction display graphics, and the like. The display device comprises an arithmetic unit which carries out operation by receiving various interactive instructions input by a user and displays various objects according to display attributes. And a renderer for generating various objects based on the operator and displaying the rendered result on the display 280.

A CPU processor 212 for executing operating system and application program instructions stored in memory 290. And executing various application programs, data and contents according to various interactive instructions received from the outside so as to finally display and play various audio and video contents.

In some exemplary embodiments, the CPU processor 212 may include a plurality of processors. The plurality of processors may include a main processor and a plurality of or a sub-processor. A main processor for performing some operations of the display apparatus 200 in a pre-power-up mode and/or operations of displaying a screen in a normal mode. A plurality of or one sub-processor for performing an operation in a standby mode or the like.

The communication interfaces may include a first interface 218-1 through an nth interface 218-n. These interfaces may be network interfaces that are connected to external devices via a network.

The controller 210 may control the overall operation of the display apparatus 200. For example: in response to receiving a user command for selecting a UI object to be displayed on the display 280, the controller 210 may perform an operation related to the object selected by the user command.

Wherein the object may be any one of selectable objects, such as a hyperlink or an icon. Operations related to the selected object, such as: displaying an operation connected to a hyperlink page, document, image, or the like, or performing an operation of a program corresponding to an icon. The user command for selecting the UI object may be a command input through various input means (e.g., a mouse, a keyboard, a touch pad, etc.) connected to the display apparatus 200 or a voice command corresponding to a voice spoken by the user.

The memory 290 includes a memory for storing various software modules for driving and controlling the display apparatus 200. Such as: various software modules stored in memory 290, including: the system comprises a basic module, a detection module, a communication module, a display control module, a browser module, various service modules and the like.

The basic module is a bottom layer software module for signal communication between hardware in the display device 200 and sending processing and control signals to an upper layer module. The detection module is a management module used for collecting various information from various sensors or user input interfaces, and performing digital-to-analog conversion and analysis management.

For example: the voice recognition module comprises a voice analysis module and a voice instruction database module. The display control module is a module for controlling the display 280 to display image content, and may be used to play information such as multimedia image content and UI interface. The communication module is used for carrying out control and data communication with external equipment. And the browser module is used for executing data communication between the browsing servers. The service module is a module for providing various services and various applications.

Meanwhile, the memory 290 is also used to store received external data and user data, images of respective items in various user interfaces, and visual effect maps of the focus object, etc.

A user input interface for transmitting an input signal of a user to the controller 210 or transmitting a signal output from the controller to the user. For example, the control device (e.g., a mobile terminal or a remote controller) may transmit an input signal input by a user, such as a power switch signal, a channel selection signal, a volume adjustment signal, etc., to the user input interface, and then the input signal is forwarded to the controller through the user input interface; alternatively, the control device may receive an output signal such as audio, video, or data output from the user input interface via the controller, and display the received output signal or output the received output signal in audio or vibration form.

In some embodiments, a user may enter a user command on a Graphical User Interface (GUI) displayed on the display 280, and the user input interface receives the user input command through the Graphical User Interface (GUI). Alternatively, the user may input the user command by inputting a specific sound or gesture, and the user input interface receives the user input command by recognizing the sound or gesture through the sensor.

The video processor 260-1 is configured to receive a video signal, and perform video data processing such as decompression, decoding, scaling, noise reduction, frame rate conversion, resolution conversion, and image synthesis according to a standard codec protocol of the input signal, so as to obtain a video signal that is directly displayed or played on the display 280.

Illustratively, the video processor 260-1 includes a demultiplexing module, a video decoding module, an image synthesizing module, a frame rate conversion module, a display formatting module, and the like.

The demultiplexing module is used for demultiplexing the input audio and video data stream, and if the input MPEG-2 is input, the demultiplexing module demultiplexes the input audio and video data stream into a video signal and an audio signal.

And the video decoding module is used for processing the video signal after demultiplexing, including decoding, scaling and the like.

And the image synthesis module is used for carrying out superposition mixing processing on the GUI signal input by the user or generated by the user and the video image after the zooming processing by the graphic generator so as to generate an image signal for display.

The frame rate conversion module is configured to convert a frame rate of an input video, such as a 24Hz, 25Hz, 30Hz, or 60Hz video, into a 60Hz, 120Hz, or 240Hz frame rate, where the input frame rate may be related to a source video stream, and the output frame rate may be related to an update rate of a display. The input is realized in a common format by using a frame insertion mode.

And a display formatting module for converting the signal output by the frame rate conversion module into a signal conforming to a display format of a display, such as converting the format of the signal output by the frame rate conversion module to output an RGB data signal.

And a display 280 for receiving the image signal input from the video processor 260-1 and displaying the video content and image and the menu manipulation interface. The display 280 includes a display component for presenting a picture and a driving component for driving the display of an image. The video content may be displayed from the video in the broadcast signal received by the tuner/demodulator 220, or from the video content input from the communicator or the external device interface. And a display 220 simultaneously displaying a user manipulation interface UI generated in the display apparatus 200 and used to control the display apparatus 200.

And, a driving component for driving the display according to the type of the display 280. Alternatively, in case the display 280 is a projection display, it may also comprise a projection device and a projection screen.

The audio processor 260-2 is configured to receive the audio signal, and perform decompression and decoding, and audio data processing such as noise reduction, digital-to-analog conversion, and amplification processing according to a standard codec protocol of the input signal, so as to obtain an audio signal that can be played in the speaker 272.

An audio output interface 270 for receiving the audio signal output from the audio processor 260-2 under the control of the controller 210, which may include a speaker 272 or an external audio output terminal 274 for outputting to a generating device of an external device, such as: external sound terminal or earphone output terminal.

In other exemplary embodiments, the video processor 260-1 may comprise one or more chips. The audio processor 260-2 may also comprise one or more chips.

And, in other exemplary embodiments, the video processor 260-1 and the audio processor 260-2 may be separate chips or may be integrated in one or more chips with the controller 210.

And a power supply for supplying power supply support to the display apparatus 200 from the power input from the external power source under the control of the controller 210. The power supply may include a built-in power supply circuit installed inside the display apparatus 200, or may be a power supply installed outside the display apparatus 200, such as a power supply interface for providing an external power supply in the display apparatus 200.

Similar to the N-chip, as shown in fig. 4, the a-chip may include a controller 310, a communicator 330, a detector 340, and a memory 390. A user input interface, a video processor, an audio processor, a display, an audio output interface may also be included in some embodiments. In some embodiments, there may also be a power supply that independently powers the A-chip.

The communicator 330 is a component for communicating with an external device or an external server according to various communication protocol types. For example: the communicator 330 may include a WIFI module 331, a bluetooth communication protocol module 332, a wired ethernet communication protocol module 333, and other network communication protocol modules such as an infrared communication protocol module or a near field communication protocol module.

The a-chip communicator 330 and the N-chip communicator 230 also interact with each other. For example, the N-chip WiFi module 231 is used to connect to an external network, generate network communication with an external server, and the like. The WiFi module 331 of the a chip is used to connect to the WiFi module 231 of the N chip without making a direct connection with an external network or the like. Therefore, for the user, a display device as in the above embodiment displays a WiFi account to the outside.

The detector 340 is a component of the display device a chip for collecting signals of an external environment or interacting with the outside. The detector 340 may include a light receiver 342, a sensor for collecting the intensity of ambient light, which may be used to adapt to display parameter changes, etc.; the system may further include an image collector 341, such as a camera, a video camera, etc., which may be configured to collect external environment scenes, collect attributes of the user or interact gestures with the user, adaptively change display parameters, and identify user gestures, so as to implement a function of interaction with the user.

An external device interface 350, which provides a component for data transmission between the controller 310 and the N-chip or other external devices. The external device interface may be connected with an external apparatus such as a set-top box, a game device, a notebook computer, etc. in a wired/wireless manner.

The controller 310 controls the operation of the display device 200 and responds to the user's operation by running various software control programs stored on the memory 390 (e.g., using an installed third party application, etc.), and interacting with the N-chip.

As shown in fig. 4, the controller 310 includes a read only memory ROM313, a random access memory RAM314, a graphics processor 316, a CPU processor 312, a communication interface 318, and a communication bus. The ROM313 and the RAM314, the graphic processor 316, the CPU processor 312, and the communication interface 318 are connected via a bus.

A ROM313 for storing instructions for various system boots. CPU processor 312 executes system boot instructions in ROM and copies the operating system stored in memory 390 to RAM314 to begin running the boot operating system. After the start of the operating system is completed, the CPU processor 312 copies various application programs in the memory 390 to the RAM314, and then starts running and starting various application programs.

The CPU processor 312 is used for executing the operating system and application program instructions stored in the memory 390, communicating with the N chip, transmitting and interacting signals, data, instructions, etc., and executing various application programs, data and contents according to various interaction instructions received from the outside, so as to finally display and play various audio and video contents.

The communication interfaces may include a first interface 318-1 through an nth interface 318-n. These interfaces may be network interfaces connected to external devices via a network, or may be network interfaces connected to the N-chip via a network.

The controller 310 may control the overall operation of the display apparatus 200. For example: in response to receiving a user command for selecting a UI object to be displayed on the display 280, the controller 210 may perform an operation related to the object selected by the user command.

A graphics processor 316 for generating various graphics objects, such as: icons, operation menus, user input instruction display graphics, and the like. The display device comprises an arithmetic unit which carries out operation by receiving various interactive instructions input by a user and displays various objects according to display attributes. And a renderer for generating various objects based on the operation unit and displaying the rendered result on the display 280.

Both the A-chip graphics processor 316 and the N-chip graphics processor 216 are capable of generating various graphics objects. Distinctively, if application 1 is installed on the a-chip and application 2 is installed on the N-chip, the a-chip graphics processor 316 generates a graphics object when a user performs a user-entered command within application 1 at the interface of application 1. When a user makes a command input by the user at the interface of the application 2 and within the application 2, a graphic object is generated by the graphic processor 216 of the N chip.

Fig. 5 is a diagram exemplarily showing a functional configuration of a display device according to an embodiment.

As shown in fig. 5, the memory 390 of the a-chip and the memory 290 of the N-chip are used to store an operating system, an application program, contents, user data, and the like, respectively, and perform system operations for driving the display device 200 and various operations in response to a user under the control of the controller 310 of the a-chip and the controller 210 of the N-chip. The A-chip memory 390 and the N-chip memory 290 can include volatile and/or non-volatile memory.

The memory 290 is specifically configured to store an operating program for driving the controller 210 in the display device 200, and store various applications installed in the display device 200, various applications downloaded by a user from an external device, various graphical user interfaces related to the applications, various objects related to the graphical user interfaces, user data information, and internal data of various supported applications. The memory 290 is used to store system software such as an Operating System (OS) kernel, middleware, and applications, and to store input video data and audio data, and other user data.

The memory 290 is specifically used for storing drivers and related data such as the video processor 260-1 and the audio processor 260-2, the display 280, the communication interface 230, the tuner demodulator 220, the input/output interface, etc.

In some embodiments, memory 290 may store software and/or programs representing software programs for an Operating System (OS) including, for example: a kernel, middleware, an Application Programming Interface (API), and/or an application program. For example, the kernel may control or manage system resources, or functions implemented by other programs (e.g., the middleware, APIs, or applications), and the kernel may provide interfaces to allow the middleware and APIs, or applications, to access the controller to implement controlling or managing system resources.

The memory 290, for example, includes a broadcast receiving module 2901, a channel control module 2902, a volume control module 2903, an image control module 2904, a display control module 2905, an audio control module 2906, an external instruction recognition module 2907, a communication control module 2908, a power control module 2910, an operating system 2911, and other application programs 2912, a browser module, and the like. The controller 210 performs functions such as: the system comprises a broadcast television signal receiving and demodulating function, a television channel selection control function, a volume selection control function, an image control function, a display control function, an audio control function, an external instruction identification function, a communication control function, an optical signal receiving function, an electric power control function, a software control platform supporting various functions, a browser function and other various functions.

The memory 390 includes a memory storing various software modules for driving and controlling the display apparatus 200. Such as: various software modules stored in memory 390, including: the system comprises a basic module, a detection module, a communication module, a display control module, a browser module, various service modules and the like. Since the functions of the memory 390 and the memory 290 are similar, reference may be made to the memory 290 for relevant points, and details will not be described herein.

The memory 390, for example, includes an image control module 3904, an audio control module 2906, an external instruction recognition module 3907, a communication control module 3908, a light receiving module 3909, an operating system 3911, and other application programs 3912, a browser module, and the like. The controller 210 performs functions such as: the system comprises an image control function, a display control function, an audio control function, an external instruction identification function, a communication control function, an optical signal receiving function, an electric power control function, a software control platform supporting various functions, a browser function and other various functions.

Distinctively, the external instruction recognition module 2907 of the N-chip and the external instruction recognition module 3907 of the a-chip can recognize different instructions.

For example, since an image receiving device such as a camera is connected to the a-chip, the external instruction identifying module 3907 of the a-chip may include an image identifying module 3907-1, a graphic database is stored in the image identifying module 3907-1, and when the camera receives an external graphic instruction, the camera corresponds to the instruction in the graphic database to perform instruction control on the display device. Since the voice receiving device and the remote controller are connected to the N chip, the external command recognition module 2907 of the N chip may include a voice recognition module 2907-2, a voice database is stored in the voice recognition module 2907-2, and when the voice receiving device receives an external voice command or the like, the voice receiving device corresponds to a command in the voice database to perform command control on the display device. Similarly, a control device 100 such as a remote controller is connected to the N-chip, and command interaction is performed with the control device 100 by the key command recognition module.

A block diagram of the configuration of the software system in the display device 200 according to an embodiment is exemplarily shown in fig. 6 a.

For an N-chip, as shown in fig. 6a, the operating system 2911, including the executing operating software for handling various basic system services and for performing hardware related tasks, acts as an intermediary between applications and hardware components for data processing.

In some embodiments, portions of the operating system kernel may contain a series of software to manage the display device hardware resources and provide services to other programs or software code.

In other embodiments, portions of the operating system kernel may include one or more device drivers, which may be a set of software code in the operating system that assists in operating or controlling the devices or hardware associated with the display device. The drivers may contain code that operates the video, audio, and/or other multimedia components. Examples include a display, a camera, Flash, WiFi, and audio drivers.

The accessibility module 2911-1 is configured to modify or access the application program to achieve accessibility of the application program and operability of the displayed content.

A communication module 2911-2 for connection to other peripherals via associated communication interfaces and a communication network.

The user interface module 2911-3 is configured to provide an object for displaying a user interface, so that each application program can access the object, and user operability can be achieved.

Control applications 2911-4 for controlling process management, including runtime applications and the like.

The event transmission system 2914 may be implemented within the operating system 2911 or within the application 2912. In some embodiments, one aspect is implemented within the operating system 2911, while implemented in the applications 2912, for listening for various user input events, and the handlers that implement one or more predefined sets of operations in response to the recognition of various events or sub-events will be referred to in terms of various events.

The event monitoring module 2914-1 is configured to monitor an event or a sub-event input by the user input interface.

The event recognition module 2914-2 is used to input various event definitions for various user input interfaces, recognize various events or sub-events, and transmit them to the processes for executing their respective set or sets of handlers.

The event or sub-event refers to an input detected by one or more sensors in the display device 200 and an input of an external control device (e.g., the control apparatus 100). Such as: the method comprises the following steps of inputting various sub-events through voice, inputting a gesture sub-event through gesture recognition, inputting a remote control key instruction of a control device, and the like. Illustratively, the one or more sub-events in the remote control include a variety of forms including, but not limited to, one or a combination of key presses up/down/left/right/, ok key, key press and the like. And non-physical key operations such as move, hold, release, etc.

The interface layout management module 2913, directly or indirectly receiving the input event or sub-event from the event transmission system 2914, monitors the input events or sub-events, and updates the layout of the user interface, including but not limited to the position of each control or sub-control in the interface, and the size, position, and level of the container, and other various execution operations related to the layout of the interface.

Since the functions of the operating system 3911 of the a chip are similar to those of the operating system 2911 of the N chip, reference may be made to the operating system 2911 for relevant points, and details are not repeated here.

Fig. 6b schematically shows a configuration of an application in a display device according to an embodiment; as shown in fig. 6b, the application layer of the display device contains various applications that can be executed at the display device 200.

The N-chip application layer 2912 may include, but is not limited to, one or more applications such as: video on demand applications, application centers, gaming applications, and the like. The application layer 3912 of the a-chip may include, but is not limited to, one or more applications such as: live television applications, media center applications, and the like. It should be noted that what applications are respectively contained in the a chip and the N chip is determined according to an operating system and other designs, and the present invention does not need to make specific limitations and divisions on the applications contained in the a chip and the N chip.

The live television application program can provide live television through different signal sources. For example, a live television application may provide television signals using input from cable television, radio broadcasts, satellite services, or other types of live television services. And, the live television application may display video of the live television signal on the display device 200.

A video-on-demand application may provide video from different storage sources. Unlike live television applications, video on demand provides video displays from some storage source. For example, the video on demand may come from a server side of cloud storage, from a local hard disk storage containing stored video programs.

The media center application program can provide various applications for playing multimedia contents. For example, a media center, which may be other than live television or video on demand, may provide services for a user to access various images or audio through a media center application.

The application center can provide and store various applications. The application may be a game, an application, or some other application associated with a computer system or other device but that may be run on the display device. The application center may obtain these applications from different sources, store them in local storage, and then be executable on the display device 200.

A schematic diagram of a user interface in a display device 200 according to an embodiment is illustrated in fig. 7. As shown in fig. 7, the user interface includes a plurality of view display areas, illustratively, a first view display area 201 and a play screen 202, wherein the play screen includes a layout of one or more different items. And a selector is included in the user interface indicating that an item is selected, the position of the selector being movable by user input to change the selection of a different item.

It should be noted that the multiple view display areas may present display screens of different hierarchies. For example, a first view display area may present video chat project content and a second view display area may present application layer project content (e.g., web video, VOD presentation, application screens, etc.).

Optionally, the different view display areas are presented with different priority levels, and the display priority levels of the view display areas are different among the view display areas with different priority levels. If the priority of the system layer is higher than that of the application layer, when the user uses the acquisition selector and switches pictures in the application layer, the picture display of the view display area of the system layer is not blocked; and when the size and the position of the view display area of the application layer are changed according to the selection of the user, the size and the position of the view display area of the system layer are not influenced.

The display frames of the same hierarchy can also be presented, at this time, the selector can switch between the first view display area and the second view display area, and when the size and the position of the first view display area are changed, the size and the position of the second view display area can be changed along with the change.

Since the a-chip and the N-chip may have independent operating systems installed therein, there are two independent but interrelated subsystems in the display device 200. For example, Android (Android) and various APPs can be independently installed on the chip a and the chip N, so that each chip can realize a certain function, and the chip a and the chip N cooperatively realize a certain function. As the use requirements of users change, the system built in the display device needs to be upgraded continuously to meet the requirements of users.

When a display device with a dual-system architecture is upgraded, the conventional method generally adopts a serial upgrade mode, that is, after one system is upgraded, another system is upgraded, and the upgrade time is double that of a single system, so that the upgrade efficiency of the dual system is low. And if one system is upgraded successfully and the other system is upgraded unsuccessfully, versions of the two systems are inconsistent, and normal operation of the display device is affected. Therefore, the embodiment of the invention provides a dual-system OTA parallel upgrading method, two systems adopt a parallel upgrading mode, one system is upgraded while the other system is upgraded, and the dual systems enter an upgrading mode simultaneously, so that the time for upgrading the two systems is the same as that of a single system, and the upgrading efficiency is improved. If an upgrade exception occurs, the embodiment further provides a failure processing logic to recover the upgrade process of the system in which the exception occurs.

The dual system proposed in the present embodiment includes a first hardware system (system a) and a second hardware system (system N). The second hardware system (system N) is a main system and is used for receiving an upgrading instruction, and if a USB flash disk is adopted for upgrading, the USB flash disk needs to be accessed into the second hardware system (system N); the first hardware system (system a) is an auxiliary system and has no USB interface. The first hardware system (system A) and the second hardware system (system N) are connected through a network cable, a serial port, an HDMI and a USB cable.

When the dual system is upgraded in parallel, two modes of USB flash disk upgrading and Recovery upgrading are generally adopted. In order to enable the two systems to simultaneously enter an upgrading mode, the second hardware system triggers upgrading in the USB flash disk upgrading mode, and an upgrading mark is written into the first hardware system when the first hardware system is started, so that after being restarted, the first hardware system and the second hardware system both simultaneously enter a program for detecting an upgrading packet instead of entering a normal starting process. In the Recovery upgrade mode, the difference from the usb disk upgrade mode is that the first hardware system and the second hardware system write the upgrade flag at the same time before the restart.

In order to reduce the time spent on upgrading the dual systems, the dual systems need to simultaneously execute the upgrading process after entering the upgrading mode, and therefore, real-time communication needs to be performed between the two systems. Fig. 8 is a diagram illustrating a communication manner of a dual system according to an embodiment; as shown in fig. 8, the dual systems may communicate using a direct physical path. In the USB flash disk upgrade mode: at this time, serial ports are selected for communication paths of the system N and the system A. In Recovery upgrade mode: the network may be normally established, and at this time, the communication path between the system N and the system a is the master network and the alternative serial port.

The dual systems synchronously enter a Recovery mode to carry out subsequent upgrading operation, the dual systems in the Recovery mode carry out communication through a network or a serial port, and the states of the two sides of the N/A are synchronized in the installation process. The dual-system communication mode comprises an active inquiry mode and a behavior command sending mode, wherein the N end is an active communication party and is respectively in an R/R mode judging stage, an OTA packet checking stage, an OTA packet installing stage and an exit stage. In the R/R mode judging stage, the N terminal actively inquires the mode of the A terminal system, and if the A terminal does not enter the Recovery mode, a restart command is sent; in the verification stage, the N terminal actively inquires the verification state of the A terminal, sends an installation instruction under the condition of successful verification and sends a restart instruction under the condition of failed verification; in the installation stage, the N terminal actively inquires the installation state and the installation progress of the A terminal and sends a restart instruction after installation.

FIG. 9 is a flow diagram that illustrates a concurrent upgrade between system N and system A, according to an embodiment; the process of the simultaneous upgrade between the system N and the system a provided in this embodiment is shown in fig. 9, where the two systems enter the upgrade mode at the same time, each performs its own version check, and then waits for establishing communication. In the usb disk upgrade mode, since a separate upgrade can be implemented on one side, the communication establishment section needs to be executed regardless of whether the version check of the system N is successful or not. In the Recovery upgrade mode, if the N-side verification fails, because Recovery does not allow the OTA upgrade alone in order to prevent version mismatch, at this time, it is necessary to directly enter the verification failure processing module and execute the failure processing logic.

After the respective version detection is finished, the system N and the system A establish communication, and at the moment, different communication modes can be selected according to different scenes to establish communication connection. After the communication is established, the system N actively inquires the inspection state of the system A, wherein the inspection state comprises different communication and no return value; the verification is successful; three cases of verification failure. In the USB flash disk upgrading mode, the system N waits for 10s, if the system A has no return value, the connection between the system N and the system A fails, and at the moment, the upgrading of the system N is directly started. If the return value of the system A is check failure, the system A also directly enters the N system for upgrading. If the return value of system A is successful, system N proceeds to the next step. In the Recovery upgrade mode, the system N waits for 10s, if the system A has no return value, the connection between the system N and the system A is failed, and then the system N directly enters an error processing module. And if the return value of the system A is the check failure, directly entering an error processing module. If the return value of system A is successful, system N proceeds to the next step.

And when the system N receives a successful verification result returned by the system A, sending an installation command to the system A, and installing the system N and the system A at the same time. During installation, a progress bar representing the installation progress is displayed on the system N, the installation progress of the system A is inquired in real time in the installation process, and the installation progress of the system N and the installation progress of the system A are displayed on the progress bar together.

And after the system N is upgraded, actively inquiring the upgrading result of the system A. If system A returns a success, the system is restarted to enter user mode. And if the system A returns an upgrade result and is overtime or fails to upgrade, entering an exception handling module.

If the dual system is abnormal when installing the upgrade package for upgrading, a recovery mechanism needs to be executed, specifically, the content of the failure processing logic needs to be determined according to the service logic. For example, in the usb disk upgrade mode, since the usb disk mode supports single-side upgrade, if a certain system is abnormal, a waiting step may be performed until the upgrade of the opposite terminal is completed. In the Recovery upgrade mode, when the dual system performs OTA upgrade, the principle adopted in this embodiment is that both ends of the dual system must be upgraded at the same time, if one end fails to check, both ends are not upgraded, but the upgrade failure of a certain end does not interrupt the upgrade progress of the other end, and after the end finishes upgrading, both systems restart at the same time.

When the dual-system performs OTA upgrade, the main process comprises four processes of detecting the version, downloading the version, checking the version and installing the version, and in order to realize the dual-system OTA parallel upgrade, the method provided by the embodiment is mainly applied to the process of installing the version.

Fig. 10 illustrates a flow diagram of a dual system OTA parallel upgrade method according to an embodiment; as shown in fig. 10, the dual-system OTA parallel upgrading method provided in the embodiment of the present invention includes the following steps:

s11, when the first hardware system and the second hardware system enter into Recovery mode at the same time, the first hardware system checks the first OTA upgrade package, the second hardware system checks the second OTA upgrade package; the first OTA upgrade package is used for upgrading the first hardware system, and the second OTA upgrade package is used for upgrading the second hardware system.

When an upgrade instruction is received, the first hardware system (system A) and the second hardware system (system N) write an upgrade flag at the same time, and enter a Recovery mode after being restarted. After the N terminal is restarted and enters the Recovery mode, the N terminal judges whether the current A terminal is also in the Recovery mode, if so, the subsequent logic is continuously executed; if not, entering failure processing logic.

After the N/A terminals simultaneously enter a Recovery mode, the N/A terminals simultaneously and respectively verify respective OTA upgrade packages; if the verification of the N end fails, entering a failure processing logic, if the verification of the N end succeeds, entering a synchronous mode, and in the process, directly entering the synchronous mode after the verification of the A end, waiting for an N-end communication command, and executing a subsequent logic; and the N end actively inquires the verification result of the A end in the synchronous mode, if the verification of the A end is successful, the dual-system enters an installation mode, and if the verification of the A end is failed or the communication is overtime, the dual-system enters failure processing logic and does not execute the subsequent installation.

It can be seen that after the dual systems are started, before the respective OTA upgrade packages are verified, it is further required to determine whether both the system N and the system a are in the Recovery mode, and if one end of the system N is not in the Recovery mode, parallel upgrade of the dual systems cannot be guaranteed.

Fig. 11 illustrates an overall data flow diagram of a dual system OTA parallel upgrade method according to an embodiment; FIG. 12 is a flow diagram illustrating a dual system OTA parallel upgrade method according to another embodiment; as shown in fig. 11 and fig. 12, before verifying the OTA upgrade package, the method provided in this embodiment further includes:

and S01, writing the upgrading marks into the first hardware system and the second hardware system respectively according to the upgrading instruction.

The second hardware system receives an upgrading instruction, and the upgrading instruction can be triggered by a user through a remote controller or by inserting an upgrading USB flash disk into the second hardware system. And after receiving the upgrading instruction, the second hardware system sends an upgrading mark writing instruction to the first hardware system, and controls the first hardware system and the second hardware system to write the upgrading mark at the same time.

The upgrade flag is a flag written in a boot directory of the system, and is used for guiding a subsequent program to enter an upgrade mode. According to the upgrading mark, the dual system can enter an upgrading mode instead of entering a normal starting state.

And S02, restarting the first hardware system and the second hardware system according to the upgrading mark, and enabling the first hardware system and the second hardware system to respectively enter a Recovery mode.

And after the upgrade flag is written into the first hardware system and the second hardware system, restarting the first hardware system and the second hardware system, wherein the first hardware system and the second hardware system can enter a Recovery mode under a normal condition.

Because the result of writing the upgrade flag is different, and due to network, it may happen that a certain system does not enter the Recovery mode, and therefore, in order to ensure that both systems are in the Recovery mode for synchronous upgrade, it is necessary to check whether both system N and system a enter the Recovery mode.

S03, after the second hardware system enters the Recovery mode, sending a query instruction to the first hardware system; the query instruction is used for querying whether the first hardware system successfully enters the Recovery mode.

And the second hardware system is an active communication party, and actively inquires whether the first hardware system successfully enters the Recovery mode after the second hardware system is restarted and enters the Recovery mode.

And the second hardware system generates a query instruction immediately after entering the Recovery mode, sends the query instruction to the first hardware system, and returns a result according to the query instruction by the first hardware system, wherein the result comprises that the Recovery mode is successfully entered and the Recovery mode is not successfully entered.

And S04, if the second hardware system receives a successful entering result returned by the first hardware system according to the query instruction, the first hardware system verifies the first OTA upgrading packet, and the second hardware system verifies the second OTA upgrading packet.

If the first hardware system returns the successful entering result, the first hardware system and the second hardware system are both successfully entered into the Recovery mode, and the upgrading steps can be continuously executed, namely, the steps that the first hardware system verifies the first OTA upgrading packet and the second hardware system verifies the second OTA upgrading packet are executed.

However, if the first hardware system returns an unsuccessful entry result, which indicates that the first hardware system is abnormal, the failure processing logic needs to be entered.

FIG. 13 is a data flow diagram that illustrates failure handling logic for the verification phase in accordance with an embodiment; fig. 14 is a flow chart illustrating a dual system OTA parallel upgrade method according to yet another embodiment; as shown in fig. 13 and fig. 14, the method provided in this embodiment further includes:

and S05, if the second hardware system receives the unsuccessful entry result returned by the first hardware system according to the query instruction, querying whether the first hardware system has the OTA upgrade patch of the current version.

And when the result of entering the Recovery mode returned by the first hardware system is an unsuccessful entering result, generating a query instruction by the second hardware system, and sending the query instruction to the first hardware system to query whether the OTA upgrade package of the current version exists in the first hardware system. The current version of the OTA upgrade package is a first OTA upgrade package for implementing the first hardware system upgrade.

And S06, if the instruction does not exist, the second hardware system generates an exit instruction and sends the exit instruction to the first hardware system, so that the first hardware system and the second hardware system exit the Recovery mode.

And if the first hardware system does not have the OTA upgrade package of the current version, the second hardware system directly judges that the upgrade fails, generates an exit instruction at the moment, exits the Recovery mode, and restarts and returns to the main system.

And S07, if the command exists, sending a command for writing the BCB information to the first hardware system.

If the first hardware system has the OTA upgrade package of the current version, the upgrade process can be continuously executed. And the second hardware system generates a BCB information writing instruction to the first hardware system, so that the BCB information is written into the first hardware system.

The BCB (BootLoader Control Block) is a structural body, and is a communication interface between BootLoader and Recovery. The BCB information refers to information used for determining to enter Recovery mode or the host system when the loader boots, for example, if the system needs to enter Recovery mode, the system can be determined to enter OTA upgrade or clear data operation according to the BCB information.

Each system has own BCB information, and the first hardware system writes the BCB information which is restarted to enter a Recovery mode to execute OTA upgrading in the next time according to a BCB information writing instruction sent by the second hardware system.

And S08, receiving a BCB information writing success result returned by the first hardware system according to the BCB information writing instruction, and sending a restarting instruction to the first hardware system so that the first hardware system is restarted after the BCB information is written in.

After the first hardware system finishes writing the BCB information, a success result of writing the BCB information is returned to the second hardware system, and the second hardware system generates a restart instruction after receiving the success result of writing the BCB information so that the first hardware system is restarted.

The first hardware system can enter a Recovery mode instead of a normal starting mode after being restarted according to the BCB information.

And S09, after the first hardware system is restarted, the second hardware system generates a new query instruction, sends the new query instruction to the first hardware system, and queries whether the first hardware system successfully enters the Recovery mode.

After the first hardware system is restarted, the second hardware system continuously inquires the mode state of the first hardware system, namely, whether the first hardware system enters a Recovery mode or not is inquired.

The second hardware system generates a new query instruction every 30 seconds, namely, whether the first hardware system enters the Recovery mode is queried every 30 seconds until the first hardware system enters the Recovery mode; and if the first hardware system does not enter the Recovery mode after the third retry, exiting the installation mode and not executing upgrading operation on the first hardware system and the second hardware system.

And S010, if the second hardware system receives a successful entering result returned by the first hardware system according to the new query instruction, the first hardware system verifies the first OTA upgrading packet, and the second hardware system verifies the second OTA upgrading packet.

And if the first hardware system returns a successful entering result to the second hardware system after entering the Recovery mode, at the moment, the second hardware system and the first hardware system can continue to execute subsequent upgrading operation, namely the first hardware system verifies the first OTA upgrading packet, and the second hardware system verifies the second OTA upgrading packet.

And under the condition that the first hardware system and the second hardware system simultaneously enter a Recovery mode, respectively checking the respective upgrade packages by the first hardware system and the second hardware system.

And S12, under the condition that the first hardware system and the second hardware system are verified successfully respectively, the second hardware system generates an installation instruction and sends the installation instruction to the first hardware system.

And if the first hardware system successfully verifies the first OTA upgrade package and the second hardware system successfully verifies the second OTA upgrade package, indicating that the first hardware system and the second hardware system can enter the installation mode. At the moment, the second hardware system generates an installation instruction and sends the installation instruction to the first hardware system, the first OTA upgrade package is installed on the first hardware system to realize the upgrade of the first hardware system, and the second hardware system installs the second OTA upgrade package to realize the upgrade of the second hardware system.

In order to ensure that the first hardware system and the second hardware system synchronously enter the installation mode after synchronously entering the Recovery mode, the first hardware system and the second hardware system need to enter the synchronization mode. FIG. 15 is a flow diagram that illustrates a method for a dual system to enter an upgrade phase in parallel, according to an embodiment; specifically, in this embodiment, as shown in fig. 15, when the first hardware system and the second hardware system are verified successfully respectively, the generating, by the second hardware system, an installation instruction, which is sent to the first hardware system, includes:

s141, judging whether the first OTA upgrade package is checked by the first hardware system, and whether the second OTA upgrade package is checked by the second hardware system successfully.

The first hardware system directly enters a synchronization mode after completing the verification process of the first OTA upgrade package, and the second hardware system enters the synchronization mode only after the second OTA upgrade package is successfully verified, so that the conditions for the first hardware system and the second hardware system to enter the synchronization mode are different, the first hardware system can complete the verification of the first OTA upgrade package, and the second hardware system can enter the synchronization mode only after the second OTA upgrade package is successfully verified.

The synchronization mode is used for realizing information and state synchronization of the first hardware system and the second hardware system so as to ensure that the first hardware system and the second hardware system can execute the same flow at the same time, and enter the installation mode at the same time.

And S142, if the second hardware system successfully verifies the second OTA upgrade package and the first hardware system completes verification of the first OTA upgrade package, the second hardware system and the first hardware system respectively enter a synchronization mode.

And S143, in the synchronous mode, the second hardware system generates a checking result query instruction and sends the checking result query instruction to the first hardware system.

When the first hardware system and the second hardware system simultaneously meet the condition of entering the synchronous mode, namely the second hardware system successfully verifies the second OTA upgrade package, immediately entering the synchronous mode; and the first hardware system completes the verification of the first OTA upgrade package, directly enters a synchronization mode and waits for a communication command of the second hardware system.

In the synchronous mode, the second hardware system may actively query the state of the first hardware system. At this time, the second hardware system generates a checking result query instruction to query the checking result of the first hardware system on the first OTA upgrade package.

And S144, if the second hardware system receives a verification success result returned by the first hardware system according to the verification result query instruction, the second hardware system generates an installation instruction and sends the installation instruction to the first hardware system.

And the first hardware system returns the verification result of the first OTA upgrade package to the second hardware system according to the verification result query instruction, and if the returned result is a verification success result, the first hardware system and the second hardware system both complete the verification process and succeed, and can enter a subsequent installation mode.

At the moment, the second hardware system immediately generates an installation instruction and sends the installation instruction to the first hardware system, the first hardware system and the second hardware system synchronously enter an installation mode according to the installation instruction, the first hardware system installs the first OTA upgrade package to realize the upgrade of the first hardware system, and the second hardware system installs the second OTA upgrade package to realize the upgrade of the second hardware system.

However, if the second hardware system receives a check failure result or a check timeout result returned by the first hardware system according to the check result query instruction, the first hardware system is abnormal at this time, and the second hardware system enters a failure processing logic and does not execute the subsequent installation process any more.

Specifically, the second hardware system may generate a new query instruction every 30 seconds, that is, query every 30 seconds whether the first hardware system successfully verifies the first OTA upgrade package until the first hardware system successfully verifies and returns a verification success result; if the first hardware system is retried for three times and the first hardware system is not verified successfully or the verification success result is not returned, the installation mode is exited, and the upgrading operation is not executed on the first hardware system and the second hardware system.

In the actual verification process, the second hardware system may also have a verification failure. When the second hardware system fails to verify, the method provided by this embodiment further includes:

and S151, if the second hardware system fails to verify the second OTA upgrade package, generating a verification state query instruction and sending the verification state query instruction to the first hardware system.

And if the second hardware system fails to check, directly entering failure processing logic. In this case, the failure handling logic comprises: and the second hardware system generates a checking state inquiry instruction to inquire the state of the first hardware system and judge whether the first hardware system is in a checking state or is checked.

And S152, when the second hardware system receives a result in the check state returned by the first hardware system according to the check state query instruction, generating an exit instruction, and sending the exit instruction to the first hardware system to enable the first hardware system to enter an exit mode.

And if the result returned by the first hardware system according to the check state query instruction is the result in the check state, the second hardware system generates an exit instruction at the moment, so that the first hardware system enters an exit mode and does not perform the check process any more. And after the first hardware system enters the exit mode, the second hardware system performs resource releasing restarting operation, returns to the main system and finishes the upgrading operation.

And if the result returned by the first hardware system is a result which is not in the checking state, namely the first hardware system finishes checking, at the moment, the second hardware system can be directly restarted, and the upgrading operation is finished.

Therefore, the first hardware system and the second hardware system respectively check the respective upgrade packages, and when the first hardware system and the second hardware system are successfully checked, the first hardware system and the second hardware system synchronously enter an installation mode. If the verification abnormality occurs at one end, the method enters a failure processing logic, can adopt a retry mechanism to obtain the information of the end again, and can also directly end the upgrading operation, thereby avoiding that the double systems are always in an abnormal upgrading state, the upgrading time is too long, and the user experience is influenced.

And S13, according to the installation instruction, the first hardware system starts to be installed according to the first OTA upgrade package, and the second hardware system starts to be installed according to the second OTA upgrade package.

After receiving the installation instruction, the first hardware system and the second hardware system synchronously enter an installation mode, the first hardware system starts to install the first OTA upgrade package to realize the upgrade of the first hardware system, and the second hardware system starts to realize the upgrade of the second hardware system according to the second OTA upgrade package.

After the first hardware system and the second hardware system are verified successfully, the second hardware system communicates that the first hardware system starts to enter an installation mode, and the first hardware system and the second hardware system start to be installed at the same time. And if the second hardware system is failed to be installed, entering a failure processing logic, and if the second hardware system is successfully installed, entering a synchronization mode. And actively inquiring the installation result of the first hardware system by the second hardware system in a synchronous mode, entering an exit mode by the dual system if the first hardware system is successfully installed, and entering a failure processing logic if the first hardware system is failed to install or the communication is overtime.

The process of exiting the mode includes: after the first hardware system and the second hardware system are installed successfully, the second hardware system communicates the first hardware system to enter an exit mode, and after the second hardware system exits from the first hardware system, the second hardware system releases resources to restart and returns to the main system.

S14, under the condition that the first hardware system and the second hardware system are installed successfully respectively, the second hardware system generates a restart instruction and sends the restart instruction to the first hardware system;

and if the first hardware system is successfully installed and the second hardware system is successfully installed, indicating that the first hardware system and the second hardware system can enter an exit mode. At the moment, the second hardware system generates a restart instruction and sends the restart instruction to the first hardware system, and the first hardware system and the second hardware system enter an exit mode simultaneously.

To ensure that the dual systems simultaneously enter the installation mode and then execute the corresponding installation process, the dual systems may synchronously enter the exit mode, and fig. 16 is a flowchart illustrating a method for the dual systems to enter the restart phase in parallel according to an embodiment; as shown in fig. 16, in the method provided in this embodiment, when the first hardware system and the second hardware system are installed successfully, the second hardware system generates a restart instruction and sends the restart instruction to the first hardware system, which includes:

s161, judging whether the installation process of the second OTA upgrade patch installed by the second hardware system is successful, and whether the installation process of the first OTA upgrade patch installed by the first hardware system is completed.

Because the first hardware system can enter the synchronization mode after the first OTA upgrade package is installed, and the second hardware system can enter the synchronization mode after the second OTA upgrade package is installed successfully, the conditions for the first hardware system and the second hardware system to enter the synchronization mode are different, the first hardware system can complete the installation of the first OTA upgrade package, and the second hardware system can enter the synchronization mode after the second OTA upgrade package is installed successfully.

And S162, if the second hardware system successfully installs the second OTA upgrade package and the first hardware system completes the installation of the first OTA upgrade package, the second hardware system and the first hardware system respectively enter a synchronization mode.

And S163, in the synchronous mode, the second hardware system generates an installation result query instruction and sends the installation result query instruction to the first hardware system.

When the first hardware system and the second hardware system simultaneously meet the condition of entering the synchronous mode, namely the second hardware system successfully installs the second OTA upgrade package, immediately entering the synchronous mode; and the first hardware system completes the installation of the first OTA upgrade package, directly enters a synchronization mode and waits for a communication command of the second hardware system.

In the synchronous mode, the second hardware system may actively query the state of the first hardware system. At this time, the second hardware system generates an installation result query instruction to query the installation condition of the first hardware system on the first OTA upgrade package.

And S164, if the second hardware system receives an installation success result returned by the first hardware system according to the installation result query instruction, generating an exit instruction and sending the exit instruction to the first hardware system.

And S165, according to the exit instruction, after the first hardware system and the second hardware system enter the exit mode, the second hardware system generates a restart instruction and sends the restart instruction to the first hardware system.

And the first hardware system returns the installation result of the first OTA upgrade package to the second hardware system according to the installation result query instruction, and if the returned result is an installation success result, the first hardware system and the second hardware system both complete the installation process and succeed at the moment, and can enter a subsequent exit mode.

At the moment, the second hardware system immediately generates an exit instruction and sends the exit instruction to the first hardware system, and the first hardware system and the second hardware system synchronously enter an exit mode according to the exit instruction. And after the first hardware system enters the exit mode, the second hardware system performs resource releasing restarting operation, returns to the main system and finishes the upgrading operation.

And S15, according to the restart instruction, the first hardware system and the second hardware system carry out restart operation.

After the first hardware system receives the restart instruction, the first hardware system and the second hardware system are simultaneously restarted, and the first hardware system and the second hardware system are upgraded in parallel.

However, if the second hardware system receives an installation failure result or an installation overtime result returned by the first hardware system according to the installation result query instruction, the first hardware system is abnormal at this time, and the second hardware system enters a failure processing logic and does not execute the subsequent installation process.

In particular, a method flow diagram of failure handling logic according to an installation phase in an embodiment is illustrated in FIG. 17; as shown in fig. 17, the failure processing logic for the installation state includes:

and S171, if the second OTA upgrade package is failed to be installed by the second hardware system, generating an installation state query instruction and sending the installation state query instruction to the first hardware system.

And if the second hardware system fails to be installed, directly entering failure processing logic. In this case, the failure handling logic comprises: the second hardware system generates an installation state query instruction to query the state of the first hardware system and judge whether the first hardware system is in an installation state or is installed completely.

And S172, when the second hardware system receives a result in the installation state returned by the first hardware system according to the installation state inquiry instruction, generating a waiting instruction, and waiting for the completion of the installation of the first hardware system.

And if the result returned by the first hardware system according to the installation state query instruction is the result in the installation state, the second hardware system generates a waiting instruction to wait for the first hardware system to finish installation and then return failure processing logic.

And S173, if the first OTA upgrade package is installed in the waiting time threshold according to the waiting instruction, the second hardware system generates an exit instruction and sends the exit instruction to the first hardware system to enable the first hardware system to enter an exit mode.

And if the second hardware system receives the installation finishing information returned by the first hardware system within the waiting time threshold, the second hardware system generates a proposed instruction at the moment, so that the first hardware system enters an exit mode. And after the first hardware system quits, the second hardware system releases the resources to restart the system and returns to the main system.

For example, the latency threshold may be set to 20min, and in 20min, the first hardware system completes installation of the first OTA upgrade package and enters the exit mode.

And if the first hardware system is still not installed successfully within 20min, the first hardware system is failed to be installed, the second hardware system performs resource releasing restart operation, returns to the main system, and ends the upgrade operation.

And if the first hardware system is installed, directly returning to the failure processing logic, namely, the second hardware system sends an exit instruction to the first hardware system to enable the first hardware system to enter an exit mode, and after the second hardware system exits from the first hardware system, releasing resources to restart and returning to the main system.

In another embodiment, another failure handling logic for installation state includes:

and if the second OTA upgrade package is successfully installed by the second hardware system, generating an installation state query instruction, and sending the installation state query instruction to the first hardware system to query the state of the first hardware system and judge whether the first hardware system is in an installation state or is installed completely.

And if the first hardware system is in the installation state, the second hardware system generates a waiting instruction, waits for the first hardware system to finish installation, and returns to the corresponding state after the first hardware system finishes installation. The waiting time is the same as the waiting time threshold provided in the above embodiment, and when the waiting time exceeds the waiting time threshold, it is determined that the first hardware system has failed to be installed, the second hardware system performs the resource releasing restart operation, returns to the main system, and ends the upgrade operation.

If the first hardware system is not in the installation state, namely the installation process is finished, the first OTA upgrade package of the first hardware system is successfully installed, and the first hardware system is successfully upgraded.

The difference between the failure processing logic in the verification stage and the failure processing logic in the installation stage is that, in consideration of the actual verification situation, the verification waiting time is determined to exceed 5min, and then the verification is determined to be failed, that is, in the verification stage, the total retry time for the second hardware system to re-acquire the verification result of the first hardware system cannot exceed 5 min.

When the dual system installs the corresponding OTA upgrade package simultaneously, the first hardware system and the second hardware system have their own installation progress respectively, and this embodiment adopts a unified progress bar to show the installation progress of the first hardware system and the second hardware system simultaneously.

Specifically, the method provided by this embodiment, when performing dual-system parallel installation, further includes:

in the process of installing the first OTA upgrade package on the first hardware system and installing the second OTA upgrade package on the second hardware system, the installation progress of the first hardware system and the installation progress of the second hardware system are displayed on the same progress bar, and the progress bar is displayed by the second hardware system.

Because the dual systems share one display screen, and the display of the display screen is controlled by the second hardware system. And when the installation progress of the first hardware system and the installation progress of the second hardware system are simultaneously displayed by utilizing one progress bar, distributing the progress value of the progress bar to the first hardware system and the second hardware system. The total progress data of the progress bar is 0-100, wherein the odd number shows the installation progress of the first hardware system (system A), and the even number shows the installation progress of the second hardware system (system N).

Under this setting, the logic of the update progress value of the progress bar is as follows:

and recording the progress value of the current progress bar as percent. The next progress value is shown as next _ percent + 1.

And if the next _ percentage is an odd number, acquiring the installation progress from the system A (a first hardware system), and if the acquired progress value is not less than the next _ percentage, updating the next _ percentage to a progress bar for displaying. If the next _ percentage is larger than the installation progress acquired by the system A (the first hardware system), waiting and circularly acquiring the progress of the system A at the position until the installation progress of the system A is not smaller than the next _ percentage, and updating the display of the progress bar. If the system A has a problem, the progress bar is always blocked, and the currently displayed progress value is percentage, which is the progress already executed by the system N. It can be determined that the system a is out of order at this time based on the progress display showing an even number.

Similarly, if the next _ percentage is an even number, the system progress is obtained from the system N (the second hardware system), and if the obtained progress value is not less than the next _ percentage, the next _ percentage is updated to the progress bar for displaying. If the next _ percentage is larger than the installation progress acquired by the system N, waiting and circularly acquiring the progress of the system N at the position until the installation progress of the system N is not smaller than the next _ percentage, and updating the display of the progress bar. If the system N is in a problem, the progress bar is always blocked, and the currently displayed progress value is percentage, which is the progress already executed by the system A. It can be determined that the system N is out of order at this time based on the odd number of progress indicators.

FIG. 18 is a data flow diagram that illustrates a progress bar display in accordance with an embodiment; that is, as shown in fig. 18, the progress bar on the second hardware system obtains the installation progress of the first hardware system and the installation progress of the second hardware system, and then performs even-numbered operation and odd-numbered operation, and then compares the values of the two installation progresses, and displays the smaller installation progress. Therefore, after the system at one end fails to be installed, the system which is possibly wrong currently can be known through the progress value displayed by the progress bar, if the system is stuck at 45%, the situation that the installation progress of the system N (a second hardware system) is not transmitted all the time is shown, and the installation failure of the N end is indicated.

Specifically, a flowchart of a method of progress bar display according to an embodiment is illustrated in fig. 19; as shown in fig. 19, the display manner of the progress bar includes:

and S191, if the target progress value required to be displayed by the progress bar is an odd number, checking the installation progress of the first hardware system by the progress bar.

The progress values to be displayed on the progress bar comprise odd numbers and even numbers, and corresponding installation progress is updated on the progress bar in real time along with the installation of the first hardware system and the second hardware system.

If the progress bar needs to display odd numbers at the current moment, at the moment, the progress bar acquires the installation progress of the first hardware system, and whether the installation progress of the first hardware system reaches a target progress value is judged, namely whether the installation progress of the first hardware system is larger than or equal to the target progress value is judged.

If the installation progress of the first hardware system is larger than or equal to the target progress value, the installation progress of the first hardware system is faster than the progress value required to be displayed by the progress bar, and at the moment, the target progress value can be displayed on the progress bar.

If the installation progress of the first hardware system is not larger than or equal to the target progress value, namely the installation progress of the first hardware system is smaller than the target progress value, the installation progress of the first hardware system is slower than the progress value needing to be displayed by the progress bar, the progress bar is needed to wait for installation of the first hardware system at the moment, the installation progress is checked in a circulating mode, and once the installation progress of the first hardware system is larger than or equal to the target progress value, the target progress value is displayed on the progress bar.

And S192, when the installation progress of the first hardware system reaches the target progress value, displaying the target progress value on the progress bar.

Therefore, when the installation progress of the first hardware system is greater than or equal to the target progress value, the target progress value can be directly displayed on the progress bar.

For example, if the target progress value that the progress bar needs to display is 15%, at this time, if the acquired installation progress of the first hardware system is 16%, 15% may be displayed on the progress bar; if the obtained installation progress of the first hardware system is 10%, the progress bar needs to wait and circularly obtain the real-time installation progress of the first hardware system, and the installation progress of the first hardware system is not displayed on the progress bar by 15% until the installation progress of the first hardware system rises from 10% to 15% or more.

And S193, if the target progress value required to be displayed by the progress bar is an even number, checking the installation progress of the second hardware system by the progress bar.

And if the progress bar needs to display an even number at the current moment, acquiring the installation progress of the second hardware system by the progress bar, and judging whether the installation progress of the second hardware system reaches a target progress value, namely whether the installation progress of the second hardware system is greater than or equal to the target progress value.

If the installation progress of the second hardware system is greater than or equal to the target progress value, it is indicated that the installation progress of the second hardware system is faster than the progress value required to be displayed by the progress bar, and at this time, the target progress value can be displayed on the progress bar.

If the installation progress of the second hardware system is not larger than or equal to the target progress value, namely the installation progress of the second hardware system is smaller than the target progress value, the installation progress of the second hardware system is slower than the progress value needing to be displayed by the progress bar, the progress bar is needed to wait for installation of the second hardware system at the moment, the installation progress is checked in a circulating mode, and once the installation progress of the second hardware system is larger than or equal to the target progress value, the target progress value is displayed on the progress bar.

And S194, when the installation progress of the second hardware system reaches the target progress value, displaying the target progress value on the progress bar.

Therefore, when the installation progress of the second hardware system is greater than or equal to the target progress value, the target progress value may be directly displayed on the progress bar.

For example, if the target progress value that the progress bar needs to display is 20%, at this time, if the obtained installation progress of the second hardware system is 23%, 20% may be displayed on the progress bar; if the obtained installation progress of the second hardware system is 17%, the progress bar needs to wait and circularly obtain the real-time installation progress of the second hardware system, and the real-time installation progress of the second hardware system is not displayed on the progress bar for 20% until the installation progress of the second hardware system rises from 17% to 20% or more.

When the installation progress of the first hardware system or the second hardware system does not reach the target progress value, the progress bar needs to wait and circularly acquire the real-time installation progress of the first hardware system or the second hardware system, if the installation progress acquired in real time reaches the target progress value, the target progress value can be directly displayed, but if the progress bar still does not acquire the real-time installation progress meeting the display condition of the target progress value, the method of the embodiment further comprises the following steps:

s1101, if the installation progress of the first hardware system does not reach the target progress value, waiting for a period of time, and then checking the installation progress of the first hardware system.

S1102, if the progress bar does not acquire the installation progress of the first hardware system within the waiting time threshold, judging that the first hardware system is abnormally installed.

And when the installation progress of the first hardware system is smaller than the target progress value, the progress bar waits for and circularly acquires the real-time installation progress of the first hardware system. If the progress bar still does not obtain the new installation progress within the waiting time threshold, namely the progress bar is always clamped on an even number, the fact that the first hardware system is installed abnormally is indicated.

For example, if the currently displayed numerical value of the progress bar is 20% and the target progress value thereof is 21%, the progress bar acquires the installation progress of the first hardware system in real time. If the progress bar always displays the value of 20% and is still, it indicates that the progress bar does not acquire the installation progress of the first hardware system all the time, and the progress bar cannot display the value of 21%, so that it indicates that the first hardware system is abnormal.

The progress value displayed by the progress bar is mainly the slowest installation speed in the first hardware system or the second hardware system, the progress value which can be seen on the progress bar is the installation progress which is finished by the system corresponding to the progress value, and if the next progress value can not be seen at all, the system corresponding to the unseen progress value is abnormal. Because the displayed numerical values of the progress bar are continuous and cannot be skipped, the system which is abnormally installed can be accurately judged according to the duration of a certain numerical value displayed on the progress bar. When the abnormal system is judged, the corresponding failure processing logic in the installation stage can be executed to correspondingly operate the first hardware system and the second hardware system so as to finish the upgrading process as soon as possible and avoid causing more time waste.

As can be seen from the foregoing technical solutions, the dual-system OTA parallel upgrading method provided in the embodiment of the present invention includes: after the first hardware system and the second hardware system simultaneously enter the Recovery mode, synchronously enter the verification mode, namely the first hardware system verifies the first OTA upgrade package and the second hardware system verifies the second OTA upgrade package. After the verification is completed, the second hardware system generates an installation instruction and sends the installation instruction to the first hardware system, so that the first hardware system and the second hardware system synchronously enter an installation mode, and the second hardware system also installs the second OTA upgrade package while the first hardware system installs the first OTA upgrade package. And when the installation is finished, the first hardware system and the second hardware system are synchronously restarted. Therefore, the method provided by the implementation can realize the OTA parallel upgrade of the dual systems, and the dual systems can simultaneously enter the verification mode, synchronously enter the installation mode and restart at the same time, so that the upgrade efficiency of the dual systems is improved, the upgrade time is not prolonged, and the user experience is improved.

Fig. 20 is a block diagram illustrating an architecture of a dual-system OTA parallel upgrade system according to an embodiment.

As shown in fig. 20, an embodiment of the present invention provides a dual-system OTA parallel upgrade system, configured to execute the dual-system OTA parallel upgrade method shown in fig. 10 to fig. 19, where the system includes: the system comprises a first hardware system and a second hardware system, wherein the second hardware system is connected with the first hardware system through a serial port or a network cable; the first hardware system and the second hardware system are respectively configured to perform the following steps: under the condition that the first hardware system and the second hardware system simultaneously enter a Recovery mode, the first hardware system verifies the first OTA upgrade package, and the second hardware system verifies the second OTA upgrade package; the first OTA upgrade package is used for upgrading a first hardware system, and the second OTA upgrade package is used for upgrading a second hardware system; under the condition that the first hardware system and the second hardware system are verified successfully respectively, the second hardware system generates an installation instruction and sends the installation instruction to the first hardware system; according to the installation instruction, the first hardware system starts to be installed according to a first OTA upgrade package, and the second hardware system starts to be installed according to a second OTA upgrade package; under the condition that the first hardware system and the second hardware system are installed successfully respectively, the second hardware system generates a restart instruction and sends the restart instruction to the first hardware system; and according to the restart instruction, the first hardware system and the second hardware system carry out restart operation.

Optionally, the first hardware system and the second hardware system are further configured to perform the following steps, respectively: according to the upgrading instruction, the first hardware system and the second hardware system write upgrading marks respectively; restarting the first hardware system and the second hardware system according to the upgrading mark, wherein the first hardware system and the second hardware system respectively enter a Recovery mode; after the second hardware system enters a Recovery mode, sending a query instruction to the first hardware system; the query instruction is used for querying whether the first hardware system successfully enters a Recovery mode; and if the second hardware system receives a successful entering result returned by the first hardware system according to the query instruction, the first hardware system verifies the first OTA upgrading packet, and the second hardware system verifies the second OTA upgrading packet.

Optionally, the first hardware system and the second hardware system are further configured to perform the following steps, respectively: if the second hardware system receives an unsuccessful entry result returned by the first hardware system according to the query instruction, querying whether the first hardware system has an OTA upgrade patch of the current version; if the instruction does not exist, the second hardware system generates an exit instruction and sends the exit instruction to the first hardware system, so that the first hardware system and the second hardware system exit the Recovery mode; if yes, sending a BCB information writing instruction to the first hardware system; receiving a BCB information writing success result returned by the first hardware system according to the BCB information writing instruction, and sending a restarting instruction to the first hardware system so that the first hardware system is restarted after the BCB information is written in; after the first hardware system is restarted, the second hardware system generates a new query instruction, sends the new query instruction to the first hardware system and queries whether the first hardware system successfully enters a Recovery mode; and if the second hardware system receives a successful entering result returned by the first hardware system according to the new query instruction, the first hardware system verifies the first OTA upgrading packet, and the second hardware system verifies the second OTA upgrading packet.

Optionally, the first hardware system and the second hardware system are further configured to perform the following steps, respectively: judging whether the first hardware system verifies the first OTA upgrade package, and whether the second hardware system verifies the second OTA upgrade package; if the second hardware system successfully verifies the second OTA upgrade package and the first hardware system completes the verification of the first OTA upgrade package, the second hardware system and the first hardware system respectively enter a synchronization mode; in the synchronous mode, the second hardware system generates a checking result query instruction and sends the checking result query instruction to the first hardware system; and if the second hardware system receives a verification success result returned by the first hardware system according to the verification result query instruction, the second hardware system generates an installation instruction and sends the installation instruction to the first hardware system.

Optionally, the first hardware system and the second hardware system are further configured to perform the following steps, respectively: if the second hardware system fails to verify the second OTA upgrade package, generating a verification state query instruction and sending the verification state query instruction to the first hardware system; and when the second hardware system receives a result in the check state returned by the first hardware system according to the check state query instruction, generating an exit instruction, and sending the exit instruction to the first hardware system to enable the first hardware system to enter an exit mode.

Optionally, the first hardware system and the second hardware system are further configured to perform the following steps, respectively: judging whether the installation process of installing the second OTA upgrade package by the second hardware system is successful or not, and whether the installation process of installing the first OTA upgrade package by the first hardware system is completed or not; if the second hardware system successfully installs the second OTA upgrade package and the first hardware system completes the installation of the first OTA upgrade package, the second hardware system and the first hardware system respectively enter a synchronization mode; in the synchronous mode, the second hardware system generates an installation result query instruction and sends the installation result query instruction to the first hardware system; if the second hardware system receives an installation success result returned by the first hardware system according to the installation result query instruction, an exit instruction is generated and sent to the first hardware system; and according to the exit instruction, after the first hardware system and the second hardware system enter an exit mode, the second hardware system generates a restart instruction and sends the restart instruction to the first hardware system.

Optionally, the first hardware system and the second hardware system are further configured to perform the following steps, respectively: if the second hardware system fails to install the second OTA upgrade package, generating an installation state query instruction, and sending the installation state query instruction to the first hardware system; when the second hardware system receives a result in the installation state returned by the first hardware system according to the installation state query instruction, generating a waiting instruction and waiting for the completion of the installation of the first hardware system; and if the first hardware system finishes the installation of the first OTA upgrade package within the waiting time threshold according to the waiting instruction, the second hardware system generates an exit instruction and sends the exit instruction to the first hardware system, so that the first hardware system enters an exit mode.

Optionally, the first hardware system and the second hardware system are further configured to perform the following steps, respectively: and in the process of installing the second OTA upgrade package by the second hardware system, the installation progress of the first hardware system and the installation progress of the second hardware system are displayed on the same progress bar, and the progress bar is displayed by the second hardware system.

Optionally, the first hardware system and the second hardware system are further configured to perform the following steps, respectively: if the target progress value required to be displayed by the progress bar is an odd number, checking the installation progress of the first hardware system by the progress bar; when the installation progress of the first hardware system reaches a target progress value, displaying the target progress value on the progress bar; if the target progress value required to be displayed by the progress bar is an even number, checking the installation progress of a second hardware system by the progress bar; and when the installation progress of the second hardware system reaches a target progress value, displaying the target progress value on the progress bar.

Optionally, the first hardware system and the second hardware system are further configured to perform the following steps, respectively: if the installation progress of the first hardware system does not reach the target progress value, waiting for a period of time, and then checking the installation progress of the first hardware system; and within the waiting time threshold, if the progress bar does not acquire the installation progress of the first hardware system, judging that the first hardware system is abnormally installed.

In specific implementation, the present invention further provides a computer storage medium, where the computer storage medium may store a program, and the program may include some or all of the steps in the embodiments of the dual-system OTA parallel upgrade method provided by the present invention when executed. The storage medium may be a magnetic disk, an optical disk, a read-only memory (ROM) or a Random Access Memory (RAM).

Those skilled in the art will readily appreciate that the techniques of the embodiments of the present invention may be implemented as software plus a required general purpose hardware platform. Based on such understanding, the technical solutions in the embodiments of the present invention may be essentially or partially implemented in the form of a software product, which may be stored in a storage medium, such as ROM/RAM, magnetic disk, optical disk, etc., and includes several instructions for enabling a computer device (which may be a personal computer, a server, or a network device, etc.) to execute the method according to the embodiments or some parts of the embodiments.

The same and similar parts among the various embodiments in this specification may be referred to each other. Especially, for the system embodiment of the dual-system OTA parallel upgrade, since it is basically similar to the method embodiment, the description is simple, and the relevant points can be referred to the description in the method embodiment.

The method for restoring factory settings in parallel by using dual systems provided by the embodiment of the application is applied to the display device 200 with a dual system architecture. When factory settings are restored to the terminal equipment, in order to avoid prolonging the time for clearing data, the factory settings need to be restored to the two systems in parallel.

The dual system in this embodiment includes a first hardware system 310 and a second hardware system 210, and a related component for implementing factory setting restoration is set in the second hardware system, and the first hardware system does not have any component related to factory setting restoration. Therefore, in order to achieve parallel factory restoration of the two systems, in this embodiment, the second hardware system is used as an active communication party, and the second hardware system invokes the first hardware system to restore the factory settings.

Fig. 21 is a flowchart illustrating a factory reset trigger according to an embodiment. As shown in fig. 21, the instruction for the second hardware system to execute factory reset is triggered by the user, and the user calls a system setting menu located in the second hardware system through a remote controller 100A matched with the terminal device, then selects a factory reset option of the user, and enters a data clearing process, so as to start a data clearing module in the second hardware system.

The method provided by the embodiment adopts two modes of network and serial port to carry out communication, preferentially selects the network under normal conditions, and uses the serial port to carry out communication under the condition that the network cannot be normally connected. In the communication processing process, the second hardware system is an active communication party and informs the first hardware system of executing a response command and a synchronous state through a command mode and an inquiry mode respectively.

Fig. 22 is a block diagram illustrating a system for restoring factory settings in parallel in dual systems according to an embodiment. To implement the communication between the two systems and the individual clear data process of each system, as shown in fig. 22, the first hardware system 310 includes a first hardware system clear data module 3101 for performing clear data operation on the first hardware system and a first hardware system communication module 3102 for implementing the communication between the first hardware system and the second hardware system. Similarly, the second hardware system 210 includes a second hardware system clearing data module 2101 and a second hardware system communication module 2102, where the second hardware system clearing data module is configured to perform a data clearing operation on the second hardware system, and the second hardware system communication module is configured to implement communication between the second hardware system and the first hardware system.

After the second hardware system data clearing module receives the factory reset command, the second hardware system communication module notifies the first hardware system, the second hardware system communication module performs information interaction with the first hardware system communication module, and the first hardware system communication module starts the first hardware system data clearing module to execute data clearing operation of the first hardware system, so that the data can be cleared in parallel by the two systems, and the time for clearing the data is not prolonged.

In order to better describe the parallel factory restoration setting of the first hardware system and the second hardware system, a detailed description is given below for an implementation process of each module, that is, a specific process of the method for parallel factory restoration of dual systems provided in the embodiment of the present application.

Fig. 23 is a flowchart illustrating a method for factory settings restoration in parallel by two systems according to an embodiment; FIG. 24 is a timing flow diagram illustrating a method for dual system parallel factory reset in accordance with an embodiment; referring to fig. 23 and fig. 24, the method for restoring factory settings in parallel by using dual systems according to the embodiment of the present application is applied to a second hardware system communication module, where the second hardware system communication module is configured to receive an instruction of clearing a data module by using a second hardware system, and communicate with a first hardware system communication module. Specifically, the method for restoring factory settings in parallel by using dual systems provided by the embodiment of the present application includes the following steps:

S211, receiving a starting instruction sent by a second hardware system data clearing module in a second hardware system; the starting instruction refers to an instruction generated by the second hardware system data clearing module according to the received factory reset instruction.

After the second hardware system receives a factory reset instruction triggered by a user, a data clearing module of the second hardware system executes data clearing operation of the second hardware system, and in order to ensure parallel data clearing of the second hardware system and the first hardware system, the data clearing module of the second hardware system does not timely clear data operation of the second hardware system after receiving the factory reset instruction, but does not inform the first hardware system.

Therefore, the second hardware system data clearing module generates a starting instruction according to the factory reset instruction, and sends the starting instruction to the second hardware system communication module, so that the second hardware system communication module communicates with the first hardware system communication module in the first hardware system.

S212, according to the starting instruction, a starting clearing instruction is generated and sent to a first hardware system communication module of the first hardware system, so that the first hardware system clearing data module is started through the first hardware system communication module, and data clearing operation is conducted on the first hardware system.

The starting instruction carries a command parameter for starting to clear data, so that after the second hardware system data clearing module starts the second hardware system communication module according to the starting instruction, the second hardware system communication module generates a clearing starting instruction, and communicates with the first hardware system communication module of the first hardware system, so that the first hardware system communication module starts the first hardware system data clearing module, and the first hardware system is subjected to data clearing operation.

After the first hardware system data clearing module is started, the second hardware system and the first hardware system are indicated to be successfully communicated, and in the data clearing process, the first hardware system and the second hardware system can realize real-time communication.

And S213, receiving a starting result of the first hardware system data clearing module returned by the first hardware system communication module, and sending the starting result to the second hardware system data clearing module so as to clear data of the second hardware system.

In the method provided by this embodiment, after the second hardware system notifies the first hardware system to perform the data clearing operation according to the factory reset instruction, the second hardware system performs the data clearing operation again. Therefore, the second hardware system only carries out the data clearing operation after receiving the starting result returned by the first hardware system.

After receiving a clearing start instruction sent by the second hardware system communication module, the first hardware system communication module immediately starts the first hardware system data clearing module to clear data of the first hardware system, and simultaneously sends a starting result to the second hardware system communication module to inform the second hardware system data clearing module to clear data of the second hardware system.

Therefore, in this embodiment, the time of receiving the start result of the first hardware system data clearing module returned by the first hardware system communication module is the same as the time of the first hardware system data clearing module started by the first hardware system communication module, and the second hardware system is notified to perform the data clearing operation in time, so as to shorten the time of data clearing.

S214, under the condition that the data clearing operation of the second hardware system is completed, the data clearing result of the first hardware system sent by the first hardware system communication module is obtained according to the query instruction sent by the data clearing module of the second hardware system.

And after the second hardware system data clearing module receives the starting result of the first hardware system data clearing module returned by the second hardware system communication module, the second hardware system data clearing module immediately clears data of the second hardware system. And when the second hardware system finishes the data clearing operation, generating a query instruction and sending the query instruction to the second hardware system communication module.

The query instruction is used for checking a data clearing result of the first hardware system, wherein the data clearing result comprises a completed state and an uncompleted state, so that the second hardware system is restarted under the condition that the second hardware system and the first hardware system complete data clearing operation, and the factory setting recovery process is completed.

The second hardware system communication module sends the query instruction to the first hardware system communication module, the first hardware system communication module queries the data clearing result of the first hardware system data clearing module, and the first hardware system communication module returns the data clearing result to the second hardware system communication module.

And the data clearing result is used for indicating the data clearing progress of the first hardware system, and the system is restarted only after the first hardware system and the second hardware system complete data clearing operation.

S215, sending the data clearing result to the data clearing module of the second hardware system, and restarting the second hardware system and the first hardware system under the condition that the data clearing module of the second hardware system judges that the data clearing result is in a finished state, so that factory restoration settings of the second hardware system and the first hardware system are finished.

And the second hardware system communication module sends the data clearing result to the second hardware system data clearing module, in order to ensure the synchronization of the second hardware system and the first hardware system, the second hardware system data clearing module judges the completion condition of the data clearing result, if the state indicated by the data clearing result is a completion state, the first hardware system finishes the data clearing operation, and at the moment, the step of restarting the system can be executed. If the status indicated by the result of clearing data is an unfinished status, which indicates that the first hardware system has not finished clearing data operation, the system cannot be restarted at this time.

Therefore, in order to ensure that the second hardware system and the first hardware system are restored to the factory settings in parallel, when the factory settings are restored by triggering the second hardware system, in order to simultaneously clear the data of the second hardware system and the first hardware system, in this embodiment, only when the data clearing result of the second hardware system is judged to be in the complete state by the data clearing module, the second hardware system and the first hardware system are restarted, and the factory settings are restored to the second hardware system and the first hardware system.

In specific implementation, the first hardware system is not provided with a component related to factory setting restoration, and the first hardware system also does not have a self-restarting function. Therefore, in this embodiment, the restart of the first hardware system is started by the second hardware system, that is, after the second hardware system and the first hardware system both complete the data clearing operation, the second hardware system is restarted, and a restart instruction is generated by the second hardware system and sent to the first hardware system to notify the first hardware system that the restart operation is completed, so that the factory reset of the second hardware system and the first hardware system is completed immediately.

If the second hardware system data clearing module determines that the data clearing result is an incomplete state, the first hardware system needs to wait for continuing the data clearing operation, and therefore, the method for restoring factory settings in parallel by using dual systems, provided by the embodiment of the present application, further includes:

s231, receiving a waiting instruction sent by a second hardware system data clearing module; the wait instruction refers to an instruction sent by the second hardware system data clearing module when the data clearing result is judged to be in an incomplete state.

And the second hardware system data clearing module generates a waiting instruction and sends the waiting instruction to the second hardware system communication module under the condition that the data clearing result is judged to be in an unfinished state.

The wait instruction is used for informing the first hardware system communication module to return a data clearing result after waiting for a period of time.

S232, sending the waiting instruction to the first hardware system communication module, so that the first hardware system communication module waits for the data clearing process of the first hardware system until the data clearing result returned by the data clearing module of the first hardware system is in a finished state, and acquiring the current data clearing result.

And the second hardware system communication module sends the waiting instruction to the first hardware system communication module, the first hardware system communication module waits for a period of time and returns a data clearing result of the first hardware system data clearing module until the data clearing result is in a finished state.

And the current data clearing result is used for indicating the result that the first hardware system data clearing module finishes the data clearing operation after waiting for a period of time.

And S233, sending the current data clearing result returned by the second hardware communication module to the second hardware system data clearing module so as to restart the second hardware system and the first hardware system, and completing factory restoration setting of the second hardware system and the first hardware system.

And sending the current data clearing result to a data clearing module of the second hardware system, restarting the second hardware system by the data clearing module of the second hardware system when the first hardware system finishes data clearing operation, and then transferring the first hardware system by the second hardware system to restart, thereby finishing factory resetting of the second hardware system and the first hardware system.

Fig. 25 is a flowchart illustrating a method for dual system parallel factory reset according to another embodiment. Referring to fig. 25, the method for restoring factory settings of dual systems provided in the embodiment of the present application is applied to a first hardware system communication module. Because the first hardware system does not have the factory resetting function, the factory resetting of the first hardware system needs to be transferred by the second hardware system, that is, the first hardware system communication module is used for receiving a clearing start instruction sent by the second hardware system communication module, communicating with the second hardware system communication module, and transferring the first hardware system clearing data module to clear data of the first hardware system. Specifically, the method for restoring factory settings in parallel by using dual systems provided by the embodiment of the present application includes the following steps:

S221, acquiring a clearing starting instruction sent by a second hardware system communication module in the second hardware system.

The first hardware system cannot receive a factory resetting instruction triggered by a user by itself, but needs the second hardware system to transfer, so that the first hardware system communication module receives a clearing starting instruction sent by the second hardware system communication module.

And the start clearing instruction is generated by the second hardware system communication module according to the starting instruction of the second hardware system data clearing module, and the start clearing instruction is used for realizing that the first hardware system communication module starts the first hardware system data clearing module.

S222, according to the clearing starting instruction, starting a first hardware system data clearing module in the first hardware system, and carrying out data clearing operation on the first hardware system through the first hardware system data clearing module.

The first hardware system communication module can start a first hardware system data clearing module in the first hardware system according to the clearing starting instruction, and immediately starts data clearing operation on the first hardware system after the first hardware system data clearing module is started.

In order to ensure that the first hardware system and the second hardware system are restored to factory settings in parallel, the method provided in this embodiment immediately returns the start result when the first hardware system data clearing module is started to perform data clearing operation on the first hardware system, and the second hardware system is notified to perform data clearing operation.

Therefore, the method provided by the embodiment further includes: and sending a starting result of the first hardware system data clearing module to the second hardware system communication module while starting the first hardware system data clearing module according to the clearing starting instruction so as to start the second hardware system data clearing module to clear data of the second hardware system through the second hardware system communication module.

The first hardware system communication module starts the first hardware system data clearing module and simultaneously returns a starting result to the second hardware system communication module, and the second hardware system communication module sends the starting result to the second hardware system data clearing module, so that when the first hardware system data clearing module clears the first hardware system, the second hardware system data clearing module can also clear data of the second hardware system in time, the parallel data clearing process of the two systems is guaranteed, and the data clearing time is shortened.

And S223, receiving a data clearing result returned by the data clearing module of the first hardware system.

When the first hardware system data clearing module clears data of the first hardware system, the data clearing result of the first hardware system is fed back to the first hardware system communication module in real time, and the data clearing result is used for indicating the progress of clearing data.

And the first hardware system communication module stores the data clearing result returned by the first hardware system data clearing module after receiving the data clearing result, and updates the current data clearing result in real time, so that the second hardware system can know the data clearing progress of the first hardware system.

And S224, sending the data clearing result to the second hardware system data clearing module through the second hardware system communication module according to the query instruction sent by the second hardware system communication module, and restarting the first hardware system and the second hardware system by the second hardware system data clearing module under the condition that the data clearing result is judged to be in a finished state, so that factory restoration setting of the first hardware system and the second hardware system is finished.

The query instruction is used for checking the data clearing result of the first hardware system, and the query instruction is generated by the data clearing module of the second hardware system according to the data clearing result of the first hardware system, namely the query instruction is generated when the data clearing result of the first hardware system is in a finished state.

After the data clearing operation of the second hardware system is completed, the data clearing module of the second hardware system can inquire the data clearing progress of the first hardware system so as to restart the first hardware system and the second hardware system after the data clearing operation of the first hardware system and the second hardware system is completed.

Specifically, in this embodiment, sending the data clearing result to the second hardware system data clearing module through the second hardware system communication module according to the query instruction sent by the second hardware system communication module includes:

s271, receiving a query instruction sent by the second hardware system communication module; the query instruction is an instruction sent by the second hardware system data clearing module to the second hardware system communication module;

and S272, sending the data clearing result returned by the first hardware system data clearing module to the second hardware system communication module according to the query instruction, and sending the data clearing result to the second hardware system data clearing module by the second hardware system communication module.

The second hardware system data clearing module sends the query instruction to the first hardware system communication module through the second hardware system communication module, and the first hardware system communication module returns the stored data clearing result to the second hardware system communication module according to the query instruction, so that the second hardware system data clearing module can judge the data clearing result.

In this embodiment, only when the second hardware system data clearing module determines that the data clearing result is in the complete state, the second hardware system and the first hardware system are restarted to complete factory restoration settings of the second hardware system and the first hardware system.

Because the first hardware system does not have the function of self-restarting and needs to be informed of the first hardware system to restart by the second hardware system, in order to ensure that factory-restoration setting is completed after the data is cleared in parallel of the two systems, the second hardware system is restarted under the condition that the data clearing result is judged to be in a completed state by the second hardware system data clearing module, and meanwhile, the first hardware system is transferred to restart through the second hardware system communication module and the first hardware system communication module, so that factory-restoration setting of the first hardware system and the second hardware system is completed immediately.

s261, receiving a waiting instruction sent by the second hardware system communication module; the wait instruction is an instruction sent by the second hardware system clearing data module to the second hardware system communication module when the clearing data result is in an incomplete state.

If the first hardware system does not finish the data clearing operation, if the system is restarted at the moment, the performance of the first hardware system is affected, and therefore, in order to guarantee the performance of the system, when the system is required to be restarted, the first hardware system and the second hardware system are both in a state of finishing data clearing.

And the second hardware system data clearing module generates a waiting instruction and sends the waiting instruction to the second hardware system communication module under the condition that the data clearing result is judged to be in an unfinished state. The wait instruction is used for informing the first hardware system communication module to return a data clearing result after waiting for a period of time.

And S262, waiting for the data clearing process of the first hardware system according to the waiting instruction until the data clearing result returned by the data clearing module of the first hardware system is in a finished state, and sending the current data clearing result to the communication module of the second hardware system.

After receiving the waiting instruction, the first hardware system communication module waits for a period of time and then returns a data clearing result of the first hardware system to the second hardware system communication module, so that the first hardware system is restarted after the data clearing process is finished.

And in the waiting time, the first hardware system data clearing module continues to clear data of the first hardware system and returns a data clearing result to the first hardware system communication module in real time. When the first hardware system finishes the data clearing operation, the current data result is in a finished state, and at the moment, the current data clearing result is sent to the second hardware system communication module, so that the second hardware system data clearing module can execute the operation of restarting the second hardware system according to the current data clearing result.

According to the technical scheme, the method for restoring the factory settings of the dual systems in parallel provided by the embodiment of the application comprises the following steps: the second hardware system data clearing module generates a starting instruction according to the received factory resetting instruction, sends the starting instruction to the second hardware system communication module, generates a clearing starting instruction according to the starting instruction by the second hardware system communication module, and starts the first hardware system data clearing module through the first hardware system communication module to clear data of the first hardware system; after the second hardware system data clearing module receives the starting result returned by the first hardware system communication module, the second hardware system data clearing module carries out data clearing operation on the second hardware system; under the condition that the data clearing operation of the second hardware system is completed, generating a query instruction to obtain a data clearing result of the first hardware system; and under the condition that the second hardware system data clearing module judges that the data clearing result is in a finished state, restarting the first hardware system and the second hardware system to finish the factory restoration setting of the first hardware system and the second hardware system. The method provided by the embodiment can realize the parallel data clearing of the first hardware system and the second hardware system, so as to shorten the time for restoring factory settings of the two systems.

As shown in fig. 22, a system for dual-system parallel factory reset according to an embodiment of the present application is configured to execute relevant steps of the method for dual-system parallel factory reset shown in fig. 23 and fig. 24, where the system includes: a first hardware system 310 and a second hardware system 210; the first hardware system 310 includes a first hardware system clearing data module 3101 and a first hardware system communication module 3102, and the second hardware system 210 includes a second hardware system clearing data module 2101 and a second hardware system communication module 2102; the first hardware system clearing data module 3101 is configured to perform a data clearing operation on the first hardware system 310 according to an instruction of the first hardware system communication module 3102, the first hardware system communication module 3102 is in communication with the second hardware system communication module 2102, and the second hardware system clearing data module 2101 is configured to perform a data clearing operation on the second hardware system 210; the second hardware system communication module 2102 is configured to: receiving a starting instruction sent by a second hardware system clearing data module in a second hardware system; the starting instruction refers to an instruction generated by the second hardware system data clearing module according to the received factory resetting instruction; generating a clearing starting instruction according to the starting instruction, and sending the clearing starting instruction to a first hardware system communication module of a first hardware system so as to start a first hardware system data clearing module through the first hardware system communication module and clear data of the first hardware system; receiving a starting result of a first hardware system data clearing module returned by the first hardware system communication module, and sending the starting result to a second hardware system data clearing module so as to clear data of the second hardware system; under the condition that the data clearing operation of the second hardware system is completed, acquiring a data clearing result of the first hardware system, which is sent by the first hardware system communication module, according to a query instruction sent by a data clearing module of the second hardware system; and sending the data clearing result to a second hardware system data clearing module, and restarting the first hardware system and the second hardware system to complete factory restoration setting of the first hardware system and the second hardware system under the condition that the second hardware system data clearing module judges that the data clearing result is in a finished state.

Optionally, the time for receiving the start result of the first hardware system data clearing module returned by the first hardware system communication module is the same as the time for the first hardware system communication module to start the first hardware system data clearing module.

Optionally, the second hardware system communication module is further configured to: receiving a waiting instruction sent by a second hardware system clearing data module; the waiting instruction is an instruction sent by the second hardware system data clearing module under the condition that the data clearing result is judged to be in an unfinished state; sending the waiting instruction to a first hardware system communication module, so that the first hardware system communication module waits for a data clearing process of a first hardware system, and acquiring a current data clearing result when the data clearing result returned by the data clearing module of the first hardware system is in a finished state; and sending the current data clearing result returned by the second hardware communication module to a second hardware system data clearing module so as to restart the first hardware system and the second hardware system and complete factory restoration setting of the first hardware system and the second hardware system.

As shown in fig. 22, a system for dual-system parallel factory reset provided in an embodiment of the present application is configured to execute relevant steps of the method for dual-system parallel factory reset shown in fig. 25, where the system includes: a first hardware system 310 and a second hardware system 210; the first hardware system 310 comprises a first hardware system clearing data module 3101 and a first hardware system communication module 3102, and the second hardware system 210 comprises a second hardware system clearing data module 2101 and a second hardware system communication module 2102; the first hardware system clearing data module 3101 is configured to perform a clearing data operation on the first hardware system 310 according to an instruction of the first hardware system communication module 3102, the first hardware system communication module 3102 is in communication with the second hardware system communication module 2102, and the second hardware system clearing data module 2101 is configured to perform a clearing data operation on the second hardware system 210; the first hardware system communication module 3102 is configured to: acquiring a clearing starting instruction sent by a second hardware system communication module in a second hardware system; starting a first hardware system data clearing module in a first hardware system according to the clearing starting instruction so as to clear data of the first hardware system through the first hardware system data clearing module; receiving a data clearing result returned by the data clearing module of the first hardware system; and sending the data clearing result to a second hardware system data clearing module through the second hardware system communication module according to the query instruction sent by the second hardware system communication module, so that the second hardware system data clearing module restarts the first hardware system and the second hardware system under the condition that the data clearing result is judged to be in a finished state, and the factory-leaving-restoration setting of the first hardware system and the second hardware system is finished.

Optionally, the first hardware system communication module is further configured to: and sending a starting result of the first hardware system data clearing module to a second hardware system communication module while starting the first hardware system data clearing module according to the clearing starting instruction so as to start the second hardware system data clearing module to clear data of the second hardware system through the second hardware system communication module.

Optionally, the first hardware system communication module is further configured to: receiving a waiting instruction sent by the second hardware system communication module; the waiting instruction refers to an instruction sent to a second hardware system communication module by the second hardware system data clearing module under the condition that the data clearing result is in an unfinished state; and waiting for the data clearing process of the first hardware system according to the waiting instruction until the data clearing result returned by the data clearing module of the first hardware system is in a finished state, and sending the current data clearing result to a communication module of a second hardware system.

Optionally, the first hardware system communication module is further configured to: receiving a query instruction sent by the second hardware system communication module; the query instruction is an instruction sent to the second hardware system communication module by the second hardware system data clearing module; and sending a data clearing result returned by the first hardware system data clearing module to a second hardware system communication module according to the query instruction, and sending the data clearing result to the second hardware system data clearing module by the second hardware system communication module.

In a specific implementation, the present application further provides a computer storage medium, where the computer storage medium may store a program, and the program may include some or all of the steps in each embodiment of the method for restoring factory settings in parallel by using dual systems provided by the present application when executed. The storage medium may be a magnetic disk, an optical disk, a read-only memory (ROM) or a Random Access Memory (RAM).

Those skilled in the art will readily appreciate that the techniques of the embodiments of the present application may be implemented as software plus any required general purpose hardware platform. Based on such understanding, the technical solutions in the embodiments of the present application may be substantially or partially embodied in the form of a software product, which may be stored in a storage medium, such as a ROM/RAM, a magnetic disk, an optical disk, or the like, and includes several instructions for enabling a computer device (which may be a personal computer, a server, or a network device) to execute the method according to the embodiments or some parts of the embodiments of the present application.

The same and similar parts in the various embodiments in this specification may be referred to each other. Especially, for the system embodiment of dual-system parallel factory reset, since it is basically similar to the method embodiment, the description is relatively simple, and reference may be made to the description in the method embodiment for relevant points.

When the dual systems are subjected to parallel factory setting restoration, under a normal condition, the second hardware system receives a factory setting restoration instruction and sends a clearing start instruction to the first hardware system, after the first hardware system starts clearing data, a starting result is returned to the second hardware system, and after the second hardware system receives the starting result, the second hardware system starts clearing data. In order to ensure that the two systems can restore factory settings in parallel, after the second hardware system finishes data clearing operation, an inquiry instruction is sent to the first hardware system to inquire the data clearing state of the first hardware system, and after the first hardware system finishes data clearing, a restart instruction is generated by the second hardware system and sent to the first hardware system, and the first hardware system and the second hardware system are restarted at the same time.

However, in the factory setting recovery process, the first hardware system starts a data clearing operation by the second hardware system, and the second hardware system needs to execute the next process under the condition that the first hardware system returns a normal result, so that the two systems are easy to be abnormal during interaction. For example, a first hardware system data clearing module in a first hardware system cannot be started to clear data of the first hardware system, or a first hardware system communication module cannot return a start result and a data clearing result of the first hardware system to a second hardware system communication module, which all affect the next operation of the second hardware system, and further affect the process of recovering factory settings of the dual systems in parallel.

When the display device with the dual-system architecture is used, third-party applications, media playing files and the like downloaded by a user are stored in the first hardware system, and if the first hardware system cannot clear data, the first hardware system is abnormal in use due to the fact that the first hardware system cannot be cleared for a long time. Therefore, when the dual systems are subjected to parallel factory reset, exception handling logic needs to be executed to ensure that the first hardware system and the second hardware system can normally complete data clearing operation, so that the parallel factory reset of the two systems is realized.

In the parallel factory setting restoration process, the second hardware system is an active communication party, so the exception handling logic is performed in the second hardware system.

FIG. 26 is a flow diagram that illustrates a method for handling a dual system parallel factory reset exception, according to an embodiment; as shown in fig. 26, a method for processing a factory setting exception through parallel dual systems according to an embodiment of the present invention includes the following steps:

and S31, generating a clearing starting instruction according to the received factory reset instruction.

And the second hardware system receives a factory reset instruction triggered by a user and then sends the factory reset instruction to the second hardware system data clearing module, the second hardware system data clearing module generates a starting instruction according to the factory reset instruction and sends the starting instruction to the second hardware system communication module, so that the second hardware system communication module is communicated with the first hardware system communication module in the first hardware system.

The starting instruction carries a command parameter for starting clearing data, and the second hardware system communication module generates a clearing starting instruction after starting the second hardware system communication module according to the starting instruction.

And S32, sending the clearing start instruction to the first hardware system communication module through the second hardware system communication module, so that the first hardware system communication module starts the first hardware system data clearing module to clear data of the first hardware system.

The second hardware system communication module is communicated with the first hardware system communication module of the first hardware system, and sends a clearing starting instruction to the first hardware system communication module, so that the first hardware system communication module starts the first hardware system data clearing module and clears data of the first hardware system.

And S33, retrying the process of the first hardware system communication module starting the first hardware system data clearing module under the condition that the second hardware system communication module cannot receive the starting result of the first hardware system communication module returned by the first hardware system communication module.

The first hardware system data clearing module immediately clears the data of the first hardware system according to the clearing starting instruction, and simultaneously sends a starting result to the second hardware system communication module to inform the second hardware system data clearing module of clearing the data of the second hardware system.

However, if the first hardware system is abnormal, for example, the first hardware system cannot be started to clear the data module according to the clear start instruction, or the first hardware system communication module cannot return the start result to the second hardware system communication module, at this time, the first hardware system needs to be processed by using the exception handling logic to ensure that the first hardware system can perform the data clearing operation normally.

In this embodiment, when the second hardware system data clearing module cannot receive the start result returned by the first hardware system communication module to the first hardware system through the second hardware system communication module, the adopted exception handling logic is a retry mechanism, that is, the first hardware system data clearing module is started again by the first hardware system communication module according to the start clearing instruction, so as to retry.

And S34, if the starting result of the first hardware system returned by the first hardware system communication module is received by the second hardware system communication module within the threshold of the retry times, performing data clearing operation on the second hardware system, and performing data clearing operation on the first hardware system by the first hardware system data clearing module.

In order to ensure that factory restoration can be performed in a short time, when an abnormal condition that a starting result cannot be obtained is retried, a threshold value of the retry time needs to be set, namely within the threshold value of the retry time, the second hardware system clearing data can receive the starting result returned by the first hardware system communication module to the first hardware system, so that the first hardware system clearing data module immediately clears the first hardware system while being started, and the second hardware system clearing data module also immediately clears the second hardware system after receiving the starting result.

In this embodiment, the threshold of the retry number may be set to 10 times, and the specific set number may be determined according to the actual application environment, which is not specifically limited in this embodiment.

And after the second hardware system clears the data, the second hardware system clears the data to obtain a result returned by the first hardware system communication module once again, if the second hardware system clears the data after retrying for a plurality of times of starting, namely the number of times of retrying is within 10 times, the second hardware system can receive the starting result returned by the first hardware system communication module, and the starting result shows that the first hardware system is successfully started, so that the data clearing operation can be carried out.

However, if the second hardware system cannot receive the start result of the first hardware system returned by the first hardware system communication module after the retry of the multiple start, that is, the retry exceeds 10 times, which indicates that the first hardware system fails to clear the data, at this time, the data clearing operation of the second hardware system is exited, and the parallel factory resetting process of the first hardware system and the second hardware system is stopped.

And S35, restarting the first hardware system and the second hardware system after finishing the data clearing operation.

And under the condition that the second hardware system data clearing module finishes the data clearing operation of the second hardware system, the second hardware system data clearing module generates a query instruction, sends the query instruction to the second hardware system communication module, and then sends the query instruction to the first hardware system communication module through the second hardware system communication module so as to query the data clearing result of the first hardware system through the first hardware system communication module.

The first hardware system communication module sends the data clearing result of the first hardware system to the second hardware system data clearing module through the second hardware system communication module, in order to ensure the synchronization of the second hardware system and the first hardware system, the second hardware system data clearing module judges the completion condition of the data clearing result, if the state indicated by the data clearing result is the completion state, the first hardware system finishes the data clearing operation, and at the moment, the step of restarting the system can be executed. If the status indicated by the result of clearing data is an unfinished status, which indicates that the first hardware system has not finished clearing data operation, the system cannot be restarted at this time.

And the second hardware system communication module sends the waiting instruction to the first hardware system communication module, the first hardware system communication module waits for a period of time and returns a data clearing result of the first hardware system data clearing module until the data clearing result is in a finished state. And the current data clearing result is used for indicating the result that the first hardware system data clearing module finishes the data clearing operation after waiting for a period of time.

And sending the current data clearing result to a data clearing module of the second hardware system, and restarting the second hardware system by the data clearing module of the second hardware system when the first hardware system finishes the data clearing operation. Because the first hardware system is not provided with components related to factory setting restoration, the first hardware system also has a self-restarting function. Therefore, in this embodiment, the restart of the first hardware system is started by the second hardware system, that is, after the second hardware system and the first hardware system both complete the data clearing operation, the second hardware system is restarted. And generating a restart instruction by the second hardware system, sending the restart instruction to the first hardware system, informing the first hardware system of finishing the restart operation, and immediately finishing factory restoration settings of the second hardware system and the first hardware system.

In an extreme case, the first hardware system data clearing module at the first hardware system end is prone to be abnormal, that is, when the retry time threshold is reached, the second hardware system data clearing module still cannot receive the start result returned by the first hardware system communication module to the first hardware system, and at this time, the data clearing operation of the second hardware system is exited, and the factory settings of the two systems are stopped from being restored.

When factory settings of the two systems are restored, if the two systems cannot be successfully restored due to abnormal conditions, the subsequent application performance of the two systems is easily affected, and therefore, under extreme conditions, another abnormal processing logic, namely a functional abnormal processing method is adopted to solve the problems.

Fig. 27 is a flowchart illustrating a method for handling a dual system parallel factory reset exception according to another embodiment. Specifically, as shown in fig. 27, the method for processing a dual-system parallel factory setting restoration exception according to this embodiment further includes:

s321, if the retry time threshold value is within, the start result returned by the first hardware system communication module to the first hardware system cannot be received through the second hardware system communication module, and a start failure instruction returned by the first hardware system communication module is received.

After the starting is retried for multiple times, in order to ensure that the second hardware system can process the situation that the data clearing operation cannot be performed on the first hardware system in time under the condition that the second hardware system cannot still receive the starting result returned by the first hardware system communication module, the first hardware system generates a starting failure instruction after the retry number reaches the retry number threshold value, and sends the starting failure instruction to the second hardware system data clearing module through the first hardware system communication module and the second hardware system communication module.

S322, acquiring a local key instruction triggered by a user according to the start failure instruction;

in a native mechanism of the Android system, a Recovery module is usually entered to remove user data, and based on this, the functional exception handling method provided in this embodiment is triggered by an external means and enters a Recovery mode of a dual system to execute an operation of removing data.

The external trigger can be local key trigger and remote controller key trigger, and the remote controller key is easily triggered by the user by mistake, so the local key trigger mode is adopted in the embodiment. In the process of adopting the functional exception handling method, the communication mode of the dual system adopts a network and serial port mode, and is the same as the communication mode of the dual system for parallel factory restoration, and network communication and serial port communication are prioritized.

After the second hardware system receives the starting failure instruction returned by the first hardware system, prompt information can be displayed on the display screen for reminding a user to process the extreme condition. Namely, the second hardware system generates prompt information according to the start failure instruction, sends the prompt information to the display screen, and the prompt information is displayed by the display screen to remind a user to trigger the key of the local computer.

And the second hardware system clears the data module to execute corresponding operation according to the local key instruction.

S323, according to the key instruction of the machine, writing BCB information in the second hardware system clear data module and the first hardware system clear data module simultaneously; and the BCB information is used for the first hardware system and the second hardware system to enter a Recovery mode for clearing data.

After the local key is triggered, according to a local key instruction, BCB information for entering a Recovery module to clear data is written into a first hardware system and a second hardware system at the same time, and specifically, the BCB information is written into a second hardware system data clearing module and a first hardware system data clearing module at the same time.

The BCB (BootLoader Control Block) is a structural body, and is a communication interface between the BootLoader and the Recovery, and also a communication interface between the BootLoader and the second hardware system. The BCB information refers to information used for determining to enter a Recovery mode or a main system when the loader boots, for example, if the system needs to enter the Recovery mode, the system can be determined to enter OTA upgrade or clear data operation according to the BCB information.

And S324, in the Recovery mode, according to the BCB information, the first hardware system data clearing module performs data clearing operation on the first hardware system, and the second hardware system data clearing module performs data clearing operation on the second hardware system.

And according to the BCB information, the data clearing operation after the first hardware system and the second hardware system enter the Recovery mode can be simultaneously realized, namely, the data clearing operation is carried out on the first hardware system by the data clearing module of the first hardware system, and the data clearing operation is carried out on the second hardware system by the data clearing module of the second hardware system.

When the first hardware system and the second hardware system carry out a data clearing process, the first hardware system and the second hardware system both enter a synchronous mode, and in the synchronous mode, the first hardware system is in a waiting state and waits for an instruction of the second hardware system all the time, so that the second hardware system can inquire a data clearing state of the first hardware system, and the first hardware system and the second hardware system achieve the purpose of clearing data in parallel.

It can be seen that, in an extreme case, that is, in a case where the first hardware system cannot be started and cannot perform the data clearing operation after the second hardware system retries for multiple times, the method provided in this embodiment adopts a functional exception handling method to simultaneously enter the Recovery mode for the first hardware system and the second hardware system, and simultaneously execute the data clearing operation for the first hardware system and the second hardware system that enter the Recovery mode according to the BCB information, so that the first hardware system and the second hardware system clear data in parallel while recovering the normal factory setting restoring process, thereby not prolonging the time for clearing data and improving user experience.

When the first hardware system and the second hardware system are in a synchronous mode, the second hardware system data clearing module can inquire the data clearing state of the first hardware system in real time, and further can execute a step of restarting the system when the first hardware system and the second hardware system finish data clearing operation so as to finish the process of restoring factory settings.

Therefore, the processing method provided by this embodiment further includes:

and S331, after the first hardware system and the second hardware system enter a synchronization mode, the second hardware system data clearing module generates a query instruction, and the query instruction is sent to the first hardware system communication module through the second hardware system communication module to query a data clearing result of the first hardware system.

After the first hardware system and the second hardware system are synchronized, the second hardware system data clearing module generates a query instruction after the data clearing operation of the second hardware system is completed, and the data clearing state of the first hardware is queried in real time. And the first hardware system clears the data by the first hardware system data clearing module to execute data clearing operation, and after the first hardware system data clearing module enters the synchronous mode, the first hardware system data clearing module feeds a current data clearing result back to the first hardware system communication module in real time and stores the data clearing result so as to facilitate the query of the second hardware system.

Specifically, the second hardware system data clearing module sends the query instruction to the second hardware system communication module, and then the second hardware system communication module sends the query instruction to the first hardware system communication module, so that information interaction between the second hardware system and the first hardware system is realized. After receiving the query instruction, the first hardware system communication module immediately sends the currently stored data clearing result of the first hardware system to the second hardware system communication module, and then the second hardware system communication module sends the data clearing result of the first hardware system to the second hardware system data clearing module.

S332, if the second hardware system data clearing module judges that the received data clearing result is in a finished state, restarting the second hardware system; and generating a restart instruction, sending the restart instruction to the first hardware system data clearing module through the first hardware system communication module, and restarting the first hardware system.

When the second hardware system data clearing module receives the data clearing result, the first hardware system and the second hardware system are communicated normally. The second hardware system data clearing module judges the received data clearing result, and if the data clearing result is in a completion state, the first hardware system is in a data clearing completion state. At this time, after the second hardware system data clearing module finishes the data clearing operation on the second hardware system, a restart instruction is generated, and the restart instruction is sent to the first hardware system data clearing module through the second hardware system communication module and the first hardware system communication module, so that the first hardware system data clearing module restarts the first hardware system according to the restart instruction. And the second hardware system can inform the first hardware system of restarting at the same time of restarting so that the factory settings can be restored after the first hardware system and the second hardware system are restarted at the same time.

Therefore, the second hardware system data clearing module judges the received data clearing result of the first hardware system, can ensure that the first hardware system and the second hardware system restart the two systems under the condition of finishing data clearing operation, and realizes synchronization of data clearing states in a synchronization mode so as to ensure parallel data clearing of the first hardware system and the second hardware system and realize parallel factory restoration of the two systems.

However, if the speed of the clear data operation of the second hardware system is faster and the speed of the clear data operation of the first hardware system is slower, the first hardware system may not complete the clear data operation after the second hardware system completes the clear data operation. If the second hardware system generates the query command, the result of the data purging of the first hardware system is queried, which may be in an incomplete state. When the first hardware system does not finish the data clearing operation, the second hardware system cannot initiate a restart instruction, and the problem that the performance of the first hardware system is influenced by the restart of the first hardware system under the condition that the data clearing operation is not finished is avoided.

Therefore, to avoid the above problem, when the first hardware system does not complete the data clearing operation, the method provided in this embodiment further includes:

And S341, if the second hardware system data clearing module judges that the received data clearing result is in an unfinished state, generating a waiting instruction.

And if the second hardware system data clearing module judges that the data clearing result is in an unfinished state, the first hardware system is in the unfinished data clearing state. At the moment, the second hardware system data clearing module generates a waiting instruction, the waiting instruction is sent to the first hardware system communication module through the second hardware system communication module, the first hardware system communication module waits for a period of time, and then a data clearing result of the first hardware system data clearing module is returned until the data clearing result is in a finished state.

S342, restarting a second hardware system within a waiting time threshold value according to the waiting instruction if a data clearing result in a finished state cannot be received; and generating a restart command, sending the restart command to the first hardware system data clearing module through the first hardware system communication module, and restarting the first hardware system.

And the first hardware system communication module waits for the data clearing result when the data clearing operation is in the finished state returned by the first hardware system data clearing module according to the waiting instruction, and at the moment, the second hardware system is also in a state of waiting for the latest data clearing result of the first hardware system. In order to ensure the time taken for restoring the factory setting, the second hardware system end sets a waiting time threshold, that is, if the second hardware system can receive the latest data clearing result of the first hardware system within the waiting time threshold, the process of restoring the factory setting of the dual system is normal; however, if the second hardware system still cannot receive the latest data clearing result of the first hardware system within the waiting time threshold, it indicates that the first hardware system side fails to clear the data.

In this embodiment, the waiting time threshold is set to be 5 minutes, and during waiting for 5 minutes, the second hardware system data clearing module receives the latest data clearing result of the first hardware system through the second hardware system communication module, and at this time, generates a restart instruction, and notifies the first hardware system to restart while the second hardware system is restarted, thereby implementing parallel factory settings restoration of the dual systems.

If the time is 5 minutes after the first hardware system is finished, the second hardware system data clearing module still cannot receive the latest data clearing result of the first hardware system through the second hardware system communication module, and then the first hardware system data clearing failure can be judged. Under the functional exception handling method, the first hardware system still cannot finish the data clearing operation after repeated retries, the first hardware system is not processed any more, and in order to avoid prolonging the time length for clearing data, the second hardware system generates a restart instruction at the moment, and sends the restart instruction to the first hardware system data clearing module through the second hardware system communication module and the first hardware system communication module, so that the first hardware system data clearing module restarts the first hardware system according to the restart instruction. And the second hardware system can inform the first hardware system of restarting at the same time of restarting so that the factory settings can be restored after the first hardware system and the second hardware system are restarted at the same time.

Under another condition, when the second hardware system data clearing module finishes the data clearing operation of the second hardware system, under the synchronization module, the data clearing result of the first hardware system is inquired, and if the first hardware system end cannot return the data clearing result, or the returned data clearing result is in an incomplete state, in order to ensure that the dual systems can be successfully restored to factory settings, a retry mechanism is entered.

Fig. 28 is a flowchart illustrating a method for handling a dual system parallel factory reset exception according to yet another embodiment. Specifically, as shown in fig. 28, the method provided in this embodiment further includes:

s351, generating a query instruction under the condition that the data clearing module of the second hardware system completes the data clearing operation of the second hardware system;

s352, sending the query instruction to the first hardware system communication module through the second hardware system communication module so that the first hardware system communication module queries the data clearing result of the first hardware system;

and when finishing the data clearing operation of the second hardware system, the second hardware system data clearing module initiates active communication to inquire the data clearing result of the first hardware system so as to ensure the parallel data clearing of the two systems.

When the first hardware system carries out data clearing operation, the first hardware system data clearing module returns a data clearing result to the first hardware system communication module in real time and stores the data clearing result, after the first hardware system communication module receives the query instruction, the first hardware system communication module can directly send the currently stored data clearing result of the first hardware system to the second hardware system communication module, and the second hardware system communication module returns the data clearing result of the first hardware system to the second hardware system data clearing module.

S353, under the condition that a data clearing result of the first hardware system returned by the first hardware system communication module cannot be received, retrying according to the interval duration;

when the network and the serial port are abnormal, the first hardware system and the second hardware system cannot realize communication, so that the second hardware system cannot receive a data clearing result sent by the first hardware system.

When the second hardware system data clearing module determines that the data clearing result of the first hardware system is in an incomplete state, or the first hardware system communication module and the second hardware system communication module cannot communicate with each other, so that when the data clearing result of the first hardware system cannot be sent to the second hardware system, in order to ensure that the process of factory restoration is normal, a retry mechanism is adopted in the embodiment, and the retry frequency is determined according to the set interval duration.

In this embodiment, the set interval duration is 2 seconds, that is, the second hardware system data clearing module resends the query instruction to the first hardware system communication module every 2 seconds, and the first hardware system communication module resends the data clearing result of the first hardware system to the second hardware system communication module every 2 seconds.

S354, if the total retry duration is within the threshold value, the data clearing result is received, and the first hardware system and the second hardware system are restarted;

and S355, if the data clearing result cannot be received within the retry total time length threshold, restarting the second hardware system.

To avoid extending the time period for the dual system to clear data, in this embodiment, the threshold of total retry time period is set to be 5 minutes. And when the accumulated retry duration reaches the retry total duration threshold, not retrying any more, and judging that the first hardware system fails to clear the data. The retry total duration threshold may be set according to the requirement of the user, and the embodiment is not limited in particular.

Within 5 minutes, if the first hardware system communication module can send a data clearing result of the first hardware system to the second hardware system communication module according to the query instruction, the second hardware system data clearing module generates a restart instruction when judging that the data clearing result is in a finished state, and sends the restart instruction to the first hardware system data clearing module through the second hardware system communication module and the first hardware system communication module, so that the first hardware system data clearing module restarts the first hardware system according to the restart instruction. And the second hardware system can inform the first hardware system of restarting at the same time of restarting so that the factory settings can be restored after the first hardware system and the second hardware system are restarted at the same time.

If the time is overtime for 5 minutes, the first hardware system communication module still cannot send the data clearing result of the first hardware system to the second hardware system communication module according to the query instruction, and the second hardware system data clearing module cannot receive the data clearing result of the first hardware system in a data clearing state, that is, the first hardware system data clearing failure can be judged, and at the moment, only the second hardware system is restarted.

As can be seen from the foregoing technical solutions, the method for processing a factory setting exception through parallel recovery of dual systems according to the embodiment of the present invention includes: the second hardware system data clearing module generates a clearing starting instruction according to the received factory reset restoring instruction, and the clearing starting instruction is sent to the first hardware system communication module through the second hardware system communication module, so that the first hardware system data clearing module is started by the first hardware system communication module to clear data of the first hardware system. When the second hardware system data clearing module cannot receive the starting result returned by the first hardware system communication module through the second hardware system communication module, the adopted exception handling logic is a retry mechanism, within a retry time threshold, the second hardware system data clearing module can receive the starting result returned by the first hardware system communication module, so that the first hardware system data clearing module immediately clears the first hardware system while being started, and the second hardware system data clearing module also immediately clears the second hardware system after receiving the starting result. The method provided by this embodiment may adopt a retry mechanism to restart the first hardware system when the first hardware system is abnormal during the factory reset process, so as to ensure that the parallel factory reset of the dual systems is performed smoothly, and avoid prolonging the time for the dual systems to clear data.

Fig. 29 is a block diagram illustrating a configuration of a processing apparatus for a dual system parallel factory reset exception according to an embodiment. As shown in fig. 29, a processing apparatus for dual-system parallel factory reset exception according to an embodiment of the present application is configured to execute relevant steps of a processing method for dual-system parallel factory reset exception shown in fig. 26 to 28, and specifically, the processing apparatus includes: a clearing start instruction generating module 10, configured to generate a clearing start instruction according to the received factory reset instruction; a start clearing instruction sending module 20, configured to send the start clearing instruction to a first hardware system communication module through a second hardware system communication module, so that the first hardware system communication module starts a first hardware system data clearing module to perform data clearing operation on the first hardware system; the retry module 30 is configured to retry a process of the first hardware system communication module starting the first hardware system data clearing module when the start result that the first hardware system communication module returns the first hardware system cannot be received by the second hardware system communication module; a starting result receiving module 40, configured to, when the starting result that the first hardware system communication module returns to the first hardware system is received through the second hardware system communication module within the threshold of the retry number, perform a data clearing operation on the second hardware system, and perform a data clearing operation on the first hardware system through the first hardware system data clearing module; and the restarting module 50 is configured to restart the first hardware system and the second hardware system after the data clearing operation is completed.

Optionally, the method further comprises: the starting failure instruction receiving module is used for receiving a starting failure instruction returned by the first hardware system communication module under the condition that the starting result returned by the first hardware system communication module cannot be received by the second hardware system communication module within the threshold value of the retry times; the local key instruction acquisition module is used for acquiring a local key instruction triggered by a user according to the start failure instruction; the BCB information writing module is used for simultaneously writing BCB information in the second hardware system clear data module and the first hardware system clear data module according to the local key instruction; the BCB information is used for enabling the first hardware system and the second hardware system to enter a Recovery mode to clear data; and the data clearing module is used for carrying out data clearing operation on the first hardware system by the first hardware system data clearing module and carrying out data clearing operation on the second hardware system by the second hardware system data clearing module according to the BCB information in a Recovery mode.

Optionally, the method further comprises: the query instruction generating module is used for generating a query instruction after the first hardware system and the second hardware system enter a synchronous mode, and sending the query instruction to the first hardware system communication module through the second hardware system communication module so as to query a data clearing result of the first hardware system; the restarting module is also used for restarting the second hardware system when the second hardware system data clearing module judges that the received data clearing result is in a finished state; and generating a restart command, sending the restart command to the first hardware system data clearing module through the first hardware system communication module, and restarting the first hardware system.

Optionally, the method further comprises: a wait instruction generating module, configured to generate a wait instruction when the second hardware system data clearing module determines that the received data clearing result is an incomplete state; the restarting module is also used for restarting the second hardware system if the data clearing result in the finished state cannot be received within the waiting time threshold value according to the waiting instruction; and generating a restart command, sending the restart command to the first hardware system data clearing module through the first hardware system communication module, and restarting the first hardware system.

Optionally, the method further comprises: the query instruction generating module is further used for generating a query instruction under the condition that the second hardware system data clearing module finishes the data clearing operation of the second hardware system; the query instruction sending module is used for sending the query instruction to the first hardware system communication module through the second hardware system communication module so as to query the clearing data result of the first hardware system through the first hardware system communication module; the retry module is further configured to retry according to the interval duration under the condition that the data clearing result of the first hardware system returned by the first hardware system communication module cannot be received; the restarting module is also used for restarting the first hardware system and the second hardware system under the condition that a data clearing result is received within the retry total duration threshold; and restarting the second hardware system under the condition that the result of clearing the data cannot be received within the threshold value of the total retry time.

In a specific implementation, the present invention further provides a computer storage medium, where the computer storage medium may store a program, and when the program is executed, the program may include some or all of the steps in each embodiment of the processing method for parallel dual-system factory setting exception recovery provided by the present invention. The storage medium may be a magnetic disk, an optical disk, a read-only memory (ROM) or a Random Access Memory (RAM).

The same and similar parts in the various embodiments in this specification may be referred to each other. Especially, for an embodiment of a processing apparatus for dual system parallel factory setting recovery exception, since it is substantially similar to the method embodiment, the description is relatively simple, and for relevant points, reference may be made to the description in the method embodiment.

When the display equipment of the Android system is restored to factory settings, under a normal condition, the Android system needs to enter a restoration mode to clear user data. However, when the display device is abnormal or when the display device is abnormal in the factory reset process, the Android system needs to be forced to enter the reset mode by pressing a key of the display device, so that factory reset under emergency reset measures is realized.

In the conventional display apparatus, there is only one system, i.e., a main system, and the local key is provided on the main system. When the display device is started, the main system detects whether a key of the main system is continuously pressed so as to judge whether a recovery mode needs to be entered. For example, if the local key is continuously pressed for more than 3 seconds, the main system enters a recovery mode; if the local key is not continuously pressed but is immediately bounced after being pressed, the main system does not enter the recovery mode but enters the normal starting mode.

In the display device with the dual-system architecture, the local key is only connected to the main system, namely the second hardware system, and the auxiliary system, namely the first hardware system, is not provided with relevant parts for restoring factory settings. When factory setting is restored on display equipment comprising a first hardware system and a second hardware system, the first hardware system and the second hardware system are required to synchronously enter a restoration mode, so that the time for clearing data by double systems is prevented from being prolonged, and the user experience is ensured.

Therefore, the embodiment of the invention provides a method for synchronously entering a recovery mode by two systems, which can ensure that the two systems synchronously enter the recovery mode on the basis of not adding an extra circuit by multiplexing the existing communication line between a first hardware system and a second hardware system, and has little influence on the performance of the starting time of the two systems.

A communication interaction diagram between dual systems according to an embodiment is illustrated in fig. 30. In order to implement the synchronous entry recovery mode between the first hardware system 310 and the second hardware system 210, as shown in fig. 30, in this embodiment, a communication module 510 and a power management module 410 are disposed between the first hardware system 310 and the second hardware system 210, the communication module 510 is configured to complete bidirectional communication between the first hardware system 310 and the second hardware system 210, the power management module 410 is configured to provide power-related functions between the first hardware system 310 and the second hardware system 210, and the power-on of the first hardware system 310 is implemented by the second hardware system 210 through the power management module 410.

The second hardware system 210 is connected with a local key module 610, the local key module 610 is only connected to the second hardware system 210, and the second hardware system 210 can obtain the local key state through the local key module 610, so as to determine the state information of the local key such as long press, duration, short press, lifting time, and the like.

When factory reset is performed, the operation of enabling the system to enter the recovery mode generally occurs in a system starting stage, specifically, a BootLoader stage of an Android system starting process, which is a stage when the dual system normally performs factory reset.

In addition, the method provided by the embodiment can also be applied to the situation that the dual system is abnormal when factory settings are restored. In the foregoing embodiments, it is mentioned that, when the second hardware system starts the first hardware system to clear the data, the first hardware system is very easy to fail to start or to return the start result and the clear data result to the second hardware system. In this case, the foregoing embodiment employs a retry mechanism to perform multiple boots on the first hardware system, so that the data clearing process of the first hardware system is recovered to normal.

Under normal conditions, the second hardware system can restart the first hardware system after a few retries, and enter normal clear data operation. However, in an extreme case, the first hardware system may not be restarted even if the number of retries exceeds the number of retries. Therefore, in the scheme provided by the foregoing embodiment, in order to ensure that the dual systems recover the factory settings in parallel, a functional exception handling method is adopted, that is, the first hardware system and the second hardware system enter the Recovery mode simultaneously to perform data clearing operation in a manner of triggering a local key.

The first hardware system and the second hardware system enter the triggering condition of the Recovery mode at the same time, and the triggering can be performed without pressing a local key by a user, so that the triggering can be performed only by continuously pressing the local key for a long time by the user to avoid misoperation of the user. That is to say, in the foregoing embodiment, the scheme of using the native key to enable the first hardware system and the second hardware system to simultaneously enter the Recovery mode for performing the data clearing operation may also be applied to the method for enabling the dual systems to synchronously enter the Recovery mode provided in this embodiment.

FIG. 31 is a flow diagram illustrating a method for dual system synchronization to enter recovery mode in accordance with an embodiment; fig. 32 is a data flow diagram illustrating a method for dual system synchronous entry into recovery mode according to an embodiment. As shown in fig. 31 and fig. 32, a method for dual system synchronous entry into a recovery mode according to an embodiment of the present invention includes the following steps:

And S41, acquiring the key state of the computer.

The second hardware system is provided with a local key module, and the second hardware system is communicated with the local keys through the local key module.

When a user needs to restore factory settings of the display device, a local key is pressed in the starting process for a period of time, at the moment, the pressed state of the local key is sent to a second hardware system by a local key module, and the second hardware system executes corresponding operation according to the obtained local key state.

The key state of the machine is the state that the key of the machine is pressed, and comprises a long-press state, a short-press state, a key-up state and the like. In different states, the second hardware system performs different operations, such as entering a recovery mode or entering a normal boot mode.

S42, entering a recovery mode countdown state when the key state of the machine is a long-time pressing state;

after receiving the state of the local key sent by the local key module, the second hardware system judges the pressed state of the local key, and if the local key is continuously pressed, namely in a long-time pressing state, the second hardware system indicates that the user wants to restore the Android system to factory settings; if the key of the machine is pressed and quickly lifted, namely in a short-time pressing state, the user only starts up and starts up the display equipment normally without entering a recovery mode by an Android system.

Therefore, when the second hardware system judges that the key state of the local machine is the long-press state, the second hardware system can be controlled to enter the countdown state of the recovery mode.

The recovery mode countdown state is a state that a countdown mode is adopted, and the control system enters the recovery mode when the countdown is finished. In this embodiment, the countdown time period may be set to 8 seconds, and the countdown time period may be configured according to the user's usage requirement. The countdown duration may be longer than a standard duration that is commonly used in the art to determine that the key is in the long-press state, and the standard duration in the long-press state may be 2 seconds or 3 seconds, so as to avoid a user from generating a malfunction, for example, the user may enter the system into the recovery mode only after continuously pressing the local key for 8 seconds.

And S43, generating a notification instruction, and sending the notification instruction to the first hardware system to notify the first hardware system to enter a recovery mode countdown state.

And under the condition that the second hardware system meets the condition of entering the recovery mode countdown state, generating a notification instruction, and sending the notification instruction to the first hardware system through the communication module, wherein the first hardware system also enters the recovery mode countdown state according to the notification instruction.

In order to ensure the synchronism of the first hardware system and the second hardware system entering the recovery mode, in this embodiment, the second hardware system notifies the first hardware system of the time when entering the recovery mode countdown state is the time when the second hardware system determines that the local key state is the long-press state.

That is to say, when the second hardware system determines that the local key state is the long-press state, that is, after the local key is pressed for 2 seconds or 3 seconds, a notification instruction is immediately generated and sent to the first hardware system through the communication module, so as to ensure that the time when the second hardware system enters the recovery mode countdown state is the same as or close to the time when the first hardware system enters the recovery mode countdown state.

The first hardware system is in a waiting instruction state before entering a recovery mode countdown state, and the condition for triggering the first hardware system to be in the waiting instruction state is the moment when the second hardware system powers on the first hardware system through the power management module.

Therefore, before the second hardware system acquires the state of the local key, the method further comprises a step of enabling the first hardware system to be in a waiting instruction state, specifically:

s401, carrying out power-on and power-on operation on the second hardware system according to the power-on signal.

S402, the second hardware system sends the power-on signal to the first hardware system through the power management module, so that the first hardware system is started and is in a waiting instruction state.

The power supply key of the display equipment is only connected with the second hardware system, a user triggers the power supply key to generate a power-on signal, and the second hardware system can realize power-on starting operation according to the power-on signal. The first hardware system is not directly communicated with the power supply key, so that starting and starting cannot be realized according to the power-on signal generated by the power supply key.

In the display equipment with the dual-system structure, the power-on operation of the first hardware system is realized by the second hardware system, and the second hardware system sends a power-on signal to the first hardware system through the power management module to provide power related functions for the first hardware system so as to promote the start-up of the first hardware system. The first hardware system is always in a waiting instruction state after being started, and waits for a corresponding command sent by the second hardware system through the communication module.

The first hardware system is started in advance and waits for the command of the second hardware system all the time, so that when the second hardware system sends the command, the first hardware system can respond to the command in time, the first hardware system and the second hardware system can realize synchronous operation, and the time length of corresponding operation is prevented from being prolonged.

S44, detecting the current state of the key state of the machine, and if the current state is matched with the countdown state of the recovery mode, the first hardware system and the second hardware system synchronously enter the recovery mode.

And after entering a recovery mode countdown state, the second hardware system continuously detects the state of the local key so as to be capable of acquiring the state change of the local key in time.

During the process from the beginning of the countdown to the end of the countdown, there are many possible changes to the state of the local key, for example, the current state includes that the local key is continuously pressed, lifted, and the like. If the key of the local machine is still in the continuous pressing state when the countdown is finished, at the moment, the current state of the key state of the local machine is matched with the countdown state of the recovery mode, and the system can be controlled to enter the recovery mode. If the key of the machine is lifted in the countdown process, namely the current state of the key state of the machine is the lifted state, at the moment, the current state of the key state of the machine is not matched with the countdown state of the recovery mode, and the system cannot be controlled to enter the recovery mode but enter the normal starting state.

In order to accurately control the first hardware system and the second hardware system to synchronously enter the recovery mode, in this embodiment, a mode that the current state of the local key is matched with the countdown state of the recovery mode is adopted, that is, when the countdown is finished, the local key is still in the continuously pressed state. Determining the judgment basis of the key of the local machine in the continuous pressing state to be the duration of the long pressing state, and representing the continuous pressing state of the key of the local machine through the duration; the relationship between the key of the local machine and the countdown ending time is represented by the time of the key lifting state of the local machine, so as to represent whether the key of the local machine is in the long-time pressing state. Under each judgment basis, the first hardware system and the second hardware system synchronously enter the recovery mode according to the following method.

A method flow diagram of one implementation of dual system synchronization into resume mode in accordance with an embodiment is illustrated in fig. 33. In one possible embodiment, as shown in fig. 33, detecting the current state of the native key state, and if the current state matches the recovery mode countdown state, the first hardware system and the second hardware system synchronously entering the recovery mode includes:

s4411, detecting a duration of the press key status of the device as a long press status.

After entering the recovery mode countdown state, the second hardware system continuously checks the current state of the local key state, and in this embodiment, the current state is represented by the duration of the long-press state.

The duration of the long press state refers to the duration corresponding to the time from the moment when the second hardware system judges that the key state of the local machine is the long press state to the moment when the key state is lifted.

S4412, if the duration of the long press state of the key of the computer exceeds the countdown duration of the countdown state of the recovery mode, the second hardware system enters the recovery mode.

After the second hardware system acquires the duration that the key state of the local machine is the long-press state, the duration and the countdown duration of the recovery mode countdown state need to be judged. If the duration is longer than or equal to the countdown duration, the key of the local computer is lifted after the countdown is finished, and at the moment, the current state of the key state of the local computer is matched with the countdown state of the recovery mode, so that the entry condition of the recovery mode is met, and the second hardware system enters the recovery mode.

If the duration is less than the countdown duration, the key of the local computer is lifted before the countdown is finished, and at the moment, the current state of the key state of the local computer is not matched with the countdown state of the recovery mode, so that the triggering condition of normal starting is met, and the second hardware system enters the normal starting state.

S4413, if the first hardware system does not receive the command sent by the second hardware system when the countdown of the recovery mode countdown status corresponding to the first hardware system is finished, the first hardware system enters the recovery mode.

The first hardware system is always in a waiting instruction state, if the first hardware system still does not receive the command sent by the second hardware system when the countdown is finished, the second hardware system enters the recovery mode, and at the moment, the first hardware system enters the recovery mode from the time when the countdown is finished.

Because the first hardware system and the second hardware system enter the recovery mode countdown state at the same or similar time, when the countdown of the second hardware system is finished, the countdown of the first hardware system is also finished or is about to be finished, and the first hardware system and the second hardware system both enter the recovery mode after the countdown is finished, so that the time when the second hardware system enters the recovery mode is the same as or similar to the time when the first hardware system enters the recovery mode, the first hardware system and the second hardware system can be ensured to synchronously enter the recovery mode, and the data clearing time of the double systems is prevented from being prolonged.

And if the first hardware system receives the command sent by the second hardware system before the countdown corresponding to the first hardware system is finished, the second hardware system enters a normal starting process. At the moment, the first hardware system enters a normal starting process according to the received command, stops counting down at the same time, and converts the recovery mode counting down state into a normal starting state.

Specifically, when the second hardware system detects that the duration of the long-press state of the host key is less than the countdown duration, the second hardware system enters a normal starting state and sends a starting command to the first hardware system through the communication module, the first hardware system stops countdown according to the starting command, the recovery mode countdown state is converted into a normal starting state, and a normal starting process is entered.

A method flow diagram according to another implementation of dual system synchronization into resume mode in an embodiment is illustrated in fig. 34. In another possible embodiment, as shown in fig. 34, detecting the current state of the native key state, and if the current state matches the recovery mode countdown state, the first hardware system and the second hardware system synchronously entering the recovery mode includes:

S4421, detecting the key lifting time of the key state of the device.

After entering the recovery mode countdown state, the second hardware system continuously checks the current state of the local key state.

After the pressed key of the local computer is lifted, the second hardware system can acquire the lifted key of the local computer and the lifting time of the key through the key module of the local computer. The key lifting time is the corresponding time when the key of the machine is changed from a pressed state to a lifted state.

S4422, if the key lifting time is behind the countdown ending time of the recovery mode countdown state, the second hardware system enters the recovery mode.

After the second hardware system acquires the key lifting time corresponding to the key state of the local hardware system in the lifting state, the precedence relationship between the key lifting time and the countdown ending time of the recovery mode countdown state corresponding to the second hardware system needs to be judged. If the key lifting time is after the countdown ending time, the key of the local computer is lifted after the countdown ending time, and at the moment, the current state of the key state of the local computer is matched with the countdown state of the recovery mode, so that the entry condition of the recovery mode is met, and the second hardware system enters the recovery mode.

If the key lifting time is before the countdown ending time, the key of the local computer is lifted before the countdown ending time, and at the moment, the current state of the key state of the local computer is not matched with the countdown state of the recovery mode, so that the triggering condition of normal starting is met, and the second hardware system enters the normal starting state.

S4423, if the first hardware system does not receive the command sent by the second hardware system when the countdown of the recovery mode countdown status corresponding to the first hardware system is finished, the first hardware system enters the recovery mode.

And if the first hardware system receives the command sent by the second hardware system before the countdown corresponding to the first hardware system is finished, indicating that the second hardware system enters a normal starting process. At the moment, the first hardware system enters a normal starting process according to the received command, stops counting down at the same time, and converts the recovery mode counting down state into a normal starting state.

Specifically, under the condition that the second hardware system detects that the key lifting time of the host key in the lifting state is before the countdown ending time, the second hardware system enters the normal starting state and sends a starting command to the first hardware system through the communication module, and the first hardware system stops countdown according to the starting command, converts the recovery mode countdown state into the normal starting state and enters the normal starting process.

After the first hardware system and the second hardware system enter the recovery mode, the states of the first hardware system and the second hardware system are synchronized, so that the first hardware system and the second hardware system can synchronously clear data, the data clearing time is prevented from being prolonged, and the user experience is improved.

As can be seen from the foregoing technical solutions, a method for a dual system to synchronously enter a recovery mode provided in an embodiment of the present invention includes: acquiring the key state of the local machine by a second hardware system; under the condition that the second hardware system judges that the key state of the computer is a long-press state, the second hardware system enters a recovery mode countdown state; meanwhile, the second hardware system generates a notification instruction and sends the notification instruction to the first hardware system to notify the first hardware system to enter the recovery mode countdown state, and the time when the first hardware system enters the recovery mode countdown state is the same as or similar to the time when the second hardware system enters the recovery mode countdown state, so that the first hardware system and the second hardware system can synchronously execute the same operation. The second hardware system continuously detects the current state of the key state of the local machine, if the current state is matched with the countdown state of the recovery mode, namely when the countdown is finished, the key of the local machine is always in the pressed state, the first hardware system does not receive the command of the second hardware system, and the first hardware system and the second hardware system synchronously enter the recovery mode. Therefore, according to the method provided by the embodiment, the time when the two systems enter the recovery mode countdown state is the same or similar, and the condition for entering the recovery mode is the time when the countdown is finished, so that the first hardware system and the second hardware system can be ensured to synchronously execute corresponding operations, the recovery mode can be synchronously entered, the duration of clearing data is prevented from being prolonged, and the user experience is improved.

Fig. 35 is a block diagram illustrating an apparatus for entering a recovery mode in synchronization with a dual system according to an embodiment. As shown in fig. 35, an apparatus for dual-system synchronous entry into a recovery mode according to an embodiment of the present application is configured to perform the relevant steps of the method for dual-system synchronous entry into a recovery mode shown in fig. 31 to 34. Specifically, the apparatus includes: an obtaining module 101, configured to obtain a key state of a local computer; a countdown state entering module 201, configured to enter a recovery mode countdown state when the local key state is a long-press state; the notification instruction processing module 301 is configured to generate a notification instruction, and send the notification instruction to the first hardware system to notify the first hardware system of entering a recovery mode countdown state; a detecting module 401, configured to detect a current state of the key state of the local computer, and if the current state matches the recovery mode countdown state, synchronously enter a recovery mode in the first hardware system and the second hardware system.

Optionally, the method further comprises: the power-on module is used for carrying out power-on and power-on operations on the second hardware system according to the power-on signal; and the standby module is used for sending the power-on signal to a first hardware system through the power management module so that the first hardware system is started and is in a waiting instruction state.

Optionally, the second hardware system notifies the first hardware system of the time when the first hardware system enters the recovery mode countdown state, which is the time when the second hardware system determines that the local key state is the long-press state.

Optionally, the detection module 401 includes: the first detection unit is used for detecting the duration of the key state of the mobile phone as a long-press state; a second recovery mode entering unit, configured to, when a duration of the long-press state of the local key exceeds a countdown duration of the recovery mode countdown state, enter a recovery mode by a second hardware system; a first recovery mode entering unit, configured to, when the countdown of the recovery mode countdown state corresponding to the first hardware system is finished, if the first hardware system does not receive an instruction sent by the second hardware system, enter the recovery mode by the first hardware system.

Optionally, the detection module 401 includes: the second detection unit is used for detecting the key lifting moment of the key state of the machine; the second recovery mode entering unit is further used for enabling the second hardware system to enter the recovery mode when the key lifting moment is behind the countdown ending moment of the recovery mode countdown state; and the first recovery mode entering unit is used for entering the recovery mode by the first hardware system when the countdown of the recovery mode countdown state corresponding to the first hardware system is finished and the first hardware system does not receive the instruction sent by the second hardware system.

In a specific implementation, the present invention further provides a computer storage medium, where the computer storage medium may store a program, and the program may include some or all of the steps in the embodiments of the method for synchronously entering a recovery mode in a dual system provided by the present invention when executed. The storage medium may be a magnetic disk, an optical disk, a read-only memory (ROM) or a Random Access Memory (RAM).

The same and similar parts in the various embodiments in this specification may be referred to each other. Especially, for the embodiment of the apparatus for synchronously entering the recovery mode in dual systems, since it is basically similar to the embodiment of the method, the description is simple, and the relevant points can be referred to the description in the embodiment of the method.

All other embodiments, which can be derived by a person skilled in the art from the exemplary embodiments shown in the present application without inventive step, are within the scope of protection of the present application. Moreover, while the disclosure herein has been presented in terms of exemplary embodiment or embodiments, it is to be understood that each aspect of the disclosure can independently be implemented as a single unitary embodiment.

It should be understood that the terms "first," "second," "third," and the like in the description and claims of this application and in the foregoing drawings are used for distinguishing between similar elements and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used are interchangeable under appropriate circumstances and can, for example, be implemented in sequences other than those illustrated or otherwise described herein with reference to the embodiments of the application.

Furthermore, the terms "comprises" and "comprising," as well as any variations thereof, are intended to cover a non-exclusive inclusion, such that a product or device that comprises a list of elements is not necessarily limited to those elements explicitly listed, but may include other elements not expressly listed or inherent to such product or device.

Finally, it should be noted that: the above embodiments are only used for illustrating the technical solutions of the present application, and not for limiting the same; although the present application has been described in detail with reference to the foregoing embodiments, it should be understood by those of ordinary skill in the art that: the technical solutions described in the foregoing embodiments may still be modified, or some or all of the technical features may be equivalently replaced; and the modifications or the substitutions do not make the essence of the corresponding technical solutions depart from the scope of the technical solutions of the embodiments of the present application.

Claims

1. A dual-system OTA parallel upgrading method is characterized by comprising the following steps:

2. The method of claim 1, further comprising:

3. The method of claim 2, further comprising:

4. The method according to claim 1, wherein in a case that the first hardware system and the second hardware system respectively verify successfully, the second hardware system generates an installation instruction, and sends the installation instruction to the first hardware system, and the method includes:

5. The method of claim 4, further comprising:

6. The method of claim 1, wherein, in a case that the first hardware system and the second hardware system are installed successfully respectively, the second hardware system generates a restart instruction, and sends the restart instruction to the first hardware system, and the method includes:

7. The method of claim 6, further comprising:

when the second hardware system receives a result in the installation state returned by the first hardware system according to the installation state query instruction, generating a waiting instruction and waiting for the completion of the installation of the first hardware system;

8. The method of claim 1, further comprising:

9. The method of claim 8, wherein the display manner of the progress bar comprises:

10. The method of claim 9, further comprising:

11. A dual-system OTA parallel upgrade system is characterized by comprising: the system comprises a first hardware system and a second hardware system, wherein the second hardware system is connected with the first hardware system through a serial port or a network cable; the first hardware system and the second hardware system are respectively configured to perform the following steps:

12. The system of claim 11, wherein the first hardware system and the second hardware system are further configured to perform the steps of:

13. The system of claim 12, wherein the first hardware system and the second hardware system are further configured to perform the steps of:

14. The system of claim 11, wherein the first hardware system and the second hardware system are further configured to perform the steps of:

15. The system of claim 14, wherein the first hardware system and the second hardware system are further configured to perform the steps of:

16. The system of claim 11, wherein the first hardware system and the second hardware system are further configured to perform the steps of:

17. The system of claim 16, wherein the first hardware system and the second hardware system are further configured to perform the steps of:

18. The system of claim 11, wherein the first hardware system and the second hardware system are further configured to perform the steps of:

19. The system of claim 18, wherein the first hardware system and the second hardware system are further configured to perform the steps of:

20. The system of claim 19, wherein the first hardware system and the second hardware system are further configured to perform the steps of: