Q:

Interesting thread behavior when Layout Inflater inflates EditText

When watching my app through the Device Manager I came across behaviour with the inflater that I was hoping someone in the stack overflow community could help me understand. I have a fragment that when It uses the layout inflater to inflate an EditText it spawns two Async Tasks. Why are these getting spawned and what can I do to prevent this or close them afterwards?
When I comment out the EditText, right after the fragment loads I see this:

After I put it back:

My fragment looks like:
public class SearchFragment implements View.OnClickListener{

    // the fragment initialization parameters, e.g. ARG_ITEM_NUMBER
    private static final String TAG = "HistorySearchFragment";

    private static final String ARG_SECTION_NUMBER = "sectionNumber";

    public static SearchFragment newInstance(int sectionNumber) {
        SearchFragment fragment = new SearchFragment();
        Bundle args = new Bundle();
        args.putInt(ARG_SECTION_NUMBER, sectionNumber);
        fragment.setArguments(args);
        return fragment;
    }

    @Override
    public View onCreateView(LayoutInflater inflater, ViewGroup container,
                         Bundle savedInstanceState) {

        super.onCreateView(inflater, container, savedInstanceState);
        View view = inflater.inflate(R.layout.fragment_search, container, false)

        return view;
    }
}

fragment_search.xml looks like
<RelativeLayout
    xmlns:android="http://schemas.android.com/apk/res/android"
    tools:context="com.main.SearchFragment"
    xmlns:tools="http://schemas.android.com/tools"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:padding="10dp">

<ScrollView
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:layout_above="@+id/search_button_bw"
    android:layout_below="@+id/space"
    android:isScrollContainer="false">
    <RelativeLayout
        android:layout_width="match_parent"
        android:layout_height="wrap_content">

/*************************************************
THIS TEXT BOX HERE
/************************************************/
    <EditText
        android:layout_width="wrap_content"
        android:layout_height="wrap_content" />

/*************************************************
To here
/************************************************/

    </RelativeLayout>
</ScrollView >

<Button
    android:id="@+id/search_button_bw"
    android:layout_width="match_parent"
    android:layout_height="70dp"
    android:text="Search"
    android:layout_alignParentBottom="true"
    android:layout_alignParentLeft="true"
    android:layout_alignParentStart="true" />

I have verified that this only happens when this fragment loads and the Tasks get spawned every time without fail. Does anyone have any idea why this is happening and how I can prevent it?

A:

Does anyone have any idea why this is happening

TextView has references to AsyncTask in its locale handling (at least in its Android 5.1 version; you would need to check for the specific version of Android that you are running).
AsyncTask will initialize a thread pool when the AsyncTask class is loaded as part of setting up the rest of the static data members. That pool has a minimum pool size of the number of CPU cores plus one. So, on an emulator or single-core hardware, two Thread objects will be created once something references the AsyncTask class. They will exist for the duration of your process. Note that on multi-core CPUs, I would expect more threads to be in this pool in the steady state, and there can be even more threads (up to double the number of cores, plus one) if a lot of tasks are active.

how I can prevent it?

Don't use TextView or anything that inherits from it. Also, do not use any other framework classes that reference AsyncTask. 
Since those threads are not running (as you can see from your screenshot), I fail to see what your issue is. If anything, we need more stuff in the framework using background threads, as there are some places where Android's framework code runs afoul of StrictMode threading checks.

what can I do to... close them afterwards?

They are closed, insofar as they are not running. As you see in your screenshot, they are blocked ("Wait"). They will remain in that state until something needs to run a task. This is how thread pools work.

