The following is the first few sections of a chapter from The Busy Coder's Guide to Android Development, plus headings for the remaining major sections, to give you an idea about the content of the chapter.

AppCompat: The Official Action Bar Backport

Approximately 30 months after Google added the action bar to Android 3.0, Google released a backport for previous devices. Referred to here as AppCompat or, appcompat-v7 (after its library name), this adds action bar support to Android apps, going all the way back to API Level 7.

The appcompat-v7 Android Support Package artifact houses AppCompat. Version 21 and higher of this artifact change the way that AppCompat looks, to try to not only backport the action bar, but to backport a bit of the Material Design aesthetic.

This chapter will outline why you might want to use AppCompat and how to employ it in your Android applications.


Understanding this chapter requires that you have read the core chapters, particularly the one on the action bar.

Ummmm… Why?

You might wonder why we would bother with any of it. AppCompat is not required, and apps can work fine without it. And, in truth, most apps will be just fine using the native action bar implementation.

That being said, you may find some pressures nudging you towards using an action bar backport, and AppCompat specifically.

Why an Action Bar Backport?

If your minSdkVersion is 11 or higher, you have an action bar on all Android versions that your app supports.

If, however, your minSdkVersion is below 11, by default you will get the old-style options menu on Android 1.x/2.x devices. That is not a crime. However, the action bar design pattern had been used in various Android apps prior to Android 3.0’s formalization of the pattern. Many apps that users will see on older devices will have an action bar, courtesy of one of the backports. By adopting a backport, you will gain a measure of consistency in your UX across Android versions that you would otherwise miss by falling back to the options menu.

You might also adopt a backport because something else is steering you to use AppCompat, and therefore you elect to use it for those reasons.

Why AppCompat?

AppCompat is a somewhat controversial library nowadays. It did not start that way when it was released in the Summer of 2013. But Google has been rather aggressive about trying to get developers to use AppCompat, and that aggressiveness has had its downsides.


The #1 reason for using AppCompat is because you decided, for other reasons, that you wanted an action bar backport, and AppCompat right now is the primary supported option.

The original backport, ActionBarSherlock, was officially deprecated by its author (Jake Wharton), who is steering you towards the native action bar or AppCompat as alternatives. While this does not prevent you from using ActionBarSherlock, it is probably not a great choice today given that Google is supporting AppCompat.


The current version of AppCompat does not only give you an action bar. It gives you an action bar that looks like the one that you get from Theme.Material. It also will attempt to apply your accent color to select widgets, the way Android 5.0 and Theme.Material do, to make your app abide a bit more by the Material Design aesthetic.

Whether or not this is a good thing is up to you.


One hidden advantage of using AppCompat, particularly in concert with the fragments backport, is consistency across Android versions. By using the native action bar and fragments, you are at some risk of inconsistent behavior based upon:

Having your action bar and fragments be in a library in your app isolates you from those changes. AppCompat always uses its own implementation, so any changes in the native implementation will not affect your app.

This comes at a cost of additional complexity and APK size.


Some things in the Android development ecosystem, like official support for the MediaRouteActionProvider, only work with the AppCompat action bar, as Google has either not shipped or has deprecated their native alternatives.

You may find some “cross-ports” of those things that work with the native action bar, but those are unlikely to be as well-supported as Google’s own editions.

Also, new projects created via Android Studio basically shove appcompat-v7 down your throat. This is why this book’s tutorials have you start by importing an existing project, so you do not have to rip appcompat-v7 and its references out by the roots to start a new project.

While it is theoretically possible that Google itself will eventually offer native action bar implementations of those things, it is unlikely. Hence, if you determine that you need one of those, you may be more inclined to use AppCompat, even if you do not need it for any other reason.

The Basics of Using AppCompat

The preview of this section is unavailable right now, but if you leave your name and number at the sound of the tone, it might get back to you (BEEEEEEEEEEEEP!).

Other AppCompat Effects

The preview of this section will not appear here for a while, due to a time machine mishap.

Toolbar and AppCompat

The preview of this section is in an invisible, microscopic font.

To Material, or Not to Material

The preview of this section was abducted by space aliens.