天才之嵌入式

谨以此文于2021/5/24日结束整个Android Camera专栏，术业有专攻，谢谢大家。

前沿：鉴于项目开发的需求，2014年开年到现在，一直在学习Android的视频采集与显示系统在底层的实现机制，通过零基础来死磕这2个模块的Code，主要参考的Blog，书籍有《老罗的Android之旅》，《邓凡平的深入理解Android卷I和II》。Blog记录的内容主要是自己学习与熟悉时，遇到的困难与疑惑，以及Android架构中特有的设计思想，编码方式等等，在此和所以嵌入式开发的爱好者一起交流

step1：之前在讲到CameraService处的setPreviewWindow中传入一个窗口给HAL status_t setPreviewWindow(const sp& buf) { ALOGV("%s(%s) buf %p", __FUNCTION__, mName.string(), buf.get()); if (mDevice->o

之前的10篇博文主要是记录了Android4.2.2的SurfaceFlinger的相关内容，为何之前会投入那么多的时间，原因就在于之前在看camera的架构时，遇到了本地的ANativeWindow和Surface的内容。而这些是SurfaceFlinger中最常见的应用端的使用品。故而在学习完了SurfaceFlinger之后就来看看Camera的的架构内容。这里先和大家分享android4.

这里单独以preview的控制和数据流来进行相关的camera的调用处理，主要先引入Camera 的HAL层的处理结构。调用还是先从camera的JNI和HAL两个方面来分析： step1：启动预览startPreview()// start preview modestatus_t Camera::startPreview(){ ALOGV("startPreview");

本文均属自己阅读源码的点滴总结，转账请注明出处谢谢。欢迎和大家交流。qq:1037701636 email:gzzaigcn2012@gmail.comAndroid源码版本Version：4.2.2; 硬件平台 全志A31 FrameBufferSurface类，SurfaceFlinger处的本地的帧缓存，实际意义上的显存FramebufferSurface::FramebufferSurfa

前一博文总结了Android4.2.2 SurfaceFlinger之图形缓存区申请与分配dequeueBuffer的实现，由于受到OpenGL Es的中介作用（内部实现图层绘制并写入到分配好的图形缓存中去），eglSwapBuffers()函数内部的实现就是如此。好了作为生产者以及使用dequeueBuffer获取了图形缓存并写入了绘图数据，这下就该是渲染的过程queueBuffer来看看他的实

前几天把android init 进程看了一遍，这次回过头来再把android系统启动的Logo相关学习内容做一个梳理和总结。我们知道android系统的启动logo包括3个启动画面（这里不对uboot中的logo做解析），第一个是android系统启动时，linux内核启动阶段显示的logo，这个和普通的linux像类似。下面主要针对logo的相关修改以及一些配置和注意点做个总结。1.第一个

这段时间，断断续续的忙了一阵，因为父亲的去世也不情愿的休息了20来天，一点也没有办法。回来后重新开始学习android的启动流程。对android系统级别的学习，阅读代码成为了唯一的办法，不像应用程序开发来得那么明了快捷。之前花了好多时间才对android的binder驱动做了一定的了解，最近几天从android的启动画面，分析到了init这个内核最先启动的一个进程。参考内容包括老罗的androi

接着前面的BootAnimation的启动过程，可以看到内部会涉及很多OpenGL ES的相关操作，OpenGL ES通过之前创建的具备有SurfaceTexture等的Surface类，来操作远端的SF来完成相关的图像渲染。这里主要涉及到ANativeWindow的2个核心回调函数，OpenGL ES在应用层的eglSwapBuffers就是调用了QueueBuffer和DequeueBuf

之前的博文在BootAnimation的基础上来到了SurfaceFlinger端的Surface的创建过程，具体实现由Client的createSurface来完成。其实所谓在客户端的Surface在服务端是以Layer图层的名字存在。sp Client::createSurface( ISurfaceComposerClient::surface_data_t* param

本文均属自己阅读源码的点滴总结，转账请注明出处谢谢。欢迎和大家交流。qq:1037701636 email:gzzaigcn2012@gmail.comAndroid源码版本Version：4.2.2; 硬件平台 全志A31 前面的几张博文都在记录SurfaceFLinger侧，也就是所谓的Server端，接下去就和大家来看看客户端是如何将要处理的图形信息请求SF来传递出去的呢

在前面的博文中，可以发现在SurfaceFlinger中的OnFirstRef里面有如下函数：void SurfaceFlinger::onFirstRef(){ mEventQueue.init(this); run("SurfaceFlinger", PRIORITY_URGENT_DISPLAY);//启动一个新的thread线程，调用thread类的run函数

在介绍FrameWork是不得不提的是HAL（硬件抽象层）一般是用来和特点的硬件平台进行交互的，所以不同的android平台主要的区别也就是在这个部分，HAL的好处在于一个FrameWork可以调用不同的HAL，只需要相关的HAL满足一定接口规范即可。另一方面HAL的好处是可以屏蔽相关对底层硬件操作的应用代码。网上对HAL的介绍内容已经很多，这里就简单和大家分享我所深入去了解的HAL层的相关规

接着上文的SF启动流程，这里单独拎出来分析SurfaceFlinger::readyToRun()函数。里面的知识点比较多，只能和大家分享自己所知道的，共同交流学习。status_t SurfaceFlinger::readyToRun(){ ALOGI( "SurfaceFlinger's main thread ready to run. " "Init

这周继续我的Blog，前面几篇博文简单的介绍了阅读Android FW的源码所需要的基础知识，主要和C++相关。从这篇博文开始将会和大家一起学习并总结SurfaceFlinger模块在Android中的相关内容，本文主要描述的是SurfaceFlinger的详细启动流程。 1.SurfaceFlinger在哪里启动？在android系统中一个核心的Service都有ServiceMan

在阅读Android的Framework处的代码可以发现，无处不在SP给予了我视觉上的冲击，这个是什么？初级的我，看这个当初就基本当成指针来用，熟不知其的内在美，于是在这里和大家一起学习总结SP类的魅力所在。1 SP这货是个模板类，让我们看下他的结构。template class sp{public: inline sp() : m_ptr(0) { } sp(T*

这篇博文其实就是想简单的来记录下Binder驱动在Android中的重要性，早在2012年的时候就按着2.3的源码深入学习过Binder驱动的底层实现（Android之binder驱动个人学习小结），Binder驱动主要是android为了构建C/S的通信模型而量身定做的，没有过多复杂的协议，一个Parcl基本包含了所要传递的所有信息，本文就对FrameWork从运用到的Binder机制做一个

俗话说，良好的开头是成功的一半。研究Android庞大的系统代码（话说编译完4.2.2的源码大概也就10多个G吧），工具上至少要高大上，心态上必要低奢内，本着Read The Fucking Code的不死精神，大脚大脚的向前走，死不要脸的读下去。然后，然后，最终你就会看到那阳光是多么的灿烂，拨开云雾见天日的优越感瞬间会冲刷着你的最强大脑。 一.写一下属于我的Android4.2.2 FW