上半年遇到的一些service绑定失败的分析

对于近期4.4和5.x上出现服务无法绑定的问题分析如下：

【具体原因分析】

一、    用户侧数据

我们从用户侧拿到的servicedump信息：

从用户侧拿到的sevices文件，都有这几特征：

解释这几个值。

1.serviceRecord：就是用于服务对象本身

1.App=null：说明服务于进程没有关联起来

2.lastStartid=124;说明主进程调用startservice接近124次了。对这个频繁的调用，只有两种可能：

A.      进程被杀后服务自启，如果要触发这个条件，相当于进程短时间内一直被kill，从log看，是可以排除这种情况

B.       客户端判断绑定没成功进行重邦定，很显然，这个124值就是我们一直在调用

1.      至于这个restartDelay这个值：说明这个ServiceRecord是要延时启动的。

2.       

二、    源代码信息疑点

从上面的这些信息。我们结合源码，看到两个可疑点：

无论是何种方式启动或重启都会调用这个方法：bringUpServiceLocked，这两处（标红的1，2）会直接return，这种分支执行的结果就是永远都无法绑定成功。

大家先记住这张图。后面分析会用到

第一种情况：

首先我们app==null.所以不可能是第一种情况，接下来重点分析第二种情况。

第二种情况：

首先，出现二种情况的条件是如下：

Ø  whileRestarting=false;

Ø  r.restartDelay>0   //上面我们抓到的dump可以看到restartDelay是大于0的。哪我们主要看这个值whileRestarting是什么情况了。因为这里失败时，是我们主动调用了startservice和bindservices。

查代码后，发现有三个地方会调用：

 

1.        startServiceInnerLocked-->bringUpServiceLocked(r, service.getFlags(), callerFg, false);

2.        bindServiceLocked-->bringUpServiceLocked(s,service.getFlags(), callerFg, false)

3.        performServiceRestartLocked-->bringUpServiceLocked(r,r.intent.getIntent().getFlags(), r.createdFromFg, true