Use legacy android support libraries что это
Support Library
In this document
See also
The Android Support Library package is a set of code libraries that provide backward-compatible versions of Android framework APIs as well as features that are only available through the library APIs. Each Support Library is backward-compatible to a specific Android API level. This design means that your applications can use the libraries’ features and still be compatible with devices running Android 1.6 (API level 4) and up.
This guide provides information about what features are enabled by the Support Libraries, how to use them in your development environment and information about library releases.
Overview
Including the Support Libraries in your Android project is considered a best practice for application developers, depending on the range of platform versions your app is targeting and the APIs that it uses. Using the features the libraries provide can help you improve the look of your application, increase performance and broaden the reach of your application to more users. If you use the Android code template tools, you will notice that all the Android application templates include one or more of the Support Libraries by default.
The Support Libraries each target a base Android API level and each provides a different set of features. In order to effectively use the libraries, it is important to consider what features you want to support and understand what features are supported by each library at what Android API level. To get started, review the Support Library Features guide. After that, go to the Support Library Setup topic to learn how to incorporate the Support Libraries into your application. For more details about Support Library APIs, see the android.support packages in the API reference.
Revisions
This section provides details about the Support Library package releases.
Added a new mediarouter library that provides support for the Google Cast developer preview. The v7 mediarouter library APIs provide a means of controlling the routing of media channels and streams from the current device to external screens, speakers, and other destination devices, with compatibility back to Android 2.1 (API level 7). See V7 mediarouter library for more information.
The v7 mediarouter library APIs introduced in Support Library r18 are subject to change in later revisions of the Support Library. At this time, we recommend using the library only in connection with the Google Cast developer preview.
These are exactly the same as the APIs added to the v4 support library, but rely on other platform components in Android 3.2. Use this library instead of v4 if you’re developing for Android 3.2 and higher (all other APIs in the v4 library are already available with API level 13).
Understanding the Android Support Library
by Josh Hight June 2, 2015
Without help from the Android team, developers would be forced to make some pretty ugly compromises in order to support most of their users. Fortunately, the Android team recognized that accommodating older devices and releases was strategically important. However, doing this in a way that doesn’t hamstring future releases presents an architectural challenge because the Android APIs obviously need to evolve over time. How can important new APIs be made available to the majority of Android users and not just those with newer devices lucky enough to run the latest releases?
The answer is one of the most important and peculiar design decisions made by the Android team: the Android Support Library.
What is the Android Support Library?
The Android Support Library is not actually a single library, but rather a collection of libraries that can roughly be divided into two groups: compatibility and component libraries.
Each library uses a naming convention that identifies the minSdkVersion your project must have in order to use it. This can be a little confusing, because it seems natural to think that support libraries with higher version numbers include the features from previous libraries (you might think v7-appcompat improves upon and includes all features from v4). In most cases, this is incorrect. To add to this confusion, libraries themselves have a revision number. For example, “AppCompat v21” actually refers to support library v7-appcompat, revision 21.
Compatibility Libraries
Compatibility libraries focus on back porting features from newer framework releases so that devices running previous releases can take advantage of the newer APIs. The major compatibility libraries are v4 and v7-appcompat.
Large and monolithic, the v4 library is the granddaddy of them all. It includes many features and, as its name suggests, supports back to API 4. In addition to support implementations for major classes like Fragment and Loader (which were both introduced in the framework in API 11), you’ll also find several widely-used classes not present in the framework at all, such as ViewPager and DrawerLayout.
Don’t let its name fool you: despite supporting all the way back to Android 1.6, this remains a very widely used and important library. And because of support library dependencies, it’s often hard to avoid the use of v4 entirely.
v7-appcompat
Often simply referred to as AppCompat, the v7-appcompat library provides support implementations for ActionBar (introduced in API 11) and Toolbar (introduced in API 21) for releases back to API 7. It requires the v4 library but does not include it. Thus, any feature dependent upon v7-appcompat is also dependent upon v4.
Under the Hood
The compatibility libraries largely use shims to back port features. These compatibility shims are thin wrappers around components that pass calls through to the underlying framework implementation if used on a release that supports the API. On older releases, the shims instead call the support implementation, perhaps with slightly different or reduced functionality.
However, in some cases a compatibility shim is not used. Instead, in these cases the support library always uses its own implementation in place of the framework implementation — even when the release supports the framework implementation. One major example of this is v4 support Fragments.
This is a very interesting decision, one that ripples across the entire Android framework. Android has created an entirely different support implementation of these major features, duplicating a lot of functionality, and packaging it as a different set of classes and resources. These support implementations live in parallel to their framework cousins, complete with their own inheritance hierarchy, revisions, and bugs.
Google claims that in these cases most of the APIs are the same, except that they belong to a different package and have minor differences in a few method names and signatures. However, in practice, there are some inconsistent and not so insignificant API differences between support and framework implementations – differences that will likely grow over time.
Furthermore, in some cases, developers may think they have the choice between framework and support implementations of a particular feature, only to find out that support dependencies dictate that decision for them. For example, the v7-appcompat library enables developers to use Material Design UI features introduced in API 21. However, doing so requires that all activities extend from AppCompatActivity, which extends from the v4 support FragmentActivity. So, developers targeting anything less than API 21 and wishing to use Material Design UI features are forced to use v4 support Fragments, rather than framework Fragments.
Google considers use of the support libraries a best practice, even if not necessarily required. It includes v7-appcompat and v4 libraries in most of its sample code as well as in Android Studio’s new project templates. Google is clearly investing significant effort in these compatibility libraries and expects developers to heavily rely upon them.
Component Libraries
In addition to compatibility libraries, the Android Support Library also provides smaller, more modular component libraries that enable developers to add features that are otherwise not part of the standard framework. These self-contained libraries can be easily added or removed from a project without concern for dependencies. There are several valuable component libraries to consider:
Adding any of these components to your gradle-based project is as simple as adding a dependency to your build script.
Beyond the benefits of convenience and modularity, separating these components into their own libraries allows Google to release important APIs outside of the framework. This allows feedback to be gathered and design iterated before possibly being finalized into the framework, where breaking changes would be much more difficult make.
Other Libraries
The Android Support Library also contains a few other libraries that are used less often, but still worth mentioning:
Common Questions
When should I use the Android Support Library?
You should use one of the support libraries when you need specific framework features that are newer than the minSdkVersion of your app or that are not available in the standard framework.
However, Google considers the general use of the support libraries to be a best practice, even if not necessarily required.
Which version of the Android Support Library should I use?
In short, use the version your application can support that has the features you need. Some features are modular. For example, to use RecyclerView, simply add the v7-recyclerview dependency identifier to your gradle build script.
If you need one of the compatibility components from v4, you can use v13 instead if your minSdkVersion supports that, since it bundles v4. Otherwise, if you need to support API versions
When you develop an app on a latest version of android like 5.x and you also want it to run on those devices which are running older versions of android like 3.2 e.t.c. you can’t do that until you add backward compatibility to your code.
To provide this backward compatibility android provides you the Android Support Library package. The Android Support Library package is a set of code libraries that provide backward-compatible versions of Android framework APIs as well as features that are only available through the library APIs. Each Support Library is backward-compatible to a specific Android API level.
Including the Support Libraries in your Android project is considered a best practice for application developers, depending on the range of platform versions your app is targeting and the APIs that it uses.
Support Library Features
The Android Support Library package contains several libraries that can be included in your application. Each of these libraries supports a specific range of Android platform versions and set of features.
In order to effectively use the libraries, it is important to consider that which API level you want to target as each library supports different API level.
Following is a brief description of android support libraries and API level they support.
