Patent Description:
This application relates to the technical field of electronic devices, and in particular, to a battery cover color change method and an electronic device.

Accompanied with the development and popularization of electronic devices, electronic devices such as mobile phones and computers have been inseparable from people's lives, can be seen everywhere in life, and greatly improve people's living standards. The aesthetics of electronic devices, for example, the aesthetics of housings of the electronic devices, directly decide the purchase intention of consumers. At present, the colors of the housings of the electronic devices are generally fixed, and to implement interactions between colors of the appearance of the electronic devices and users, a color change solution may be used for battery covers of the electronic devices, so as to increase the degree of recognition of products.

Known methods and devices for color change of a battery cover are disclosed by <CIT> and <CIT>.

Electrochromism is a phenomenon that optical properties (reflectivity, transmittance, absorption rate, and the like) of a material undergo a stable and reversible color change under the action of an external electric field, which is manifested as a reversible change in color and transparency in the appearance. For example, the electronic device is a mobile phone. A material having an electrochromic property is applied to a rear housing, that is, a battery cover, of the mobile phone, so that the battery cover of the mobile phone can change colors based on playing of an audio in different scenarios. However, audio subsystems in the current widely used Android operating systems are quite complex, and how to adapt an audio subsystem of an electronic device, to enable a battery cover of the electronic device to change colors along with playing of an audio is a problem to be solved.

Embodiments of this application provide a battery cover color change method and an electronic device, which solve the technical problem of driving a battery cover to change colors by using an audio playing process of the electronic device, to enable the battery cover of the electronic device to change colors along with playing rhythms of an audio, thereby meeting use requirements of a plurality of scenarios.

To achieve the foregoing objective, the embodiments of this application provide the following technical solutions:.

In a first aspect, as defined in claim <NUM>, this application provides a battery cover color change method, applicable to an electronic device. The electronic device includes an application and a battery cover. The method includes:.

The method is characterized in that the first audio data sequentially passes through an application layer, an application framework, an audio hub service layer, an audio hardware abstraction layer, and a kernel layer in the audio playing process; wherein the kernel layer comprises a battery cover virtual device and an audio virtual device, wherein the battery cover virtual device and the audio virtual device are independent of each other.

By the battery cover color change method applicable to an electronic device provided in the embodiments of this application, the battery cover of the electronic device can change colors along with playing rhythms of an audio, and the technical problem of driving the battery cover to change colors by using the audio playing process of the electronic device is solved.

In a possible implementation, the application is an incoming call application, an alarm application, or a calendar application.

In this embodiment, any one of the incoming call application, the alarm application, or the calendar application in the electronic device can enable a battery cover color change function when an audio needs to be played, so as to provide a reminder to a user from two sensory dimensions, auditory and visual.

In a possible implementation, before sending the audio data by the application, whether a battery cover color change switch is in an on state is determined, and the application sends an audio control signal to the audio hardware abstraction layer, where the audio control signal is used for configuring a battery cover path, and the battery cover path is used for transmitting and processing the color change data.

In this embodiment, by setting on and off states of the battery cover color change switch, the user can control whether to enable the battery cover color change function, thereby increasing the operation flexibility of the electronic device. Further, after determining that the battery cover color change switch is in the on state, the application sends an audio control signal to configure a battery cover color change path, so as to prepare for subsequent playing of the audio data and sending of the color change data of the battery cover.

In a possible implementation, the sending, by the application, first audio data to an audio playing process specifically includes:.

In a possible implementation, in the audio playing process, the obtaining color change data based on the first audio data further includes generating color change data based on the audio data by using a conversion algorithm.

In a possible implementation, the conversion algorithm is an audio rhythm identification algorithm, to enable rhythms of the color change data to correspond to the rhythms of the first audio data.

In a possible implementation, in the audio playing process, the obtaining the color change data based on the first audio data further includes obtaining, by a conversion algorithm module in the audio hardware abstraction layer, the color change data based on the second audio data, and outputting the color change data to a battery cover virtual device in the kernel layer.

In this embodiment, the conversion algorithm used specifically refers to an audio rhythm identification algorithm. In the audio playing process, color change data is obtained in real time based on audio data, so that color change data corresponding to rhythms of audio data to be played can be obtained, to enable the battery cover to change colors along with the rhythms of the audio data driven by the color change data.

In a possible implementation, in the audio playing process, the obtaining color change data based on the first audio data further includes: the first audio data including the color change data, where the color change data is manually edited and combined into the first audio data in advance; and splitting the color change data from the first audio data by using a splitting algorithm.

In a possible implementation, in the audio playing process, the obtaining color change data based on the first audio data further includes splitting, by an audio splitting module in the audio hardware abstraction layer, the second audio data into the third audio data and the color change data, outputting the third audio data to the audio virtual device in the kernel layer, and outputting the color change data to a battery cover virtual device in the kernel layer.

In a possible implementation, the color change data is obtained from the first audio data that has undergone an audio rhythm identification algorithm.

In this embodiment, the color change data corresponding to the audio data is obtained in advance by using a conversion algorithm, is combined with the audio data by manual editing, and then is split out in the audio playing process, to obtain the color change data, to enable the battery cover to change colors along with the rhythms of the audio data driven by the color change data.

In a possible implementation, in the audio playing process, the obtaining color change data based on the first audio data further includes storing the color change data in the electronic device, where the audio control signal includes an index corresponding to the first audio data, and loading the color change data based on the index, where the color change data corresponds to the first audio data.

In a possible implementation, in the audio playing process, the obtaining color change data based on the first audio data further includes loading, by a loading module in the audio hardware abstraction layer, the color change data based on the index, and transmitting the color change data to an audio distribution module in the audio hardware abstraction layer.

In a possible implementation, if the first audio data is external audio data, default color change data corresponding to a default index is loaded.

In this embodiment, the color change data is stored in the electronic device in advance, the corresponding color change data is loaded based on the audio data to be played, and the audio data and the color change data are separately transmitted through an audio playing path, to enable the battery cover to change colors based on the rhythms of the audio data driven by the color change data. In addition, when the user chooses to play external audio data, the battery cover color change function can also be realized.

In a second aspect, this application further provides an electronic device as defined in claim <NUM>. The electronic device includes: one or more processors, a memory, and a battery cover. The memory is configured to store program code. The one or more processors are configured to run the program code, to cause the electronic device to perform the battery cover color change method according to the first aspect or any possible implementation of the first aspect.

In a third aspect, according to a non-claimed embodiment, this application further provides a computer-readable storage medium. The computer-readable storage medium includes instructions, and the instructions, when run on an electronic device, cause the electronic device to perform the battery cover color change method according to the first aspect and any possible implementation of the first aspect.

In the specification, claims, and accompanying drawings of this application, the terms "first", "second", "third", and the like are intended to distinguish between different objects but do not indicate a particular order.

In the embodiments of this application, the terms "exemplary" or "for example" are used for giving an example, an illustration, or a description. Any embodiment or design scheme described as an "exemplary" or "for example" in the embodiments of this application should not be explained as being more preferred or having more advantages than another embodiment or design scheme. Exactly, use of the terms, such as "exemplarily" or "for example", is intended to present a related concept in a specific manner.

An embodiment of this application provides a battery cover color change method. The method can be applicable to an electronic device. The electronic device may be any electronic device such as a mobile phone, a wearable device, a tablet computer, or a laptop, which is not limited in this embodiment of this application. For example, the electronic device is a mobile phone.

<FIG> illustrates a rear cover, that is, a battery cover, of an electronic device according to an embodiment of this application. For example, the electronic device is a mobile phone. An electrochromic material is applied to a battery cover of the mobile phone. For example, the electrochromic material is applied in areas <NUM> such as solid letters O, R, H, and the like, and in outlines <NUM> such as hollowed letters O, R, H, and the like. In a particular audio playing scenario, for example, in scenarios such as an incoming call ringing, an alarm ringing, or a schedule reminder, according to the battery cover color change method of this embodiment of this application, the areas to which the electrochromic material is applied as shown in the figure change colors along with playing of an audio when the electronic device plays the audio. In other words, the electrochromic material in these areas may change colors driven by the color change data. A battery cover color change frequency may vary depending on rhythms of the audio played. For example, the color of the battery cover may change from blue to white and then from white to blue, or switch between blue and white, and so on, along with playing of the audio. An original color and an electrochromic color of the battery cover depend on properties of the material of the battery cover and the electrochromic material, which are not limited herein.

In addition, since the battery cover color change method of this embodiment of this application is used, the electronic device may obtain the color change data corresponding to the audio data by using the audio data played, to enable the color change frequency of the battery cover to correspond to the rhythms of the audio data, and the electrochromic properties can achieve millisecond response, so that the color of the battery cover can be quickly changed to a degree synchronized with playing of the audio. In this way, in scenarios such as an incoming call ringing, an alarm ringing, and a schedule reminder, the electronic device can further visually prompt a user through a color change of the battery cover in addition to audibly prompting the user in a manner of playing an audio, thereby implementing user experience in a plurality of sensory dimensions.

Further, during color change of the battery cover having a color change function, the battery cover itself does not emit light, but the color of the battery cover changes. Therefore, in a dark environment, the battery cover color change function does not cause light interference to the user. In addition, the color change area on the battery cover may not be limited to the pattern shown in this embodiment of this application, and the electrochromic material may be arranged in various patterns and text forms to appear when the battery cover changes color, so as to achieve a cool and personalized effect.

<FIG> is a schematic structural diagram of an electronic device according to an embodiment of this application. The electronic device may include a processor <NUM>, a display screen <NUM>, an external memory interface <NUM>, an internal memory <NUM>, a speaker <NUM>, and a battery cover <NUM>. The battery cover <NUM> may include an electrochromic material <NUM> and a control circuit <NUM>.

It may be understood that the structure shown in this embodiment constitutes no specific limitation on the electronic device. In some other embodiments, the electronic device may include more or fewer components than those shown in the figure, or some components may be combined, or some components may be split, or components are arranged in different manners. The components shown in the figure may be implemented by hardware, software, or a combination of software and hardware.

The processor <NUM> may include one or more processing units. For example, the processor <NUM> may include an application processor (application processor, AP), a modulation and demodulation processor, a graphics processing unit (graphics processing unit, GPU), an image signal processor (image signal processor, ISP), a controller, a video codec, a digital signal processor (digital signal processor, DSP), a baseband processor, and/or a neural-network processing unit (neural-network processing unit, NPU). Different processing units may be separate devices, or may be integrated into one or more processors.

The external memory interface <NUM> may be configured to connect to an external storage card such as a micro SD card, to expand a storage capability of the electronic device. The external storage card communicates with the processor <NUM> by using the external memory interface <NUM>, to implement a data storage function, such as storing a file such as a music or a video in the external storage card.

The internal memory <NUM> may be configured to store computer-executable program code. The executable program code may include an operating system, an application (such as an audio playing function) required by at least one function, and the like. The executable program code includes instructions, and the processor <NUM> runs the instructions stored in the internal memory <NUM> to cause the electronic device to execute various functional applications and data processing. For example, in this embodiment, the processor <NUM> executes instructions stored in the internal memory <NUM> to cause the electronic device to perform the battery cover light-emitting control method provided in this embodiment of this application.

The internal memory <NUM> may include a program storage area and a data storage area. The data storage area may store data (for example, audio data, an address book, and the like) and the like created when the electronic device is used. The program storage area may be configured to store computer-executable program code. In addition, the internal memory <NUM> may include a high-speed random access memory, or may include a non-volatile memory such as at least one disk storage memory, a flash memory, or a universal flash storage apparatus (universal flash storage, UFS).

The speaker <NUM> may be configured to play an audio, for example, an incoming call ringtone, an information prompt tone, a music, and the like. In particular, the speaker <NUM> may be equipped with a smart power amplifier SmartPA, to which a feedback for an output signal is added, so that the sound quality can be improved to a particular extent while protecting a sounding device.

The battery cover <NUM> may include an electrochromic material <NUM> and a control circuit <NUM>. The control circuit <NUM> is connected to the electrochromic material <NUM>, so that the electrochromic material <NUM> in the battery cover <NUM> can change colors under the control of the control circuit <NUM>.

In addition, an operating system runs on the foregoing components, for example, the Android open source operating system developed by Google, the Windows operating system developed by Microsoft, the iOS operating system developed by Apple, and the like. An application may be installed and run on the operating system.

The operating system of the electronic device may use a layered architecture, an event-driven architecture, a microkernel architecture, a micro service architecture, or a cloud architecture. In this embodiment of this application, the software structure of the electronic device is exemplarily described by using an Android system having a layered architecture as an example.

In the hierarchical architecture, software is divided into several layers, and each layer has a clear role and task. The layers communicate with each other through a software interface. For example, in some embodiments, the Android system is divided into: an application layer, an application framework layer, a hardware abstraction layer, and a kernel layer.

It should be noted that although this embodiment of this application is described by using an Android system as an example, the basic principle is also applicable to an electronic device based on an operating system such as iOS or Windows.

To enable the electronic device to implement the function that the battery cover changes colors along with playing of an audio by using an audio playing process, the audio playing process of the electronic device is improved and adapted in this embodiment of this application. The battery cover color change method according to this embodiment of this application is further described in detail below.

<FIG> is a diagram of a menu for setting a color change function in an electronic device according to an embodiment of this application. Referring to <FIG>, a first level menu entry may be provided for the color change function in a "Settings" <NUM> menu of the electronic device. For example, a color change function may be regarded as pertaining to "Self-Study and Auxiliary Functions", and the color change function may be classified as "Auxiliary Functions" <NUM>. Alternatively, the color change function may be classified into other functions.

A next level of menu may be entered by clicking/tapping on the entry "Auxiliary Functions" <NUM>, as shown in <FIG> is a secondary diagram of a menu for setting a color change function in an electronic device according to an embodiment of this application. Referring to <FIG>, the "Auxiliary Functions" may include various categories such as a barrier-free <NUM>, a one-hand mode <NUM>, and a quick start & gesture <NUM>. An entrance of the color change function may be set below the entry "Barrier-Free" <NUM>. For example, the color change function may be named as "Rhythmic Shine" <NUM>, or the color change function may be named in other ways, which is not limited herein. In some implementations, the color change function may be set above other functions as a characteristic function, so that a user can easily find the newly added entry "Rhythmic Shine" <NUM> after opening the auxiliary function menu, to try and use the color change function more easily. In other implementations, the color change function may also be placed at any position in the auxiliary function menu, which is not limited herein. In addition, the entry "Rhythmic Shine" may be included in the menu "Setting" <NUM> in <FIG>, to be in a same level as the "Auxiliary Functions" <NUM>, which is not limited herein.

In <FIG>, the entry "Rhythmic Shine" <NUM> may be clicked/tapped to enter a next level of menu, in which the color change function can be set in detail, as shown in <FIG> is a diagram of an interface for setting a color change function in an electronic device according to an embodiment of this application. Referring to <FIG>, a switch of the color change function may be set for each application in an interface of <FIG>.

For an incoming call application, an incoming call reminder color change switch <NUM> is turned on, and in addition, incoming calls from which contacts and for which the color change function is enabled may be further selected in a next level of submenu. For example, an entry "Contacts" <NUM> is clicked/tapped on to enter a next level of submenu, in which enabling the color change function for incoming calls from all contacts, or enabling the color change function for incoming calls of particular contacts may be selected.

During selection of the particular contacts, any number of contacts may be added; or, a definite number of contacts may be added, for example, a maximum of three contacts, to highlight the particularity of incoming calls from these contacts, so as to achieve the purpose of helping a user to identify a contact of an incoming call more clearly. In a subsequent case, if the number of contacts selected to be added is greater than three, the electronic device may display "Unable to add the contact(s)". If the number of contacts selected to be added is less than or equal to three, the electronic device displays "Successfully added the contact(s)". The number "three" herein is used merely as an example but not a limitation.

For an alarm application, in this embodiment of this application, by turning on an alarm reminder color change switch <NUM>, the electronic device can be enabled to implement synchronous color change of the battery cover when the alarm rings. In other embodiments of this application, in a case that the alarm reminder color change switch <NUM> is turned on, which alarm for which the color change function is enabled may be further selected. For example, enabling the color change function for an alarm <NUM> at <NUM>:<NUM> AM may be selected, so that a user can also see the color change of the battery cover while hearing a ringtone, so as to achieve an auditory-and-visual dual reminder effect.

For a calendar application, in this embodiment of this application, in a case that a schedule reminder color change switch <NUM> of the electronic device is turned on, the electronic device may implement a battery cover color change function while playing an audio to notify a user of a particular schedule.

The above are only examples to describe the method for setting a color change switch for an application in the electronic device, it should be understood that a color change switch can be set for another application.

In another possible implementation, states of color change switches may also be set inside applications, and the manner of setting a color change switch is not limited in this application.

The following embodiments are discussed in a case that the color change switches of the applications are on.

<FIG> is a software flow block diagram of a battery cover color change method according to an embodiment of this application.

An application layer (application layer) may include a series of application packages. The application packages may include an incoming call reminder, an alarm, a schedule reminder, and the like. Each application may initiate playing of an audio in different scenarios and drive a battery cover to change colors at the same time.

An application framework (framework, FWK) layer provides an application programming interface (application programming interface, API) and a programming framework for an application at an application layer. The application framework layer may include a window manager, a call manager, a resource manager, an audio player, and the like.

A hardware abstraction layer (hardware abstract layer, HAL) is an interface layer between a kernel of an operating system and a hardware circuit, and its purpose is abstracting hardware. In the HAL, details of a hardware interface of a particular hardware platform are hidden, which provides a virtual hardware platform for the operating system, so that the operating system has a hardware independence, and that the operating system can be portable among a plurality of hardware platforms.

A kernel (kernel) layer is a layer between hardware and software.

When processing an audio, an operating system of a mobile phone may be divided into an application layer, an application framework layer, an audio hub service layer (AudioFlinger), a hardware abstraction layer, and a kernel layer according to processing logic of an audio service.

The audio hub service layer is an audio hub in an Android system, and is also a system service that plays the role of supporting (providing an access interface for an upper layer) and enabling (managing an audio device by using a hardware abstraction layer).

Referring to <FIG>, in a scenario such as an incoming call ringing, an alarm ringing, or a schedule reminder, an application (for example, an incoming call application <NUM>, an alarm application <NUM>, or a calendar application <NUM>) in an application layer <NUM> first sends an audio control signal <NUM> to an audio hardware abstraction layer <NUM>, to notify the audio hardware abstraction layer <NUM> that a battery cover color change function needs to be enabled for playing of audio data this time. The audio hardware abstraction layer <NUM>, after receiving the audio control signal <NUM>, configures a battery cover color change path, for example, turning on an audio virtual device (PCM) and a color change data path corresponding to color change data, and the like. The color change data path enables the color change data and the audio data to be transmitted independently of each other in an audio playing process without interfering with each other. In another aspect, the application may send an audio data stream (as indicated by wide arrows in <FIG>) to the application framework layer <NUM>. The audio data stream carries audio data to be played <NUM>.

The application framework layer <NUM> may initialize an audio player MediaPlayer <NUM> in an electronic device upon detection of the audio data <NUM>. The audio data <NUM> may then be decoded by an audio codec MediaCodec <NUM> (the decoding process is a software decoding process, and may therefore be referred to as soft decoding), to obtain decoded audio data <NUM>. The audio data <NUM> is transferred to an audio hub service layer AudioFlinger <NUM>.

The audio hub service layer <NUM> processes the decoded audio data <NUM> to obtain audio data <NUM>. The processing content includes but is not limited to: resampling (Resample), sound effect applying (Apply Effect), volume adjusting (Adjust Volume), and sound mixing (Mixer). The processed audio data <NUM> may then arrive at the audio hardware abstraction layer AudioHal <NUM> for further processing.

The audio hardware abstraction layer <NUM> may configure a battery cover path upon receipt of the audio control signal <NUM> from the application layer <NUM>, so that the battery cover path is configured to transmit and process the color change data. In this case, the audio hardware abstraction layer <NUM> needs to determine whether the audio data <NUM> is to be played by a speaker of the electronic device. If the electronic device is connected to an external device such as a headset or a Bluetooth speaker, so that the audio data is to be played by the headset or the Bluetooth speaker instead of by the speaker of the electronic device, the audio hardware abstraction layer <NUM> may not configure the battery cover path, that is, does not turn on the audio virtual device (PCM) and the color change data path corresponding to the color change data. In this case, the audio data only arrives at the external device through an audio data path for playing, and the battery cover does not change colors. Upon determining that the audio data is to be played by the speaker of the electronic device, the audio hardware abstraction layer <NUM> configures the battery cover path, specifically in the following.

<FIG> is a software-and-hardware flow block diagram following the battery cover color change method of <FIG> according to this embodiment of this application. Referring to <FIG>, after the audio data <NUM> arrives at the audio hardware abstraction layer <NUM>, the audio data <NUM> may be sent by an audio distribution module <NUM> to an audio virtual device (PCM) <NUM> in a kernel layer <NUM>. The audio virtual device <NUM> in the kernel layer <NUM> may be configured to perform digital-to-analog conversion on the audio data <NUM> to generate audio data <NUM>, and then send the audio data <NUM> to a hardware device (for example, a speaker <NUM>) in the hardware layer <NUM> for playing.

In another aspect, an audio distribution module <NUM> in the audio hardware abstraction layer <NUM> may further send the audio data <NUM> to a conversion algorithm module <NUM> for processing, to generate color change data <NUM>. The generated color change data <NUM> may be sent to a battery cover virtual device <NUM> in the kernel layer <NUM>, to drive the battery cover to change colors. Similarly, the battery cover virtual device <NUM> in the kernel layer <NUM> may perform digital-to-analog conversion on the color change data <NUM>, to generate color change data <NUM>, and then send the color change data <NUM> to a battery cover <NUM> in a hardware layer <NUM>, to drive the battery cover <NUM> to change colors.

The conversion algorithm module <NUM> may convert the audio data <NUM> into the color change data <NUM> by using a plurality of forms of conversion algorithms. For example, the conversion algorithm may be an audio rhythm identification (on-site detection) algorithm. In an implementation, the conversion algorithm module <NUM> identifies rhythmic changes of the audio data by using an amplitude difference mean curve of the audio data <NUM>, so as to generate the color change data <NUM> based on the rhythmic change thereof.

The generation process of the color change data <NUM> is described in detail below with reference to <FIG> is a curve graph of audio data according to an embodiment of this application.

In <FIG>, an abscissa x of a graph <NUM> may represent sampling time points for the audio data. Specifically, numerals on the abscissa (for example, numerals <NUM>, <NUM>, and the like) represent only relative numbers of sampling time points, not absolute sampling moments. For example, at a sampling rate <NUM>, <NUM> sampling points may be obtained within <NUM>. There are four curves <NUM>-<NUM> in the graph <NUM>, and for different curves, an ordinate y of the graph <NUM> may separately represent different meanings.

In the graph <NUM>, a coordinate y may represent an amplitude value of the audio data. Therefore, the curve <NUM> may be regarded as being obtained by sampling the amplitude value of the audio data at a fixed time interval, and thus the curve <NUM> may be referred to as an amplitude curve <NUM> of the audio data.

It can be seen that a position of the amplitude curve <NUM> is relatively high, that is, amplitude values of all sampling points thereof are relatively large. An amplitude value of the audio data may be affected by a volume at which the audio data is played by the electronic device. A larger volume at which the audio data is played by the electronic device indicates a larger amplitude value of the audio data and further indicates a higher position of the amplitude curve <NUM> in <FIG>. If the color change data is generated based on the amplitude curve <NUM> of the audio data, that is, if an amplitude threshold is set, the color change data is emitted when the amplitude value of the audio data is higher than the amplitude threshold, and the color change data is not emitted when the amplitude value of the audio data is less than the amplitude threshold, the following problems may occur:.

When the volume at which the audio data is played by the electronic device is relatively large, the position of the amplitude curve <NUM> of the audio data may be relatively high, amplitude values of the amplitude curve <NUM> may all be greater than the amplitude threshold, and as a result, the electronic device may always emit color change data during playing of the audio data. From the perspective of a user, the battery cover of the electronic device may consistently be in a second color state during ringing. On the contrary, when the volume at which the audio data is played by the electronic device is relatively small, the position of the amplitude curve <NUM> of the audio data may be relatively low, amplitude values of the amplitude curve <NUM> may all be less than the amplitude threshold, and as a result the electronic device cannot emit color change data during playing of the audio data. From the perspective of a user, the battery cover of the electronic device may not change colors during ringing, that is, the battery cover color change function is not implemented. To avoid such a situation, it is necessary to set a universal standard for generating color change data regardless of the volume of the electronic device.

In this embodiment of this application, a difference between amplitude values of two adjacent sampling time points is calculated based on the amplitude curve <NUM> of the audio data, to obtain an amplitude difference curve <NUM> as shown in <FIG>. For the amplitude difference curve <NUM>, a coordinate y of the graph <NUM> represents an amplitude difference. Therefore, by extracting differences of the amplitude curve <NUM>, the influence of the volume at which the audio data is played by the electronic device on generation of the color change data can be eliminated. It can be seen from the amplitude difference curve <NUM> that if a difference between amplitude values of two successive sampling time points in the amplitude curve <NUM> is relatively large, spikes may appear in the amplitude difference curve <NUM>, for example, spikes <NUM> and <NUM>; if amplitude values of two successive sampling time points in the amplitude curve <NUM> are close to each other, a data point close to zero is obtained in the amplitude difference curve <NUM> even if the amplitude values at the two sampling time points are large in the amplitude curve <NUM>. In this way, regardless of the volume at which the audio data is played by the electronic device, the amplitude difference curve <NUM> of the audio data can reflect a relative change of the amplitude values at different sampling time points in the audio data, and a generation rule of the color change data is designed by using the relative change of the amplitude values, which helps to obtain a conversion algorithm irrelevant of the type and volume of the audio data.

In the amplitude difference curve <NUM>, the "spikes" therein may be identified as rhythm points, for example, the spikes <NUM> and <NUM> and the like may be identified as rhythm points. It can be seen that the amplitude differences of the audio data at the rhythm points are large. In the conversion algorithm, it may be specified that the electronic device sends a color change signal at the spikes of the audio data and does not send a color change signal at a non-spike area, so that the battery cover of the electronic device can appear that: during playing of the audio data by the electronic device, the battery cover changes colors at a rhythm point, and the battery cover does not change colors at a non-rhythm point, presenting an effect that the battery cover of the electronic device flickers and changes colors along with the rhythms of the audio data.

Further, in the conversion algorithm in this embodiment of this application, a rhythm point may be identified by using an amplitude threshold, that is, when the amplitude difference curve <NUM> is greater than a set amplitude threshold, the sampling time point may be identified as a rhythm point. However, if the amplitude threshold used to identify the rhythm point is a fixed value, there may still be the situation discussed above in actual applications that either the battery cover is always changing colors or the battery cover cannot change colors.

In this embodiment of this application, the following method may be used to set the amplitude threshold, so as to overcome the above defects, thereby identifying the rhythm point more accurately. As shown in <FIG>, a mean value of the amplitude difference curve <NUM> within a particular time interval is obtained. For example, the time interval is <NUM>. A mean value of amplitude differences of the amplitude difference curve <NUM> within every <NUM> is obtained, to obtain an amplitude difference mean curve <NUM>, as indicated by the curve <NUM> in <FIG>. A data point on the amplitude difference mean curve <NUM> may be considered as an amplitude threshold at the sampling time point.

At a moment, that is, at a sampling time point, a sampling time point at which the amplitude difference in the amplitude difference curve <NUM> is greater than the amplitude threshold in the amplitude difference mean curve <NUM> may be identified as a rhythm point of the audio data. In the conversion algorithm in this embodiment of this application, it may be specified that: color change data is sent at each rhythm point for driving the battery cover to change colors. When the amplitude difference in the amplitude difference curve <NUM> falls back to less than the amplitude threshold in the amplitude difference mean curve <NUM>, the sending of the color change data is stopped. A curve <NUM> in the graph <NUM> represents a color change signal curve generated by using the above conversion algorithm. An ordinate y of the color change signal curve represents a signal intensity. In some embodiments, the color change data is PCM format audio data.

By determining the amplitude threshold by using the amplitude difference mean curve <NUM>, the process of determining an amplitude threshold can be applicable to a plurality of types of audio data, so as to identify a rhythm point of the audio data more accurately, so that color change data of the battery cover can be generated based on the rhythm point, thereby achieving an effect that the battery cover of the electronic device flickers and changes colors along with playing rhythms of the audio data.

From the perspective of a user, for example, during ringing of the electronic device, the battery cover of the electronic device may change colors at rhythm points of a ringtone. If the ringtone is a soothing music, rhythm points identified by using the conversion algorithm are more dispersed temporally, and a color change frequency of the battery cover is relatively low; if the ringtone is a rapid music, rhythm points identified by using the conversion algorithm are more intensive temporally, and a color change frequency of the battery cover is relatively high.

Therefore, the color change data <NUM> can be generated based on the audio data <NUM> by the conversion algorithm module <NUM> provided in the audio hardware abstraction layer <NUM>. By appropriately selecting a specific conversion algorithm used by the conversion algorithm module <NUM>, influence of the volume at which the audio data is played by the electronic device on the generation of the color change data can be avoided, and the rhythm points of the audio data can be identified more effectively.

Again referring to <FIG>, the conversion algorithm module <NUM> sends the generated color change data <NUM> to the battery cover virtual device <NUM> in the kernel layer <NUM>. A particular battery cover virtual device <NUM> may be designated for the color change data <NUM>, and the battery cover virtual device <NUM> may represent a battery cover device <NUM> in the hardware layer <NUM>. In the kernel layer <NUM>, the battery cover virtual device <NUM> and the audio virtual device <NUM> are independent of each other, and the audio data <NUM> and the color change data <NUM> can be transmitted independently of each other, so that interference therebetween can be avoided.

In the kernel layer <NUM>, the audio data <NUM> is further processed to form the audio data <NUM>, and the audio data <NUM> and the color change data <NUM> are separately sent to an audio digital signal processor ADSP <NUM> in the hardware layer <NUM>.

The audio digital signal processor ADSP <NUM> further processes the audio data <NUM> to obtain audio data <NUM>, and the color change data <NUM> is transparently transmitted through the ADSP <NUM>, so that the audio data <NUM> and the color change data <NUM> can be respectively sent to actual hardware components by the ADSP <NUM>. Specifically, the audio data <NUM> may be obtained from the audio data <NUM> after being processed by the ADSP <NUM>, the audio data <NUM> may be sent to a smart power amplifier SmartPA <NUM>, to undergo digital-to-analog conversion by the SmartPA <NUM>, so as to generate final audio data <NUM>, and the final audio data <NUM> is sent to the speaker <NUM> for playing.

In another aspect, the color change data <NUM> may be sent to the codec <NUM>, so that the color change data <NUM> can be generated through digital-to-analog conversion, and the color change data <NUM> may be a <NUM> sine wave signal. The color change data <NUM> may be sent to the battery cover <NUM> to drive the battery cover <NUM> to change colors. Therefore, the audio playing process of the electronic device is used, so that the color change data of the battery cover is generated and sent during playing of the audio data by the electronic device, to enable the battery cover of electronic device to change colors along with the playing of the audio data.

<FIG> is a software flow block diagram of another battery cover color change method according to an embodiment of this application. This embodiment differs from Embodiment <NUM> in that: in this embodiment, the audio data may be manually edited in advance, and the color change data of the battery cover and the audio data are combined into source audio data, to be transmitted through the audio playing process. In the hardware abstraction layer, the color change data is split from the source audio data, and then sent to the battery cover in the hardware layer to drive the battery cover to change colors.

Referring to <FIG>, in a scenario such as an incoming call ringing, an alarm ringing, or a schedule reminder, an application (for example, an incoming call application <NUM>, an alarm application <NUM>, or a calendar application <NUM>) in an application layer <NUM> first sends an audio control signal <NUM> to an audio hardware abstraction layer <NUM>, to notify the audio hardware abstraction layer <NUM> that a battery cover color change function needs to be enabled for playing of audio data this time. The audio hardware abstraction layer <NUM>, upon receipt of the audio control signal <NUM>, configures a battery cover color change path, for example, turning on an audio virtual device (PCM) and a color change data path corresponding to color change data, and the like. In another aspect, the application may send an audio data stream (as indicated by wide arrows in <FIG>) to the application framework layer <NUM>. The audio data stream may carry to-be-played source audio data <NUM>.

The source audio data <NUM> may include audio data to be played by a speaker and color change data for driving the battery cover to change colors. For example, the color change data may be obtained by converting the audio data by using a conversion algorithm, and the conversion algorithm may be, for example, the conversion algorithm described in Embodiment <NUM>. In other implementations, the conversion algorithm may also be a conversion algorithm in another form. In addition, in other implementations, the color change data may also be color change data capable of causing the battery cover to change colors at a fixed frequency, and color change data corresponding to different audio data may have different color change frequencies. The form of the color change data is not limited herein.

The audio data and the color change data may be manually edited in advance, so that audio data and the color change data are combined together to form the source audio data to be stored in a memory of the electronic device. When an application needs to play an audio, the source audio data may be sent to the application framework layer <NUM>.

The application framework layer <NUM> may initialize an audio player <NUM> in the electronic device upon detection of the source audio data <NUM>. Then, the source audio data <NUM> may be decoded by an audio codec <NUM> (the decoding process is a software decoding process, and may therefore be referred to as soft decoding), to obtain decoded source audio data <NUM>. The decoded source audio data <NUM> is transferred to the audio hub service layer <NUM>.

In the audio hub service layer <NUM>, the audio data in the decoded source audio data <NUM> is processed, and processing content includes but is not limited to: resampling (Resample), sound effect applying (Apply Effect), volume adjusting (Adjust Volume), and sound mixing (Mixer). The color change data in the source audio data <NUM> may not be processed in the audio hub service layer <NUM>.

<FIG> is a schematic diagram of an audio data processing process according to an embodiment of this application. In <FIG>, the source audio data <NUM> from the application framework layer <NUM> is processed at the audio hub service layer <NUM>. As shown in <FIG>, the source audio data <NUM> from the application framework layer <NUM> generally includes three data channels (channels): A white box on the left and a gray box in the middle may represent left and right channel data of the audio data, respectively, and a black box on the right may represent color change data added through manual editing. The source audio data <NUM> may be sent in units of cycles. One white box, one gray box, and one black box may serve as a group to represent one source audio data cell. One cycle in the source audio data <NUM> may include a plurality of source audio data cells. In <FIG>, for example, one cycle in the source audio data is used. The cycle may include three source audio data cells <NUM>, <NUM>, and <NUM>, and data channels in the source audio data cells are numbered <NUM>, <NUM>, and <NUM>, respectively. In this way, left and right channel data of the color change data are aligned with those of the audio data temporally.

For the audio hub service layer <NUM>, after receiving one cycle of source audio data <NUM> from the application framework layer <NUM>, the audio hub service layer <NUM> may first perform rearrangement <NUM> on left channel data (white boxes <NUM>-<NUM>), right channel data (gray boxes <NUM>-<NUM>), and color change data (black boxes <NUM>-<NUM>) in the three source audio data cells <NUM>, <NUM>, and <NUM>. Specifically, the rearrangement <NUM> may include: picking up color change data <NUM>-<NUM> from the source audio data cells <NUM>-<NUM> and sequentially arranging the color change data <NUM>-<NUM> at the end of the entire source audio data of the cycle, to obtain source audio data <NUM>. As shown in <FIG>, after the rearrangement, all the color change data (black boxes <NUM>-<NUM>) in the source audio data <NUM> are sequentially located at the end of the source audio data <NUM>.

Then, processing <NUM> is performed on the left channel data and the right channel data arranged in front, that is, the left channel data and the right channel data in each of the source audio data cells <NUM>-<NUM> represented by a white box <NUM>, a gray box <NUM>, a white box <NUM>, a gray box <NUM>, a white box <NUM>, and a gray box <NUM> are processed. The processing is similar to that described above, including but not limited to: resampling, sound effect applying, volume adjusting, and sound mixing, to then obtain processed left channel data and right channel data, which are respectively represented by white dotted line boxes and gray dotted line boxes. At the same time, the color change data (black boxes <NUM>-<NUM>) in each source audio data cell may be kept unchanged. In this way, scrambled source audio data <NUM> can be obtained. In the scrambled source audio data <NUM>, the processed left channel data and the processed right channel data are located in front of the color change data.

Next, further rearrangement <NUM> may be performed on the left channel data, the right channel data, and the color change data in the scrambled source audio data <NUM>. Specifically, the further rearrangement <NUM> may include: inserting the color change data <NUM>-<NUM> back into positions, in the corresponding source audio data cells <NUM>-<NUM>, where color change data <NUM>-<NUM> are originally in. For example, the color change data, a black box <NUM>, in the source audio data cell <NUM> is inserted between the processed right channel data (a gray dotted line box <NUM>) in the source audio data cell <NUM> and the processed left channel data (a white dotted line box <NUM>) in the source audio data cell <NUM>, and so on. The source audio data <NUM> may be obtained by subjecting the scrambled source audio data <NUM> to the further rearrangement <NUM>.

Finally, the obtained source audio data <NUM> may be sent to the audio hardware abstraction layer <NUM> for further processing.

Reference is made back to <FIG> is a software-to-hardware flow block diagram following the battery cover color change method of <FIG> according to this embodiment of this application. Referring to <FIG>, after being sent to the audio hardware abstraction layer <NUM>, the source audio data <NUM> may be split by an audio splitting module <NUM>. The audio splitting module <NUM> may split the source audio data <NUM> into audio data <NUM> and color change data <NUM>. For example, for the source audio data shown in <FIG>, the audio splitting module <NUM> may separate the left channel data and the right channel data from the color change data in the source audio data, so that the left channel data and the right channel data form one path of data, and the color change data form another path of data independent of that of the left channel data and the right channel data.

Further, the audio data <NUM> obtained through splitting is sent to an audio virtual device (PCM) <NUM> in the kernel layer <NUM>; and the color change data <NUM> obtained through splitting is sent to a battery cover virtual device (PCM) <NUM> in the kernel layer <NUM>. The audio virtual device <NUM> in the kernel layer <NUM> may be configured to perform digital-to-analog conversion on the audio data <NUM> to generate the audio data <NUM>, so as to send the audio data <NUM> to a hardware device (for example, a speaker <NUM>) in the hardware layer <NUM> for playing. Similarly, the battery cover virtual device <NUM> in the kernel layer <NUM> performs digital-to-analog conversion on the color change data <NUM> to generate the color change data <NUM>, so as to then send the color change data <NUM> to the battery cover <NUM> in the hardware layer <NUM> for displaying.

A particular battery cover virtual device <NUM> may be designated for the color change data <NUM>, and the battery cover virtual device <NUM> represents a battery cover device <NUM> in the hardware layer <NUM>. In the kernel layer <NUM>, the battery cover virtual device <NUM> and the audio virtual device <NUM> are independent of each other, and the color change data <NUM> and the audio data <NUM> can be transmitted independently of each other, so that interference therebetween can be avoided.

The audio digital signal processor ADSP <NUM> further processes the audio data <NUM> to obtain audio data <NUM>, and the color change data <NUM> is transparently transmitted through the ADSP <NUM>, so that the audio data <NUM> and the color change data <NUM> can be respectively sent to actual hardware components by the ADSP <NUM>. Specifically, the audio data <NUM> may be obtained from the audio data <NUM> after being processed by the ADSP <NUM>, the audio data <NUM> may be sent to a smart power amplifier SmartPA <NUM>, to undergo digital-to-analog conversion by the SmartPA <NUM>, so as to generate speaker audio data <NUM>, and the speaker audio data <NUM> is sent to the speaker <NUM> for playing.

In addition, the color change data <NUM> may be sent to the codec <NUM> for digital-to-analog conversion, so that the color change data <NUM> can be generated, and the color change data <NUM> may be a <NUM> sine wave signal. The color change data <NUM> may be sent to the battery cover <NUM> to drive the battery cover <NUM> to change colors. Therefore, the audio playing process of the electronic device is used, so that the color change data is sent during playing of the audio data by the electronic device, to enable the battery cover of electronic device to change colors along with playing rhythms of the audio data.

<FIG> is a software flow block diagram of yet another battery cover color change method according to an embodiment of this application. This embodiment differs from Embodiment <NUM> in that: the color change data is stored in the hardware abstraction layer, and the hardware abstraction layer loads the corresponding color change data based on an index sent by an application, so as to drive the battery cover to change colors.

In this embodiment of this application, audio data to be played by the application is indexed. In other words, audio data in an application such as an incoming call application, an alarm application, or a calendar application is numbered. For example, in a case that ten incoming call ringtones are set in an electronic device, that is, in a case that ten ringtones for a user to select to be played for an incoming call are stored in the electronic device, the ten incoming call ringtones may be indexed, respectively. For example, indexes are <NUM>-<NUM>. Ten pieces of color change data respectively corresponding to the audio data corresponding to the ten ringtones may be stored. For example, the color change data may be obtained by converting the audio data by using a conversion algorithm, and the conversion algorithm may be, for example, the conversion algorithm described in Embodiment <NUM>. In other implementations, the conversion algorithm may also be a conversion algorithm in another form. In addition, in other implementations, the color change data may also be color change data capable of causing the battery cover to change colors at a fixed frequency, and color change data corresponding to different audio data may have different color change frequencies. The form of the color change data is not limited herein. Further, the color change data may be stored in an audio hardware abstraction layer <NUM>.

Referring to <FIG>, in a scenario such as an incoming call ringing, an alarm ringing, or a schedule reminder, an application (for example, an incoming call application <NUM>, an alarm application <NUM>, or a calendar application <NUM>) in an application layer <NUM> first sends an audio control signal <NUM> to an audio hardware abstraction layer <NUM>, to notify the audio hardware abstraction layer <NUM> that a battery cover color change function needs to be enabled for playing of audio data this time. In addition, an index <NUM> of the audio data to be played is sent together with the audio control signal <NUM>. The audio hardware abstraction layer <NUM>, upon receipt of the audio control signal <NUM>, configures a battery cover color change path, for example, turning on an audio virtual device (PCM) and a color change data path corresponding to color change data, and the like. In addition, the audio hardware abstraction layer <NUM> further needs to perform more detailed color change data configuration upon receipt of the index <NUM>, which is to be explained in detail below. In another aspect, the application may send an audio data stream (as indicated by wide arrows in <FIG>) to the application framework layer <NUM>. The audio data stream may carry audio data to be played <NUM>.

The application framework layer <NUM> may initialize an audio player <NUM> in the electronic device upon detection of the audio data <NUM>. Then, the audio data <NUM> may be decoded by an audio codec <NUM> (the decoding process is a software decoding process, and may therefore be referred to as soft decoding), to obtain decoded audio data <NUM>. The audio data <NUM> is transferred to the audio hub service layer <NUM>.

The audio hardware abstraction layer <NUM> may configure a battery cover path upon receipt of the audio control signal <NUM> from the application layer <NUM>. In this case, the audio hardware abstraction layer <NUM> further needs to determine whether the audio data <NUM> is to be played by a speaker of the electronic device. If the electronic device is connected to an external device such as a headset or a Bluetooth speaker, so that the audio data is to be played by the headset or the Bluetooth speaker instead of by the speaker, the audio hardware abstraction layer <NUM> may not configure the battery cover path, that is, does not turn on the audio virtual device (PCM) and the color change data path corresponding to the color change data. In this case, the audio data only arrives at the external device through an audio data path for playing, and the battery cover does not change colors. Upon determining that the audio data is to be played by the speaker of the electronic device, the audio hardware abstraction layer <NUM> configures the battery cover path, specifically in the following.

Referring to <FIG>, after the audio data <NUM> arrives at the audio hardware abstraction layer <NUM>, the audio data <NUM> may be sent by an audio distribution module <NUM> to an audio virtual device (PCM) <NUM> in a kernel layer <NUM>. The audio virtual device <NUM> in the kernel layer <NUM> may be configured to perform digital-to-analog conversion on the audio data <NUM> to generate audio data <NUM>, and then send the audio data <NUM> to a hardware device (for example, a speaker <NUM>) in the hardware layer <NUM> for playing.

In another aspect, based on the received index <NUM>, a loading module <NUM> in the audio hardware abstraction layer <NUM> may load, from a color change data folder <NUM>, the color change data <NUM> corresponding to the index. The color change data <NUM> may be sent by the audio distribution module <NUM> to a battery cover virtual device <NUM> in the kernel layer <NUM>, to drive the battery cover to change colors. Similarly, the battery cover virtual device <NUM> in the kernel layer <NUM> may perform digital-to-analog conversion on the color change data <NUM> to generate the color change data <NUM>, so as to then send the color change data <NUM> to the battery cover <NUM> in the hardware layer <NUM> for displaying.

A particular battery cover virtual device <NUM> may be designated for the color change data <NUM>, and the battery cover virtual device <NUM> may represent a battery cover device <NUM> in the hardware layer <NUM>. In the kernel layer <NUM>, the battery cover virtual device <NUM> and the audio virtual device <NUM> are independent of each other, and the audio data <NUM> and the color change data <NUM> can be transmitted independently of each other, so that interference therebetween can be avoided.

In the kernel layer <NUM>, the audio data <NUM> may be further processed to form the audio data <NUM>, and the audio data <NUM> and the color change data <NUM> are separately sent to an audio digital signal processor ADSP <NUM> in the hardware layer <NUM>.

The audio digital signal processor ADSP <NUM> further processes the audio data <NUM> to obtain audio data <NUM>, and the color change data <NUM> is transparently transmitted through the ADSP <NUM>, so that the audio data <NUM> and the color change data <NUM> can be respectively sent to actual hardware components by the ADSP <NUM>. Specifically, the audio data <NUM> may be obtained from the audio data <NUM> after being processed by the ADSP <NUM>, the audio data <NUM> may be sent to a smart power amplifier SmartPA <NUM>, to undergo digital-to-analog conversion by the SmartPA <NUM>, so as to generate audio data <NUM>, and the audio data <NUM> is sent to the speaker <NUM> for playing.

In another aspect, the color change data <NUM> may be sent to the codec <NUM>, so that the color change data <NUM> can be generated through digital-to-analog conversion, and the color change data <NUM> may be a <NUM> sine wave signal. The color change data <NUM> may be sent to the battery cover <NUM> to drive the battery cover <NUM> to change colors. Therefore, the audio playing process of the electronic device is used, so that the color change data is played during playing of the audio data by the electronic device, to enable the battery cover of electronic device to change colors along with the playing of the audio data.

In an implementation, a user may select external audio data as the audio data to be played in the above scenarios. In other words, in a scenario such as an incoming call ringing, an alarm ringing, or a schedule reminding, the user may set that the electronic device plays the external audio data, that is, not audio data built in when the electronic device leaves the factory, for example, a song downloaded by the user from the Internet or an audio from an external memory. The external audio data may be uniformly compiled into a default index value (for example, <NUM>) in the audio system, that is, all external audio data correspond to an index value <NUM>, and the index value <NUM> may be enabled to correspond to default color change data. Therefore, the electronic device can implement a battery cover color change function by using default color change data during playing of non-preset audio data.

In this embodiment of this application, function modules of the electronic device may be divided based on the foregoing method examples. For example, each function module may be divided based on each function, or two or more functions may be integrated into one processing module. The integrated module may be implemented in the form of hardware, or may be implemented in a form of a software functional module. It should be noted that in this embodiment of this application, the module division is an example, and is merely logical function division, and there may be other division manners during actual implementation.

An embodiment of this application further provides a computer-readable storage medium. The computer-readable storage medium stores instructions, and the instructions, when run on an electronic device, cause the electronic device to perform the related method steps shown in <FIG> and <FIG>, <FIG> and <FIG>, or <FIG> and <FIG>, to implement the battery cover color change method in the foregoing embodiments.

This embodiment further provides a computer program product including instructions, and the computer program product, when run on an electronic device, causes the electronic device to perform the related method steps in the method embodiments shown in <FIG> and <FIG>, <FIG> and <FIG>, or <FIG> and <FIG>, to implement the battery cover color change method in the foregoing embodiments.

Through the descriptions of the foregoing implementations, a person skilled in the art may clearly understand that, for the purpose of convenient and brief description, only division of the foregoing functional modules is used as an example for description. In actual application, the foregoing functions may be allocated to and completed by different functional modules according to requirements. That is, an inner structure of an apparatus is divided into different functional modules to complete all or some of the functions described above. For specific work processes of the system, the apparatus and the units described above, reference may be made to the corresponding processes in the foregoing method embodiments.

In the several embodiments provided in this embodiment, it should be understood that the disclosed battery cover color change method and apparatus may be implemented in other manners. For example, the module or unit division is merely logical function division and may be other division during actual implementation. The indirect couplings or communication connections between the apparatuses or units may be implemented in electrical, mechanical, or other forms.

When the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, the integrated unit may be stored in a computer-readable storage medium. Based on such an understanding, the technical solutions of this embodiment essentially, or the part contributing to the related art, or all or some of the technical solutions may be implemented in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for instructing a computer device (which may be a personal computer, a server, a network device, or the like) or a processor to perform all or some of the steps of the methods described in the embodiments. The storage medium includes: any medium that can store program code, such as a flash memory, a removable hard disk, a read-only memory, a random access memory, a magnetic disk, or a compact disc.

Claim 1:
A battery cover color change method, carried out by an electronic device, wherein the electronic device comprises an application and a battery cover (<NUM>), and the method comprising:
sending, by the application, first audio data to an audio playing process;
in the audio playing process, obtaining color change data based on the first audio data, wherein the color change data corresponds to rhythms of the first audio data; and
playing the first audio data while the battery cover changes colors in accordance with the rhythms of the first audio data driven by the color change data;
characterized in that the first audio data sequentially passes through an application layer (<NUM>), an application framework (<NUM>), an audio hub service layer (<NUM>), an audio hardware abstraction layer (<NUM>), and a kernel layer (<NUM>) in the audio playing process;
wherein the kernel layer comprises a battery cover virtual device (<NUM>) and an audio virtual device (<NUM>), wherein the battery cover virtual device and the audio virtual device are independent of each other.