Difference Between Android-Support-V7-Appcompat and Android-Support-V4

Difference between android-support-v7-appcompat and android-support-v4

UPDATE

There are many changes done into support library since this question was answered. Good thing is, it is very well documented also. So you must read Support Library Documentation for more details and more available support library.

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.

---

Below is difference from Support Library Packages:

v4 Support Library

This library is designed to be used with Android 1.6 (API level 4) Android 2.3 (API level 9) Android 4.0 (API level 14) and higher. It includes the largest set of APIs compared to the other
libraries, including support for application components, user
interface features, accessibility, data handling, network
connectivity, and programming utilities.

v7 Libraries

There are several libraries designed to be used with Android 2.1 (API level 7) Android 2.3 (API level 9) Android 4.0 (API level 14) and higher. These libraries provide specific feature sets and
can be included in your application independently from each other.

v7 appcompat library

This library adds support for the Action Bar user interface design pattern.

Note:
This library depends on the v4 Support Library. If you are using Ant or Eclipse, make sure you include the v4 Support Library as part
of this library's classpath.

So yes you need both jars if you want to use v7.

---

Update for android-support-v13.jar

v13 Support Library

This interface was deprecated in API level 27.1.0. Use Fragment instead of the framework Fragment.

v13 Support Library

This library is designed to be used for Android 3.2 (API level 13) and higher. It adds support for the Fragment user interface pattern
with the (FragmentCompat) class and additional fragment support
classes

When you see the package details it has a class FragmentCompat as given in definition. So it has not the all classes of appcompat library.

Can you explain why support v4 and v7 on android

but i cant understand why they divided into v4 and v7 ?

They are not "divided into v4 and v7". They are divided along functional lines. There are many pieces of the Android Support package, such as:

compile 'com.android.support:appcompat-v7:21.0.0'
compile 'com.android.support:cardview-v7:21.0.0'
compile 'com.android.support:gridlayout-v7:21.0.0'
compile 'com.android.support:leanback-v17:21.0.0'
compile 'com.android.support:mediarouter-v7:21.0.0'
compile 'com.android.support:palette-v7:21.0.0'
compile 'com.android.support:recyclerview-v7:21.0.0'
compile 'com.android.support:support-annotations:21.0.0'
compile 'com.android.support:support-v13:21.0.0'
compile 'com.android.support:support-v4:21.0.0'

The only ones of these that are replacements for the other are support-v4 and support-v13. support-v13 contains everything that is in support-v4, plus a few additional classes that are only relevant for devices running API Level 13 or higher.

The -vNN notation in the artifact name is just to help remind you what Android API level the code in that library works back to.

Why just dont use one support library for all versions?

For the same reason that we do not compile in every line of code ever written in human history: we don't need it. appcompat-v7 is an independent library from leanback-v17, for example -- they are about as related as they are to one of my libraries.

Or even all classes on support, be on SDK properly?

In some cases, it it because we have not invented a time machine yet, and so we cannot "retcon" older versions of Android to have different classes and methods. For example, part of the reason why appcompat-v7 exists is to allow the action bar pattern to be used on devices going back to API Level 7; the native action bar only showed up at API Level 11.

There is also pressure from manufacturers to keep the size of the OS down, particularly framework classes, to reduce the amount of RAM and flash storage needed to build an Android device. Hence, some things (e.g., leanback-v17, for Android TV-style experiences) are not part of the OS as they are not needed everywhere.

Also, by having things in libraries, your app is more independent of the underlying device. For example, some developers will use the backport of fragments in support-v4 or support-v13, not because they want to run on devices older than API Level 11 (when native fragments were introduced), but because they want an implementation of fragments that works the same across all Android versions. The native fragments implementation will vary by Android OS version.

Difference between appcompat_v7 and android-support-v7-appcompat?

android-support-v7-appcompat.jar is a JAR file, containing only compiled Java classes. appcompat_v7 is a Library Project, which contains the previous JAR file, no actual source code, and a great many resources (layouts, images, &c).

In the particular case of appcompat-v7, you need to use the Library Project, since it contains necessary UI resources.

Other libraries (such as v7 MediaRouter or v7 Palette) do not contain these resources, and therefore the JAR file can be used directly.

Note that the difference applies mainly to Eclipse (in which libraries with resources must be imported as a project while the others can be just placed in the libs folder). With Android Studio/gradle this is all handled by the build system and therefore the procedure is the same for both. This is well explained in the Support Library Setup documentation.

If I use new V7 Appcompat library , do I still need V4 Support Library for a minimum SDK = 7?

v7 includes the v4 support library so there is no need to have it in there again

if you look in the libs folder of the v7 support library you will see that the v4 jar is already referenced in the library

What replaced appcompat-v7 in AndroidX

Use in the order:

implementation 'androidx.appcompat:appcompat:1.0.2'   
implementation 'com.google.android.material:material:1.0.0'
implementation 'androidx.cardview:cardview:1.0.0'

If you would like to use alpha/beta releases:

implementation 'androidx.appcompat:appcompat:1.1.0-rc01'
implementation 'com.google.android.material:material:1.1.0-alpha09'

More info about the releases:

• AndroidX Releases
• Material Components library

Difference between androidx and com.android.support

All the support libraries are dropping the v4 v7 v12 v13 etc tags and everything is refactored into the androidx packages.

They are essentially the same but for future reference androidx will be the library that we should use in our apps.

Android studio 3.2 canary that comes out this week (week of May 14, 2018) should have the tool that allows automatic refactoring to the androidx packages. There was an announcement about this at google i/o 2018.

---

Related Topics