Note: With the release of Android 9.0 (API level 28) there is
a new version of the support library called
AndroidX which is part of Jetpack.
The AndroidX library
contains the existing support library and also includes the latest Jetpack components.
You can continue to use the support library.
Historical artifacts (those versioned 27 and earlier, and packaged as android.support.*) will
remain available on Google Maven. However, all new library development
will occur in the AndroidX library.
We recommend using the AndroidX libraries in all new projects. You should also consider
migrating existing projects to AndroidX as well.
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.
Originally a single binary library for apps, the Android Support Library has
evolved into a suite of libraries for app development. Many of these
libraries are now a strongly recommended, if not essential, part of app
development.
This document provides an overview of the support library to help you
understand its components and how to use it effectively in your app.
Caution: Starting with Support Library release 26.0.0
(July 2017), the minimum supported API level across most support libraries
has increased to Android 4.0 (API level 14) for most library packages. For
more information, see Version Support and Package
Names on this page.
Uses for the Support Libraries
There are a few distinct uses for the support libraries. Backward
compatibility classes for earlier versions of the platform is just one of
them. Here is a more complete list of ways you can use the support libraries
in your app:
-
Backward Compatibility for newer APIs - A large amount of the
support libraries provide backward compatibility for newer framework
classes and methods. For example, the
Fragment
support class provides support for fragments on devices running versions
earlier than Android 3.0 (API level 11).
-
Convenience and Helper Classes - The support libraries provides a
number of helper classes, particularly for user interface development. For
example the
RecyclerView class provides a user
interface widget for displaying and managing very long lists, useable on
versions of Android from API level 7 and up.
-
Debugging and Utilities - There are a number of features
that provide utility beyond code you incorporate into your app, including
the
support-annotations
library for improved code lint checks on method inputs and Multidex support for
configuring and distributing apps with over 65,536 methods.
Using Support versus Framework APIs
Support Libraries provide classes and methods that closely resemble APIs in
the Android Framework. Upon discovering this, you may wonder if you should
use the framework version of the API or the support library equivalent. Here
are the guidelines for when you should use support library classes in place
of Framework APIs:
-
Compatibility for a Specific Feature - If you want to support a
recent platform feature on devices that are running earlier versions of the
platform, use the equivalent classes and methods from the support library.
-
Compatibility for Related Library Features - More sophisticated
support library classes may depend on one or more additional support
library classes, so you should use support library classes for those
dependencies. For example, the
ViewPager
support class should be used with FragmentPagerAdapter or the FragmentStatePagerAdapter support classes.
-
General Device Compatibility - If you do not have a specific
platform feature you intend to use with your app in a backward compatible
way, it is still a good idea to use support library classes in your app.
For example, you may want to use
ActivityCompat in place of the framework Activity class, so you can take advantage of newer features
later on, such as incorporating the new permissions model introduced in
Android 6.0 (API level 23).
Support Library classes that provide a compatible implementation of platform
API classes may not be able to provide the full set of functionality
available in the latest release, due to the limitations of the host device
platform version. In these cases, Support Library classes are designed to
degrade gracefully, and may not provide the all the functionality or data of
the current, platform API. For this reason, you should review the reference
documentation for the library classes and methods you use, and thoroughly
test on devices running the earliest version of the platform supported by
your app.
Note: The support libraries do not provide equivalent
classes and methods for each framework API. In some cases, you may need to
wrap a framework method call with an explicit SDK version check and provide
alternative code to handle methods not available on a device. For more
information on using version checks in your code, see Supporting Different
Platform Versions.
Version Support and Package Names
Some of the Support Library packages have package names to indicate the
minimum level of the API they originally supported,
using a v# notation, such as the
support-v4 package. Starting with Support Library version 26.0.0 (released in
July 2017), the minimum supported API level has changed to Android 4.0 (API
level 14) for all support library packages. For this reason, when working with
any recent release of the support library, you should not assume that the
the v# package notation indicates a minimum API support level.
This change in recent releases also means that library packages with the v4
and v7 are essentially equivalent in the minimum level of API they support.
For example, the support-v4 and the support-v7 package both support a minimum
API level of 14, for releases of the Support Library from 26.0.0 and higher.
Support Library Release Versions
The
release version of the Support Library, such as 24.2.0 or 25.0.1, is
different from the minimum API level supported by any library in that
release.The release version number indicates which version of the platform
API it was built against, and therefore, what the most recent APIs may be
included in this version of the libraries.
Specifically, the first section of the release version number, for example
the 24 in version 24.2.0, generally corresponds with the version of the
platform API available when it was released. The release version level of the
support library indicates it incorporates some features of that API
level, but you should not assume it provides compatibility with all
features released in the new platform API version.
Library Dependencies
Most libraries in the Android Support Library suite have some dependency on
one or more libraries. For example, nearly all support libraries have a
dependency on the support-compat package. In general, you do not
need to worry about support library dependencies, because the gradle build
tool manages library dependencies for you, by automatically including
dependent libraries.
If you want to see what libraries and library dependencies are included in
your app, run the following command at the build root of your app development
project to get a report of the dependencies for that project, including
Android Support Libraries and other libraries:
gradle -q dependencies your-app-project:dependencies
For more information about adding support libraries to your development
project using Gradle, see Support
Library Setup. For more information about working with Gradle, see
Configure
Your Build.
Note that all Android Support Libraries also depend on some base level
of the platform, for recent releases, that is Android 4.0 (API level 14) or
higher.
Content and code samples on this page are subject to the licenses described in the Content License. Java and OpenJDK are trademarks or registered trademarks of Oracle and/or its affiliates.
Last updated 2024-05-20 UTC.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Missing the information I need","missingTheInformationINeed","thumb-down"],["Too complicated / too many steps","tooComplicatedTooManySteps","thumb-down"],["Out of date","outOfDate","thumb-down"],["Samples / code issue","samplesCodeIssue","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2024-05-20 UTC."],[],[],null,["# Support Library\n\n**Note:** With the release of Android 9.0 (API level 28) there is\na new version of the support library called\n[AndroidX](/jetpack/androidx) which is part of [Jetpack](/jetpack).\nThe AndroidX library\ncontains the existing support library and also includes the latest Jetpack components.\n\n\u003cbr /\u003e\n\n\nYou can continue to use the support library.\nHistorical artifacts (those versioned 27 and earlier, and packaged as `android.support.*`) will\nremain available on Google Maven. However, all new library development\nwill occur in the [AndroidX](/jetpack/androidx) library.\n\n\u003cbr /\u003e\n\n\nWe recommend using the AndroidX libraries in all new projects. You should also consider\n[migrating](/jetpack/androidx/migrate) existing projects to AndroidX as well.\n\n\nWhen developing apps that support multiple API versions, you may want a\nstandard way to provide newer features on earlier versions of Android or\ngracefully fall back to equivalent functionality. Rather than building code\nto handle earlier versions of the platform, you can leverage these libraries\nto provide that compatibility layer. In addition, the Support Libraries\nprovide additional convenience classes and features not available in the\nstandard Framework API for easier development and support across more\ndevices.\n\n\nOriginally a single binary library for apps, the Android Support Library has\nevolved into a suite of libraries for app development. Many of these\nlibraries are now a strongly recommended, if not essential, part of app\ndevelopment.\n\n\nThis document provides an overview of the support library to help you\nunderstand its components and how to use it effectively in your app.\n\n\n**Caution:** Starting with Support Library release 26.0.0\n(July 2017), the minimum supported API level across most support libraries\nhas increased to Android 4.0 (API level 14) for most library packages. For\nmore information, see [Version Support and Package\nNames](#api-versions) on this page.\n\nUses for the Support Libraries\n------------------------------\n\n\nThere are a few distinct uses for the support libraries. Backward\ncompatibility classes for earlier versions of the platform is just one of\nthem. Here is a more complete list of ways you can use the support libraries\nin your app:\n\n- **Backward Compatibility for newer APIs** - A large amount of the support libraries provide backward compatibility for newer framework classes and methods. For example, the [Fragment](/reference/androidx/fragment/app/Fragment) support class provides support for fragments on devices running versions earlier than Android 3.0 (API level 11).\n- **Convenience and Helper Classes** - The support libraries provides a number of helper classes, particularly for user interface development. For example the [RecyclerView](/reference/androidx/recyclerview/widget/RecyclerView) class provides a user interface widget for displaying and managing very long lists, useable on versions of Android from API level 7 and up.\n- **Debugging and Utilities** - There are a number of features that provide utility beyond code you incorporate into your app, including the [`support-annotations`](/studio/write/annotations) library for improved code lint checks on method inputs and [Multidex support](/studio/build/multidex) for configuring and distributing apps with over 65,536 methods.\n\nUsing Support versus Framework APIs\n-----------------------------------\n\n\nSupport Libraries provide classes and methods that closely resemble APIs in\nthe Android Framework. Upon discovering this, you may wonder if you should\nuse the framework version of the API or the support library equivalent. Here\nare the guidelines for when you should use support library classes in place\nof Framework APIs:\n\n- **Compatibility for a Specific Feature** - If you want to support a recent platform feature on devices that are running earlier versions of the platform, use the equivalent classes and methods from the support library.\n- **Compatibility for Related Library Features** - More sophisticated support library classes may depend on one or more additional support library classes, so you should use support library classes for those dependencies. For example, the [ViewPager](/reference/androidx/viewpager/widget/ViewPager) support class should be used with [FragmentPagerAdapter](/reference/androidx/fragment/app/FragmentPagerAdapter) or the [FragmentStatePagerAdapter](/reference/androidx/fragment/app/FragmentStatePagerAdapter) support classes.\n- **General Device Compatibility** - If you do not have a specific platform feature you intend to use with your app in a backward compatible way, it is still a good idea to use support library classes in your app. For example, you may want to use [ActivityCompat](/reference/androidx/core/app/ActivityCompat) in place of the framework [Activity](/reference/android/app/Activity) class, so you can take advantage of newer features later on, such as incorporating the new permissions model introduced in Android 6.0 (API level 23).\n\n\nSupport Library classes that provide a compatible implementation of platform\nAPI classes may not be able to provide the full set of functionality\navailable in the latest release, due to the limitations of the host device\nplatform version. In these cases, Support Library classes are designed to\ndegrade gracefully, and may not provide the all the functionality or data of\nthe current, platform API. For this reason, you should review the reference\ndocumentation for the library classes and methods you use, and thoroughly\ntest on devices running the earliest version of the platform supported by\nyour app.\n\n\n**Note:** The support libraries do not provide equivalent\nclasses and methods for each framework API. In some cases, you may need to\nwrap a framework method call with an explicit SDK version check and provide\nalternative code to handle methods not available on a device. For more\ninformation on using version checks in your code, see [Supporting Different\nPlatform Versions](/training/basics/supporting-devices/platforms).\n\nVersion Support and Package Names\n---------------------------------\n\n\nSome of the Support Library packages have package names to indicate the\nminimum level of the API they originally supported,\nusing a v# notation, such as the\nsupport-v4 package. Starting with Support Library version 26.0.0 (released in\nJuly 2017), the minimum supported API level has changed to Android 4.0 (API\nlevel 14) for all support library packages. For this reason, when working with\nany recent release of the support library, you should not assume that the\nthe *v#* package notation indicates a minimum API support level.\nThis change in recent releases also means that library packages with the v4\nand v7 are essentially equivalent in the minimum level of API they support.\nFor example, the support-v4 and the support-v7 package both support a minimum\nAPI level of 14, for releases of the Support Library from 26.0.0 and higher.\n\n### Support Library Release Versions\n\n\nThe [release version](/topic/libraries/support-library/revisions) of the Support Library, such as 24.2.0 or 25.0.1, is\ndifferent from the minimum API level supported by any library in that\nrelease.The release version number indicates which version of the platform\nAPI it was built against, and therefore, what the most recent APIs *may be\nincluded* in this version of the libraries.\n\n\nSpecifically, the first section of the release version number, for example\nthe 24 in version 24.2.0, generally corresponds with the version of the\nplatform API available when it was released. The release version level of the\nsupport library indicates it incorporates *some* features of that API\nlevel, but you should not assume it provides compatibility with *all*\nfeatures released in the new platform API version.\n\nLibrary Dependencies\n--------------------\n\n\nMost libraries in the Android Support Library suite have some dependency on\none or more libraries. For example, nearly all support libraries have a\ndependency on the `support-compat` package. In general, you do not\nneed to worry about support library dependencies, because the gradle build\ntool manages library dependencies for you, by automatically including\ndependent libraries.\n\n\nIf you want to see what libraries and library dependencies are included in\nyour app, run the following command at the build root of your app development\nproject to get a report of the dependencies for that project, including\nAndroid Support Libraries and other libraries: \n\n```\ngradle -q dependencies your-app-project:dependencies\n```\n\n\nFor more information about adding support libraries to your development\nproject using Gradle, see [Support\nLibrary Setup](/topic/libraries/support-library/setup). For more information about working with Gradle, see\n[Configure\nYour Build](/studio/build).\n\n\nNote that *all* Android Support Libraries also depend on some base level\nof the platform, for recent releases, that is Android 4.0 (API level 14) or\nhigher."]]
