洪伟的专栏

nanosleep （高分辨率睡眠）可实现纳秒级的睡眠，暂停调用线程的执行。在 Linux 内核中是如何实现的？下面基于 arm64 cpu 架构去分析。

Camera v1 startPreview 起点位于 android.hardware 包下的 Camera 类中，这是老版本的 Camera 预览的起点。有助于理解后续 Camera v2 API 所做的努力。

使当前正在执行的线程休眠（暂时停止执行）指定的毫秒数，取决于系统计时器和调度器的精度和准确性。

前面已经分析过 MediaRecorder 初始化和配置过程，接下来就可以真正进入录制流程了。现在不难得出这个结论：MediaRecorder 录制 Camera 的数据实际上是将预览数据经过 MediaCodec 硬编码后封装成对应的容器。具体到现在谈的场景实际上将渲染数据直接绘制到硬编码器 Surface 上然后去编码，编码后的数据是 H264，将 MIC 音频硬编码为 AAC，然后将它们封装成 MP4。开始捕获数据并将数据编码到使用 setOutputFile() 指定的文件中。在 prepare

MediaRecorder 录像配置主要涉及输出文件路径、音频来源、视频来源、输出格式、音频编码格式、视频编码格式、比特率、帧率和视频尺寸等。我们假设视频输入源来自 Camera，Camera2 API 将相机图像渲染到 MediaRecorder 提供的 Surface 上，而 MediaRecorder 将这个渲染数据编码为 H264。 /** * 配置录制视频相关数据 */ private void configMediaRecorder(){ F

MediaRecorder 用于录制音频和视频，录制控制基于一个简单的状态机。下面是典型的使用 camera2 API 录制，需要使用到的 MediaRecorder API。 /** * 初始化MediaRecorder */ private void initMediaRecorder(){ mMediaRecorder = new MediaRecorder(); } /** * 配置录制视频相关数据 */

BatteryService 是在 SystemServer 中启动的，BatteryService 监控设备电池的充电状态和充电水平。当这些值改变时，这个服务会将这些新值广播给所有正在监听 ACTION_BATTERY_CHANGED 的广播接收者。BatteryService 被划分到核心服务类别。frameworks/base/services/java/com/android/server/SystemServer.javapublic final class SystemServer {

Android 9 引入了从 health@1.0 HAL 升级的主要版本 android.hardware.health HAL 2.0。

health@1.0：android.hardware.health@1.0 的缩写。指的是 Android 8.0 中发布的运行状况 HIDL 的 1.0 版 HAL。Android 8.x 中的“运行状况”服务在 Android 8.x 中，运行状况组件的工作原理详情如下图所示：在此图中：框架通过一次 Binder 调用和一次 hwbinder 调用与硬件进行通信。healthd 静态关联到 libhealthd_android、libbatterymonitor 和 libbattery

Linux 内核中为了方便对 battery 的管理，专门提供了power supply framework。battery 管理分开为两个部分，一个是电池监控（fuelgauge），另一个是充放电管理（charger）。fuelgauge 驱动主要负责向上层 android 系统提供当前电池的电量以及健康状态信息等，另外它也向 charger 驱动提供电池的相关信息；charger 驱动主要负责电源线的插拔检测，以及充放电的过程管理。对于 battery 管理，硬件上有电量计 IC 和充放电 IC。

现在编译 FFmpeg 已经全面采用 Clang 了，gcc 被高版本 NDK 废弃，所以从网上搜索出来的编译脚本既有使用低版本 NDK 编译 FFmpeg 的，也有采用高版本 NDK 编译的。采用低版本 NDK 编译 FFmpeg 虽然也是一种手段，但是采用高版本 NDK 编译 FFmpeg 一定是“大势所趋”。另外就算采用低版本 NDK 去编译 FFmpeg，你会发现高版本的 FFmpeg 编译会报各种错误，有的人甚至修改了 FFmpeg 源码，虽然修改源码最终可以编译完成，但是终究不是解决问题的良方

FFmpeg 解码 H264 主要分三个步骤，其一获取解码器，其二向解码器中送入 H264 NALU，其三从解码器中获取解码后的 YUV 等数据。一、H264H.264，同时也是 MPEG-4 第十部分，是由 ITU-T 视频编码专家组（VCEG）和 ISO/IEC 动态图像专家组（MPEG）联合组成的联合视频组（JVT，Joint Video Team）提出的高度压缩数字视频编解码器标准。这个标准通常被称之为 H.264/AVC（或者 AVC/H.264 或者 H.264/MPEG-4 AVC 或 M

FFmpeg 默认是可以解码 AAC 格式的音频，但是如果需要获取 PCM16 此类数据则需要经过音频转码。首先要打开解码器，然后向解码器发送 AAC 音频帧（不带 ADTS），然后从解码器获取解码后的音频帧，数据是 float 类型的，如果需要则进行转码流程将 float 转成整型。一、AAC 音频AAC 是高级音频编码（Advanced Audio Coding）的缩写，出现于 1997 年，最初是基于 MPEG-2 的音频编码技术。由Fraunhofer IIS、Dolby Laboratorie

CMake 到底在干什么？怎么用！

做 Android 音视频离不开 MediaCodec。实际上不局限于平台看问题，不管是 Linux、Mac OS、iOS、Android 还是 Window 这些系统，只要涉及到音视频编解码，无非要么软编解码、要么硬编解码，软编解码通常会使用瑞士军刀“FFmpeg”，主要靠 cpu 的算力去实现。硬编解码就要调用系统开放的 API 去使用硬件编解码。从效率上看，调用硬件编解码是最快的，通常会使用专用的硬件去处理编解码。尤其在嵌入式设备上通常 cpu 性能有限，想要达到满足要求的编解码需求，不用硬件编解码也

使用 MediaCodec 的关键一步是 configure，在 start 之前配置是必须的。以解码为例，并且直接解码到外部提供的 surface 上，所以输入的 surface 不为空。configure(…) 提供给外部调用的 public 方法内部调用了同名重载版本的方法。遍历从 MediaFormat 返回的 map，构造为 key 和 value 数组；调用 native_configure(…) 交给 native 层处理。frameworks/base/media/java/a

MediaCodec 系列文章：【Android 10 源码】深入理解 MediaCodec 硬解码初始化【Android 10 源码】深入理解 Omx 初始化【Android 10 源码】深入理解 codecservice 启动【Android 10 源码】深入理解 software Codec2 服务启动【Android 10 源码】深入理解构建 MediaCodec 列表：buildMediaCodecList组件分配的起点位于 native MediaCodec 的 init 流程。

构建 MediaCodec 列表——buildMediaCodecList(…) ，确切地说是构建了 std::vector<sp > 容器，容器内部是指向 MediaCodecInfo 对象的指针。关于 buildMediaCodecList(…) 在 MediaCodec 中初始化流程可以参考前一节《【Android 10 源码】深入理解 MediaCodec 硬解码初始化》。在 MediaCodecList 构造函数中，根据分析得出 builder 调用其 buildMediaCode

经过前面几节分析不难得出想要支持 Codec2 框架，需要实现其要求的 hal 接口，并实现相应的支撑服务。这里以源码中实现 software Codec2 服务启动为例进行分析。software Codec2 服务启动位于 CodecServiceRegistrant.cpp 中。在 rk3399 Android 10 平台上可以看到启动 Log：CodecServiceRegistrant: Creating software Codec2 service…CodecServiceRegistra

MediaCodec 系列文章：【Android 10 源码】深入理解 MediaCodec 硬解码初始化【Android 10 源码】深入理解 Omx 初始化codecservice 主要负责 HAL 层给 framework 层提供调用音视频编解码接口。它的入口是 main_codecservice.cpp。首先我们来看下启动它的配置 rc 脚本。可以看到它放在 vendor 目录下，说明和供应商有关。frameworks/av/services/mediacodec/android.ha