9527的专栏

Android开发中，有时候要实现应用程序之间的跳转，在知道包名与Activity的情况下，可以采用下面的方法实现。[java] view plain copy// 简单的写法：  Intent intent = new Intent();  intent.setClassName("com...(包名) ", "com....(完整

native_setup函数讲解：private void final int native_setup(Object camera_this,int cameraId, int halVersion, String packageName);这个方法在JNI层通过Binder通信请求Server端的ICameraService去初始化摄像头。在Server端ICameraServ

pen之new

Camera的架构与Android系统的整体架构保持一致，如下图所示，本文主要从以下四个方面对其进行说明。Framework：Camera.javaAndroid Runtime：android_hardware_Camera.cppLibrary：Camera Client和Camera ServiceHAL：CameraHardwareInterface

转载博客：点击打开链接上一篇文章  android Camera --- 架构简介         地址： http://blog.csdn.net/andyhuabing/article/details/7229557   对其层次结构进行了简要的介绍，这篇文章主要针对其数据流程进行分析。Camera一般用于图像浏览、拍照和视频录制。这里先对图像浏览和拍照的数

转载：点击打开链接目前需要做一个语音通话及视频聊天功能开发，主要分为音频及视频两个部分，必然会涉及到Camera及AudioFlinger部分，对于显示部分又会涉及到SurfaceFlinger部分，因此需要一步步的进行学习并确认设计是否合理.这篇文章主要针对Camera作个简要的介绍，了解需要开发的各个环节。摄像头系统提供的功能如下几个方面

一、命令流程1.APPpackages/apps/Camera/src/com/android/camera/PhotoModule.java[java] view plain copyprivate void startPreview() {    mCameraDevice.setPreviewDispla

我们已经把大致的流程已经贯穿完了，还有很多东西没有讲，日后慢慢再说。不过现在有一个重要的问题，就是整个流利里各种buf，provider，bufmgr，queue类等之间的关系，说白了就是buf类和buf辅助类之前的关系。理清这些类的关系和这些类的作用，再从Buf流理解一下整个框架，CamAdapter和CamClient是怎么通过Buf联系，会对日后的分析有一个很大的帮助。也相当于对本文的一个总

Camera的数据来源及Camera的管理 我们接着第3篇，再返回Cam1DeviceBase::startPreview()的(4) mpCamAdapter->startPreview()。在讲(4)前我们先来看看(1)onStartPreview()。onStartPreview();的实现在DefaultCam1Device.cppDefaultCam1Device

Preview的显示流程这次我们要从最开始startPreview的时候开始，在starPreview之间就setPreviewWindow()。//CameraClient.cppstatus_t CameraClient::startPreviewMode() { mHardware->previewEnabled(); mHardware->setPrevie

Camera startPreview流程上接第一篇，这个过程的主要任务是，如何读取数据的，读取的数据是什么格式，最好能知道是如何去预览的上层APP调用的是Camera.java的startPreview();，下面列出startPreview的调用流程//Camera.javapublic native final void startPreview(); /

转载于：点击打开链接系统：MTK Android4.4日期：2015年10月10日stamp&data  setParameters  Utils::Property::tryGet一. 前述之前对MTK的Camera的源码流程有过初步的了解，现在对以前了解的东西做一些梳理总结，但也仅是对源码流程一个贯穿，并不会对其进行深入分析，方便日后

Bn意味着Binder Native 端Bp是Binder Proxy端，这两端会实现相同的接口，但Proxy端只是通过binder ipc发送一个binder transaction，native端是真正做事情，再将结果返回。Android用此机制实现高效的远程调用Bn    n 就是native，这是一个怎样的类？ 我们继承它的原因是为了实现一个接口，具体点说就是一

之前写的EEPRPOM是直接在Android系统下直接编写的，JNI代码的实现依靠hal层的方法，即包含了：#include    #include    所以实现起来依赖关系很严重，而上层app的开发需要有自己生成的jni的.h方法，导致上下不通，具体体现在：例如 open方法：/*通过硬件抽象层定义的硬件模块open接口打开硬件设备*/         static