Inspecting NullPointer setVisibility case
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
add a comment |
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
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 anysetVisibility
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
add a comment |
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
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
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 anysetVisibility
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
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 anysetVisibility
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
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
});
}
});
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
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.
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
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