В моем аварийном журнале я иногда вижу следующее:
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, но его нет ни в одном из перечисленных в стеке методов. как это проверить?
это похоже на магию. Но Java не использует магию. Таким образом, либо код не тот, из которого построено аварийное приложение, либо трассировка стека не из этого кода (что на самом деле одно и то же)
@laalto ваше предложение может быть правильным, но я проверил "ближний" код и, к сожалению, не нашел никаких вызовов setVisibility ... proguard должен "очень глубоко" перемешать мой код: / есть идеи, как это проверить? может быть, файлы сопоставления, созданные прогардом, могут помочь в поиске?
Другая возможность состоит в том, что файл сопоставления на самом деле не принадлежит этой сборке, поэтому имена деобфусцированных методов неверны.
на самом деле я проверил и (к сожалению) не сохранил эти файлы (для сборки, которая сообщает об ошибке). Я планирую выпустить обновление в ближайшие несколько дней, после чего сохраню соответствующие файлы для дальнейшего изучения. PS. log из Crashlytics, я не вижу возможности для загрузки файлов сопоставления, но это возможно в консоли GP (и Firebase?). Спасибо за предложение, я думаю, это хорошая подсказка
Похоже, что stacktrace взят из сборки, оптимизированной для proguard. Оптимизация может включать встроенные методы и т. д., Поэтому трассировки стека не всегда точны. Ищите код поблизости в том же классе.