Android 4.4 Случайная авария KitKat - программирование

Недавно я обнаружил случайные сбои в приложении, которое я разрабатываю для клиента. Теперь через 3 года приложение имеет примерно 100 000 активных пользователей.

Мы не можем воспроизвести его на наших собственных Nexus 4 и 5 под управлением 4.4.

У нас был клиент через нашу поддержку. Он сказал нам, что авария происходит каждый раз в одном и том же месте при вызове новой активности. Он бежал Далвик, а не АРТ. После перезагрузки прошивки приложение отлично работало и не могло воспроизвести его снова!

Я не могу опубликовать источник или макет по юридическим причинам, но у меня есть этот стек:

РЕДАКТИРОВАТЬ: вторая стоп-трасса без привязки

Макет, устанавливаемый в setContentView(), содержит фреймы, иначе он довольно стандартный и простой.

Ответы

Ответ 1

Я также столкнулся с этой проблемой с некоторым кодом, который я поддерживал. Я смог последовательно реплицировать ошибку, включив TalkBack в параметрах доступности.

Во-первых, здесь используется метод из View.java, где была использована нулевая ссылка, вызвавшая крах, из выпуска KitKat для 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);
}

Для меня основной причиной оказался пользовательский вид, который переопределил View.isShown() следующим образом:

public boolean isShown(){
  return someCondition;
}

Это означало, что sendAccessibilityEventUncheckedInternal пропустит проверку if (! isShown()), которую он делает, прежде чем продолжить, даже если представление имеет нулевой родительский элемент и поэтому вызвало сбой.

Я изначально считал, что это проблема concurrency, потому что я предположил, что проверка isShown() гарантировала, что родительский элемент не был нулевым и что ссылка на родительский элемент View была изменена во время выполнения sendAccessibilityEventUncheckedInternal. Неправильно!

Если вы обнаружите подобную проблему, особенно в коде, который вы не пишете, вы можете легко избежать этого сбоя, включив в него результат суперкласса isShown() (при условии, что вы меняете код в прямом подклассе View):

public boolean isShown(){
  return super.isShown() && someCondition;
}

Ответ 2

Мои пользователи столкнулись с одной и той же проблемой и, похоже, вызваны включением одной или нескольких параметров доступности. Некоторые из моих пользователей использовали Pebble smart watch, который устанавливает параметр доступности - так что это не просто TalkBack и т.д.

Диагноз

Взгляните на этот бит метода KitKat View#setFlags() на https://github.com/android/platform_frameworks_base/blob/kitkat-mr1-release/core/java/android/view/View.java#L9006

if (accessibilityEnabled) {
  ...
  notifyViewAccessibilityStateChangedIfNeeded(
                        AccessibilityEvent.CONTENT_CHANGE_TYPE_UNDEFINED);
}

который отправляет вас вниз по кроличьей дыре, заканчивающейся на NullPointerException, если она выполняется до того, как представление присоединено к иерархии представления (т.е. не имеет родительского элемента), потому что в View#sendAccessibilityEventUncheckedInternal() в https://github.com/android/platform_frameworks_base/blob/kitkat-mr1-release/core/java/android/view/View.java#L4952:

getParent().requestSendAccessibilityEvent(this, event);

Мое обходное решение (похоже, оно не сработает для вас)

Для моего приложения я создаю подкласс View программно и вызывал View#setOnClickListener() в конструкторе. Вместо этого я теперь вызываю View#setOnClickListener() из

@Override
protected void onAttachedToWindow() {
    super.onAttachedToWindow();
    /* Due to a bug in how Android 4.4 handles accessibility options,
     * we can't set the onClick listener until this View has a parent or we will
     * get an NPE. */
    setOnClickListener(this);
}

Это работает, потому что этот View будет иметь родителя к тому времени, когда будет вызван View#onAttachedToWindow().

Трассировка стека более проблематична. Вы попадаете в отверстие кролика через атрибуты на макете XML. У меня нет идеи для вас. Одна мысль состоит в том, что это должно произойти только при запуске приложения - иначе практически все инфляции XML-макетов будут приводить к сбою, потому что существует так много путей, которые проходят через View#setFlags(). В моем приложении это одно место является единственным крахом, и это происходит при запуске приложения. Это не приятная идея, но одна из возможностей заключается в том, чтобы переупорядочить вещи, чтобы раздуть это мнение позже.