Audio frame of Android audio system

http://blog.csdn.net/xuesen_lin/article/details/8796492

We can combine the knowledge we have now and think about which modules will be included in each level (regardless of the Bluetooth audio section)?

· APP

This is the top level of the entire audio system and is not the focus of Android system implementation. For example, the manufacturer according to the specific needs of a music player, the game used to sound, or adjust the audio of a class of software and so on.

· Framework

I believe you can immediately think of MediaPlayer and Mediarecorder, as this is the most widely used two classes in the development of audio-related products. In fact, Android also provides another two similar functions of the class, that is, Audiotrack and audiorecorder,mediaplayerservice inside the implementation is done through them, but mediaplayer/ The Mediarecorder provides more powerful control capabilities and is easier to use than the former. We'll have a detailed introduction later.

In addition, the Android system provides Audiomanager, Audioservice and Audiosystem classes for our control of the audio system. These are the frameworks designed to facilitate upper-level application development.

· Libraries

We know that many of the classes in the framework layer are really just "intermediaries" for applications that use the Android library file. Because the upper-level applications are written in the Java language, they require the support of the most straightforward Java interfaces, which is one of the implications of the framework layer's existence. As "intermediaries", they do not actually implement specific functions, or only some of the functions, but the main focus on the library to complete. For example, the above Audiotrack, Audiorecorder, MediaPlayer, and Mediarecorder can find corresponding classes in the library.

This part of the code is centrally placed in the frameworks/av/media/libmedia of the project, mostly written in the C + + language.

In addition to the class library implementation above, the audio system requires a "core control", or, in the general implementation of Android, requires a system service (such as ServiceManager, Locationmanagerservice, Activitymanagerservice and so on), this is Audioflinger and Audiopolicyservice. Their code is placed in Frameworks/av/services/audioflinger, and the most important library generated is called Libaudioflinger.

Another important system service in the audio system is Mediaplayerservice, which is located in Frameworks/av/media/libmediaplayerservice.

Because there are so many libraries and related classes involved, it is recommended that you divide them into two clues when you understand them.

First, take the library as a clue. For example, Audiopolicyservice and Audioflinger are all in the Libaudioflinger library, while Audiotrack, Audiorecorder and other implementations are in the Libmedia library.

Second, take the process as a clue. The library does not represent a process, and the process relies on the library to run. Although some classes are implemented in the same library, they do not mean that they are called in the same process. For example, Audioflinger and Audiopolicyservice reside in a system process called mediaserver, while Audiotrack/audiorecorder and mediaplayer/ Mediarecorder is actually just part of the application process, which communicates with other system processes through the binder service.

In the process of analyzing the source code, it is important to grasp these two clues, so as not to feel confused.

· HAL

From a design point of view, the hardware abstraction layer is an object that Audioflinger directly accesses. This illustrates two problems, on the one hand Audioflinger not directly invoke the underlying driver, on the other hand, Audioflinger upper layer (including the same layer of Mediaplayerservice) module only need to interact with it to achieve audio-related functions. As a result, we can assume that Audioflinger is the real "isolator" in the Android audio system, and no matter how the following changes, the implementation of the upper layer can be kept compatible.

The hardware abstraction layer of audio is mainly divided into two parts, namely Audioflinger and Audiopolicyservice. In fact, the latter is not a real device, but the use of virtual devices to make it easy for vendors to customize their own strategy.

The task of the abstraction layer is to actually associate the Audioflinger/audiopolicyservice with a hardware device, but it must provide a flexible structure to cope with the change--especially for Android, a system that has a very frequent update. For example, the audio system in the previous Android system relied on Alsa-lib, but later became TINYALSA, and such a shift should not be disruptive to the upper layer. The audio HAL thus provides a unified interface to define how it communicates with Audioflinger/audiopolicyservice, which is Audio_hw_device, audio_stream_in, and AUDIO_STREAM_ For the purpose of existence, these struct data types are mostly simply definitions of function pointers, and are some "shells". When Audioflinger/audiopolicyservice is initialized, they look for the most matching implementations in the system (these implementations reside in various libraries in the name of audio.primary.*,audio.a2dp.*) to populate these "shells".

Depending on the product, the audio device is very different, in the Android audio architecture, these problems are solved by the HAL layer Audio.primary, and so on, without the need to modify the upper level implementation on a large scale. In other words, the focus of the vendor's customization is how to provide the efficient implementation of this part of the library.

Based on the above analysis, we give a complete Android audio system framework for reference (no Linux layer implementations are listed, such as Alsadriver, etc.), as follows:

Audio frame of Android audio system