This is a fix for:
https://code.google.com/p/ankidroid/issues/detail?id=1567
http://ankidroid-triage.appspot.com/view_bug?bug_id=4182062
but to be honest I am not sure if it is the right fix.

The import was actually successful, but without the updated counts, the deck picker will not show the right counts.
I am not sure if there is an underlying issue that causes the counts not to be updated correctly, but this would at least not crash...

What do you think?

It might just be that when it reaches that point the collection is not loaded.
The status of the collection (loaded/unloaded) changes a lot during the import, differently for each way of import. I spent a day debugging similar issues (import successful, but update of counts not happening, or flash screen not quitting).

The linked triage crash doesn't seem correct (it points to DeckPicker.java:L1664 where nullpointerexception seems unlikely).

Do you remember how to replicate the issue, what was the state of your collection before you imported, did it exist? was it open?

The transition diagram for the upgrade wizard is hard to follow, not sure how to simplify it, because the transition diagram around the deckpicker is already complicated.

In general, there's an ongoing (as far as I remember ankidroid's code) anti-pattern that generates many nullpointerexceptions, when we try to do something with a collection that is null. Maybe the problem is that we treat it as global variable whose state can change in dozens of places and threads. But what is a good way to handle this?

This is the line where the NPE happens:
https://github.com/nobnago/Anki-Android/blob/v2.0/src/com/ichi2/anki/DeckPicker.java#L1664

This is my understanding of what happens. The result of TASK_TYPE_IMPORT_REPLACE is true, but info is null. The result is coming from https://github.com/nobnago/Anki-Android/blob/v2.0/src/com/ichi2/async/DeckTask.java#L832, specifically from: https://github.com/nobnago/Anki-Android/blob/v2.0/src/com/ichi2/async/DeckTask.java#L890. The code there checks that result from https://github.com/nobnago/Anki-Android/blob/v2.0/src/com/ichi2/async/DeckTask.java#L475 is not null and returns null as the object array if it is null. However, that means that the calling code will NPE. The way null can come back is either that the collection passed in is null (https://github.com/nobnago/Anki-Android/blob/v2.0/src/com/ichi2/async/DeckTask.java#L479) or there was a RuntimeException (https://github.com/nobnago/Anki-Android/blob/v2.0/src/com/ichi2/async/DeckTask.java#L486). I was not able to replicate so far, but one of these two seems to be happening.

Yes, I think we have lots of NPEs in the code because the assumptions we make on the code are very clear. Mostly we should avoid nulls as much as possible, as a way to avoid NPEs.

In a way this is just a stopgap solution: it avoids the NPE when something fails at the inner level, but I am not sure what the underlying problem actually is...

I will try further to reproduce.

Did I submit the right pull request to you?
In my tree, I've updated this part and took the listeners for import and importreplace to variables mImportAddListener and mImportReplaceListener.
Norbert's branch was merged into mine, but I did further changes into it. This branch https://github.com/nobnago/Anki-Android/blob/v2.0/src/com/ichi2/anki/DeckPicker.java#L1664 has issues like the ones you mentioned (not updating counts under some cases).

Please try the one in branch v2.0.1-dev, which looks different for the line you mention:
https://github.com/iniju/Anki-Android/blob/v2.0.1-dev/src/com/ichi2/anki/DeckPicker.java#L1664

I based this on the crash reports for 2.0 and therefore I am looking at the 2.0 code.
This is one of the 3 top issues, and I was trying to look if we can fix it.

Maybe this is already fixed in 2.0.1?

I hope so, I surely fixed some instances of this in the wizard work

I understand now, you were testing 2.0. The stopgap is useful, but we should implement it also in the DeckTask.doInBackgroundImportAdd() method, since the same piece of code exists there.

Thanks Kostas. I updated to have the same stopgap in the other method.

Thank you!