Gluon Attach 4.0.16启动时出现黑屏问题求助

环境信息 #

<maven-compiler-plugin-version>3.10.1</maven-compiler-plugin-version>
<maven-surefire-plugin-version>3.0.0-M6</maven-surefire-plugin-version>
<javafx-maven-plugin-version>0.0.8</javafx-maven-plugin-version>
<gluonfx-maven-plugin-version>1.0.15</gluonfx-maven-plugin-version>

<java-version>17</java-version>
<javafx-version>19</javafx-version>
<charm-version>6.1.0</charm-version>
<attach-version>4.0.16</attach-version>

• 指定javafxStaticSdkVersion为19
• 使用GraalVM版本：graalvm-svm-java17-linux-gluon-22.1.0.1-Final
• 依赖的Attach服务：

<attachList>
    <list>display</list>
    <list>lifecycle</list>
    <list>statusbar</list>
    <list>storage</list>
    <list>position</list>
    <list>accelerometer</list>
    <list>magnetometer</list>
    <list>audio</list>
</attachList>

问题现象 #

升级Attach到4.0.16后，应用启动出现黑屏；回退到4.0.15版本时运行正常。此前4.0.14版本曾出现过PositionService导致黑屏的类似问题，怀疑是回归问题。

错误日志 #

更新到GluonFX 1.0.16-SNAPSHOT并取消日志过滤后，捕获到关键异常：

10-17 15:04:24.966 26884 26908 D GluonAttach: Util :: Load className com/gluonhq/helloandroid/DalvikDisplayService
10-17 15:04:24.982 26884 26908 F zygote64: java_vm_ext.cc:504] JNI DETECTED ERROR IN APPLICATION: JNI NewStringUTF called with pending exception java.lang.RuntimeException: Can't create handler inside thread that has not called Looper.prepare()
10-17 15:04:24.982 26884 26908 F zygote64: java_vm_ext.cc:504]   at void android.os.Handler.<init>(android.os.Handler$Callback, boolean) (Handler.java:203)
10-17 15:04:24.982 26884 26908 F zygote64: java_vm_ext.cc:504]   at void android.os.Handler.<init>() (Handler.java:117)
10-17 15:04:24.982 26884 26908 F zygote64: java_vm_ext.cc:504]   at void android.content.ClipboardManager$2.<init>(android.content.ClipboardManager) (ClipboardManager.java:84)
10-17 15:04:24.982 26884 26908 F zygote64: java_vm_ext.cc:504]   at void android.content.ClipboardManager.<init>(android.content.Context, android.os.Handler) (ClipboardManager.java:84)
10-17 15:04:24.982 26884 26908 F zygote64: java_vm_ext.cc:504]   at android.content.ClipboardManager android.app.SystemServiceRegistry$12.createService(android.app.ContextImpl) (SystemServiceRegistry.java:379)
10-17 15:04:24.982 26884 26908 F zygote64: java_vm_ext.cc:504]   at java.lang.Object android.app.SystemServiceRegistry$12.createService(android.app.ContextImpl) (SystemServiceRegistry.java:377)
10-17 15:04:24.982 26884 26908 F zygote64: java_vm_ext.cc:504]   at java.lang.Object android.app.SystemServiceRegistry$CachedServiceFetcher.getService(android.app.ContextImpl) (SystemServiceRegistry.java:1402)
10-17 15:04:24.982 26884 26908 F zygote64: java_vm_ext.cc:504]   at java.lang.Object android.app.SystemServiceRegistry.getSystemService(android.app.ContextImpl, java.lang.String) (SystemServiceRegistry.java:1354)
10-17 15:04:24.982 26884 26908 F zygote64: java_vm_ext.cc:504]   at java.lang.Object android.app.ContextImpl.getSystemService(java.lang.String) (ContextImpl.java:1695)
10-17 15:04:24.982 26884 26908 F zygote64: java_vm_ext.cc:504]   at java.lang.Object android.view.ContextThemeWrapper.getSystemService(java.lang.String) (ContextThemeWrapper.java:171)
10-17 15:04:24.982 26884 26908 F zygote64: java_vm_ext.cc:504]   at java.lang.Object android.app.Activity.getSystemService(java.lang.String) (Activity.java:6008)
10-17 15:04:24.982 26884 26908 F zygote64: java_vm_ext.cc:504]   at void com.gluonhq.helloandroid.Util.<init>(android.app.Activity) (Util.java:53)
10-17 15:04:24.982 26884 26908 F zygote64: java_vm_ext.cc:504]
10-17 15:04:24.982 26884 26908 F zygote64: java_vm_ext.cc:504]     in call to NewStringUTF
10-17 15:04:24.982 26884 26908 F zygote64: java_vm_ext.cc:504] "Thread-6" daemon prio=5 tid=16 Runnable
10-17 15:04:24.982 26884 26908 F zygote64: java_vm_ext.cc:504]   | group="main" sCount=0 dsCount=0 flags=0 obj=0x12e80000 self=0x7e74f27800
10-17 15:04:24.982 26884 26908 F zygote64: java_vm_ext.cc:504]   | sysTid=26908 nice=0 cgrp=default sched=0/0 handle=0x7e604ff4f0
10-17 15:04:24.982 26884 26908 F zygote64: java_vm_ext.cc:504]   | state=R schedstat=( 106877037 2373803 92 ) utm=9 stm=1 core=2 HZ=100
10-17 15:04:24.982 26884 26908 F zygote64: java_vm_ext.cc:504]   | stack=0x7e60405000-0x7e60407000 stackSize=1005KB
10-17 15:04:24.982 26884 26908 F zygote64: java_vm_ext.cc:504]   | held mutexes= "mutator lock"(shared held)
10-17 15:04:24.982 26884 26908 F zygote64: java_vm_ext.cc:504]   native: #00 pc 00000000003973ec  /system/lib64/libart.so (_ZN3art15DumpNativeStackERNSt3__113basic_ostreamIcNS0_11char_traitsIcEEEEiP12BacktraceMapPKcPNS_9ArtMethodEPv+212)
10-17 15:04:24.982 26884 26908 F zygote64: java_vm_ext.cc:504]   native: #01 pc 000000000045dba0  /system/lib64/libart.so (_ZNK3art6Thread9DumpStackERNSt3__113basic_ostreamIcNS1_11char_traitsIcEEEEbP12BacktraceMapb+348)
10-17 15:04:24.982 26884 26908 F zygote64: java_vm_ext.cc:504]   native: #02 pc 00000000002d57b8  /system/lib64/libart.so (_ZN3art9JavaVMExt8JniAbortEPKcS2_+1040)
10-17 15:04:24.982 26884 26908 F zygote64: java_vm_ext.cc:504]   native: #03 pc 00000000002d5c38  /system/lib64/libart.so (_ZN3art9JavaVMExt9JniAbortVEPKcS2_St9__va_list+116)
10-17 15:04:24.982 26884 26908 F zygote64: java_vm_ext.cc:504]   native: #04 pc 0000000000108878  /system/lib64/libart.so (_ZN3art11ScopedCheck6AbortFEPKcz+148)
10-17 15:04:24.982 26884 26908 F zygote64: java_vm_ext.cc:504]   native: #05 pc 00000000001083a4  /system/lib64/libart.so (_ZN3art11ScopedCheck11CheckThreadEP7_JNIEnv+536)
10-17 15:04:24.982 26884 26908 F zygote64: java_vm_ext.cc:504]   native: #06 pc 0000000000106840  /system/lib64/libart.so (_ZN3art11ScopedCheck5CheckERNS_18ScopedObjectAccessEbPKcPNS_12JniValueTypeE+856)
10-17 15:04:24.982 26884 26908 F zygote64: java_vm_ext.cc:504]   native: #07 pc 00000000000fd004  /system/lib64/libart.so (_ZN3art8CheckJNI12NewStringUTFEP7_JNIEnvPKc+648)
10-17 15:04:24.982 26884 26908 F zygote64: java_vm_ext.cc:504]   native: #08 pc 00000000019c07f0  /data/app/com.gps.demo-vSN-YTEtwQ1kgcyL1xFIMg==/lib/arm64/libsubstrate.so (registerDalvikClass+448)
10-17 15:04:24.982 26884 26908 F zygote64: java_vm_ext.cc:504]   native: #09 pc 00000000019be2e4  /data/app/com.gps.demo-vSN-YTEtwQ1kgcyL1xFIMg==/lib/arm64/libsubstrate.so (initializeDisplayDalvikHandles+36)
10-17 15:04:24.982 26884 26908 F zygote64: java_vm_ext.cc:504]   native: #10 pc 00000000019bde90  /data/app/com.gps.demo-vSN-YTEtwQ1kgcyL1xFIMg==/lib/arm64/libsubstrate.so (JNI_OnLoad_display+140)
10-17 15:04:24.982 26884 26908 F zygote64: java_vm_ext.cc:504]   native: #11 pc 00000000002e2ea8  /data/app/com.gps.demo-vSN-YTEtwQ1kgcyL1xFIMg==/lib/arm64/libsubstrate.so (JNILibraryInitializer_callOnLoadFunction_7833a452cbe2b969eec248ff45fd5fe129f3cbdc+104)
10-17 15:04:24.982 26884 26908 F zygote64: java_vm_ext.cc:504]   (no managed stack frames)
10-17 15:04:24.982 26884 26908 F zygote64: java_vm_ext.cc:504]

问题分析 #

日志显示，加载DalvikDisplayService时，在非UI线程（Thread-6）中尝试初始化ClipboardManager，而该系统服务内部创建Handler时，要求线程必须先调用Looper.prepare()。非UI线程默认没有Looper，因此触发RuntimeException，进而导致JNI调用失败，应用崩溃黑屏。

解决方案 #

1. 临时回退版本：将Attach版本从4.0.16回退到4.0.15，这是最直接的解决方式，因为该版本无此问题。
2. 调整初始化时机：如果必须使用4.0.16版本，可调整代码逻辑，确保DisplayService在UI线程初始化；若需在非UI线程初始化，需提前为线程准备Looper：

   if (Looper.myLooper() == null) {
       Looper.prepare();
   }
   // 执行DisplayService初始化逻辑
   // 若为独立后台线程，需调用Looper.loop()维持消息循环
   

3. 等待官方修复：该问题属于Attach库的内部实现回归，可关注Gluon官方更新，等待修复版本发布。

内容的提问来源于stack exchange，提问作者user1803551