System starting method and apparatus, electronic device, medium, and computer program product

Abstract

This application discloses a system startup method, apparatus, electronic device, medium, and computer program product, relating to the field of electronic devices. The method is used in an electronic device that supports the operation of a first system and a second system. The method includes: starting the first system in response to a device startup event; during the operation of the first system, starting the second system if the system startup conditions of the second system are met; and synchronizing information between the first system and the second system after the second system starts. By delaying the startup time of the second system, the situation where the second system is started but idle can be avoided, effectively saving device power consumption and extending device battery life.

Description

Technical Field

[0001] This application relates to the field of electronic devices, and in particular to a system startup method, apparatus, electronic device, medium, and computer program product. Background Technology

[0002] With the continuous upgrading of electronic devices, dual-core dual-system devices, which include both high-performance and low-power processors, have emerged to improve battery life. The two systems can work together, while each system also has the ability to operate independently.

[0003] In related technologies, when electronic devices are powered on, a dual-core, dual-system configuration is typically started directly and maintained in a dual-system running state. However, during daily device use, users often do not immediately use applications supported by the high-performance system upon startup. There is a considerable time interval between the high-performance system starting up and the user actually using it. If the high-performance system remains running even when not in use, it results in wasted power consumption. Summary of the Invention

[0004] This application provides a system startup method, apparatus, electronic device, medium, and computer program product. The technical solution is as follows:

[0005] On the one hand, embodiments of this application provide a system startup method, the method being used in an electronic device, the electronic device supporting the operation of a first system and a second system;

[0006] The method includes:

[0007] In response to a device startup event, the first system is started;

[0008] During the operation of the first system, if the system startup conditions of the second system are met, the first system starts the second system;

[0009] After the second system is started, the first system and the second system synchronize information.

[0010] On the other hand, embodiments of this application provide a system startup method for an electronic device, wherein the electronic device supports the operation of a first system and a second system;

[0011] The method includes:

[0012] When the first system has started but the second system has not started, the first system displays the boot screen during the startup process of the second system;

[0013] After the second system starts up, the second system obtains screen control permissions from the first system.

[0014] On the other hand, embodiments of this application provide a system startup device for an electronic device, wherein the electronic device supports the operation of a first system and a second system;

[0015] The device includes:

[0016] The first system module is used to start the first system in response to a device startup event;

[0017] The first system module is used to start the second system during the operation of the first system, provided that the system startup conditions of the second system are met;

[0018] The first system module is also used to synchronize information with the second system module after the second system is started.

[0019] On the other hand, embodiments of this application provide a system startup device for an electronic device, wherein the electronic device supports the operation of a first system and a second system;

[0020] The device includes:

[0021] The first system module is used to display the boot screen during the boot process of the second system when the first system has been started but the second system has not been started.

[0022] The second system module is used to obtain screen control permissions from the first system module after the second system is started.

[0023] On the other hand, embodiments of this application provide an electronic device, which includes a processor and a memory; the memory stores at least one computer instruction, which is executed by the processor to implement the system startup method as described above.

[0024] On the other hand, embodiments of this application provide a computer-readable storage medium storing at least one computer instruction, which is loaded and executed by a processor to implement the system startup method as described above.

[0025] On the other hand, embodiments of this application provide a computer program product including computer instructions stored in a computer-readable storage medium; a processor of an electronic device reads the computer instructions from the computer-readable storage medium and executes the computer instructions to cause the electronic device to perform the system startup method as described above.

[0026] For electronic devices that support the operation of both a first system and a second system, unlike related technologies where the first and second systems are directly started upon device startup, this application embodiment employs a system delayed startup mechanism. That is, in response to a device startup event, only the first system is started first. During the operation of the first system, if the system startup conditions of the second system are met, the first system then starts the second system to synchronize information with it. By delaying the startup time of the second system, the solution provided in this application embodiment avoids situations where the second system is started but idle, effectively saving device power consumption and extending device battery life. Attached Figure Description

[0027] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0028] Figure 1 This is a diagram of a dual-core communication software framework for the Android operating system provided in an exemplary embodiment of this application;

[0029] Figure 2 This is a diagram of a dual-core communication software framework for an RTOS provided in an exemplary embodiment of this application;

[0030] Figure 3 This is a flowchart of a system startup method provided in an exemplary embodiment of this application;

[0031] Figure 4 This is a schematic diagram of the system startup interface provided in an exemplary embodiment of this application;

[0032] Figure 5 This is a schematic diagram of an interface for displaying notification messages provided in an exemplary embodiment of this application;

[0033] Figure 6 This is a timing diagram of system startup provided in an exemplary embodiment of this application;

[0034] Figure 7 This is a schematic diagram of the interface for responding to an application startup operation provided in an exemplary embodiment of this application;

[0035] Figure 8 This is a timing diagram of system startup provided in another exemplary embodiment of this application;

[0036] Figure 9 This is a timing diagram of system startup provided in another exemplary embodiment of this application;

[0037] Figure 10 This is a flowchart of a system startup method provided in another exemplary embodiment of this application;

[0038] Figure 11 This is a comparison chart of the battery life of an electronic device provided in an exemplary embodiment of this application;

[0039] Figure 12 This is a structural block diagram of a system startup device provided in an exemplary embodiment of this application;

[0040] Figure 13 This is a structural block diagram of a system startup device provided in another exemplary embodiment of this application;

[0041] Figure 14 This is a structural block diagram of an electronic device provided in an exemplary embodiment of this application. Detailed Implementation

[0042] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0043] Traditional electronic devices typically feature a single processor, with an operating system running on that processor handling events. However, as user demands for electronic devices increase, stronger data processing capabilities are required. Therefore, dual-core, dual-system electronic devices have emerged. In one possible implementation, the electronic device includes at least a first processor and a second processor with different processing performance and power consumption. The first system runs on the first processor, and the second system runs on the second processor. Furthermore, the dual-core, dual-system electronic device also incorporates a system switching mechanism.

[0044] For example, products such as smartwatches or smart bracelets can simultaneously include a high-performance processor and a low-power processor, running in the first system and the second system respectively (i.e., dual-core dual-system).

[0045] To reduce power consumption, systems running on low-power processors often handle low-performance events, while switching to systems running on high-power processors handles high-performance events when high-performance processing is required, thus meeting the performance needs of electronic devices.

[0046] Optionally, the first system runs on a low-power processor and the second system runs on a high-performance processor; alternatively, the first system runs on a high-performance processor and the second system runs on a low-power processor.

[0047] In this embodiment, the first processor and the second processor operate asynchronously, and the first system and the second system need to achieve system communication (or dual-core communication). In one possible application scenario, the second system is the Android operating system running on a central processing unit (CPU), and the first system is a real-time operating system (RTOS) running on a microcontroller unit (MCU).

[0048] Figure 1 This is a diagram of a dual-core communication software framework for the Android operating system provided in an exemplary embodiment of this application. The dual-core communication software framework follows the design principles of "low coupling, high reliability, and high reusability," and includes module development for the Kernel, HIDL (Hardware Abstraction Layer Interface Description Language), Native Service, Framework Service, Framework API, and APP (Application) components.

[0049] The APP module includes functional modules such as Launcher, Settings, and SystemUI. The Framework API module includes management modules such as MCUManager, SensorManager, and LocationManager. The Framework Service module includes service modules such as MCUManagerService, SystemSensorManager, and LocationManagerService. The Native Service module includes service modules such as dccservice and Sensorservice. The HIDL module includes modules such as SensorHAL and GPS HAL. The Kernel module includes DCC Transfer Drivers such as dcc_data, MCU_sensor, and MCU_gps.

[0050] As the interface layer connecting the upper and lower layers in the dual-core communication software framework, the transport layer shields the application layer from the transmission details of the lower layer (data link layer) of the system, providing a service channel for application scenarios. The application layer, as the main provider of services, responds to human-computer interaction and transmits the data generated during the human-computer interaction process through the transport layer, as well as responding to external data requests.

[0051] RTOS is designed using the peer-to-peer principle. Taking a smartwatch as an example, Figure 2 This is a diagram of a dual-core communication software framework for an RTOS provided in an exemplary embodiment of this application.

[0052] like Figure 2 As shown, the dual-core communication software framework of RTOS is divided into the Application Layer, Service Layer, Framework Layer, Hardware Abstraction Layer, and Platform Layer.

[0053] The application layer includes modules such as watch face, Daily Tracker, Messagecenter, Voice around Apps, Health Apps, and Settings; the service layer includes modules such as Sport & Health task, System manager task, AMS (Activity Management Service), Audio Service, Log Service, OFTP Service (Odette File Transfer Protocol Service), BT Service, Delegate Service, RPC Service, Sensor Service, and Storage Service; the framework layer includes modules such as Message Pub, UIFramework, G2D Engine, Audio Middleware, Preference, and File. The framework modules include system (file system), Algorithms, and AsyncEvent (in-process asynchronous events); the hardware abstraction layer includes hardware abstraction modules such as Screen / TP (screen / touchscreen), sensors, Keypad, and Motor; the platform layer includes Board Support Package (BSP) and Low-level Drivers. The BSP includes Screen / TP, Codec (encoder / decoder), sensors, Flash, PSRAM (pseudo-static random access memory), etc., while the Low-level Drivers include UART (Universal Asynchronous Receiver / Transmitter), ADC (Analog-to-Digital Converter), GPIO (General Purpose Input / Output), SPI (Serial Peripheral Interface), I2C (Integrated Circuit Bus), IOS (Input / Output System), PCM (Pulse Code Modulation), I2S (Integrated Audio Bus), and HWTimer (Hardware Timer).

[0054] It should be noted that the above dual-core communication software framework is for illustrative purposes only. Those skilled in the art can add, delete or modify the framework according to actual needs. The embodiments of this application do not limit the specific structure of the dual-core communication software framework.

[0055] See Figure 3 , Figure 3 This is a flowchart of a system startup method provided in an exemplary embodiment of this application. The method is applied to an electronic device that supports running a first system and a second system, and the method includes the following steps.

[0056] Step 301: In response to the device startup event, start the first system.

[0057] Optionally, the electronic device is a smartwatch, smart bracelet, or other device that includes a high-performance processor and a low-power processor.

[0058] In electronic devices, a high-performance processor and a low-power processor run a first system and a second system, respectively. Since the first and second processors operate asynchronously, and the first and second systems need to communicate (or dual-core communication), this embodiment uses the example of the second system being the Android operating system running on a central processing unit (CPU), and the first system being a real-time operating system (RTOS) running on a microcontroller unit (MCU) for illustration.

[0059] In one possible implementation, the electronic device includes a first processor and a second processor, wherein the processing performance of the first processor is lower than that of the second processor (both the processing power and speed of the first processor are lower than those of the second processor), and the power consumption of the first processor is lower than that of the second processor. Accordingly, the second system (run by the second processor) is capable of processing events processed by the first system (run by the first processor), but the first system may not necessarily be capable of processing events processed by the second system.

[0060] In another possible implementation, the electronic device may also be equipped with a single processor, with the first system and the second system running on different cores of the processor, wherein the core running the second system has higher processing performance than the core running the first system.

[0061] For example, taking a smartwatch as an electronic device, the first processor is an MCU, the second processor is a CPU, the first system is an RTOS, and the second system is an Android system. Correspondingly, the events that the first system can handle include scenarios with low processing performance requirements or weak interaction scenarios such as watch face display, watch face interface switching, and notification message display; the events that the second system can handle include scenarios with high processing performance requirements or strong interaction scenarios such as answering calls, launching applications, watch face editing, and function settings.

[0062] Unlike smartphones, which are electronic devices with strong interactive features, wearable devices, as auxiliary electronic devices, have only weak interactions with users in most usage scenarios. For example, in most situations, users only use smartwatches to raise their wrists to check the time. Therefore, when wearable devices process events through the first system, the second processor can be kept in a sleep state (the second system is in a sleep state), thereby reducing the overall power consumption of the wearable device.

[0063] In one possible implementation, the operating mode of the electronic device includes one or more of performance mode, hybrid mode, and low-power mode. The electronic device can possess one or more of these modes according to product requirements, all of which are within the scope of this application. For example, in performance mode, screen control always belongs to the high-performance processor (such as the higher-performance second system in the first and second systems), and both systems run when processing business. In low-power mode, only the lower-power processor (such as the first processor) remains awake or in sleep mode, while the higher-power processor (such as the second processor) remains off; this can also be understood as the low-power system not shutting down and the high-power system shutting down. In hybrid mode, both the first and second systems may be in running or sleep mode, automatically switching according to business needs to balance power consumption and performance. For example, when only the first system processes events, the second processor is in... In a hibernation state, the second processor (second system) is only awakened to handle tasks requiring its processing. In some embodiments, when the second processor is awakened, the first processor (first system) may not be in hibernation and can assist the second processor (second system). In some embodiments, when there is no business demand, both the first and second processors (second systems) are in hibernation. In some embodiments, in hybrid mode, screen control permissions can also switch between the first and second systems. For example, when an application is running on the second system, screen control permissions belong to the second system; when the second system is in hibernation, screen control permissions belong to the first system. It is understood that the electronic device of this application can also operate in other modes, and this is not limited.

[0064] Optionally, in the wake-up state, system-related data is cached in memory (RAM) for easy access. In the hibernation state, most of the processor's hardware modules are shut down, and system-related data is stored in the hard disk (ROM), which is then written into memory when switching to the wake-up state.

[0065] In related technologies, when an electronic device starts up, a second system with higher power consumption is started first, and then the second system starts a first system with lower power consumption. After both the first and second systems are started, the electronic device then operates in the corresponding working mode.

[0066] In this embodiment, considering the significant time interval between the startup of the second system and its actual use by the user, and the unnecessary power consumption regardless of the operating mode entered after startup, this application proposes a system delayed startup mechanism to further save device power consumption. Specifically, in the event of a device startup event, the electronic device first starts the first system, but temporarily postpones the startup of the second system.

[0067] Optionally, the device startup event can be a power-on event triggered by the user pressing a physical button, a device restart event triggered by the first system within the electronic device, or an event that does not immediately require processing by the second system after the other electronic devices have started. This application embodiment does not limit this.

[0068] In one possible implementation, in response to a device startup event, the electronic device first starts a first system, and after the first system starts, it keeps the first system in operation to respond to user operations.

[0069] Indicative, such as Figure 4 As shown, when a device startup event occurs, the electronic device starts the first system, displays the startup screen 401, and after startup is complete, displays the main interface 402 through the first system.

[0070] Step 302: During the operation of the first system, if the system startup conditions of the second system are met, the first system starts the second system.

[0071] In some embodiments, in order to meet the user's needs for using the second system, during the operation of the first system, the first system may also determine whether to start the second system by judging whether the system startup conditions of the second system are met. Thus, if the system startup conditions of the second system are met, the first system starts the second system and switches the second system from the shutdown state to the startup state.

[0072] Optionally, the system startup condition can be a time condition for system startup, an event that requires the second system to be started, or an operational condition for system startup, etc. This application embodiment does not limit this.

[0073] Optionally, starting the second system refers to powering on the second system, switching it from a power-off state to a standby state. It should be noted that the startup process of the second system differs from its wake-up process. Optionally, the startup time of the second system is longer than its wake-up time, and the startup speed is slower than its wake-up speed. Furthermore, no device power is consumed before the second system starts up, whereas it consumes power while in sleep mode before waking up.

[0074] Optionally, the first system starts the second system in the background. In one possible implementation, the electronic device displays the application interface of the application supported by the first system in the foreground and starts the second system through the first system. In another possible implementation, the electronic device displays the system startup prompt interface corresponding to the second system through the first system and starts the second system through the first system.

[0075] Indicative, such as Figure 4 As shown, during the operation of the first system, if the system startup conditions of the second system are met, the first system starts the second system and displays the corresponding system startup prompt interface 403 of the second system.

[0076] Step 303: After the second system starts up, the first system and the second system synchronize information.

[0077] In some embodiments, after the second system is started, in order to facilitate the switching of subsequent working modes and improve the collaboration efficiency between the first and second systems, the electronic device also needs to synchronize information with the second system through the first system.

[0078] Optionally, the information synchronized between the first system and the second system may include device status information, notification information, interface information, operation information, etc., which are not limited in this embodiment. For example, the first system may synchronize system time with the second system or synchronize user operations with the second system.

[0079] In one possible implementation, after the second system starts up, the second system sends a message to the first system indicating that the startup is complete. Upon receiving the message, the first system then synchronizes its information with the second system.

[0080] In summary, in this embodiment of the application, a system delayed startup mechanism is set for electronic devices that support the operation of both the first and second systems. That is, in response to a device startup event, only the first system is started first. During the operation of the first system, if the system startup conditions of the second system are met, the first system then starts the second system to synchronize information with it. By delaying the startup time of the second system, the situation where the second system is started but idle can be avoided, effectively saving device power consumption and extending device battery life.

[0081] In some embodiments, the first system may determine the system startup conditions of the second system in different ways. Optionally, the first system may actively determine whether to start the second system based on the corresponding auto-start conditions of the second system. Optionally, the first system may also determine whether to start the second system based on user operations. The two condition determination methods will be described below.

[0082] 1) If the self-starting conditions of the second system are met, the first system starts the second system. The self-starting conditions are determined based on the historical usage records of the second system.

[0083] In one possible implementation, in order to enable the second system to start without the user's awareness, optimize the device user experience, and avoid the phenomenon that the second system is still not started when the user needs to use it, the automatic startup conditions of the second system can be set. The first system can actively start the second system by judging the automatic startup conditions, so that the second system is already in a ready-to-run state when the user needs to use it, thus shortening the system response time.

[0084] Optionally, the auto-start condition of the second system can be determined based on the historical usage records of the second system. Optionally, the historical usage records of the second system can be system-level historical usage records or historical usage records of the various applications supported by the second system; this embodiment does not limit this. For example, the auto-start condition can be determined based on the historical usage time or historical system events of the second system, or it can be determined based on the historical usage time or historical application events of the various applications supported by the second system.

[0085] Optionally, the self-starting conditions of the second system can also be preset by the developers or set by the user according to their own device usage habits. This application embodiment does not limit this.

[0086] In one possible implementation, during the operation of the first system, the first system determines in real time whether the self-starting conditions of the second system are met, and then starts the second system if the self-starting conditions of the second system are met.

[0087] Optionally, the self-starting condition of the second system can be a time condition, such as the system startup time, which is also determined based on the historical usage records of the second system.

[0088] In one possible implementation, during the operation of the first system, the first system determines in real time whether the system startup time of the second system has been reached based on the system time, and then the first system starts the second system when the system startup time of the second system is reached.

[0089] To illustrate, the system starts at 8:00 every day. At 8:00, the first system starts the second system, and the second system is in a shut-off (power off) state before 8:00.

[0090] Optionally, the self-starting condition of the second system can also be a combination of time conditions and other conditions, such as a combination of time conditions and application events, or a combination of time conditions and system events, etc.

[0091] Optionally, the self-starting condition of the second system can be set as a combination of time conditions and application messages. In one possible implementation, to further save device power consumption, when the system startup time of the second system is reached, the first system may also temporarily not start the second system, but continue to wait for notification messages from applications supported by the second system. Then, upon receiving a notification message from the first application supported by the second system, the first system will start the second system, and after the second system starts, the first system will synchronize notification information to the second system.

[0092] Optionally, the notification message received by the first system from the first application can come from a terminal device that is connected to the electronic device via Bluetooth. For example, if the first system in the electronic device does not support running instant messaging applications, but the second system does, then the second system needs to be launched when it receives an instant messaging message transmitted via Bluetooth from the terminal device.

[0093] For example, the system starts at 8:00 every day. When 8:00 is reached, the first system does not start the second system. Only when 8:00 is reached and a notification message from the first application is received, the first system starts the second system and synchronizes the notification message with the second system so that the second system can run the first application and display the notification message to the user.

[0094] Indicative, such as Figure 5 As shown, the first system is currently in a wake-up state, displaying the main interface 501. Upon receiving a notification message from the terminal device transmitted via Bluetooth for the first application, the first system starts the second system in the background. After the second system starts, it opens the first application and displays the notification message interface 502 corresponding to the first application.

[0095] Regarding the method for determining the system startup time of the second system, in one possible implementation, the first system can obtain the application usage time of each application supported by the second system within a historical time period, and thus the first system determines the system startup time of the second system based on the application usage time of each application.

[0096] For example, the historical time period is the 7 days prior to the current date. That is, the first system obtains the application usage time of each application supported by the second system within the past 7 days, and determines the system startup time of the second system based on the application usage time of each application.

[0097] Optionally, in order to ensure the accuracy and regularity of the system startup time, the historical time period may include at least two unit time periods, so as to regularly determine the system startup time of the second system from the application usage time of each application within multiple unit time periods.

[0098] In one possible implementation, the first system can determine the intersection of application usage times between different time units based on the application usage time of each application within each time unit, and thus determine the start time of the intersection of application usage times as the system startup time.

[0099] For example, if the historical time period is the three days prior to the current date, then each day can be considered a unit of time. The first system can then determine the intersection of application usage times over the three days based on the daily usage time of each application. For instance, if the application usage time on the first day is 8:30 AM to 7:30 PM, the second day is 9:00 AM to 9:30 PM, and the third day is 8:40 AM to 8:30 PM, then the intersection of application usage times is 9:00 AM to 7:30 PM. Therefore, the system startup time can be determined to be 9:00 AM each day.

[0100] In another possible implementation, considering that when determining the system startup time based on the intersection of application usage time, it is very likely that the time when the user needs to use the second system is earlier than the system startup time, which would require the user to wait for the second system to start, from the perspective of device user experience, in order to fully meet the user's needs for the second system, the first system can also determine the union of application usage time between different unit time periods based on the application usage time of each application within each unit time period, and thus determine the start time of the union of application usage time as the system startup time.

[0101] For example, if the historical time period is the three days prior to the current date, then each day can be considered a unit of time. The first system can then determine the union of application usage times over the three days based on the daily usage time of each application. For instance, if the application usage time on the first day is 8:30 AM to 7:30 PM, the application usage time on the second day is 9:00 AM to 9:30 PM, and the application usage time on the third day is 8:40 AM to 8:30 PM, then the union of application usage times is 8:30 AM to 9:30 PM. Therefore, the system startup time can be determined as 8:30 AM each day.

[0102] Optionally, in order to optimize the process of determining the system startup time, before determining the system startup time based on the application usage time of each application, each application can be filtered and selected based on the application usage frequency of each application within a historical time period, so as to determine the system startup time of the second system based on the application usage time of the filtered applications.

[0103] Optionally, an application usage frequency threshold can be set to filter applications based on this threshold. In one possible implementation, the first system statistically analyzes the application usage time and frequency of each application within a historical time period, thereby filtering applications whose usage frequency is less than the application usage frequency threshold, and determining the system startup time of the second system based on the application usage time of each application whose usage frequency is not less than the application usage frequency threshold.

[0104] Optionally, to further optimize the process of determining the system startup time, the applications within a historical time period can be filtered and selected based on their application priorities, and the system startup time of the second system can be determined based on the application usage time of each selected application.

[0105] The application priority can be determined based on factors such as the frequency of application use and user preferences for each application; however, this application does not limit this.

[0106] Optionally, the first system can also transmit the usage data of each application within the collected historical time period to the terminal device via Bluetooth communication, so that the terminal device can output the system startup time of the second system through the large language model.

[0107] Optionally, the system startup time of the second system can also be manually set by the user according to their own usage habits. This application embodiment only illustrates the method of determining the system startup time, but does not limit it.

[0108] Corresponding to the system startup conditions, considering that the user may no longer be using the second system before the electronic device is turned off, even if the second system is in a dormant state, there will still be power consumption loss. For example, if the electronic device monitors the user's sleep and restarts every day when exiting sleep mode, there may be situations where the user has stopped using the second system before entering sleep mode. Therefore, to further optimize device power consumption, in one possible implementation, the first system can also determine the system shutdown conditions of the second system, so that the first system shuts down the second system when the system shutdown conditions of the second system are met.

[0109] Optionally, the system shutdown conditions can also be determined based on the historical usage records of the second system.

[0110] Optionally, the system shutdown condition can be a time condition, such as the system shutdown time, which is also determined based on the historical usage records of the second system.

[0111] In one possible implementation, during the operation of the first system, the first system determines in real time whether the system shutdown time of the second system has been reached based on the system time. When the system shutdown time of the second system is reached, the first system shuts down the second system, that is, the second system changes from the power-on state to the power-off state.

[0112] Regarding the method for determining the system shutdown time of the second system, please refer to the specific implementation of determining the system startup time of the second system described above, which will not be repeated here.

[0113] In some embodiments, in order to obtain the application usage records of each application supported by the second system in a sufficiently efficient manner, the second system may not be delayed in starting before the self-starting conditions of the second system are determined. Instead, the second system may be set to a hibernation state only when it is not in use, thereby shortening the system switching time when the user needs to use the second system.

[0114] In one possible implementation, if the conditions for the second system to start automatically are not determined, in response to a device startup event, the electronic device can first start the first system and then start the second system through the first system. After the second system starts, it is controlled to enter a sleep state. Then, upon receiving an application launch operation for the second application, and if the second application is an application supported by the second system, the first system wakes up the second system. The second system then switches to foreground operation, obtains screen control permissions, displays the application interface of the second application, and responds to user operations within the second application.

[0115] In other words, if the conditions for the second system to start automatically are not determined, in order to collect enough historical usage records of the second system and effectively save device power consumption during the data collection process, the second system can be directly controlled to enter a hibernation state after it starts.

[0116] Please refer to the above embodiments. Figure 6 The diagram illustrates a timing diagram of system startup provided in an exemplary embodiment of this application. When a device startup event occurs, the electronic device starts the first system and displays a boot screen. During the operation of the first system, it determines whether the self-starting conditions of the second system are met. If the self-starting conditions are met, the first system starts the second system. After the second system finishes starting, it sends a startup completion message back to the first system, and the first and second systems synchronize their information.

[0117] 2) When the first system receives a system startup operation and the system startup operation meets the startup conditions of the second system, the first system starts the second system.

[0118] Optionally, to improve the flexibility of starting the second system, it is also possible to directly determine whether to start the second system based on user operations. In one possible implementation, if the first system receives a system startup operation and the system startup operation meets the startup conditions of the second system, the first system starts the second system.

[0119] Optionally, the system startup operation that meets the startup conditions of the second system can be a system switching operation, such as switching from the first system to the second system through a system switching control; or it can be an application startup operation for applications that the second system supports running, such as clicking the application icon.

[0120] In one possible implementation, upon receiving a user's application launch operation for a third application, and the third application being an application supported by the second system, the first system starts the second system. After the second system starts, in order to ensure a smooth system switching, the first system synchronizes the application launch operation with the second system. The second system obtains screen control permissions, and thus the second system responds to the application launch operation and displays the application interface of the third application.

[0121] Considering that the user's operation to open the third application is received by the first system during the operation of the first system, and the second system may be in two states while the first system is running: one is a power-off and not started state, and the other is started and in a dormant state, in order to determine whether to start the second system or wake up the second system, when the first system receives the user's operation to open the third application, it can first determine whether the second system has been started, and then execute different processes according to the determination result.

[0122] Optionally, the first system can determine whether the second system has started by checking whether the corresponding system startup pin of the second system has been pulled up. If the pin is pulled up, it indicates that the second system has started; if the pin is not pulled up, it indicates that the second system has not started.

[0123] In one possible implementation, upon receiving a user's application launch command for a third application, and if the third application is an application supported by the second system and the second system is not yet running, the first system can launch the second system. Then, after the second system launches, the first system synchronizes the application launch command with the second system, which then responds to the command and displays the application interface of the third application.

[0124] Optionally, considering that the system startup time may be long, in order to inform the user that the second system is currently starting, when the first system receives the user's application opening operation for the third application, and the third application is an application supported by the second system and the second system has not started, the first system may first display the loading screen, and start the second system during the display of the loading screen.

[0125] Optionally, the loading interface is stored and managed by the first system. Optionally, the loading interface may include the system startup identifier and system startup progress corresponding to the second system, and may also include other content that may be displayed, which is not limited in this embodiment.

[0126] Optionally, the content displayed on the loading screen and the boot screen may be the same or different, and this application embodiment does not limit this.

[0127] Indicative, such as Figure 7 As shown, at this time, only the first system is started and is running in the foreground, displaying the application list interface 701. Therefore, when the user's operation to open the third application is received, and the third application is an application supported by the second system, and the second system is not started, the first system displays the loading interface 702, and during the display of the loading interface, the second system is started. Then, after the second system starts, the second system displays the application interface 703 of the third application.

[0128] In another possible implementation, when the first system receives a user's application launch operation for a third application, and the third application is an application supported by the second system and the second system is already running and in a dormant state, the first system can directly wake up the second system and synchronize the application launch operation to the second system, so that the second system responds to the application launch operation and displays the application interface of the third application.

[0129] As can be seen from the above two scenarios, starting the second system means changing the second system from a power-off state to a power-on state, and the system startup pin corresponding to the second system switches from a never-pull-up state to a pulled-up state; while waking up the second system means switching the second system from a hibernation state to a running state, and the system startup pin corresponding to the second system is always in a pulled-up state.

[0130] Please refer to the above embodiments. Figure 8This illustration shows a timing diagram of system startup provided by another exemplary embodiment of this application. When a device startup event occurs, the electronic device starts the first system and displays a boot screen through the first system. During the operation of the first system, if it receives a user's application startup operation and the application is an application supported by the second system, the first system displays a loading interface, and during the display of the loading interface, the second system is launched. Then, after the second system has started, it sends a startup completion message to the first system. The first system synchronizes information with the second system and synchronizes the application startup operation to the second system, thereby the second system responds to the application startup operation and launches the application.

[0131] The above embodiments provide two methods for determining whether to start the second system: one is to start the second system automatically when the self-starting conditions are met; the other is to start the second system manually when a system start operation is received. By using these two methods to delay starting the second system, it is possible to save device power consumption while ensuring the user's need for the second system, thus optimizing the user's device experience.

[0132] In addition, by setting system shutdown conditions, the second system can be shut down in advance before the device is turned off, which can further save device power consumption and extend device battery life.

[0133] In some embodiments, considering that there may be events that need to be processed by the second system immediately after the device starts up, such as the current device startup event being triggered by an alarm event in the second system, or the current device startup event being a system upgrade / update / restart event related to the second system, the electronic device also needs to determine the device startup event and, based on whether the device startup event is a startup event in the second system, whether to adopt a delayed startup method for the second system.

[0134] The startup event within the second system refers to the event that needs to be processed immediately by the second system after the device starts up. Optionally, the startup event within the second system can be a startup event triggered by an alarm event within the second system, a startup event triggered by a system update event within the second system, or other possible startup events. This application embodiment does not limit the specific startup events.

[0135] In one possible implementation, if a device startup event exists, but the device startup event is not a startup event within the second system, the electronic device adopts a second system delayed startup mechanism, first starting the first system, and then, during the operation of the first system, determining whether to start the second system based on whether the system startup conditions of the second system are met.

[0136] In another possible implementation, when a device startup event occurs, and this startup event is within the second system, the electronic device starts the first system and then starts the second system through the first system. Thus, the second system is in a wake-up state and has screen control permissions; the first system can be in a wake-up state or a sleep state. That is, the electronic device can operate in either a performance mode or a hybrid mode where the second system is running.

[0137] In one possible implementation, when the operating mode of the electronic device is switched, such as from low power mode to hybrid mode, since only the first system is started in low power mode, while the second system needs to be started in hybrid mode, a device startup event may be triggered. That is, in the case of mode switching, the electronic device needs to be restarted to achieve mode switching. At this time, the electronic device needs to start the first system first, and then start the second system through the first system after the first system is started.

[0138] As can be seen from the above embodiments, regardless of whether the second system is started later, the first system is started first when the device starts up in this embodiment. Therefore, to indicate to the user that the device is currently in the startup phase, in one possible implementation, a boot screen can be displayed through the first system during its startup process.

[0139] Optionally, the boot screen is stored and managed by the first system. Optionally, the boot screen may include a device startup identifier and device startup progress, and may also include other content that may be displayed; this embodiment does not limit this. Optionally, regardless of whether the second system is delayed in starting, the boot screen displayed by the first system is the same when the device starts, that is, during the device startup process, the startup of the second system is seamlessly delayed.

[0140] Please refer to the above embodiments. Figure 9 This illustrates a timing diagram of system startup provided by another exemplary embodiment of this application. When a device startup event exists, and this device startup event is a startup event within the second system, the electronic device starts the first system and displays a boot screen through the first system. After the first system starts, it directly starts the second system through the first system, whereby the second system obtains screen control permissions and processes the corresponding events.

[0141] In some embodiments, considering that different users have different device usage needs, a switch button can be set for the system delayed startup function in order to optimize the user experience. After receiving the user's operation to enable the system delayed startup function, the electronic device will delay starting the second system.

[0142] Optionally, the first system can receive the user's operation to enable the system delayed start function, so that when there is a device start event and the system delayed start function is enabled, the electronic device starts the first system, and the first system does not start the second system for the time being, and during the operation, it determines in real time whether the system start conditions of the second system are met.

[0143] Optionally, the second system may receive the user's activation command for the system's delayed startup function, and then transmit the activation message to the first system. When a device startup event occurs and the system's delayed startup function is enabled, the electronic device starts the first system, and the first system temporarily does not start the second system. During operation, the system continuously checks whether the startup conditions of the second system are met.

[0144] In the above embodiments, by determining whether the device startup event is a startup event within the second system, the mechanism for delaying the startup of the second system is optimized, thus ensuring a better user experience. Furthermore, by providing a toggle switch for the system delay startup function, the system's delayed startup mechanism can be applied according to user needs, further optimizing the user's device experience.

[0145] Please refer to Figure 10 The diagram illustrates a flowchart of a system startup method provided in an exemplary embodiment of this application.

[0146] Step 1001: When the first system has started but the second system has not started, the first system displays the boot screen during the startup process of the second system.

[0147] In some embodiments, when the first system has started but the second system has not started, during the operation of the first system, the first system can determine whether to start the second system by judging whether the system startup conditions of the second system are met, and display the boot screen during the startup process of the second system.

[0148] Optionally, the boot screen is used to notify the user that the second system is starting up. Optionally, the boot screen can be stored and managed by the first system, and the boot screen may include information such as the boot progress of the second system; this embodiment of the application does not limit this.

[0149] In one possible implementation, the first system can trigger the startup of the second system based on the user's historical usage information. The user's historical usage information may include the user's usage information of the second system, such as the system usage time of the second system, the usage time of each application supported by the second system, etc., and may also include other usage information, which is not limited in this embodiment.

[0150] Step 1002: After the second system starts up, the second system obtains screen control permissions from the first system.

[0151] In some embodiments, after the second system starts up, the second system can obtain screen control permissions from the first system to display the system interface corresponding to the second system, or run applications supported by the second system.

[0152] It should be noted that the steps of the system startup method proposed in the above embodiments can be combined or substituted with each other, and this application does not limit the combination and substitution of the steps. For example, the first system in each embodiment can be the same system and can be substituted for each other, and the second system in each embodiment can be the same system and can be substituted for each other. Furthermore, the features related to the first system and the second system in each embodiment can also be combined or substituted for each other without conflict.

[0153] Please refer to Figure 11 The diagram illustrates a comparison of the battery life of an electronic device provided in an exemplary embodiment of this application. Taking the electronic device's operating mode as hybrid mode (both the first and second systems are on) as an example, the device's battery life is 5 days; and its operating mode as low-power mode (the first system is on, the second system is off) as an example, the device's battery life is 15 days. After adopting the system delayed startup function proposed in this embodiment, the electronic device starts both the first and second systems on the first day to facilitate the collection of historical usage records of the second system. If the user does not use the second system, from the second day onwards, the electronic device can only start the first system without starting the second system. Therefore, the device's battery life can reach 1 + 12 = 13 days.

[0154] See Figure 12 , Figure 12 This is a structural block diagram of a system startup apparatus provided in an exemplary embodiment of this application. The apparatus is used in an electronic device that supports the operation of a first system and a second system. The apparatus includes:

[0155] The first system module 1201 is used to start the first system in response to a device startup event;

[0156] The first system module 1201 is used to start the second system during the operation of the first system, provided that the system startup conditions of the second system are met;

[0157] The first system module 1201 is also used to synchronize information with the second system module 1202 after the second system is started.

[0158] Optionally, the first system module 1201 is used for:

[0159] The second system is started when the self-starting conditions of the second system are met, and the self-starting conditions are determined based on the historical usage records of the second system.

[0160] When the first system receives a system startup operation and the system startup operation meets the startup conditions of the second system, the second system is started.

[0161] Optionally, the first system module 1201 is used for:

[0162] When the system startup time of the second system is reached, the second system is started, and the system startup time is determined based on the historical usage records of the second system.

[0163] Optionally, the first system module 1201 is used for:

[0164] When the system startup time of the second system is reached and a notification message of the first application supported by the second system is received, the second system is started.

[0165] The first system module 1201 is used for:

[0166] After the second system starts, the notification message is synchronized to the second system module 1202.

[0167] Optionally, the first system module 1201 is used for:

[0168] Obtain the application usage time of each application supported by the second system within a historical time period; determine the system startup time of the second system based on the application usage time of each application.

[0169] Optionally, the historical time period includes at least two unit time periods; the first system module 1201 is used for:

[0170] Based on the application usage time of each application within each of the aforementioned time units, the intersection of application usage times between different time units is determined; the starting time of the intersection of application usage times is determined as the system startup time.

[0171] Optionally, the first system module 1201 is used for:

[0172] If the system shutdown conditions of the second system are met, the second system is shut down, and the system shutdown conditions are determined based on the historical usage records of the second system.

[0173] Optionally, the first system module 1201 is used for:

[0174] If the self-starting conditions of the second system are not determined, the first system is started in response to the device startup event;

[0175] The second system is started, and then enters hibernation mode.

[0176] Upon receiving an application launch command for a second application, and if the second application is an application supported by the second system, the second system is woken up.

[0177] Optionally, the first system module 1201 is used for:

[0178] Upon receiving an application launch command for a third application, and if the third application is an application supported by the second system, the second system is launched.

[0179] The first system module 1201 is used for:

[0180] After the second system starts, the application startup operation is synchronized to the second system module 1202;

[0181] The second system module 1202 is used to respond to the application opening operation and display the application interface of the third application.

[0182] Optionally, the first system module 1201 is used for:

[0183] Upon receiving an application launch operation for the third application, and the third application is an application supported by the second system, and the second system is not started, a loading screen is displayed;

[0184] During the display of the loading interface, the second system is launched.

[0185] Optionally, the first system module 1201 is used for:

[0186] Upon receiving an application launch operation for the third application, and the third application is an application supported by the second system, and the second system is already started and in a dormant state, the second system is woken up.

[0187] Synchronize the application startup operation with the second system module 1202;

[0188] The second system module 1202 is used to respond to the application opening operation and display the application interface of the third application.

[0189] Optionally, the first system module 1201 is used for:

[0190] If the device startup event exists, and the device startup event is not a startup event within the second system, then the first system is started;

[0191] If the device startup event exists and the device startup event is the startup event within the second system, the first system is started; the second system is started, and the second system is in a wake-up state.

[0192] In summary, in this embodiment of the application, a system delayed startup mechanism is set for electronic devices that support the operation of both the first and second systems. That is, in response to a device startup event, only the first system is started first. During the operation of the first system, if the system startup conditions of the second system are met, the first system then starts the second system to synchronize information with it. By delaying the startup time of the second system, the situation where the second system is started but idle can be avoided, effectively saving device power consumption and extending device battery life.

[0193] See Figure 13 , Figure 13 This is a structural block diagram of a system startup apparatus provided in an exemplary embodiment of this application. The apparatus is used in an electronic device that supports the operation of a first system and a second system. The apparatus includes:

[0194] The first system module 1301 is used to display a boot screen during the boot process of the second system when the first system has been started but the second system has not been started.

[0195] The second system module 1302 is used to obtain screen control permissions from the first system module after the second system is started.

[0196] Optionally, the first system module 1301 triggers the second system to start based on the user's historical usage information, which includes the user's usage information of the second system.

[0197] Please refer to Figure 14 , Figure 14 This is a structural block diagram of an electronic device provided in an exemplary embodiment of this application. The electronic device in this application may include one or more of the following components: processor 1410 and memory 1420.

[0198] Optionally, the processor 1410 includes at least a first processor 1411 and a second processor 1412, wherein the first processor 1411 is used to run a first system, and the second processor 1412 is used to run a second system. In some embodiments, the power consumption of the first processor 1411 is lower than that of the second processor 1412, and the performance of the first processor 1411 is lower than that of the second processor 1412. In other embodiments, the power consumption of the first processor 1411 is higher than that of the second processor 1412, and the performance of the first processor 1411 is higher than that of the second processor 1412. For example, the power consumption of the first processor 1411 and the power consumption of the second processor 1412 can be understood as standby (sleep) power consumption, power consumption when processing the same service, or overall power consumption, etc., and can be measured using an ammeter. For example, the performance of the first processor 1411 and the performance of the second processor 1412 can be understood as computing power or hardware resources, etc. The processor 1410 connects various parts within the electronic device using various interfaces and lines. It performs various functions and processes data by running or executing instructions, programs, code sets, or instruction sets stored in the memory 1420, and by calling data stored in the memory 1420. Optionally, the processor 1410 can be implemented using at least one hardware form of Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), or Programmable Logic Array (PLA). The processor 1410 can integrate one or a combination of several of the following: Central Processing Unit (CPU), Graphics Processing Unit (GPU), Neural-network Processing Unit (NPU), and modem. Specifically, the CPU primarily handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the content required for display on the touch screen; the NPU is used to implement Artificial Intelligence (AI) functions; and the modem is used for wireless communication. It is understandable that the aforementioned modem may not be integrated into the processor 1410, but may be implemented as a separate chip.

[0199] The memory 1420 may include random access memory (RAM) or read-only memory (ROM). Optionally, the memory 1420 may include a non-transitory computer-readable storage medium. The memory 1420 may be used to store instructions, programs, code, code sets, or instruction sets. The memory 1420 may include a program storage area and a data storage area, wherein the program storage area may store instructions for implementing an operating system, instructions for at least one function (such as touch function, sound playback function, image playback function, etc.), instructions for implementing the various method embodiments described below, etc.; the data storage area may store data created according to the use of the electronic device (such as audio data, phone book, etc.).

[0200] The electronic device in this embodiment further includes a communication component 1430 and a display component 1440. The communication component 1430 can be a Bluetooth component, a WiFi (Wireless Fidelity) component, an NFC (Near Field Communication) component, etc., used to communicate with external devices (servers or other terminal devices) via wired or wireless networks; the display component 1440 is used to display a graphical user interface and / or receive user interaction operations.

[0201] In addition, those skilled in the art will understand that the structure of the electronic device shown in the above figures does not constitute a limitation on the electronic device. The electronic device may include more or fewer components than shown, or combine certain components, or have different component arrangements. For example, the electronic device may also include radio frequency circuits, input units, sensors, audio circuits, speakers, microphones, power supplies, etc., which will not be described in detail here.

[0202] This application also provides a computer-readable storage medium storing at least one computer instruction, which is loaded and executed by a processor to implement the system startup method as described in the above embodiments.

[0203] Optionally, the computer-readable storage medium may include ROM, RAM, solid-state drives (SSDs), or optical discs. RAM may include resistive random access memory (ReRAM) and dynamic random access memory (DRAM).

[0204] This application also provides a computer program product, which includes computer instructions stored in a computer-readable storage medium; a processor of an electronic device reads the computer instructions from the computer-readable storage medium and executes the computer instructions to cause the electronic device to perform the system startup method as described in the above embodiments.

[0205] The above description is merely an optional embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A system startup method, characterized in that, The method is used in an electronic device that supports the operation of a first system and a second system. The method includes: In response to a device startup event, the first system is started; During the operation of the first system, if the system startup conditions of the second system are met, the first system starts the second system; After the second system is started, the first system and the second system synchronize information.

2. The method according to claim 1, characterized in that, The first system starting the second system when the system startup conditions of the second system are met includes at least one of the following: If the self-starting conditions of the second system are met, the first system starts the second system, and the self-starting conditions are determined based on the historical usage records of the second system. When the first system receives a system startup operation and the system startup operation meets the startup conditions of the second system, the first system starts the second system.

3. The method according to claim 2, characterized in that, The step of the first system starting the second system when the self-starting conditions of the second system are met includes: When the system startup time of the second system is reached, the first system starts the second system, and the system startup time is determined based on the historical usage records of the second system.

4. The method according to claim 3, characterized in that, The step of the first system starting the second system when the system startup time of the second system is reached includes: When the system startup time of the second system is reached and a notification message of the first application supported by the second system is received, the first system starts the second system. After the second system starts, the first system synchronizes information with the second system, including: After the second system starts up, the first system synchronizes the notification message to the second system.

5. The method according to claim 3, characterized in that, The method further includes: The first system obtains the application usage time of each application supported by the second system within a historical time period; The first system determines the system startup time of the second system based on the application usage time of each application.

6. The method according to claim 5, characterized in that, The historical time period includes at least two time units; The first system determines the system startup time of the second system based on the application usage time of each application, including: The first system determines the intersection of application usage time between different time units based on the application usage time of each application within each unit time period; The first system determines the start time of the intersection of the application usage times as the system startup time.

7. The method according to claim 2, characterized in that, The method further includes: If the system shutdown conditions of the second system are met, the first system shuts down the second system, and the system shutdown conditions are determined based on the historical usage records of the second system.

8. The method according to claim 2, characterized in that, The method further includes: If the self-starting conditions of the second system are not determined, the first system is started in response to the device startup event; The first system starts the second system, and the second system enters a hibernation state; Upon receiving an application launch command for a second application, and if the second application is an application supported by the second system, the first system wakes up the second system.

9. The method according to claim 2, characterized in that, The step of starting the second system when the first system receives a system startup operation and the system startup operation meets the startup conditions of the second system includes: Upon receiving an application launch command for a third application, and the third application being an application supported by the second system, the first system launches the second system. After the second system starts, the first system synchronizes information with the second system, including: After the second system starts, the first system synchronizes the application startup operation to the second system; The second system responds to the application launch operation and displays the application interface of the third application.

10. The method according to claim 9, characterized in that, When the first system receives an application launch operation for a third application, and the third application is an application supported by the second system, the second system starts the second system, including: When the system receives an application launch operation for the third application, and the third application is an application supported by the second system, and the second system is not started, the first system displays a loading screen. During the display of the loading interface, the first system launches the second system.

11. The method according to claim 10, characterized in that, The method further includes: Upon receiving an application launch operation for the third application, and the third application is an application supported by the second system, and the second system is already started and in a dormant state, the first system wakes up the second system. The first system synchronizes the application startup operation with the second system; The second system responds to the application launch operation and displays the application interface of the third application.

12. The method according to any one of claims 1 to 11, characterized in that, The step of starting the first system in response to a device startup event includes: If the device startup event exists, and the device startup event is not a startup event within the second system, then the first system is started; The method further includes: If the device startup event exists, and the device startup event is the startup event within the second system, then the first system is started; The first system starts the second system, and the second system is in a wake-up state.

13. A system startup method, characterized in that, The method is used in an electronic device that supports the operation of a first system and a second system. The method includes: When the first system has started but the second system has not started, the first system displays the boot screen during the startup process of the second system; After the second system starts up, the second system obtains screen control permissions from the first system.

14. The system startup method according to claim 13, characterized in that, The first system triggers the second system to start based on the user's historical usage information, which includes the user's usage information of the second system.

15. A system startup device, characterized in that, The device is used in an electronic device, which supports the operation of a first system and a second system. The device includes: The first system module is used to start the first system in response to a device startup event; The first system module is used to start the second system during the operation of the first system, provided that the system startup conditions of the second system are met; The first system module is also used to synchronize information with the second system module after the second system is started.

16. A system startup device, characterized in that, The device is used in an electronic device, which supports the operation of a first system and a second system. The device includes: The first system module is used to display the boot screen during the boot process of the second system when the first system has been started but the second system has not been started. The second system module is used to obtain screen control permissions from the first system module after the second system is started.

17. An electronic device, characterized in that, The electronic device includes a processor and a memory; the memory stores at least one computer instruction, which is executed by the processor to implement the system startup method as described in any one of claims 1 to 12, or the system startup method as described in any one of claims 13 to 14.

18. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores at least one computer instruction, which is loaded and executed by a processor to implement the system startup method as described in any one of claims 1 to 12, or the system startup method as described in any one of claims 13 to 14.

19. A computer program product, characterized in that, The computer program product includes computer instructions stored in a computer-readable storage medium; a processor of an electronic device reads the computer instructions from the computer-readable storage medium and executes the computer instructions to cause the electronic device to perform the system startup method as described in any one of claims 1 to 12, or the system startup method as described in any one of claims 13 to 14.

Images