Let’s have a glance of the architecture of Android Multimedia Framework.
The MediaPlayerService is one of the key component of Android multimedia framework. MediaPlayerService separates application implement from native module design. The structure of class MediaPlayerService is a little complicated as follow:
There are three nested classes in MediaPlayerService class. Let’s focus on MediaPlayerService and Client. BnMediaPlayerService and BnMediaPlayer hint that both class MediaPlayerService and nested class Client export API for remote process invoke. The nested class name “Client” indicates it represents the MediaPlayer in application process. The API call from Application player will invoke the matched native player via Client. Let’s see an example of a call flow as following figure.
While dissecting the architecture of MediaPlayerService, I choose to start with Binder interface. The advantage is that once we know all the exported API, we can skip Bn->Bp next time we track another function call. Refer to following UML diagram of MediaPlayerService and MediaPlayerService::Client.
As mentioned early, Client is in charge of handling all operation, including start, stop, or pause music, of media player in application process. Since Client is a nested class declared in MediaPlayerService, the instance of Client must be created and returned by MediaPlayerService. Let’s see the key function doing this.
Previous figure indicates that MediaPlayerService::Client represents the native media players. Next article I will introduce how a specific native players was chosen and composed into Client.
I would say MediaPlayerService::Client is most important component of MediaPlayerService. MediaPlayerService create the Client instance and returned it for remote client use. There is also other APIs exported by MediaPlayerService like createMediaRecorder(…), decode(…), etc. However, the function call flow is relatively simpler than those in Client.