I've also run into this same problem with some code I was maintaining. I was able to consistently replicate the bug by enabling TalkBack in the accessibility options.
First, here's the method from View.java where the null reference that caused the crash was used, from the KitKat release of Android:
void sendAccessibilityEventUncheckedInternal(AccessibilityEvent event) {
if (!isShown()) {
return;
}
onInitializeAccessibilityEvent(event);
// Only a subset of accessibility events populates text content.
if ((event.getEventType() & POPULATING_ACCESSIBILITY_EVENT_TYPES) != 0) {
dispatchPopulateAccessibilityEvent(event);
}
// In the beginning we called #isShown(), so we know that getParent() is not null.
getParent().requestSendAccessibilityEvent(this, event);
}
For me, the root cause turned out to be a custom View which had overridden View.isShown() like so:
public boolean isShown(){
return someCondition;
}
This meant that sendAccessibilityEventUncheckedInternal would run past the if(!isShown()) check that it makes before proceeding even when the View had a null parent, and so caused the crash.
I had originally thought it was a concurrency problem, because I assumed the isShown() check had ensured the parent wasn't null and that the reference to the View's parent had been changed during the execution of sendAccessibilityEventUncheckedInternal. Wrong!
If you find a similar problem, especially in code you didn't write, you can prevent this crash pretty easily by including the result of the superclass's isShown() (assuming you are changing code in a direct subClass of View):
public boolean isShown(){
return super.isShown() && someCondition;
}