安卓厂商系统级强制弹出自启动权限框，因ROM识别应用为后台保活类；触发行为包括声明RECEIVE_BOOT_COMPLETED权限、使用后台音频、集成含自启的推送SDK等；应删除相关权限与广播接收器、禁用自启插件、选用standard启动模式并排查第三方SDK隐藏注册。
uni-app打包后安卓自动弹出自启动权限申请框？
不是 uni-app 主动申请，而是某些 Android 厂商（如小米、华为、OPPO、vivo）在应用首次冷启动时，**系统级强制检测并弹窗提示用户是否允许“自启动”**。uni-app 本身不调用 startActivity 或 AlarmManager 等触发该弹窗的 API，但只要你的应用被厂商 ROM 识别为“可能后台保活类应用”，就可能被拦截并弹窗。
哪些配置或行为会触发厂商自启动检测？
厂商 ROM 通常基于 manifest 声明、进程行为、服务注册、广播接收器等综合判断。以下操作容易被误判：
- 在
AndroidManifest.xml中声明了android.permission.RECEIVE_BOOT_COMPLETED权限，且注册了对应BroadcastReceiver - 使用了
uni.getBackgroundAudioManager()或uni.startBackgroundAudio()（部分版本底层启用了前台服务） - 插件市场引入了含后台服务的原生插件（如推送 SDK：个推、极光、华为 HMS Push），它们默认注册开机广播或常驻服务
- manifest 中设置了
android:process=":remote"或额外进程声明 - 使用了
uni.setKeepScreenOn(true)+ 长时间前台运行，被系统判定为“高耗电/保活嫌疑”
如何实质性减少或关闭该弹窗？
无法完全“关闭”，但可大幅降低触发概率。核心思路是：**不声明、不注册、不启用任何与开机/后台保活相关的原生能力**。
- 检查
unpackage/dist/build/android/AndroidManifest.xml（或你自定义的nativeplugins/xxx/android/AndroidManifest.xml），删除所有<uses-permission android:name="android.permission.RECEIVE_BOOT_COMPLETED" />及对应<receiver>块 - 禁用所有需要开机自启的插件：在
manifest.json → “SDK 配置” → “推送”中关闭所有推送服务；若必须用推送，选择仅支持「通知栏」不拉起进程的轻量方案（如微信小程序式静默通知） - 避免在 App.vue 的
onLaunch中调用uni.getBackgroundAudioManager()或启动任何plus.android.importClass(...)启动的服务 - 在 HBuilderX 3.2+ 中，打开
manifest.json → “Android 设置” → “应用启动模式”，选standard（勿选singleTask或singleInstance，后者易被厂商视为保活入口） - 如果使用自定义基座（custom debug base），确保其
AndroidManifest.xml未预埋自启动 receiver —— 这是最常被忽略的源头
测试时怎么确认是否还触发弹窗？
真机测试最可靠，注意三点：
- 用新手机或恢复出厂设置后的设备，首次安装 + 冷启动（杀掉进程后点击图标启动），观察是否弹出自启动开关页
- 在小米手机上进「设置 → 应用设置 → 自启动管理」，查看你的应用是否出现在列表中（出现即说明已被识别）
- 用
adb logcat | grep -i "autostart\|boot"抓日志，看是否有厂商 SDK 主动注册BOOT_COMPLETED广播的痕迹
真正难处理的是那些隐藏在第三方 SDK AAR 包里的静态 receiver —— 它们不写在你可见的 manifest 中，却在编译期被合并进去。这种必须联系插件作者提供无自启动版本，或改用 Web 推送（Service Worker + Push API）替代原生推送。
