Memory leak in PreferenceFragmentCompat adapter handling [121006469]

Fixed

Bug

Status Update

No update yet.

Description

js...@gmail.com

created issue #1

Dec 14, 2018 07:54PM

RecyclerView registers an observer (

https://android.googlesource.com/platform/frameworks/support/+/androidx-master-dev/recyclerview/recyclerview/src/main/java/androidx/recyclerview/widget/RecyclerView.java#1201) that is only unregistered manually, by either setting the adapter again, or calling unregisterAdapterDataObserver externally.

PreferenceFragmentCompat sets this adapter (PreferenceGroupAdapter), which implicitly registers an observer. PreferenceFragmentCompat never sets the adapter to null when the view is destroyed, so the observer keeps references to the RecyclerView and doesn't get gc'ed.

I've worked around this by explicitly setting the adapter to null in an override of onDestroyView, but since my component doesn't explicitly have ownership of the list handling, I'd argue that PreferenceFragmentCompat should do this cleanup.

It would be solved by setting the RecyclerView adapter to null in the fragment's onDestroyView.

Here's a memory dump.

2018-12-14_10-38-54_921.hprof

23 MB

Download

Comments

lp...@google.com <lp...@google.com> #2Jan 10, 2019 11:35PM

Project: platform/frameworks/support
Branch: androidx-main

commit 57ca221882695bd6a52549f4d9ea3b812e6fe87c
Author: Simon Schiller <simonschiller@users.noreply.github.com>
Date: Mon Mar 22 16:09:30 2021

[GH] [FragmentStrictMode] Detect <fragment> tag usage

## Proposed Changes

- Detect `<fragment>` tag usage inside XML layouts

## Testing

Test: See `FragmentStrictModeTest#detectFragmentTagUsage`

## Issues Fixed

Fixes: 153738235

This is an imported pull request from

https://github.com/androidx/androidx/pull/141.

Resolves #141
Github-Pr-Head-Sha: 4ea052596e4341b9f11bcf335e2bc38045a91f19
GitOrigin-RevId: 62e7487aa4874eef6bb556490e193717cf937251
Change-Id: Iae48578e85e4e4897f806d7ade2e2a660adf9479

M fragment/fragment/api/public_plus_experimental_current.txt
M fragment/fragment/api/restricted_current.txt
M fragment/fragment/src/androidTest/java/androidx/fragment/app/strictmode/FragmentStrictModeTest.kt
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentLayoutInflaterFactory.java
M fragment/fragment/src/main/java/androidx/fragment/app/strictmode/FragmentStrictMode.java
A fragment/fragment/src/main/java/androidx/fragment/app/strictmode/FragmentTagUsageViolation.java

https://android-review.googlesource.com/1649748

lp...@google.com <lp...@google.com> #3Jan 14, 2019 08:41PM

Marked as fixed.

Nevermind, this has been fixed and will be available in an upcoming release.

ma...@gmail.com <ma...@gmail.com> #4Feb 28, 2020 01:26PM

An unfortunate side effect of this seems to be that the adapter is set to null before any pending fragment animations are completed.

In my project I add a PreferenceFragmentCompat to the backstack, specifying custom enter and exit animations. Now, when the user presses the back button I call FragmentManager.popBackStack() which in turn starts the custom exit animation.

The problem is that popBackstack() internally calls onDestroyView() on the PreferenceFragmentCompat to be removed. The PreferenceFragmentCompat calls unbindPreferences() which calls getListView().setAdapter(null).

The effect is that the list of preference items is cleared instantly before the exit animation even starts! This causes a white flicker and is clearly noticeable, the preference items disappear, then the view fades out.

Could you prevent setAdapter(null) from being called in this scenario? Maybe unregister the data observer instead?

jb...@google.com <jb...@google.com> #5Feb 28, 2020 05:57PM

Since the Fragment 1.2.0-alpha02 release fragments wait until exit animations are complete before onDestroyView() is called so this should not be an issue in any current Fragment versions.

Please file a bug against Fragments the with a sample project that reproduces this issue and we will be happy to take a look at what's going on.

ma...@gmail.com <ma...@gmail.com> #6Feb 29, 2020 09:16PM

I can confirm that using fragment 1.2.2 resolves the issue, thank you!

Without an explicit dependency declaration version 1.1.0 was still used (transient dependency of appcompat 1.1.0).

Issue 121006469