Android EditText Memory Leak

Question

Alot of people are noticing EditText in an activity is holding a Strong Reference to an Activity even once its finished. To be clear this EditText is inside a layout and inflated, there is no Listeners set. This only happens on certain devices e.g. Samsung Galaxy S4 (Android 4.2.2) and others. Many post about this still no solution. First here is some useful posts. (Eventually GC will clean this so its not technically a leak, but for heavy memory apps it takes way to long and will cause OOM)

Android Samsung Memory leak in EditText

Why does EditText retain its Activity's Context in Ice Cream Sandwich

EditText causing memory leak

Possibility of unhandled memory leak

The solutions noted do not work for all devices. It comes down to the Edittext Watcher. I think there may be solution in overriding this Watcher then having a function to clean it up onDestroy(). Please any help here, I been at this for days.

Here is the MAT Histogram

Usurer

To be clear memory-leak detection devices can report "false positives". It is well documented and can be a result of code you have no control over. – Ucayali

Yes this is related to certain phones only, however I would like to find a work around to change this because the phones that have this will eventually have oom. – Usurer

Maybe this workaround might help you : https://mcmap.net/q/583708/-edittext-causing-memory-leak – Jubal

Answer 1

It is because EditText references the context of Activity. When the Activity is destroyed, Activity cannot be recycled normally because Edittext holds a reference to the context of activity. Solution: Rewrite EditText, change the reference to the Context in Activity to the reference to ApplicationContext.

Instructions:

https://programming.vip/docs/solve-the-memory-leak-problem-caused-by-edittext-in-android.html

Oringas

Answer 2

I was confused about this memory leak for a very long time. But recently I found two ways to fix this problem.

1. I found that if your TextView/EditText has the android:hint property, this cannot happen. So the easiest way is give every TextView/EditText the hint property.

2. The most forceful way is to reflect over TextLine and find the ChangeWatcher listener, then kill this listener.

Bode

Answer 3

I solved the problem by changing the activity context to application context.

Dreyer

Answer 4

Try to use Application Context instead of Activity Context in onCreateView() for this particular View (which contain any android:textIsSelectable="true" components).

// Singleton
class MyApplication extends Application {
    private static MyApplication mApp;

    @Override
    public void onCreate() {
        mApp = this;
    }

    public static MyApplication getApp() {
        return mApp;
    }
}

@Override
public View onCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState) {
    // Suggested inflater use Activity Context
    // So we must tu use Application Context
    Context context = MyApplication.getApp().getApplicationContext();
    LayoutInflater myLayoutInflater = LayoutInflater.from(context);

    View view = myLayoutInflater.inflate(R.layout.my_view, container, false);
    return view;
}

Portiaportico

Using app context instead of activity context to inflate views can lead to unwanted results if you use different default theme for your app and another theme for your activity. In that case use new ContextThemeWrapper(getApplicationContext(), R.style.your_activity_theme). I've had more issues (links in tex views not working or popup menus not opening with crashes) so this is generally a bad idea. – Vedic