Fixed
Status Update
Comments
be...@gmail.com <be...@gmail.com> #2
I see same issue and have been debugging it.
NOTE: It DOES NOT happen if not using support package, but use android level 14/15 library. I believe Honeycomb works well too.
My current workaround is to provide my own DialogFragment.show() method, like below:
public int show(FragmentTransaction transaction, String tag) {
return show(transaction, tag, false);
}
public int show(FragmentTransaction transaction, String tag, boolean allowStateLoss) {
transaction.add(this, tag);
mRemoved = false;
mBackStackId = allowStateLoss ? transaction.commitAllowingStateLoss() : transaction.commit();
return mBackStackId;
}
NOTE: It DOES NOT happen if not using support package, but use android level 14/15 library. I believe Honeycomb works well too.
My current workaround is to provide my own DialogFragment.show() method, like below:
public int show(FragmentTransaction transaction, String tag) {
return show(transaction, tag, false);
}
public int show(FragmentTransaction transaction, String tag, boolean allowStateLoss) {
transaction.add(this, tag);
mRemoved = false;
mBackStackId = allowStateLoss ? transaction.commitAllowingStateLoss() : transaction.commit();
return mBackStackId;
}
be...@gmail.com <be...@gmail.com> #4
But Google pls fix this issue, as the expected behaviors must be consistent with ICS DialogFragment + FragmentManager and support package DialogFragment + FragmentManager.
It happens with both Support Package v4 r6 and v13 r6.
It happens with both Support Package v4 r6 and v13 r6.
ra...@google.com <ra...@google.com> #5
I have this problem too.
As a workaround I use a boolean in the onActivityResult to mark the desired dialog and show the dialog in the onResume.
As a workaround I use a boolean in the onActivityResult to mark the desired dialog and show the dialog in the onResume.
ng...@google.com <ng...@google.com> #7
This is definitely not a bug. There are times when onActivityResult() can be called before the Activity has restored its saved state... committing fragment transactions in these situations will simply not be remembered as a result (see this blog post: http://www.androiddesignpatterns.com/2013/08/fragment-transaction-commit-state-loss.html ).
Try moving your commits into "onPostResume()" instead as described here:http://stackoverflow.com/questions/16265733/failure-delivering-result-onactivityforresult/18345899#18345899
Try moving your commits into "onPostResume()" instead as described here:
be...@gmail.com <be...@gmail.com> #8
Adding a "super.onActivityResult(requestCode, resultCode, data)" call at the beginning of the method seems to fix the problem. I'm surprised than almost nobody came up with such a simple solution.
be...@gmail.com <be...@gmail.com> #9
Dear alockw...@google.com,
Let's say we have an application where we need to select a picture from gallery, and then when we come back to onActivityResult(), we need to show a DialogFragment asking the user if he really wants to send the file.
How do you propose we can implement this with the current API?
Thank you,
Sabin
Let's say we have an application where we need to select a picture from gallery, and then when we come back to onActivityResult(), we need to show a DialogFragment asking the user if he really wants to send the file.
How do you propose we can implement this with the current API?
Thank you,
Sabin
ng...@google.com <ng...@google.com> #10
Please also consider how to deal with "Avoid performing transactions inside asynchronous callback methods." problem which is stated in http://www.androiddesignpatterns.com/2013/08/fragment-transaction-commit-state-loss.html#more
dismissAllowingStateLoss() is the least resort for dismiss() dialog in onPostExecute(), but there is no solution for DialogFragment#show() in onPreExecute() callback.
dismissAllowingStateLoss() is the least resort for dismiss() dialog in onPostExecute(), but there is no solution for DialogFragment#show() in onPreExecute() callback.
be...@gmail.com <be...@gmail.com> #11
I have a similar problem, but I show the DialogFragment (not the one of the support library) on the onStart method call.
How could it be? And, how can I solve this?
How could it be? And, how can I solve this?
mi...@google.com <mi...@google.com> #13
public void showAllowingStateLoss(FragmentManager manager, String tag) {
FragmentTransaction ft = manager.beginTransaction();
ft.add(this, tag);
ft.commitAllowingStateLoss();
}
I looked up the source code and got this method. I'm wondering why Google add a @hide annotation to this great API?
FragmentTransaction ft = manager.beginTransaction();
ft.add(this, tag);
ft.commitAllowingStateLoss();
}
I looked up the source code and got this method. I'm wondering why Google add a @hide annotation to this great API?
be...@gmail.com <be...@gmail.com> #14
Agree #14.
mi...@google.com <mi...@google.com> #15
Just looked up source code and this method was introduced since API 23. So maybe here's another alternative:
getFragmentManager().beginTransaction()
.add(fragment, tag)
.commitAllowingStateLoss();
getFragmentManager().beginTransaction()
.add(fragment, tag)
.commitAllowingStateLoss();
mi...@google.com <mi...@google.com> #16
Oh my god..
This error happened to my app users..
Please refer to below logs.
Samsung Galaxy Note10+ 5G (d2x), Android 9
java.lang.IllegalStateException:
at androidx.fragment.app.FragmentManager.checkStateLoss (FragmentManager.java:1997)
at androidx.fragment.app.FragmentManager.enqueueAction (FragmentManager.java:2029)
at androidx.fragment.app.BackStackRecord.commitInternal (BackStackRecord.java:321)
at androidx.fragment.app.BackStackRecord.commit (BackStackRecord.java:286)
at androidx.fragment.app.DialogFragment.show (DialogFragment.java:156)
at com.xxx.yyyyy.ZZZActivity$8$1.run (ZZZActivity.java:585)
at android.os.Handler.handleCallback (Handler.java:873)
at android.os.Handler.dispatchMessage (Handler.java:99)
at android.os.Looper.loop (Looper.java:216)
at android.app.ActivityThread.main (ActivityThread.java:7263)
at java.lang.reflect.Method.invoke (Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:494)
at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:975)
This error happened to my app users..
Please refer to below logs.
Samsung Galaxy Note10+ 5G (d2x), Android 9
java.lang.IllegalStateException:
at androidx.fragment.app.FragmentManager.checkStateLoss (FragmentManager.java:1997)
at androidx.fragment.app.FragmentManager.enqueueAction (FragmentManager.java:2029)
at androidx.fragment.app.BackStackRecord.commitInternal (BackStackRecord.java:321)
at androidx.fragment.app.BackStackRecord.commit (BackStackRecord.java:286)
at androidx.fragment.app.DialogFragment.show (DialogFragment.java:156)
at com.xxx.yyyyy.ZZZActivity$8$1.run (ZZZActivity.java:585)
at android.os.Handler.handleCallback (Handler.java:873)
at android.os.Handler.dispatchMessage (Handler.java:99)
at android.os.Looper.loop (Looper.java:216)
at android.app.ActivityThread.main (ActivityThread.java:7263)
at java.lang.reflect.Method.invoke (Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:494)
at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:975)
be...@gmail.com <be...@gmail.com> #17
Thank you!
Description
I have an Android application which creates classes at runtime, loads it by InMemoryDexClassLoader and calls method of generated classes using MethodHandle API .
But sometimes calling
MethodHandle.invoke()
may lead to a crash with SIGSEGV. Probably because GC frees my class despite the fact that I still have a reference to it throughMethodHandle
's instance. The attachment contains a project with a minimal reproducible testcom.example.bugreport.ClassLoaderBugTest
. The bug reproduces in emulator on all API levels from 26 to 35.