Jack的博客

surfaceflinger创建Connection对象的过程前面已经论述过,在此就不赘述了。Surfaceflinger中接收vsync信号的入口为MessageQueue的cb_eventReceiver方法,调用流程图如下,cb_eventReceiver方法如下,直接调用eventReceiver方法,MessageQueue* queue = reinterpret_cast<Me...

还是以SurfaceFlinger为例论述。SurfaceFlinger的init方法会调用MessageQueue的setEventThread方法创建Connection对象,并且还会调用Looper的addFd方法将BitTube对象的文件描述符添加到Looper中进行监听,mEventThread = eventThread;mEvents = eventThread->creat...

在SurfaceFlinger的init方法中,构造了2个EventThread类型的线程,mEventThread = new EventThread(vsyncSrc, *this, false);sp<VSyncSource> sfVsyncSrc = new DispSyncSource(&mPrimaryDispSync, sfVsyncPhaseOffse...

在SurfaceFlinger的构造方法中调用了DispSync的init方法对DispSync进行初始化,mPrimaryDispSync.init(hasSyncFramework, dispSyncPresentTimeOffset);调用流程图如下,DispSync的构造方法如下,DispSync::DispSync(const char* name) : mName(name),...

上个小节说明了HWC模块的加载等操作,并且也说明了HWC模块主要用于产生vsync信号,现在的问题是, vsync信号是如何产生的呢? 又是如何传输到SurfaceFlinger 中,处理的呢?在上面的论述中,HWComposer 的构造方法在加载完FB模块打开设备文件以及加载HWC模块之后,会注册vsync信号,mHwc->registerProcs(mHwc, &mCBConte...

HWComposerVsync信号的产生有两种来源，一种是硬件，也就是显示模块产生;另外一种是软件模拟，因为目前基本都是硬件产生的，所以软件模拟的代码就没有分析的必要了。接下来分析由硬件产生的vsync是怎么传到surfaceflinger的。这个硬件源就是HWComposer，它一方面管理这composer的hal模块，composer模块是厂商定制UI合成的接口，通常不会直接操作HWCompo...

surfaceflinger进程surfaceflinger是一个守护进程,开机启动。surfaceflinger代码的路径如下,frameworks
ative\services\surfaceflinger在android 8.1系统中, surfaceflinger进程对应的配置不是在init.rc中,而是在surfaceflinger.rc中,如下,service surfaceflin...

下面分析一个文件hardware/libhardware/hardware.c,这个文件提供了一些函数,上层通过这些函数可以用来查找加载HAL库,以及获取指定HAL库的模块变量;load方法如下,static int load(const char *id, const char *path,const struct hw_module_t **pHmi){int status;

3, HAL接口层所有的HAL moudle需要涉及如下三个关键结构体：struct hw_module_t;struct hw_module_methods_t;struct hw_device_t;用户一般需要基于上面这些结构体设计如下两个结构体：struct xxx_module_t {struct hw_module_t common;.};自定义一个模块

NativeSensorManagerNativeSensorManager定义如下,class NativeSensorManager : public Singleton {friend class Singleton;NativeSensorManager();~NativeSensorManager();struct sensor_t sensor_list[MAX_SEN

2, sensor中间层HAL的中间层通过几个类来描述和管理每个sensor,类CalibrationManager管理sensor用到的校正算法模块,NativeSensorManager类则起承上启下的作用,  framework层访问标准的HAL接口,然后这些HAL接口再通过NativeSensorManager类接口访问到具体的sensors,同时所有sensor信息也是由这个

virtual sensorVirtualSensor是由实际的sensor 虚拟出来的,所有的Virtual Sensor都是class VirtualSensor类的一个实例;VirtualSensor类的定义如下,class VirtualSensor : public SensorBase {sensors_event_t mLastEvent;bool reportL

概述:Android的硬件抽象层,简单来说,就是对Linux内核驱动程序的封装,向上提供接口,屏蔽低层的实现细节。也就是说,把对硬件的支持分成了两层,一层放在用户空间（User Space）,一层放在内核空间（Kernel Space）,其中,硬件抽象层运行在用户空间,而Linux内核驱动程序运行在内核空间。为什么要这样安排呢？把硬件抽象层和内核驱动整合在一起放在内核空间不可行吗？从技术实现的角度...

3.2 更新insert/ delete/ update 三个方法执行的流程几乎完全相同,以update方法为例进行论述。update方法主要逻辑如下,1,根据不同类型为参数赋值,case ADN: efType = IccConstants.EF_ADN; subId = SubscriptionManager.getDefaultSubId();break;

1.2回调处理回调主要是通过消息的形式,首先是IccFileHandler的EVENT_EFEXT1_LINEAR_RECORD_SIZE_DONE 消息,然后是AdnRecordCache的EVENT_LOAD_ALL_ADN_LIKE_DONE消息,最后处理IccPhoneBookInterfaceManager的EVENT_LOAD_DONE消息时唤醒子线程。 回调处理的

6.3 联系人操作在前面已经论述过, SIM卡中的联系人是保存在单独的数据库中,其对应的Provider为IccProvider,在packages\services\Telephony 路径下,也就是phone进程中。并且,增删改查直接看jar包中的IccProvider类就可以了, IccProvider路径如下,frameworks/opt/telephony/src/java/co

6.2 IccCardProxy在phone进程初始化过程中, PhoneProxy的构造方法中会构造IccCardProxy对象,mIccCardProxy = new IccCardProxy(mContext, mCommandsInterface, mActivePhone.getPhoneId());IccCardProxy的构造方法注册SIM卡状态变化的代码如下,mUi

6,SIM卡SIM卡主要的内容包括,SIM卡信息的状态的变化。其中,状态的变化主要是从Modem到RIL守护进程最后上报给phone进程的RIL.java的。6.1 状态变化SIM卡状态的变化主要通过UiccController,这个类在phone进程初始化的时候会进行初始化。UiccController的构造方法如下,mContext = c; //进程上下文mCis =

一键合并联系人的MergeContacts方法调用流程图如下,MergeContacts方法如下,mMergeTask = new QueryContactDetailAndMergeTask(this);mMergeTask.execute(mSubGroupContactsIds);构造QueryContactDetailAndMergeTask对象并调用execu

5.2显示查询完成之后, QuerypartRepeartContactsTask 的onPostExecute方法调用流程图如下,onPostExecute方法主要逻辑如下,((MergeallActivity)target).updateAdapterData(result);MergeallActivity的updateAdapterData方法如下,mAda