Xavier Rubio Jansana

Xavier Rubio Jansana

Mobile engineer.
Android and iOS.
Scuba diver.

© 2024

Layout inflation and why AppCompat components replace standard ones

Some time ago I saw the following question in StackOverflow: Why does Android select AppCompat components when I don’t declare them explicitly?

I was debugging my App and found while hovering on an ImageView reference that, it is an AppCompatImageView instead of an ImageView. The same happened with a TextView (with AppCompatTextView).

So, why Android Views get “automagically” converted into AppCompat* equivalents? The answer comes from the fact that he is extending from AppCompatActivity instead of Activity or other alternatives (in fact, the original question also asks whether he should keep extending AppCompatActivity or start using Activity).

Short answer to “Should I just extend from an Activity from now on?” is no, you should keep extending AppCompatActivity as it provides backwards compatible features to older devices. In the case of AppCompatImageView:

A ImageView which supports compatible features on older versions of the platform, including:

  • Allows dynamic tint of its background via the background tint methods in ViewCompat.
  • Allows setting of the background tint using backgroundTint and backgroundTintMode.
  • Allows dynamic tint of its image via the image tint methods in ImageViewCompat.
  • Allows setting of the image tint using tint and tintMode.

Also, it adds compatibility with vector drawables for older Android versions.

So, how when the layout specifies ImageView, an AppCompatImageView gets created?

AppCompatActivity installs a LayoutInflater.Factory2 to intercept the inflation of certain views. The code of this inflater can be seen in AppCompatViewInflater.java (replaced with Android Code Search, now AndroidX version, code may be slightly different).

The function responsible for creating the Views is AppCompatViewInflater#createView(View, String, Context, AttributeSet, boolean, boolean, boolean, boolean), and as you can see here it checks for simple view names (without the package prefixing it), and creates the AppCompat* version instead:

public final View createView(View parent, final String name, @NonNull Context context,
        @NonNull AttributeSet attrs, boolean inheritContext,
        boolean readAndroidTheme, boolean readAppTheme, boolean wrapContext) {
    final Context originalContext = context;

    // ...

    View view = null;

    // We need to 'inject' our tint aware Views in place of the standard framework versions
    switch (name) {
        case "TextView":
            view = new AppCompatTextView(context, attrs);
        case "ImageView":
            view = new AppCompatImageView(context, attrs);
        case "Button":
            view = new AppCompatButton(context, attrs);
        case "EditText":
            view = new AppCompatEditText(context, attrs);
        case "Spinner":
            view = new AppCompatSpinner(context, attrs);
        case "ImageButton":
            view = new AppCompatImageButton(context, attrs);
        case "CheckBox":
            view = new AppCompatCheckBox(context, attrs);
        case "RadioButton":
            view = new AppCompatRadioButton(context, attrs);
        case "CheckedTextView":
            view = new AppCompatCheckedTextView(context, attrs);
        case "AutoCompleteTextView":
            view = new AppCompatAutoCompleteTextView(context, attrs);
        case "MultiAutoCompleteTextView":
            view = new AppCompatMultiAutoCompleteTextView(context, attrs);
        case "RatingBar":
            view = new AppCompatRatingBar(context, attrs);
        case "SeekBar":
            view = new AppCompatSeekBar(context, attrs);

    if (view == null && originalContext != context) {
        // If the original context does not equal our themed context, then we need to manually
        // inflate it using the name so that android:theme takes effect.
        view = createViewFromTag(context, name, attrs);

    // ...

    return view;

Forcing the usage of non-AppCompat views

So, in order to force the creation of a regular ImageView (no AppCompatImageView) while still using AppCompatActivity you need to specify the complete class name, for example:


For more information on how layout inflation works you can see the amazing talk “LayoutInflater: Friend or Foe?” by Chris Jenx, author of Calligraphy.