皮皮网

皮皮网

【everycircuit源码】【智卓星源码】【repo 下载android源码】servicemanager 源码

时间:2024-11-19 02:24:06 分类:热点

1.Android Binder Hook的实现
2.Framework层的源码Binder(源码分析篇)
3.Android Touch事件InputManagerService源码解析(二)
4.service manager在安卓的什么层中层
5.Android N 四大组件的工作原理

servicemanager 源码

Android Binder Hook的实现

        Binder Hook可以Hook掉当前App用到的系统Service服务。

        以LocationManager为例,在获取一个LocationManager时分为两步。第一,获取IBinder对象;第二:IBinder对象通过asInterface()转化为LocationMangerService对象。最后初始化LocationManager,application层用到的都是LocationManager。

        Hook的大致原理是:ServiceManager在获取某个Binder时,如果本地有缓存的Binder,就不再跨进程请求Binder了。我们可以在缓存中加入自己的Binder,使得ServiceManager查询本地缓存时得到一个自定义的CustomBinder对象,不再跨进程向系统请求。并且ILocationManager.Stub.asInterface(CustomBinder)方法返回我们自定义的Service对象。

        这里面有两个地方需要用到自定义的对象。由于我们只Hook其中一部分的功能,其他功能还需要保留,所以用动态代理的方式创建自定义的Binder和自定义的Service。

        在理解后面的内容前你需要了解这些知识点:

        Activity等类在获取系统Service时,都是调用getSystemService(serviceName)方法获取的。

        Context 的 getSystemService() 方法调用了 SystemServiceRegistry 的 getSystemService() 方法。

        SystemServiceRegistry 中有一个常量 SYSTEM_SERVICE_FETCHERS,这是一个Map。保存了ServiceName和对应的ServiceFetcher。ServicFetcher是用于创建具体Service的类。ServiceFetcher 的关键方法是 createService() 方法。

        在 ServiceFetcher 的 createService() 方法中,调用了 ServiceManager.getService(name) 方法。以 LocationManager 对应的 ServiceFetcher 为例,它的createService()方法源码如下:

        假如我们要修改 LocationManager 的 getLastKnownLocation() 方法(下文都是)。我们要做的就是让ServiceManager.getService("location")返回我们自定义的Binder。先看一下这个方法简化后的源码:

        sCache是一个Map,缓存了已经向系统请求过的Binder。如果我们需要让这个方法返回我们我们自己的binder,只需要事先往sCache中put一个自定义的Binder就行了。

        在put之前,需要先创建出一个自定义的Binder。这个Binder在被 ILocationManager.Stub.asInterface 处理后,可以返回一个自定义的 LocationManagerService。

        先看一下Binder的 asInterface() 的实现:

        如果把 queryLocalInterface()方法返回一个自定义的Service,使得走if语句内部,不走else,那就算是Hook成功了。

        假设我们想让系统的LocationManager返回的位置信息全是在天安门(., .)。那我们需要使得 LocatitionManagerService 的 getLastLocation() 方法 返回的全是 (., .)。

        由于我们不能直接拿到系统的这个Service对象,可以先用反射的方式拿到系统的LocationManagerService。然后拦截getLastLocation()方法。

        原生的Binder对象在调用 queryLocalInterface() 方法时会返回原生的Service对象。我们希望返回3.1中的自定义Service。所以这里拦截 queryLocalInterface() 方法。

        有了自定义的Binder后,将它注入到ServiceManger的sCache变量中就完成Hook了~

        当onClick被调用的时候,Toast和Log都会显示天安门的坐标(., .)。证明Hook成功!

        你甚至可以用Binder Hook的方式Hook掉 ActivityManager。

Framework层的Binder(源码分析篇)

       本文以android-.0.0_r的AOSP分支为基础,解析framework层的源码Binder工作原理。

       从ServiceManager的源码getService方法入手,其核心代码是源码通过getIServiceManager().getService(name)获取服务。首先,源码ServiceManager的源码everycircuit源码实现与进程中的ProcessState密切相关,ProcessState是源码单例,负责打开和映射Binder驱动。源码构造函数中,源码它会初始化驱动、源码验证版本并设置线程数,源码接着进行binder映射。源码

       在ProcessState的源码getContextObject方法中,调用native函数android_util_Binder.cpp中的源码getContextObject()。这个函数通过handle 0(ServiceManager的源码handle)获取BpBinder对象,然后通过javaObjectForIBinder函数将其转换为Java中的类型。

       进一步分析,智卓星源码BpBinder与java层的Binder之间存在对应关系,通过BinderProxy NativeData创建单例的BinderProxy。然后,每个服务的BinderProxy实例化和计数处理都在这个过程中完成。ServiceManagerNative.asInterface方法简化了getIServiceManager的调用,通过调用asInterface实例化ServiceManagerProxy。

       IServiceManager接口通过AIDL生成,其代理类ServiceManagerProxy实际上是repo 下载android源码不必要的。aidl文件在编译时生成对应java代码,用于binder通信。通过aidl文件,我们可以看到如queryLocalInterface等方法的实现细节。

       在Parcel的协助下,客户端与服务端进行数据传递,通过序列化和反序列化进行交互。在transact函数中,淘宝联盟商品源码对Parcel大小进行检查,避免数据传输过大导致的问题。最后,客户端与binder驱动的通信过程涉及了Transaction数据的写入、等待响应、数据处理和内存回收等步骤。

       总的来说,framework层的dz网站论坛源码Binder工作涉及服务管理、数据转换、通信协议和内存管理等环节,理解这些有助于深入掌握Binder的工作机制。

Android Touch事件InputManagerService源码解析(二)

       解析Android Touch事件分发过程,深入InputManagerService源码。触摸事件的产生与传递机制是本文探讨的核心。

       InputDispatcher接收到事件,通过enqueueInboundEventLocked接口将事件放入mInboundQueue队列,等待分发处理。

       InputDispatcher内部线程在有事件时被唤醒,执行dispatchOnce,根据事件类型调用dispatchMotionLocked进行处理。处理流程涉及找到要处理事件的窗口。

       窗口查找通过findFocusedWindowTargetsLocked方法实现,该方法从map中获取focusedWindowHandle和focusedApplicationHandle,存储目标窗口信息。

       这些句柄的初始化在Activity的生命周期回调中,如Activity.onResume时。具体路径涉及ActivityTaskManagerService、DisplayContent、InputMonitor和InputManagerService。

       分发循环由prepareDispatchCycleLocked、enqueueDispatchEntryLocked和enqueueDispatchEntriesLocked方法实现,最后调用startDispatchCycleLocked,将事件发送给对应进程。

       InputReader持续从底层读取事件,InputDispatcher通过线程处理分发,直至事件被发送至目标进程。本文深入解析了Touch事件的分发机制与关键步骤,提供了对Android触摸事件处理过程的全面理解。

service manager在安卓的什么层中层

       service manager在安卓的什么层中层

        android-sdk-manager包括如下文件:

       åŒ…含大量demo 演示工程....SDK添加了新功能一般就会在这里添加示例程序.

       Sources for Android SDK

       FrameWork层的源代码

       Google APIs

       æ‰“包了Google服务的Framework,比正常使用的android.jar里多了一些东西(比如 Google Play Service / Google map 之类的).

       XXX image

       å¯¹åº”版本的虚拟机文件.一般会给ARM和x两种版本

Android N 四大组件的工作原理

       æœ¬æ–‡ä¾§é‡è®²è§£android N 系统中四大组件的工作原理,不同系统原理略有差别。通过分析四大组件的工作流程加深对Android Framework的理解,也为插件化开发打下基础。

        Activity

        展示一个界面并和用户交互,它扮演的是一个前台界面的角色。

        Service

        计算型组件,用于后台执行一系列计算任务,工作在主线程,耗时操作需要另起线程, 分为启动状态和绑定状态。

        BroadcastReceiver

        消息型组件,主要用于不同组件或者不同应用之间的消息传递,它工作在系统内部,不适合执行耗时操作,操作超过5s,会出现ANR。

        ContentProvider

        数据共享型组件,用于向其他组件或者应用共享数据,主要执行CURD操作。

        我们启动一个activity有两种方法,

        第一种(Activity直接启动方式):

        Intent intent = new Intent(this, MainActivity.class);

        startActivity(intent);

        第二种(Context启动方式)

        Intent intent = new Intent(this, MainActivity.class);

        getApplicationContext().startActivity(intent);

        不同的启动方式Activity的工作流程有点差别。

        两种启动都会调用到Instrumentation类中的execStartActivity的方法,系统最终是通过ActivityThread中的performLaunchActivity完成Activity的创建和启动。

        performLaunchActivity方法主要完成以下工作:

        1、通过ActivityClientRecord对象获取启动activity的组件信息

        2、通过mInstrumentation对象的newActivity方法调用classloader完成activity的创建

        3、通过r.packageInfo(LoadedApk 对象)的makeApplication方法尝试创建Application对象

        4、创建ContextImpl对象并调用Activity的attach方法完成一些数据的初始化

        5、调用Activity的onCreate方法

        在Activity启动的过程中,App进程会频繁地与AMS进程进行通信:

        App进程会委托AMS进程完成Activity生命周期的管理以及任务栈的管理;这个通信过程AMS是Server端,App进程通过持有AMS的client代理IActivityManager完成通信过程;

        AMS进程完成生命周期管理以及任务栈管理后,会把控制权交给App进程,让App进程完成Activity类对象的创建,以及生命周期回调;这个通信过程也是通过Binder完成的,App所在server端的Binder对象存在于ActivityThread的内部类ApplicationThread;AMS所在client通过持有IApplicationThread的代理对象完成对于App进程的通信。

        Service有两种启动方式,startService()和bindService(),两种状态可以并存:

        startService流程

        bindService流程

        BroadcastReceiver的工作过程主要包括广播的注册、发送和接收:

        动态注册过程:

        发送过程

        静态注册是由PackageManagerService(PMS)在应用安装的时候完成整个注册过程的,除广播以外,其他三大组件也都是在应用安装时由PMS解析并注册的。

        每个进程的入口都是ActivityThead.main(),App的启动流程如下:

        从源码中可以看出:

        应用启动的入口为ActivityThread的main方法,main方法会创建ActivityThread实例并创建主线程消息队列。

        attach方法中远程调用AMS的attachApplication方法,并提供ApplicationThread用于和AMS的通信。

        attachApplication方法会通过bindApplication方法和H来调回ActivityThread的handleBindApplication,这个方法会先创建Application,再加载ContentProvider,然后才会回调Application的onCreate方法。

        由上图可以看出,在ContentProvider的启动过程中伴随着app进程的启动。

        ContentProvider的其他CURD操作如insert,delete,update跟query的流程类似。