Every editable TextView has an Editor instance which has a SpellChecker instance. SpellChecker is in charge of displaying the little squiggle spans that show typos. SpellChecker starts a SpellCheckerSession as needed and then closes it when the TextView is detached from the window. A SpellCheckerSession is in charge of communicating with the spell checker service (which lives in another process) through TextServicesManager.

The SpellChecker sends the TextView content to the spell checker service every 400ms, ie every time the service calls back with a result the SpellChecker schedules another check for 400ms later.

When the TextView is detached from the window, the spell checker closes the session. In practice, SpellCheckerSessionListenerImpl.mHandler is set to null and when the service calls SpellCheckerSessionListenerImpl.onGetSuggestions or SpellCheckerSessionListenerImpl.onGetSentenceSuggestions back from another process, there's a null check for SpellCheckerSessionListenerImpl.mHandler and the callback is dropped.

Unfortunately, on Android M there's a race condition in how that's done. When the service calls back into our app process, the IPC call is received on a binder thread. That's when the null check happens. If the session is not closed at this point (mHandler not null), the callback is then posted to the main thread. If on the main thread the session is closed after that post but prior to that post being handled, then the post will still be processed, after the session has been closed.

When the post is processed, SpellCheckerSession calls back into SpellChecker which in turns schedules a new spell check to be ran in 400ms. The check is an anonymous inner class (SpellChecker$1) stored as SpellChecker.mSpellRunnable and implementing Runnable. It is scheduled by calling View.postDelayed. As we've seen, at this point the session may be closed which means that the view has been detached. View.postDelayed behaves differently when a view is detached: instead of posting to the single Handler used by the view hierarchy, it enqueues the Runnable into ViewRootImpl.RunQueue, a static queue that holds on to "actions" to be executed. As soon as a view hierarchy is attached, the ViewRootImpl.RunQueue is processed and emptied.

Unfortunately, that means that as long as no view hierarchy is attached, ie as long as there are no activities alive, the actions stay in ViewRootImpl.RunQueue. That means SpellChecker$1 ends up being kept in memory. It holds on to SpellChecker which in turns holds on to the detached TextView and corresponding destroyed activity & view hierarchy.

We have a fix for this! When the spell check session is closed, we replace SpellCheckerSession.mSpellCheckerSessionListener (which normally is the SpellChecker) with a no-op implementation. So even if callbacks are enqueued to the main thread handler, these callbacks will call the no-op implementation and SpellChecker will not be scheduling a spell check.

Sources to corroborate:

https://android.googlesource.com/platform/frameworks/base/+/marshmallow-release/core/java/android/view/textservice/SpellCheckerSession.java https://android.googlesource.com/platform/frameworks/base/+/marshmallow-release/core/java/android/view/textservice/TextServicesManager.java https://android.googlesource.com/platform/frameworks/base/+/marshmallow-release/core/java/android/widget/SpellChecker.java https://android.googlesource.com/platform/frameworks/base/+/marshmallow-release/core/java/android/view/ViewRootImpl.java

Fix for https://code.google.com/p/android/issues/detail?id=171190 .

When a view that has focus gets detached, we wait for the main thread to be idle and then check if the InputMethodManager is leaking a view. If yes, we tell it that the decor view got focus, which is what happens if you press home and come back from recent apps. This replaces the reference to the detached view with a reference to the decor view.

Samsung added a static mContext field to ActivityManager, holding a reference to the activity.

This fix clears the field when an activity is destroyed if it refers to this specific activity.

Observed here: https://github.com/square/leakcanary/issues/177

A static helper for EditText bubble popups leaks a reference to the latest focused view.

This fix clears it when the activity is destroyed.

ConnectivityManager has a sInstance field that is set when the first ConnectivityManager instance is created. ConnectivityManager has a mContext field. When calling activity.getSystemService(Context.CONNECTIVITY_SERVICE) , the first ConnectivityManager instance is created with the activity context and stored in sInstance. That activity context then leaks forever.

This fix makes sure the connectivity manager is created with the application context.

Tracked here: https://code.google.com/p/android/issues/detail?id=198852 Introduced here: https://github.com/android/platform_frameworks_base/commit/e0bef71662d81caaaa0d7214fb0bef5d39996a69

HandlerThread instances keep local reference to their last handled message after recycling it. That message is obtained by a dialog which sets on an OnClickListener on it and then never recycles it, expecting it to be garbage collected but it ends up being held by the HandlerThread.

This flushes the TextLine pool when an activity is destroyed, to prevent memory leaks.

The first memory leak has been fixed in android-5.1.0_r1 https://github.com/android/platform_frameworks_base/commit/893d6fe48d37f71e683f722457bea646994a10bf

Second memory leak: https://github.com/android/platform_frameworks_base/commit/b3a9bc038d3a218b1dbdf7b5668e3d6c12be5ee4