IssueTracker

It's not just EditTextPreference related problem, just to clarify things. ListPreference throws the same exception.

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).

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.

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).

Your workaround seems to work properly, even if infinite backstack growth isn't desirable.

A possible fix to this issue is to use available indices greater than the current fragments target fragment (if one is set) index only in the makeActive method of FragmentManagerImpl.

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...

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.

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)

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`.

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

I'll probably be working around this by caching the needed fields the first time the fragment is created and storing them in the instance state. That way the fragment will be basically immune to re-creation order, and we'll be able to live with the fact that the preference object won't be available during fragment re-creation.

I was facing the zero code coverage report problem. Today I did completely removed android studio, android sdk, gradle. Then reinstall everything. After that, I just added inside the app build.gradle.

debug {
    testCoverageEnabled true
}
Then I run ./gradlew connectedChec. Everything is working perfectly. Android studio default Jacoco working fine for me. I think it is also possible to create a jacocoTestReport Task and then create code coverage.I don't know gradle and android studio was not working previously.

Assigning to you Chris, as you also own http://b.android.com/82835 which is either closely related or a duplicate.

[Comment deleted]

[Comment deleted]

[Comment deleted]