androidapi16对应版本

① android API Level与sdk版本对照表

API等级1： Android 1.0
API等级2： Android 1.1 Petit Four 花式小蛋糕
API等级3： Android 1.5 Cupcake 纸杯蛋糕
API等级4： Android 1.6 Donut 甜甜圈
API等级5： Android 2.0 Éclair 松饼
API等级6： Android 2.0.1 Éclair 松饼
API等级7： Android 2.1 Éclair 松饼
API等级8： Android 2.2 - 2.2.3 Froyo 冻酸奶
API等级9： Android 2.3 - 2.3.2 Gingerbread 姜饼
API等级10：Android 2.3.3-2.3.7 Gingerbread 姜饼
API等级11：Android 3.0 Honeycomb 蜂巢
API等级12：Android 3.1 Honeycomb 蜂巢
API等级13：Android 3.2 Honeycomb 蜂巢
API等级14：Android 4.0 - 4.0.2 Ice Cream Sandwich 冰激凌三明治
API等级15：Android 4.0.3 - 4.0.4 Ice Cream Sandwich 冰激凌三明治
API等级16：Android 4.1 Jelly Bean 糖豆
API等级17：Android 4.2 Jelly Bean 糖豆
API等级18：Android 4.3 Jelly Bean 糖豆
API等级19：Android 4.4 KitKat 奇巧巧克力棒
API等级20 : Android 4.4W KitKat with wearable extensions奇巧巧克力棒
API等级21：Android 5.0-5.0.2 Lollipop 棒棒糖
API等级22：Android 5.1 Lollipop 棒棒糖
API等级23：Android 6.0 MarshMallow

② Android API版本对照表及各个版本特性简单描述

5、提供屏幕虚拟键盘
6、主屏幕增加音乐播放器和相框widgets
7、应用程序自动随着手机旋转
8、短信、Gmail、日暦，浏览器的用户接口大幅改进，如Gmail可以批量删除邮件
9、相机启动速度加快，拍摄图片可以直接上传到Picasa
10、来电照片显示

主要的更新如下：
1、优化硬件速度
2、 “Car Home”程序
3、支持更多的屏幕分辨率
4、改良的用户界面
5、新的浏览器的用户接口和支持HTML5
6、新的联系人名单
7、更好的白色/黑色背景比率
8、改进Google Maps3.1.2
9、支持Microsoft Exchange
10、支持内置相机闪光灯
11、支持数码变焦
12、改进的虚拟键盘
13、支持蓝牙2.1
14、支持动态桌面的设计

5、任务管理器可滚动，支持USB 输入设备（键盘、鼠标等）。
6、支持 Google TV、可以支持XBOX 360无线手柄
7、widget支持的变化，能更加容易的定制屏幕widget插件。

7、具有开关切换的用户界面
8、全新的电源管理系统
9、更为轻便的主题模式
10、全新的锁屏页面
11、全新的时钟界面

③ android 21 是什么版本

android每一个系统版本都对应一个编号的，21代表安卓5.0系统，23代表安卓6.0系统。

API等级15：Android 4.0.3 - 4.0.4 Ice Cream Sandwich

API等级16：Android 4.1 Jelly Bean

API等级17：Android 4.2 Jelly Bean

API等级18：Android 4.3 Jelly Bean

API等级19：Android 4.4 KitKat

API等级20：Android 4.4W

API等级21：Android 5.0 Lollipop

API等级22：Android 5.1 Lollipop

API等级23：Android 6.0 Marshmallow

(3)androidapi16对应版本扩展阅读：

从2009年5月开始，Android操作系统改用甜点来作为版本代号，这些版本按照从C大写字母开始的顺序来进行命名：纸杯蛋糕（Cupcake）、甜甜圈（Donut）、闪电泡芙（Éclair）、冻酸奶（Froyo）、姜饼（Gingerbread）。

蜂巢（Honeycomb）﹑冰淇淋三明治（Ice Cream Sandwich）、果冻豆（Jelly Bean）、奇巧（KitKat）、棒棒糖（Lollipop）、棉花糖（Marshmallow）、牛轧糖（Nougat）、奥利奥（Oreo ）、馅饼（Pie）。

④ Android原生编解码接口 MediaCodec 之——完全解析

MediaCodec 是Android 4.1(api 16)版本引入的编解码接口， Developer 官网 上描述的已经很清楚了。可以配合 中文翻译 一起看。理解更深刻。

MediaCodec的工作流程：

从上图可以看出 MediaCodec 架构上采用了2个缓冲区队列，异步处理数据，并且使用了一组输入输出缓存。
你请求或接收到一个空的输入缓存（input buffer），向其中填充满数据并将它传递给编解码器处理。编解码器处理完这些数据并将处理结果输出至一个空的输出缓存（output buffer）中。最终，你请求或接收到一个填充了结果数据的输出缓存（output buffer），使用完其中的数据，并将其释放给编解码器再次使用。
具体工作如下：

MediaCodec的基本调用流程是：

1.初始化MediaCodec，方法有两种，分别是通过名称和类型来创建，对应的方法为：

2.配置编码器，设置各种编码器参数（MediaFormat），这个类包含了比特率、帧率、关键帧间隔时间等。然后再调用 mMediaCodec .configure，对于 API 19 以上的系统，我们可以选择 Surface 输入：mMediaCodec .createInputSurface，

3.打开编码器，获取输入输出缓冲区

获取输入输出缓冲区在api19 上是以上方式获取，api21以后 可以使用直接获取ByteBuffer

4.输入数据，有2种方式，一种是普通输入，一种是Surface 输入
普通输入又可区分为两种情况，一种是配合MediaExtractor ，一种是取原数据；

返回一个填充了有效数据的input buffer的索引，如果没有可用的buffer则返回-1，参数为超时时间(TIMES_OUT)，单位是微秒，当timeoutUs==0时，该方法立即返回；当timeoutUs<0时，无限期地等待一个可用的input buffer，当timeoutUs>0时，
等待时间为传入的微秒值。

上面输入缓存的index，通过getInputBuffers()得到的是输入缓存数组，通过index和输入缓存数组可以得到当前请求的输入缓存，在使用之前要clear一下，避免之前的缓存数据影响当前数据，接着就是把数据添加到输入缓存中，并调用queueInputBuffer(...)把缓存数据入队；

5.输出数据
通常编码传输时每个关键帧头部都需要带上编码配置数据（PPS，SPS），但 MediaCodec 会在首次输出时专门输出编码配置数据，后面的关键帧里是不携带这些数据的，所以需要我们手动做一个拼接；

6.使用完MediaCodec后释放资源
要告知编码器我们要结束编码，Surface 输入的话调用 mMediaCodec .signalEndOfInputStream，普通输入则可以为在 queueInputBuffer 时指定 MediaCodec.BUFFER_FLAG_END_OF_STREAM 这个 flag；告知编码器后我们就可以等到编码器输出的 buffer 带着 MediaCodec.BUFFER_FLAG_END_OF_STREAM 这个 flag 了，等到之后我们调用 mMediaCodec .release 销毁编码器

流控就是流量控制。 为什么要控制，就是为了在一定的限制条件下，收益最大化！
涉及到了 TCP 和视频编码：
对 TCP 来说就是控制单位时间内发送数据包的数据量，对编码来说就是控制单位时间内输出数据的数据量。

TCP 的限制条件是网络带宽，流控就是在避免造成或者加剧网络拥塞的前提下，尽可能利用网络带宽。带宽够、网络好，我们就加快速度发送数据包，出现了延迟增大、丢包之后，就放慢发包的速度（因为继续高速发包，可能会加剧网络拥塞，反而发得更慢）。

视频编码的限制条件最初是解码器的能力，码率太高就会无法解码，后来随着 codec 的发展，解码能力不再是瓶颈，限制条件变成了传输带宽/文件大小，我们希望在控制数据量的前提下，画面质量尽可能高。
一般编码器都可以设置一个目标码率，但编码器的实际输出码率不会完全符合设置，因为在编码过程中实际可以控制的并不是最终输出的码率，而是编码过程中的一个量化参数（Quantization Parameter，QP），它和码率并没有固定的关系，而是取决于图像内容。 这一点不在这里展开，感兴趣的朋友可以阅读视频压缩编码和音频压缩编码的基本原理。

无论是要发送的 TCP 数据包，还是要编码的图像，都可能出现“尖峰”，也就是短时间内出现较大的数据量。TCP 面对尖峰，可以选择不为所动（尤其是网络已经拥塞的时候），这没有太大的问题，但如果视频编码也对尖峰不为所动，那图像质量就会大打折扣了。如果有几帧数据量特别大，但仍要把码率控制在原来的水平，那势必要损失更多的信息，因此图像失真就会更严重。 这种情况通常的表现是画面出现很多小方块，看上去像是打了马赛克一样，导致画面的局部或者整体看不清楚的情况

配置时指定目标码率和码率控制模式：

码率控制模式有三种：
码率控制模式在 MediaCodecInfo.EncoderCapabilities 类中定义了三种，在 framework 层有另一套名字和它们的值一一对应：

动态调整目标码率：

Android 流控策略选择

下面展示使用MediaExtractor获取数据后，用MediaMuxer重新写成一个MP4文件的简单栗子

⑤ Android -- 音视频基础知识

帧，是视频的一个基本概念，表示一张画面，如上面的翻页动画书中的一页，就是一帧。一个视频就是由许许多多帧组成的。

帧率，即单位时间内帧的数量，单位为：帧/秒 或fps（frames per second）。一秒内包含多少张图片，图片越多，画面越顺滑，过渡越自然。 帧率的一般以下几个典型值：

24/25 fps：1秒 24/25 帧，一般的电影帧率。

30/60 fps：1秒 30/60 帧，游戏的帧率，30帧可以接受，60帧会感觉更加流畅逼真。

85 fps以上人眼基本无法察觉出来了，所以更高的帧率在视频里没有太大意义。

这里我们只讲常用到的两种色彩空间。

RGB的颜色模式应该是我们最熟悉的一种，在现在的电子设备中应用广泛。通过R G B三种基础色，可以混合出所有的颜色。

这里着重讲一下YUV，这种色彩空间并不是我们熟悉的。这是一种亮度与色度分离的色彩格式。

早期的电视都是黑白的，即只有亮度值，即Y。有了彩色电视以后，加入了UV两种色度，形成现在的YUV，也叫YCbCr。

Y：亮度，就是灰度值。除了表示亮度信号外，还含有较多的绿色通道量。

U：蓝色通道与亮度的差值。

V：红色通道与亮度的差值。

音频数据的承载方式最常用的是 脉冲编码调制 ，即 PCM 。

在自然界中，声音是连续不断的，是一种模拟信号，那怎样才能把声音保存下来呢？那就是把声音数字化，即转换为数字信号。

我们知道声音是一种波，有自己的振幅和频率，那么要保存声音，就要保存声音在各个时间点上的振幅。

而数字信号并不能连续保存所有时间点的振幅，事实上，并不需要保存连续的信号，就可以还原到人耳可接受的声音。

根据奈奎斯特采样定理：为了不失真地恢复模拟信号，采样频率应该不小于模拟信号频谱中最高频率的2倍。

根据以上分析，PCM的采集步骤分为以下步骤：

采样率，即采样的频率。

上面提到，采样率要大于原声波频率的2倍，人耳能听到的最高频率为20kHz，所以为了满足人耳的听觉要求，采样率至少为40kHz，通常为44.1kHz，更高的通常为48kHz。

采样位数，涉及到上面提到的振幅量化。波形振幅在模拟信号上也是连续的样本值，而在数字信号中，信号一般是不连续的，所以模拟信号量化以后，只能取一个近似的整数值，为了记录这些振幅值，采样器会采用一个固定的位数来记录这些振幅值，通常有8位、16位、32位。

位数越多，记录的值越准确，还原度越高。

最后就是编码了。由于数字信号是由0，1组成的，因此，需要将幅度值转换为一系列0和1进行存储，也就是编码，最后得到的数据就是数字信号：一串0和1组成的数据。

整个过程如下：

声道数，是指支持能不同发声（注意是不同声音）的音响的个数。 单声道：1个声道
双声道：2个声道
立体声道：默认为2个声道
立体声道（4声道）：4个声道

码率，是指一个数据流中每秒钟能通过的信息量，单位bps（bit per second）

码率 = 采样率 * 采样位数 * 声道数

这里的编码和上面音频中提到的编码不是同个概念，而是指压缩编码。

我们知道，在计算机的世界中，一切都是0和1组成的，音频和视频数据也不例外。由于音视频的数据量庞大，如果按照裸流数据存储的话，那将需要耗费非常大的存储空间，也不利于传送。而音视频中，其实包含了大量0和1的重复数据，因此可以通过一定的算法来压缩这些0和1的数据。

特别在视频中，由于画面是逐渐过渡的，因此整个视频中，包含了大量画面/像素的重复，这正好提供了非常大的压缩空间。

因此，编码可以大大减小音视频数据的大小，让音视频更容易存储和传送。

视频编码格式有很多，比如H26x系列和MPEG系列的编码，这些编码格式都是为了适应时代发展而出现的。

其中，H26x（1/2/3/4/5）系列由ITU（International Telecommunication Union）国际电传视讯联盟主导

MPEG（1/2/3/4）系列由MPEG（Moving Picture Experts Group, ISO旗下的组织）主导。

当然，他们也有联合制定的编码标准，那就是现在主流的编码格式H264，当然还有下一代更先进的压缩编码标准H265。

H264是目前最主流的视频编码标准，所以我们后续的文章中主要以该编码格式为基准。

H264由ITU和MPEG共同定制，属于MPEG-4第十部分内容。

我们已经知道，视频是由一帧一帧画面构成的，但是在视频的数据中，并不是真正按照一帧一帧原始数据保存下来的（如果这样，压缩编码就没有意义了）。

H264会根据一段时间内，画面的变化情况，选取一帧画面作为完整编码，下一帧只记录与上一帧完整数据的差别，是一个动态压缩的过程。

在H264中，三种类型的帧数据分别为

I帧：帧内编码帧。就是一个完整帧。

P帧：前向预测编码帧。是一个非完整帧，通过参考前面的I帧或P帧生成。

B帧：双向预测内插编码帧。参考前后图像帧编码生成。B帧依赖其前最近的一个I帧或P帧及其后最近的一个P帧。

全称：Group of picture。指一组变化不大的视频帧。

GOP的第一帧成为关键帧：IDR

IDR都是I帧，可以防止一帧解码出错，导致后面所有帧解码出错的问题。当解码器在解码到IDR的时候，会将之前的参考帧清空，重新开始一个新的序列，这样，即便前面一帧解码出现重大错误，也不会蔓延到后面的数据中。

DTS全称：Decoding Time Stamp。标示读入内存中数据流在什么时候开始送入解码器中进行解码。也就是解码顺序的时间戳。

PTS全称：Presentation Time Stamp。用于标示解码后的视频帧什么时候被显示出来。

前面我们介绍了RGB和YUV两种图像色彩空间。H264采用的是YUV。

YUV存储方式分为两大类：planar 和 packed。

planar如下：

packed如下：

上面说过，由于人眼对色度敏感度低，所以可以通过省略一些色度信息，即亮度共用一些色度信息，进而节省存储空间。因此，planar又区分了以下几种格式：YUV444、 YUV422、YUV420。

YUV 4:4:4采样，每一个Y对应一组UV分量。

YUV 4:2:2采样，每两个Y共用一组UV分量。

YUV 4:2:0采样，每四个Y共用一组UV分量。

其中，最常用的就是YUV420。

YUV420属于planar存储方式，但是又分两种类型：

YUV420P：三平面存储。数据组成为YYYYYYYYUUVV（如I420）或YYYYYYYYVVUU（如YV12）。

YUV420SP：两平面存储。分为两种类型YYYYYYYYUVUV（如NV12）或YYYYYYYYVUVU（如NV21）

原始的PCM音频数据也是非常大的数据量，因此也需要对其进行压缩编码。

和视频编码一样，音频也有许多的编码格式，如：WAV、MP3、WMA、APE、FLAC等等，音乐发烧友应该对这些格式非常熟悉，特别是后两种无损压缩格式。

但是，我们今天的主角不是他们，而是另外一个叫AAC的压缩格式。

AAC是新一代的音频有损压缩技术，一种高压缩比的音频压缩算法。在MP4视频中的音频数据，大多数时候都是采用AAC压缩格式。

AAC格式主要分为两种：ADIF、ADTS。

ADIF：Audio Data Interchange Format。音频数据交换格式。这种格式的特征是可以确定的找到这个音频数据的开始，不需进行在音频数据流中间开始的解码，即它的解码必须在明确定义的开始处进行。这种格式常用在磁盘文件中。

ADTS：Audio Data Transport Stream。音频数据传输流。这种格式的特征是它是一个有同步字的比特流，解码可以在这个流中任何位置开始。它的特征类似于mp3数据流格式。

ADIF数据格式：

ADTS 一帧 数据格式（中间部分，左右省略号为前后数据帧）：

AAC内部结构也不再赘述，可以参考AAC 文件解析及解码流程

细心的读者可能已经发现，前面我们介绍的各种音视频的编码格式，没有一种是我们平时使用到的视频格式，比如：mp4、rmvb、avi、mkv、mov...

没错，这些我们熟悉的视频格式，其实是包裹了音视频编码数据的容器，用来把以特定编码标准编码的视频流和音频流混在一起，成为一个文件。

例如：mp4支持H264、H265等视频编码和AAC、MP3等音频编码。

我们在一些播放器中会看到，有硬解码和软解码两种播放形式给我们选择，但是我们大部分时候并不能感觉出他们的区别，对于普通用户来说，只要能播放就行了。

那么他们内部究竟有什么区别呢？

在手机或者PC上，都会有CPU、GPU或者解码器等硬件。通常，我们的计算都是在CPU上进行的，也就是我们软件的执行芯片，而GPU主要负责画面的显示（是一种硬件加速）。

所谓软解码，就是指利用CPU的计算能力来解码，通常如果CPU的能力不是很强的时候，一则解码速度会比较慢，二则手机可能出现发热现象。但是，由于使用统一的算法，兼容性会很好。

硬解码，指的是利用手机上专门的解码芯片来加速解码。通常硬解码的解码速度会快很多，但是由于硬解码由各个厂家实现，质量参差不齐，非常容易出现兼容性问题。

MediaCodec 是Android 4.1(api 16)版本引入的编解码接口，是所有想在Android上开发音视频的开发人员绕不开的坑。

由于Android碎片化严重，虽然经过多年的发展，Android硬解已经有了很大改观，但实际上各个厂家实现不同， 还是会有一些意想不到的坑。

相对于FFmpeg，Android原生硬解码还是相对容易入门一些，所以接下来，我将会从MediaCodec入手，讲解如何实现视频的编解码，以及引入OpenGL实现对视频的编辑，最后才引入FFmpeg来实现软解，算是一个比较常规的音视频开发入门流程吧。

⑥ 出现No minsdk(API 16)>device sdk(api 1)怎么办不兼容，手机5.0版本的

不会有问题的，由于andrid系统是向下兼容的,也就是说,高版本的SDK会兼容低版本的SDK。
举例说明：
1. 新建一个 Android Project (HelloAndroid), 指定为 Android 2.2 版本，对应的 minSdkVersion 填8，finish;
2. 此时我们运行 HelloAndroid ,会运行一个 2.2 版本的模拟器。
3. 假若现在去 AndroidManifest.xml 文件 中修改 android:minSdkVersion=7，再次运行，那么会在已经打开的 2.2 模拟器上运行。因为 Android API 都是向后兼容的，所以系统在编译时，这个 Project 是利用 2.1 版本来编译的，但也可以在 2.2 模拟器上运行；若先把 2.2 模拟器关闭，再运行 HelloAndroid 这个Project 的话，那么会新建一个 API Level=7 的 模拟器来运行这个程序（也就是 2.1模拟器）。
4. 假若修改 android:minSdkVersion=10， 那么无论是否打开了 2.2 版本的模拟器，都会报错：
ERROR: Application requires API version 10. Device API version is 8 (Android 2.2).
Launch canceled。

⑦ Android各个版本的介绍

前言：笔者在面试的过程中，已经被问过不下三次，因此在这里分析一下。可能不够详细，请各位大佬多多包涵。

一、 版本对应的API 级别

API 级别：是对 Android 平台版本提供的框架 API 修订版进行唯一标识的整数值。

1 ，Android 4.4 API 级别是19；

2，Android 5.0 API 级别：21；

3，Android 5.1 API 级别：22；

4，Android 6.0 API 级别：23；

5，Android 7.0 API 级别：24；

6，Android 7.1 API 级别：25；

7，Android 8.0  API 级别：26；

8，Android 8.1 API 级别：27；

9，Android 9  API 级别：28；

10，Android 10  API 级别：29；

二、版本变更

注：只举一些常见的。

Android 4.4

1，文件的读写权限，长期对文件进行读写；

2，增加了webview组件；

3，打印框架，通过 WLAN、蓝牙或其他服务连接的打印机；

4，短信内容的提供，允许应用读写设备的短信和彩信；

5，NFC读取

6，沉浸式

7，透明系统状态栏

8，虚拟机的改变

Android 5.0 

1，webview更新，增加了安全性和稳定性

2，录屏功能

3，camera2

4，多个网络连接

5，蓝牙低功耗

6，NFC增强

7，ART运行时取代了Dalvik成为平台默认设置

8，浮动窗口

Android 6.0 

1，指纹身份认证

2，蓝牙触控笔并且改进蓝牙低功耗

3，4K显示

4，低功耗模式

5，USB连接授权与其他设备连接

6，APK验证更为严格

Android 7.0 

1，增强了低功耗模式，可以监听到用户的行为

2，屏幕缩放

3，快速安装app

4，来电过滤

Android 8.0 

1，自适应启动图标

2，增加了webview的安全性和稳定性

3，多显示器支持，可以一边聊天一边看视频

4，网络连接和 HTTP(S) 连接

5，蓝牙，兼容蓝牙5.0版本超过字节约60的限制

Android 9

1，WIFI RTT可以室内定位

2，DEX 文件的 ART 提前转换

Android 10

1，可折叠设备

2，5G网络

3，保护用户隐私

4，安全性

5，ART 优化

⑧ Android音频开发（三）——音频编解码

上一节中我们讲了怎么采集音频并播放，由于AudioRecord采集的是PCM数据，没有经过处理，所有播放的时候会有杂音，啸叫等现象出现。因此处理掉这些不需要的数据就是本节的内容，编码与解码。

Android官方提供给我们的用于编解码的类是 MediaCodec ,它是android 4.1（API 16）才引入的，所以只能工作于andorid4.1以上的手机，如果想兼容4.1以下版本的手机，只能使用第三方库，如大名鼎鼎的 ffmpeg ,B站的 ijkplayer 等。

（1）提供了一套访问 Android 底层多媒体模块的接口，主要是音视频的编解码接口

（2）在Android上，预设的多媒体框架是基于第三方PacketVideo公司的OpenCORE来实现，OpenCORE的优点是兼顾了跨平台的移植性，而且已经过多方验证，所以相对来说较为稳定；缺点是国语庞大复杂，需要耗费相当多的时间去维护。因此从Android 2.0开始，Google引进了较为简洁的StageFright。Android 底层多媒体模块采用的是 StageFright 框架，它是基于OpenMax标准实现的，任何 Android 底层编解码模块的实现，都必须遵循 OpenMax 标准。值得一提的是，OpenMAX是Khronos制定的API，Khronos也是OpenGL的制定者。Google 官方默认提供了一系列的软件编解码器：包括：OMX.google.h264.encoder，OMX.google.h264.encoder， OMX.google.aac.encoder， OMX.google.aac.decoder 等等，而硬件编解码功能，则需要由芯片厂商依照 OpenMax 框架标准来完成，所以，一般采用不同芯片型号的手机，硬件编解码的实现和性能是不同的

（3）Android 应用层统一由 MediaCodec API 来提供各种音视频编解码功能，由参数配置来决定采用何种编解码算法、是否采用硬件编解码加速等等

根据android官方文档的描述，MediaCodec的核心就是使用缓冲区队列来操作数据，使用流程如下：

//name既是媒体文件的类型，如audio/3gpp，详情参考MediaFormat的MIMETYPE常量
MediaCodec codec = MediaCodec.createByCodecName(name);
codec.configure(format, …);
MediaFormat outputFormat = codec.getOutputFormat(); // option B
codec.start();
for (;;) {
////获取可用的inputBuffer -1代表一直等待，0表示不等待 建议-1,避免丢帧
int inputBufferId = codec.dequeueInputBuffer(-1);
if (inputBufferId >= 0) {
ByteBuffer inputBuffer = codec.getInputBuffer(…);
// fill inputBuffer with valid data
…
codec.queueInputBuffer(inputBufferId, …);
}
//执行上面的操作后就把待编解码的数据存入了输入缓冲区，然后下一步就是操作然后把编解码的数据存入输出缓冲区
int outputBufferId = codec.dequeueOutputBuffer(…);
if (outputBufferId >= 0) {
ByteBuffer outputBuffer = codec.getOutputBuffer(outputBufferId);
MediaFormat bufferFormat = codec.getOutputFormat(outputBufferId); // option A
// bufferFormat is identical to outputFormat
// outputBuffer is ready to be processed or rendered.
…
codec.releaseOutputBuffer(outputBufferId, …);
} else if (outputBufferId == MediaCodec.INFO_OUTPUT_FORMAT_CHANGED) {
// Subsequent data will conform to new format.
// Can ignore if using getOutputFormat(outputBufferId)
outputFormat = codec.getOutputFormat(); // option B
}
}
codec.stop();
codec.release();

MediaCodec codec = MediaCodec.createByCodecName(name);
MediaFormat mOutputFormat; // member variable
codec.setCallback(new MediaCodec.Callback() {
@Override
void onInputBufferAvailable(MediaCodec mc, int inputBufferId) {
ByteBuffer inputBuffer = codec.getInputBuffer(inputBufferId);
// fill inputBuffer with valid data
…
codec.queueInputBuffer(inputBufferId, …);
}

@Override
void onOutputBufferAvailable(MediaCodec mc, int outputBufferId, …) {
ByteBuffer outputBuffer = codec.getOutputBuffer(outputBufferId);
MediaFormat bufferFormat = codec.getOutputFormat(outputBufferId); // option A
// bufferFormat is equivalent to mOutputFormat
// outputBuffer is ready to be processed or rendered.
…
codec.releaseOutputBuffer(outputBufferId, …);
}

@Override
void onOutputFormatChanged(MediaCodec mc, MediaFormat format) {
// Subsequent data will conform to new format.
// Can ignore if using getOutputFormat(outputBufferId)
mOutputFormat = format; // option B
}

@Override
void onError(…) {
…
}
});
codec.configure(format, …);
mOutputFormat = codec.getOutputFormat(); // option B
codec.start();
// wait for processing to complete
codec.stop();
codec.release();

MediaCodec codec = MediaCodec.createByCodecName(name);
codec.configure(format, …);
codec.start();
//API的区别在这里
ByteBuffer[] inputBuffers = codec.getInputBuffers();
ByteBuffer[] outputBuffers = codec.getOutputBuffers();
for (;;) {
int inputBufferId = codec.dequeueInputBuffer(…);
if (inputBufferId >= 0) {
// fill inputBuffers[inputBufferId] with valid data
…
codec.queueInputBuffer(inputBufferId, …);
}
int outputBufferId = codec.dequeueOutputBuffer(…);
if (outputBufferId >= 0) {
// outputBuffers[outputBufferId] is ready to be processed or rendered.
…
codec.releaseOutputBuffer(outputBufferId, …);
} else if (outputBufferId == MediaCodec.INFO_OUTPUT_BUFFERS_CHANGED) {
outputBuffers = codec.getOutputBuffers();
} else if (outputBufferId == MediaCodec.INFO_OUTPUT_FORMAT_CHANGED) {
// Subsequent data will conform to new format.
MediaFormat format = codec.getOutputFormat();
}
}
codec.stop();
codec.release();

⑨ 如何查看Android APP能够运行的最低系统版本

使用Android自带工具 aapt 即可，以Windows平台为例。

首先进入Android SDK安装目录，

运行命令 aapt ，

然后用记事本之类的软件（这里使用 Notepad++ ）打开刚刚生成的文件 wexin_740_sdk_v.txt ，搜索关键字 minSdkVersion ，如图 1-1。

可以看到 minSdkVersion 的值是 0xf（十六进制），即 API 级别为 15（十进制）。参照图 1-2，可以知道对应的 Android 平台版本为 Android 4.0.3、4.0.4 ，也就是说该APP能够运行的最低系统版本为 Android 4.0.3 。

PS. API 级别（API LEVEL）是一个对 Android 平台版本提供的框架 API 修订版进行唯一标识的整数值。可以认为API 级别是内部可见的（用户不关心），而 Android 平台的版本提供了新特性给用户，是外部可见的（用户关心）。

Android 平台版本与API级别的最新对应关系可以查看以下网址：
https://developer.android.com/guide/topics/manifest/uses-sdk-element.html#ApiLevels

⑩ Android开发环境搭建：jdk版本为1.7，sdk 版本选择哪个合适

现在android开发，都是使用android studio这个官方提供的IDE，它有自带的jdk的，目前官方默认自带的jdk版本是1.7的，存储在你的android studio安装目录下的jre目录，你可以在android studio操作界面 File-->Project Structure 打开操作界面，SDK Location就能看到JDK location了，也可以在这里进行修改。
其实使用jdk1.7 和1.8的区别，仅仅在于你的java代码编写方面，1.8的版本，支持一些更简洁的语法表达式，从某种意义上来说，这只是程序语言的进化而已。就好比最早的程序，使用10101010，但实现一个功能，可能需要写N多的101010，于是出了编程语言，比如C，C++，用几行英文单词来释义，就大大减少了工作量，然后在c++的基础上，诞生了java，剔除了繁杂的指针问题，再到现在主流的python，以前c++,java代码10行才能实现的功能，python可能只需要1-2行代码就可以实现了，这就是编程语言的进化
对应的sdk版本，sdk，其实指的是android操作系统的版本，从最早的1.0beta版本到现在的9.0版本，有相当多的变化，目前市面上90%以上的android手机，操作系统都在4.x以上，也就是说，你的程序支持最低的版本，在API 16以上，即可以兼容几乎所有的手机，而target版本，设定在API 25,26即可，最新的API 28,对应的操作系统也就是android9.0，目前还在测试阶段，2018-07-02发布的，不建议把target设置为最新版本