-
Notifications
You must be signed in to change notification settings - Fork 4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Another framework InputMethodManager leak (Moto G 4.4.4) #2
Comments
I can't answer that question for sure without the heap dump, it's unclear what this leak is about. SettingsActivity is not the leaking instance, so I'm going to assume it wasn't destroyed, otherwise you would probably have posted that as well. The leak here is From what I can read, this is very likely a leak in your app. In DockPreferences you set an OnCheckedChangeListener on a TintableSwitchCompat that is a switch that seems to be living in the action bar. Then you probably do a fragment transaction, the DockPreferences fragment gets destroyed, but the action bar is still living and holding to that OnCheckedChangeListener. You should probably remove the listener when the fragment is destroyed. I'm going to close this issue, but please follow up and let me know if that was it. It's kind of hard to do that without the codebase. |
I'm actually now seeing this on Samsung kitkat as well, here's one with a full activity leak:
hprof: http://teslacoilsw.com/tmp/inputmethodmanager_sinstance_dump.hprof And the Moto G again, this time with an activity leak:
I'm seeing it triggered by doing a startActivityForResult into a new process, so there is only one activity there and it gets onDestroyed at the end with nothing else in that process. It looks like basically the same issue as the InputMethodManager mCurRootView, it's just the trace is a bit different thanks to the sInstance. |
Known AOSP leak, already reported in #1. |
LeakCanary is awesome, I love the work you guys do.
I was going to introduce some leaks intentionally to test, but found this one instead. Seems to be a Motorola-ism as AOSP KitKat doesn't have an InputMethodManager.sInstance .
The text was updated successfully, but these errors were encountered: