【问题标题】:After Upgrading to Google Play Services 9.0.0, App Hangs in DynamiteModulesC升级到 Google Play Services 9.0.0 后,DynamiteModulesC 中 App 挂起
【发布时间】:2016-05-21 01:23:59
【问题描述】:

通过这些更改和 google-services.json 的重新生成将开发中的应用升级到 9.0.0:

classpath 'com.google.gms:google-services:3.0.0'
compile 'com.google.android.gms:play-services:9.0.0'

升级后,当应用程序初始化时,会出现预期的 logcat 消息序列。大约 7 秒后,再次输出相同的消息序列,并添加了标题 background_crash。例如:

17:39:30.162 5453-5453/com.xxx.nub:background_crash I/MultiDex: install done

应用程序正常运行,直到它被隐藏,例如通过在另一个应用程序中启动一个活动。 5 秒后系统检测到应用已挂起:

05-20 17:40:10.315 5138-5138/com.xxx.nub I/MainActivity: STOP MainActivity
05-20 17:40:10.375 5138-5138/com.xxx.nub I/NubApplication: onTrimMemory(): TRIM_MEMORY_UI_HIDDEN
05-20 17:40:10.375 5138-5138/com.xxx.nub D/FirebaseApp: Notifying background state change listeners.
05-20 17:45:10.465 5138-5143/com.xxx.nub I/dalvikvm: threadid=3: reacting to signal 3
05-20 17:45:10.565 5138-5143/com.xxx.nub I/dalvikvm: Wrote stack traces to '/data/anr/traces.txt'

堆栈跟踪显示应用程序挂在com.google.android.gms.DynamiteModulesC

----- pid 5138 at 2016-05-20 17:45:10 -----
Cmd line: com.xxx.nub

JNI: CheckJNI is off; workarounds are off; pins=0; globals=295

DALVIK THREADS:
(mutexes: tll=0 tsl=0 tscl=0 ghl=0)

"main" prio=5 tid=1 WAIT
  | group="main" sCount=1 dsCount=0 obj=0x416c5ea0 self=0x415bb5d0
  | sysTid=5138 nice=-11 sched=0/0 cgrp=apps handle=1073844564
  | state=S schedstat=( 0 0 0 ) utm=1774 stm=244 core=1
  at java.lang.Object.wait(Native Method)
  - waiting on <0x42804a68> (a aaf)
  at java.lang.Object.wait(Object.java:364)
  at aaf.a(:com.google.android.gms.DynamiteModulesC:75)
  at zq.onTrimMemory(:com.google.android.gms.DynamiteModulesC:1187)
  at android.app.Application.onTrimMemory(Application.java:148)
  at com.xxx.nub.NubApplication.onTrimMemory(NubApplication.java:211)
  at android.app.ActivityThread.handleTrimMemory(ActivityThread.java:4298)
  at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1481)
  at android.os.Handler.dispatchMessage(Handler.java:102)
  at android.os.Looper.loop(Looper.java:146)
  at android.app.ActivityThread.main(ActivityThread.java:5487)
  at java.lang.reflect.Method.invokeNative(Native Method)
  at java.lang.reflect.Method.invoke(Method.java:515)
  at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1283)
  at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1099)
  at dalvik.system.NativeStart.main(Native Method)

问题出现在运行 KitKat 的手机上。该问题不会发生在运行 Lollipop 的手机上。

完整的logcat输出可以查看here

【问题讨论】:

    标签: android google-play-services


    【解决方案1】:

    background_crash 进程由Firebase Crash Reporting 创建。这就是您看到重复消息的原因,但我认为这不是根本原因。我将把挂起作为上游的问题提交给 Google Play 服务团队,但您可能同时可以使用一种解决方法:

    因为您将 com.google.android.gms:play-services:9.0.0 指定为依赖项,所以您实际上引入了所有 Google Play 服务 - 这很多!

    我建议将该行替换为您需要的特定依赖项。您可以找到完整列表 here。例如,如果您使用地图和 Google 登录,您可以指定:

    compile 'com.google.android.gms:play-services-auth:9.0.0'
    compile 'com.google.android.gms:play-services-maps:9.0.0'
    

    【讨论】:

    • 正如您所建议的,我用应用程序实际需要的七个特定依赖项替换了对 play-services 的依赖项。该更改消除了 logcat 中的挂起和许多与 Firebase 相关的警告消息。感谢您的回答并提出问题。
    • @IanBarber 这是否意味着 classpath 'com.google.gms:google-services:3.0.0' 仍将包含在项目级别的 gradle 中?
    • 是的,那个留在那里,因为它是 gradle 本身而不是您的应用程序的插件。
    猜你喜欢
    • 2016-09-15
    • 1970-01-01
    • 2016-11-02
    • 2016-09-16
    • 1970-01-01
    • 2016-04-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多