Comment trouver la source des plantages de type java.lang.RuntimeException: Parcel android.os.Parcel@####: Unmarshalling code de type inconnu XXXX au décalage YYY

Je viens d'apprendre que vous pouvez empêcher votre appareil de test d'empêcher les activités. Il y a une option dans les options pour les développeurs, section "Applications" qui, une fois activée, détruit les activités chaque fois que l'utilisateur les quitte.

Après avoir activé cette option, j'ai pu reproduire l'erreur en fermant et en rouvrant simplement mon application. Comme vous l'avez dit, c'est une erreur dans la méthode onCreate (). Dans mon cas, la raison est une exception ClassNotFoundException lors de la suppression d'un Parcelable personnalisé de mon état d'instance enregistré. Cela pourrait ne pas être une solution à votre problème, mais au moins pourrait vous aider à reproduire et à identifier l'erreur. Bonne chasse!

D'après mon expérience, une erreur comme celle-ci concerne moins ce qui se passe lorsque l'erreur se produit, mais plus ce qui s'est passé plus tôt dans votre application. Plus précisément, lorsque l'application est passée en arrière-plan.

Mais en commençant par ce que la trace de pile révèle. TopLevelFragment est en cours de restauration à partir de l'état précédent. Au cours de cette restauration, les fragments enfants de TopLevelFragment sont en cours de restauration. Lors de la restauration des fragments enfants, l'état de fragment enregistré de l'une des tentatives du fragment de se décompresser lorsque getSparseParcelableArray () est appelé sur Bundle pour récupérer l'état de vue enregistré du fragment. Cela se produit dans FragmentManager.java, ligne 1329. Il y a quelque chose à propos de l'état de fragment enregistré que Parcel ne sait pas quoi faire car il se démarshaling lui-même.

Pour affiner sur quel fragment enfant de TopLevelFragment vous devriez vous concentrer, je mettrais un point d'arrêt sur la ligne 1329 de FragmentManager.java et inspecterais le type Fragment f is. Gardez à l'esprit que plusieurs fragments enfants peuvent être restaurés, vous voulez donc voir quel fragment ne peut pas dépasser la ligne 1329.

Mais bien sûr, vous avez forcé cette logique de restauration à se produire de manière cohérente. Si vous envoyez simplement votre application en arrière-plan et la ramenez au premier plan, cela ne se produira probablement pas. Vous pouvez donc faire comme le suggère Richard R et utiliser l'option développeur "Ne pas conserver les activités" pour forcer Android à détruire et restaurer les activités.

Une fois que vous avez déterminé quel fragment est le problème, vous devez revenir plus tôt dans votre application et examiner de plus près les types de données que vous mettez à l'état de sauvegarde dans Fragment.onSaveInstanceState (). Espérons que cela vous oriente dans la bonne direction.

S'il s'agit d'un problème de proguard, vous devriez voir l'erreur disparaître si vous désactivez la minification. Et si tel est le cas, vous aurez peut-être besoin d'une règle proguard ou d'une annotation @Keep sur l'un de vos types de colis personnalisés. Si l'erreur se produit avec et sans minification, elle n'est probablement pas liée à la proguard.

Pour obtenir ce type de traces de pile, nous pouvons utiliser des crashlytics ou nous pouvons définir manuellement le gestionnaire d'exceptions par défaut

public class CustomExceptionHandler implements       UncaughtExceptionHandler {
private UncaughtExceptionHandler defaultUEH;
private String dirName;
private String url;

/*
* if any of the parameters is null, the respective functionality
* will not be used
*/           
public CustomExceptionHandler(String dirName, String url) {
this.dirName = dirName;
this.url = url;
this.defaultUEH = Thread.getDefaultUncaughtExceptionHandler();
}

public void uncaughtException(Thread t, Throwable e) {
final Writer result = new StringWriter();
final PrintWriter printWriter = new PrintWriter(result);
e.printStackTrace(printWriter);
String stacktrace = result.toString();
printWriter.close();           
if (dirName != null) {
writeToFile(stacktrace);
}
defaultUEH.uncaughtException(t, e);
}          
private void writeToFile(String stacktrace) {
try {
File myDir = new File(dirName.replace(" ", "") + "_Log");
if (!myDir.exists()) {
myDir.mkdir();
}
//Store only 10 file in device because of size.
if (myDir != null & myDir.isDirectory() & myDir.listFiles().length > 10) {
File[] filelist = myDir.listFiles();
for (int i = 0; i < filelist.length; i++) {
try {
filelist[i].delete();
} catch (Exception e) {}
}
}
Calendar c = Calendar.getInstance();                       c.setTimeInMillis(System.currentTimeMillis());
String fileName = "";
fileName = c.get(Calendar.SECOND) + "-" +
c.get(Calendar.MINUTE) + "-" +
c.get(Calendar.HOUR) + "-" +
(c.get(Calendar.AM) == 0 ? "AM" : "PM") + "_" +
c.get(Calendar.DAY_OF_MONTH) + "-" +
(c.get(Calendar.MONTH) + 1) + "-" +
c.get(Calendar.YEAR) + ".txt";
File f = new File(myDir, fileName);
FileWriter fr = new FileWriter(f);
BufferedWriter bos = new BufferedWriter(fr);
bos.write(stacktrace);
bos.flush();
bos.close();
} catch (Exception e) {
e.printStackTrace();
}
}
}

Pour stocker le journal dans le chemin du fichier ...

    public class BaseActivity extends Activity {
    @Override
    protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);

    if (!(Thread.getDefaultUncaughtExceptionHandler() instanceof CustomExceptionHandler)) {
    String path = Environment.getExternalStorageDirectory()
    + "/" + getString(R.string.app_name);
    Thread.setDefaultUncaughtExceptionHandler(new
    CustomExceptionHandler(path, ""));
    }
    }