Audio data intercommunication method and system in Android ecological application, terminal and storage medium

Abstract

The invention discloses an audio data intercommunication method and system in an Android ecological application, a terminal and a storage medium, and the method comprises the steps: constructing a Socket Server in an Audio HAL layer of an Android, and waiting for the service connection of an audio bridging system of OpenHarmony; the OpenHarmony constructs an audio bridging system service, and carries out data communication with the Socket Server of the Android through the UnixSocket; and the Android server side sends the Android communication signaling to the OpenHarmony, and the OpenHarmony reads the PCM audio data on the Android according to the Android communication signaling. According to the invention, the difference between the OpenHarmony and the Android audio framework is solved, the Android application can directly use audio hardware equipment on the OpenHarmony, a low-delay audio data transmission mechanism is provided, the real-time performance of audio playing is ensured, the real-time conversion of audio data formats is realized, the compatibility of the Android application and the OpenHarmony audio framework is ensured, and the application and the implementation of the OpenHarmony audio framework are facilitated. Therefore, the audio data intercommunication between the OpenHamrony and the Android application is realized.

Description

Technical Field

[0001] This invention relates to the field of communication technology, and in particular to a method, system, terminal, and computer-readable storage medium for audio data interoperability in Android ecosystem applications. Background Technology

[0002] OpenHarmony is an open-source operating system led by the OpenAtom Foundation, aiming to provide a unified operating system solution for all smart devices. Currently, OpenHarmony has made some progress in areas such as smart homes, smart wearables, smart vehicles, industrial manufacturing, and military aerospace, but its application ecosystem is still in its early stages of development. According to official OpenHarmony data, currently only some demo applications are available in the community edition, making it difficult to align with the current Android application ecosystem.

[0003] The OpenHarmony operating system currently faces the following challenges: a weak application ecosystem (lacking a rich selection of third-party applications); insufficient developer support (development tools and documentation are still incomplete); and user dependency (users' reliance on the Android ecosystem is difficult to change in the short term).

[0004] Android is the world's largest mobile operating system, holding over 70% of the global smartphone market share. Its application ecosystem is extremely rich, with over 3 million apps in the Google Play Store, covering various fields such as games, social networking, office work, and entertainment.

[0005] Currently, OpenHarmony does not support Android applications. OpenHarmony's audio framework is based on the HDF driver framework, which differs significantly from Android's audio. This causes Android applications running on Docker services to be unable to directly use OpenHarmony's audio hardware devices, resulting in issues such as multimedia playback failing to produce sound.

[0006] Therefore, existing technologies still need to be improved and developed. Summary of the Invention

[0007] The main objective of this invention is to provide a method, system, terminal, and computer-readable storage medium for audio data interoperability in Android ecosystem applications. This invention aims to solve the problem that there are significant differences between the OpenHarmony audio framework and Android audio in the prior art, which prevents Android applications running on Docker services from directly using OpenHarmony audio hardware devices, resulting in the inability to produce sound in multimedia playback functions.

[0008] To achieve the above objectives, the present invention provides a method for interoperability of audio data in Android ecosystem applications, the method comprising the following steps: Build a Socket Server in the Android Audio HAL layer and wait for the OpenHarmony audio bridging system service to connect; OpenHarmony builds an audio bridging system service that communicates with Android's SocketServer via UnixSocket; The Android server sends Android communication signaling to OpenHarmony, and OpenHarmony reads the PCM audio data on the Android device based on the Android communication signaling.

[0009] Optionally, in the method for interoperability of audio data in Android ecosystem applications, the step of building a Socket Server in the Android AudioHAL layer specifically involves: Create a Socket Server in the audio_hw.c file in Android libhardware.

[0010] Optionally, the method for interoperability of audio data in Android ecosystem applications, wherein building a Socket Server in the Android AudioHAL layer, further includes: A circular queue is built in the Android audio libhardware to serve as a buffer for PCM audio data.

[0011] Optionally, the method for interoperability of audio data in the Android ecosystem applications, wherein OpenHarmony constructs an audio bridging system service and communicates with the Android Socket Server via UnixSocket, specifically includes: OpenHarmony builds an audio bridging system service, configures the compilation script for the audio bridging system service, and declares the creation of UnixSocket files; The audio bridging system service initiates a background process that continuously checks whether the Socket Server is running. Once the Socket Server is detected to be running, it actively initiates a connection request. Once the request is established, the Android server sends a file descriptor for communication to the audio bridging system service; When the Android server plays audio data, it sends the PCM audio data frame by frame through the SocketServer according to the specified size. After receiving the PCM audio data, the audio bridging system service reads the PCM audio data and informs the Android server.

[0012] Optionally, in the method for interoperating audio data in the Android ecosystem applications, when the Android server plays audio data, it sends the PCM audio data frame by frame according to a specified size to the audio bridging system service via a Socket Server. After receiving the PCM audio data, the audio bridging system service reads the PCM audio data and informs the Android server. The method further includes: After receiving the PCM audio data, the audio bridging system service transmits the PCM audio data to the OpenHarmony media service framework for audio playback.

[0013] Optionally, the method for interoperability of audio data in Android ecosystem applications further includes: When the Android service needs to record audio, it sends a recording request to the audio bridging system service. After receiving the recording request, the audio bridging system service calls the microphone device of the media service to record audio. After receiving the recording data, it sends the recording data to the Android service through the Socket Server.

[0014] Optionally, in the method for interoperating audio data in the Android ecosystem applications, the Android communication signaling includes: Readable data block: Indicates information about the currently readable data block; Read command: Request to read data; Write command: Request to write data; Memory address information: Informs the other party which memory location needs to be read from or written to; Data size: Specifies the amount of data to read or write.

[0015] Furthermore, to achieve the above objectives, the present invention also provides an audio data interoperability system for Android ecosystem applications, wherein the audio data interoperability system for Android ecosystem applications includes: The service creation module is used to build a Socket Server in the Android Audio HAL layer, waiting for the OpenHarmony audio bridging system service to connect; The communication connection module is used to build an audio bridging system service using OpenHarmony, and communicates with Android's Socket Server via UnixSocket. The audio interoperability module is used by the Android server to send Android communication signaling to OpenHarmony, and OpenHarmony reads the PCM audio data on Android according to the Android communication signaling.

[0016] Furthermore, to achieve the above objectives, the present invention also provides a terminal, wherein the terminal includes: a memory, a processor, and an audio data interoperability program stored on the memory and executable on the processor, wherein when the audio data interoperability program in the Android ecosystem is executed by the processor, it implements the steps of the audio data interoperability method in the Android ecosystem as described above.

[0017] Furthermore, to achieve the above objectives, the present invention also provides a computer-readable storage medium, wherein the computer-readable storage medium stores an interoperability program for audio data in an Android ecosystem application, and when the interoperability program for audio data in an Android ecosystem application is executed by a processor, it implements the steps of the interoperability method for audio data in an Android ecosystem application as described above.

[0018] In this invention, a Socket Server is built in the Android Audio HAL layer, waiting for the OpenHarmony audio bridging system service to connect. OpenHarmony builds an audio bridging system service, communicating with the Android Socket Server via UnixSocket. The Android server sends Android communication signaling to OpenHarmony, and OpenHarmony reads the PCM audio data on Android based on the Android communication signaling. This invention resolves the differences between OpenHarmony and the Android audio framework, enabling Android applications to directly use audio hardware devices on OpenHarmony, providing a low-latency audio data transmission mechanism, ensuring real-time audio playback, enabling real-time conversion of audio data formats, and ensuring compatibility between Android applications and the OpenHarmony audio framework, thereby achieving interoperability of audio data between OpenHarmony and Android applications. Attached Figure Description

[0019] Figure 1 This is a flowchart of a preferred embodiment of the audio data interoperability method in the Android ecosystem application of the present invention; Figure 2 This is a schematic diagram of the Android HarmonyOS audio data interoperability architecture in a preferred embodiment of the audio data interoperability method in Android ecosystem applications of the present invention. Figure 3 This is a structural diagram of a preferred embodiment of the audio data interoperability system in the Android ecosystem application of the present invention; Figure 4 This is a structural diagram of a preferred embodiment of the terminal of the present invention. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of this invention clearer and more explicit, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.

[0021] Based on the proposed OpenHarmony operating system running Docker services and loading Android images, this solution has the following drawbacks: (1) The audio hardware of the OpenHarmony development board cannot be used directly: OpenHarmony's audio framework is based on the HDF (Hardware Driver Foundation) driver framework, while Android's audio framework is based on AudioFlinger and AudioPolicyManager, and the two have significant architectural differences. When an Android application plays audio through AudioTrack or MediaPlayer, the audio data stream passes through Android's audio framework and finally interacts with the audio hardware through the HAL (Hardware Abstraction Layer). Because OpenHarmony's audio framework is incompatible with Android, Android applications running on Docker services cannot directly use OpenHarmony's audio hardware devices, resulting in the inability to produce sound during multimedia playback.

[0022] (2) Performance overhead: Running Android images using Docker services introduces additional performance overhead, especially in scenarios with high real-time requirements such as audio processing, which may lead to audio latency or stuttering. The Android audio framework uses AudioFlinger to achieve low-latency audio processing, while audio data in the Docker environment needs to go through an additional virtualization layer, increasing processing latency.

[0023] (3) Compatibility issues: Some Android applications running in a Docker environment may fail to correctly handle audio data formats or audio routing, leading to audio playback failures or degraded quality. The Android audio framework supports multiple audio formats (such as PCM, AAC, MP3), while the OpenHarmony audio framework may not support certain formats, resulting in data format incompatibility and causing audio playback failures or degraded quality.

[0024] This invention aims to solve the technical problems of audio hardware incompatibility, high audio transmission latency, and incompatible audio data formats.

[0025] The core of this invention is the establishment of a direct, controlled, and efficient audio data channel between Android Audio HAL and OpenHarmony system services. This enables cross-system ecosystem audio data interoperability, breaking down the audio barriers between the two independent operating systems, Android and OpenHarmony. It allows the OpenHarmony system to directly play raw data from the Android audio ecosystem, ensuring low latency and high performance of the audio stream. This establishes a clear and robust architecture and communication paradigm, improving system reliability and maintainability. It successfully connects the audio subsystems of two heterogeneous operating systems, forming a unified audio output capability while maintaining their independence.

[0026] The preferred embodiment of the present invention describes a method for interoperability of audio data in Android ecosystem applications, such as... Figure 1 and Figure 2 As shown, the method for interoperability of audio data in the Android ecosystem applications includes the following steps: Step S10: Build a Socket Server in the Android Audio HAL layer and wait for the OpenHarmony audio bridging system service to connect.

[0027] Specifically, a Socket Server is created in the audio_hw.c file in Android libhardware. This is usually done by customizing or modifying a specific Audio HAL implementation (such as primary or aospHAL) to ensure that the Socket Server is ready and listening for connections before the Android audio service (audioserver) fully starts up and begins calling the HAL interface. This avoids the "connection refused" error that occurs when OpenHarmony attempts to connect.

[0028] The Socket type can use AF_UNIX (also known as a local domain Socket) to complete data copying within the same device kernel without going through the network protocol stack (efficient). It addresses based on file system paths and can be easily accessed through file permission control (secure). After creating the Socket Server, a separate daemon thread is immediately created. The task of this thread is to wait for OpenHarmony client connections; when a client connects, it returns a new Socket file descriptor for communication with that specific client.

[0029] For example, in the Audio HAL initialization routine, an AF_UNIX domain streaming socket is created and bound to a predetermined path; a separate listening thread is started to asynchronously accept connection requests from the OpenHarmony audio bridging system service. File system access permissions and SELinux policies are set for the AF_UNIX domain socket to restrict connections from unauthorized processes. In the listening thread, the accept system call is called repeatedly to block and wait for connections; when a new connection is accepted, a new dedicated data communication socket is created for subsequent audio data and signaling transmission.

[0030] By establishing a controlled, efficient, and secure local IPC service endpoint at the source of the Android audio data stream (Audio HAL), a stable and reliable "data retrieval" entry point is provided for the OpenHarmony system. This solves the fundamental "connection establishment" problem for audio data sharing between two heterogeneous systems and is the cornerstone of the entire interoperability solution. All subsequent data streams depend on the successful establishment of this connection.

[0031] A circular queue is built in the Android audio libhardware to serve as a buffer for PCM audio data. The circular queue (or circular buffer) acts as a first-in, first-out (FIFO) shared memory area, decoupling data producers and consumers to ensure the continuity and low latency of the audio stream. The lifecycle of this circular queue is tied to an open audio stream (Playback). The queue is ready each time audio playback begins.

[0032] Step S20: OpenHarmony builds an audio bridging system service, which communicates with Android's Socket Server via UnixSocket.

[0033] Specifically, OpenHarmony builds an audio bridging system service (building a persistent, high-privilege system-level service as a client and hub for communication with the Android Audio HAL, developed in accordance with OpenHarmony's system service specifications, integrated into OpenHarmony's unified build system through GN and Bundle.json configuration files, and using SELinux policies to ensure the service runs securely with the necessary permissions), configures the compilation script for the audio bridging system service (the compilation script needs to be correctly configured in order to compile, link, and package the service code into the system image), and declares the creation of UnixSocket files.

[0034] The audio bridging system service initiates a background process that continuously checks whether the Socket Server is running. Upon detecting that the Socket Server is running, it actively initiates a connection request. For example, it creates a separate daemon thread that repeatedly attempts to connect to the Socket server, and sleeps for a predetermined time interval after each failed attempt. When the connection status changes, it publishes status events to the system through OpenHarmony's public event manager. These status events include connection establishment, connection termination, and reconnection failure. Once the request is established, the Android server sends a file descriptor for communication to the audio bridging system service. The audio bridging system service then uses this file descriptor for subsequent communication. File descriptor passing is a mechanism for sharing open kernel objects across processes. Through a special IPC channel (such as a Unix Domain Socket), access rights to a file descriptor (representing a file, socket, pipe, etc.) opened in one process are copied and passed to another process. The receiving process receives a new file descriptor number that belongs to it, but this new file descriptor points to the same kernel object. Subsequent PCM audio data transmission occurs through the data channel represented by the transmitted file descriptor, while device control, status synchronization, and other signaling are handled through the initially established control socket, thus separating the data plane from the control plane. Introducing the file descriptor transmission mechanism separates the control flow from the data flow; it establishes a dedicated channel for transmitting large amounts of audio data, and can even achieve zero-copy using shared memory.

[0035] When the Android server plays audio data, it sends PCM audio data frame by frame to the audio bridging system service via SocketServer (retrieving PCM audio data of a specified size (e.g., 1920 bytes) from a previously constructed circular queue). Upon receiving the PCM audio data, the audio bridging system service reads it and informs the Android server. Furthermore, before sending each frame of PCM data, a protocol header is added. This header includes at least the frame sequence number and the size of the PCM data payload for that frame. The encapsulated header and payload are sent together via a data socket. After successfully receiving and processing a frame of audio data, OpenHarmony sends an acknowledgment message to the Android server. This message includes at least the sequence number of the acknowledged frame. After sending a frame, the Android server waits to receive the acknowledgment message for that frame before sending the next frame. The Android server starts a timer after sending a frame. If no acknowledgment message is received before the timer expires, the frame transmission is considered a failure, and a retransmission is automatically initiated. If the number of consecutive retransmission failures exceeds a threshold, a connection error is detected, triggering a connection reconstruction process.

[0036] This "frame-by-frame sending and confirmation waiting" mechanism elevates simple data forwarding into a controlled, reliable, and adaptive data stream service. It ensures that even with system load fluctuations and minor network jitter, audio data can be transmitted stably at the most suitable rate, without data loss or overwhelming the receiver. It establishes a closed-loop feedback transmission channel between two independent systems for audio data with high real-time requirements, which is the essence of achieving high-quality, low-latency, cross-ecosystem audio interoperability.

[0037] After receiving the PCM audio data, the audio bridging system service transmits the PCM audio data to the OpenHarmony media service framework (which provides an upper-layer API), and the audio is played through the media service framework. Handing over the PCM audio data to the OpenHarmony media service framework is not just a simple data transfer; it involves a series of sophisticated operations such as format conversion, synchronization strategies, buffer management, and state synchronization.

[0038] Furthermore, when the Android service needs to record, it sends a recording request to the audio bridging system service. Upon receiving the recording request, the audio bridging system service calls the microphone device of the media service to record audio. After receiving the recording data, it sends the recording data to the Android service via a Socket Server. For example, the OpenHarmony audio bridging service encapsulates the PCM audio data read from AudioCapturer into data frames and sends them to the Android server via a data Socket. The Android server receives and parses the data frames, writing the final PCM data into a virtual audio input device or a buffer of the proxy Audio HAL for use by upper-layer Android recording applications. This functionality enables seamless operation of Android applications requiring recording functions, such as voice calls, recorders, and voice assistants, on OpenHarmony devices, greatly enhancing the practical value and coverage of the solution.

[0039] Step S30: The Android server sends Android communication signaling to OpenHarmony, and OpenHarmony reads the PCM audio data on Android according to the Android communication signaling.

[0040] Specifically, the Android communication signaling includes: Readable data block: Indicates information about the currently readable data block; Read command: Request to read data; Write command: Request to write data; Memory address information: Informs the other party which memory location needs to be read from or written to; Data size: Specifies the amount of data to read or write.

[0041] Whenever OpenHarmony's audio pipeline (or audio buffer) needs more data, it sends an Android communication signal to the Android server via a control socket. Upon receiving this request, the Android server reads a specified size of PCM audio data from the circular queue (or directly from a callback in the Audio HAL). The Android server then encapsulates the read PCM audio data into a data frame (including a protocol header), as discussed earlier, and sends it to OpenHarmony via a data socket (signaling goes through the control socket, data goes through the data socket). This process is a response to the request, but it carries the actual data payload, ensuring stable data transmission and low latency.

[0042] The technical effects of this invention are as follows: (1) Audio hardware interoperability: It resolves the differences between OpenHarmony and the Android audio framework, enabling Android applications to directly use audio hardware devices on OpenHarmony.

[0043] (2) Low-latency audio transmission: It provides a low-latency audio data transmission mechanism to ensure real-time audio playback.

[0044] (3) Audio data format compatibility: Enables real-time conversion of audio data formats, ensuring compatibility between Android applications and the OpenHarmony audio framework.

[0045] Furthermore, such as Figure 3 As shown, based on the above-mentioned method for interoperability of audio data in Android ecosystem applications, the present invention also provides a corresponding system for interoperability of audio data in Android ecosystem applications, wherein the system for interoperability of audio data in Android ecosystem applications includes: Service creation module 51 is used to build a Socket Server in the Android Audio HAL layer, waiting for the OpenHarmony audio bridging system service to connect. The communication connection module 52 is used to build an audio bridging system service in OpenHarmony and communicate with the Android Socket Server via UnixSocket. The audio interoperability module 53 is used by the Android server to send Android communication signaling to OpenHarmony, and OpenHarmony reads the PCM audio data on Android according to the Android communication signaling.

[0046] Furthermore, such as Figure 4As shown, based on the above-mentioned method and system for interoperability of audio data in Android ecosystem applications, the present invention also provides a terminal, which includes a processor 10, a memory 20 and a display 30. Figure 4 Only some of the terminal components are shown; however, it should be understood that it is not required to implement all of the components shown, and more or fewer components may be implemented instead.

[0047] In some embodiments, the memory 20 may be an internal storage unit of the terminal, such as a hard drive or memory. In other embodiments, the memory 20 may be an external storage device of the terminal, such as a plug-in hard drive, Smart Media Card (SMC), Secure Digital (SD) card, or Flash Card. Furthermore, the memory 20 may include both internal and external storage devices. The memory 20 is used to store application software and various types of data installed on the terminal, such as the program code installed on the terminal. The memory 20 can also be used to temporarily store data that has been output or will be output. In one embodiment, the memory 20 stores an audio data interoperability program 40 for Android ecosystem applications. This audio data interoperability program 40 can be executed by the processor 10 to implement the audio data interoperability method for Android ecosystem applications in this application.

[0048] In some embodiments, the processor 10 may be a central processing unit (CPU), a microprocessor, or other data processing chip, used to run program code stored in the memory 20 or process data, such as executing the audio data interoperability method in the Android ecosystem application.

[0049] In some embodiments, the display 30 may be an LED display, a liquid crystal display, a touch-sensitive liquid crystal display, or an OLED (Organic Light-Emitting Diode) touchscreen. The display 30 is used to display information on the terminal and to display a visual user interface. The terminal's processor 10, memory 20, and display 30 communicate with each other via a system bus.

[0050] In one embodiment, when the processor 10 executes the interoperability program 40 for audio data in the Android ecosystem application stored in the memory 20, the following steps are performed: Build a Socket Server in the Android Audio HAL layer and wait for the OpenHarmony audio bridging system service to connect; OpenHarmony builds an audio bridging system service that communicates with Android's SocketServer via UnixSocket; The Android server sends Android communication signaling to OpenHarmony, and OpenHarmony reads the PCM audio data on the Android device based on the Android communication signaling.

[0051] Specifically, building a Socket Server in the Android Audio HAL layer involves: Create a Socket Server in the audio_hw.c file in Android libhardware.

[0052] The step of building a Socket Server in the Android Audio HAL layer includes, in addition to: A circular queue is built in the Android audio libhardware to serve as a buffer for PCM audio data.

[0053] Specifically, OpenHarmony constructs an audio bridging system service that communicates with Android's Socket Server via UnixSocket, including: OpenHarmony builds an audio bridging system service, configures the compilation script for the audio bridging system service, and declares the creation of UnixSocket files; The audio bridging system service initiates a background process that continuously checks whether the Socket Server is running. Once the Socket Server is detected to be running, it actively initiates a connection request. Once the request is established, the Android server sends a file descriptor for communication to the audio bridging system service; When the Android server plays audio data, it sends the PCM audio data frame by frame through the SocketServer according to the specified size. After receiving the PCM audio data, the audio bridging system service reads the PCM audio data and informs the Android server.

[0054] When the Android server plays audio data, it sends the PCM audio data frame by frame to the audio bridging system service via a Socket Server according to a specified size. After receiving the PCM audio data, the audio bridging system service reads the PCM audio data and informs the Android server. The process then includes: After receiving the PCM audio data, the audio bridging system service transmits the PCM audio data to the OpenHarmony media service framework for audio playback.

[0055] The method for interoperability of audio data in Android ecosystem applications also includes: When the Android service needs to record audio, it sends a recording request to the audio bridging system service. After receiving the recording request, the audio bridging system service calls the microphone device of the media service to record audio. After receiving the recording data, it sends the recording data to the Android service through the Socket Server.

[0056] The Android communication signaling includes: Readable data block: Indicates information about the currently readable data block; Read command: Request to read data; Write command: Request to write data; Memory address information: Informs the other party which memory location needs to be read from or written to; Data size: Specifies the amount of data to read or write.

[0057] The present invention also provides a computer-readable storage medium, wherein the computer-readable storage medium stores an interoperability program for audio data in an Android ecosystem application, and when the interoperability program for audio data in an Android ecosystem application is executed by a processor, it implements the steps of the interoperability method for audio data in an Android ecosystem application as described above.

[0058] In summary, this invention provides a method, system, terminal, and computer-readable storage medium for audio data interoperability in Android ecosystem applications. The method includes: constructing a Socket Server in the Android Audio HAL layer, waiting for the OpenHarmony audio bridging system service to connect; OpenHarmony constructing an audio bridging system service, communicating with the Android Socket Server via UnixSocket; the Android server sending Android communication signaling to OpenHarmony, and OpenHarmony reading PCM audio data on Android according to the Android communication signaling. This invention resolves the differences between OpenHarmony and the Android audio framework, enabling Android applications to directly use audio hardware devices on OpenHarmony, providing a low-latency audio data transmission mechanism, ensuring real-time audio playback, achieving real-time audio data format conversion, and ensuring compatibility between Android applications and the OpenHarmony audio framework, thereby achieving audio data interoperability between OpenHarmony and Android applications.

[0059] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or terminal that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or terminal. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or terminal that includes that element.

[0060] Of course, those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware (such as a processor, controller, etc.). The program can be stored in a computer-readable storage medium, and when executed, it can include the processes described in the above method embodiments. The computer-readable storage medium can be a memory, magnetic disk, optical disk, etc.

[0061] It should be understood that the application of the present invention is not limited to the examples above. Those skilled in the art can make improvements or modifications based on the above description, and all such improvements and modifications should fall within the protection scope of the appended claims.

Claims

1. A method for interoperability of audio data in Android ecosystem applications, characterized in that, The methods for interoperability of audio data in Android ecosystem applications include: Build a Socket Server in the Android Audio HAL layer and wait for the OpenHarmony audio bridging system service to connect; OpenHarmony builds an audio bridging system service that communicates with Android's Socket Server via UnixSocket; The Android server sends Android communication signaling to OpenHarmony, and OpenHarmony reads the PCM audio data on the Android device based on the Android communication signaling.

2. The method for interoperability of audio data in Android ecosystem applications according to claim 1, characterized in that, The specific steps for building a Socket Server in the Android Audio HAL layer are as follows: Create a Socket Server in the audio_hw.c file in Android libhardware.

3. The method for interoperability of audio data in Android ecosystem applications according to claim 1, characterized in that, The process of building a Socket Server in the Android Audio HAL layer also includes: A circular queue is built in the Android audio libhardware to serve as a buffer for PCM audio data.

4. The method for interoperability of audio data in Android ecosystem applications according to claim 1, characterized in that, The OpenHarmony system builds an audio bridging service that communicates with Android's Socket Server via UnixSocket, specifically including: OpenHarmony builds an audio bridging system service, configures the compilation script for the audio bridging system service, and declares the creation of UnixSocket files; The audio bridging system service initiates a background process that continuously checks whether the Socket Server is running. Once the Socket Server is detected to be running, it actively initiates a connection request. Once the request is established, the Android server sends a file descriptor for communication to the audio bridging system service; When the Android server plays audio data, it sends the PCM audio data frame by frame through the SocketServer according to the specified size. After receiving the PCM audio data, the audio bridging system service reads the PCM audio data and informs the Android server.

5. The method for interoperability of audio data in Android ecosystem applications according to claim 4, characterized in that, When the Android server plays audio data, it sends the PCM audio data frame by frame to the audio bridging system service via a Socket Server according to a specified size. After receiving the PCM audio data, the audio bridging system service reads the PCM audio data and informs the Android server. The process then includes: After receiving the PCM audio data, the audio bridging system service transmits the PCM audio data to the OpenHarmony media service framework for audio playback.

6. The method for interoperability of audio data in Android ecosystem applications according to claim 1, characterized in that, The methods for audio data interoperability in Android ecosystem applications also include: When the Android service needs to record audio, it sends a recording request to the audio bridging system service. After receiving the recording request, the audio bridging system service calls the microphone device of the media service to record audio. After receiving the recording data, it sends the recording data to the Android service through the Socket Server.

7. The method for interoperability of audio data in Android ecosystem applications according to claim 1, characterized in that, The Android communication signaling includes: Readable data block: Indicates information about the currently readable data block; Read command: Request to read data; Write command: Request to write data; Memory address information: Informs the other party which memory location needs to be read from or written to; Data size: Specifies the amount of data to read or write.

8. A system for interoperating audio data in Android ecosystem applications, characterized in that, The audio data interoperability system in the Android ecosystem applications includes: The service creation module is used to build a Socket Server in the Android Audio HAL layer, waiting for the OpenHarmony audio bridging system service to connect; The communication connection module is used to build an audio bridging system service using OpenHarmony, and communicates with Android's Socket Server via UnixSocket. The audio interoperability module is used by the Android server to send Android communication signaling to OpenHarmony, and OpenHarmony reads the PCM audio data on Android according to the Android communication signaling.

9. A terminal, characterized in that, The terminal includes: a memory, a processor, and an audio data interoperability program in an Android ecosystem application stored in the memory and executable on the processor. When the audio data interoperability program in the Android ecosystem application is executed by the processor, it implements the steps of the audio data interoperability method in an Android ecosystem application as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores an interoperability program for audio data in Android ecosystem applications, which, when executed by a processor, implements the steps of the method for interoperability of audio data in Android ecosystem applications as described in any one of claims 1-7.

Images