A hardware module management method, device and equipment

Abstract

This application provides a hardware module management method, apparatus, and device, applicable to the field of computer technology. The method includes: upon receiving a switching instruction instructing the device to enter a light sleep mode, directly shutting down a target hardware module in the device used for processing audio data. The method provided in this application, by directly shutting down the target hardware module, can eliminate interference caused by the target hardware module during the process of the device entering a light sleep mode, ensuring the device smoothly enters the light sleep mode and thus improving the success rate of entering the light sleep mode.

Description

Technical Field

[0001] This application relates to the field of computer technology, and more specifically, to a hardware module management method, apparatus, and device in the field of computer technology. Background Technology

[0002] Currently, devices frequently fail to switch to Suspend To RAM (STR) mode, making it impossible to enter STR mode. Therefore, there is an urgent need for a method to improve the success rate of devices entering STR mode. Summary of the Invention

[0003] This application provides a hardware module management method, apparatus, and device, which can increase the probability of the device entering a light sleep mode.

[0004] Firstly, a hardware module management method is provided, the method comprising:

[0005] Determine whether a switching command has been received, the switching command indicating that the device needs to enter a light sleep mode; If the switching instruction is received, the target hardware module in the device used for processing audio data is turned off.

[0006] In this embodiment, after receiving a switching command instructing the device to enter light sleep mode, the target hardware module in the device used for processing audio data is directly shut down. By directly shutting down the target hardware module, interference caused by the target hardware module in the process of the device entering light sleep mode can be eliminated, ensuring that the device can smoothly enter light sleep mode and thus improving the success rate of the device entering light sleep mode.

[0007] Optionally, before shutting down the target hardware module in the device used for processing audio data, the method further includes: shutting down the audio stream if a pre-created audio stream exists in the device.

[0008] In this embodiment of the application, before shutting down the target hardware module in the device used to process audio data, it is first determined whether there is an audio stream in the device, and the audio stream is shut down when there is an audio stream in the device. This not only indirectly shuts down the target hardware module, but also prevents the application from making mistakes when the target hardware module is directly shut down, thereby improving the reliability of the device.

[0009] Optionally, shutting down the audio stream includes: sending a fault notification indicating a fault in the target hardware module to the application that created the audio stream, thereby triggering the application to shut down the audio stream.

[0010] In this embodiment, by inducing the application to close the created audio stream through a fault notification that characterizes a target hardware module failure, the audio stream in the device can be closed simply and quickly, thereby ensuring that the audio stream and the target hardware module can be reliably closed, and thus improving the success rate of the device entering a light sleep mode.

[0011] Optionally, shutting down the target hardware module in the device used for processing audio data includes: After closing the audio stream, determine whether there is an abnormal audio stream that has not been closed in the device; if the abnormal audio stream exists, notify the hardware abstraction layer in the device to close the target hardware module.

[0012] In this embodiment, the audio stream is first shut down, and then when it is determined that there is an abnormal audio stream that has not been shut down, the hardware abstraction layer is notified to shut down the target hardware module. This can prevent application fault alarms and thus improve the reliability of the device.

[0013] Optionally, the method further includes: if the abnormal audio stream is an audio stream playing audio data, then writing the audio data in the abnormal audio stream into memory through the hardware abstraction layer and discarding it; or, if the abnormal audio stream is an audio stream recording audio data, then sending empty data to the abnormal application that created the abnormal audio stream through the hardware abstraction layer.

[0014] In this embodiment, for abnormal audio streams used for playing audio data, the audio data in the abnormal audio stream is written to memory and then discarded through the hardware abstraction layer. For abnormal audio streams used for recording audio data, empty data is sent to the abnormal application that created the abnormal audio stream through the hardware abstraction layer. This can prevent abnormal application errors and thus improve the reliability of the device.

[0015] Optionally, the method further includes: notifying the hardware abstraction layer to send a fault notification characterizing a fault in the target hardware module to the abnormal application that created the abnormal audio stream, so as to trigger the abnormal application to close the abnormal audio stream.

[0016] In this embodiment, while shutting down the target hardware module through the hardware abstraction layer, the abnormal application is notified of the target hardware module failure, causing the abnormal application to shut down the audio stream. This can prevent the abnormal application from continuing to play or record audio data after the target hardware module is shut down, thereby reducing device power consumption and improving device reliability.

[0017] Optionally, the method further includes: marking the abnormal application that created the abnormal audio stream so that the device shuts down the target hardware module when it detects that the abnormal application is running during the process of entering the light sleep mode.

[0018] Optionally, shutting down the target hardware module in the device used for processing audio data includes: Identify at least one application currently running on the device; If the at least one application includes a pre-tagged application, then the target hardware module is shut down.

[0019] In this embodiment, when an abnormal audio stream exists, the abnormal application that created the abnormal audio stream can be marked. Thus, when the device enters light sleep mode again, if it is determined that the abnormal application is running, the target hardware module can be directly shut down. This allows for a quick shutdown of the target hardware module, minimizing interference from any unshutdowned target hardware module during the device's entry into light sleep mode, thereby improving the success rate of entering light sleep mode.

[0020] Secondly, a hardware module management device is provided, the device comprising: The determination module is used to determine whether a switching instruction has been received, wherein the switching instruction indicates that the device needs to enter a light sleep mode; The shutdown module is used to shut down the target hardware module in the device used for processing audio data if the switching instruction is received.

[0021] Thirdly, a device is provided, the device comprising: Memory, used to store executable program code; A processor is configured to call and run the executable program code from the memory, causing the device to perform the method in any possible implementation of the first aspect described above.

[0022] Fourthly, a program product is provided, comprising: program code that, when run on a device, causes the device to execute the method in any possible implementation of the first aspect.

[0023] Fifthly, a readable storage medium is provided that stores program code, which, when run on a device, causes the device to perform the method in any possible implementation of the first aspect described above. Attached Figure Description

[0024] Figure 1 This is a flowchart illustrating the steps of a hardware module management method provided in an embodiment of this application; Figure 2 This is a schematic diagram of the system architecture of a device provided in an embodiment of this application; Figure 3This is a flowchart illustrating a hardware module management method provided in an embodiment of this application; Figure 4 This is a schematic diagram of the structure of a hardware module management device provided in an embodiment of this application; Figure 5 This is a schematic diagram of the structure of a device provided in an embodiment of this application. Detailed Implementation

[0025] The technical solutions in this application will be clearly and thoroughly described below with reference to the accompanying drawings. In the description of the embodiments of this application, unless otherwise stated, " / " means "or," for example, A / B can mean A or B. "And / or" in the text is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Furthermore, in the description of the embodiments of this application, "multiple" refers to two or more than two.

[0026] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature.

[0027] Light sleep mode is a new device management mode widely used in various devices, designed to balance energy consumption and the need for rapid recovery. The main principle of light sleep mode is to save the device's current state and operating data to memory, which can be Random Access Memory (RAM). When the device enters light sleep mode, most hardware modules except memory are shut down to reduce power consumption, while memory remains powered to ensure that the data stored in memory is not lost. This is similar to putting the device into a "standby" state, saving energy while retaining the ability to recover quickly. When the device needs to resume operation, it directly reads data from memory to restore the device, allowing it to quickly return to its previous working state, thereby improving work efficiency.

[0028] As mentioned above, when a device enters a light sleep mode, it needs to shut down most of the hardware modules except for the memory. If some hardware modules cannot be shut down properly, the conditions for entering a light sleep mode cannot be met, and the device will not be able to enter a light sleep mode.

[0029] In practical applications, devices may launch various applications (APPs) during operation. These applications may create one or more audio streams during operation. The processing of audio data in these audio streams requires the use of relevant hardware modules (hereinafter referred to as target hardware modules), such as digital signal processors (DSPs), microphones, speakers, and Bluetooth modules.

[0030] The DSP (Digital Signal Processor) is a hardware module in the device used to process audio signals. For example, the DSP can process audio signals captured by the microphone in real time, executing algorithms such as noise reduction and echo cancellation. Specifically, in call or voice assistant scenarios, the DSP can process the audio captured by the microphone to improve the clarity and quality of the speech. For instance, during audio playback, the DSP can optimize the audio signal to be played, such as enhancing sound effects and adjusting the equalizer, before sending the processed audio signal to the speaker for playback output.

[0031] The device, for example, is a vehicle. During operation, the vehicle may launch applications for playing music, navigation, and providing vehicle-related information. The music playback application needs to create an audio stream for playing music; the navigation application needs to create an audio stream for receiving user-input voice commands and outputting voice prompts; and the vehicle-related information prompt application needs to create an audio stream for playing prompt information. Processing the audio data in these audio streams requires the use of the aforementioned target hardware modules such as the DSP, microphone, speaker, and Bluetooth module.

[0032] Audio stream refers to the transmission path and processing of audio data within a device. Audio stream can be understood as the transmission process of audio data, such as the entire process from the microphone to the recording app, and the entire process from the playback app to the speaker.

[0033] For the various audio streams mentioned above, during the process of entering light sleep mode, the device needs to send a notification to the application that created the audio stream, instructing the application to close the created audio stream, thereby shutting down the relevant target hardware modules. Once the relevant target hardware modules are shut down, the device meets the conditions for entering light sleep mode and can successfully enter it. In practical applications, some applications (such as independently developed third-party apps) do not follow the above rules. After receiving the notification, they do not close the created audio stream, preventing the relevant target hardware modules from shutting down. Consequently, the conditions for the device to enter light sleep mode are not met, leading to the device failing to enter light sleep mode.

[0034] In short, during the process of a device entering light sleep mode, audio streams created by some applications may not close properly, preventing the target hardware module from shutting down. This prevents the conditions for entering light sleep mode from being met, potentially causing the device to fail to enter light sleep mode. Understandably, the more applications on the device that cannot properly close their audio streams, the lower the success rate of the device entering light sleep mode.

[0035] To address the aforementioned technical problems, this application provides a hardware module management method. This method manages the hardware modules used for processing audio data in the device during the process of the device entering a light sleep mode, thereby improving the success rate of the device entering a light sleep mode.

[0036] In this method, after receiving the switching command to enter light sleep mode, the device directly shuts down the target hardware module in the device used to process audio data. Thus, during the process of entering light sleep mode, regardless of whether the audio stream in the device is successfully shut down, the target hardware module can be shut down normally without interfering with the process of entering light sleep mode, ensuring that the device smoothly enters light sleep mode and thereby improving the success rate of entering light sleep mode.

[0037] See Figure 1 , Figure 1 This is a flowchart illustrating the steps of a hardware module management method provided in an embodiment of this application. The method can be executed by a control terminal in the device (e.g., a Head Unit Terminal (HUT) in a vehicle), specifically by a management program in the control terminal used to manage the device's operating mode. The method may include the following steps: Step 101: Determine if a switching command has been received. The switching command indicates that the device needs to enter a light sleep mode.

[0038] The switching command is used to control the device to enter a light sleep mode, and the switching command can be input to the device in a variety of ways.

[0039] For example, when the device is running, if a user temporarily does not need to use the device and requires it to be in a standby state, they can input a switching command into the management program. For instance, the device is a vehicle, and the HUT has a display screen showing a virtual button used to input the switching command. When the vehicle is running, the management program runs in the background of the HUT, continuously monitoring the virtual button. When the user needs the vehicle to enter a standby state, they can click the virtual button. Correspondingly, after detecting the user's click on the virtual button, the management program determines that it has received the user's input switching command.

[0040] For example, if the vehicle's battery level is higher than a preset threshold (indicating sufficient battery power), the management program can use a power-down command as a switching command upon receiving it, thus confirming receipt of the switching command. Another example is a physical button on the vehicle's smart key for inputting switching commands. When the user needs the vehicle to enter a waiting state, they can press this button to send a switching command to the HUT. Correspondingly, after detecting that the HUT has received the switching command sent by the smart key, the management program confirms that the switching command has been received.

[0041] It should be understood that the above are merely illustrative examples, and the specific form of the switching instruction and the method by which the management program determines whether a switching instruction has been received may include, but are not limited to, the examples above.

[0042] Step 102: If the switching instruction is received, the target hardware module in the device used to process audio data is turned off.

[0043] In one implementation, after determining that the device has received a switching instruction, the management program directly shuts down the target hardware module in the device used to process audio data, regardless of whether there is an audio stream in the device. The target hardware module includes, but is not limited to, the DSP, speaker, and microphone mentioned in the examples above.

[0044] See Figure 2 , Figure 2 This is a schematic diagram of the system architecture of a device provided in an embodiment of this application. The device includes an operating system and a hardware layer. The operating system is, for example, Android, and can be divided into an application layer, a middleware layer, and a hardware abstraction layer (HAL). The hardware layer includes target hardware modules for processing audio data, such as the DSP, microphone, and speaker mentioned in the example above, as well as other hardware modules. This embodiment does not specifically limit the other hardware modules included in the device.

[0045] like Figure 1 As shown, the application layer has one or more applications, such as APP1, APP2, and APP3, that can create audio streams, while the middle layer has an audio server. The management program can reside in the middle layer. After receiving a switching command, the management program can directly send a shutdown command to the audio server, which then forwards the shutdown command to the hardware abstraction layer. Correspondingly, after receiving the shutdown command from the audio server, the hardware abstraction layer can control the shutdown of target hardware modules such as the DSP, speakers, and microphones in the hardware layer. It should be understood that... Figure 1 For illustrative purposes only, the methods by which the management program controls the shutdown of individual target hardware modules may include, but are not limited to, the examples above.

[0046] Among them, after each target hardware module is turned off, the interference of each target hardware module to the device entering the shallow sleep mode can be eliminated.

[0047] It's understandable that once the target hardware modules are shut down, even if an audio stream exists, the shutdown of the target hardware modules can trigger each application to automatically close its created audio stream. Simultaneously, after confirming receipt of the switching command, the management program can send shutdown commands to each application, controlling each application to shut down automatically.

[0048] It should be noted that the management program's operation of shutting down each target hardware module is only one step in the process of the device entering light sleep mode. After receiving the switching command, the management program will perform other related operations in addition to shutting down each target hardware module to enable the device to enter light sleep mode.

[0049] Taking a vehicle as an example, after receiving a switching command, the management program also checks whether the battery charge meets the minimum threshold for entering shallow sleep mode. If the battery charge is below the threshold, the management program will prompt the user and prevent the vehicle from entering shallow sleep mode. The management program also checks whether the ambient temperature is within the allowable range. If the temperature is too high or too low, it may affect the data retention capability of the RAM, and the management program will prompt the user and prevent the vehicle from entering shallow sleep mode. The management program also checks the status of other critical systems, such as the engine and braking system, to ensure that the vehicle is in a safe state before entering shallow sleep mode. In addition, the management program will save the vehicle's current operating status (such as system configuration, application status, user settings, etc.) to RAM and shut down other hardware modules in the hardware layer besides the aforementioned target hardware modules.

[0050] In this embodiment, after receiving a switching command instructing the device to enter light sleep mode, the target hardware module used for processing audio data in the device is directly shut down. With the target hardware module shut down, it will not interfere with the process of the device entering light sleep mode, ensuring a smooth transition and thus improving the success rate of entering light sleep mode.

[0051] Optionally, before shutting down the target hardware module in the device used to process audio data, the method may further include: If a pre-created audio stream exists on the device, turn off the audio stream.

[0052] In one implementation, after receiving a switching instruction, the management program first determines whether a pre-created audio stream exists in the device. If a pre-created audio stream exists in the device, the management program can first shut down the audio stream.

[0053] For example, after confirming that a switching instruction has been received, the management program can request audio focus from the device's operating system. If the request is denied, it is determined that the audio focus is being used by an application, and thus it can be determined that an audio stream exists on the device. Alternatively, after confirming that a switching instruction has been received, the management program can request the operating system to release the audio focus. If the request is denied, it is determined that the audio focus is being used by an application, and thus it can be determined that an audio stream exists on the device.

[0054] After determining that an audio stream exists on the device, the management program can identify all currently active applications on the device (i.e., assuming the audio stream was created by a currently active application), and then send a custom broadcast (i.e., a notification) to each active application, notifying the application to close itself, thus shutting down the audio stream it pre-created. Alternatively, after determining that an audio stream exists on the device, the management program can identify the application currently holding audio focus on the device, and then send a custom broadcast to that application, notifying it to close the pre-created audio stream.

[0055] It is understandable that the application closes the audio stream after receiving a notification from the management program. At the same time as closing the audio stream, the target hardware module used to process the audio data in the audio stream will be closed synchronously.

[0056] Alternatively, the management program can be pre-configured to have the highest privilege to acquire audio focus. After determining that an audio stream exists on the device, the management program can preempt the audio focus. Once the management program has acquired the audio focus, the application that preempted the audio focus and created the audio stream will release the audio focus and close the created audio stream.

[0057] It should be understood that the above are merely illustrative examples, and methods for closing the audio stream may include, but are not limited to, the examples above.

[0058] It should be noted that during the process of closing audio streams, some audio streams created by applications may not be able to be closed normally. The reason for this failure may be that the application does not allow other applications to close the audio streams it created, or other reasons. This embodiment will not elaborate on these points.

[0059] In this embodiment of the application, before shutting down the target hardware module in the device used to process audio data, it is first determined whether there is an audio stream in the device, and the audio stream is shut down when there is an audio stream in the device. This not only indirectly shuts down the target hardware module, but also prevents the application from making mistakes when the target hardware module is directly shut down, thereby improving the reliability of the device.

[0060] Optionally, the steps to close the audio stream include: Send a fault notification indicating a failure of the target hardware module to the application that created the audio stream, triggering the application to shut down the audio stream.

[0061] In one implementation, during the process of closing an audio stream, the management program can trigger the application to close a pre-created audio stream using a fault notification method. For example, after determining that an audio stream exists on the device, the management program can send a fault notification to the currently active application on the device via broadcast notification. This fault notification informs the application of a fault in the target hardware module. Correspondingly, upon receiving the broadcast notification, the application determines that the target hardware module is faulty, can close the audio stream, and synchronously shut down the target hardware module.

[0062] It should be noted that sending a fault notification to the application that creates the audio stream does not indicate that the target hardware module has actually malfunctioned; it is merely used to induce the application that creates the audio stream to close the audio stream in order to shut down the target hardware module.

[0063] In practical applications, some applications have high permissions to seize audio focus, making it impossible to shut down the audio stream by seizing audio focus. Some applications are independent third-party applications and may not shut down the audio stream after receiving a notification from the management program.

[0064] In this embodiment, by inducing the application to close the created audio stream through a fault notification that characterizes a target hardware module failure, the audio stream in the device can be closed simply and quickly, thereby ensuring that the audio stream and the target hardware module can be reliably closed, and thus improving the success rate of the device entering a light sleep mode.

[0065] Optionally, the target hardware module in the device used for processing audio data is turned off, including: After closing the audio stream, determine if there are any abnormal audio streams that have not been closed on the device; If an abnormal audio stream is detected, the hardware abstraction layer in the device is notified to shut down the target hardware module.

[0066] Based on the above examples, after the management program closes the audio stream by sending a broadcast notification to the application that created the audio stream or by preempting the audio focus, it can determine again whether an audio stream exists on the device. The audio stream that exists at this time is an abnormal audio stream that has not been closed.

[0067] like Figure 2 As shown, after determining the existence of an abnormal audio stream, the management program can send a notification to the Hardware Abstraction Layer (HAL) to instruct the HAL to shut down the target hardware module. Correspondingly, upon receiving this notification, the HAL directly shuts down the target hardware modules located in the hardware layer, such as the DSP, speaker, and microphone.

[0068] In practical applications, directly shutting down the target hardware module without closing the audio stream may cause application failure alarms, which in turn may lead to a series of other problems.

[0069] In this embodiment, the audio stream is first shut down, and then when it is determined that there is an abnormal audio stream that has not been shut down, the hardware abstraction layer is notified to shut down the target hardware module. This can prevent application fault alarms and thus improve the reliability of the device.

[0070] Optionally, the method may further include: If the abnormal audio stream is an audio stream that plays audio data, then the audio data in the abnormal audio stream is written to memory and then discarded through the hardware abstraction layer; Alternatively, if the abnormal audio stream is an audio stream containing recorded audio data, then empty data is sent to the abnormal application that created the abnormal audio stream through the hardware abstraction layer.

[0071] For example, after shutting down the target hardware module, the Hardware Abstraction Layer (HAL) can determine whether the audio stream is for playing audio data or for recording audio data. After determining that the audio stream is for playing audio data, the HAL can request a memory region from the operating system, hereinafter referred to as the first memory region. Upon receiving audio data sent by the abnormal application that created the abnormal audio stream, the HAL can write the received audio data to the first memory region to assist the abnormal application in completing the audio data writing operation. After writing the received audio data to the first memory region, the HAL can discard the audio data written to the first memory region.

[0072] For example, after determining that the audio stream is for recording audio data, the Hardware Abstraction Layer (HAL) can request a memory region from the operating system, hereinafter referred to as the second memory region. The HAL creates empty data in the second memory region; this empty data is all zeros (i.e., silence data). Based on the second memory region, the HAL can add necessary metadata such as the sampling rate, bit depth, and number of channels to the empty data, and then send the empty data including the metadata to the exception application, allowing the exception application to process the empty data.

[0073] It's understandable that after the target hardware module is shut down, the Hardware Abstraction Layer (HAL) cannot obtain audio data from it. In this situation, the HAL sends the empty data containing the relevant metadata of the normal audio data to the malfunctioning application, allowing the target program to process the empty data correctly based on this metadata.

[0074] In practical applications, when playing audio streams, if the audio stream is not closed, the application will continuously call the write interface to send audio data from the audio stream to the hardware abstraction layer. The hardware abstraction layer then sends the audio data to the DSP in the hardware layer for processing, and finally plays it through speakers or headphones. If the hardware abstraction layer directly closes the target hardware module without processing the audio data sent by the application, it may cause the application to throw an error.

[0075] Similarly, for audio streams containing recorded audio data, if the audio stream is not closed, the application will continuously call the read interface to read audio data from the hardware abstraction layer. If the hardware abstraction layer does not provide audio data to the application at this time, it will cause the application to throw an error.

[0076] In this embodiment, for abnormal audio streams used for playing audio data, the audio data in the abnormal audio stream is written to memory and then discarded through the hardware abstraction layer. For abnormal audio streams used for recording audio data, empty data is sent to the abnormal application that created the abnormal audio stream through the hardware abstraction layer. This can prevent abnormal application errors and thus improve the reliability of the device.

[0077] Optionally, the method may further include: The hardware abstraction layer is notified to send a fault notification indicating a failure of the target hardware module to the abnormal application that created the abnormal audio stream, so as to trigger the abnormal application to close the abnormal audio stream.

[0078] Based on the above example, after determining the existence of an abnormal audio stream and notifying the hardware abstraction layer to shut down the target hardware module, the management program or the hardware abstraction layer can send a fault notification to applications (including abnormal applications) that call the write data interface or read data structure. This fault notification is used to inform the abnormal application that the target hardware module has failed. Correspondingly, after receiving the fault notification, the abnormal application determines that the target hardware module has failed. Since the target hardware cannot process audio data due to the failure, the abnormal application will proactively shut down the audio stream.

[0079] It should be noted that sending a fault notification to an abnormal application does not indicate that the target hardware module has actually malfunctioned; it is only used to induce the abnormal application to close the audio stream.

[0080] In this embodiment, while shutting down the target hardware module through the hardware abstraction layer, the abnormal application is notified of the target hardware module failure, causing the abnormal application to shut down the audio stream. This can prevent the abnormal application from continuing to play or record audio data after the target hardware module is shut down, thereby reducing device power consumption and improving device reliability.

[0081] Optionally, the method may further include: Abnormal applications that create abnormal audio streams are flagged so that the device shuts down the target hardware module when the abnormal application is detected running during the process of entering light sleep mode.

[0082] Optionally, the target hardware module in the device used for processing audio data is turned off, including: Identify at least one application currently running on the device; If at least one application includes a pre-tagged application, then the target hardware module is shut down.

[0083] In one implementation, after determining that an unclosed abnormal audio stream exists on the device, the management program can mark the abnormal application that created the abnormal audio stream. For example, the management program can create and maintain a log table. After determining that an unclosed abnormal audio stream exists on the device, the management program can obtain the program identifier of the abnormal application that created the abnormal audio stream. The program identifier can be the package name of the abnormal application. Then, the program program adds the identifier of the abnormal application to the log table to mark the abnormal application.

[0084] Correspondingly, after receiving a switching command, the management program first identifies each currently running application on the device. Then, for each running application, it checks if one or more identifiers in the log table include the application's program identifier. If the program identifier is included, the application is determined to be a pre-marked application, and the audio stream will not be properly shut down when the device enters light sleep mode. At this point, the management program can directly control the shutdown of the target hardware module.

[0085] It should be understood that the above are merely illustrative examples, and specific methods for marking abnormal applications may include, but are not limited to, the examples above.

[0086] In this embodiment, when an abnormal audio stream exists, the abnormal application that created the abnormal audio stream can be marked. Thus, when the device enters light sleep mode again, if it is determined that the abnormal application is running, the target hardware module can be directly shut down. This allows for a quick shutdown of the target hardware module, minimizing interference from any unshutdowned target hardware module during the device's entry into light sleep mode, thereby improving the success rate of entering light sleep mode.

[0087] See Figure 3 , Figure 3 This is a flowchart illustrating a hardware module management method provided in an embodiment of this application. The method can be executed by a management program in the control terminal of the device, and may include the following steps: Step 301: Determine whether a switching instruction has been received.

[0088] For example, after the device is powered on, the management program starts running. During operation, the management program can periodically monitor the device to determine whether the device has received a switching command. The specific form of the switching command may include, but is not limited to, the example above. After determining that the device has received a switching command, the management program executes step 302. If it determines that the device has not received a switching command, it returns to continue executing step 301.

[0089] Step 302: Determine if an audio stream exists in the device.

[0090] Step 303: Turn off the audio stream.

[0091] For example, after determining that the device has received a switching instruction, the management program can monitor whether there is an audio stream in the device. If it is determined that there is an audio stream in the device, step 303 is executed. If it is determined that there is no audio stream in the device, the process is terminated directly.

[0092] For example, upon determining that an audio stream exists on the device, the management program can broadcast a notification to currently running applications on the device, instructing the receiving applications to close the audio stream. Alternatively, upon determining that an audio stream exists on the device, the management program can send notifications to various audio servers within the device's operating system, which in turn send closing notifications to the applications that created the audio stream, instructing each application to close the created audio stream. Alternatively, the management program can be pre-configured to have the highest privileges to acquire audio focus. After determining that an audio stream exists on the device, the management program can preempt audio focus. Once the management program has acquired audio focus, the applications that preemptively acquired audio focus and created the audio stream will release audio focus and close the created audio stream.

[0093] It should be understood that during the process of closing an audio stream, audio streams created by some applications may not close, while audio streams created by other applications may close normally.

[0094] Step 304: Determine if there are any abnormal audio streams that are not closed in the device.

[0095] For example, after executing step 303, the management program detects whether there is an abnormal audio stream that is not closed in the device. If it is determined that there is an abnormal audio stream in the device, step 305 is executed. If it is determined that there is no abnormal audio stream in the device, the process ends directly.

[0096] Step 305: Shut down the target hardware module used to process audio data.

[0097] For example, if an abnormal audio stream is detected in the device, the management program can send a notification to the Hardware Abstraction Layer (HAL) to shut down the target hardware module used for processing audio data. Accordingly, upon receiving the notification, the HAL shuts down the target hardware module used for processing audio data.

[0098] Step 306: Determine whether the abnormal audio stream is used to play audio data.

[0099] For example, for an abnormal audio stream that is not closed, the management program determines whether the audio stream is used to play audio data. If it is used to play audio data, step 307 is executed. If it is not used to play audio data, the abnormal audio stream is determined to be used to record audio data, and step 308 is executed.

[0100] Step 307: Write the audio input from the abnormal audio stream to memory and then discard it.

[0101] Step 308: Send empty data to the abnormal application that created the abnormal audio stream.

[0102] For example, after determining that the abnormal audio stream is an audio stream used to play audio data, the management program can control the hardware abstraction layer to request a first memory region from the operating system. After receiving the audio data sent by the abnormal application that created the abnormal audio stream, the hardware abstraction layer writes the received audio data into the first memory region and then discards the audio data written into the first memory region.

[0103] For example, after determining that the abnormal audio stream is an audio stream used for recording audio data, the management program can control the Hardware Abstraction Layer (HAL) to request a second memory region from the operating system. The HAL creates an empty data in the second memory region, adds necessary metadata such as the sampling rate, bit depth, and number of channels to the empty data, and then sends the empty data including the metadata to the abnormal application, allowing the abnormal application to process the empty data.

[0104] It should be noted that after receiving the switching command, in addition to steps 301-308, the management program will also perform other operations to control the device to enter the light sleep mode, which will not be described in detail in this embodiment.

[0105] The above text combined Figures 1 to 3 The hardware module management method provided in the embodiments of this application is described in detail below; the following will be combined with Figure 4 and Figure 5 The apparatus embodiments of this application are described in detail below. It should be understood that the apparatus in the embodiments of this application can perform the various methods described in the foregoing embodiments of this application, that is, the specific working processes of the various products described below can be referred to the corresponding processes in the foregoing method embodiments.

[0106] See Figure 4 , Figure 4 This is a schematic diagram of the structure of a hardware module management device provided in an embodiment of this application. Figure 4 As shown, the hardware module management device 400 may include: The determination module 401 is used to determine whether a switching instruction has been received, wherein the switching instruction indicates that the device needs to enter a light sleep mode; The shutdown module 402 is used to shut down the target hardware module in the device used for processing audio data if the switching instruction is received.

[0107] Optionally, the shutdown module 402 is also configured to shut down the audio stream if a pre-created audio stream exists in the device before shutting down the target hardware module in the device used for processing audio data.

[0108] Optionally, the shutdown module 402 is specifically used to send a fault notification characterizing a fault in the target hardware module to the application that created the audio stream, so as to trigger the application to shut down the audio stream.

[0109] Optionally, the shutdown module 402 is specifically used to determine whether there is an abnormal audio stream that has not been shut down in the device after the audio stream is shut down; if the abnormal audio stream exists, the hardware abstraction layer in the device is notified to shut down the target hardware module.

[0110] Optionally, the device includes a writing module and a sending module. The writing module is configured to write the audio data in the abnormal audio stream into memory and then discard it through the hardware abstraction layer if the abnormal audio stream is an audio stream playing audio data. The sending module is configured to send empty data to the abnormal application that created the abnormal audio stream through the hardware abstraction layer if the abnormal audio stream is an audio stream recording audio data.

[0111] Optionally, the method further includes: notifying the hardware abstraction layer to send a fault notification characterizing a fault in the target hardware module to the abnormal application that created the abnormal audio stream, so as to trigger the abnormal application to close the abnormal audio stream.

[0112] Optionally, the shutdown module 402 is specifically used to mark the abnormal application that creates the abnormal audio stream, so that when the device enters the light sleep mode, it shuts down the target hardware module when it detects that the abnormal application is running.

[0113] Optionally, the shutdown module 402 is specifically used to determine at least one application currently running in the device; if the at least one application includes a pre-marked application, then the target hardware module is shut down.

[0114] See Figure 5 , Figure 5 This is a schematic diagram of the structure of a device provided in an embodiment of this application. For example... Figure 5 As shown, the device 500 includes a memory 501 and a processor 502, wherein the memory 501 stores executable program code 5011, and the processor 502 is used to call and execute the executable program code 5011 to perform a hardware module management method.

[0115] Furthermore, embodiments of this application also protect a hardware module management device, which may include a memory and a processor, wherein the memory stores executable program code, and the processor is used to call and execute the executable program code to execute a hardware module management method provided in embodiments of this application.

[0116] This embodiment can divide the device into functional modules based on the above method example. For example, each module can correspond to a separate function, or two or more functions can be integrated into one processing module. The integrated module can be implemented in hardware. It should be noted that the module division in this embodiment is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods.

[0117] When the functional modules are divided according to their respective functions, the device may also include a determining module, a replacing module, and a controlling module. It should be noted that all relevant content regarding the steps involved in the above method embodiments can be referenced to the functional descriptions of the corresponding functional modules, and will not be repeated here.

[0118] It should be understood that the device provided in this embodiment is used to execute the above-described hardware module management method, and therefore can achieve the same effect as the above-described implementation method.

[0119] When using integrated units, the device may include a determination module and a control module. Specifically, when the device is applied to an equipment, the processing module can be used to control and manage the equipment's operations. The storage module can be used to support the execution of relevant program code by the equipment.

[0120] The processing module can be a processor or a vehicle body module, which can implement or execute various exemplary logic blocks, modules, and circuits shown in conjunction with the disclosure of this application. The processor can also be a combination of functions that implement computing capabilities, such as a combination of one or more microprocessors, a combination of digital signal processing and microprocessors, etc., and the storage module can be a memory.

[0121] This embodiment also provides a readable storage medium storing program code. When the program code is run on the device, the device executes the above-described related method steps to implement a hardware module management method provided in the above embodiment.

[0122] This embodiment also provides a program product that, when run on a device, causes the device to perform the aforementioned steps to implement a hardware module management method provided in the above embodiment.

[0123] In this embodiment, the device, readable storage medium, program product, or chip are all used to execute the corresponding methods provided above. Therefore, the beneficial effects that can be achieved can be referred to the beneficial effects of the corresponding methods provided above, and will not be repeated here.

[0124] Through the above description of the embodiments, those skilled in the art will understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0125] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another device, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

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

Claims

1. A hardware module management method, characterized in that, The method includes: Determine whether a switching command has been received, the switching command indicating that the device needs to enter a light sleep mode; If the switching instruction is received, the target hardware module in the device used for processing audio data is turned off.

2. The method as described in claim 1, characterized in that, Before shutting down the target hardware module in the device used for processing audio data, the method further includes: If a pre-created audio stream exists in the device, the audio stream is turned off.

3. The method as described in claim 2, characterized in that, The step of shutting down the audio stream includes: A fault notification indicating a failure of the target hardware module is sent to the application that created the audio stream, triggering the application to shut down the audio stream.

4. The method as described in claim 2, characterized in that, The step of shutting down the target hardware module in the device used for processing audio data includes: After closing the audio stream, determine whether there is an abnormal audio stream that has not been closed in the device; If the abnormal audio stream exists, the hardware abstraction layer in the device is notified to shut down the target hardware module.

5. The method as described in claim 4, characterized in that, The method further includes: If the abnormal audio stream is an audio stream that plays audio data, then the audio data in the abnormal audio stream is written to memory and then discarded through the hardware abstraction layer; Alternatively, if the abnormal audio stream is an audio stream containing recorded audio data, then empty data is sent to the abnormal application that created the abnormal audio stream through the hardware abstraction layer.

6. The method as described in claim 4, characterized in that, The method further includes: The hardware abstraction layer is notified to send a fault notification indicating a fault in the target hardware module to the abnormal application that created the abnormal audio stream, thereby triggering the abnormal application to close the abnormal audio stream.

7. The method as described in claim 4, characterized in that, The method further includes: The abnormal application that creates the abnormal audio stream is marked so that the device shuts down the target hardware module when it detects that the abnormal application is running during the process of entering the light sleep mode.

8. The method according to any one of claims 1-7, characterized in that, The step of shutting down the target hardware module in the device used for processing audio data includes: Identify at least one application currently running on the device; If the at least one application includes a pre-tagged application, then the target hardware module is shut down.

9. A hardware module management device, characterized in that, The device includes: The determination module is used to determine whether a switching instruction has been received, wherein the switching instruction indicates that the device needs to enter a light sleep mode; The shutdown module is used to shut down the target hardware module in the device used for processing audio data if the switching instruction is received.

10. A device, characterized in that, The device includes: Memory, used to store executable program code; A processor for calling and running the executable program code from the memory, causing the device to perform the method as described in any one of claims 1 to 8.

Images