shisi的专栏

向android的内核添加驱动，其实就是向linux内核添加驱动。主要在两个文件里添加点信息，一个是Kconfig文件，一个是Makefile文件。比如你添加的驱动你代码放到drivers目录下面的XXX目录，那么修在该目录下的Kconfig文件和Makefile文件。具体的修改方法：比如我现在修改drivers/staging/android/下的Kconfig文件。config ANDROID_LOGGER         tristate"Android log driver"         d

OMX 框架是android 音视频codec 的入口吧。 说到入口， 首先omx 就是在ACodec 被使用， 而且是以一个client 来使用， 所以omx 会有个service。这个分析就从这里开始好了。bool ACodec::UninitializedState::onAllocateComponent(const sp &msg) { ALOGV("onAllocate

看到哪里， 写到哪里， 也有可能烂尾，写这个主要是自己的总结，如果有人看不懂我想也是正常的。android 5.0 之后player 主要就是Nuplayer, 所以awesome player 所使用的OMXCodec就不在使用了， 主要就是使用ACodec了。 所以libstagefright的decode过程大概就是MediaCodec.cpp -> ACodec.cpp->OMX.

最近遇到一个问题， 就是不知道audioFlinger 在选择hal 的时候是怎么选择的， 为什么选择的是vendor 的audio hal 而不是default 的？本文急于5.1 的代码。audioflinger 什么时候会去打开audio hal 的so， 5.1版本的不是初始化audioflinger 时就去选择。会在openoutput 时找hw 时去选择，如果已有就不需要找，第

写这个主要还是方便自己记忆和

Running:  mkuserimg.sh out/target/product/vbox_x86/system out/target/product/vbox_x86/obj/PACKAGING/systemimage_intermediates/system.img ext4 system 268435456 out/target/product/vbox_x86/root/file_con

AudioFlinger 是android 多媒体模块Audio模块的两大服务之一。音频相关的数据必须通过它来传递到底层，所以它就会有一个音频数据的处理过程。这里主要就是分析音频数据从编码器出来之后，怎么流向驱动的。从audoFlinger的代码中很容易发现，数据写到驱动的处理是在函数AudioFlinger::PlaybackThread::threadLoop_write()中。这个t

写这个的目的主要是自己做个总结和积累，看别人的比较容易忘记。

AudioPolicyService 是audio framework 的一大service， 另外一个是AudioFlinger。一直觉得通过代码来分析的话写起来很费劲， 最近去看了下UML, 通过同UML 去分析感觉比较清晰，而我自己看回来的话也很容易就知道框架是怎样。先看下AudioPolicyService 的各个主要类的关系。这个看起来简单清晰多了。然后再以getOu