Inspecting NullPointer setVisibility case












0















In my crash log I see occasionally this:



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)


...



that easy, right? problem is surely in AbstractFragment.init, but:



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");
}


any setVisibility call in here, in fact it's just a "setter". So maybe in ExtendingFragment.onEnabled? Lets see:



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


no setVisibility also... inside attached OnClickListener there is no setVisibility and also no AbstractFragment.init calls...



inside ExtendingFragment.enableScrolling I'm preparing few listeners, but no setVisibility call in any



ExtendingFragment$7.onClick suggest that this NullPointer occurs after some OnClick, but I've checked ALL OnClickListeners in both fragment layers and you will never guess... There is no setVisibility call in any of these...



so how to resolve this? I'm using some visibility switching, but not in any of listed in stack methods. how to inspect that?










share|improve this question




















  • 1





    Looks like the stacktrace is from a proguard-optimized build. The optimization can inline methods etc. so the stacktraces are not always accurate. Look for code nearby in the same class.

    – laalto
    Nov 22 '18 at 12:15











  • this looks like magic. But Java does not use magic. So either the code is not the one the crashing app is built from, or the stacktrace is not from this code (which in fact is the same)

    – Vladyslav Matviienko
    Nov 22 '18 at 12:15











  • @laalto your suggestion may be right, but I've checked "near" code and unfortunatelly didn't found any setVisibility calls... proguard must mix my code "very deeply" :/ any idea how to inspect that? maybe mapping files generated by proguard may help in searching?

    – snachmsm
    Nov 23 '18 at 9:05











  • Another possibility is that the mapping file does not really belong to this build, so the deobfuscated method names are incorrect.

    – laalto
    Nov 23 '18 at 9:08











  • in fact I've checked and (sadly) I don't have stored these files (for build, which is reporting bug). I'm planning to release update in next few days, then I will keep appropriate files for further inspection. PS. log is from Crashlytics, I don't see option for uploading mapping files, but this is possible in GP console (and Firebase?). Thanks for suggestion, I think its a good clue

    – snachmsm
    Nov 23 '18 at 10:26


















0















In my crash log I see occasionally this:



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)


...



that easy, right? problem is surely in AbstractFragment.init, but:



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");
}


any setVisibility call in here, in fact it's just a "setter". So maybe in ExtendingFragment.onEnabled? Lets see:



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


no setVisibility also... inside attached OnClickListener there is no setVisibility and also no AbstractFragment.init calls...



inside ExtendingFragment.enableScrolling I'm preparing few listeners, but no setVisibility call in any



ExtendingFragment$7.onClick suggest that this NullPointer occurs after some OnClick, but I've checked ALL OnClickListeners in both fragment layers and you will never guess... There is no setVisibility call in any of these...



so how to resolve this? I'm using some visibility switching, but not in any of listed in stack methods. how to inspect that?










share|improve this question




















  • 1





    Looks like the stacktrace is from a proguard-optimized build. The optimization can inline methods etc. so the stacktraces are not always accurate. Look for code nearby in the same class.

    – laalto
    Nov 22 '18 at 12:15











  • this looks like magic. But Java does not use magic. So either the code is not the one the crashing app is built from, or the stacktrace is not from this code (which in fact is the same)

    – Vladyslav Matviienko
    Nov 22 '18 at 12:15











  • @laalto your suggestion may be right, but I've checked "near" code and unfortunatelly didn't found any setVisibility calls... proguard must mix my code "very deeply" :/ any idea how to inspect that? maybe mapping files generated by proguard may help in searching?

    – snachmsm
    Nov 23 '18 at 9:05











  • Another possibility is that the mapping file does not really belong to this build, so the deobfuscated method names are incorrect.

    – laalto
    Nov 23 '18 at 9:08











  • in fact I've checked and (sadly) I don't have stored these files (for build, which is reporting bug). I'm planning to release update in next few days, then I will keep appropriate files for further inspection. PS. log is from Crashlytics, I don't see option for uploading mapping files, but this is possible in GP console (and Firebase?). Thanks for suggestion, I think its a good clue

    – snachmsm
    Nov 23 '18 at 10:26
















0












0








0








In my crash log I see occasionally this:



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)


...



that easy, right? problem is surely in AbstractFragment.init, but:



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");
}


any setVisibility call in here, in fact it's just a "setter". So maybe in ExtendingFragment.onEnabled? Lets see:



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


no setVisibility also... inside attached OnClickListener there is no setVisibility and also no AbstractFragment.init calls...



inside ExtendingFragment.enableScrolling I'm preparing few listeners, but no setVisibility call in any



ExtendingFragment$7.onClick suggest that this NullPointer occurs after some OnClick, but I've checked ALL OnClickListeners in both fragment layers and you will never guess... There is no setVisibility call in any of these...



so how to resolve this? I'm using some visibility switching, but not in any of listed in stack methods. how to inspect that?










share|improve this question
















In my crash log I see occasionally this:



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)


...



that easy, right? problem is surely in AbstractFragment.init, but:



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");
}


any setVisibility call in here, in fact it's just a "setter". So maybe in ExtendingFragment.onEnabled? Lets see:



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


no setVisibility also... inside attached OnClickListener there is no setVisibility and also no AbstractFragment.init calls...



inside ExtendingFragment.enableScrolling I'm preparing few listeners, but no setVisibility call in any



ExtendingFragment$7.onClick suggest that this NullPointer occurs after some OnClick, but I've checked ALL OnClickListeners in both fragment layers and you will never guess... There is no setVisibility call in any of these...



so how to resolve this? I'm using some visibility switching, but not in any of listed in stack methods. how to inspect that?







android android-layout nullpointerexception






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 22 '18 at 12:27









Rohit5k2

14.5k42651




14.5k42651










asked Nov 22 '18 at 12:10









snachmsmsnachmsm

4,13911134




4,13911134








  • 1





    Looks like the stacktrace is from a proguard-optimized build. The optimization can inline methods etc. so the stacktraces are not always accurate. Look for code nearby in the same class.

    – laalto
    Nov 22 '18 at 12:15











  • this looks like magic. But Java does not use magic. So either the code is not the one the crashing app is built from, or the stacktrace is not from this code (which in fact is the same)

    – Vladyslav Matviienko
    Nov 22 '18 at 12:15











  • @laalto your suggestion may be right, but I've checked "near" code and unfortunatelly didn't found any setVisibility calls... proguard must mix my code "very deeply" :/ any idea how to inspect that? maybe mapping files generated by proguard may help in searching?

    – snachmsm
    Nov 23 '18 at 9:05











  • Another possibility is that the mapping file does not really belong to this build, so the deobfuscated method names are incorrect.

    – laalto
    Nov 23 '18 at 9:08











  • in fact I've checked and (sadly) I don't have stored these files (for build, which is reporting bug). I'm planning to release update in next few days, then I will keep appropriate files for further inspection. PS. log is from Crashlytics, I don't see option for uploading mapping files, but this is possible in GP console (and Firebase?). Thanks for suggestion, I think its a good clue

    – snachmsm
    Nov 23 '18 at 10:26
















  • 1





    Looks like the stacktrace is from a proguard-optimized build. The optimization can inline methods etc. so the stacktraces are not always accurate. Look for code nearby in the same class.

    – laalto
    Nov 22 '18 at 12:15











  • this looks like magic. But Java does not use magic. So either the code is not the one the crashing app is built from, or the stacktrace is not from this code (which in fact is the same)

    – Vladyslav Matviienko
    Nov 22 '18 at 12:15











  • @laalto your suggestion may be right, but I've checked "near" code and unfortunatelly didn't found any setVisibility calls... proguard must mix my code "very deeply" :/ any idea how to inspect that? maybe mapping files generated by proguard may help in searching?

    – snachmsm
    Nov 23 '18 at 9:05











  • Another possibility is that the mapping file does not really belong to this build, so the deobfuscated method names are incorrect.

    – laalto
    Nov 23 '18 at 9:08











  • in fact I've checked and (sadly) I don't have stored these files (for build, which is reporting bug). I'm planning to release update in next few days, then I will keep appropriate files for further inspection. PS. log is from Crashlytics, I don't see option for uploading mapping files, but this is possible in GP console (and Firebase?). Thanks for suggestion, I think its a good clue

    – snachmsm
    Nov 23 '18 at 10:26










1




1





Looks like the stacktrace is from a proguard-optimized build. The optimization can inline methods etc. so the stacktraces are not always accurate. Look for code nearby in the same class.

– laalto
Nov 22 '18 at 12:15





Looks like the stacktrace is from a proguard-optimized build. The optimization can inline methods etc. so the stacktraces are not always accurate. Look for code nearby in the same class.

– laalto
Nov 22 '18 at 12:15













this looks like magic. But Java does not use magic. So either the code is not the one the crashing app is built from, or the stacktrace is not from this code (which in fact is the same)

– Vladyslav Matviienko
Nov 22 '18 at 12:15





this looks like magic. But Java does not use magic. So either the code is not the one the crashing app is built from, or the stacktrace is not from this code (which in fact is the same)

– Vladyslav Matviienko
Nov 22 '18 at 12:15













@laalto your suggestion may be right, but I've checked "near" code and unfortunatelly didn't found any setVisibility calls... proguard must mix my code "very deeply" :/ any idea how to inspect that? maybe mapping files generated by proguard may help in searching?

– snachmsm
Nov 23 '18 at 9:05





@laalto your suggestion may be right, but I've checked "near" code and unfortunatelly didn't found any setVisibility calls... proguard must mix my code "very deeply" :/ any idea how to inspect that? maybe mapping files generated by proguard may help in searching?

– snachmsm
Nov 23 '18 at 9:05













Another possibility is that the mapping file does not really belong to this build, so the deobfuscated method names are incorrect.

– laalto
Nov 23 '18 at 9:08





Another possibility is that the mapping file does not really belong to this build, so the deobfuscated method names are incorrect.

– laalto
Nov 23 '18 at 9:08













in fact I've checked and (sadly) I don't have stored these files (for build, which is reporting bug). I'm planning to release update in next few days, then I will keep appropriate files for further inspection. PS. log is from Crashlytics, I don't see option for uploading mapping files, but this is possible in GP console (and Firebase?). Thanks for suggestion, I think its a good clue

– snachmsm
Nov 23 '18 at 10:26







in fact I've checked and (sadly) I don't have stored these files (for build, which is reporting bug). I'm planning to release update in next few days, then I will keep appropriate files for further inspection. PS. log is from Crashlytics, I don't see option for uploading mapping files, but this is possible in GP console (and Firebase?). Thanks for suggestion, I think its a good clue

– snachmsm
Nov 23 '18 at 10:26














0






active

oldest

votes











Your Answer






StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53430723%2finspecting-nullpointer-setvisibility-case%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























0






active

oldest

votes








0






active

oldest

votes









active

oldest

votes






active

oldest

votes
















draft saved

draft discarded




















































Thanks for contributing an answer to Stack Overflow!


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53430723%2finspecting-nullpointer-setvisibility-case%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

"Incorrect syntax near the keyword 'ON'. (on update cascade, on delete cascade,)

Alcedinidae

Origin of the phrase “under your belt”?