安卓系统中的“Spurious Death”是什么？

Question

我知道这听起来像是一个懒惰的问题...但实际上我并不清楚这种情况是如何发生的，也无法在Google上找到太多信息。

背景：

这是一个带有IPC的应用程序：我有一个在单独进程中运行的服务。有时，服务会被杀死...但它并没有真正“正式死亡”，相反，我从ActivityManager得到了一个术语叫做“Spurious death”。当这种情况发生时，服务就像僵尸一样。它还活着，但它实际上没有在运行。

04-12 10:03:37.935 728 830 I ActivityManager: 强制关闭 activity ActivityRecord{11eee41f u0 com.android.staging/com.android.activities.MainActivity t8210} 04-12 10:03:37.937 728 830 I ActivityManager: 强制停止服务ServiceRecord{291a4c9b u0 com.android.staging/com.android.services.CallService} 04-12 10:03:37.969 728 2563 W ActivityManager: 进程ProcessRecord{27ecf545 11057:com.android.staging/u0a268}的虚假死亡, 当前进程为11057: null

- xialin

---

我认为这与内核和低内存有关... - Šime Tokić

Answer 1

冒犯的代码行可以在此找到： http://grepcode.com/file/repository.grepcode.com/java/ext/com.google.android/android/5.0.0_r1/com/android/server/am/ActivityManagerService.java/#4858 （不同版本的Android L有不同的代码行）。

我假设你正在使用某种形式的Android L，因为该特定错误消息直到那时才被添加。

如果您在进程中运行ContentProvider，则ActivityManagerService中的这两个注释可能会有所帮助：

9303                     // NOTE: there is still a race here where a signal could be
9304                     // pending on the process even though we managed to update its
9305                     // adj level.  Not sure what to do about this, but at least
9306                     // the race is now smaller.
9307                     if (!success) {
9308                         // Uh oh...  it looks like the provider's process
9309                         // has been killed on us.  We need to wait for a new
9310                         // process to be started, and make sure its death
9311                         // doesn't kill our process.

and then ...

9317                         appDiedLocked(cpr.proc);

appDiedLocked还可以从其他源文件中调用：ActiveServices.java和ActivityStackSupervisor.java，其中一个依赖于DeadObjectException的抛出，另一个依赖于RemoteException。

appDiedLocked的代码如下：

4853     final void appDiedLocked(ProcessRecord app, int pid, IApplicationThread thread) {
4854         // First check if this ProcessRecord is actually active for the pid.
4855         synchronized (mPidsSelfLocked) {
4856             ProcessRecord curProc = mPidsSelfLocked.get(pid);
4857             if (curProc != app) {
4858                 Slog.w(TAG, "Spurious death for " + app + ", curProc for " + pid + ": " + curProc);
4859                 return;
4860             }
4861         }

由于某种原因，curProc与应用程序ProcessRecord不同，appDiedLocked方法被截断。在您的情况下，curProc为空，同样是由于某种原因。

简而言之：您的进程已经死亡或被杀死，并且某些状态或条件阻止了appDiedLocked继续运行killProcess命令。您需要进行更多的调查/记录，以找出发生这种情况的原因。

如果您有一个希望保持活动状态的服务，除非您已经这样做，否则我建议您将状态栏通知附加到该服务上，这样就可以降低其被杀死的可能性。

- Erik Zivkovic