Android开机自启与后台保活实战：BOOT_COMPLETED+前台服务全解析

简介：面向需要实现后台保活与开机自启的Android开发者，这份Demo工程围绕Service与BroadcastReceiver展开，演示如何监听ACTION_BOOT_COMPLETED广播，在系统启动完成后拉起指定APK，并覆盖权限声明、生命周期管理、START_STICKY等启动模式、前台服务、IntentService、Doze模式与JobScheduler/WorkManager适配等关键处理。压缩包共54个文件，大小仅1.31MB，以Java源码、XML配置、class编译文件及可直接安装的APK为主，附带jar依赖、Dex与工程配置文件，导入Android Studio或Eclipse即可查看运行。已有307人学习下载。代码中完整呈现了开机广播接收器、自定义后台服务、目标APK拉起逻辑以及应对Android高版本后台限制的替代方案，适合有一定Android基础、希望快速掌握应用保活与自启思路的开发者参考改造。

1. 安卓后台保持运行与开机自启，真正的难点不在构建而在系统限制

开机后自动启动一个设定好的 APK，听起来只是加一个开机广播的事，但放到 Android 8.0 之后的真机上，一半以上的初次实现都会翻车：广播收不到、服务拉不起来、拉起 Activity 直接被系统丢回桌面。标题里这套“后台保持运行 + 开机后自动启动设定好的 APK”的 DEMO，解决的正是无人值守设备上最常见的三个诉求：设备重启后无人点击也能进入业务、承载业务的服务不被系统回收、指定 APK 能被可靠拉起。它对应的是自助终端、工控看板、车载盒子、测试机集群这类场景。下文从系统限制讲起，落到一份可直接编译的最小工程，最后给出各 Android 版本和国产 ROM 下的验证与排查方法。

2. 开机自启与后台保持运行的实现基础

2.1 BOOT_COMPLETED 开机广播经常收不到，先分清三类原因

Android 系统开机完成后，由系统进程发出android.intent.action.BOOT_COMPLETED这条全局广播。应用在 Manifest 里静态注册一个 Receiver 就能收到。但实际开发时，很多工程师会遇到“装了不上电，广播就是不来”的情况，问题通常出在下面三点。

第一，Android 3.1 之后引入了stopped状态。应用安装完成后默认处于停止状态，系统不会给它发送任何广播，用户必须至少点击启动一次 App，系统才会把应用标记为正常状态。所以 DEMO 安装后不打开就直接重启，开机广播自然收不到。

第二，Android 8.0 开始限制隐式广播。很多应用通过静态注册方式接收的PACKAGE_ADDED、NETWORK_CHANGE等广播全部失效，但BOOT_COMPLETED是被系统豁免的，静态注册仍然有效。这里要注意的是 targetSdk 版本：编译时 targetSdk 越高，系统行为越接近新版本规则，建议直接以 targetSdk 34 编译。

第三，国产 ROM 的自启动管理。MIUI、EMUI、OriginOS、ColorOS 都有自己的自启动拦截策略，应用即使注册了RECEIVE_BOOT_COMPLETED权限，也会在系统设置里被默认关闭。判断问题属于哪一类，最简单的方法是先用adb shell dumpsys package查应用是否处于 stopped 状态，再用adb shell am broadcast手动发送一条开机广播来复现。

2.1.1 注意 targetSdk 与开机广播的边界

2.2 后台保持运行的两根支柱：前台服务与 START_STICKY

BOOT_COMPLETED只是给了应用一个起点，真正让 App 存活下来的是 Service 本身。Android 对后台进程的回收策略是：进程被 LMK 杀掉后，如果系统仍认为它需要运行，就会尝试重建。START_STICKY就是告诉系统“这个服务被杀后，你把我重新拉起”。但仅有START_STICKY是不够的，进程长时间无前台可见组件会被缩到 cached 级别，还是会被系统回收。

这时就需要前台服务。Service 调用startForeground()后，系统会为它创建一个常驻通知，进程的 oom_adj 值会被抬高，进入前台进程级别。直观表现是：同样是保活，普通后台服务被杀的概率远高于前台服务。

Android 12 开始，系统禁止从后台直接启动前台服务，开机广播拉起前台服务的路径也被收窄。常见做法是在onReceive()里先做一次桌面启动判定，或使用AlarmManager延迟几十秒再尝试启动，系统对开机完成后的启动窗口期有特殊豁免逻辑。

2.2.1 双进程守护方案在 Android 8+ 的失效边界

早期保活常采用双进程互相拉起：两个进程通过 AIDL 绑定，一个被杀另一个立刻拉起。这套方案从 Android 8.0 后台执行限制开始基本失效，原因是系统禁止后台进程创建前台服务，且对force-stop之后的所有拉起路径做了拦截。DEMO 如果仍使用双进程守护，最终只会得到一个“两个进程都被封杀”的结果。

2.3 保活方案选型表

我的建议是：主题功能用前台服务，辅助保活用 WorkManager 做周期心跳，不碰双进程。这样代码在 Android 14 上不会因为没有后台启动权限直接崩溃。

3. 最小工程搭建：BootReceiver 拉起前台服务，再启动指定 APK

3.1 Manifest 中的权限、Receiver 与 Service 声明

新建工程时包名假设为com.demo.bootlauncher，主功能包含一个 Activity、一个继承自BroadcastReceiver的BootReceiver、一个前台服务KeepRunningService。AndroidManifest.xml的关键代码如下：

<uses-permission android:name="android.permission.RECEIVE_BOOT_COMPLETED" /> <uses-permission android:name="android.permission.FOREGROUND_SERVICE" /> <uses-permission android:name="android.permission.FOREGROUND_SERVICE_SPECIAL_USE" /> <uses-permission android:name="android.permission.POST_NOTIFICATIONS" /> <application android:icon="@mipmap/ic_launcher" android:label="@string/app_name"> <activity android:name=".MainActivity" android:exported="true"> <intent-filter> <action android:name="android.intent.action.MAIN" /> <category android:name="android.intent.category.LAUNCHER" /> </intent-filter> </activity> <receiver android:name=".BootReceiver" android:exported="true" android:enabled="true"> <intent-filter> <action android:name="android.intent.action.BOOT_COMPLETED" /> </intent-filter> </receiver> <service android:name=".KeepRunningService" android:exported="false" android:foregroundServiceType="specialUse"> <property android:name="android.app.PROPERTY_SPECIAL_USE_FGS_SUBTYPE" android:value="device_keep_alive" /> </service> </application>

RECEIVE_BOOT_COMPLETED用于接收开机广播，FOREGROUND_SERVICE是 Android 9 之后动态检查的前台服务权限，缺少它会导致服务启动失败。FOREGROUND_SERVICE_SPECIAL_USE是 Android 14 新增的类型权限，必须在清单里声明类型为specialUse并附上用途说明，否则系统会认为你使用了未声明的前台服务类型，运行时会报 SecurityException。POST_NOTIFICATIONS是 Android 13 开始的通知运行时权限，不申请的话前台服务通知不会显示，但服务本身仍能运行。

android:exported="true"是必须的，因为系统需要把BOOT_COMPLETED广播发送到该 Receiver。如果写成 false，开机广播会直接被系统过滤。

3.2 BootReceiver 中的广播判断与启动逻辑

public class BootReceiver extends BroadcastReceiver { private static final String TAG = "BootReceiver"; @Override public void onReceive(Context context, Intent intent) { if (!Intent.ACTION_BOOT_COMPLETED.equals(intent.getAction())) { return; } Log.i(TAG, "BOOT_COMPLETED received"); // 启动前台服务 Intent serviceIntent = new Intent(context, KeepRunningService.class); context.startForegroundService(serviceIntent); // 先记住用户当前偏好，DEMO 中固定为包名 String targetPackage = "com.demo.targetapp"; launchTargetApp(context, targetPackage); } private void launchTargetApp(Context context, String packageName) { PackageManager pm = context.getPackageManager(); Intent launchIntent = pm.getLaunchIntentForPackage(packageName); if (launchIntent != null) { launchIntent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK); try { context.startActivity(launchIntent); } catch (ActivityNotFoundException e) { Log.e(TAG, "target app not found: " + packageName); } } } }

这里的逻辑是：收到开机广播后先拉起常驻服务，再尝试启动设定好的 APK。startForegroundService方法在 Android 8.0 之后是强制要求的前台服务启动方式，如果直接调用startService会抛异常。服务启动后必须在 5 秒内调用startForeground()，否则系统会报ANR。getLaunchIntentForPackage获取目标 APK 的启动 Intent，部分 APK 没有配置 LAUNCHER 入口，此时返回 null，需要改用packageManager.getPackageInfo配合显式 Intent 来启动。

3.2.1 常见误用点

不要在onReceive里直接做耗时操作，广播接收器默认只有约 10 秒的执行时间。业务初始化应该丢给 Service 的onStartCommand()去做。也要注意，不要同时从 BroadcastReceiver 和 Service 里重复拉起目标 APK，目标应用会启动两次，界面叠加。

3.3 前台服务实现与通知渠道

public class KeepRunningService extends Service { private static final String CHANNEL_ID = "keep_alive_channel"; private static final int NOTIFICATION_ID = 1; @Override public void onCreate() { super.onCreate(); createNotificationChannel(); } @Override public int onStartCommand(Intent intent, int flags, int startId) { Notification notification = buildNotification(); // Android 14 需要传入 foregroundServiceType startForeground(NOTIFICATION_ID, notification, ServiceInfo.FOREGROUND_SERVICE_TYPE_SPECIAL_USE); return START_STICKY; } private Notification buildNotification() { Intent notificationIntent = new Intent(this, MainActivity.class); PendingIntent pendingIntent = PendingIntent.getActivity( this, 0, notificationIntent, PendingIntent.FLAG_IMMUTABLE); Notification.Builder builder = new Notification.Builder(this, CHANNEL_ID) .setContentTitle("后台保持运行中") .setContentText("设备开机自启服务已载入") .setSmallIcon(android.R.drawable.ic_popup_sync) .setContentIntent(pendingIntent) .setOngoing(true); return builder.build(); } private void createNotificationChannel() { NotificationChannel channel = new NotificationChannel( CHANNEL_ID, "boot_keep_alive", NotificationManager.IMPORTANCE_LOW); NotificationManager manager = getSystemService(NotificationManager.class); manager.createNotificationChannel(channel); } @Override public IBinder onBind(Intent intent) { return null; } }

FOREGROUND_SERVICE_TYPE_SPECIAL_USE是 Android 14 前台服务类型中比较通用的一种，适合“不是为具体业务类型设计的设备守护”场景。若 targetSdk 是 34，不传类型启动前台服务会直接抛ForegroundServiceStartNotAllowedException或MissingForegroundServiceTypeException。setOngoing(true)让通知无法被用户滑动清除，用户只能通过停止应用或强制停止来关闭服务。START_STICKY保证服务被系统回收后能再次重建。

4. 设定好的 APK：两种实现方式与参数差异

4.1 方案 A：通过包名启动系统内已安装的 APK

这是最轻量的方式，也是 DEMO 默认采用的方式。目标 APK 会被放置在设备的/system/app或由用户在开机前提前安装。这种方式的好处是不需要任何安装权限，代码简单，启动耗时短；缺点是依赖包名存在，包名变更后需要重新编译。

public void launchByPackageName(Context context, String packageName) { PackageManager pm = context.getPackageManager(); Intent intent = pm.getLaunchIntentForPackage(packageName); if (intent == null) { Log.w("BootDemo", "launch intent unavailable"); return; } intent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK | Intent.FLAG_ACTIVITY_RESET_TASK_IF_NEEDED); try { context.startActivity(intent); } catch (SecurityException e) { Log.e("BootDemo", "no permission to launch: " + packageName); } }

FLAG_ACTIVITY_NEW_TASK是从非 Activity 上下文启动 Activity 的必要条件。FLAG_ACTIVITY_RESET_TASK_IF_NEEDED可以保证目标 APK 以干净的任务栈出现，适合启动后即全屏展示的终端场景。SecurityException通常出现在目标应用设置了exported=false或调用者缺少权限时，需要在启动前用PackageManager.getApplicationInfo判断对方的 exported 属性。

4.1.1 包名校验的边界

部分系统应用或 ROM 内置应用不允许三方应用获取getLaunchIntentForPackage的返回结果，这里常见做法是捕获NullPointerException与ActivityNotFoundException，并在日志中打印具体的包名和系统版本，便于现场排查。

4.2 方案 B：将 APK 内置在工程 assets 中，开机自动安装并拉起

如果目标 APK 不希望提前刷进系统镜像，可以把它放到工程的assets目录，开机后由 DEMO 复制出来调用PackageInstaller安装。这种方式适合设备交付时只给一个安装包的场景，也方便渠道替换目标 APK。

public void installApkFromAssets(Context context, String assetName) throws Exception { File apkFile = new File(context.getCacheDir(), assetName); try (InputStream is = context.getAssets().open(assetName); FileOutputStream fos = new FileOutputStream(apkFile)) { byte[] buffer = new byte[1024 * 8]; int len; while ((len = is.read(buffer)) != -1) { fos.write(buffer, 0, len); } } PackageInstaller.Session session = null; try { PackageInstaller packageInstaller = context.getPackageManager().getPackageInstaller(); PackageInstaller.SessionParams params = new PackageInstaller.SessionParams( PackageInstaller.SessionParams.MODE_FULL_INSTALL); params.setAppPackageName("com.demo.targetapp"); int sessionId = packageInstaller.createSession(params); session = packageInstaller.openSession(sessionId); try (OutputStream os = session.openWrite("demo", 0, apkFile.length())) { byte[] buffer = new byte[1024 * 8]; int len; try (InputStream is = new FileInputStream(apkFile)) { while ((len = is.read(buffer)) != -1) { os.write(buffer, 0, len); } } session.fsync(os); } Intent callbackIntent = new Intent(context, InstallResultReceiver.class); PendingIntent pendingIntent = PendingIntent.getBroadcast( context, 0, callbackIntent, PendingIntent.FLAG_IMMUTABLE); session.commit(pendingIntent.getIntentSender()); } finally { if (session != null) { session.close(); } } }

PackageInstaller.SessionParams.MODE_FULL_INSTALL表示完整安装新应用而不是覆盖数据；session.openWrite后需要注意调用fsync，确保 APK 数据落盘后再提交安装。安装完成后系统会发送ACTION_PACKAGE_ADDED广播，在InstallResultReceiver里监听完成后再次调用launchByPackageName。

4.2.1 内置 APK 方案的坑

第一，session.commit之后系统在安装期间耗时会比较长，不建议在onReceive主线程直接执行。第二，目标 APK 的签名与当前 DEMO 签名不一致时，如果目标 APK 声明了sharedUserId，安装会失败。第三，assets 目录里的 APK 名不要带空格和中文，避免PackageInstaller内部解析异常。

4.3 两种方式选择对照

5. 开机自启生效的验证方法：adb 模拟、dumpsys 与厂商自启动白名单

开发时不可能每次都重启真机，更高效的验证路径是先用 adb 手动发送开机广播，再检查服务存活状态。

# 发送开机广播给指定包名 adb shell am broadcast -a android.intent.action.BOOT_COMPLETED \ -p com.demo.bootlauncher # 查看目标进程是否存活 adb shell ps -A | grep demo # 查看前台服务运行状态 adb shell dumpsys activity services com.demo.bootlauncher # 查看应用是否处于 stopped 状态 adb shell dumpsys package com.demo.bootlauncher | grep stopped

广播发出后观察 BootReceiver 中的日志有没有打印。Android 12 之后的设备，从 adb 发出的广播与实际开机广播在进程白名单上有细微差异，若 adb 模拟成功而真实重启失败，优先检查厂商自启动白名单。

国产 ROM 的路径有固定规律：小米在“设置-应用设置-授权管理-自启动管理”中允许；华为在“设置-应用-应用启动管理”中关闭自动限制；vivo 在“设置-电池-后台高耗电”与“自启动”中双向开启；OPPO 在“设置-电池-应用耗电管理”中允许自启动并允许后台运行。这些开关名称在不同系统版本上有差异，但关键词始终是“自启动”和“后台运行”。

验证阶段最容易踩的坑是通知权限。Android 13 及更高版本，如果未授权通知权限，前台服务的通知栏不可见，用户容易误以为服务没启动，调试时会平白浪费时间。建议在主界面用一个按钮跳转到通知授权页，把引导流程放进 DEMO 的 MainActivity 中。另一个技巧是使用adb shell dumpsys meminfo查看进程的 oom_adj 值，值越小代表进程优先级越高，0是前台进程，通常在0到2之间代表前台服务正常工作。若该值长时间处于后台级别，说明系统仍在压缩进程内存，服务并不会常驻，需要回到清单检查前台服务类型声明是否完整。

本文还有配套的精品资源，点击获取