本文的调查基于Android P的原生源代码。
本周在处理某一款应用的问题时，遇到一处名为ServiceConnectionLeaked的运行时异常，异常信息如下：
Service com.xxx.xxx.alexaservice.MetroAlexaAudioProviderService has leaked ServiceConnection com.xxx.xxx.connection.MetroConnection@32dc748 that was originally bound here
备注：因涉及三方应用，所以包名以com.xxx.xxx替换
详细信息：
10-29 15:15:19.422 1000 1190 1209 I ActivityManager: Start proc 2308:com.xxx.xxx/u0a165 for activity com.xxx.xxx/com.xxx.xxx.AlexaSettingsLauncherActivity caller=com.android.settings
......
10-29 15:15:20.360 10165 2308 2308 E ActivityThread: Service com.xxx.xxx.alexaservice.MetroAlexaAudioProviderService has leaked ServiceConnection com.xxx.xxx.connection.MetroConnection@32dc748 that was originally bound here
10-29 15:15:20.360 10165 2308 2308 E ActivityThread: android.app.ServiceConnectionLeaked: Service com.xxx.xxx.alexaservice.MetroAlexaAudioProviderService has leaked ServiceConnection com.xxx.xxx.connection.MetroConnection@32dc748 that was originally bound here
10-29 15:15:20.360 10165 2308 2308 E ActivityThread: at android.app.LoadedApk$ServiceDispatcher.(LoadedApk.java:1618)
10-29 15:15:20.360 10165 2308 2308 E ActivityThread: at android.app.LoadedApk.getServiceDispatcher(LoadedApk.java:1510)
10-29 15:15:20.360 10165 2308 2308 E ActivityThread: at android.app.ContextImpl.bindServiceCommon(ContextImpl.java:1670)
10-29 15:15:20.360 10165 2308 2308 E ActivityThread: at android.app.ContextImpl.bindService(ContextImpl.java:1623)
10-29 15:15:20.360 10165 2308 2308 E ActivityThread: at android.content.ContextWrapper.bindService(ContextWrapper.java:708)
10-29 15:15:20.360 10165 2308 2308 E ActivityThread: at com.xxx.xxx.alexaservice.MetroAlexaAudioProviderService.connectToMetroService(MetroAlexaAudioProviderService.java:168)
10-29 15:15:20.360 10165 2308 2308 E ActivityThread: at com.xxx.xxx.alexaservice.MetroAlexaAudioProviderService.doBind(MetroAlexaAudioProviderService.java:68)
10-29 15:15:20.360 10165 2308 2308 E ActivityThread: at com.xxx.xxx.AlexaAudioProviderService.onBind(Unknown Source:0)
10-29 15:15:20.360 10165 2308 2308 E ActivityThread: at android.app.ActivityThread.handleBindService(ActivityThread.java:3626)
10-29 15:15:20.360 10165 2308 2308 E ActivityThread: at android.app.ActivityThread.access$1600(ActivityThread.java:207)
10-29 15:15:20.360 10165 2308 2308 E ActivityThread: at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1722)
10-29 15:15:20.360 10165 2308 2308 E ActivityThread: at android.os.Handler.dispatchMessage(Handler.java:106)
10-29 15:15:20.360 10165 2308 2308 E ActivityThread: at android.os.Looper.loop(Looper.java:201)
10-29 15:15:20.360 10165 2308 2308 E ActivityThread: at android.app.ActivityThread.main(ActivityThread.java:6831)
10-29 15:15:20.360 10165 2308 2308 E ActivityThread: at java.lang.reflect.Method.invoke(Native Method)
10-29 15:15:20.360 10165 2308 2308 E ActivityThread: at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:547)
10-29 15:15:20.360 10165 2308 2308 E ActivityThread: at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:927)
从异常信息中，粗略看到Service对象MetroAlexaAudioProviderService泄漏了其成员变量MetroConnection@32dc748，这一变量是ServiceConnection类型。有些疑惑。
ServiceConnectionLeaked是继承自AndroidRuntimeException类的子类。
先解释下该应用（包名：com.xxx.xxx）的这段异常堆栈吧，通过反编译apk源代码发现，原来是：
com.xxx.xxx进程启动后，有调用端通过bindService来绑定服务
MetroAlexaAudioProviderService（父类：com.xxx.xxx.AlexaAudioProviderService），MetroAlexaAudioProviderService的doBind方法执行中，会调用connectToMetroService方法绑定另外一个新的服务绑定新服务过程：ContextWrapper.bindService → ContextImpl.bindService → ContextImpl.bindServiceCommon → android.app.LoadedApk.getServiceDispatcher → android.app.LoadedApk$ServiceDispatcher.
，最后突然抛出ServiceConnectionLeaked异常，也就是我们看到的上面Java异常栈。
查看栈顶的调用at android.app.LoadedApk$ServiceDispatcher.LoadedApk.java:1618)，这里的代码是：
// android/app/LoadedApk.java
ServiceDispatcher(ServiceConnection conn,
Context context, Handler activityThread, int flags) {
mIServiceConnection = new InnerConnection(this);
mConnection = conn;
mContext = context;
mActivityThread = activityThread;
mLocation = new ServiceConnectionLeaked(null);
mLocation.fillInStackTrace(); // LoadedApk.java:1618
mFlags = flags;
}
第1618行是mLocation.fillInStackTrace方法。熟悉此方法的同学了解，这里相当于埋雷，预先收集了执行到此函数的Java栈调用，像是保存了相关快照，但异常并非在这里抛出！
那异常是在哪里抛出的？根据"Service xxx has leaked ServiceConnection xxx that was originally bound here"，我们可以发现，真正触发并抛出异常的代码位置是：android/app/LoadedApk.java中 removeContextRegistrations方法，
public void removeContextRegistrations(Context context,
String who, String what) {
// ...
synchronized (mServices) {
//Slog.i(TAG, "Receiver registrations: " + mReceivers);
ArrayMap smap =
mServices.remove(context);
if (smap != null) {
for (int i = 0; i < smap.size(); i++) {
LoadedApk.ServiceDispatcher sd = smap.valueAt(i);
ServiceConnectionLeaked leak = new ServiceConnectionLeaked(
what + " " + who + " has leaked ServiceConnection "
+ sd.getServiceConnection() + " that was originally bound here");
leak.setStackTrace(sd.getLocation().getStackTrace());
Slog.e(ActivityThread.TAG, leak.getMessage(), leak);
if (reportRegistrationLeaks) {
StrictMode.onServiceConnectionLeaked(leak);
}
try {
ActivityManager.getService().unbindService(
sd.getIServiceConnection());
} catch (RemoteException e) {
throw e.rethrowFromSystemServer();
}
sd.doForget();
}
}
// ...
}
}
removeContextRegistrations方法最后触发了ServiceConnectionLeaked异常，那什么时候会调用removeContextRegistrations，并触发这样的异常呢？
通过查看frameworks/base/core/java/android/app/源码，以下是removeContextRegistrations的正常2种使用场景调用：
ActivityThread#handleDestroyActivity → ContextImpl#scheduleFinalCleanup → ContextImpl#performFinalCleanup → LoadedApk#removeContextRegistrations
ActivityThread#handleStopService → ContextImpl#scheduleFinalCleanup → ContextImpl#performFinalCleanup → LoadedApk#removeContextRegistrations
总结来说，应用的Acitivty和Service在销毁时，会最终调用到LoadedApk#removeContextRegistrations方法，这里有可能会抛出ServiceConnectionLeaked异常。
那下一个问题是，为何会抛出ServiceConnectionLeaked异常？它的作用是什么呢？
这里先要学习下Android中bindService、unbindService的代码实现知识：
首先我们知道，客户端在bindService时，需要生成一个ServiceConnection对象，该对象会封装为一个ServiceDispatcher对象，并将其内部类InnerConnection对象，通过ActivityManager#bindService，binder调用传递给AMS
-
注意：内部类InnerConnection对象是一个Binder对象，传递给AMS的目的是，bindService成功执行后，AMS可以通过该对象回调其connected方法，最终在应用端ServiceConnection对象的onServiceConnected方法被调用，一次完成的bindService成功完成！具体可参考：
- 服务端：com/android/server/am/ActiveServices.java#bindServiceLocked
- 客户端：android/app/LoadedApk.java#ServiceDispatcher#InnerConnection类的connected方法
客户端断开服务时，会通过调用unbindService方法，ContextImpl#unbindService执行时，会先调用
LoadedApk#forgetServiceDispatcher方法，该方法作用非常重要：其会将本地ServiceConnection对象与其ServiceDispatcher对象关系从ArrayMap中移除，并执行ServiceDispatcher的doForget方法（主要作用：解除针对服务端Service的死亡回调注册。因为这是正常的unbind，不再需要监听服务端的死亡回调）。
// android/app/ContextImpl.java
@Override
public void unbindService(ServiceConnection conn) {
if (conn == null) {
throw new IllegalArgumentException("connection is null");
}
if (mPackageInfo != null) {
IServiceConnection sd = mPackageInfo.forgetServiceDispatcher(
getOuterContext(), conn);
try {
ActivityManager.getService().unbindService(sd);
} catch (RemoteException e) {
throw e.rethrowFromSystemServer();
}
} else {
throw new RuntimeException("Not supported in system context");
}
}
那什么情况下会抛出ServiceConnectionLeaked异常呢？我们看到正常情况下，通过unbindService断开服务时，本地保存的ArrayMap（ArrayMap）信息会被清理、删除。但是ServiceConnectionLeaked异常抛出时，也就是方法
removeContextRegistrations中的逻辑执行时，本地保存的ArrayMap（ArrayMap）信息仍然存在！这里可推断说明：
结论：
应用的Acitivty和Service在销毁前，如果其已绑定一个服务Service，那么应用需主动调用unbindService方法（例如Acitity或Service的onDestroy方法中）解绑。否则销毁走到removeContextRegistrations方法逻辑中时，就会抛出ServiceConnectionLeaked异常，并通过提前埋雷的方式，将相关栈信息打印出来，以便开发者查清原因。
最后，本地Demo复现此问题：
我们在Demo应用（包名：com.kevin.test）的Activity#onCreate中调用bindService来绑定服务，onDestroy方法中未调用unbindService，那么打开页面Activity后，进入最近任务，强制上滑杀掉应用，那么日志中就会发现ServiceConnectionLeaked异常信息了。示例如下：
public class MainActivity extends Activity {
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
TestService service = new TestService(this);
service.connectService(); //其中会调用mContext.bindService(intent, mConnection, mContext.BIND_AUTO_CREATE);
}
@Override
protected void onDestroy() {
super.onDestroy();
}
}
抛出的异常信息：
11-04 14:39:20.624 11439 11439 E ActivityThread: Activity com.kevin.test.MainActivity has leaked ServiceConnection com.kevin.test.TestService$2@3201e07 that was originally bound here
11-04 14:39:20.624 11439 11439 E ActivityThread: android.app.ServiceConnectionLeaked: Activity com.kevin.test.MainActivity has leaked ServiceConnection com.kevin.test.TestService$2@3201e07 that was originally bound here
11-04 14:39:20.624 11439 11439 E ActivityThread: at android.app.LoadedApk$ServiceDispatcher.(LoadedApk.java:1618)
11-04 14:39:20.624 11439 11439 E ActivityThread: at android.app.LoadedApk.getServiceDispatcher(LoadedApk.java:1510)
11-04 14:39:20.624 11439 11439 E ActivityThread: at android.app.ContextImpl.bindServiceCommon(ContextImpl.java:1669)
11-04 14:39:20.624 11439 11439 E ActivityThread: at android.app.ContextImpl.bindService(ContextImpl.java:1622)
11-04 14:39:20.624 11439 11439 E ActivityThread: at android.content.ContextWrapper.bindService(ContextWrapper.java:708)
11-04 14:39:20.624 11439 11439 E ActivityThread: at com.kevin.test.TestService.connectService(TestService.java:29)
11-04 14:39:20.624 11439 11439 E ActivityThread: at com.kevin.test.MainActivity.onCreate(MainActivity.java:20)
11-04 14:39:20.624 11439 11439 E ActivityThread: at android.app.Activity.performCreate(Activity.java:7224)
11-04 14:39:20.624 11439 11439 E ActivityThread: at android.app.Activity.performCreate(Activity.java:7213)
11-04 14:39:20.624 11439 11439 E ActivityThread: at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1272)
11-04 14:39:20.624 11439 11439 E ActivityThread: at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2926)
11-04 14:39:20.624 11439 11439 E ActivityThread: at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:3081)
11-04 14:39:20.624 11439 11439 E ActivityThread: at android.app.servertransaction.LaunchActivityItem.execute(LaunchActivityItem.java:78)
11-04 14:39:20.624 11439 11439 E ActivityThread: at android.app.servertransaction.TransactionExecutor.executeCallbacks(TransactionExecutor.java:108)
11-04 14:39:20.624 11439 11439 E ActivityThread: at android.app.servertransaction.TransactionExecutor.execute(TransactionExecutor.java:68)
11-04 14:39:20.624 11439 11439 E ActivityThread: at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1831)
11-04 14:39:20.624 11439 11439 E ActivityThread: at android.os.Handler.dispatchMessage(Handler.java:106)
11-04 14:39:20.624 11439 11439 E ActivityThread: at android.os.Looper.loop(Looper.java:201)
11-04 14:39:20.624 11439 11439 E ActivityThread: at android.app.ActivityThread.main(ActivityThread.java:6806)
11-04 14:39:20.624 11439 11439 E ActivityThread: at java.lang.reflect.Method.invoke(Native Method)
11-04 14:39:20.624 11439 11439 E ActivityThread: at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:547)
11-04 14:39:20.624 11439 11439 E ActivityThread: at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:873)
这样我们的分析，便得到验证！
最后说明下，此问题影响不大，更多的是暴露了开发者开发时的不规范，未考虑到bindService、unbindService的成对调用或正确时机调用。因为在最后Activity、Service销毁时removeContextRegistrations中会最后调用AMS#unbindService方法，ServiceDispatcher#doForget方法完成补救。但值得开发者注意！
作者：kevin song，2019.11.4于南京建邺区