Hibernation state management methods and terminal devices

Abstract

This application provides a method and terminal device for managing a sleep state, applicable to terminal devices with a USB Type-C interface, which helps reduce power consumption of the terminal device. The method includes: connecting a digital headset to the terminal device; at a first time point, turning off the terminal device screen, and maintaining this screen-off state for a preset duration after the first time point, without any audio input or output; at a second time point, entering a sleep state; after the second time point, turning on the terminal device screen; disconnecting the terminal device from the digital headset; connecting the terminal device to another USB device, which is not a digital headset; at a third time point, turning off the terminal device screen, and maintaining this screen-off state for a preset duration after the third time point, without any audio input or output; starting from the third time point, the terminal device does not enter a sleep state after the preset duration.

Description

Technical Field

[0001] This application relates to the field of terminals, and more particularly to a method for managing a hibernation state and a terminal device. Background Technology

[0002] Most terminal devices on the market (such as mobile phones) are equipped with a headphone jack, allowing users to plug in headphones for audio input or output, such as playing music, making phone calls, and recording.

[0003] Typically, to save power, terminal devices can enter a sleep state when there is no audio input or output after headphones are plugged in.

[0004] However, in some scenarios, the inventors discovered that after plugging in digital headphones, the terminal device could not enter sleep mode even without audio input or output, which increased the power consumption of the terminal device. Summary of the Invention

[0005] This application provides a method and terminal device for managing sleep mode, which helps the terminal device enter sleep mode when there is no audio input or output, thereby reducing the power consumption of the terminal device.

[0006] In a first aspect, this application provides a method for managing a sleep state, applied to a terminal device with a Universal Serial Bus (USB) Type-C interface. The method includes: the terminal device turning on its screen; the terminal device connecting to a digital headset via the USB Type-C interface; at a first time point, the terminal device turning off its screen; and for a preset duration after the first time point, the terminal device remaining in a screen-off state with no audio input or output; at a second time point, the terminal device entering a sleep state, the duration between the first and second time points being greater than or equal to the preset duration; after the second time point, the terminal device turning on its screen; the terminal device disconnecting from the digital headset; the terminal device connecting to another USB device via the USB Type-C interface, wherein the other USB device is not a digital headset; at a third time point, the terminal device turning off its screen; and for a preset duration after the third time point, the terminal device remaining in a screen-off state with no audio input or output; starting from the third time point, the terminal device not entering a sleep state after the preset duration.

[0007] Based on the technical solution of this application, when a digital headset is connected to a terminal device while the screen is on, the terminal device can enter a sleep state if there is no audio input or output within a preset time after the screen is turned off. This helps to save power consumption of the terminal device and improve the user experience.

[0008] In scenarios where the terminal device is connected to other USB devices (not digital headphones), the terminal device can recognize that the connected USB device is not a digital headphone. Therefore, even if there is no audio input or output within a preset time after the screen is turned off, the terminal device will not enter sleep mode.

[0009] In conjunction with the first aspect, in some implementations of the first aspect, the method further includes: after the terminal device connects to the digital headset via the USB Type-C interface, the terminal device holds a kernel lock on the USB; at a second time point, the terminal device enters a sleep state, including: at the second time point, the terminal device releases the kernel lock on the USB and enters a sleep state.

[0010] In this application, after the terminal device connects to the digital headset, it holds a USB kernel lock (hereinafter referred to as the USB lock). The terminal device will not enter a sleep state while holding the USB lock. After the terminal device releases the USB lock, it can enter a sleep state, which helps to save power consumption of the terminal device.

[0011] In conjunction with the first aspect, in certain implementations of the first aspect, the terminal device releases the USB kernel lock, including:

[0012] After the terminal device screen is turned off, the terminal device determines that there is no audio input or output and starts timing; the terminal device determines that the duration of no audio input or output has reached the preset duration and releases the USB kernel lock.

[0013] In one possible scenario, a user plays music through digital headphones. The user might briefly pause playback and then resume playback after a very short period (less than a preset duration). If the terminal device immediately releases the USB lock and enters sleep mode after pausing playback, the user may be unable to resume playback, causing inconvenience and degrading the user experience. Therefore, in this application, the terminal device can release the USB kernel lock only after a preset duration of inactivity (no audio input or output), thus improving the user experience.

[0014] In conjunction with the first aspect, in certain implementations of the first aspect, the terminal device determines that there is no audio input or output, including: the terminal device detects the state of the wake-up lock of the audio input interface and the state of the wake-up lock of the audio output interface; when the wake-up lock of the audio input interface is in a released state and the wake-up lock of the audio output interface is in a released state, the terminal device determines that there is no audio input or output.

[0015] In conjunction with the first aspect, in some implementations of the first aspect, after the second or third time point, the method further includes: the terminal device turns on its screen, holds the kernel lock of the USB, and the terminal device has no audio input or output; at the fourth time point, the terminal device turns off its screen; at the fifth time point, the terminal device turns on its screen, the duration between the fourth and fifth time points is less than a preset duration, and the terminal device does not enter a sleep state between the fourth and fifth time points.

[0016] In conjunction with the first aspect, in some implementations of the first aspect, after the third time point, the method further includes: the terminal device turning on its screen; the terminal device connecting to a digital headset via a USB Type-C interface and holding a USB kernel lock; the terminal device playing audio via the digital headset; at the sixth time point, the terminal device turning off its screen; at the seventh time point, music playback on the terminal device ending, and for a preset duration after the seventh time point, the terminal device remaining in a screen-off state with no audio input or output; at the eighth time point, the terminal device releasing the USB kernel lock and entering a hibernation state, wherein the duration between the seventh time point and the eighth time point is greater than or equal to the preset duration.

[0017] In this application, after the terminal device connects to a digital headset and holds the USB kernel lock, if the terminal device has audio input or output, it does not release the USB kernel lock or enter sleep mode while the screen is off. This prevents interruption of music playback and improves the user experience. When music playback ends and there is no audio output, the terminal device, while the screen is off and the duration of no audio input or output reaches a preset time, can release the USB kernel lock and enter sleep mode, which helps reduce power consumption.

[0018] In conjunction with the first aspect, in some implementations of the first aspect, after the sixth time point and before the seventh time point, the method further includes: the terminal device determines that there is audio input or output, and does not release the kernel lock of the USB.

[0019] In conjunction with the first aspect, in some implementations of the first aspect, the terminal device releasing the USB kernel lock also needs to meet at least one of the following conditions: the user does not have the habit of using a voice assistant; the terminal device is in sleep mode and the terminal device is in an absolutely static state; or, the terminal device is in a permanent location.

[0020] Secondly, this application provides a method for managing a hibernation state, applied to a terminal device with a USB Type-C interface. The method includes: the terminal device turning on its screen; the terminal device connecting a digital headset via the USB Type-C interface and holding a USB kernel lock; the terminal device turning off its screen; starting a timer when there is no audio input or output on the terminal device; and releasing the USB kernel lock and entering a hibernation state after the timer has reached a preset duration, wherein there is no audio input or output on the terminal device during the timer.

[0021] In this application, after connecting digital headphones, the terminal device holds a USB kernel lock. While holding the USB kernel lock, the terminal device does not enter sleep mode when the screen is off. After the terminal device's screen is off, if there is no audio input or output, the terminal device can start a timer. If the duration of no audio input or output reaches a preset duration, the terminal device can release the USB kernel lock and enter sleep mode. This helps reduce power consumption and improves the user experience.

[0022] In conjunction with the second aspect, in some implementations of the second aspect, the method further includes: during the timing process of the terminal device, if the terminal device has audio input or output, the terminal device exits the timing and resets the timing duration to zero.

[0023] Thirdly, this application provides a terminal device, which can also be referred to as a terminal, user equipment (UE), mobile station (MS), mobile terminal (MT), etc. The terminal device can be a mobile phone, personal computer (PC), smart TV, wearable device, tablet computer, computer with wireless transceiver function, virtual reality (VR) terminal device, augmented reality (AR) terminal device, wireless terminal in industrial control, wireless terminal in self-driving, wireless terminal in remote medical surgery, wireless terminal in smart grid, wireless terminal in transportation safety, wireless terminal in smart city, wireless terminal in smart home, etc.

[0024] The terminal device includes: a processor and a memory; the memory stores computer-executable instructions; the processor executes the computer-executable instructions stored in the memory, causing the terminal device to perform the method as described in the first aspect.

[0025] Fourthly, this application provides a computer-readable storage medium storing a computer program. When executed by a processor, the computer program implements the method as described in the first aspect.

[0026] Fifthly, this application provides a computer program product comprising a computer program that, when run, causes a computer to perform the method as described in the first aspect.

[0027] In a sixth aspect, this application provides a chip including a processor for calling a computer program in memory to perform the method described in the first aspect.

[0028] It should be understood that the third to sixth aspects of this application correspond to the technical solutions of the first or second aspects of this application, and the beneficial effects achieved by each aspect and the corresponding feasible implementation are similar, and will not be repeated here. Attached Figure Description

[0029] Figure 1 This is a schematic diagram of the structure of a terminal device to which this application embodiment applies;

[0030] Figure 2 This is a software structure block diagram of a terminal device to which the embodiments of this application are applicable;

[0031] Figure 3A This is a schematic diagram illustrating the interaction between a simulated headset and a mobile phone, provided in an embodiment of this application.

[0032] Figure 3B This is a schematic diagram illustrating the interaction between a digital headset and a mobile phone, provided in an embodiment of this application.

[0033] Figure 4 This is a schematic diagram of a Type-C interface provided in an embodiment of this application;

[0034] Figure 5 This is a schematic diagram of a scenario provided in an embodiment of this application;

[0035] Figure 6 This is a schematic flowchart illustrating a method for managing a dormant state provided in an embodiment of this application;

[0036] Figure 7 This is a flowchart illustrating a device detection process performed by a terminal device after an earphone is inserted, as provided in an embodiment of this application.

[0037] Figure 8This is a flowchart illustrating the release of a USB lock according to an embodiment of this application;

[0038] Figure 9 This is a schematic flowchart illustrating another method for managing a dormant state provided in an embodiment of this application;

[0039] Figure 10 This is a schematic flowchart illustrating another method for managing a dormant state provided in an embodiment of this application. Detailed Implementation

[0040] The technical solutions in this application will now be described with reference to the accompanying drawings.

[0041] To facilitate a clear description of the technical solutions in the embodiments of this application, some terms involved in the embodiments of this application are briefly introduced below:

[0042] In the embodiments of this application, the terms "first" and "second" are used to distinguish identical or similar items with essentially the same function and effect, without limiting their order. Those skilled in the art will understand that the terms "first" and "second" do not limit the quantity or execution order, and that the terms "first" and "second" do not necessarily imply that they are different.

[0043] It should be noted that, in this application, the words "exemplarily" or "for example" are used to indicate examples, illustrations, or explanations. Any embodiment or design described as "exemplarily" or "for example" in this application should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of words such as "exemplarily" or "for example" is intended to present the relevant concepts in a specific manner.

[0044] Furthermore, "at least one" refers to one or more, while "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 mean: A alone, A and B simultaneously, or B alone, where 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" or 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 mean: a, or b, or c, or a and b, or a and c, or b and c, or a, b, and c, where a, b, and c can be single or multiple.

[0045] It should be noted that the phrase "at...time" in the embodiments of this application can refer to the instant at which a certain situation occurs, or to a period of time after the occurrence of a certain situation; the embodiments of this application do not specifically limit this. Furthermore, the display interface provided in the embodiments of this application is merely an example, and the display interface may include more or less content.

[0046] Figure 1 This is a schematic diagram of the structure of a terminal device to which this application embodiment applies. For example... Figure 1 As shown, the terminal device 100 may include: a processor 110, an external memory interface 120, an internal memory 121, a USB interface 130, a charging management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, a headphone jack 170D, a sensor module 180, buttons 190, a motor 191, an indicator 192, a camera 193, a display screen 194, and a subscriber identity module (SIM) card interface 195, etc.

[0047] 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.

[0048] It is understood that the structure illustrated in this embodiment does not constitute a specific limitation on the terminal device 100. In other embodiments of this application, the terminal 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.

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

[0050] Figure 2This is a software architecture block diagram of a terminal device to which this application embodiment applies. The layered architecture divides the software system of the terminal device 100 into several layers, each with a clear role and division of labor. Layers communicate with each other through software interfaces. In some embodiments, the Android system can be divided into an application layer (APP), an application framework layer, an Android runtime and system libraries, a hardware abstraction layer (HAL), and a kernel layer. In some embodiments, the terminal device 100 also includes hardware (e.g., a microphone, a speaker).

[0051] The application layer can include a series of application packages. The application layer runs applications by calling the application programming interface (API) provided by the application framework layer. For example... Figure 2 As shown, the application package may include applications such as camera, calendar, map, call, music, WLAN, Bluetooth, video, social networking, gallery, navigation, SMS, and power saving.

[0052] Among them, Power Saving Wizard can be understood as a system-level APP. Its function is to monitor and find which application in the Android system is consuming power, which software resources and hardware resources are consuming power, and intelligently identify whether there is any abnormal or unreasonable use of resources that is imperceptible to the user. Once an abnormality is detected, measures are taken to dynamically adjust the reasonable reallocation of software and hardware resources to reduce background power consumption.

[0053] It should be understood that the Power Saving Genie APP in this application is only an example, and other APPs with similar or the same functions as the Power Saving Genie APP that can perform similar or the same technical solutions as this application are also within the protection scope of the embodiments of this application.

[0054] The application framework layer provides APIs and a programming framework for applications within the application layer. The application framework layer includes predefined functions. For example... Figure 2 As shown, the application framework layer may include a window manager, content provider, resource manager, notification manager, view system, phone manager, etc.

[0055] 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.

[0056] Content providers store and retrieve data, making that data accessible to applications. This data can include video images, audio, phone calls made and received, browsing history and bookmarks, phone books, and more.

[0057] 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.

[0058] The phone manager is used to provide the call status of terminal device 100, obtain phone information (e.g., device information, SIM card information, and network information), monitor phone status (e.g., call status, service status, and signal strength status), and can invoke the phone dialer to make calls.

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

[0060] 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 download completion or message alerts. The notification manager can also display notifications as icons or scrolling text in the system's 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 alert sounds, vibrating the device, or flashing indicator lights.

[0061] The power manager (PM) provides the power management service (PMS), which is the core service for power management in the Android system. Its functions include: providing upper-level interfaces to applications, such as keeping the system awake in audio scenarios and waking the phone screen in message notification scenarios; and making decisions at the hardware abstraction layer and kernel layer to control the device's standby state and the status of hardware devices such as the display, backlight, proximity sensor, and light sensor. Common device functions such as screen on / off, brightness adjustment, low power mode, and keeping the central processing unit (CPU) awake can all be coordinated and handled through the PMS.

[0062] PM is a proxy class for PMS. PM provides an interface for interaction with upper-layer applications. After the upper-layer application calls the interface of PM, the actual work is completed by PMS. The interfaces provided by PM include: wakeUp, gotoSleep, userActivity, and wakelock.

[0063] WakeLock provides related interfaces for manipulating wakelocks. The application layer can use the newWakeLock method to create a wakelock, and use the acquire and release functions to acquire and release the wakelock.

[0064] The Android runtime consists of the core libraries and the virtual machine. The Android runtime is responsible for scheduling and managing the Android system. The core libraries comprise two parts: one part contains the Java functions that the Java API framework needs to call, and the other part consists of the Android core libraries. The application layer and application framework layer run in the 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.

[0065] 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.

[0066] The Surface Manager manages the display subsystem and provides fusion of 2D and 3D layers for multiple applications. The Media Library supports playback and recording of various common audio and video formats, as well as still image files. The Media Library supports multiple audio and video encoding formats, such as MPEG4, H.264, MP3, AAC, AMR, JPG, and PNG. The 3D Graphics Processing Library implements 3D graphics drawing, image rendering, compositing, and layer processing. The 2D Graphics Engine is the drawing engine for 2D graphics.

[0067] The Hardware Abstraction Layer (HAL) is an abstract interface for the device kernel driver, providing application programming interfaces (APIs) for accessing the underlying device to higher-level Java API frameworks. The HAL can include multiple library modules, such as display, audio, Bluetooth, and Wi-Fi modules, each implementing an interface for a specific type of hardware component. When the framework API requests access to the device hardware, the Android system loads the corresponding library module for that hardware component.

[0068] The kernel layer is the layer between hardware and software. It drives the hardware, enabling it to function. The kernel layer includes at least display drivers, audio drivers, Bluetooth drivers, Wi-Fi drivers, and USB drivers, though this embodiment does not limit the specific drivers. The USB driver includes: the USB host driver, the USB device driver (or slave driver), and OTG (on-the-go).

[0069] It should be understood that the terminal device involved in the embodiments of this application may have the features described above. Figure 1 and / or Figure 2 The architecture shown below illustrates the technical solution of this application and how it solves the aforementioned technical problems through specific embodiments. These specific embodiments can be implemented independently or in combination with each other. Similar or identical concepts or processes may not be described again in some embodiments. It should be understood that the interfaces provided in the embodiments of this application are merely examples and do not constitute further limitations on the embodiments of this application.

[0070] Currently, headphones on the market include analog headphones and digital headphones. Analog headphones can be headphones with a 3.5-inch analog headphone jack or headphones with a USB Type-C analog headphone jack. Digital headphones can be headphones with a USB Type-C interface (which can be called USB digital headphones). This application embodiment uses a digital headphone with a USB Type-C interface as an example for description.

[0071] The following section uses a mobile phone as an example to describe the interaction process between analog and digital headphones and the mobile phone.

[0072] Figure 3A This is a schematic diagram illustrating the interaction between a simulated headset and a mobile phone, provided in an embodiment of this application. Figure 3A The mobile phone 01 includes an access point (AP) 31, a decoder 32, and a digital-to-analog converter (DAC) 33, while the analog headset 02 includes a sound-generating unit 34. The mobile phone 01 has a USB Type-C headphone jack, and the analog headset has a USB Type-C analog headphone jack.

[0073] When analog headphones 02 are plugged into mobile phone 01 to play music, mobile phone 01 decodes and converts the digital audio signal to analog signal via AP 31, decoder 32, and DAC 33, and outputs analog audio signal to analog headphones 02 through the Type-C interface. After receiving the analog audio signal, analog headphones 02 processes the conversion between analog quantity and sound output (input and output), and outputs audio through the sound unit 34 of analog headphones 02.

[0074] Figure 3B This is a schematic diagram illustrating the interaction between a digital headset and a mobile phone, provided in an embodiment of this application. Figure 3B The mobile phone 03 includes an access point (AP) 35, and the digital headset 04 includes a decoder 36, a DAC 37, and a sound-generating unit 38. When the digital headset 04 is plugged into the mobile phone 03 to play music, the mobile phone 03 outputs a digital audio signal through the AP 35, which is then output to the digital headset 04 via the Type-C interface. After receiving the digital audio signal, the digital headset 04 performs audio decoding via the decoder 36 and digital-to-analog conversion via the DAC 37, before outputting the audio through the sound-generating unit 38.

[0075] Typically, the digital headset 04 has a high-performance decoder 36 and DAC 37. This allows it to deliver high-quality audio and high-fidelity playback even when the mobile phone 04 lacks sufficient decoder and DAC capabilities. In contrast, the analog headset 02 lacks its own built-in decoder and DAC, relying on the mobile phone 01 for these functions. Therefore, achieving high-quality audio playback requires high-performance decoders and DACs from the mobile phone 01.

[0076] Therefore, without considering the performance of a phone's decoder and DAC, digital headphones are more universally compatible and can be used with more types of phones. Based on this, in recent years, the Type-C interface on mobile phones has become increasingly multifunctional, with many phones eliminating the 3.5-inch analog headphone jack and instead outputting audio via Type-C. Changing the headphone jack from analog to Type-C serves two purposes: firstly, to standardize the interface, and secondly, to allow users to connect external digital headphones and directly output digital audio signals to them. Compared to analog headphones, using the built-in decoder of digital headphones provides a better sound quality experience.

[0077] Type-C is a USB interface form factor standard, short for USB Type-C interface. It is an interface type that can be used in both PCs (host devices) and external devices (slave devices, such as mobile phones). Visually, its top and bottom are completely identical, eliminating the distinction between the front and back of a USB port.

[0078] Figure 4 This is a schematic diagram of a Type-C interface provided in an embodiment of this application. Figure 4As shown, the Type-C interface includes 24 pins, of which 8 pins are for power (VBUS) and ground (GND), which can be used to improve power transmission capability; there are two sets of cross-connected data signal lines A6 and A7, B6 and B7 for transmitting USB 2.0 data; and there are two sets of data signal lines A2 and A3, B11 and B10 for transmitting USB 3.0 / USB 4.0 data.

[0079] Optionally, Figure 4 The diagram shows the interface schematic of a Type-C male connector (or plug). The male connector can be inserted into a female connector (or socket), and the pin functions of the male and female connectors are compatible regardless of whether they are plugged in or out. Pins A5CC (configuration channel) and B5 VCONN of the Type-C male connector are key to the Type-C interface, and their function is to confirm the transmission direction and the correct insertion direction during the Type-C connection process.

[0080] For example, when charging a mobile phone with a Type-C interface using a charging cable with a Type-C interface, the phone detects whether the connection is established by pin A5 CC or pin B5 VCONN. This allows the phone to determine the correct orientation of the cable during charging, thus ensuring proper configuration of data transmission and signal correspondence.

[0081] Figure 4 The pinouts of the Type-C male connector are shown in Table 1.

[0082] Table 1

[0083]

[0084]

[0085] During operation, terminal devices often need to ensure that the CPU can continuously work while performing relevant tasks. Therefore, the kernel layer of the terminal device's operating system prevents the CPU from sleeping. The kernel layer generally uses a locking mechanism to prevent the CPU from sleeping, such as a wakelock. The wakelock mechanism is a native mechanism of the Linux kernel, and all wakelocks are ultimately implemented in the Linux kernel. The following explanation uses the Android system as an example to illustrate the wakelock mechanism.

[0086] In the Android system, the wakelock of a terminal device includes a kernel driver lock and a lock at the Android upper layer. The kernel driver lock can be marked with a separate name at the kernel's wakelock management node; this is called a holding lock. Because this lock is added directly at the kernel's wakelock management node, such a lock can be called a kernel lock. For example, the kernel lock for USB is a USB suspend lock; in this embodiment, the USB kernel lock is referred to as a USB lock.

[0087] It should be noted that in this embodiment, the lock that can prevent the terminal device from sleeping is called a wakelock. That is, when an application holds a wakelock and / or the kernel layer holds a wakelock, the terminal device cannot enter a sleep state. Specifically, the application can request to hold a lock on the upper layer of Android (which can be simply referred to as the upper-layer lock) from the PMS, and the kernel layer can hold a kernel lock.

[0088] Figure 5 This is a schematic diagram of a scenario provided in an embodiment of this application. Figure 5 Taking a mobile phone as an example, the illustration shows a user placing a digital headset (e.g., a mobile phone) while the phone screen is on. Figure 3B The digital earphone 04) is plugged into the phone (e.g. Figure 3B In scenario 03 of the mobile phone, in response to a user inserting digital headphones, the phone first determines the type of the inserted device. If it confirms that it is a USB device, the phone executes the connection process. After the user inserts the digital headphones, the phone recognizes them as a USB device, executes the connection process, and holds the USB lock. Even if the phone has no audio input or output, it will continue to hold the USB lock until the headphones are unplugged. Ultimately, holding the USB lock prevents the terminal device from entering sleep mode, increasing battery consumption.

[0089] For example, in some scenarios, if a user falls asleep after plugging in digital headphones to listen to music on their phone at night, and the music finishes playing without any audio input or output, the phone will remain locked due to the digital headphones not being unplugged, leading to increased power consumption at night.

[0090] It's important to note that when digital headphones are plugged into the phone, it enters USB host mode, holding a USB lock and driving the USB OTG device—this is a native kernel mechanism. However, when analog headphones (e.g., headphones with a 3.5-inch analog headphone jack) are plugged in, they are not recognized as USB devices, so the phone doesn't hold a USB lock, allowing the system to hibernate normally during standby. In hibernation mode, the phone's CPU draws less current than during operation, conserving battery power.

[0091] In view of the problem that the phone's system cannot hibernate during standby due to the fact that the phone still holds the USB lock when there is no audio input or output, resulting in high power consumption, this application provides a hibernation state management method. When a digital headset is plugged into the phone, if the phone has no audio input or output for a period of time, the phone can release the USB lock. This allows the phone's system to hibernate normally during standby, reducing the phone's power consumption.

[0092] Figure 6 This is a schematic flowchart of a hibernation state management method 600 provided in an embodiment of this application. Figure 6 This illustrates the process by which a terminal device releases its USB lock to enter sleep mode after a digital headset is plugged in.

[0093] The terminal device in this embodiment of the application has a Type-C interface (as a Type-C female connector), and the Type-C interface of the digital headset is inserted into the Type-C interface of the terminal device as a male connector. The terminal device may have, for example... Figure 2 The software architecture shown includes an application layer, an application framework layer, and a kernel layer. The application layer includes the Power Saving Assistant app; the application framework layer includes Power Management System (PMS), which manages upper-level locks for the application; and the kernel layer manages various kernel locks.

[0094] Method 600 includes steps S601 to S603, and the specific steps are as follows:

[0095] S601, the terminal device screen lights up in response to the insertion of digital headphones. The terminal device connects to the digital headphones and holds the USB lock.

[0096] Optionally, "screen on" on the terminal device can indicate that the screen of the terminal device is powered on, and the terminal device is in a screen-on state after the screen is powered on.

[0097] Optionally, turning on the terminal device screen can also indicate that the screen brightness is greater than the preset brightness.

[0098] After the terminal device connects to the digital headset via the USB Type-C interface, the terminal device first detects the inserted device. The following section will combine... Figure 7 This describes the process by which the terminal device detects the inserted device.

[0099] Combining the above text Figure 4 And Table 1, Figure 7 This is a flowchart illustrating a device detection process provided in an embodiment of this application, showing the process of device detection performed by a terminal device after headphones are plugged in. The terminal device in this embodiment has a Type-C interface (as a Type-C female connector). When headphones with a Type-C interface (as a Type-C male connector) are plugged into the terminal device, the terminal device first determines whether the plugged-in headphones are analog or digital headphones based on the voltage level of pin A5 or pin B5 of the Type-C male connector.

[0100] In one possible scenario, if the voltage level of pin A5 or pin B5 is low, the terminal device determines that an analog headset is inserted. Further, the terminal device determines the headset's insertion status—whether it's correctly inserted or incorrectly inserted—based on the resistance value of pin A5 or pin B5. After determining the insertion orientation, the terminal device further determines the pin output of the Type-C interface. For example, it might use pin A7 or pin B7 to output the left channel signal, pin A6 or pin B6 to output the right channel signal, and pin A8 or pin B8 to output the microphone (MIC) signal. The terminal device can then execute the normal analog headset procedure, outputting analog audio signals through the Type-C interface.

[0101] In another possible scenario, if pin A5 or pin B5 is high, the terminal device executes the USB device detection process. The terminal device and the headset communicate based on the USB protocol. If the headset returns a device descriptor to the terminal device, the terminal device confirms that a USB device has been inserted. After confirming that a USB device has been inserted, the terminal device enters USB HOST mode, identifies the headset as a USB OTG device, executes the Linux native OTG device process, and holds the USB lock. The device descriptor includes information such as device type, device manufacturer, and device name. The terminal device can determine that the connected USB OTG device is a digital headset based on the device type. Subsequently, the terminal device's AP transmits digital audio signals to the digital headset through the Type-C interface. After receiving the digital audio signals, the digital headset decodes them using a decoder and converts them using a DAC before outputting analog audio signals.

[0102] During the process of detecting the inserted device on the terminal device, after determining that the inserted device is a USB device, the terminal device holds a USB lock through the kernel layer.

[0103] Optionally, kernel-level holding of USB locks may include: the kernel layer recording the name of the USB lock (USB suspend lock) in a linked list. When releasing the USB lock, the kernel layer can delete the USB lock name from the linked list. When the linked list is empty, it indicates that the kernel layer does not hold any locks.

[0104] Optionally, after determining that a digital headset is inserted, the terminal device sets the value of a preset flag to true. When the value of the preset flag is true, the process of managing the USB lock according to this embodiment can be initiated. When the digital headset is unplugged, the terminal device sets the value of the preset flag to false and exits the process of managing the USB lock according to this embodiment.

[0105] Optionally, the preset flag is a flag set in a preset application, such as the Power Saving Genie APP.

[0106] Taking the Power Saving Assistant APP as a default application as an example, optionally, the terminal device can register a first listening event with the kernel layer through the Power Saving Assistant APP. This first listening event is used to monitor the state of the kernel lock. The kernel lock state includes a holding state and a released state. After acquiring the USB lock, the kernel layer can return a lock-acquire event to the Power Saving Assistant APP, indicating that the kernel layer holds the USB lock. This allows the Power Saving Assistant APP to know that the kernel layer holds the USB lock, preventing the terminal device's system from entering hibernation mode during standby. Correspondingly, the Power Saving Assistant APP receives the lock-acquire event from the kernel layer. Similarly, when releasing the USB lock, the kernel layer can return a release event to the Power Saving Assistant APP, indicating that the kernel layer releases the USB lock.

[0107] Optionally, the Power Saving Genie app can record the names of kernel locks held by the kernel layer.

[0108] S602, at the first time point, the terminal device screen turns off, and for a preset duration after the first time point, the terminal device remains in the screen-off state and there is no audio input or output.

[0109] Optionally, "screen off" on the terminal device can mean that the screen of the terminal device is powered off, and the terminal device is in a screen-off state after the screen is powered off.

[0110] Optionally, turning off the terminal device screen can also indicate that the screen brightness is less than the preset brightness.

[0111] The terminal device can turn off the screen after the user presses the power button, or the terminal device can turn off the screen after not detecting any user operation within a preset time.

[0112] Taking Android phones as an example, Android phone screens typically have three state changes: screen on and bright, screen unlocked (on), and screen off and black (off). The system will issue corresponding system broadcast messages for these three state changes, and applications only need to register for the corresponding broadcast to listen for the screen state changes.

[0113] Optionally, when the terminal device screen is off, the power-saving app on the terminal device can receive a system broadcast message to indicate the screen-off event. After receiving the system broadcast message, the power-saving app can determine that the screen is off and has entered the screen-off state.

[0114] Optionally, after the terminal device screen is turned off, the terminal device's screen driver can update the screen state node to "screen off". The screen state node is used to record the screen state, which includes "screen on" and "screen off".

[0115] After the terminal device's screen is turned off, it first checks if a preset flag is true. If the preset flag is true, the terminal device is triggered to detect whether there is audio input or output. The following describes the process by which the terminal device detects audio input or output, specifically involving the interaction between the terminal device's internal power-saving app and the Power Management System (PMS).

[0116] The Power Saving Genie app registers a second listening event with the Power Management System (PMS). This second listening event is used to monitor the status of the upper-level lock. The status of the upper-level lock includes either a held state or a released state. For example, the upper-level lock includes an AudioMIX lock for the audio output interface (AudioMIX) and an AudioIN lock for the audio input interface (AudioIN).

[0117] Optionally, the PMS returns a message indicating successful registration to the Power Saver app.

[0118] Applications can request to acquire or release a lock from the Power Saver Management System (PMS) based on different usage scenarios. For example, an application with audio output can request an AudioMIX lock, while an application with audio input can request an AudioIN lock. After an application acquires or releases a lock, the PMS can return an event to the Power Saver app to indicate the lock's state change.

[0119] When an application requests a lock from the Power Saver Management System (PMS), the PMS returns an acquire event to the Power Saver App to indicate that an application has acquired the upper-level lock. When an application requests to release a lock from the PMS, the PMS returns a release event to the Power Saver App to indicate that an application has released the upper-level lock. After receiving the event, the Power Saver App records the state of the upper-level lock. For example, if it indicates that an application has acquired an AudioMIX lock, the Power Saver App records the AudioMIX lock as acquired; if it indicates that an application has released an AudioMIX lock, the Power Saver App records the AudioMIX lock as released.

[0120] Optionally, the Power Saving App records the state of the upper-level lock, which may include: the Power Saving App uses a map to record the state of the upper-level lock. When a lock holding event is reported, the Power Saving App records the name of the lock contained in the lock holding event in the map; when a release event is reported, the Power Saving App deletes the name of the lock contained in the release event from the map. If the size of the map is 0 at any time, it means that no lock holding is currently applied.

[0121] For example, when a user opens a music app to play music, the music app can request an AudioMIX lock from the Power Saving Manager (PMS). After successfully requesting the AudioMIX lock, the music app holds the AudioMIX lock, and the AudioMIX lock is in a held state. The PMS records that the AudioMIX lock is in a held state and returns an acquire event to the Power Saving Manager app. After receiving the acquire event, the Power Saving Manager app can know that an application has requested to hold the AudioMIX lock. Optionally, the acquire event can indicate the name of the application that requested to hold the AudioMIX lock, such as the music app.

[0122] When detecting audio input or output, the terminal device can check the recorded upper-level lock status to determine whether an application holds an AudioMIX lock or an AudioIN lock. If the recorded upper-level locks held by the application do not include an AudioMIX lock or an AudioIN lock, it indicates that there is no audio input or output. If the recorded upper-level locks held by the application include an AudioMIX lock or an AudioIN lock, it indicates that there is audio input or output.

[0123] When the terminal device detects no audio input or output, it starts a timer via the Power Saver APP and detects whether the state of the AudioMIX lock and / or AudioIN lock changes during the timer.

[0124] It should be noted that the device screen remains off throughout the timing period. If the device screen is turned on during the timing period, the Power Saving Assistant app will exit the timing.

[0125] The Power Saving Assistant app starts a timer based on a preset duration. For example, when the timer starts, the Power Saving Assistant app can set the preset timer marker to "1" to indicate that the timer has started.

[0126] During the timing process, the Power Saving App detects whether the state of the AudioMIX lock and / or AudioIN lock changes, including: the Power Saving App detects changes in the state of the upper-level lock based on whether there are event reports. The following scenarios may occur during the timing process:

[0127] Scenario 1: During timing, the Power Saving App receives a lock-holding event from the PMS, indicating that an application holds an AudioMIX lock or AudioIN lock. In this scenario, the Power Saving App updates the status of the AudioMIX lock and / or AudioIN lock, for example, by adding the names of the AudioMIX lock and / or AudioIN lock to the mapping table. Once the Power Saving App determines that an application holds an AudioMIX lock and / or AudioIN lock and that timing has started, it exits the timing process. Specifically, the Power Saving App can determine that timing has started if the preset timing flag is set to "1" or the timing duration is not 0. If there is audio input or output during timing, the Power Saving App exits the timing process. For example, when exiting the timing process, the Power Saving App can set the preset timing flag to "0" to indicate that timing has ended.

[0128] In one example, during the timer function of the Power Saving App, a user answers a call using a digital headset. In this case, the call app requests the Power Management System (PMS) to hold the AudioMIX lock and the AudioIN lock. After the call app successfully requests the AudioMIX lock and the AudioIN lock, the PMS sends a lock holding event to the Power Saving App, instructing the call app to hold the AudioMIX lock and the AudioIN lock. Optionally, the call app's requests for the AudioMIX lock and the AudioIN lock can be performed separately, or the call app can request the AudioMIX lock and the AudioIN lock simultaneously; this embodiment does not limit this. After the user ends the call, the call app can request the PMS to release the AudioMIX lock and the AudioIN lock. After the call app successfully releases the AudioMIX lock and the AudioIN lock, the PMS sends a release event to the Power Saving App, instructing the call app to release the AudioMIX lock and the AudioIN lock. Optionally, the call app may request to release the AudioMIX lock and the AudioIN lock separately, or the call app may request to release the AudioMIX lock and the AudioIN lock simultaneously. This embodiment of the application does not limit this.

[0129] In one example, while the Power Saver app is timing the process, a user opens a music app and listens to music through digital headphones. In this case, the music app requests the AudioMIX lock from the Power Management System (PMS). After the music app successfully requests the AudioMIX lock, the PMS sends a lock-holding event to the Power Saver app, instructing the music app to hold the AudioMIX lock. After the user stops playing music, the music app can request the PMS to release the AudioMIX lock.

[0130] In one example, while the Power Saver app is timing the recording, the user opens a recording app and records through digital headphones. In this case, the recording app requests the AudioIN lock from the Power Management System (PMS). After the recording app successfully requests the AudioIN lock, the PMS sends a lock-holding event to the Power Saver app, instructing the recording app to hold the AudioIN lock. After the user stops recording, the recording app can request the PMS to release the AudioIN lock.

[0131] Scenario 2: During the timing process, the Power Saver app does not receive a lock event from the PMS indicating that an application is holding an AudioMIX lock or AudioIN lock, meaning there is no audio input or output during the timing process. In this scenario, the Power Saver app continues to check whether other sleep conditions are met.

[0132] Other sleep conditions include: no application in the upper layer holds a wakelock, and the kernel layer does not hold any wakelocks other than the USB lock.

[0133] Optionally, the Power Saver app can view the lock holding information of applications recorded in the mapping table. When the size of the mapping table is 0, it can be determined that no application in the upper layer holds a wakelock. Similarly, the Power Saver app can view the recorded lock holding information of the kernel layer to determine whether the kernel layer holds any kernel locks other than USB locks.

[0134] S603, at the second time point, the terminal device releases the USB lock and enters sleep mode.

[0135] Based on the description of Scenario 2 in S602, if the terminal device does not receive a lock-holding event from the PMS during the timing process, indicating that an application is holding an AudioMIX lock or AudioIN lock, that is, if the duration of no audio input or output reaches the preset duration during the timing process after the screen is turned off, the terminal device can release the USB lock at a second time point to allow the CPU to enter a sleep state. Optionally, in addition to satisfying the condition that the duration of no audio input or output reaches the preset duration, the terminal device must also satisfy the condition that it is not holding any other wakelock lock besides the USB lock. When the duration of no audio input or output reaches the preset duration and the terminal device is not holding any other wakelock lock besides the USB lock, the terminal device can release the USB lock and enter a sleep state to save power consumption.

[0136] The second time point is the time point after a preset duration starting from the first time point. It can also be understood as the preset duration being the time between the first and second time points.

[0137] The terminal device releases the USB lock and enters a sleep state, which may include: the terminal device sending an instruction to release the SUB lock to the kernel layer via the Power Saver APP, and the kernel layer receiving the instruction to release the USB lock accordingly. The kernel layer then releases the USB lock and enters a sleep state.

[0138] Optionally, the kernel layer releases the USB lock, including removing the USB lock name from the linked list to release the SUB lock. After entering hibernation, the terminal device's CPU automatically enters a power-saving mode, reducing or shutting down some voltage outputs, and all software stops running, thus saving power and reducing energy consumption.

[0139] Based on the technical solution of this application embodiment, when the terminal device is connected to a digital headset in the screen-on state, and then in the scenario where the terminal device is off, if the terminal device has no audio input or output within a preset time, the terminal device can actively release the USB lock. This helps to save the terminal device's power consumption and improve the user experience.

[0140] In method 600, the terminal device inserts a digital headset when the screen is on. In another scenario, the terminal device inserts a digital headset when the screen is off. When the screen is off, the terminal device is in a "standby state." After the digital headset is inserted, the terminal device detects the insertion and transitions from the "standby state" to the working state, beginning to execute actions such as... Figure 7 The device detection process shown is not repeated here. After detecting a device insertion, the terminal device checks the current screen state. Based on the description in S602 that the screen driver can update the screen state node to "screen off" after the terminal device's screen is off, the terminal device can view the screen state node through the Power Saving Assistant APP. When the screen state node is "screen off," the terminal device checks if the value of the preset flag bit is true. If the value of the preset flag bit is true, the terminal device is triggered to detect whether there is audio input or output. The subsequent steps performed by the terminal device can be referred to the descriptions in S602 and S603, and will not be repeated here.

[0141] Optionally, based on scenario two described in S602, the embodiments of this application may add the following optional judgment conditions to determine whether the terminal device executes S603.

[0142] Judgment condition 1: Does the user have a habit of using voice assistants?

[0143] With the addition of condition one, if the terminal device has no audio input or output for a preset duration and is not holding any wakelock other than the USB lock, it can further detect whether the user has a habit of using a voice assistant. If it is determined that the user does not have a habit of using a voice assistant, the terminal device can instruct the kernel layer to release the USB lock through the Power Saving Assistant APP; otherwise, the terminal device will not release the USB lock.

[0144] Typically, users may be accustomed to using the voice assistant function of their mobile devices to wake up the device and perform certain functions. Taking a mobile phone as an example, when the phone is in a screen-off state, users can use the phone's voice assistant to wake up the phone to play music, make calls, etc. The phone can learn the user's usage habits based on the user's historical usage records, such as whether the voice assistant function is used and common headphone usage.

[0145] If a user habitually uses a voice assistant, there's a possibility that they might wake up the device with a digital headset while it's plugged in, the screen is off, and there's no audio input or output for a preset period. Therefore, if the user is accustomed to using a voice assistant, the device won't release the USB lock. Instead, it will visually remind the user that the digital headset has been without audio input or output for a period, affecting the phone's normal standby time. After seeing the reminder, the user can decide whether to unplug the digital headset. Once the user unplugs the headset, the kernel layer can release the USB lock.

[0146] Judgment condition two: Whether the terminal device is in sleep mode and in an absolutely still state.

[0147] With the addition of condition two, if the terminal device has no audio input or output for a preset duration and does not hold any wakelocks other than the USB lock, it can further detect whether the terminal device is in sleep mode and in a completely still state. If it is determined that the terminal device is in sleep mode and in a completely still state, the terminal device can instruct the kernel layer to release the USB lock through the Power Saving Assistant APP; otherwise, the terminal device will not release the USB lock.

[0148] Taking a mobile phone as an example, in one possible scenario, a user listens to music on their phone using digital headphones before going to sleep. After the music finishes playing, the user may have already fallen asleep, but the headphones are still plugged into the phone. In this scenario, if the phone is detected to be in sleep mode and completely still, it can release the USB lock to put the phone into hibernation mode. If the phone is not in sleep mode and / or not completely still, there might be a situation where the user suddenly needs to use the digital headphones, so the phone may choose not to release the USB lock.

[0149] For example, the terminal device can use a light sensor to detect whether it is currently nighttime and the lights are off, or use ambient noise to detect whether it is currently quiet, to determine whether to enable sleep mode; or, the terminal device can learn the time when the user turns off the screen to determine whether to enable sleep mode.

[0150] For example, the terminal device can detect whether it is in an absolutely stationary state based on the gyroscope accelerometer sensor.

[0151] The aforementioned judgment conditions one and two can be implemented individually or in combination if the terminal device experiences a preset duration of no audio input or output and is not holding any wakelock other than the USB lock. For example, if the terminal device meets the following conditions: the preset duration of no audio input or output, no wakelock other than the USB lock, the user does not use a voice assistant, and the terminal device is in sleep mode and completely still, the USB lock can be released to put the terminal device into sleep mode. Conversely, if the preset duration of no audio input or output, no wakelock other than the USB lock, and the user does not use a voice assistant, but the terminal device is not in sleep mode and / or is completely still, the USB lock will not be released.

[0152] Optionally, the terminal device can also add a third condition: whether the terminal device is in its usual location.

[0153] After determining that there has been no audio input or output for a preset duration after the screen is turned off, the terminal device can further determine whether to release the USB lock and enter a hibernation state by combining at least one of the above optional judgment conditions one, two, or three.

[0154] Figure 8 This is a flowchart illustrating a process for releasing a USB lock, provided in an embodiment of this application. It demonstrates how a terminal device, after the screen is off, determines whether to release the USB lock based on three conditions: condition one, condition two, and condition three. Figure 8 As shown, with the addition of condition three, the terminal device can release the USB lock and enter sleep mode if it meets any of the following conditions: the duration of no audio input or output reaches a preset duration; no wakelock other than the USB lock is held; the user does not use a voice assistant; the terminal device is in sleep mode and completely still; and the terminal device is in its usual location. Conversely, if the terminal device does not meet any of the following conditions, it will not release the USB lock and will not enter sleep mode.

[0155] Typically, users will fall asleep at relatively fixed times according to their own habits at their usual location. Therefore, when the terminal device is in sleep mode and in a completely still state, the terminal device can further determine the user's current location based on geofencing. When the terminal device is at its usual location, the terminal device can release the USB lock.

[0156] In method 600 described above, the terminal device inserts a digital headset and turns off the screen at a first time point. For a preset duration after the first time point, the terminal device remains in a screen-off state with no audio input or output. Then, without holding any wakelock other than the USB lock, the terminal device can release the USB lock at a second time point, allowing the CPU to enter a sleep state. After the CPU enters a sleep state, the terminal device remains in a screen-off state.

[0157] Optionally, after the second time point, method 600 further includes steps S604 to S608, with the following specific steps:

[0158] S604, the terminal device screen lights up.

[0159] S605, the terminal device disconnects from the digital headset.

[0160] For example, the terminal device can disconnect from the digital headset in response to the user unplugging the digital headset.

[0161] S606 allows terminal devices to connect to other USB devices (other USB devices are not digital headsets) via a USB Type-C interface.

[0162] After the terminal device connects to the other USB device, it will hold a USB lock.

[0163] S607: At the third time point, the terminal device screen turns off. For a preset duration after the third time point, the terminal device remains in the screen-off state and there is no audio input or output.

[0164] S608: Starting from the third time point, after a preset duration, the terminal device will not enter a sleep state.

[0165] In the scenarios described in S404 to S607, the user may insert a USB device other than a digital headset into the terminal device. The terminal device can determine the device type of the inserted USB device through the device descriptor, such as a USB mouse, USB keyboard, USB camera, USB flash drive, etc. After inserting the other USB device besides the digital headset, the kernel layer of the terminal device holds a USB lock. Since the inserted USB device is not a digital headset, the terminal device does not execute the judgment logic of whether to release the USB lock in this embodiment when the screen is off, and holds the USB lock indefinitely. Therefore, the terminal device does not enter a sleep state after the third time point.

[0166] Combination Figure 6 , Figure 9 This is a schematic flowchart of another hibernation state management method 900 provided in the embodiments of this application. Figure 9 This illustrates the process by which a terminal device cannot enter sleep mode after a digital headset is plugged in.

[0167] Method 900 can be executed after the second time point or the third time point described in method 600. Method 900 includes steps S901 to S903, and the specific steps are as follows:

[0168] S901, the terminal device screen is on, USB lock is engaged, and there is no audio input or output.

[0169] As described in S603, the terminal device releases the USB lock at the second time point, and then remains in a sleep state. When the terminal device responds to a user's screen activation, it can regain control of the USB lock.

[0170] Based on the description in S607, at the third time point, the terminal device turns off the screen and holds the USB lock. After the third time point, when the terminal device turns on the screen in response to a user operation, the terminal device can unplug the other USB device and replug the digital headset. After replugging, the terminal device holds the USB lock.

[0171] S902, at the fourth time point, the terminal device screen turns off.

[0172] After the terminal device's screen is turned off, it can determine whether there is audio input or output based on whether an application holds an AudioMIX lock or AudioIN lock. If there is no audio input or output, it starts a timer to determine whether the duration of no audio input or output reaches a preset duration. During the timer, the terminal device must remain in a screen-off state. For a detailed description, please refer to the description of S602 above, which will not be repeated here.

[0173] In the S903, at the fifth time point, the terminal device's screen turned on. The duration between the fourth and fifth time points was less than the preset duration, meaning that the terminal device did not remain in a continuously off state during the timing process, but rather turned on the screen during the timing. The terminal device did not release the USB lock or enter sleep mode between the fourth and fifth time points.

[0174] In this embodiment, the terminal device does not meet the condition of keeping the screen off during the timing process. Therefore, the terminal device will exit the timing, continue to hold the USB lock, and not enter the sleep state.

[0175] Combination Figure 6 or Figure 9 , Figure 10 This is a schematic flowchart of another hibernation state management method 1000 provided in the embodiments of this application. Figure 10 This illustrates the process where the terminal device plays music after plugging in digital headphones, and releases the USB lock to enter sleep mode after the music playback ends.

[0176] Method 1000 can be executed after the second or third time point described in method 600, or after the fifth time point described in method 900. Method 1000 includes steps S1001 to S1006, and the specific steps are as follows:

[0177] S1001, the terminal device screen is on.

[0178] S1002, in response to the insertion of digital headphones, the terminal device connects the digital headphones, holds the USB lock, and plays music.

[0179] S1003, at the sixth time point, the terminal device screen turns off.

[0180] S1004, at the seventh time point, the music playback on the terminal device ends, and there is no audio input or output.

[0181] Between the sixth and seventh time points, the terminal device holds the USB lock and does not enter sleep mode. The duration between the sixth and seventh time points is greater than or equal to a preset duration, meaning that the terminal device determines there is audio input or output after the screen is turned off, therefore the terminal device does not release the USB lock and does not enter sleep mode.

[0182] S1005, after the seventh time point, the duration of no audio input or output by the terminal device reaches the preset duration.

[0183] After the seventh time point, the terminal device begins timing if there is no audio input or output, to determine whether the duration of no audio input or output has reached the preset duration. During the timing process, the terminal device must remain in a screen-off state. For a detailed description, please refer to the description of S602 above; it will not be repeated here.

[0184] S1006, at the eighth time point, the terminal device releases the USB lock and enters sleep mode.

[0185] In this embodiment, after the terminal device inserts digital headphones, it plays music through the headphones, resulting in audio output. Therefore, after the terminal device screen is turned off, it continues to hold the USB lock while audio output is present, without entering a sleep state. When the music finishes playing, and there is no audio input or output, the terminal device begins to execute the judgment logic of this application. If the duration of no audio input or output reaches a preset duration and the terminal device does not hold any wakelock other than the USB lock, the terminal device releases the USB lock and enters a sleep state, which helps reduce the power consumption of the terminal device.

[0186] This application provides a terminal device, which includes a processor and a memory; the memory stores computer execution instructions; the processor executes the computer execution instructions stored in the memory, causing the terminal device to perform the above-described method.

[0187] This application provides a chip. The chip includes a processor, which is used to call a computer program in memory to execute the technical solutions in the above embodiments. Its implementation principle and technical effects are similar to those in the related embodiments described above, and will not be repeated here.

[0188] This application also provides a computer-readable storage medium. The computer-readable storage medium stores a computer program. When the computer program is executed by a processor, it implements the methods described above. The methods described in the above embodiments can be implemented wholly or partially by software, hardware, firmware, or any combination thereof. If implemented in software, the functionality can be stored as one or more instructions or code on or transmitted over the computer-readable medium. The computer-readable medium can include computer storage media and communication media, and can also include any medium that can transfer a computer program from one place to another. The storage medium can be any target medium accessible by a computer.

[0189] In one possible implementation, a computer-readable medium may include random access memory (RAM), read-only memory (ROM), compact disc read-only memory (CD-ROM) or other optical disc storage, magnetic disk storage or other magnetic storage devices, or any other medium targeted to carry or to store the required program code in the form of instructions or data structures, and accessible by a computer. Furthermore, any connection is appropriately referred to as a computer-readable medium. For example, if software is transmitted from a website, server, or other remote source using coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, then coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of medium. As used herein, disks and optical discs include optical discs, laser discs, optical discs, digital versatile discs (DVDs), floppy disks, and Blu-ray discs, where disks typically reproduce data magnetically, while optical discs optically reproduce data using lasers. Combinations of the above should also be included within the scope of computer-readable media.

[0190] This application provides a computer program product, which includes a computer program that, when run, causes a computer to perform the above-described method.

[0191] This application describes embodiments of methods, apparatus (systems), and computer program products according to embodiments of this application with reference to flowchart illustrations and / or block diagrams. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processing unit of a general-purpose computer, special-purpose computer, embedded processor, or other programmable device to produce a machine, such that the instructions, which execute via the processing unit of the computer or other programmable data processing device, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0192] The above specific embodiments further illustrate the purpose, technical solution and beneficial effects of this application. It should be understood that the above are only specific embodiments of this application and are not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made on the basis of the technical solution of this application should be included within the scope of protection of this application.

Claims

1. A method for managing a dormant state, characterized in that, The method, applied to a terminal device having a Universal Serial Bus (USB) Type-C interface, includes: The terminal device lights up its screen, and the terminal device connects to a digital headset through the USB Type-C interface. After determining that the digital headset is a digital headset by detecting the device descriptor of the digital headset, the terminal device sets the preset flag position to true and holds the kernel lock of the USB. The power-saving application of the terminal device registers a first listening event with the kernel layer. The first listening event is used to monitor the kernel lock status of the USB. The power-saving application registers a second listening event with the power manager (PMS). The second listening event is used to monitor the status of the upper-level locks, which include the AudioMIX lock for the audio output interface and the AudioIN lock for the audio input interface. At the first time point, the terminal device turns off the screen. For a preset duration after the first time point, the terminal device remains in the screen-off state, and the power-saving application determines, based on the recorded state of the upper-level lock, that the wake-up locks of the audio input interface and the audio output interface are both in the released state, and the preset flag bit is true. The power-saving application continues to detect whether other sleep conditions are met. These other sleep conditions include: no upper-layer application holding a wakelock, and the kernel layer holding no other wakelocks besides the USB lock. When the other sleep conditions are met, at a second time point, the terminal device releases the kernel lock of the USB and enters a sleep state. The duration between the first time point and the second time point is greater than or equal to the preset duration. The terminal device releasing the kernel lock of the USB also needs to meet at least one of the following conditions: the user does not have the habit of using a voice assistant, the terminal device is in sleep mode and the terminal device is in an absolutely still state, or the terminal device is in a permanent location. After the second time point, the terminal device screen turns on; The terminal device disconnects from the digital headset; The terminal device connects to other USB devices via the USB Type-C interface, and the other USB devices are not digital headphones; At the third time point, the terminal device turns off its screen, and for a preset duration after the third time point, the terminal device remains in a screen-off state with no audio input or output. Starting from the third time point, after the preset duration, the terminal device will not enter a sleep state.

2. The method according to claim 1, characterized in that, The terminal device releases the kernel lock of the USB, including: After the terminal device screen is turned off, the terminal device determines that there is no audio input or output and starts timing; The terminal device determines that the duration of no audio input or output reaches the preset duration and then releases the kernel lock of the USB.

3. The method according to claim 1, characterized in that, After the third time point, the method further includes: The terminal device has its screen lit up, holds a USB kernel lock, and has no audio input or output. At the fourth time point, the terminal device screen is turned off; At the fifth time point, the terminal device turns on its screen. The duration between the fourth and fifth time points is less than the preset duration. Between the fourth and fifth time points, the terminal device does not enter a sleep state.

4. The method according to claim 1, characterized in that, After the third time point, the method further includes: The terminal device screen is turned on; The terminal device connects to the digital headset via the USB Type-C interface and holds the USB kernel lock; The terminal device plays audio through the digital headphones; At the sixth time point, the terminal device screen is turned off; At the seventh time point, the music playback on the terminal device ends, and for the preset duration following the seventh time point, the terminal device remains in a screen-off state with no audio input or output. At the eighth time point, the terminal device releases the kernel lock of the USB and enters a hibernation state. The duration between the seventh time point and the eighth time point is greater than or equal to the preset duration.

5. The method according to claim 4, characterized in that, After the sixth time point and before the seventh time point, the method further includes: The terminal device determines that there is audio input or output, and does not release the kernel lock of the USB.

6. A method for managing a dormant state, characterized in that, The method, applied to a terminal device having a Universal Serial Bus (USB) Type-C interface, includes: The terminal device lights up its screen, and the terminal device connects to a digital headset through the USB Type-C interface. After determining that the digital headset is a digital headset by detecting the device descriptor of the digital headset, the preset mark position is set to true, and the kernel lock of the USB is held. The power-saving application of the terminal device registers a first listening event with the kernel layer. The first listening event is used to monitor the kernel lock status of the USB. The power-saving application registers a second listening event with the power manager (PMS). This second listening event is used to monitor the status of the upper-level locks, which include the AudioMIX lock for the audio output interface and the AudioIN lock for the audio input interface. When an application requests to hold or release a lock from the PMS, the PMS returns a corresponding event to the power-saving application to indicate the lock's status change. The power-saving application records the status of the upper-level locks, recording the lock's name when a lock-holding event is reported and deleting the lock's name when a release event is reported. The terminal device screen is off; The timing begins when the terminal device has no audio input or output. After the preset time has elapsed, the terminal device releases the kernel lock of the USB and enters a sleep state. Releasing the kernel lock of the USB also requires at least one of the following conditions to be met: the user does not have a habit of using a voice assistant, the terminal device is in sleep mode and the terminal device is in an absolutely still state, the terminal device is in a permanent location, and during the timekeeping process, the terminal device determines that there is no audio input or output by detecting the wake-up lock status of the audio input interface and the audio output interface.

7. The method according to claim 6, characterized in that, The method further includes: If the terminal device has audio input or output during the timing process, the terminal device will exit the timing and reset the timing duration to zero.

8. A terminal device, characterized in that, include: Processor and memory, of which, The memory is used to store computer programs; The processor is used to invoke and execute the computer program to cause the terminal device to perform the method as described in any one of claims 1 to 7.

9. A computer-readable storage medium, characterized in that, Used to store computer programs that, when run on a computer, cause the computer to perform the method as described in any one of claims 1 to 7.

10. A computer program product, characterized in that, Includes a computer program that, when run, causes a computer to perform the method as described in any one of claims 1 to 7.

Images