Android 设备管控开发实战：常见保活与拉活方案怎么组合，实测能到什么程度？

设备管控 App 的持续运行要拆成两个问题：保活是在进程仍存活时降低被回收概率；拉活是在进程已经退出后，重新获得执行入口并恢复业务。死亡检测只是拉活的前置条件，不等于已经把进程拉起来。

本文给出常见的“保活 + 拉活”组合，并结合原项目已有记录说明它们能做到哪里。强制停止后，普通 APK 没有公开接口保证自行恢复。

1. 先分清：哪些方案保活，哪些方案拉活

2. 保活：前台服务降低核心进程被回收概率

核心服务放进 :core 进程，立即进入前台并返回 START_STICKY。Android 14 以后必须声明真实业务类型；下面仅以真实业务确属 specialUse、且目标分发渠道认可的管控会话为例，不能为保活拼接无关类型。

<uses-permission android:name="android.permission.FOREGROUND_SERVICE" />
<uses-permission android:name="android.permission.FOREGROUND_SERVICE_SPECIAL_USE" />

<service
android:name=".keepalive.ControlForegroundService"
android:process=":core"
android:exported="false"
android:stopWithTask="false"
android:foregroundServiceType="specialUse">
<property
android:name="android.app.PROPERTY_SPECIAL_USE_FGS_SUBTYPE"
android:value="managed-device-control-session" />
</service>

<service
android:name=".keepalive.GuardService"
android:process=":guard"
android:exported="false" />

服务先展示持续通知，再初始化业务。onStartCommand() 的 intent 可能为空，待恢复状态必须写入 DataStore 或数据库。

class ControlForegroundService : Service() {
private val binder = Binder()
private val scope = CoroutineScope(SupervisorJob() + Dispatchers.Default)
private lateinit var guardLink: PeerLink

override fun onCreate() {
super.onCreate()
createNotificationChannel()

val type = if (Build.VERSION.SDK_INT >= 34) {
ServiceInfo.FOREGROUND_SERVICE_TYPE_SPECIAL_USE
} else {
0
}
ServiceCompat.startForeground(this, 1001, buildNotification(), type)

guardLink = PeerLink(this, GuardService::class.java) {
KeepAliveLog.peerLost("guard")
startGuard()
}
startGuard()
guardLink.connect()
}

override fun onStartCommand(intent: Intent?, flags: Int, startId: Int): Int {
scope.launch {
RestoreCoordinator.restore(intent?.action ?: "sticky-recreate")
}
return START_STICKY
}

override fun onBind(intent: Intent?): IBinder = binder

private fun startGuard() {
runCatching {
startService(Intent(this, GuardService::class.java))
}.onFailure(KeepAliveLog::guardStartFailed)
}

override fun onDestroy() {
guardLink.close()
scope.cancel()
super.onDestroy()
}
}

这里要拆开理解：startForeground() 提供的是保活能力，返回 START_STICKY 提供的是系统择机重建 Service 的拉活机会。后者没有重启时限；Android 12 以后后台启动还可能被拒绝，失败后应安排 Job，而不是循环调用。

3. 拉活一：Java 双进程检测死亡并由存活端恢复

双进程本身不会让整个应用更难被系统清理，它解决的是拉活：Binder 断开负责发现单进程死亡，仍存活的一侧负责请求重建对端。:core 先启动 :guard，两边再以 BIND_AUTO_CREATE 互相绑定。

public final class PeerLink {
private final Context app;
private final Class<? extends Service> peerService;
private final Runnable onPeerLost;
private final Handler main = new Handler(Looper.getMainLooper());
private boolean bound;
private boolean closed;
private final Runnable reconnect = this::connect;

public PeerLink(Context context,
Class<? extends Service> peerService,
Runnable onPeerLost) {
this.app = context.getApplicationContext();
this.peerService = peerService;
this.onPeerLost = onPeerLost;
}

private final ServiceConnection connection = new ServiceConnection() {
@Override public void onServiceConnected(ComponentName name, IBinder binder) {
bound = true;
}
@Override public void onServiceDisconnected(ComponentName name) {
main.post(PeerLink.this::retry);
}
@Override public void onBindingDied(ComponentName name) {
main.post(PeerLink.this::retry);
}
};

public void connect() {
if (closed || bound) return;
Intent intent = new Intent(app, peerService);
bound = app.bindService(
intent,
connection,
Context.BIND_AUTO_CREATE | Context.BIND_IMPORTANT
);
if (!bound) schedule();
}

private void retry() {
if (closed) return;
if (bound) {
try { app.unbindService(connection); } catch (RuntimeException ignored) {}
}
bound = false;
onPeerLost.run();
schedule();
}

private void schedule() {
main.removeCallbacks(reconnect);
main.postDelayed(reconnect, 1500L);
}

public void close() {
closed = true;
main.removeCallbacksAndMessages(null);
if (bound) {
try { app.unbindService(connection); } catch (RuntimeException ignored) {}
}
bound = false;
}
}

GuardService 必须同时启动并绑定。只互相绑定时，:core 死亡会移除绑定，:guard 可能随即销毁；先启动再绑定，守护进程才有机会发现断开并恢复核心服务。

class GuardService : Service() {
private val binder = Binder()
private lateinit var coreLink: PeerLink

override fun onCreate() {
super.onCreate()
coreLink = PeerLink(this, ControlForegroundService::class.java) {
KeepAliveEntry.requestCore(this, "guard-detected-core-death")
}
KeepAliveEntry.requestCore(this, "guard-created")
coreLink.connect()
}

override fun onStartCommand(intent: Intent?, flags: Int, startId: Int): Int {
return START_STICKY
}

override fun onBind(intent: Intent?): IBinder = binder

override fun onDestroy() {
coreLink.close()
super.onDestroy()
}
}

业务只在核心服务初始化；守护进程只检测存活、请求重建和重新绑定，避免两边重复创建 Socket 或监听。

若产品本来就依赖无障碍，可将它放在 :access。授权有效且应用未处于 stopped 状态时，系统可能重连；成功后再接回核心服务。

class ControlAccessibilityService : AccessibilityService() {
override fun onServiceConnected() {
super.onServiceConnected()
KeepAliveEntry.requestCore(this, "accessibility-connected")
}

override fun onInterrupt() = Unit
}

无障碍必须服务于真实功能；用户关闭授权或应用被停止时，这条入口也会消失。

4. 拉活二：广播与 JobScheduler 等待系统入口

双进程只能处理“死一个、还剩一个”。全部 Java 进程消失后，依靠开机、用户解锁和当前 APK 覆盖更新重新进入。

<uses-permission android:name="android.permission.RECEIVE_BOOT_COMPLETED" />

<receiver
android:name=".keepalive.RecoveryReceiver"
android:exported="false">
<intent-filter>
<action android:name="android.intent.action.BOOT_COMPLETED" />
<action android:name="android.intent.action.USER_UNLOCKED" />
<action android:name="android.intent.action.MY_PACKAGE_REPLACED" />
</intent-filter>
</receiver>

<service
android:name=".keepalive.RecoveryJobService"
android:permission="android.permission.BIND_JOB_SERVICE"
android:exported="true" />

Receiver 只请求核心服务并安排延迟检查；依赖用户凭据的业务在解锁后恢复。

object KeepAliveEntry {
fun requestCore(context: Context, origin: String) {
val intent = Intent(context, ControlForegroundService::class.java)
.setAction(origin)
try {
ContextCompat.startForegroundService(context, intent)
} catch (blocked: IllegalStateException) {
RecoveryJob.schedule(context)
} catch (denied: SecurityException) {
RecoveryJob.schedule(context)
}
}
}

class RecoveryReceiver : BroadcastReceiver() {
override fun onReceive(context: Context, intent: Intent) {
KeepAliveEntry.requestCore(context, intent.action ?: "broadcast")
RecoveryJob.schedule(context, delayMs = 60_000L)
}
}

object RecoveryJob {
private const val JOB_ID = 21001

fun schedule(context: Context, delayMs: Long = 15 * 60_000L) {
val service = ComponentName(context, RecoveryJobService::class.java)
val job = JobInfo.Builder(JOB_ID, service)
.setMinimumLatency(delayMs)
.setOverrideDeadline(delayMs + 15 * 60_000L)
.setPersisted(true)
.build()
context.getSystemService(JobScheduler::class.java).schedule(job)
}
}

class RecoveryJobService : JobService() {
override fun onStartJob(params: JobParameters): Boolean {
KeepAliveEntry.requestCore(this, "job")
return false
}

override fun onStopJob(params: JobParameters): Boolean = true
}

JobScheduler 只是延迟机会，执行时间由系统决定。强制停止后，Job 和普通广播都不能自恢复，必须等待用户或管理员重新进入应用。

5. 所有入口最终只恢复一次业务状态

多个入口只请求核心服务，由 RestoreCoordinator 串行、幂等地恢复业务；它负责避免重复连接，不是新的保活方案。

object RestoreCoordinator {
private val mutex = Mutex()

suspend fun restore(origin: String) = mutex.withLock {
val desired = RuntimeStore.read()
if (!desired.controlEnabled) return

AccessibilityRules.ensureRegistered()
CommandChannel.ensureConnected(
endpoint = desired.endpoint,
revision = desired.configRevision
)
KeepAliveLog.ready(origin, desired.configRevision)
}
}

两个 ensure 对相同版本直接复用，版本变化时先关闭旧连接再替换。

6. 实测：分别看保活与拉活能力

以下只列原项目已有记录。“普通方案”指前台服务、系统管理的无障碍服务、广播和 JobScheduler；Java 双进程只覆盖单进程死亡，不改变整包停止结论。

测试时先记录 :core、:guard、:access 的 PID，再验收以下五条链路。

**保活结论：**前台服务和系统管理的服务能降低回收概率，但不是不死进程。Q20 和原生模拟器清理最近任务时进程保持，华为 C3 上相同方案仍会被清理，能力明显依赖系统与后台权限。

**拉活结论：**双进程能在一侧仍存活时恢复另一侧；广播和 Job 能在系统给出入口时恢复全部业务，但都不保证时效。强制停止后必须保持停止，厂商整包清理且没有后续入口时也不能自行恢复。

7. 进阶：增强保活与拉活

上面的组合依赖“至少还有一个 Java 进程存活”或“系统之后再次给入口”。如果厂商清理会同时结束多个进程，或者普通系统恢复入口太慢，下一步需要把保活和拉活分开增强：屏幕联动方案降低被清理概率，Native flock 检测对端死亡，再由仍存活的 Java 进程请求恢复。

继续阅读 VIP 进阶篇：《Android 设备管控开发实战：第三方设备如何增强管控 App 保活与拉活？Native 守护实战》

参考资料

• Foreground services overview
• Restrictions on starting a foreground service from the background
• Bound services overview
• JobScheduler API