简介面向需要实现后台保活与开机自启的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 与开机广播的边界targetSdk 版本开机广播行为后台启动 Service 行为25 及以下静态注册正常后台可任意 startService26 - 27静态注册正常权限需声明后台 startService 抛 IllegalStateException28 - 30静态注册正常必须使用 startForegroundService31 - 33静态注册正常从 BOOT_COMPLETED 拉起前台服务受限制34静态注册正常前台服务必须声明类型且不能任意后台启动2.2 后台保持运行的两根支柱前台服务与 START_STICKYBOOT_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 保活方案选型表方案存活时长适用场景前台服务 START_STICKY长直到被用户主动停止工控、监控类必须配合通知WorkManager 周期任务非精确会被延迟数据同步、心跳上报AlarmManager 精确闹钟受 Doze 模式影响定时巡检、唤醒自身双进程守护Android 8 基本不可用不建议在新项目采用我的建议是主题功能用前台服务辅助保活用 WorkManager 做周期心跳不碰双进程。这样代码在 Android 14 上不会因为没有后台启动权限直接崩溃。3. 最小工程搭建BootReceiver 拉起前台服务再启动指定 APK3.1 Manifest 中的权限、Receiver 与 Service 声明新建工程时包名假设为com.demo.bootlauncher主功能包含一个 Activity、一个继承自BroadcastReceiver的BootReceiver、一个前台服务KeepRunningService。AndroidManifest.xml的关键代码如下uses-permission android:nameandroid.permission.RECEIVE_BOOT_COMPLETED / uses-permission android:nameandroid.permission.FOREGROUND_SERVICE / uses-permission android:nameandroid.permission.FOREGROUND_SERVICE_SPECIAL_USE / uses-permission android:nameandroid.permission.POST_NOTIFICATIONS / application android:iconmipmap/ic_launcher android:labelstring/app_name activity android:name.MainActivity android:exportedtrue intent-filter action android:nameandroid.intent.action.MAIN / category android:nameandroid.intent.category.LAUNCHER / /intent-filter /activity receiver android:name.BootReceiver android:exportedtrue android:enabledtrue intent-filter action android:nameandroid.intent.action.BOOT_COMPLETED / /intent-filter /receiver service android:name.KeepRunningService android:exportedfalse android:foregroundServiceTypespecialUse property android:nameandroid.app.PROPERTY_SPECIAL_USE_FGS_SUBTYPE android:valuedevice_keep_alive / /service /applicationRECEIVE_BOOT_COMPLETED用于接收开机广播FOREGROUND_SERVICE是 Android 9 之后动态检查的前台服务权限缺少它会导致服务启动失败。FOREGROUND_SERVICE_SPECIAL_USE是 Android 14 新增的类型权限必须在清单里声明类型为specialUse并附上用途说明否则系统会认为你使用了未声明的前台服务类型运行时会报 SecurityException。POST_NOTIFICATIONS是 Android 13 开始的通知运行时权限不申请的话前台服务通知不会显示但服务本身仍能运行。android:exportedtrue是必须的因为系统需要把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通常出现在目标应用设置了exportedfalse或调用者缺少权限时需要在启动前用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 两种方式选择对照对比项包名启动assets 内置安装目标 APK 更新直接替换设备已装 APK需更新 Demo 工程重新打包首次装机时间秒级加上安装时间约 3-8 秒依赖系统权限无无适合场景镜像已内置 APK批量交付、渠道分发失败率低中受系统安装策略影响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之间代表前台服务正常工作。若该值长时间处于后台级别说明系统仍在压缩进程内存服务并不会常驻需要回到清单检查前台服务类型声明是否完整。本文还有配套的精品资源点击获取 
长河君 · 2026/9/16 1:44:05 · 阅读 1.2k 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 与开机广播的边界targetSdk 版本开机广播行为后台启动 Service 行为25 及以下静态注册正常后台可任意 startService26 - 27静态注册正常权限需声明后台 startService 抛 IllegalStateException28 - 30静态注册正常必须使用 startForegroundService31 - 33静态注册正常从 BOOT_COMPLETED 拉起前台服务受限制34静态注册正常前台服务必须声明类型且不能任意后台启动2.2 后台保持运行的两根支柱前台服务与 START_STICKYBOOT_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 保活方案选型表方案存活时长适用场景前台服务 START_STICKY长直到被用户主动停止工控、监控类必须配合通知WorkManager 周期任务非精确会被延迟数据同步、心跳上报AlarmManager 精确闹钟受 Doze 模式影响定时巡检、唤醒自身双进程守护Android 8 基本不可用不建议在新项目采用我的建议是主题功能用前台服务辅助保活用 WorkManager 做周期心跳不碰双进程。这样代码在 Android 14 上不会因为没有后台启动权限直接崩溃。3. 最小工程搭建BootReceiver 拉起前台服务再启动指定 APK3.1 Manifest 中的权限、Receiver 与 Service 声明新建工程时包名假设为com.demo.bootlauncher主功能包含一个 Activity、一个继承自BroadcastReceiver的BootReceiver、一个前台服务KeepRunningService。AndroidManifest.xml的关键代码如下uses-permission android:nameandroid.permission.RECEIVE_BOOT_COMPLETED / uses-permission android:nameandroid.permission.FOREGROUND_SERVICE / uses-permission android:nameandroid.permission.FOREGROUND_SERVICE_SPECIAL_USE / uses-permission android:nameandroid.permission.POST_NOTIFICATIONS / application android:iconmipmap/ic_launcher android:labelstring/app_name activity android:name.MainActivity android:exportedtrue intent-filter action android:nameandroid.intent.action.MAIN / category android:nameandroid.intent.category.LAUNCHER / /intent-filter /activity receiver android:name.BootReceiver android:exportedtrue android:enabledtrue intent-filter action android:nameandroid.intent.action.BOOT_COMPLETED / /intent-filter /receiver service android:name.KeepRunningService android:exportedfalse android:foregroundServiceTypespecialUse property android:nameandroid.app.PROPERTY_SPECIAL_USE_FGS_SUBTYPE android:valuedevice_keep_alive / /service /applicationRECEIVE_BOOT_COMPLETED用于接收开机广播FOREGROUND_SERVICE是 Android 9 之后动态检查的前台服务权限缺少它会导致服务启动失败。FOREGROUND_SERVICE_SPECIAL_USE是 Android 14 新增的类型权限必须在清单里声明类型为specialUse并附上用途说明否则系统会认为你使用了未声明的前台服务类型运行时会报 SecurityException。POST_NOTIFICATIONS是 Android 13 开始的通知运行时权限不申请的话前台服务通知不会显示但服务本身仍能运行。android:exportedtrue是必须的因为系统需要把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通常出现在目标应用设置了exportedfalse或调用者缺少权限时需要在启动前用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 两种方式选择对照对比项包名启动assets 内置安装目标 APK 更新直接替换设备已装 APK需更新 Demo 工程重新打包首次装机时间秒级加上安装时间约 3-8 秒依赖系统权限无无适合场景镜像已内置 APK批量交付、渠道分发失败率低中受系统安装策略影响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之间代表前台服务正常工作。若该值长时间处于后台级别说明系统仍在压缩进程内存服务并不会常驻需要回到清单检查前台服务类型声明是否完整。本文还有配套的精品资源点击获取