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?
android 
android-layout nullpointerexception edited Nov 22 '18 at 12:27
Rohit5k2
14.5k42651
asked Nov 22 '18 at 12:10
snachmsmsnachmsm
4,13911134
add a comment |
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?
android android-layout nullpointerexception edited Nov 22 '18 at 12:27
Rohit5k2
14.5k42651
asked Nov 22 '18 at 12:10
snachmsmsnachmsm
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 anysetVisibilitycalls... 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
add a comment |
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?
android android-layout nullpointerexception edited Nov 22 '18 at 12:27
Rohit5k2
14.5k42651
asked Nov 22 '18 at 12:10
snachmsmsnachmsm
4,13911134
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 android android-layout nullpointerexception edited Nov 22 '18 at 12:27
Rohit5k2
14.5k42651
asked Nov 22 '18 at 12:10
snachmsmsnachmsm
4,13911134
edited Nov 22 '18 at 12:27
Rohit5k2
14.5k42651
asked Nov 22 '18 at 12:10
snachmsmsnachmsm
4,13911134
edited Nov 22 '18 at 12:27
Rohit5k2
14.5k42651
edited Nov 22 '18 at 12:27
Rohit5k2
14.5k42651
edited Nov 22 '18 at 12:27
Rohit5k2
14.5k42651
14.5k42651
asked Nov 22 '18 at 12:10
snachmsmsnachmsm
4,13911134
asked Nov 22 '18 at 12:10
snachmsmsnachmsm
4,13911134
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 anysetVisibilitycalls... 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
add a comment |
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 anysetVisibilitycalls... 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
add a comment |
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
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
setVisibilitycalls... 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