Method for managing wake lock, electronic device, storage medium and chip system

Abstract

Embodiments of the present application provide a method for managing a wake lock, an electronic device, a storage medium and a chip system, and relate to the technical field of terminals. The method comprises: obtaining lock holding information of a first process, the lock holding information being used to indicate a case in which the first process holds a wake lock; and in a case where the lock holding information satisfies a preset condition, the first process does not hold the wake lock. In this way, the number of times of holding a lock by a process in a period of time can be limited, the case that an electronic device cannot enter a sleep state due to frequent holding of a lock by an application can be reduced, and the endurance time of the electronic device can be prolonged.

Description

Technical Field

[0001] This application relates to the field of terminal technology, and in particular to a method for managing wake-up locks, electronic devices, storage media, and chip systems. Background Technology

[0002] Mobile phones, computers, and other electronic devices can enter sleep mode to save power. However, applications can acquire a wakelock to prevent these devices from entering sleep mode. This allows the device to continue playing music, downloading files, and performing other operations. Once all operations are complete, the application can release the wakelock, allowing the device to enter sleep mode.

[0003] However, when applications are running on electronic devices, some applications may frequently request wake-up locks, preventing the electronic devices from entering sleep mode and resulting in high power consumption. Summary of the Invention

[0004] This application provides a wake-up lock management method, electronic device, storage medium, and chip system, applicable to the field of terminal technology. It helps save power.

[0005] In a first aspect, embodiments of this application propose a method for managing a wake-up lock, the method comprising: obtaining lock holding information of a first process, the lock holding information being used to indicate the status of the first process holding a wake-up lock; and, if the lock holding information meets preset conditions, the first process does not hold a wake-up lock.

[0006] In this way, electronic devices can record the wake-up lock status of each process. When a process requests a lock, the device can determine whether to allow the lock based on the process's lock holding status.

[0007] In one possible implementation, the preset conditions include: the number of times the first process requests a wake-up lock within a preset time period is greater than or equal to a first preset threshold; if the lock holding information meets the preset conditions, the first process does not hold a wake-up lock, including: if the number of times the first process requests a wake-up lock within a preset time period is greater than or equal to the first preset threshold, the wake-up lock of the first process is not created.

[0008] The first preset threshold may correspond to the preset number of times, the number of times threshold, etc. mentioned below, but no specific limitation is made here.

[0009] This limits the number of times a process holds a lock within a certain period, reducing the likelihood of electronic devices being unable to enter sleep mode due to frequent lock holding by applications, and extending the battery life of electronic devices.

[0010] In one possible implementation, the preset conditions include: the number of times the first process requests a wake-up lock within the current time period is greater than or equal to a second preset threshold; if the lock holding information meets the preset conditions, the first process does not hold a wake-up lock, including: if the number of times the first process requests a wake-up lock within the current time period is greater than or equal to the second preset threshold, a wake-up lock for the first process is not created.

[0011] The second preset threshold may correspond to the preset number of times, the number of times threshold, etc. mentioned below, and is not specifically limited here.

[0012] This limits the number of times a process holds a lock within a certain period, reducing the likelihood of electronic devices being unable to enter sleep mode due to frequent lock holding by applications, and extending the battery life of electronic devices.

[0013] In one possible implementation, the method further includes: if the number of times the first process requests a wake-up lock in N consecutive time periods is greater than or equal to a second preset threshold, then no wake-up lock is created for the first process within the first time period; N is a positive integer.

[0014] The first duration can be 1 day, 1 week, or any other duration; there are no specific limitations here. The first duration can be longer than the duration corresponding to the time period.

[0015] In this way, if there are frequent applications over a long period of time, the application will be banned for an extended period, thus improving the user experience.

[0016] In one possible implementation, the wake-up lock for the first process is not created, including: not writing the lock name of the wake-up lock that the first process needs to create into the corresponding file node.

[0017] In this way, when creating a wake_source node in the kernel layer, the identifier of the process to which the wake_source node belongs is not written into the wake_source node, reducing the association between the wakelock created by the process and the process identifier.

[0018] In one possible implementation, the first process is the application process, the native process, or the kernel process.

[0019] Secondly, embodiments of this application provide a wake-up lock management device, which can be an electronic device, or a chip or chip system within an electronic device. The wake-up lock management device may include a display unit and a processing unit. When the wake-up lock management device is an electronic device, the display unit may be a display screen. The display unit is used to perform display steps to enable the electronic device to implement a wake-up lock management method described in the first aspect or any possible implementation of the first aspect. When the wake-up lock management device is an electronic device, the processing unit may be a processor. The wake-up lock management device may further include a storage unit, which may be a memory. The storage unit is used to store instructions, and the processing unit executes the instructions stored in the storage unit to enable the electronic device to implement a wake-up lock management method described in the first aspect or any possible implementation of the first aspect. When the wake-up lock management device is a chip or chip system within an electronic device, the processing unit may be a processor. The processing unit executes the instructions stored in the storage unit to enable the electronic device to implement a wake-up lock management method described in the first aspect or any possible implementation of the first aspect. The storage unit can be a storage unit inside the chip (e.g., a register, cache, etc.) or a storage unit located outside the chip within the electronic device (e.g., a read-only memory, random access memory, etc.).

[0020] An example is a display unit used to display an interface.

[0021] The processing unit is used to obtain the lock holding information of the first process, which indicates whether the first process holds the wake-up lock; if the lock holding information meets the preset conditions, the first process does not hold the wake-up lock.

[0022] In one possible implementation, the preset conditions include: the number of times the first process requests a wake-up lock within a preset time period is greater than or equal to a first preset threshold; the processing unit is specifically used to not create a wake-up lock for the first process when the number of times the first process requests a wake-up lock within a preset time period is greater than or equal to the first preset threshold.

[0023] In one possible implementation, the preset conditions include: the number of times the first process requests a wake-up lock within the current time period is greater than or equal to a second preset threshold; the processing unit is specifically used to not create a wake-up lock for the first process when the number of times the first process requests a wake-up lock within the current time period is greater than or equal to the second preset threshold.

[0024] In one possible implementation, the processing unit is further configured to not create a wake-up lock for the first process during a first duration if the number of times the first process requests a wake-up lock in N consecutive time periods is greater than or equal to a second preset threshold; where N is a positive integer.

[0025] In one possible implementation, the processing unit is specifically configured not to write the lock name of the wake-up lock that the first process needs to create to the corresponding file node.

[0026] In one possible implementation, the first process is the application process, the native process, or the kernel process.

[0027] Thirdly, embodiments of this application provide an electronic device including a processor and a memory, the memory for storing code instructions, and the processor for running the code instructions to perform the methods described in the first aspect or any possible implementation of the first aspect.

[0028] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program or instructions that, when executed on a computer, cause the computer to perform the methods described in the first aspect or any possible implementation thereof.

[0029] Fifthly, embodiments of this application provide a computer program product including a computer program, which, when run on a computer, causes the computer to perform the methods described in the first aspect or any possible implementation thereof.

[0030] Sixthly, this application provides a chip or chip system including at least one processor and a communication interface. The communication interface and the at least one processor are interconnected via a circuit. The at least one processor is used to run computer programs or instructions to perform the methods described in the first aspect or any possible implementation of the first aspect. The communication interface in the chip can be an input / output interface, pins, or circuits, etc.

[0031] In one possible implementation, the chip or chip system described above in this application further includes at least one memory storing instructions. The memory can be an internal storage unit of the chip, such as a register or cache, or it can be a storage unit of the chip itself (e.g., read-only memory, random access memory, etc.).

[0032] It should be understood that the second to sixth aspects of this application correspond to the technical solutions of the first aspect 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

[0033] Figure 1 A flowchart illustrating a possible management method for a wake-up lock;

[0034] Figure 2A flowchart illustrating a possible method for managing a wake-up lock in a design;

[0035] Figure 3 This is a schematic diagram illustrating a scenario where a process frequently requests a wake-up lock, as provided in an embodiment of this application.

[0036] Figure 4 A schematic diagram of the hardware structure of an electronic device provided in an embodiment of this application;

[0037] Figure 5 A schematic diagram of the software structure of an electronic device provided in an embodiment of this application;

[0038] Figure 6 A flowchart illustrating a wake-up lock management method provided in an embodiment of this application;

[0039] Figure 7 A flowchart illustrating a wake-up lock management method provided in an embodiment of this application;

[0040] Figure 8 A flowchart illustrating a wake-up lock management method provided in an embodiment of this application;

[0041] Figure 9 This is a flowchart illustrating a wake-up lock management method provided in an embodiment of this application. Detailed Implementation

[0042] To facilitate a clear description of the technical solutions in the embodiments of this application, some terms and technologies involved in the embodiments of this application will be briefly introduced below:

[0043] 1. Dormancy

[0044] Hibernation can be understood as a state in which an electronic device remains powered on while reducing power consumption. In hibernation mode, certain functions or components of the electronic device may be partially or completely shut down to reduce energy consumption. Specifically, hibernation may include, but is not limited to, the processor entering a low-frequency operating mode, the display being turned off or dimmed, and wireless communication modules being turned off or entering standby mode.

[0045] In some embodiments, during hibernation, the electronic device saves the process context within the process and can supply power only to the memory, while other components in the electronic device are powered down. The electronic device requires power during hibernation; if the power is disconnected or depleted, the electronic device will lose the data in its memory, and even if power is restored, the electronic device cannot return to its previous operating state.

[0046] 2. Wake up

[0047] Wake-up can be understood as the process by which an electronic device returns to an active state from sleep mode. After wake-up, the electronic device's processor, display screen, communication modules, and other components return to normal operation, allowing the user to fully operate the device.

[0048] In some embodiments, during the wake-up process, the electronic device can restore power to the device and load the process context stored in memory, so that the electronic device can return to its state before hibernation after waking up.

[0049] Understandably, when an electronic device detects that a user has clicked the sleep button or that no user interaction has been detected within the set sleep time, the device can turn off the screen, instruct the system to enter sleep mode, and save the process context. When the electronic device detects a wake-up event, it can turn on the screen, wake up the system, and load the process context.

[0050] When an electronic device is in sleep mode, it can be woken up through various triggering mechanisms. These include user input (such as button or touchscreen operations), timer events, environmental changes detected by sensors, or received external signals. The sleep mode duration can be understood as the time from when the user is inactive until the electronic device enters sleep mode. Achieving wake-up typically requires the device to quickly return to an operational state to improve user experience and device responsiveness.

[0051] When a process is executing, the values ​​in all the CPU's registers, the process state, and the contents of the stack can be referred to as the process context.

[0052] 3. Wakelock

[0053] A wakelock can be understood as a lock that prevents electronic devices from going to sleep. It's understandable that the wakelock mechanism is a native mechanism of the Linux kernel; all wakelocks ultimately reside within the Linux kernel.

[0054] Specifically, adding a lock marker at the kernel's wakelock management node is called holding the lock. Deleting the lock marker at the kernel's wakelock management node is called releasing the lock. Wakelocks can include: partial wake locks, native wake locks, and kernel wakelocks.

[0055] 4. Partial wake lock

[0056] A partial lock can be understood as a wake-up lock added by an application process at the kernel's wakelock management node. The application process can refer to the process created by the application. In this embodiment, the partial wake-up lock can be simply referred to as a partial lock.

[0057] 5. Native wake lock

[0058] A native wake-up lock can be understood as a wake-up lock added by a native process at the kernel's wakelock management node. In this embodiment, the native wake-up lock can be simply referred to as a native lock.

[0059] Native processes are processes created at the native layer of an electronic device to provide local services or system library functions. Native processes are usually resident, meaning they are created when the system starts up, and can provide the corresponding services when an application needs to implement a certain function.

[0060] 6. Kernel wake lock

[0061] A kernel wake-up lock can be understood as a wake-up lock directly added at the wakelock management node of a kernel process. In this embodiment, the kernel wake-up lock can be simply referred to as a kernel lock.

[0062] Processes created in kernel mode are called kernel processes, such as kernel driver processes. Kernel processes are usually resident, meaning they are created when the system starts up, and can provide the corresponding services when an application needs to implement the corresponding function.

[0063] Understandably, application processes typically do not directly request kernel wake locks. However, application processes may indirectly trigger kernel wake locks. For example, an application process might call a process at the kernel level (a kernel process), which might then request a kernel wake lock.

[0064] 7. Other terms

[0065] In the embodiments of this application, terms such as "first" and "second" are used to distinguish identical or similar items with essentially the same function and purpose. For example, "first chip" and "second chip" are used only to distinguish different chips and do not limit their order. Those skilled in the art will understand that terms such as "first" and "second" do not limit the quantity or execution order, and that "first" and "second" do not necessarily imply that they are different. The embodiments of this application use "equal to" to implement one judgment situation as an example for explanation; the equal to situation can also correspond to another judgment situation. No specific limitations are made here.

[0066] In this application, the terms "exemplary" or "for example" are used to indicate that something is an example, illustration, or description. Any embodiment or design described as "exemplary" 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 terms such as "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0067] 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: 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, or c can represent: a, b, c, ab, a--c, bc, or abc, where a, b, and c can be single or multiple. This application embodiment uses equality to illustrate one judgment situation; equality can also correspond to another judgment situation. No specific limitations are made here.

[0068] 8. Electronic equipment

[0069] The electronic devices in this application embodiment may include handheld devices with sleep function, vehicle-mounted devices, etc. For example, some electronic devices include: mobile phones, tablets, PDAs, laptops, mobile internet devices (MIDs), wearable devices (e.g., smartwatches, smart glasses, smart bracelets, or smart jewelry), virtual reality (VR) devices, augmented reality (AR) devices, wireless terminals in industrial control, wireless terminals in self-driving, wireless terminals in remote medical surgery, wireless terminals in smart grids, wireless terminals in transportation safety, wireless terminals in smart cities, wireless terminals in smart homes, cellular phones, cordless phones, session initiation protocol (SIP) phones, wireless local loop (WLL) stations, personal digital assistants (PDAs), handheld devices with wireless communication capabilities, computing devices or other processing devices connected to a wireless modem, in-vehicle devices, and the Internet of Things (IoT). Terminal devices in IoT systems, terminal devices in 5G networks, or terminal devices in future public land mobile networks (PLMNs) are not limited to this category in the embodiments of this application.

[0070] The electronic devices in the embodiments of this application may also be referred to as: terminal equipment, user equipment (UE), mobile station (MS), mobile terminal (MT), access terminal, user unit, user station, mobile station, mobile station, remote station, remote terminal, mobile device, user terminal, terminal, wireless communication equipment, user agent, or user device, etc.

[0071] In this embodiment, the electronic device or various network devices include a hardware layer, an operating system layer running on top of the hardware layer, and an application layer running on top of the operating system layer. The hardware layer includes hardware such as a central processing unit (CPU), a memory management unit (MMU), and memory (also called main memory). The operating system can be any one or more computer operating systems that implement business processing through processes, such as Linux, Unix, Android, iOS, or Windows. The application layer includes applications such as browsers, address books, word processing software, and instant messaging software.

[0072] A wakelock is a software control mechanism in electronic devices used to control the sleep state of these devices. When an application in an electronic device holds a wakelock, the device cannot enter a sleep state. Therefore, in scenarios where certain business operations are performed, applications can create wakelocks to prevent the electronic device from going to sleep.

[0073] Understandably, applications typically consist of multiple processes to implement different business functionalities. The wake-up locks created by each process of an application can be considered wake-up locks for that application. Therefore, an application can hold one or more wake-up locks.

[0074] Taking a music application as an example, a music application can include: a user interface (UI) thread, an audio playback thread, a download thread, and background service threads. The UI thread is responsible for handling user interface updates and user interaction events. UI-related operations (such as button clicks and interface refreshes) are executed in the UI thread. The audio playback thread handles audio playback tasks, including decoding audio files, managing audio output devices (such as speakers or headphones), and handling playback controls (such as play, pause, and stop). The download thread is responsible for downloading audio files or other resources from a web server. Background service threads execute tasks that need to run continuously in the background, such as music playback services, media session management, and notification updates.

[0075] In a music playback scenario, the audio playback thread in the music application can request a wake-up lock from the electronic device to prevent the device from going to sleep during audio playback. Similarly, during audio file download, the download thread in the music application can request a wake-up lock from the electronic device to prevent the device from going to sleep during the download process. Once the audio file download is complete, the download thread can release the wake-up lock it created.

[0076] However, due to various reasons such as abnormal infinite loops in the application process or non-standard application practices, abnormal locking may occur, and the electronic device will not enter sleep mode, resulting in high power consumption.

[0077] In one possible design, the electronic device can automatically release the wake-up lock created by the process if the process exits abnormally.

[0078] For example, Figure 1 This is a flowchart illustrating one possible method for managing a wake-up lock in a design. Figure 1 As shown, the method includes:

[0079] S101, Process creates wake-up lock.

[0080] S102. Monitor whether the process exits abnormally.

[0081] S103. When a process exits abnormally, release the wake-up lock corresponding to that process.

[0082] In this embodiment, the wake-up lock may include a partial lock, a native lock, and a kernel lock. The partial lock may be located at the application framework layer; the native lock may be located at the native layer; and the kernel lock may be located at the kernel layer.

[0083] Adaptively, when a process exits abnormally, the corresponding partial lock, the corresponding native lock, and the corresponding kernel lock for that process are released.

[0084] This reduces the likelihood of electronic devices not going to sleep due to abnormal process locking after process exit, thus extending the battery life of electronic devices.

[0085] In a possible design 2, the electronic device can determine whether the lock held by each process is an abnormal lock based on the holding time and lock type of the wake-up lock, and release the abnormal lock.

[0086] For example, Figure 2 This is a flowchart illustrating one possible method for managing a wake-up lock in a design. Figure 2 As shown, the method includes:

[0087] S201. Detect the wake-up lock that is in working state in the detection system.

[0088] When a process exits abnormally, release the wake-up lock corresponding to that process, such as a partial lock, a native lock, or a kernel lock.

[0089] S202. If the holding time and lock type of the wake-up lock meet the preset abnormal conditions, the wake-up lock is determined to be an abnormal lock and added to the preset abnormal lock list.

[0090] Abnormal conditions include: the holding time exceeds the holding threshold, and the lock type belongs to a preset specified lock type. The specified lock type is preset by those skilled in the art; for example, it can be set to partial lock, native lock, and kernel lock, etc.

[0091] For example, taking a holding threshold of 30 minutes as an example, if an electronic device holds a partial lock for more than 30 minutes, then the partial lock is an abnormal lock; if an electronic device holds a native lock for more than 30 minutes, then the native lock is an abnormal lock; if an electronic device holds a kernel lock for more than 30 minutes, then the kernel lock is an abnormal lock.

[0092] In some embodiments, the holding thresholds for different types of wake-up locks may be the same or different, and no specific limitation is made here.

[0093] This allows for anomaly detection of wake-up locks that are in operation within the system, enabling subsequent restrictions on the identified abnormal locks.

[0094] S203. If the abnormal lock list is not empty and meets the preset reporting conditions, then an abnormality is reported and cleared.

[0095] This can clear abnormal lock situations, reduce the number of times abnormal locks cause electronic devices to not go into sleep mode, and extend the battery life of electronic devices.

[0096] However, if a process frequently requests to release the wake-up lock, the electronic device may be unable to enter sleep mode.

[0097] It should be understood that various reasons, such as improper application implementation or virus intrusion, may cause processes to frequently request wake-up locks. This application does not specifically limit the reasons that may lead to frequent wake-up lock requests by processes.

[0098] For example, Figure 3 This is a schematic diagram illustrating a scenario where a process frequently requests a wake-up lock, as provided in an embodiment of this application. Taking process 1 as an example, ... Figure 3 As shown, process 1 may request a wake-up lock at time t0 and release the wake-up lock at time t1. Process 1 may request a wake-up lock at time t2 and release the wake-up lock at time t3. Process 1 may request a wake-up lock at time t4 and release the wake-up lock at time t5.

[0099] from Figure 3As can be seen, since the durations between t1 and t2, and between t3 and t4, are both relatively short, the electronic device will not enter sleep mode between t0 and t5. Because the process requests the wake-up lock three times, the electronic device cannot enter sleep mode for an extended period, resulting in high power consumption.

[0100] Understandably, when a process frequently requests and releases the wake-up lock, the process continues to exist without exiting, therefore, the first possible design approach cannot solve the problem of the electronic device not sleeping under this situation. Furthermore, due to the frequent requests and releases of the wake-up lock, the duration for which the process holds the wake-up lock is short, failing to meet the preset abnormal conditions. Therefore, the first and second possible design approaches cannot solve the problem of the electronic device not sleeping under this situation.

[0101] In view of this, embodiments of this application provide a wake-up lock management method, an electronic device, a storage medium, and a chip system. The electronic device can record the wake-up lock status of each process. When a process requests to hold the lock, it determines whether to allow the lock holding based on the process's lock holding status.

[0102] For example, the lock holding situation includes: if the number of times a process holds the lock is greater than or equal to the number of times it wakes up the lock in the past period, the process is not allowed to hold the lock; if the number of times the first process requests the lock to wake up the lock in the past period is less than the number of times it wakes up the lock, the next process is allowed to hold the lock.

[0103] This limits the number of times a process holds a lock within a certain period, reducing the likelihood of electronic devices being unable to enter sleep mode due to frequent lock holding by applications, and extending the battery life of electronic devices.

[0104] To better understand the embodiments of this application, the structure of the electronic device of the embodiments of this application is described below.

[0105] For example, Figure 4 This is a schematic diagram of the hardware structure of an electronic device provided in an embodiment of this application. Figure 4As shown, the electronic device may include: a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (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 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.

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

[0107] The processor 110 may include one or more processing units. These processing units may be independent devices or integrated within one or more processors. The processor 110 may also include a memory for storing instructions and data. For example, the memory may be used to store instructions and data related to the wake-up lock management method provided in this embodiment. The processor 110 may be used to invoke and execute the instructions and data of the wake-up lock management method stored in the memory to implement the wake-up lock management method of this embodiment.

[0108] In some embodiments, the memory may not be located in the processor 110. For example, the memory may exist independently or be located in any other location, without specific limitations.

[0109] The above Figure 4 The hardware structure of the electronic device has been described. The software structure of the electronic device will be described below.

[0110] The software system of electronic devices can adopt layered architecture, event-driven architecture, microkernel architecture, microservice architecture, or cloud architecture, etc. This application uses a layered architecture as an example to illustrate the software structure of an electronic device.

[0111] As is understandable, a layered architecture divides the software system of an electronic device into several layers, each with a clear role and division of labor. Layers communicate with each other through software interfaces.

[0112] For example, Figure 5 This is a software structure block diagram of an electronic device to which embodiments of this application apply. For example, the electronic device may include: an application layer, an application framework layer, a native layer, and a kernel layer.

[0113] 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. (See also...) Figure 5 The application layer can include: games, camera, gallery, system applications, etc. Among them, system applications include: status pass-through module.

[0114] The state pass-through module is used to sense the lock holding status of each process in an electronic device, as well as the screen status of the electronic device. Adaptively, the state pass-through module can record information such as the screen on / off state of the electronic device, the name of the wake-up lock (lock name) of the running application, the process and time threshold of the running application, etc. The running application can be a foreground application or a background application.

[0115] The application framework layer provides an application programming interface (API) and programming framework for applications in the application layer. The application framework layer includes some predefined functions. In this embodiment, the application framework layer may include a power manager (PM).

[0116] The power manager provides the power management service (PMS). PMS 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 local layer and kernel layer to control the device's standby state and the state 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 PMS.

[0117] PM is a proxy class for PMS. PM provides interaction interfaces to upper-layer applications. After the upper-layer application calls the PM's interfaces, the actual work is completed by PMS. The interfaces provided by PM include: wakeUp, gotoSleep, userActivity, and wakelock.

[0118] The wakelock interface 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.

[0119] The power management service may include a partial lock management unit. This unit records the number of times each process requests a partial lock, the request time, and other request information. Based on this information (also known as the application's partial lock holding status), it determines whether to cancel the partial lock request. For example, if the number of requests exceeds a first threshold within a past period, the process is not allowed to request a partial lock (this can be understood as a partial lock request failure). Alternatively, if the number of requests exceeds the first threshold within the current time period, the process is not allowed to request a partial lock.

[0120] The partial lock management unit may include a partial lock data recording module and a partial lock judgment module. The partial lock data recording module is used to record the number of times each process requests a partial lock; the partial lock judgment module is used to determine whether to cancel the partial lock request based on the partial lock request information.

[0121] The native layer is the layer that interacts directly with the underlying hardware or operating system kernel.

[0122] The native layer can provide system services, location services, touch services, display services, etc. for applications in the application layer.

[0123] In this embodiment, the system service may include a native lock management unit. The native lock management unit can record the number of times each process requests a native lock, and determine whether to cancel the native lock request based on the native lock request status (also known as the native lock holding status). For example, if the number of requests exceeds a second threshold within a past period, the process is not allowed to request a native lock (this can also be understood as a failed native lock request). Alternatively, if the number of requests exceeds the second threshold within the current time period, the process is not allowed to request a native lock.

[0124] The native lock management unit may include a native lock data recording module and a native lock judgment module. The native lock data recording module is used to record the number of times each process requests each lock, the request time, and other request information; the native lock judgment module is used to determine whether to cancel the native lock request based on the native lock request information.

[0125] The kernel layer is the layer between hardware and software. It drives the hardware, enabling it to function. (See also...) Figure 5 The kernel layer may include: power driver, display driver, camera driver, audio driver, sensor driver, etc., and this application embodiment does not limit this.

[0126] The power driver can handle low-level power management tasks, such as entering and exiting hibernation mode, managing CPU frequency and voltage, and handling battery charging status.

[0127] The power driver may include a kernel lock management unit. This unit records the number of kernel lock requests and the time of each process's request, and determines whether to cancel the kernel lock request based on the request status (also known as the kernel lock holding status). For example, if the number of requests exceeds a third threshold within a past period, the process is not allowed to request a kernel lock (this can be understood as the kernel lock request failing). Alternatively, if the number of requests exceeds the third threshold within the current time period, the process is not allowed to request a kernel lock.

[0128] The kernel lock management unit may include a kernel lock data recording module and a kernel lock determination module. The kernel lock data recording module records the number of times each process requests each lock; the kernel lock determination module determines whether to cancel the kernel lock request based on the kernel lock request information.

[0129] It should be understood that the state pass-through module, partial lock management unit, native lock management unit, and kernel lock management unit in this application are merely examples. Other modules or units with similar or identical functions that can perform similar or identical technical solutions to the embodiments of this application are also within the protection scope of the embodiments of this application.

[0130] It is understood that the software structure division of the electronic device in this application embodiment is just an example. This application embodiment does not limit the hierarchical division method in the software system of the electronic device. The modules in each level in the following embodiments are the modules involved in the embodiments of this application. Each level may also include more or fewer modules than shown in the figure, or combine some modules, or split some modules.

[0131] It is understandable that processes in electronic devices can be divided into three categories: application processes, native processes, and kernel processes. The functionality of an application can be achieved through the cooperation of one or more of these three types of processes.

[0132] Typically, application processes create or release wake locks through the corresponding interface in the power management service. Native processes can create or release wake locks through the corresponding interface in system services or by directly writing to file nodes. Kernel processes can create or release wake locks through the corresponding interface in the power driver at the kernel level. Furthermore, wake locks created in any way will create a wake_source node at the kernel level.

[0133] In this embodiment, the state pass-through module can monitor wake-up locks created through the various methods described above and obtain the lock information for each wake-up lock. The lock information may include: the holder's package name, the process's identity (ID), the user ID, and a tag description. Based on the lock information of each wake-up lock, the state pass-through module can determine the wake-up lock holding status (or application status) of each process. For example, it can determine the holding status of partial locks for each application process, the holding status of native locks for each native process, and the holding status of kernel locks for each kernel process.

[0134] The state pass-through module can transmit the holding status of partial locks corresponding to each application process to the partial lock management unit; the state pass-through module can transmit the holding status of native locks corresponding to each native process to the native lock management unit; the state pass-through module can transmit the holding status of kernel locks corresponding to each kernel process to the kernel lock management unit.

[0135] In this embodiment, the status transmission module can periodically transmit the holding status of various types of wake-up locks, or it can transmit the holding status of such wake-up locks after receiving a message indicating a query for the holding status of a wake-up lock. The transmission period can be 1 minute, every 5 minutes, or any value; no specific limitation is made here. This embodiment does not specifically limit the triggering mechanism for transmitting the holding status of wake-up locks.

[0136] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments.

[0137] For example, Figure 6 This is a flowchart illustrating a wake-up lock management method provided in an embodiment of this application. Figure 6 As shown, the method includes:

[0138] S601, The process sends a wake-up lock request to the wake-up lock management unit.

[0139] The process sends a wake-up lock request.

[0140] S602. If the wake-up lock of the first process meets the preset conditions, the wake-up lock management unit does not create a wake-up lock.

[0141] In some embodiments, the preset conditions include: the number of times the process requests the wake-up lock within a preset time period in the past is greater than or equal to a preset number (also known as the number threshold).

[0142] The preset duration can be 1 minute, 2 minutes, or any duration; the preset number of times can be 3 times, 5 times, or any number of times. There are no specific limitations on the preset duration and the preset number of times.

[0143] It is understandable that the preset duration and preset number of times can be the same or different for different types of wake-up locks; no specific restrictions are made here.

[0144] Based on the above embodiments, if an electronic device fails to request a wake-up lock multiple times consecutively, it will not create a wake-up lock for that process for a subsequent period of time. This period can be one day, one week, or any other length; no specific limitation is made here. This way, in the event of multiple frequent requests, requests are prohibited for an extended period, improving the user experience.

[0145] In other embodiments, the preset conditions include: the number of times the process requests the wake-up lock within the current time period is greater than or equal to a preset number.

[0146] For example, if the current time period is 1 minute long and starts at 0 seconds, then the current time period is 0 to 1 minute. Assuming a preset number of attempts is 5, if the process requests the wake-up lock for the 4th time after 20 seconds, its request will fail the next time it attempts. If the current time period is updated to 1 to 2 minutes, since the number of wake-up lock requests during this time period is less than the preset number, the process can successfully request the wake-up lock after 1 minute.

[0147] Based on the above embodiments, if an electronic device requests a wake-up lock for a process for a period of time that is greater than or equal to a preset number of times within N consecutive time periods, no wake-up lock will be created for that process for a subsequent period. N is a positive integer. A period of time can be 1 day, 1 week, or any other duration, etc., and is not specifically limited here. This way, in the event of multiple frequent requests, requests are prohibited for an extended period, improving the user experience.

[0148] In some embodiments, besides determining whether to create a wake-up lock based on the number of wake-up lock requests, other arbitrary conditions can also be used. For example, the duration for which a process holds the wake-up lock within a preset time period can also be used to determine whether to create a wake-up lock. Specifically, if the duration for which a process holds the wake-up lock within the preset time period is greater than or equal to a preset value, no wake-up lock is created; if the duration for which a process holds the wake-up lock within the preset time period is less than the preset value, a wake-up lock is created.

[0149] The preset value can be 30 seconds, 1 minute, or any value; no specific limitation is made here.

[0150] In this way, the lock can be woken up by limiting the holding time, reducing power consumption caused by holding the lock for too long.

[0151] S603. If the wake-up lock of the first process does not meet the preset conditions, create a wake-up lock.

[0152] After creating the wake-up lock, the lock holding status of the first process is recorded. For example, the lock holding count is incremented by 1, the wake-up lock creation time is recorded, and the wake-up lock release time is recorded.

[0153] This limits the number of times a process can hold a wake-up lock within a certain period, reducing the likelihood of a process frequently requesting a wake-up lock.

[0154] Based on the above embodiments, a prompt message can also be generated when preset conditions are met to alert the user to application abnormalities. This allows for the notification of application abnormalities and risk warnings. The prompt message can be displayed on the interface as a pop-up window, or delivered via voice or any other means; no specific limitation is made here.

[0155] The management method will be explained below using a specific example of a wake-up lock.

[0156] For example, Figure 7 This is a flowchart illustrating a wake-up lock management method provided in an embodiment of this application. Taking process A requesting a partial lock and determining whether to create a wake-up lock based on the number of wake-up lock requests within a preset time period as an example, the method includes:

[0157] S701, Process A transmits a request A to PMS, indicating the creation of a partial lock. Request A includes: the ID of process A and the identifier of the partial lock.

[0158] For example, process A calls the acquire interface of PMS and enters the name of the partial lock that process A needs to create in PMS.

[0159] S702, PMS obtains the partial lock holding information (also known as the request status) of process A from the status pass-through module.

[0160] The information held includes: the time of the wake-up lock request, the threshold number of times process A has held the partial lock, and the number of requests.

[0161] Taking a preset number of times process A holds a partial lock as an example, if the number of times process A requests a partial lock within a preset time period A is greater than or equal to the preset number A, execute S703. If the number of times process A requests a partial lock within a preset time period A is less than the preset number A, execute S704-S707.

[0162] S703. If the number of times process A requests a partial lock within a preset time period A is greater than or equal to a preset number A, PMS will not create a partial lock for process A.

[0163] The preset duration A can be 1 minute, 2 minutes or any duration; the preset number of times A can be 3 times, 5 times or any number of times. There are no specific limitations on the preset duration A and the preset number of times A.

[0164] This limits the number of times process A can hold a partial lock within a certain period, reducing the likelihood of process A frequently requesting a partial lock.

[0165] For example, PMS does not write the identifier of process A, or the name of the partial lock, into the corresponding file node (e.g., / sys / power / wake_lock).

[0166] S704. If the number of times process A requests a wake-up lock within a preset time period A is less than a preset number A, PMS creates a wake-up lock for process A.

[0167] For example, the process of PMS creating a partial lock is as follows: PMS calls the acquire_wake_lock interface to write the identifier of process A and the name of the partial lock into the corresponding file node (e.g., / sys / power / wake_lock). After that, the partial lock for process A is created.

[0168] After creating the wake-up lock for process A, S705 and PMS transmit a message indicating the creation of the wake-up lock for process A to the status pass-through module. Adaptively, the status pass-through module records the creation time of the wake-up lock for process A.

[0169] S706. When process A exits or terminates its task, PMS releases the wake-up lock of process A.

[0170] After releasing the wake-up lock of process A, S707 and PMS transmit a message to the status pass-through module indicating that the wake-up lock of process A has been released. Adaptively, the status pass-through module records the release time of the wake-up lock of process A.

[0171] In this way, process A can acquire the corresponding wake-up lock.

[0172] For example, Figure 8 This is a flowchart illustrating a wake-up lock management method provided in an embodiment of this application. Taking process B requesting a native lock and determining whether to create a wake-up lock based on the number of wake-up lock requests within a preset time period as an example, the method includes:

[0173] S801, Process B transmits a request B to the system service, indicating the creation of a native lock. Request B includes: the ID of Process B and the identifier of the native lock.

[0174] For example, process B calls the interface acquire_wake_lock and enters the name of the native lock that process B needs to create in the system service.

[0175] S802, The system service obtains the wake-up lock holding information of process B from the state pass-through module.

[0176] The information held includes: the time of the wake-up lock request, the threshold number of times process B holds the native lock, and the number of requests.

[0177] Taking a preset number of times process B holds the native lock as an example, if the number of times process B requests the wake-up lock within a preset time period B is greater than or equal to the preset number of times B, execute S803. If the number of times process B requests the wake-up lock within a preset time period B is less than the preset number of times B, execute S804-S807.

[0178] S803. If the number of times process B requests a wake-up lock within a preset time period B is greater than or equal to a preset number B, PMS will not create a wake-up lock for process B.

[0179] The preset duration B can be 1 minute, 2 minutes, or any duration; the preset number of times B can be 3 times, 5 times, or any number of times. There are no specific limitations on the preset duration B and the preset number of times B. The preset duration B can be the same as or different from the preset duration A.

[0180] This limits the number of times process B can hold the wake-up lock within a certain period, reducing the frequency with which process B requests the wake-up lock.

[0181] For example, the system service does not write the identifier of process B, as well as the name of the native lock, into the corresponding file node (e.g., / sys / power / wake_lock).

[0182] S804. If the number of times process B requests the wake-up lock within a preset time period B is less than a preset number B, PMS creates a wake-up lock for process B.

[0183] For example, the process of a system service creating a wake-up lock is as follows: The system service writes the identifier of process B and the name of the native lock into the corresponding file node (e.g., / sys / power / wake_lock). Afterwards, the native lock for process B is created.

[0184] In other embodiments, the native process may also directly write its identifier and the name of the native lock to be created into the corresponding file node (e.g., / sys / power / wake_lock).

[0185] S805. After creating the wake-up lock for process B, the system service transmits a message to the status pass-through module indicating the creation of the wake-up lock for process B. Adaptively, the status pass-through module records the creation time of the wake-up lock for process B.

[0186] S806. When process B exits or terminates its task, the system service releases the wake-up lock of process B.

[0187] S807. After releasing the wake-up lock of process B, the system service transmits a message to the status pass-through module indicating that the wake-up lock of process B has been released. Adaptively, the status pass-through module records the release time of the wake-up lock of process B.

[0188] In this way, process B can acquire the corresponding wake-up lock.

[0189] For example, Figure 9 This is a flowchart illustrating a wake-up lock management method provided in an embodiment of this application. Taking process C requesting a kernel lock and determining whether to create a wake-up lock based on the number of wake-up lock requests within a preset time period as an example, the method includes:

[0190] S901, Process C transmits a request C to the power driver, indicating the creation of a kernel lock. Request C includes: the ID of process C and the identifier of the kernel lock.

[0191] For example, process C calls the corresponding interface of the power driver and inputs the name of the kernel lock that process C needs to create in the power driver.

[0192] S902, the power driver obtains the wake-up lock holding information of process C from the status pass-through module.

[0193] The information held includes: the time of requesting the wake-up lock, the threshold number of times process C holds the kernel lock, and the number of requests.

[0194] Taking a preset number C as an example, if the number of times process C holds the kernel lock is greater than or equal to the preset number C within a preset time period C, execute S903. If the number of times process C requests the wake-up lock is less than the preset number C within a preset time period C, execute S904-S907.

[0195] S903. If the number of times process C requests a wake-up lock within a preset time period C is greater than or equal to a preset number C, PMS will not create a wake-up lock for process C.

[0196] The preset duration C can be 1 minute, 2 minutes, or any duration; the preset number of times C can be 3 times, 5 times, or any number of times. There are no specific limitations on the preset duration C and the preset number of times C. The preset duration C can be the same as or different from the preset duration A.

[0197] This limits the number of times process C can hold the wake-up lock within a certain period, reducing the frequency with which process C requests the wake-up lock.

[0198] For example, the power driver does not write the identifier of process C, or the name of the kernel lock, into the corresponding file node (e.g., / sys / power / wake_lock).

[0199] S904. If the number of times process C requests the wake-up lock within a preset time period C is less than a preset number C, PMS creates a wake-up lock for process C.

[0200] For example, the process of the power driver creating a wake-up lock is as follows: The power driver writes the identifier of process C and the name of the kernel lock into the corresponding file node (e.g., / sys / power / wake_lock). After that, the kernel lock for process C is created.

[0201] In other embodiments, the kernel process may also directly write its identifier and the name of the kernel lock to be created into the corresponding file node (e.g., / sys / power / wake_lock).

[0202] S905. After creating the wake-up lock for process C, the power driver transmits a message to the status pass-through module indicating the creation of the wake-up lock for process C. Adaptively, the status pass-through module records the creation time of the wake-up lock for process C.

[0203] S906. When process C exits or terminates its task, the power driver releases the wake-up lock of process C.

[0204] S907. After releasing the wake-up lock of process C, the power driver transmits a message to the status pass-through module indicating that the wake-up lock of process C has been released. Adaptively, the status pass-through module records the release time of the wake-up lock of process C.

[0205] In this way, process C can acquire the corresponding wake-up lock.

[0206] Based on the above embodiments, the lock management unit can also obtain the status of the display screen from the status pass-through module.

[0207] When the screen is off, determine whether to create a wake-up lock based on the above preset conditions. When the screen is on, do not determine whether to create a wake-up lock based on the above preset conditions.

[0208] It's understandable that electronic devices typically don't go into sleep mode when the screen is on. Electronic devices can go into sleep mode when the screen is off. Therefore, the above method can be used when the screen is off, but not when the screen is on, saving signaling resources and energy consumption.

[0209] It should be noted that the module names involved in the embodiments of this application can all be defined as other names, as long as they can achieve the function of each module, and no specific restrictions are placed on the module names.

[0210] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in the embodiments of this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0211] The wake-up lock management method of the present application embodiments has been described above. The apparatus for executing the above method provided in the present application embodiments is described below. Those skilled in the art will understand that the methods and apparatus can be combined and referenced with each other, and the related apparatus provided in the present application embodiments can execute the steps in the above method.

[0212] The wake-up lock management method provided in this application can be applied to electronic devices with sleep functionality. Electronic devices include terminal devices; the specific device form of the terminal device can be referred to the above-described related features, and will not be repeated here.

[0213] This application provides an electronic device, which includes one or more processors and a memory; the memory is coupled to one or more processors and is used to store computer program code, which includes computer instructions, and one or more processors call the computer instructions to cause the electronic device to perform the above-described method.

[0214] This application provides a chip or chip system. The chip or chip system includes one or more processors, which invoke computer instructions to cause an electronic device to execute the technical solutions described above. Its implementation principle and technical effects are similar to the related embodiments described above, and will not be repeated here.

[0215] This application also provides a computer-readable storage medium. The computer-readable storage medium includes computer instructions that, when executed on an electronic device, cause the electronic device to perform the above-described method.

[0216] The methods described in the above embodiments can be implemented, in whole or in part, 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 on a computer-readable medium. A 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. A storage medium can be any target medium accessible by a computer.

[0217] In one possible implementation, a computer-readable medium may include RAM, ROM, compact disc read-only memory (CD-ROM) or other optical disc storage, 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, 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.

[0218] This application provides a computer program product, which includes computer program code. When the computer program code is run, it causes the computer to perform the above-described method.

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

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

Claims

1. A method for managing a wake-up lock, characterized in that, include: Obtain the lock holding information of the first process, wherein the lock holding information is used to indicate the status of the first process holding a wake-up lock; If the lock holding information meets the preset conditions, the first process does not hold the wake-up lock.

2. The method according to claim 1, characterized in that, The preset conditions include: the number of times the first process requests a wake-up lock within a preset time period is greater than or equal to a first preset threshold. When the lock holding information meets preset conditions, the first process does not hold the wake-up lock, including: If the number of times the first process requests a wake-up lock within a preset time period is greater than or equal to the first preset threshold, no wake-up lock will be created for the first process.

3. The method according to claim 1, characterized in that, The preset conditions include: the number of times the first process requests a wake-up lock within the current time period is greater than or equal to a second preset threshold; When the lock holding information meets preset conditions, the first process does not hold the wake-up lock, including: If the number of times the first process requests a wake-up lock within the current time period is greater than or equal to the second preset threshold, no wake-up lock will be created for the first process.

4. The method according to claim 3, characterized in that, The method further includes: If the number of times the first process requests a wake-up lock is greater than or equal to the second preset threshold in N consecutive time periods, no wake-up lock is created for the first process within the first time period; where N is a positive integer.

5. The method according to any one of claims 2-4, characterized in that, The statement that the wake-up lock for the first process is not created includes: not writing the lock name of the wake-up lock that the first process needs to create into the corresponding file node.

6. The method according to any one of claims 1-5, characterized in that, The first process is an application process, a native process, or a kernel process.

7. An electronic device, characterized in that, The electronic device includes: one or more processors and memory; The memory is coupled to the one or more processors, the memory being used to store computer program code, the computer program code including computer instructions, the one or more processors invoking the computer instructions to cause the electronic device to perform the method as described in any one of claims 1 to 6.

8. A chip system, characterized in that, The chip system is applied to an electronic device, the chip system including one or more processors, the one or more processors being used to invoke computer instructions to cause the electronic device to perform the method as described in any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes computer instructions that, when executed on an electronic device, cause the electronic device to perform the method as described in any one of claims 1 to 6.

10. A computer program product, characterized in that, The computer program product includes computer program code that, when run on an electronic device, causes the electronic device to perform the method as described in any one of claims 1 to 6.

Images