16

Upgraded an app in development to 9.0.0 with these changes and a regeneration of google-services.json:

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

After upgrade, when the app initializes, the expected sequence of logcat messages appear. After about 7 seconds, the same sequence of messages is output again, with added header background_crash. For example:

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

The app operates normally until it becomes hidden, for example by starting an activity in another app. After 5 seconds the system detects that the app is hung:

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'

The stack trace shows the app is hung in 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)

The problem occurs on a phone running KitKat. The problem does not occur on a phone running Lollipop.

The complete logcat output can be viewed here.

Bob Snyder
  • 37,759
  • 6
  • 111
  • 158

1 Answers1

23

The background_crash process is created by Firebase Crash Reporting. That's why you're seeing the duplicate messages, but I don't think its the root cause here. I'm going to file the hang as an issue upstream with the Google Play services team, but there is probably a workaround you can use in the mean time:

Because you're specifying com.google.android.gms:play-services:9.0.0 as a dependency you're bringing in literally all of Google Play services - which is a lot!

I would recommend replacing that line with the specific dependencies you need. You can find a full list here. As an example, if you're using Maps and Google Sign In, you might specify:

compile 'com.google.android.gms:play-services-auth:9.0.0'
compile 'com.google.android.gms:play-services-maps:9.0.0'
Ian Barber
  • 19,765
  • 3
  • 58
  • 58
  • 2
    As you suggested, I replaced the dependency on play-services with the seven specific dependencies the app actually needs. That change eliminated the hang and many of the Firebase related warning messages in the logcat. Thanks for the answer and filing the issue. – Bob Snyder May 22 '16 at 21:40
  • @IanBarber does that mean the `classpath 'com.google.gms:google-services:3.0.0'` would still be included in the project level gradle? – Paula Kristin May 27 '16 at 10:43
  • 1
    Yep, that one stays there as it is a plugin for gradle itself rather than your app. – Ian Barber May 27 '16 at 22:43