一、从插件中startService的流程
这个过程虽然比Activity启动简单很多,但是需要深入理解android源码。点此链接可查看高清svg图:
过程分拆:
1、Hook工作
在插件内调用startService,会进入hooked StartService方法,该方法会调用VActivityManager的public ComponentName startService(IInterface caller, Intent service, String resolvedType, int userId)方法,当然,其实最终是调用了:x进程的VActivityManagerService的对应方法。
2、VActivityManagerService内部处理之一
startService方法会调用内部的startServiceCommon方法,startServiceCommon方法会先判断是否需要启动新进程(支持Service在远程进程),如果需要则启动,并且会返回ProcessRecord(包含了Service所在进程的ApplicationThread);然后,调用findRecordLocked方法判断是否存在此Service的记录ServiceRecord,如果ServiceRecord是null或者ServiceRecord中的prcoess(ProcessRecord)为null,说明没有启动过该Service,从而needCreateService被置为true,接下来调用远程ApplicationThread的scheduleCreateService方法,并记录下此Service已启动,注意:后续stopService会用到对应的ServiceRecord。
3、Service所在进程处理之一(全是android源码)
ApplicationThread的scheduleCreateService方法会向ActivityThread发送CREATE_SERVICE消息,ActivityThread接收此消息后调用handleCreateService方法,内部会加载Service,调用Service的onCreate方法等,然后,调用ActivityManagerNative.getDefault()的serviceDoneExecuting方法告知远程创建完成。
4、hook serviceDoneExecuting
不过,serviceDoneExecuting也被hook了,它会调用VActivityManager的public void serviceDoneExecuting(IBinder token, int type, int startId, in tres)的方法,当然,其实最终是调用了:x进程的VActivityManagerService的对应方法。
5、VActivityManagerService内部处理之二
VActivityManagerService继续调用requestServiceBindingsLocked方法判断之前是否有被pending的bind请求(即非BIND_AUTO_CREATE的bindService)。如果有,调用远程ApplicationThread的scheduleBindService方法执行绑定操作(稍后会详细介绍bindService和unBindService)。
6、VActivityManagerService内部处理之三
VActivityManagerService继续调用远程ApplicationThread的scheduleServiceArgs方法。
7、Service所在进程处理之二(全是android源码)
ApplicationThread的scheduleServiceArgs方法会向ActivityThread发送SERVICE_ARGS消息,ActivityThread接收此消息后调用handleServiceArgs方法,内部会调用Service的onStartCommand方法等,最后,调用ActivityManagerNative.getDefault()的serviceDoneExecuting方法告知远程start完成。
8、hook serviceDoneExecuting
同4。
二、从插件中stopService的流程
点此链接可查看高清svg图:
过程分拆:
1、Hook工作
在插件内调用stopService,会进入hooked StopService方法,该方法会调用VActivityManager的public int stopService(IInterface caller, Intent service, String resolvedType)方法,当然,其实最终是调用了:x进程的VActivityManagerService的对应方法。
2、VActivityManagerService内部处理之一
stopService方法会调用内部的findRecordLocked方法判断是否启动过此Service,如果已经启动,则查看
是否有BIND_AUTO_CREATE模式的bindService,如果有,则结束此次调用;
如果没有,则再次判断是否有非BIND_AUTO_CREATE模式的bindService,如果有,则调用远程ApplicationThread的scheduleUnbindService方法结束绑定,最终,调用scheduleStopService方法,传递的参数则是ServiceRecord(Binder对象)。
3、Service所在进程处理之一(全是android源码)
ApplicationThread的scheduleStopService方法会向ActivityThread发送STOP_SERVICE消息,ActivityThread接收此消息后调用handleStopService方法,内部会调用对应Service(注意:Service和token一一对应)的onDestroy方法等,最后,调用ActivityManagerNative.getDefault()的serviceDoneExecuting方法告知远程销毁完成。
4、hook serviceDoneExecuting
serviceDoneExecuting也被hook了,它会调用VActivityManager的public void serviceDoneExecuting(IBinder token, int type, int startId, int res)的方法,当然,其实最终是调用了:x进程的VActivityManagerService的对应方法。此方法的作用是移除对应的ServiceRecord。
三、从插件中的Service调用stopSelf的过程
stopSelf有两个重载方法:
其中mToken是VActivityManagerService记录Service启动所用的ServiceRecord,stopSelf方法最终会调用stopServiceToken方法(被Hook了):
点此链接可查看高清svg图:
过程分拆:
1、Hook工作
进入hooked StopServiceToken方法后,该方法会调用VActivityManager的public boolean isVAServiceToken(IBinder token)方法,当然,其实最终是调用了:x进程的VActivityManagerService的对应方法。
2、VActivityManagerService内部处理之一
isVAServiceToken方法判断传递进来的token是不是ServiceRecord,如果是,返回true。
3、请求stopServiceToken
StopServiceToken继续调用VActivityManager的public boolean stopServiceToken(ComponentName className, IBinder token,int startId)方法,当然,其实最终是调用了:x进程的VActivityManagerService的对应方法。
4、VActivityManagerService内部处理之二
stopServiceToken方法判断传递进来的startId是否为ServiceRecrod记录的最后一个startId,或者startId==-1,如果是,则接下来处理操作同《从插件中stopService的流程》第2步之后的所有操作。