简介这份源码工程用于在Qt for Android平台上实现应用的开机自启动主要面向需要在安卓设备上让应用随系统一同启动的开发者。工程采用Qt Quick和QML构建界面并通过C实现核心逻辑同时提供Android清单文件、Gradle构建脚本、属性配置以及Java辅助代码完成Android侧权限声明与组件注册能够帮助读者清晰理解自启动实现所需的工程配置与代码衔接。压缩包共包含21个文件其中有cpp、h、qml等源码文件也有xml、properties、gradle、java等构建辅助文件整体大小仅为70KB结构紧凑便于快速阅读和改造。目前已有496人学习下载对于希望了解Qt与Android混合工程如何接入开机自启动的中级开发者而言这份轻量测试工程提供了一个可直接运行的参考起点参照它即可快速搭建自己的开机自启项目并理清各文件之间的调用关系。1. 开机自启动在Qt for Android里的真实成本用Qt写过Android应用的人应该都有体会QML侧做得再花哨一旦涉及系统级能力最终还是要回到AndroidManifest.xml和Java/Kotlin那层去解决问题。开机自启动就是典型例子——它不是把应用装进/system/priv-app那么简单而需要处理广播接收器、Activity启动模式、Qt应用进程的拉起方式以及Android 10以后的后台启动限制。这套测试源码有意思的地方在于它把TreeView的完整示例treemodel.cpp、treeitem.cpp、TreeViewPage.qml和Android构建脚本打包在一起让你不是对着空壳工程做自启动而是能在真实UI渲染成功、树形数据加载正常的前提下确认开机广播确实把整个Qt应用拉了起来。对想做工具类App、磁盘缓存清理、设备监控这类场景的Qt开发者来说这是个可以直接复用的基准工程。2. AndroidManifest.xml与广播接收器自启动的入口配置2.1 权限声明为什么是第一步Android系统的开机广播android.intent.action.BOOT_COMPLETED是一个受保护广播普通第三方应用必须显式声明接收权限否则广播不会送达。这个工程里包含完整的AndroidManifest.xml标准的配置方式是在 根节点下加上uses-permission android:nameandroid.permission.RECEIVE_BOOT_COMPLETED /注意这个权限的protectionLevel是normal安装时自动授予不需要走运行时权限弹窗。也因此容易被开发者忽略——很多人记得申请存储权限、定位权限却忘了这个最基础的入口。这里有个细节iOS那套“开机启动”思路完全不适用Android生态里BOOT_COMPLETED是唯一合法的普通应用开机回调点哪怕targetSdkVersion升到34这个权限声明依然是必须的。2.2 在manifest里声明BootReceiver光有权限还不够必须在AndroidManifest.xml里注册一个BroadcastReceiver并且用intent-filter把开机广播“接住”。参考该工程的结构你会看到类似下面的receiver节点receiver android:name.BootReceiver android:enabledtrue android:exportedtrue intent-filter action android:nameandroid.intent.action.BOOT_COMPLETED / /intent-filter /receiver这里有两个容易踩坑的配置点。第一android:exported必须显式声明。从Android 12targetSdk 31开始如果receiver带有intent-filter却没有设置exported应用直接安装失败或运行时报SecurityException。第二部分国产ROM会把应用“开机自启动”的能力做成一个独立的用户开关即使在manifest里注册了用户还要在系统设置的目标应用里手动允许“自启动”否则广播被系统拦截。这个工程里保留了AndroidManifest.xml.autosave文件就是编辑器自动备份不影响构建但可以观察到作者修改manifest的痕迹。2.3 广播里拉起Activity而不是直接跑QtQt for Android应用本质上是在Java层有个QtActivity作为入口然后再把QML引擎挂载到该Activity上。所以开机广播收到后你要做的是启动这个Activity让Qt框架把C和QML代码加载起来。常见做法是写一个Java文件package com.example.treeviewtest; import android.content.BroadcastReceiver; import android.content.Context; import android.content.Intent; public class BootReceiver extends BroadcastReceiver { Override public void onReceive(Context context, Intent intent) { if (Intent.ACTION_BOOT_COMPLETED.equals(intent.getAction())) { Intent activityIntent new Intent(context, MainActivity.class); activityIntent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK); context.startActivity(activityIntent); } } }说明BroadcastReceiver的onReceive执行期间context并不是Activity上下文因此启动Activity必须加上FLAG_ACTIVITY_NEW_TASK标志否则会在StartActivity时抛异常。MainActivity是Qt for Android在构建时根据工程包名自动生成的通常对应QtActivity的子类。如果你的工程里没有现成的Java源码也可以用Qt Android Extras里的QAndroidJniObject在C侧发送广播或执行Java方法不过维护成本更高不如直接写Java文件放在android/src目录下Qt构建脚本会自动编译进去。3. 在Qt Quick工程里组织自启动逻辑与TreeView测试页3.1 为什么用TreeView示例当载体这个源码包里最有价值的部分其实是TreeView那套模型treeitem.h、treeitem.cpp、treemodel.h、treemodel.cpp。它实现了一个标准的QAbstractItemModel多层树结构并且通过TreeViewPage.qml暴露给前端。作为开机自启动的测试载体它比“Hello World”可靠得多——如果开机后自启成功你会在屏幕看到树形节点渲染并且可以展开、折叠这证明Qt Quick引擎、模型层、QML视图层全部正常工作。很多自启动测试死在半路广播收到了Activity起来了但QML引擎崩溃界面上什么都没有。有了TreeView示例你能明确区分“没起来”和“起来但崩溃”。3.2 在main.cpp里判断启动来源自启动与手动启动有时需要走不同逻辑比如手动启动时显示正常主界面开机拉起时自动进入某个后台任务页。因为Qt应用从Java层启动时无法直接在C侧拿到Intent但可以通过参数传递判断。参考这个工程里的main.cpp你可以这样组织启动条件#include QGuiApplication #include QQmlApplicationEngine #include QCommandLineParser int main(int argc, char *argv[]) { QGuiApplication app(argc, argv); QCommandLineParser parser; parser.setApplicationDescription(TreeViewTest); parser.addHelpOption(); QCommandLineOption bootOption(boot, Started from boot receiver); parser.addOption(bootOption); parser.process(app); const bool isBootLaunch parser.isSet(bootOption); qInfo() Boot launch: isBootLaunch; QQmlApplicationEngine engine; engine.load(QUrl(QStringLiteral(qrc:/main.qml))); return app.exec(); }逻辑说明QCommandLineParser是否真的能拿到--boot参数取决于Java侧启动Activity时是否把它加进了Intent。你需要在BootReceiver的onReceive里给activityIntent.putExtra(boot, true)然后在MainActivity的onCreate中截获这个extra再通过Qt的Intent传递机制传给C。常见做法是写一个静态字段或者在QtActivity中覆写onCreate时调用QtNative.startMainActivity把参数拼到listData里。如果只是简单测试不区分启动源也可以不写这个判断但保留它会让later的日志排查更清晰。3.3 用QSettings记录每次开机启动状态自启动的调试点在于你真的知道应用是几点被拉起的吗我一般会在main.cpp里写一个简单的状态记录把每次开机启动的时间戳写进配置文件方便事后对比#include QSettings #include QDateTime void logBootStartup(bool isBoot) { QSettings settings(TreeViewTest, BootRecord); const QString key isBoot ? lastBootTime : lastManualTime; settings.setValue(key, QDateTime::currentDateTime().toString(Qt::ISODate)); settings.sync(); }这段代码里QSettings的构造参数“TreeViewTest”和“BootRecord”分别对应组织名和应用名在Android上最终会落在一个私有目录的ini文件里。调用settings.sync()是必须的否则应用进程被杀时数据可能未落盘。通过对比lastBootTime和lastManualTime你能直观看到自启动与手动启动的间隔这也是验证整条链路是否真生效的客观证据。4. gradle构建、权限与Android高版本适配排错4.1 gradlew.bat和gradle.properties在工程里的作用这个源码包里有gradle目录、gradlew.bat、gradlew、gradle.properties和build.gradle说明作者推荐直接用Gradle命令行构建Android APK而不是只在Qt Creator里点“构建”按钮。gradlew.bat是Windows下的wrapper脚本它会根据gradle/wrapper/gradle-wrapper.properties里的配置自动下载对应Gradle版本。gradle.properties里通常会写org.gradle.jvmargs-Xmx2048m -Dfile.encodingUTF-8 android.useAndroidXtrueorg.gradle.jvmargs控制Gradle虚拟机的堆内存如果你的工程里同时编译Qt模块和Java源码堆太小会直接OOM。android.useAndroidX这个开关在Qt for Android里比较敏感如果build.gradle里依赖的是androidx库就必须设为true反之如果沿用旧的支持库设为true会触发ClassNotFoundException。4.2 Android 10-13的后台启动限制与应对开机自启动一定会碰到Android高版本的后台限制不同场景应对策略差别很大。下面这个表格是我在实际适配中总结的targetSdkVersion限制内容自启动应对策略Android 10 (API 29)后台启动Activity受限开机广播拉起Activity时尽量在接收器里直接startActivity不要通过Service中转Android 11 (API 30)软件包可见性变化部分应用查询受限在manifest里加 声明声明需要查询的系统应用IDAndroid 12 (API 31)receiver必须显式声明android:exported把receiver和activity的exported属性都写清楚Android 13 (API 33)通知权限POST_NOTIFICATIONS如果自启动后要弹通知或展示进度条需要额外运行时申请通知权限注意一个经典误区很多人以为提高targetSdkVersion会导致自启动失效其实失效的真正原因是后台限制策略变化。比如Android 10开始应用在后台想启动Activity会被系统放到底层限制但BOOT_COMPLETED广播本身是例外的接收广播时应用正处于前台临时状态所以startActivity不会被限制。真正会失败的是接收器里先去启动了一个Service然后由Service尝试启动Activity这个链路在Android 10以后会被拦截。所以最佳路径一直是接收器里直接startActivity。4.3 排错四个logcat过滤点开机自启动失败时不要漫无目的地翻日志。我通常开四个logcat过滤窗口同时查看系统、Qt和应用三方的日志adb logcat -s ActivityManager:I adb logcat -s BOOT_COMPLETED:V AndroidRuntime:E adb logcat -s Qt:V qml:V adb logcat -v time | grep -E treeviewtest|FATAL EXCEPTION第一行查看ActivityManager对Activity启动的处理重点找“Start proc”和“START u0”日志。第二行确认BOOT_COMPLETED广播是否真的发出、应用是否崩溃。第三行过滤Qt和QML的调试输出main.cpp里的qInfo()记录会打到这里。第四行按时间戳过滤应用崩溃信息能看到Java堆栈还是libc的native崩溃。注意开机阶段系统自身日志非常多建议在重启完成后立即执行adb logcat -c清空旧日志然后重新抓取。5. 验证自启动效果日志、广播与开机时间点5.1 用adb命令模拟一次开机广播严格意义上BOOT_COMPLETED是受保护广播普通adb shell命令无法直接模拟但在Android 12以下某些设备上还是可以碰碰运气的adb shell am broadcast -a android.intent.action.BOOT_COMPLETED -p com.example.treeviewtest如果提示Permission Denial说明系统把这条广播保护起来了。我一般直接重启设备重启后立刻检查进程是否存活。在开发阶段更高效的验证方式是在BootReceiver里加一条调试日志重启后用logcat抓取广播时间点。5.2 在QML里显示系统uptime验证自启动不能只看进程在不在还要观察应用启动相对开机完成的延迟。QML里可以直接读取系统时间但更好的参数是uptimeTimer { interval: 1000 running: true repeat: true onTriggered: { textLabel.text Uptime: Math.floor(Date.now() / 1000) s } }这里Date.now()返回的是Unix时间戳你需要在Java层通过SystemClock.uptimeMillis()拿到开机时长后通过信号传给QML。常见做法是在main.cpp里用QAndroidJniObject调用静态方法返回millis然后存到QML上下文属性。对比uptime和日志里BOOT_COMPLETED的时间戳就能算出自启延迟。5.3 用dumpsys验证进程状态最后一步是确认进程没有被系统杀掉或者处于stoped状态adb shell dumpsys activity processes | grep com.example.treeviewtest adb shell ps -A | grep treeviewtest第一行能看到进程的adj优先级和是否被冻结第二行确认进程实际存在。如果进程在但界面没出来多半是Activity的launchMode配置问题如果进程都不存在排查方向就要回到广播接收器本身。5.4 一通操作后你应该得到一个明确的验证清单验证项通过标准权限注册manifest中RECEIVE_BOOT_COMPLETED存在Receiver导出Android 12以上exportedtrueActivity启动logcat中无SecurityExceptionQt启动logcat出现“Boot launch: true”QML渲染屏幕出现TreeView树形数据时间戳记录QSettings里lastBootTime已更新这套源码的价值就是把上述每一条都落在可运行的工程里。即使你最终不做自启动功能光是理解AndroidManifest.xml与Qt Quick应用的通信链路也足够让人少走两周弯路。本文还有配套的精品资源点击获取