Fixed
Status Update
No update yet.
Comments
ja...@gmail.com
It's not just EditTextPreference related problem, just to clarify things. ListPreference throws the same exception.
ad...@google.com
la...@gmail.com
That stack trace implies that the preference that the dialog is based on couldn't be found. That could happen for obvious reasons (not loading the correct set of preference items in onCreatePreferences) or for subtle reasons (fragments getting onCreate called in an unexpected order).
ad...@google.com
This only appears on a specific order of adding Fragment instances and making them active in an Activity. I mean there are chances to not get the exception. The problem lies in the mActive List of active Fragment instances in the FragmentManager of the Activity. When restoring the state of the Activity on orientation change, in some cases the child PreferenceDialogFragmentCompat is created before the parent/target Fragment's onCreate() got called (if its position index in mActive List is lower). So the preference (requested in the onCreate() of the PreferenceDialogFragmentCompat through the parent/target Fragment) in the parent/target Fragment is not initialized. Maybe this helps to fix this issue.
ad...@google.com
Ah, hmm. I've seen some (unrelated) issues internally with fragment ID recycling. Feels like kind of a misguided idea in general. I think a root fix to this lies in tweaking the fragment manager.
In the mean time, you can try to arrange your fragments such that fragments created earlier remain active (being on the backstack counts).
In the mean time, you can try to arrange your fragments such that fragments created earlier remain active (being on the backstack counts).
ri...@gmail.com
Comment has been deleted.
ze...@gmail.com
Any time table on fixing this?
I'm planning to release a first alpha of my app and this preferences UI is the last thing I'm working on...
I'm planning to release a first alpha of my app and this preferences UI is the last thing I'm working on...
pi...@gmail.com
Another much cleaner and reasonable fix:
Use getChildFragmentManager() instead of getFragmentManager() in PreferenceFragmentCompat.onDisplayPreferenceDialog();
and use getParentFragment() instead of getTargetFragment() in PreferenceDialogFragmentCompat.
This way framework guarantees the order of calling onCreate(). It is also much more natural because preference dialog fragments are created and managed by our preference fragment.
Use getChildFragmentManager() instead of getFragmentManager() in PreferenceFragmentCompat.onDisplayPreferenceDialog();
and use getParentFragment() instead of getTargetFragment() in PreferenceDialogFragmentCompat.
This way framework guarantees the order of calling onCreate(). It is also much more natural because preference dialog fragments are created and managed by our preference fragment.
ra...@gmail.com
Unfortunately moving the dialog to the child preference manager is incompatible with how the dialog is presented in the leanback UI. (in leanback, the dialog replaces the preference fragment that launched it)
na...@gmail.com
I've read the preference-leanback source.
In the leanback library, the creation and management of LeanbackPreferenceDialogFragment is handled by the parent LeanbackSettingsFragment, which puts the PreferenceFragmentCompat and LeanbackPreferenceDialogFragment onto the same backstack and calls setTargetFragment() for LeanbackPreferenceDialogFragment.
This is logical because they are to replace each other. And I also wonder in this case, will the backstack preserve the order of calling onCreate(), so it won't have the bug as perference-v7?
However with preference-v7, the PreferenceDialogFragment is created and managed by PreferenceFragmentCompat itself, *they are logically parent and children*, just as the LeanbackSettingsFragment with PreferenceFragmentCompat and LeanbackPreferenceDialogFragment which indeed called `getChildFragmentManager` for adding them.
So I think PreferenceFragmentCompat.onDisplayPreferenceDialog() should be implemented with `getChildFragmentManager`.
In the leanback library, the creation and management of LeanbackPreferenceDialogFragment is handled by the parent LeanbackSettingsFragment, which puts the PreferenceFragmentCompat and LeanbackPreferenceDialogFragment onto the same backstack and calls setTargetFragment() for LeanbackPreferenceDialogFragment.
This is logical because they are to replace each other. And I also wonder in this case, will the backstack preserve the order of calling onCreate(), so it won't have the bug as perference-v7?
However with preference-v7, the PreferenceDialogFragment is created and managed by PreferenceFragmentCompat itself, *they are logically parent and children*, just as the LeanbackSettingsFragment with PreferenceFragmentCompat and LeanbackPreferenceDialogFragment which indeed called `getChildFragmentManager` for adding them.
So I think PreferenceFragmentCompat.onDisplayPreferenceDialog() should be implemented with `getChildFragmentManager`.
ad...@google.com
And by saying that the two implementation should be different because they are different in logic and behavior, I mean that I believe the EditTextPreference should have another implementation in preference-leanback, just as the TODO here: https://github.com/android/platform_frameworks_support/blob/master/v17/preference-leanback/src/android/support/v17/preference/LeanbackSettingsFragment.java#L77
Description
Case ID 0-0632000031099
Case ID 1-7572000031147
Case ID 8-6635000031896
Case ID 8-6635000031896
Case ID 2-7345000031743
Case ID 9-7750000031488
Case ID 8-9406000031270
well a couple issues. let me type them out
1. phone suddently started rebooting and rebooting in a loop. couldn't get it to stop rebooting
2. contacted google through this chat.
3. couldn't do power +volume down to get into recovery as screen would show NO COMMAND which to me seemed like the recovery partition was toast
4. after about 10 tries i finally got to the recovery and could wipe.
5. now with the wipe to factory settings the phone recovery is stuck at the COPY APPS AND DATA page. I say don't copy, it goes to next screen, asks to verify pin and then goes back to previous page
6. i was told to go to android beta page to opt out but when i do so it says CANNOT be done. here is the exact message as i will do it again right now
Could not remove device
We could not remove your device at this time. Please try again later.
that's the message. so
7. i don't know if the phone is stuck at COPY APPS AND DATA because of the enrollment in android beta
BUT....
8. i keep gettin google support giving me the message:
Due to your device running a pre-release version of Android, I cannot troubleshoot your device. There are currently no official support channels available for Android Beta users. Please see
You can also contact our repair partner.
You can locate our nearby authorized repair store by clicking on this link:
Please visit:
9. i cannot get the phone into a new recovery mode and i cannot get past the COPY APPS and data screen and i cannot opt out of the android beta program
10. yes i went to ubreakifix and they cannot do anything. here is their screenshot
ubreakifix.jpg
i've done everything you have stated above
the
IT WON"T LET ME OPT OUT
i just clicked on the link and here is the error messge
Could not remove device
We could not remove your device at this time. Please try again later.
i'm stuck as it won't opt me out and i'm thinking this is why i cannot reformat my phone.
place of purchase:
Order Number: 117518252
Store: BC879 - Bell World (632 Yonge St/Barrie)
Consultant: Janelle
Store Phone Number: (705) 719-7886
IMEI number
Model: Google Pixel 5 128GB Black
IMEI/ESN/MEID: 352494112731640
SIM Number: 89302610104322971264
my phone is not able to receive calls. you can call me at home - 905-883-6053 or on my wife's phone - 416-220-5477. please provide an update ASAP. thank you
To avoid the possibility of sharing private information, please share bugreports and screenshots from Google Drive. Share files with android-bugreport@google.com and include only Google drive links in your bug. If attaching bug reports or other sensitive data directly to issues, please mark the attachment(s) as “Restricted (
Disclaimer:
Please note, by submitting this bug report, you acknowledge that Google may use information included in the bug report to diagnose technical issues and to improve our products and services, in accordance with our Privacy Policy (
Bug reports include personal information logged on your device or by apps, such as:
File names
Installed apps and usage
Email addresses of the profiles on the device
Device identifiers, such as phone number
Web history information, including URLs / URIs
Location information, including limited location history
Network information, such as IP/SSID/MAC addresses and saved or scanned APNs
System or device information, such as memory and processes