Standby method and electronic device

Abstract

The embodiment of the present application provides a standby method and an electronic device. In the technical scheme provided by the embodiment of the present application, the standby method comprises: the electronic device enters a first standby scene, the first standby scene is a scene that the electronic device responds to a screen-off operation of a user when executing a first event through a first application, and the first event applies a first wake-up lock; a second wake-up lock of a second standby scene is applied according to a second event, the second standby scene is a scene that the electronic device executes a second event through a second application in a standby state; the application of the second wake-up lock is passed or rejected according to a relationship among the first standby scene, the second standby scene and a standby scene; after the first wake-up lock is released and the screen is turned off, or after the first wake-up lock and the second wake-up lock are both released and the screen is turned off, the standby state is entered, and the wake-up lock is controlled according to the scene, so that the electronic device is controllable and flexible in the scene of entering the standby state.

Description

[Technical Field]

[0001] This invention relates to the field of computer technology, and more particularly to a standby method and an electronic device. [Background Technology]

[0002] The ability of electronic devices to reduce power consumption and thus improve battery life by entering standby mode is a power management technique employed by operating systems. How electronic devices enter standby mode is a key technical aspect of operating system power management. However, electronic devices often exhibit uncontrollable or inflexible behavior when entering standby mode. [Summary of the Invention]

[0003] In view of this, embodiments of the present invention provide a standby method and an electronic device that manages the wake-up lock according to the scenario, so that the electronic device is both controllable and flexible when entering the standby state.

[0004] In a first aspect, embodiments of the present invention provide a standby method, the method comprising:

[0005] The electronic device enters a first standby scenario, which is the scenario in which the electronic device responds to the user's screen-off operation when the first event is executed by the first application, and requests the first wake-up lock according to the first event;

[0006] The second wake-up lock for the second standby scenario is requested according to the second event, wherein the second standby scenario is the scenario in which the electronic device executes the second event through the second application while in standby state;

[0007] The application for the second wake-up lock is approved or rejected based on the first standby scenario, the second standby scenario, and the relationship between the standby scenarios;

[0008] After the first wake-up lock is released and the screen is turned off, or after both the first and second wake-up locks are released and the screen is turned off, the device enters a standby state. The wake-up lock is controlled according to the standby scenario, so that the electronic device is both controllable and flexible when entering the standby state.

[0009] In conjunction with the first aspect, in some implementations of the first aspect, before requesting the second wake-up lock for the second standby scenario based on the second event, the method further includes:

[0010] Receive the second event. When the second event originates from an external source, the electronic device needs to receive the second event, such as an incoming call event or an SMS event.

[0011] In conjunction with the first aspect, in some implementations of the first aspect, the first standby scenario includes an audio scenario, a sports scenario, a navigation scenario, or a task scenario, and the first application includes a music application, a sports application, a map application, or a browser application. According to the application classification standards of the application market, the types of applications that perform task processing in standby mode are roughly divided into five categories: audio-visual entertainment, social communication, utility tools, sports and health, and travel navigation. This embodiment of the invention divides these five application types into six standby scenarios: notification scenario, call scenario, audio scenario, sports scenario, navigation scenario, and task scenario. Regardless of the standby scenario, only a part of the electronic device system and hardware needs to be woken up. Minimizing the wake-up range can effectively reduce unnecessary task execution, thereby reducing the time spent in standby, lowering power consumption, and improving battery life. Therefore, this embodiment of the invention redesigns the wake-up lock based on these six standby scenarios. Since the first standby scenario is the electronic device responding to the user's screen-off operation when executing the first event through the first application, it requests a first wake-up lock based on the first event and continues to execute the first event through the first application based on the first wake-up lock, the audio scenario, motion scenario, navigation scenario, or task scenario among the above six standby scenarios match the first standby scenario. The first application corresponds to the first scenario, therefore the first application includes a music application, a motion application, a map application, or a browser application. The first event corresponds to the first standby scenario. For example, if the first standby scenario is an audio scenario, the first event is playing audio; if the first standby scenario is a task scenario, the first event is downloading a task.

[0012] In conjunction with the first aspect, in some implementations of the first aspect, the second standby scenario includes a notification scenario, a call scenario, an audio scenario, a motion scenario, a navigation scenario, or a task scenario, and the second application includes an SMS application, a phone application, a music application, a fitness application, a map application, or a browser application. The second standby scenario is the scenario where the electronic device executes the second event through the second application while in standby mode. Of the six standby scenarios mentioned above, the notification scenario, call scenario, audio scenario, motion scenario, navigation scenario, and task scenario can all be considered as second standby scenarios. The second application corresponds to the second scenario; therefore, the second application includes an SMS application, a phone application, a music application, a fitness application, a map application, or a browser application. The second event corresponds to the second standby scenario. For example, if the second standby scenario is an audio scenario, the second event is playing audio; if the second standby scenario is a task scenario, the second event is downloading a task.

[0013] In conjunction with the first aspect, in some implementations of the first aspect, the first standby scenario and the second standby scenario are different. When the first standby scenario and the second standby scenario are different, the electronic device determines or rejects the wake-up lock request for the second standby scenario based on the relationship between the two standby scenarios.

[0014] In conjunction with the first aspect, in some implementations of the first aspect, the first application and the second application are different. The first application may be different from the second application.

[0015] In conjunction with the first aspect, in some implementations of the first aspect, the standby scenario relationship includes: task scenarios and non-task scenarios are mutually exclusive. Under any standby scenario, the wake-up lock of the task scenario cannot be activated. Once the electronic device has entered a certain standby scenario (excluding the task scenario), the wake-up lock of the task scenario cannot be activated. Simultaneously, the electronic device strictly controls the number of times and duration of the task scenario wake-up lock execution. Typically, frequent and trivial tasks in the system prevent the electronic device from entering a standby state. This embodiment of the invention, by setting a standby scenario relationship where task scenarios and other standby scenarios are mutually exclusive, can prevent frequent and trivial tasks in the system from preventing the system from entering a standby state.

[0016] In conjunction with the first aspect, in some implementations of the first aspect, the standby scenario relationships also include: mutual exclusion between standby scenarios that transition from foreground to screen-off sleep mode. There can be mutual exclusion between standby scenarios that transition from foreground to standby mode. For example, in a motion scenario, the electronic device's screen is off, and the wake-up lock for the audio scenario cannot be activated. However, music and motion scenarios can coexist (for example, when an electronic device wakes up with its screen on, opens both a motion app and a music app, and starts exercising and playing music simultaneously, the wake-up locks for both the motion and audio scenarios are activated at the same time).

[0017] In conjunction with the first aspect, in some implementations of the first aspect, the step of requesting the first wake-up lock based on the first standby scenario includes:

[0018] The system service corresponding to the first event in the first standby scenario requests the first wake-up lock from the power service;

[0019] Based on the first event, the power service requests the first wake-up lock. The power service of the electronic device reclaims the background wake-up lock provided to the application, no longer allowing the application to directly request it, thus preventing third-party applications from abusing the wake-up lock; based on the application's standby scenario, the corresponding system service requests the wake-up lock for the corresponding standby scenario from the power service, thereby ensuring the rationality of wake-up lock usage; when the system service and driver request the wake-up lock, if the standby scenario relationship is unreasonable, the request fails, ensuring that the wake-up lock is not abused.

[0020] In conjunction with the first aspect, in some implementations of the first aspect, the step of requesting the second wake-up lock for the second standby scenario based on the second event includes:

[0021] The system service corresponding to the second event in the second standby scenario requests the second wake-up lock from the power service.

[0022] In conjunction with the first aspect, in some implementations of the first aspect, the system services include multimedia services, push services, call services, download services, sensor services, or navigation services.

[0023] In conjunction with the first aspect, in some implementations of the first aspect, after entering the standby state, the following further includes:

[0024] Receive third event;

[0025] The third standby scenario is entered according to the third event, which is a scenario in which the electronic device executes the third event through a third application when it is in standby mode;

[0026] After the third wake-up lock corresponding to the third standby scenario is released and the screen is turned off, the system enters standby mode.

[0027] In conjunction with the first aspect, in some implementations of the first aspect, the step of entering a third standby scenario based on the third event, wherein the third standby scenario is a scenario in which the electronic device executes the third event through a third application while in standby mode, specifically includes:

[0028] Based on the third event, the system is woken up by the hardware corresponding to the third event and the system service corresponding to the third event is activated;

[0029] The system service corresponding to the third event requests a third wake-up lock from the power service;

[0030] The third application corresponding to the third event is activated according to the third wake-up lock;

[0031] The third event is executed through the third application.

[0032] In conjunction with the first aspect, in some implementations of the first aspect, the third standby scenario has the characteristic of being able to be woken up by hardware.

[0033] In conjunction with the first aspect, in some implementations of the first aspect, the third standby scenario includes a notification scenario or a call scenario.

[0034] In conjunction with the first aspect, in some implementations of the first aspect, the third event is associated with the fourth event.

[0035] In conjunction with the first aspect, in some implementations of the first aspect, after entering the third standby scenario based on the third event, the method further includes:

[0036] The fourth standby scenario is entered according to the fourth event. The fourth standby scenario is the scenario in which the electronic device executes the fourth event through the third application when it is in standby mode.

[0037] In conjunction with the first aspect, in some implementations of the first aspect, the step of entering a fourth standby scenario based on the fourth event, wherein the fourth standby scenario is a scenario in which the electronic device executes the fourth event through the third application while in standby mode, specifically includes:

[0038] Activate the system service corresponding to the fourth event according to the fourth event;

[0039] The system service corresponding to the fourth event requests the fourth wake-up lock from the power service;

[0040] The fourth event is executed by the third application according to the fourth wake-up lock.

[0041] In conjunction with the first aspect, in some implementations of the first aspect, the step of entering a standby state after the third wake-up lock corresponding to the third standby scenario is released and the screen is turned off includes:

[0042] After the third and fourth wake-up locks are released and the screen is turned off, the device enters standby mode.

[0043] In conjunction with the first aspect, in some implementations of the first aspect, the fourth event is an audio event.

[0044] Secondly, embodiments of the present invention provide an electronic device, including a processor and a memory, wherein the memory is used to store a computer program, the computer program including program instructions, and when the processor executes the program instructions, the electronic device performs the steps of the method described above.

[0045] Thirdly, embodiments of the present invention provide a computer-readable storage medium storing a computer program, the computer program including program instructions that, when requested to be run by a computer, cause the computer to perform the method described above.

[0046] Fourthly, embodiments of the present invention provide a computer program product comprising instructions that, when the computer program product is run on a computer or any at least one processor, cause the computer to perform the functions / steps as described above.

[0047] The present invention provides a standby method and an electronic device technical solution. The standby method includes: the electronic device entering a first standby scenario, wherein the first standby scenario is a scenario in which the electronic device, in response to a user's screen-off operation, requests a first wake-up lock based on the first event when executing a first event through a first application; requesting a second wake-up lock for a second standby scenario based on a second event, wherein the second standby scenario is a scenario in which the electronic device, in a standby state, executes the second event through a second application; accepting or rejecting the request for the second wake-up lock based on the first standby scenario, the second standby scenario, and the relationship between the standby scenarios; entering a standby state after the first wake-up lock is released and the screen is off, or after both the first and second wake-up locks are released and the screen is off; and managing the wake-up lock according to the scenario, so that the electronic device is both controllable and flexible when entering the standby state scenario. [Attached Image Description]

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

[0049] Figure 1 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention;

[0050] Figure 2 This is a software structure block diagram of the electronic device 100 according to an embodiment of the present invention;

[0051] Figure 3 This is a schematic diagram of a wake-up lock scheme for system power management.

[0052] Figure 4 An architecture diagram of a standby system provided in an embodiment of the present invention;

[0053] Figure 5 This is a schematic diagram illustrating the characteristics of six standby scenarios in an embodiment of the present invention;

[0054] Figure 6 This is a schematic diagram illustrating the typical characteristics of six standby scenarios of the wake-up lock in an embodiment of the present invention;

[0055] Figure 7 for Figure 4 A schematic diagram of the standby scheme of a mid-standby system;

[0056] Figure 8 This is a schematic diagram of the standby scheme in an audio scenario according to an embodiment of the present invention;

[0057] Figure 9This is a schematic diagram of the standby scheme in a notification scenario according to an embodiment of the present invention;

[0058] Figure 10 This is a schematic diagram of the standby scheme in a call scenario according to an embodiment of the present invention;

[0059] Figure 11 This is a schematic diagram of the standby scheme in a motion scenario according to an embodiment of the present invention;

[0060] Figure 12 This is a schematic diagram of the standby scheme in a navigation scenario according to an embodiment of the present invention;

[0061] Figure 13 This is a schematic diagram of the standby scheme in a task scenario according to an embodiment of the present invention;

[0062] Figure 14 A flowchart of a standby method provided in an embodiment of the present invention;

[0063] Figure 15 A flowchart of another standby method provided in an embodiment of the present invention;

[0064] Figure 16 This is a flowchart illustrating the specific process of obtaining the first wake-up lock based on the first standby scenario in an embodiment of the present invention.

[0065] Figure 17 This is a flowchart illustrating the process of entering a third standby scenario based on a third event in an embodiment of the present invention. The third standby scenario is a flowchart of the specific execution of a third event by a third application by an electronic device in standby mode.

[0066] Figure 18 This is a flowchart illustrating the process of entering a fourth standby scenario based on a fourth event in an embodiment of the present invention. The fourth standby scenario is a flowchart of the specific execution of the fourth event by a third application when the electronic device is in standby mode.

[0067] Figure 19 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention.

Detailed Implementation Methods

[0068] To better understand the technical solution of the present invention, the embodiments of the present invention will be described in detail below with reference to the accompanying drawings.

[0069] It should be understood that the described embodiments are merely some, not all, of the embodiments of the present invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without inventive effort are within the scope of protection of the present invention.

[0070] The terminology used in the embodiments of this invention is for the purpose of describing particular embodiments only and is not intended to limit the invention. The singular forms “a,” “the,” and “the” as used in the embodiments of this invention and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise.

[0071] It should be understood that the term "and / or" used in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, the character " / " in this article generally indicates that the preceding and following related objects have an "or" relationship.

[0072] Figure 1 A schematic diagram of the structure of the electronic device 100 is shown.

[0073] Electronic device 100 may include processor 110, external memory interface 120, internal memory 121, universal serial bus (USB) interface 130, charging management module 140, power management module 141, battery 142, antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, audio module 170, speaker 170A, receiver 170B, microphone 170C, headphone jack 170D, sensor module 180, button 190, motor 191, indicator 192, camera 193, display screen 194, and subscriber identification module (SIM) card interface 195, etc. The sensor module 180 may include a pressure sensor 180A, a gyroscope sensor 180B, a barometric pressure sensor 180C, a magnetic sensor 180D, an accelerometer sensor 180E, a distance sensor 180F, a proximity sensor 180G, a fingerprint sensor 180H, a temperature sensor 180J, a touch sensor 180K, an ambient light sensor 180L, a bone conduction sensor 180M, etc.

[0074] It is understood that the structures illustrated in the embodiments of the present invention do not constitute a specific limitation on the electronic device 100. In other embodiments of this application, the electronic device 100 may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0075] Processor 110 may include one or more processing units, such as application processors (APs), modem processors, graphics processing units (GPUs), image signal processors (ISPs), controllers, video codecs, digital signal processors (DSPs), baseband processors, and / or neural network processing units (NPUs). These different processing units may be independent devices or integrated into one or more processors.

[0076] The controller can generate operation control signals based on the instruction opcode and timing signals to complete the control of instruction fetching and execution.

[0077] The processor 110 may also include a memory for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory. This memory can store instructions or data that the processor 110 has just used or that are used repeatedly. If the processor 110 needs to use the instruction or data again, it can retrieve it directly from the memory. This avoids repeated accesses, reduces the waiting time of the processor 110, and thus improves the efficiency of the system.

[0078] In some embodiments, the processor 110 may include one or more interfaces. Interfaces may include an inter-integrated circuit (I2C) interface, an inter-integrated circuit sound (I2S) interface, a pulse code modulation (PCM) interface, a universal asynchronous receiver / transmitter (UART) interface, a mobile industry processor interface (MIPI), a general-purpose input / output (GPIO) interface, a subscriber identity module (SIM) interface, and / or a universal serial bus (USB) interface, etc.

[0079] USB port 130 is a USB standard compliant interface, specifically a Mini USB port, Micro USB port, USB Type-C port, etc. USB port 130 can be used to connect a charger to charge electronic device 100, and can also be used for data transfer between electronic device 100 and peripheral devices. It can also be used to connect headphones for audio playback. This interface can also be used to connect other electronic devices, such as AR devices.

[0080] It is understood that the interface connection relationships between the modules illustrated in the embodiments of the present invention are merely illustrative and do not constitute a structural limitation on the electronic device 100. In other embodiments of this application, the electronic device 100 may also employ different interface connection methods or combinations of multiple interface connection methods as described in the above embodiments.

[0081] The charging management module 140 receives charging input from a charger. The charger can be a wireless charger or a wired charger. In some wired charging embodiments, the charging management module 140 receives charging input from the wired charger via the USB interface 130. In some wireless charging embodiments, the charging management module 140 receives wireless charging input via the wireless charging coil of the electronic device 100. While charging the battery 142, the charging management module 140 can also supply power to the electronic device via the power management module 141.

[0082] The power management module 141 connects the battery 142, the charging management module 140, and the processor 110. The power management module 141 receives input from the battery 142 and / or the charging management module 140, providing power to the processor 110, internal memory 121, display screen 194, camera 193, and wireless communication module 160, etc. The power management module 141 can also monitor parameters such as battery capacity, battery cycle count, and battery health status (leakage current, impedance). In some other embodiments, the power management module 141 may also be located within the processor 110. In other embodiments, the power management module 141 and the charging management module 140 may be located in the same device.

[0083] The wireless communication function of electronic device 100 can be realized through antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, modem processor and baseband processor, etc.

[0084] Antenna 1 and antenna 2 are used to transmit and receive electromagnetic wave signals. Each antenna in electronic device 100 can be used to cover one or more communication frequency bands. Different antennas can also be multiplexed to improve antenna utilization. For example, antenna 1 can be multiplexed as a diversity antenna for a wireless local area network. In some other embodiments, the antennas can be used in conjunction with tuning switches.

[0085] The mobile communication module 150 can provide solutions for wireless communication, including 2G / 3G / 4G / 5G, applied to the electronic device 100. The mobile communication module 150 may include at least one filter, switch, power amplifier, low noise amplifier (LNA), etc. The mobile communication module 150 can receive electromagnetic waves via antenna 1, and perform filtering, amplification, and other processing on the received electromagnetic waves before transmitting them to a modem processor for demodulation. The mobile communication module 150 can also amplify the signal modulated by the modem processor and convert it into electromagnetic waves for radiation via antenna 1. In some embodiments, at least some functional modules of the mobile communication module 150 may be housed in the processor 110. In some embodiments, at least some functional modules of the mobile communication module 150 and at least some modules of the processor 110 may be housed in the same device.

[0086] The modem processor may include a modulator and a demodulator. The modulator modulates the low-frequency baseband signal to be transmitted into a mid-to-high frequency signal. The demodulator demodulates the received electromagnetic wave signal into a low-frequency baseband signal. The demodulator then transmits the demodulated low-frequency baseband signal to the baseband processor for processing. After processing by the baseband processor, the low-frequency baseband signal is transmitted to the application processor. The application processor outputs sound signals through an audio device (not limited to speaker 170A, receiver 170B, etc.) or displays images or videos through the display screen 194. In some embodiments, the modem processor may be a separate device. In other embodiments, the modem processor may be independent of the processor 110 and may be housed in the same device as the mobile communication module 150 or other functional modules.

[0087] The wireless communication module 160 can provide solutions for wireless communication applications on the electronic device 100, including wireless local area networks (WLANs) (such as wireless fidelity (Wi-Fi) networks), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), and infrared (IR) technologies. The wireless communication module 160 can be one or more devices integrating at least one communication processing module. The wireless communication module 160 receives electromagnetic waves via antenna 2, performs frequency modulation and filtering of the electromagnetic wave signals, and sends the processed signal to processor 110. The wireless communication module 160 can also receive signals to be transmitted from processor 110, perform frequency modulation and amplification, and convert them into electromagnetic waves for radiation via antenna 2.

[0088] In some embodiments, antenna 1 of electronic device 100 is coupled to mobile communication module 150, and antenna 2 is coupled to wireless communication module 160, enabling electronic device 100 to communicate with networks and other devices via wireless communication technology. The wireless communication technology may include Global System for Mobile Communications (GSM), General Packet Radio Service (GPRS), Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), Time Division Code Division Multiple Access (TD-SCDMA), Long Term Evolution (LTE), BT, GNSS, WLAN, NFC, FM, and / or IR technologies, etc. The GNSS may include the Global Positioning System (GPS), the Global Navigation Satellite System (GLONASS), the BeiDou Navigation Satellite System (BDS), the Quasi-Zenith Satellite System (QZSS), and / or satellite-based augmentation systems (SBAS).

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

[0090] Display screen 194 is used to display images, videos, etc. Display screen 194 includes a display panel. The display panel may be a liquid crystal display (LCD), an organic light-emitting diode (OLED), an active-matrix organic light-emitting diode (AMOLED), a flexible light-emitting diode (FLED), a miniature LED, a microLED, a quantum dot light-emitting diode (QLED), etc. In some embodiments, electronic device 100 may include one or N displays 194, where N is a positive integer greater than 1.

[0091] Electronic device 100 can perform shooting functions through ISP, camera 193, video codec, GPU, display 194 and application processor.

[0092] The ISP (Image Signal Processor) is used to process data fed back from the camera 193. For example, when taking a picture, the shutter is opened, and light is transmitted through the lens to the camera's photosensitive element. The light signal is converted into an electrical signal, and the camera's photosensitive element transmits the electrical signal to the ISP for processing, transforming it into an image visible to the naked eye. The ISP can also perform algorithmic optimization of image noise, brightness, and skin tone. The ISP can also optimize parameters such as exposure and color temperature of the shooting scene. In some embodiments, the ISP can be set in the camera 193.

[0093] Camera 193 is used to capture still images or videos. An object is projected onto a photosensitive element by generating an optical image through the lens. The photosensitive element can be a charge-coupled device (CCD) or a complementary metal-oxide-semiconductor (CMOS) phototransistor. The photosensitive element converts the light signal into an electrical signal, which is then passed to an ISP for conversion into a digital image signal. The ISP outputs the digital image signal to a DSP for processing. The DSP converts the digital image signal into image signals in standard RGB, YUV, or other formats. In some embodiments, the electronic device 100 may include one or N cameras 193, where N is a positive integer greater than 1.

[0094] Digital signal processors (DSPs) are used to process digital signals. Besides digital image signals, they can also process other digital signals. For example, when electronic device 100 selects a frequency, the DSP can perform Fourier transforms on the frequency energy.

[0095] Video codecs are used to compress or decompress digital video. Electronic device 100 may support one or more video codecs. Thus, electronic device 100 can play or record videos in various encoding formats, such as Moving Picture Experts Group (MPEG) 1, MPEG2, MPEG3, MPEG4, etc.

[0096] An NPU (Neural Processing Unit) is a computational processor for neural networks (NNs). By borrowing the structure of biological neural networks, such as the transmission patterns between neurons in the human brain, it can rapidly process input information and continuously learn on its own. NPUs enable intelligent cognitive applications in electronic devices, such as image recognition, facial recognition, speech recognition, and text understanding.

[0097] The external storage interface 120 can be used to connect an external memory card, such as a Micro SD card, to expand the storage capacity of the electronic device 100. The external memory card communicates with the processor 110 through the external storage interface 120 to perform data storage functions. For example, music, video, and other files can be saved on the external memory card.

[0098] Internal memory 121 can be used to store computer executable program code, which includes instructions. Internal memory 121 may include a program storage area and a data storage area. The program storage area may store the operating system, at least one application program required for a function (such as sound playback, image playback, etc.), etc. The data storage area may store data created during the use of electronic device 100 (such as audio data, phonebook, etc.). Furthermore, internal memory 121 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, universal flash storage (UFS), etc. Processor 110 executes various functional applications and data processing of electronic device 100 by running instructions stored in internal memory 121 and / or instructions stored in memory located in the processor.

[0099] Electronic device 100 can implement audio functions, such as music playback and recording, through audio module 170, speaker 170A, receiver 170B, microphone 170C, headphone jack 170D, and application processor.

[0100] The audio module 170 is used to convert digital audio information into analog audio signals for output, and also to convert analog audio input into digital audio signals. The audio module 170 can also be used for encoding and decoding audio signals. In some embodiments, the audio module 170 may be located in the processor 110, or some functional modules of the audio module 170 may be located in the processor 110.

[0101] The speaker 170A, also known as a "loudspeaker," is used to convert audio electrical signals into sound signals. The electronic device 100 can listen to music or make hands-free calls through the speaker 170A.

[0102] The receiver 170B, also known as the "earpiece," is used to convert audio electrical signals into sound signals. When the electronic device 100 answers a telephone call or voice message, the receiver 170B can be brought close to the ear to listen to the voice.

[0103] Microphone 170C, also known as a "microphone" or "voice transducer," is used to convert sound signals into electrical signals. When making a phone call or sending a voice message, the user can speak by bringing their mouth close to microphone 170C, inputting the sound signal into microphone 170C. Electronic device 100 may have at least one microphone 170C. In some embodiments, electronic device 100 may have two microphones 170C, which, in addition to collecting sound signals, can also perform noise reduction. In other embodiments, electronic device 100 may also have three, four, or more microphones 170C, which can collect sound signals, reduce noise, identify the sound source, and perform directional recording, etc.

[0104] The 170D headphone jack is used to connect wired headphones. The 170D headphone jack can be a USB 130 interface or a 3.5mm Open Mobile Terminal Platform (OMTP) standard interface, a CTIA (Cellular Telecommunications Industry Association of the USA) standard interface.

[0105] Buttons 190 include a power button, volume buttons, etc. Buttons 190 can be mechanical buttons or touch-sensitive buttons. Electronic device 100 can receive button input and generate key signal inputs related to user settings and function control of electronic device 100.

[0106] Motor 191 can generate vibration alerts. Motor 191 can be used for incoming call vibration alerts or for touch vibration feedback. For example, different vibration feedback effects can correspond to touch operations performed on different applications (such as taking photos, playing audio, etc.). Motor 191 can also correspond to different vibration feedback effects for touch operations performed on different areas of the display screen 194. Different application scenarios (such as time reminders, receiving messages, alarm clocks, games, etc.) can also correspond to different vibration feedback effects. The touch vibration feedback effect can also be customized.

[0107] Indicator 192 can be an indicator light, used to indicate charging status, power changes, or to indicate messages, missed calls, notifications, etc.

[0108] The SIM card interface 195 is used to connect a SIM card. The SIM card can be inserted into or removed from the SIM card interface 195 to make contact with and separate from the electronic device 100. The electronic device 100 can support one or N SIM card interfaces, where N is a positive integer greater than 1. The SIM card interface 195 can support Nano SIM cards, Micro SIM cards, SIM cards, etc. Multiple cards can be inserted into the same SIM card interface 195 simultaneously. The multiple cards can be of the same or different types. The SIM card interface 195 is also compatible with different types of SIM cards. The SIM card interface 195 is also compatible with external memory cards. The electronic device 100 interacts with the network through the SIM card to realize functions such as calls and data communication. In some embodiments, the electronic device 100 uses an eSIM, i.e., an embedded SIM card. The eSIM card can be embedded in the electronic device 100 and cannot be separated from the electronic device 100.

[0109] The software system of electronic device 100 can adopt a layered architecture, event-driven architecture, microkernel architecture, microservice architecture, or cloud architecture. This embodiment of the invention uses the layered architecture Android system as an example to illustrate the software structure of electronic device 100.

[0110] Figure 2 This is a software structure block diagram of the electronic device 100 according to an embodiment of the present invention.

[0111] A layered architecture divides software into several layers, each with a clear role and function. Layers communicate with each other through software interfaces. In some embodiments, the Android system is divided into four layers, from top to bottom: the application layer, the application framework layer, the Android runtime and system libraries, and the kernel layer.

[0112] The application layer can include a series of application packages.

[0113] like Figure 2 As shown, the application package may include applications such as camera, gallery, calendar, call, map, navigation, WLAN, Bluetooth, music, video, and SMS.

[0114] The application framework layer provides application programming interfaces (APIs) and a programming framework for applications in the application layer. The application framework layer includes some predefined functions.

[0115] like Figure 2 As shown, the application framework layer may include a window manager, content provider, view system, phone manager, resource manager, notification manager, etc.

[0116] The window manager is used to manage windowed applications. It can retrieve screen size, determine the presence of a status bar, lock the screen, and capture screenshots, among other things.

[0117] Content providers store and retrieve data, making that data accessible to applications. This data may include videos, images, audio, made and received phone calls, browsing history and bookmarks, phone books, etc.

[0118] A view system includes visual controls, such as controls for displaying text and controls for displaying images. View systems can be used to build applications. A display interface can consist of one or more views. For example, a display interface including a text notification icon could include views for displaying text and views for displaying images.

[0119] The phone manager is used to provide communication functions for electronic device 100. For example, it manages call status (including connection and disconnection).

[0120] The file explorer provides applications with various resources, such as localized strings, icons, images, layout files, video files, and more.

[0121] The notification manager allows applications to display notifications in the status bar. These notifications can be used to deliver informational messages and can disappear automatically after a short pause, requiring no user interaction. For example, the notification manager can be used to notify users of completed downloads or message alerts. The notification manager can also display notifications as icons or scrolling text in the top status bar, such as notifications from background applications, or as dialog boxes on the screen. Examples include displaying text messages in the status bar, emitting sounds, vibrating electronic devices, and flashing indicator lights.

[0122] The Android Runtime consists of core libraries and a virtual machine. The Android runtime is responsible for the scheduling and management of the Android system.

[0123] The core library consists of two parts: one part is the functionalities that need to be called by the Java language, and the other part is the Android core library.

[0124] The application layer and application framework layer run in a virtual machine. The virtual machine executes the Java files of the application layer and application framework layer as binary files. The virtual machine is used to perform functions such as object lifecycle management, stack management, thread management, security and exception management, and garbage collection.

[0125] System libraries can include multiple functional modules. For example: surface manager, media libraries, 3D graphics processing libraries (e.g., OpenGL ES), 2D graphics engines (e.g., SGL), etc.

[0126] The Surface Manager is used to manage the display subsystem and provides the blending of 2D and 3D layers for multiple applications.

[0127] The media library supports playback and recording of various common audio and video formats, as well as still image files. It supports multiple audio and video encoding formats, such as MPEG4, H.264, MP3, AAC, AMR, JPG, and PNG.

[0128] The 3D graphics processing library is used to implement 3D graphics drawing, image rendering, compositing, and layer processing.

[0129] A 2D graphics engine is a graphics engine for 2D drawing.

[0130] The kernel layer is the layer between hardware and software. The kernel layer contains at least the display driver, camera driver, audio driver, and sensor driver.

[0131] The following example, using a scene of capturing a photograph, illustrates the workflow of the software and hardware of the electronic device 100.

[0132] When touch sensor 180K receives a touch operation, a corresponding hardware interrupt is sent to the kernel layer. The kernel layer processes the touch operation into a raw input event (including touch coordinates, timestamp of the touch operation, etc.). The raw input event is stored in the kernel layer. The application framework layer retrieves the raw input event from the kernel layer and identifies the control corresponding to the input event. Taking a touch click as an example, where the corresponding control is the camera application icon, the camera application calls the application framework layer's interface to launch the camera application, and then calls the kernel layer to launch the camera driver, capturing still images or videos through camera 193.

[0133] A common way to implement standby mode in electronic devices is to control whether or not to enter standby mode using a CPU wake-up lock. The problem with iOS's standby mode implementation is its lack of flexibility and openness, while Android's standby mode implementation suffers from being uncontrollable and easily abused by applications.

[0134] Take the Android standby mode solution as an example. Figure 3 This is a schematic diagram of a wake-up lock scheme for system power management, such as... Figure 3 As shown, electronic devices include system power management, applications, system services, and drivers. System power management includes power services and power drivers. System power management provides background wake-up lock interfaces to applications, system services, and drivers. When an application, system service, or driver wants to process business logic in the background, it requests a background wake-up lock from system power management and locks it, preventing the CPU from entering standby mode and ensuring normal business logic processing. Because of the background wake-up lock, the CPU cannot enter standby mode, leading to excessive power consumption and reduced battery life. Furthermore, the timing of wake-up lock release depends entirely on the business logic of the application, system service, and driver, which the system cannot control. This can lead to serious abuse, further resulting in excessive power consumption and reduced battery life.

[0135] Android, based on an open design philosophy, grants applications, system services, and drivers ample freedom for users to control flexibly. While application locking requires pre-application for permissions, the app store lacks effective review mechanisms. Once an application, system service, or driver locks its permissions, the system will not enter standby mode unless it actively releases them. Therefore, the timing of when electronic devices enter standby mode is uncontrollable, leading to degraded battery life.

[0136] In summary, electronic devices often suffer from uncontrollability or inflexibility when entering standby mode.

[0137] Based on the above-mentioned technical problems, embodiments of the present invention provide a standby system. Figure 4 This is an architecture diagram of a standby system provided in an embodiment of the present invention. The standby system is the operating system of an electronic device, such as... Figure 4 As shown, the standby system includes an application layer, a service layer, a driver layer, and a hardware layer. The hardware and software structures of the electronic device provided in this embodiment of the invention can be found in [reference needed]. Figure 1 and Figure 2 The relevant description of electronic device 100 in the text.

[0138] The application layer includes multiple applications. An application is a specific functional module implemented by application developers, such as a music application, a telephone application, and a map application.

[0139] The service layer includes multiple system services. System services refer to specific sets of functions implemented by operating system developers, such as multimedia services, power services, call services, and download services.

[0140] The driver layer includes multiple drivers. A driver refers to a specific hardware function implemented by a device developer, such as an audio driver, a WLAN driver, or a modem driver.

[0141] The hardware layer includes multiple hardware components. Hardware refers to physical devices that provide specific interactive responses, such as speakers, WLAN, and modems.

[0142] According to the application classification standards of the app market, the types of applications that perform tasks in standby mode are roughly divided into five categories: audio and video entertainment, social communication, utility tools, sports and health, and travel navigation.

[0143] In this embodiment of the invention, these five types of applications are divided into six standby scenarios: notification scenario, call scenario, audio scenario, sports scenario, navigation scenario, and task scenario. Figure 5 This is a schematic diagram illustrating the characteristics of six standby scenarios in an embodiment of the present invention.

[0144] like Figure 5 As shown, the notification scenario has the characteristics of uncertain wake-up time, need to be woken up frequently, the existence of persistent system services, the whole machine will be woken up and the screen will light up when a notification is received, and it can be woken up by hardware.

[0145] like Figure 5 As shown, the call scenario has the characteristics of occupying the background for a long time, having persistent system services, waking up the whole device during the call, being able to be woken up by hardware, remaining in the screen-on state after hanging up, and holding the Proximity screen lock.

[0146] like Figure 5 As shown, the audio scene has the characteristics of occupying the background for a long time, needing to enter sleep mode after pausing / stopping playback, having a persistent system service, being able to be woken up by hardware, and being able to go to sleep mode in the foreground when the screen is turned off.

[0147] like Figure 5 As shown, motion scenarios are characterized by prolonged background activity, the ability to be put into sleep mode by turning off the screen in the foreground, and the absence of persistent system services.

[0148] like Figure 5 As shown, the navigation scenario has the characteristics of occupying the background for a long time, being able to go to sleep in the foreground when the screen is turned off, and not having any persistent system services.

[0149] like Figure 5 As shown, the task scenario has two types of tasks (small tasks and large tasks) and the characteristic of having the need to be executed when charging or idle.

[0150] In all six standby scenarios described above, what needs to be woken up is only a part of the electronic device system and hardware. Minimizing the wake-up range can effectively reduce unnecessary task execution, thereby reducing the time spent in standby mode, lowering power consumption, and improving battery life. Therefore, this embodiment of the invention redesigns the wake-up lock based on these six standby scenarios.

[0151] When the wake-up lock for a certain standby scenario is activated, it is assumed that the electronic device's system has entered that standby scenario.

[0152] Figure 6 This is a schematic diagram illustrating the typical characteristics of six standby scenarios for the wake-up lock in an embodiment of the present invention. For example... Figure 6 As shown, based on the typical characteristics of the six standby scenarios, standby scenarios can be roughly divided into two categories: "wake-up from hardware" and "screen off standby from the foreground".

[0153] "Wake-up from hardware" means that when an electronic device enters standby mode, the hardware will actively wake up the system upon receiving a response. For example, when a phone receives a call while in standby mode, the phone will start playing a ringtone via Bluetooth.

[0154] "Screen off standby mode" means that when a user is using an electronic device while the screen is on, they can turn the device into a screen-off or standby state by pressing the power button or other methods. For example, when an electronic device is playing music, exercising, or navigating through an application, the user can press the power button to turn off the screen.

[0155] Therefore, this embodiment of the invention specifies standby scene relationships, that is, the mutual exclusion relationship between standby scenes includes: mutual exclusion between standby scenes that transition from foreground to standby mode. There can be mutual exclusion between standby scenes that transition from foreground to standby mode. For example, in a motion scene, the electronic device's screen is off, and the wake-up lock for the audio scene cannot be activated. However, music scenes and motion scenes can coexist (for example, when an electronic device is woken up with its screen on, and both a motion app and a music app are opened, and both motion and music are played simultaneously, the wake-up locks for both the motion scene and the audio scene are activated at the same time).

[0156] The standby scenario relationship also includes: task scenarios and other standby scenarios are mutually exclusive. Under any standby scenario, the wake-up lock of the task scenario cannot be activated. Once an electronic device has entered a certain standby scenario (excluding task scenarios), the wake-up lock of the task scenario cannot be activated. Simultaneously, the electronic device strictly controls the number of times and the duration of the task scenario wake-up lock execution. Typically, frequent and trivial tasks in the system prevent the electronic device from entering standby mode. This embodiment of the invention, by setting a standby scenario relationship where task scenarios and other standby scenarios are mutually exclusive, can prevent frequent and trivial tasks in the system from preventing the system from entering standby mode.

[0157] For example, such as Figure 4 As shown, the application layer includes a music application, a text messaging application, a phone application, a browser application, a fitness application, and a map application. The music application provides users with a music management interface, offering functions such as play and pause. The text messaging application provides functions such as receiving, sending, and managing text messages. The phone application provides functions such as making and answering voice calls. The browser application provides functions such as web browsing. The fitness application provides functions such as step counting and tracking exercise data. The map application provides functions such as navigation and route planning.

[0158] For example, such as Figure 4 As shown, the service layer includes multimedia services, push services, call services, power services, download services, sensor services, and navigation services. Multimedia services provide functions related to media such as video, audio, and photography. Push services provide functions for receiving and sending SMS and network messages. Call services provide functions for making and receiving voice calls. Power services provide system wake-up and standby functions. Download services provide functions for downloading and storing network data. Sensor services provide functions for managing and monitoring sensors. Navigation services provide functions for positioning and navigation.

[0159] For example, such as Figure 4 As shown, the driver layer includes audio driver, WLAN driver, modem driver, gyroscope driver, and GNSS driver. The audio driver provides the function of playing audio through the speaker. The WLAN driver provides the function of connecting to the network, receiving and sending data via a wireless local area network. The modem driver provides the function of connecting to the network, receiving and sending data via a mobile network. The gyroscope driver provides the function of detecting and reporting gyroscope data. The GNSS driver provides the function of detecting and reporting spatial positioning data.

[0160] For example, such as Figure 4 As shown, the hardware layer includes a speaker, WLAN, modem, gyroscope, and GNSS. The speaker provides sound playback functionality; the WLAN provides wireless local area network functionality; the modem provides mobile network functionality; the gyroscope provides gyroscope functionality; and GNSS provides spatial positioning functionality.

[0161] Figure 7 for Figure 4 A schematic diagram of the standby scheme of a medium-duty standby system. (For example...) Figure 7As shown, the power service reclaims the background wake locks provided to applications, no longer allowing applications to directly request them, thus preventing third-party applications from abusing wake locks; based on the application's standby scenario, the corresponding system service requests the wake lock for the corresponding standby scenario from the power service, thereby ensuring the rationality of wake lock usage; when the system service and driver request wake locks, if the standby scenario relationship is unreasonable, the request will fail, ensuring that wake locks are not abused.

[0162] Figure 8 This is a schematic diagram of the standby scheme in an audio scenario according to an embodiment of the present invention. Figure 8 As shown, when an electronic device plays music and the user presses the power button to turn off the screen, the power service begins standby detection. At this time, the multimedia service requests a wake-up lock for the audio scenario from the power service, preventing the system from entering standby mode and keeping the entire system in a wake-up state. Modules in this active state require hardware resources and consume power for business processing. If the call service receives an incoming call event, it requests a wake-up lock for the call scenario from the power service. Based on the standby scenario relationship, the audio scenario and the call scenario are not mutually exclusive; the wake-up lock request for the call scenario will be granted, and the phone application will be activated. Another scenario, such as... Figure 8 As shown, if the download service receives a background download event, it requests a wake-up lock for the task scenario from the power service. Since task scenarios are mutually exclusive with other standby scenarios, the wake-up lock request for the task scenario will be rejected. Once the wake-up locks for both the call and audio scenarios are released and the screen is off, the electronic device will enter standby mode. Figure 8 As shown, in offline audio scenarios, the electronic device needs to keep the dark gray area in a wake-up state and the white area in an inactive state. In online audio scenarios, the electronic device wakes up the light gray area as needed.

[0163] Figure 9 This is a schematic diagram of a standby scheme in a notification scenario according to an embodiment of the present invention. Figure 9 As shown, the electronic device is already in standby mode. Upon receiving an SMS notification, the system will be woken up via hardware. After waking, the push service is activated based on the SMS notification. The push service requests a wake-up lock for the notification scenario from the power service. The SMS application is then woken up based on the wake-up lock, and the screen lights up to display the SMS notification. If a notification sound is required, the multimedia service needs to be activated, and the multimedia service requests a wake-up lock for the audio scenario from the power service. Once the notification is complete, the push service releases the wake-up lock. If the user does not interact with the device, the screen turns off, and the system enters standby mode. Figure 9 As shown, in notification scenarios, the system needs to keep the dark gray area active, activating WLAN or Modem as needed based on the network channel, while the white area represents the inactive state. If a notification tone needs to be played, the multimedia service, audio driver, and speaker will be activated as needed.

[0164] Figure 10 This is a schematic diagram of the standby scheme in a call scenario according to an embodiment of the present invention. Figure 10 As shown, the electronic device is already in standby mode. When a call comes in, the system is woken up via hardware. After the system wakes up, the call service is activated based on the call event. The call service requests a wake-up lock for the call scenario from the power service. Then, the call application is woken up based on the wake-up lock of the call service, and the screen lights up to display the incoming call notification. If the incoming call ringtone is played simultaneously, the multimedia service needs to be activated, and the multimedia service requests a wake-up lock for the audio scenario from the power service. When the call ends, the call service releases the wake-up lock. If the user does not interact with the system, the screen turns off and the system enters standby mode. Figure 10 As shown, in a call scenario, the system needs to keep the dark gray area active and the white area inactive.

[0165] Figure 11 This is a schematic diagram of the standby scheme in a motion scenario according to an embodiment of the present invention. Figure 11 As shown, when an electronic device is in a screen-on wake-up state, it initiates motion mode through a motion application and then turns off the screen. After the electronic device initiates motion mode, the sensor service requests a wake-up lock for the motion scene from the power service. The wake-up lock prevents the system from entering standby mode, thus ensuring that data from the gyroscope and other sensors are reported normally. If motion status announcements or trajectory navigation are required, the multimedia service and navigation service need to be activated. When the motion is completed, the sensor service releases the wake-up lock. If the user does not interact with the system, the screen turns off and the system enters standby mode. Figure 11 As shown, in motion scenarios, the system needs to keep the dark gray areas active and the white areas inactive. If trajectory and announcements are required, the light gray areas are activated as needed.

[0166] Figure 12 This is a schematic diagram of the standby scheme in a navigation scenario according to an embodiment of the present invention. Figure 12 As shown, when an electronic device is in a screen-on wake-up state, navigation is initiated through a navigation application, and the screen is then turned off. After navigation is initiated, the navigation service requests a wake-up lock from the power service for the navigation scenario. This wake-up lock prevents the system from entering standby mode, thus ensuring normal GNSS data reporting. If navigation route announcements or direction identification are required, the multimedia service and sensor service need to be activated. Once navigation is complete, the sensor service releases the wake-up lock. If the user does not interact with the system, it enters standby mode after the screen turns off. Figure 12 As shown, in navigation scenarios, the system needs to keep the dark gray area in an active state and the white area in an inactive state. If direction, announcements, and network connectivity are required, the light gray area is activated as needed.

[0167] Figure 13This is a schematic diagram of the standby scheme in a task scenario according to an embodiment of the present invention. Figure 13 As shown, when an electronic device is in a screen-on wake-up state, it starts a download process via a browser application and then turns off the screen. After the electronic device starts downloading, the download service requests a wake-up lock from the power service for the task scenario. The wake-up lock prevents the system from entering standby mode, thus ensuring the download task continues. When the download task is completed, the download service releases the wake-up lock. If the user does not interact with the system, the screen turns off and the system enters standby mode. Figure 13 As shown, in task scenarios, the system needs to keep the dark-colored areas in a wake-up state, waking up the WLAN or Modem as needed based on the network channel, while the white areas represent the inactive state. Simultaneously, for task scenarios, the system needs to differentiate the importance of tasks based on their execution duration to ensure unified scheduling decisions.

[0168] Once an electronic device's system has entered a standby mode, the wake-up lock for the task mode cannot be activated. This effectively manages frequent and trivial tasks in the system, preventing tasks from preventing the system from entering standby mode, thereby reducing power consumption and improving battery life.

[0169] In conclusion, Figure 3 The wake-up lock scheme for system power management shown in the previous example lacks a proper design and only offers one background type. Inappropriate use of wake-up locks by application developers can prevent the system from entering standby mode, impacting battery life. Furthermore, abuse of wake-up locks by system service and driver developers can prevent entry into standby mode, also affecting battery life. The standby system provided in this application designs wake-up locks for six standby scenarios based on user usage scenarios, while retaining the capability for future expansion. Wake-up locks can be managed according to different scenarios, thereby reducing the risk of abuse. This embodiment of the invention decentralizes the wake-up locks used by applications to system services, transforming the uncontrollable into controllable from the operating system's perspective. Moreover, the scenario in which a system service requests a wake-up lock is bound to the service's responsibilities, inherently possessing rationality and ensuring its proper use. This embodiment of the invention unifies the interfaces between the service layer and the driver layer, providing permission and scenario management. Drivers cannot directly use wake-up locks by default; permission review by the power module is required before permission is granted, effectively reducing abuse. Therefore, this embodiment of the invention provides unified management of wake-up locks based on standby scenarios, ensuring both flexibility and controllability.

[0170] Figure 3 The existing wake-up lock scheme defines a single background wake-up type, which leads to serious abuse and irrationality. In contrast, this invention divides the background wake-up lock according to standby scenarios and implements unified management. This invention manages the wake-up lock based on the scenario, ensuring its rationality and thus improving battery life.

[0171] Based on the above standby system architecture, this embodiment of the invention provides a standby method that manages the wake-up lock according to the scenario, so that the electronic device is both controllable and flexible when entering the standby state.

[0172] Figure 14 A flowchart of a standby method provided in an embodiment of the present invention. Figure 15 A flowchart illustrating another standby method provided in an embodiment of the present invention. For example... Figure 14 and Figure 15 As shown, the method includes:

[0173] Step 202: The electronic device enters the first standby scenario. The first standby scenario is the scenario in which the electronic device responds to the user's screen-off operation when the first event is executed by the first application, and requests the first wake-up lock according to the first event.

[0174] According to the application classification standards of the app market, the types of applications that perform tasks in standby mode are roughly divided into five categories: audio and video entertainment, social communication, utility tools, sports and health, and travel navigation.

[0175] In this embodiment of the invention, these five types of applications are divided into six standby scenarios: notification scenario, call scenario, audio scenario, sports scenario, navigation scenario, and task scenario.

[0176] like Figure 5 As shown, the notification scenario has the characteristics of uncertain wake-up time, need to be woken up frequently, the existence of persistent system services, the whole machine will be woken up and the screen will light up when a notification is received, and it can be woken up by hardware.

[0177] like Figure 5 As shown, the call scenario has the characteristics of occupying the background for a long time, having persistent system services, waking up the whole device during the call, being able to be woken up by hardware, remaining in the screen-on state after hanging up, and holding the Proximity screen lock.

[0178] like Figure 5 As shown, the audio scene has the characteristics of occupying the background for a long time, needing to enter sleep mode after pausing / stopping playback, having a persistent system service, being able to be woken up by hardware, and being able to go to sleep mode in the foreground when the screen is turned off.

[0179] like Figure 5 As shown, motion scenarios are characterized by prolonged background activity, the ability to be put into sleep mode by turning off the screen in the foreground, and the absence of persistent system services.

[0180] like Figure 5 As shown, the navigation scenario has the characteristics of occupying the background for a long time, being able to go to sleep in the foreground when the screen is turned off, and not having any persistent system services.

[0181] like Figure 5As shown, the task scenario has two types of tasks (small tasks and large tasks) and the characteristic of having the need to be executed when charging or idle.

[0182] In all six standby scenarios described above, what needs to be woken up is only a part of the electronic device system and hardware. Minimizing the wake-up range can effectively reduce unnecessary task execution, thereby reducing the time spent in standby mode, lowering power consumption, and improving battery life. Therefore, this embodiment of the invention redesigns the wake-up lock based on these six standby scenarios.

[0183] When the wake-up lock for a certain standby scenario is activated, it is assumed that the electronic device's system has entered that standby scenario.

[0184] like Figure 6 As shown, based on the typical characteristics of the six standby scenarios, standby scenarios can be roughly divided into two categories: "wake-up from hardware" and "screen off standby from the foreground".

[0185] "Screen off standby mode" means that when a user is using an electronic device while the screen is on, they can turn the device into a screen-off or standby state by pressing the power button or other methods. For example, when an electronic device is playing music, exercising, or navigating through an application, the user can press the power button to turn off the screen.

[0186] "Wake-up from hardware" means that when an electronic device enters standby mode, the hardware will actively wake up the system upon receiving a response. For example, when a phone receives a call while in standby mode, the phone will start playing a ringtone via Bluetooth.

[0187] For example, the first standby scenario includes an audio scenario, a motion scenario, a navigation scenario, or a task scenario.

[0188] For example, the first application may include a music application, a sports application, a map application, or a browser application. The first application corresponds to the first scenario.

[0189] For example, the first event corresponds to the first standby scenario. For instance, if the first standby scenario is an audio scenario, the first event is playing audio; if the first standby scenario is a task scenario, the first event is downloading a task.

[0190] In some possible embodiments, such as Figure 16 As shown, the first wake-up lock is requested based on the first standby scenario, specifically including:

[0191] Step 2022: Request the first wake-up lock from the power service through the system service corresponding to the first event of the first standby scenario.

[0192] For example, the first standby scenario is an audio scenario, where the electronic device plays music, and then the user presses the power button to turn off the screen. The power service will then begin standby detection. Figure 8 As shown, at this time, the multimedia service requests the wake-up lock for the audio scene from the power service.

[0193] For example, the first standby scenario is a sports scenario, where the electronic device is in a screen-on wake-up state, and the sports application is used to start the sports mode and turn off the screen; such as Figure 11 As shown, after the electronic device enters motion mode, the sensor service requests a wake-up lock for the motion scene from the power service.

[0194] For example, the first standby scenario is a navigation scenario, where the electronic device is in a screen-on wake-up state, navigation is initiated through a navigation application, and the screen is turned off; Figure 12 As shown, after the electronic device starts navigation, the navigation service requests the wake-up lock for the navigation scenario from the power service.

[0195] For example, the first standby scenario is a task scenario, such as... Figure 13 As shown, when the electronic device is in a screen-on wake-up state, it starts downloading through a browser application and then turns off the screen. After the electronic device starts downloading, the download service requests the wake-up lock for the task scenario from the power service.

[0196] For example, system services may include multimedia services, push services, call services, download services, sensor services, or navigation services.

[0197] Step 2024: Based on the first event, request the first wake-up lock via the power service.

[0198] For example, the first standby scenario is an audio scenario, such as... Figure 8 As shown, after the power service of the electronic device passes the wake-up lock in the audio scene, the wake-up lock will prevent the system from entering standby mode, and the entire system will be in a wake-up state. Modules in the active state need to occupy hardware resources and consume power to perform business processing.

[0199] For example, the first standby scenario is a motion scenario, such as... Figure 11 As shown, after the power service of the electronic device passes the wake-up lock of the motion scene, the wake-up lock of the motion scene prevents the system from entering standby mode, thereby ensuring that data such as gyroscopes are reported normally; if motion status broadcasting or trajectory navigation is required, multimedia services and navigation services need to be activated.

[0200] For example, the first standby scenario is a navigation scenario, such as... Figure 12 As shown, after the power service of the electronic device is activated by the wake-up lock in the navigation scenario, the wake-up lock prevents the system from entering standby mode, thereby ensuring the normal reporting of GNSS data; if navigation route broadcasting or direction identification is required, multimedia service and sensor service need to be activated.

[0201] For example, the first standby scenario is a task scenario, such as... Figure 13 As shown, the wake-up lock prevents the system from entering standby mode, thus ensuring that the download task continues.

[0202] Step 204: Request a second wake-up lock for a second standby scenario based on the second event. The second standby scenario is a scenario in which the electronic device executes the second event through the second application while in standby mode.

[0203] For example, the second standby scenario includes a notification scenario, a call scenario, an audio scenario, a sports scenario, a navigation scenario, or a task scenario. The first standby scenario is different from the second standby scenario.

[0204] For example, the second application includes a text messaging application, a phone application, a music application, a fitness application, a map application, or a browser application. The first application and the second application are different. The second application corresponds to the second standby scenario.

[0205] In some possible embodiments, step 204 specifically includes: requesting a second wake-up lock from the power service through the system service corresponding to the second event of the second standby scenario.

[0206] Step 206: Approve or reject the application for the second wake-up lock based on the first standby scenario, the second standby scenario, and the relationship between the standby scenarios.

[0207] For example, standby scenario relationships include: task scenarios and non-task scenarios are mutually exclusive.

[0208] For example, the first standby scenario is an audio scenario, and the second standby scenario is a task scenario, such as... Figure 8 As shown, when an electronic device plays music and the user presses the power button to turn off the screen, the power service begins standby detection. At this time, the multimedia service requests a wake-up lock for the audio scenario from the power service. This wake-up lock prevents the system from entering standby mode, keeping the entire system in a wake-up state. If the download service receives a background download event, it requests a wake-up lock for the task scenario from the power service. Due to the mutual exclusion between task scenarios and other standby scenarios, the wake-up lock request for the task scenario will be rejected.

[0209] For example, the first standby scenario is an audio scenario, and the second standby scenario is a call scenario, such as... Figure 8 As shown, when an electronic device plays music and the user presses the power button to turn off the screen, the power service begins standby detection. At this time, the multimedia service requests a wake-up lock for the audio scenario from the power service. This wake-up lock prevents the system from entering standby mode, keeping the entire system in a wake-up state. If the call service receives an incoming call event, it requests a wake-up lock for the call scenario from the power service. Because the audio and call scenarios are not mutually exclusive due to the standby scenario relationship, the wake-up lock request for the call scenario will be granted, and the phone application will be activated.

[0210] Therefore, the wake-up lock for a task scenario cannot be activated in any standby scenario. Once an electronic device has entered a certain standby scenario (excluding task scenarios), the wake-up lock for the task scenario cannot be activated. Simultaneously, the electronic device strictly controls the number of times and the duration of the task scenario wake-up lock execution. Typically, frequent and trivial tasks in the system prevent the electronic device from entering standby mode. This embodiment of the invention, by setting a standby scenario relationship where task scenarios and other standby scenarios are mutually exclusive, can prevent frequent and trivial tasks in the system from preventing the system from entering standby mode.

[0211] Audio, motion, and navigation scenarios can all enter sleep mode from the foreground when the screen is off. For example, standby scenario relationships also include mutual exclusion between scenarios that enter sleep mode from the foreground. There can be mutual exclusion between standby scenarios that can enter standby mode from the foreground; for example, in a motion scenario, the electronic device's screen is off, and the wake-up lock for the audio scenario cannot be activated. However, music and motion scenarios can coexist (for example, if an electronic device is woken up with the screen on, and both a fitness app and a music app are opened, and both exercise and music are played simultaneously, the wake-up locks for both the motion and audio scenarios are activated at the same time).

[0212] Step 208: After the first wake-up lock is released and the screen is turned off, or after both the first and second wake-up locks are released and the screen is turned off, enter standby mode.

[0213] Optionally, the method further includes the following steps before step 204:

[0214] Step 203: Receive the second event.

[0215] For example, when the second event in the second standby scenario comes from the outside, the electronic device needs to receive the second event, such as an incoming call event or an SMS event, before step 204.

[0216] In some possible embodiments, such as Figure 14 As shown, after step 208, the method further includes:

[0217] Step 210: Receive the third event.

[0218] Step 212: Enter the third standby scenario based on the third event. The third standby scenario is the scenario in which the electronic device executes the third event through the third application when it is in standby mode.

[0219] For example, the third standby scenario has the feature of being able to be woken up by hardware.

[0220] For example, the third standby scenario includes a notification scenario or a call scenario. Figure 5 and Figure 6 As shown, both notification and call scenarios have the feature of being able to be woken up by hardware.

[0221] In some possible embodiments, such as Figure 17 As shown, step 212 specifically includes:

[0222] Step 2122: Based on the third event, wake up the system through the hardware corresponding to the third event and activate the system service corresponding to the third event.

[0223] For example, the third standby scenario is a notification scenario. The electronic device has entered standby mode. When it receives an SMS notification, it will wake up the system through hardware. After the system is woken up, it will activate the push service according to the SMS notification.

[0224] For example, the third standby scenario is a call scenario, where the electronic device has entered standby mode. When a call comes in, the system will be woken up by hardware. After the system is woken up, the call service will be activated based on the call event.

[0225] Step 2124: Obtain the third wake-up lock from the power service through the system service corresponding to the third event.

[0226] For example, the third standby scenario is a notification scenario, such as... Figure 9 As shown, the push service requests the wake-up lock for the notification scenario from the power service.

[0227] For example, the third standby scenario is a call scenario, such as... Figure 10 As shown, the call service requests the wake-up lock for the call scenario from the power service.

[0228] Step 2126: Wake up the third application corresponding to the third event according to the third wake-up lock.

[0229] For example, the third application is a text messaging application or a phone application.

[0230] For example, the third standby scenario is the notification scenario, where the electronic device wakes up the SMS application and turns on the screen based on the wake-up lock of the notification scenario.

[0231] For example, the third standby scenario is a call scenario, where the electronic device wakes up the phone application and turns on the screen based on the wake-up lock of the call service.

[0232] Step 2128: Execute the third event through the third application.

[0233] For example, the third standby scenario is the notification scenario, where the SMS application displays SMS notifications.

[0234] For example, the third standby scenario is the call scenario, where the phone application displays an incoming call notification.

[0235] Step 214: After the third wake-up lock corresponding to the third standby scenario is released and the screen is turned off, the system enters standby mode.

[0236] In some possible embodiments, the third event is associated with the fourth event, such as Figure 15 As shown, after step 212, the method further includes:

[0237] Step 213: Enter the fourth standby scenario based on the fourth event. The fourth standby scenario is the scenario in which the electronic device executes the fourth event through the third application when it is in standby mode.

[0238] For example, the fourth event is an audio event. The third standby scenario includes a notification scenario or a call scenario. Since the notification scenario requires the electronic device to play a notification tone, and the call scenario requires the electronic device to play an incoming call ringtone, the third event and the fourth event are related.

[0239] In some possible embodiments, such as Figure 18 As shown, step 213 specifically includes:

[0240] Step 2132: Activate the system service corresponding to the fourth event.

[0241] For example, the system service corresponding to the fourth event is a multimedia service.

[0242] Step 2134: Obtain the fourth wake-up lock from the power service through the system service corresponding to the fourth event.

[0243] Step 2136: Execute the fourth event through the third application.

[0244] In some possible embodiments, the third event is associated with the fourth event, such as Figure 15 As shown, step 214 specifically includes: after the third wake-up lock and the fourth wake-up lock are both released and the screen is turned off, entering standby mode.

[0245] The standby method provided in this embodiment of the invention includes: an electronic device entering a first standby scenario, wherein the first standby scenario is a scenario in which the electronic device, in response to a user's screen-off operation, requests a first wake-up lock based on the first event when executing a first event through a first application; requesting a second wake-up lock for a second standby scenario based on a second event, wherein the second standby scenario is a scenario in which the electronic device, in a standby state, executes the second event through a second application; accepting or rejecting the request for the second wake-up lock based on the first standby scenario, the second standby scenario, and the relationship between the standby scenarios; entering a standby state after the first wake-up lock is released and the screen is off, or after both the first wake-up lock and the second wake-up lock are released and the screen is off; and managing the wake-up lock according to the scenario, so that the electronic device is both controllable and flexible when entering the standby state scenario.

[0246] Figure 19This is a schematic diagram of an electronic device provided in an embodiment of the present invention. It should be understood that the electronic device 400 is capable of executing each step of the standby method described above. To avoid repetition, details are not provided here. The electronic device 400 includes a processing unit 401 and a receiving unit 402.

[0247] The processing unit 401 is configured to cause the electronic device to enter a first standby scenario, wherein the first standby scenario is a scenario in which the electronic device, in response to the user's screen-off operation, requests a first wake-up lock based on the first event when executing a first event through a first application; to request a second wake-up lock for a second standby scenario based on a second event, wherein the second standby scenario is a scenario in which the electronic device, while in standby mode, executes the second event through a second application; to approve or reject the request for the second wake-up lock based on the first standby scenario, the second standby scenario, and the relationship between the standby scenarios; and to enter a standby state after the first wake-up lock is released and the screen is off, or after both the first wake-up lock and the second wake-up lock are released and the screen is off.

[0248] Optionally, before the processing unit 401 requests the second wake-up lock for the second standby scenario based on the second event, the receiving unit 402 is used to receive the second event.

[0249] Optionally, the first standby scenario includes an audio scenario, a motion scenario, a navigation scenario, or a task scenario.

[0250] Optionally, the first application may include a music application, a sports application, a map application, or a browser application.

[0251] Optionally, the second standby scenario includes a notification scenario, a call scenario, an audio scenario, a sports scenario, or a navigation scenario.

[0252] Optionally, the second application may include a text messaging application, a phone application, a music application, a sports application, a map application, or a browser application.

[0253] Optionally, the first standby scenario and the second standby scenario are different.

[0254] Optionally, the first application and the second application are different.

[0255] Optionally, the standby scenario relationship includes: task scenarios and non-task scenarios are mutually exclusive.

[0256] Optionally, the standby scene relationship also includes: mutual exclusion between standby scenes that go into sleep mode from the foreground screen off.

[0257] Optionally, the processing unit 401 is specifically configured to: request the first wake-up lock from the power service through the system service corresponding to the first event in the first standby scenario; and, based on the first event, request the first wake-up lock through the power service.

[0258] Optionally, the processing unit 401 is specifically configured to: request the second wake-up lock from the power service through the system service corresponding to the second event in the second standby scenario.

[0259] Optionally, the system services include multimedia services, push services, call services, download services, sensor services, or navigation services.

[0260] Optionally, after the processing unit 401 enters the standby state, the receiving unit 402 is further configured to receive a third event; the processing unit 401 is further configured to enter a third standby scenario according to the third event, the third standby scenario being a scenario in which the electronic device executes the third event through a third application while in standby state; after the third wake-up lock corresponding to the third standby scenario is released and the screen is turned off, the device enters the standby state.

[0261] Optionally, the processing unit 401 is specifically configured to, based on the third event, wake up the system through the hardware corresponding to the third event and activate the system service corresponding to the third event; request a third wake-up lock from the power service through the system service corresponding to the third event; wake up the third application corresponding to the third event according to the third wake-up lock; and execute the third event through the third application.

[0262] Optionally, the third standby scenario has the feature of being able to be woken up by hardware.

[0263] Optionally, the third standby scenario includes a notification scenario or a call scenario.

[0264] Optionally, the third event is associated with the fourth event.

[0265] Optionally, after the processing unit 401 enters the third standby scenario according to the third event, it is further configured to enter the fourth standby scenario according to the fourth event, wherein the fourth standby scenario is a scenario in which the electronic device executes the fourth event through the third application when it is in standby mode.

[0266] Optionally, the processing unit 401 is specifically configured to activate the system service corresponding to the fourth event according to the fourth event; request a fourth wake-up lock from the power service through the system service corresponding to the fourth event; and execute the fourth event through the third application according to the fourth wake-up lock.

[0267] Optionally, the processing unit 401 is specifically used to: enter a standby state after the third wake-up lock and the fourth wake-up lock are both released and the screen is turned off.

[0268] Optionally, the fourth event is an audio event.

[0269] It should be understood that the electronic device 400 described herein is embodied in the form of a functional unit. The term "unit" here can be implemented in software and / or hardware, without specific limitation. For example, a "unit" can be a software program, hardware circuit, or a combination of both that implements the functions described above. The hardware circuit may include application-specific integrated circuits (ASICs), electronic circuits, a processor (e.g., a shared processor, a proprietary processor, or a group processor, etc.) and memory for executing one or more software or firmware programs, integrated logic circuitry, and / or other suitable components supporting the described functions.

[0270] Therefore, the units of the various examples described in the embodiments of the present invention can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of the present invention.

[0271] This application provides an electronic device, which can be a terminal device or a circuit device built into the terminal device. This electronic device can be used to perform the functions / steps described in the method embodiments above.

[0272] This application provides a computer-readable storage medium storing instructions that, when executed on a terminal device, cause the terminal device to perform the functions / steps described in the above method embodiments.

[0273] This application also provides a computer program product containing instructions that, when run on a computer or any at least one processor, cause the computer to perform the functions / steps described in the above method embodiments.

[0274] In this application embodiment, "at least one" refers to one or more, and "more than one" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent the existence of A alone, the simultaneous existence of A and B, or the existence of B alone. A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one of the following" and similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, and c can represent: a, b, c, ab, ac, bc, or abc, where a, b, and c can be single or multiple.

[0275] Those skilled in the art will recognize that the units and algorithm steps described in the embodiments disclosed herein can be implemented using electronic hardware, computer software, or a combination of electronic hardware and software. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0276] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0277] In the several embodiments provided in this application, any function, if implemented as a software functional unit and sold or used as an independent product, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause an electronic device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0278] The above description is merely a specific embodiment of this application. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the protection scope of this application. The protection scope of this application should be determined by the protection scope of the claims.

Claims

1. A standby method, characterized in that, The method includes: The electronic device enters a first standby scenario, which is the scenario in which the electronic device responds to the user's screen-off operation when the first event is executed by the first application, and requests a first wake-up lock according to the first event; The second wake-up lock for the second standby scenario is requested according to the second event, wherein the second standby scenario is that the electronic device executes the second event through the second application while in standby state; The application for the second wake-up lock is approved or rejected based on the first standby scenario, the second standby scenario, and the relationship between the standby scenarios; After rejecting the second wake-up lock request, and after the first wake-up lock is released and the screen is off, it enters standby mode; or, After the second wake-up request is approved, and both the first and second wake-up locks are released and the screen is turned off, the device enters standby mode.

2. The method according to claim 1, characterized in that, Before requesting the second wake-up lock for the second standby scenario based on the second event, the method further includes: Receive the second event.

3. The method according to claim 1 or 2, characterized in that, The first standby scenario includes an audio scenario, a sports scenario, a navigation scenario, or a task scenario, and the first application includes a music application, a sports application, a map application, or a browser application.

4. The method according to claim 1 or 2, characterized in that, The second standby scenario includes notification scenario, call scenario, audio scenario, sports scenario, navigation scenario, or task scenario, and the second application includes SMS application, phone application, music application, sports application, map application, or browser application.

5. The method according to claim 1, characterized in that, The standby scenario relationships include: task scenarios and non-task scenarios are mutually exclusive.

6. The method according to claim 5, characterized in that, The standby scene relationships also include: mutual exclusion between standby scenes that go from the foreground screen to sleep.

7. The method according to claim 1, characterized in that, The step of obtaining the first wake-up lock according to the first standby scenario includes: The system service corresponding to the first event in the first standby scenario requests the first wake-up lock from the power service; Based on the first event, the power service requests the first wake-up lock.

8. The method according to claim 1, characterized in that, After entering standby mode, the following is also included: Receive third event; The third standby scenario is entered according to the third event, which is a scenario in which the electronic device executes the third event through a third application when it is in standby mode; After the third wake-up lock corresponding to the third standby scenario is released and the screen is turned off, the system enters standby mode.

9. The method according to claim 8, characterized in that, The step of entering a third standby scenario based on the third event, wherein the third standby scenario is when the electronic device is in standby mode and the third event is executed by a third application, specifically includes: Based on the third event, the system is woken up by the hardware corresponding to the third event and the system service corresponding to the third event is activated; The system service corresponding to the third event requests a third wake-up lock from the power service; The third application corresponding to the third event is activated according to the third wake-up lock; The third event is executed through the third application.

10. The method according to claim 9, characterized in that, The third event is related to the fourth event; After entering the third standby scenario based on the third event, the process further includes: The fourth standby scenario is entered according to the fourth event. The fourth standby scenario is the scenario in which the electronic device executes the fourth event through the third application when it is in standby mode.

11. The method according to claim 10, characterized in that, The step of entering a fourth standby scenario based on the fourth event, wherein the fourth standby scenario is a scenario in which the electronic device executes the fourth event through the third application while in standby mode, specifically includes: Activate the system service corresponding to the fourth event according to the fourth event; The system service corresponding to the fourth event requests the fourth wake-up lock from the power service; The fourth event is executed by the third application according to the fourth wake-up lock.

12. The method according to claim 11, characterized in that, The step of entering standby mode after the third wake-up lock corresponding to the third standby scenario is released and the screen is turned off includes: After the third and fourth wake-up locks are released and the screen is turned off, the device enters standby mode.

13. An electronic device, characterized in that, The device includes a processor and a memory, wherein the memory is used to store a computer program, the computer program including program instructions that, when the processor executes the program instructions, cause the electronic device to perform the steps of the method as described in any one of claims 1-12.

14. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, the computer program including program instructions that, when requested to be run by a computer, cause the computer to perform the method as described in any one of claims 1-12.

Images