音视频框架Opencore(PacketVideo) /Stagefright-【OpenMAX】；DRM，TinyAlsa

  音视频编码/解码过程及API.
> 开源音频库OpenCore和Stagefright
android媒体开发，OpenCore和Stagefright(一)- https://blog.csdn.net/xmc281141947/article/details/60766737
Android Multimedia框架总结（九）Stagefright- https://www.jianshu.com/p/d04336fd1b27

  对于android 多媒体框架，Google 在 Android 2.2中就已经实现了stagefright，但还是保留了opencore；在新推出的2.3版本中，2.3正式抛弃了opencore，而采用stagefright。 Stagefright的编解码功能是利用OpenMAX框架，而且用的还是OpenCORE之OMX的操作。
  Android froyo 2.2版本多媒体引擎做了变动，新添加了stagefright框架，并且默认情况android选择stagefright，弃用之前的opencore，仅仅对opencore中的omx-component部分做了引用。stagefright是在MediaPlayerService这一层加入的，和opencore是并列的。Opencore与stagefright两套机制，对于我们的开发而言，主要体现在parser和codec部分。Opencore方面，必须按照其规范完成相应的parser-node，codec 则要按照omx规范实现相应的component。Stagefright方面，则要按照其规范实现相应的extractor和decoder。

-- stagefright框架：

-- Android 6.0 frameworks/av/media的结构截图： 

  
-- MediaPlayer与openCore的联系。OpenCore的另外一个常用的称呼是PacketVideo，它是Android的多媒体核心。OpenCore是一个多媒体的框架，从宏观上来看，它主要包含了两大方面的内容：
 1.PVPlayer：提供媒体播放器的功能，完成各种音频(Audio)、视频(Video)流的回放(Playback)功能；
 2.PVAuthor：提供媒体流记录的功能，完成各种音频(Audio)、视频(Video)流的以及静态图像捕获功能。

-- Android 音频系统：从 AudioTrack 到 AudioFlinger- http://blog.csdn.net/zyuanyun/article/details/60890534
深入剖析Android音频之AudioTrack- http://blog.csdn.net/STN_LCD/article/details/52788422?locationNum=3
MediaPlayer在底层是基于OpenCore(PacketVideo)的库实现的。
 1.AudioManager：这个主要是用来管理Audio系统的；
 2.AudioTrack：这个主要是用来播放声音的；
 3.AudioRecord：这个主要是用来录音的；

> 视频框架 多媒体框架
android多媒体框架学习 详解 最新版本- http://blog.csdn.net/u010164190/article/details/53108467
  MediaPlayer框架图, Camera框架图 ,SoundRecorder框架图, VideoCamera框架图, ALSA Audio框架图 ,Video Overlay框架图 ,Camera HAL演化图,
google终于舍得给multimedia建个独立的git了（framework/av），framework/av下都是些C/C++代码（libmedia，libmediaplayerservice，libstagefright）
-- video 部分：
  1：video playback；2：video streaming；3：video recorder
-- audio部分：
  1：audio playback；2：audio streaming；3：sound recorder；4：audio flinger

Android：构建一个典型的音乐 App- https://mp.weixin.qq.com/s/AngSHW1qUBsl_acFhlWGDA?utm_source=tuicool&utm_medium=referral
  WifiLock && WakeLock。通常情况下，当用户没有使用设备一段时间，Android 系统出于省电的考虑，可能会关闭Wifi 网络和 CPU。为了让后台播放的音乐不会因为网络关闭而获取不到音频数据等，需要获取 WifiLock，使音乐播放过程中，Wifi 保持唤醒。

Android 5.0(L) 的MediaSession架构分析（转载）- http://blog.csdn.net/mikesno1/article/details/47254143
android-MediaBrowserService- https://github.com/googlesamples/android-MediaBrowserService
 Android5.0 提出了全新的MediaSession概念用于播放器与控制器之间进行交互，它取代之前的RemoteControlClient
 Android 5.0(Lolippop)更新了新的 媒体播放API 和 媒体类型通知 ，使用最新的API可以让系统界面能够读取你的媒体播放并提取和显示专辑封面。比如在Lolippop上，播放音乐时锁屏界面背景会变成专辑封面，并且还有播放控制按钮。Lolippop的锁屏兼容了 RemoteControlClient 和 MediaSession 两种方式，都可以在锁屏控制媒体播放并提取和显示专辑封面。

> 音频框架，TinyALSA
TinyALSA is a small library to interface with ALSA in the Linux kernel- https://github.com/tinyalsa/tinyalsa
Android音频底层调试-基于tinyalsa- https://blog.csdn.net/kangear/article/details/38139669
Android下音频tinyalsa(tinymix/tinycap/tinyplay/tinypcminfo)测试-https://blog.csdn.net/songze_lee/article/details/72800144
音视频开源App你值得收藏- http://blog.csdn.net/androidstarjack/article/details/68954614?locationNum=9&fps=1
Android音频系统之音频框架- http://blog.csdn.net/xuesen_lin/article/details/8796492
  在计算机发展的早期，电脑的声音处理设备是由一个非常简易的loudspeaker外加发声器(Tone Generator)构成的，功能相对局限。后来人们想到了以plug-in的形式来扩展音频设备，“Sound blaster”就是其中很有名的一个。这种早期的声卡以插件方式连接到电脑主板上，并提供了更多复杂的音频设备。ALSA是Linux社区为了取代OSS而提出的一种框架，是一个源代码完全开放的系统(遵循GNU GPL和GNU LGPL)。ALSA在Kernel 2.5版本中被正式引入后，OSS就逐步被排除在内核之外。当然，OSS本身还是在不断维护的，只是不再为Kernel所采用而已。
  MediaPlayer和MediaRecorder，因为这是我们在开发音频相关产品时使用最广泛的两个类。实际上，Android也提供了另两个相似功能的类，即AudioTrack和AudioRecorder，MediaPlayerService内部的实现就是通过它们来完成的,只不过MediaPlayer/MediaRecorder提供了更强大的控制功能。比如以前Android系统中的Audio系统依赖于ALSA-lib，但后期就变为了tinyalsa。除此以外，Android系统还为我们控制音频系统提供了AudioManager、AudioService及AudioSystem类。这些都是framework为便利上层应用开发所设计的。

Linux下Gcc生成和使用静态库和动态库详解-https://wenku.baidu.com/view/7d8602b265ce050877321301.html
  tinyalsa是Google在Android 4.0之后推的基于alsa内核的用户层音频接口。在Android 4.0之前还一直是使用这alsa-lib接口。Google之所以推出tinyalsa，我认为有可能是因为alsa使用了GPL许可证的缘故，也有可能是因为alsa-lib的库过于复杂繁琐大部分功能在Android平台没有实际实用意义却依然占用屈指可数的内存空间。
  TinyAlsa，一看“Tiny”这个词，大家应该能猜到这是一个ALSA的缩减版本。实际上在Android系统的其它地方也可以看到类似的做法——既想用开源项目，又嫌工程太大太繁琐，怎么办？那就只能瘦身了，于是很多Tiny-XXX就出现了。

-- 因为涉及到的库和相关类是非常多的，建议大家在理解的时候分为两条线索：
  其一，以库为线索。比如AudioPolicyService和AudioFlinger都是在libaudioflinger库中;而AudioTrack、AudioRecorder等一系列实现则在libmedia库中。
  其二，以进程为线索。库并不代表一个进程，进程则依赖于库来运行。虽然有的类是在同一个库中实现的，但并不代表它们会在同一个进程中被调用。比如AudioFlinger和AudioPolicyService都驻留于名为mediaserver的系统进程中;而AudioTrack/AudioRecorder和MediaPlayer/MediaRecorder一样实际上只是应用进程的一部分，它们通过binder服务来与其它系统进程通信。
  在分析源码的过程中，一定要紧抓这两条线索，才不至于觉得混乱。

  音频方面的硬件抽象层主要分为两部分，即AudioFlinger和AudioPolicyService。实际上后者并不是一个真实的设备，只是采用虚拟设备的方式来让厂商可以方便地定制出自己的策略。

> DRM
Android中DRM版权保护机制的研究- https://blog.csdn.net/wlqingwei/article/details/43982395
数字版权保护（Digital Right Management，DRM）- https://blog.csdn.net/wi__wi/article/details/51065808
  数字版权保护（Digital Right Management，DRM），DRM不是一项技术，而是一类技术。很多机构和联盟都提出过相应的DRM标准。例如Open Mobile Alliance推出的OMA DRM、Marlin Developer Community提出的Marlin DRM，而Google则通过收购Widevine公司推出了Widevine DRM。
  从Android智能终端来看，Google的原生Android（Android Open Source Project，简称AOSP）系统仅仅集成了OMA DRM V1的一部分功能，它远未构成一个完整的DRM解决方案。在这种情况下，设备厂商只能根据情况选择合适的DRM解决方案并集成到Android平台中来。例如，手机厂商可以通过Google的授权以获取Widevine DRM对应的软件包从而将Widevine DRM集成到自己的产品中。
  为了方便设备厂商的集成，Android设计了一个通用的DRM软件框架DrmManagerClient，不同的DRM解决方案可通过Plugin的方式集成到Android系统中。