Burak Dede's Blog

Android Support Library Confusion

Lets start with offical definition of the support library

When developing apps that support multiple API versions, you may want a standard way to provide newer features on earlier versions of Android or gracefully fall back to equivalent functionality. Rather than building code to handle earlier versions of the platform, you can leverage these libraries to provide that compatibility layer. In addition, the Support Libraries provide additional convenience classes and features not available in the standard Framework API for easier development and support across more devices.

What are the main benefits of using support libraries?

  • Backward Compatibility for newer API
  • Convenience Helper Classes
  • Debugging, Testing, and Utilities

Support library topic may be one of the most confusing parts of the Android development and whole SDK. I remember after Fragments introduced with API Level 11 (which if I remember correctly Honeycomb) they introduced a `support library to provide backward functionality for platforms earlier than Honeycomb. It was just a single library and you add your dependency to get Fragments functionality. As new versions launched this support library than grew into a massive library of code.

When feature does not exist on older version you have couple of options

  • Write your own support, really?
  • Runtime build check & prevention (that is just sweeping under carpet)
  • Offical support library

Offical support library is the safest option of all. The advantages would be there are people working on this full time so future updates, thoroughly tested so less buggy than your custom support library and come with helper classes as an extra.

Yes, support library thing seems confusing because it really is…

After support library got really big they divide it into a couple of versioned libraries.

  • support-v4
  • appcompat-v7
  • recyclerview-v7…..

v# scheme means that it will support all the way back to 4 or 7 API Level. But that would not be the case for all functionality. Offical doc

These are the most known ones but there are more. Check revision page for a list of changes and other ones.

When people say support library they are meaning support-v4 as the support library.

dependency support library

This is getting confusing especially using Fragments inside application. Normally you extend your activity from Activity class, if you support Fragments you would use FragmentActivity (this is not necessary if you are using native fragments instead of support one). This is all great, support-v4 library already have android.support.v4.app.Fragment and android.support.v4.app.FragmentActivity classes but the latest version of the Android Studio include appcompat-v7 as support library instead of support-v4 and most of the activity classes extend from AppCompatAcitivty.

support diagram

Some support libraries also include classes from other support libraries or directly depend on them. AppCompatAcitivity which comes with appcompat-v7 and extend from FragmentActivity from support-v4 so you get both of them if you just use AppCompatActivity. Above image explains it all better.

If you are going to support Fragments without AppCompat library you would need extra support-v4 library but if not appcompat-v7 already had it.

powered by TinyLetter