Проверка случая setVisibility NullPointer

В моем аварийном журнале я иногда вижу следующее:

Fatal Exception: java.lang.NullPointerException: Attempt to invoke virtual method 'void android.view.View.setVisibility(int)' on a null object reference
   at AbstractFragment.init(Unknown Source)
   at ExtendingFragment.onEnabled(Unknown Source)
   at ExtendingFragment.enableScrolling(Unknown Source)
   at ExtendingFragment$7.onClick(Unknown Source)
   at android.view.View.performClick(View.java:5210)

...

так просто, правда? проблема наверняка в AbstractFragment.init, но:

void init(MyPOJO myPOJO, View.OnClickListener aListener, View.OnClickListener bListener,
                    boolean stored) {
    this.myPOJO= myPOJO;
    this.aListener = aListener;
    this.bListener = bListener;
    this.stored = stored;
    this.inflater = LayoutInflater.from(getActivity());

    used = new SparseBooleanArray();
    verticalMargin = getResources().getDimensionPixelSize(R.dimen.article_spacing_vertical);
    horizontalMargin = getResources().getDimensionPixelSize(R.dimen.article_spacing_horizontal);
    if (samsung_4_4_have_bug == null) //static
        samsung_4_4_have_bug = Build.VERSION.SDK_INT == 19 &&
                Build.MANUFACTURER.toLowerCase(Locale.getDefault()).contains("samsung");
}

любой вызов setVisibility здесь, на самом деле это просто "сеттер". Так может в ExtendingFragment.onEnabled? Посмотрим:

@Override
public void onEnabled(int pendingId) {
    if (pendingId == localId && someView != null)
        someView.post(() -> someView.callOnClick());
}

тоже нет setVisibility ... внутри прикрепленного OnClickListener нет ни setVisibility, ни звонков AbstractFragment.init ...

внутри ExtendingFragment.enableScrolling готовлю несколько слушателей, но звонка setVisibility нет ни в одной

ExtendingFragment$7.onClick предполагают, что этот NullPointer возникает после некоторого OnClick, но я проверил ВСЕ OnClickListeners в обоих слоях фрагментов, и вы никогда не угадаете ... Ни в одном из них нет вызова setVisibility ...

так как это решить? Я использую переключение visibility, но его нет ни в одном из перечисленных в стеке методов. как это проверить?

Похоже, что stacktrace взят из сборки, оптимизированной для proguard. Оптимизация может включать встроенные методы и т. д., Поэтому трассировки стека не всегда точны. Ищите код поблизости в том же классе.

laalto 22.11.2018 13:15

это похоже на магию. Но Java не использует магию. Таким образом, либо код не тот, из которого построено аварийное приложение, либо трассировка стека не из этого кода (что на самом деле одно и то же)

Vladyslav Matviienko 22.11.2018 13:15

@laalto ваше предложение может быть правильным, но я проверил "ближний" код и, к сожалению, не нашел никаких вызовов setVisibility ... proguard должен "очень глубоко" перемешать мой код: / есть идеи, как это проверить? может быть, файлы сопоставления, созданные прогардом, могут помочь в поиске?

snachmsm 23.11.2018 10:05

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

laalto 23.11.2018 10:08

на самом деле я проверил и (к сожалению) не сохранил эти файлы (для сборки, которая сообщает об ошибке). Я планирую выпустить обновление в ближайшие несколько дней, после чего сохраню соответствующие файлы для дальнейшего изучения. PS. log из Crashlytics, я не вижу возможности для загрузки файлов сопоставления, но это возможно в консоли GP (и Firebase?). Спасибо за предложение, я думаю, это хорошая подсказка

snachmsm 23.11.2018 11:26
0
5
51
0

Другие вопросы по теме