Android ActivityThread.reportSizeConfigurations provoque un gel de l'application avec un écran noir, puis une panne.

Question

J'ai un crash dans mon application. Il se produit pour beaucoup d'utilisateurs et se produit à plusieurs endroits dans la méthode reportSizeConfigurations de ActivityThread.java. Je ne sais pas à quoi elle sert et pourquoi elle se bloque.

Le gel se produit juste après l'écran d'accueil (lorsque l'activité principale est lancée) et ne se produit que lors de la mise à niveau de l'application. Si vous réinstallez l'application, le problème disparaît. Le problème est que je ne peux pas dire à tous les utilisateurs de réinstaller l'application...

Quelqu'un sait-il ce qui peut causer cela et pourquoi ? Il semble que ce soit lié à la manipulation de la base de données, mais ce n'est qu'une supposition.

Voici le suivi de pile de Crashlytics :

Fatal Exception: java.lang.IllegalArgumentException: reportSizeConfigurations: ActivityRecord not found for: Token{a28a055 null}
   at android.os.Parcel.readException(Parcel.java:1697)
   at android.os.Parcel.readException(Parcel.java:1646)
   at android.app.ActivityManagerProxy.reportSizeConfigurations(ActivityManagerNative.java:8342)
   at android.app.ActivityThread.reportSizeConfigurations(ActivityThread.java:3049)
   at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2992)
   at android.app.ActivityThread.-wrap14(ActivityThread.java)
   at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1631)
   at android.os.Handler.dispatchMessage(Handler.java:102)
   at android.os.Looper.loop(Looper.java:154)
   at android.app.ActivityThread.main(ActivityThread.java:6682)
   at java.lang.reflect.Method.invoke(Method.java)
   at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1520)
   at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1410)

Voici le suivi de pile de la boutique en ligne "ANRs & crashes" :

    "main" prio=5 tid=1 TimedWaiting
  | group="main" sCount=1 dsCount=0 obj=0x74864f70 self=0x7f8b896a00
  | sysTid=28578 nice=0 cgrp=default sched=0/0 handle=0x7f8f832a98
  | state=S schedstat=( 237746089 66838748 1069 ) utm=18 stm=5 core=6 HZ=100
  | stack=0x7fcdbf9000-0x7fcdbfb000 stackSize=8MB
  | held mutexes=

  at java.lang.Object.wait! (Native method)
- waiting on <0x0c54fb7b> (a java.lang.Object)
  at java.lang.Thread.parkFor$ (Thread.java:2127)
- locked <0x0c54fb7b> (a java.lang.Object)
  at sun.misc.Unsafe.park (Unsafe.java:325)
  at java.util.concurrent.locks.LockSupport.parkNanos (LockSupport.java:201)
  at android.database.sqlite.SQLiteConnectionPool.waitForConnection (SQLiteConnectionPool.java:670)
  at android.database.sqlite.SQLiteConnectionPool.acquireConnection (SQLiteConnectionPool.java:348)
  at android.database.sqlite.SQLiteSession.acquireConnection (SQLiteSession.java:894)
  at android.database.sqlite.SQLiteSession.prepare (SQLiteSession.java:586)
  at android.database.sqlite.SQLiteProgram.<init> (SQLiteProgram.java:58)
  at android.database.sqlite.SQLiteQuery.<init> (SQLiteQuery.java:37)
  at android.database.sqlite.SQLiteDirectCursorDriver.query (SQLiteDirectCursorDriver.java:44)
  at android.database.sqlite.SQLiteDatabase.rawQueryWithFactory (SQLiteDatabase.java:1318)
  at android.database.sqlite.SQLiteQueryBuilder.query (SQLiteQueryBuilder.java:399)
  at android.database.sqlite.SQLiteQueryBuilder.query (SQLiteQueryBuilder.java:294)
  at com.norwegian.travelassistant.managers.storagemanager.StorageManager.query (StorageManager.java:1011)
  at com.norwegian.travelassistant.managers.storagemanager.StorageManager.a (StorageManager.java:1218)
- locked <0x00f0bd98> (a java.lang.Object)
  at com.norwegian.travelassistant.managers.storagemanager.StorageManager.a (StorageManager.java:1205)
  at com.norwegian.travelassistant.managers.storagemanager.StorageManager.F (StorageManager.java:1812)
  at com.norwegian.travelassistant.managers.e.a (LanguageManager.java:63)
  at com.norwegian.travelassistant.managers.e.a (LanguageManager.java:84)
  at com.norwegian.travelassistant.tabbar.TabsActivity.onCreate (TabsActivity.java:141)
  at android.app.Activity.performCreate (Activity.java:6705)
  at android.app.Instrumentation.callActivityOnCreate (Instrumentation.java:1119)
  at android.app.ActivityThread.performLaunchActivity (ActivityThread.java:2664)
  at android.app.ActivityThread.handleLaunchActivity (ActivityThread.java:2772)
  at android.app.ActivityThread.-wrap12 (ActivityThread.java)
  at android.app.ActivityThread$H.handleMessage (ActivityThread.java:1515)
  at android.os.Handler.dispatchMessage (Handler.java:102)
  at android.os.Looper.loop (Looper.java:241)
  at android.app.ActivityThread.main (ActivityThread.java:6217)
  at java.lang.reflect.Method.invoke! (Native method)
  at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run (ZygoteInit.java:865)
  at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:755)

Veuillez nous dire si vous avez besoin de plus d'informations

Answer 1

Le crash est causé par l'ANR sur votre Service, avant le lancement de votre Activité.

Si un utilisateur lance votre application pendant une tâche de longue durée dans votre service, l'activité ne sera pas créée avant la fin de la tâche dans le service. Cette attente peut sembler bizarre à l'utilisateur qui lance votre application, puis il fait glisser votre application dans le sélecteur de tâches, ce qui supprime l'enregistrement de la tâche du ActivityManager (mais le processus est toujours maintenu en vie à ce moment-là).

Lorsque la tâche de longue durée sur le service revient enfin, elle débloque le lancement de l'activité, mais à ce moment-là l'activité lancera ActivityRecord not found exception car il a déjà été supprimé.

Le diagramme de séquence suivant pourrait mieux expliquer le crash.

Le mérite en revient à YogiAi, qui a initialement enquêté sur la question en ce poste .

Answer 2

Il y a un bug ouvert avec Google, qui semble exclusif à Samsung sur les mises à jour d'applications.

https://issuetracker.google.com/issues/62427912

Answer 3

L'une des raisons de ce problème peut être une fuite de mémoire. Dans le programme de Houde blog il écrit l'application qui utilise EventBus pour recevoir l'événement pour fermer l'activité, et un événement a été l'écriture d'une classe interne, qui a causé par une fuite de mémoire.

Une fuite de mémoire provoque une activité qui n'est pas un lancement mais un redémarrage. D'après lui, c'est ce qui cause le problème.

Un autre problème pourrait être le délai de pause/arrêt/destruction de l'activité. Cela peut conduire à la même