How Do The Android Support Libraries Work

How do the Android Support Libraries work?

As far as I understood, support libraries may work as alternative of built-in APIs, but they are not supposed to be, because they directly effect the size of the application.

For example, a support library is of 2MB, and to use its functionality, it takes all classes, resources, etc (of 2MB), so now classes.dex (Dalvik executable file of all classes being used in application) of my application also include that support library classes, and same for resources. So, if without support library my app size was 1MB, then now with support library the size is 2MB extra, which means 3MB total.

Now, suppose this support library feature is so common that on single device, if I have 10 apps, then at least 9 are using this same support library, so 9*2 = 18MB on my device is being used by the same support library, which is repeated in every application, which is bad, because for now 18MB might not be so much, but the space required can increase, if you have more applications using that support library.

Thus, the best option is to have that 2MB support library already in your OS for any number of apps, instead of having it for each application. So, support libraries are meant to be used when you really want some efficient features in your app to support older versions.

Another question arise here:

why not this support library is added to the OS as its own update, so that every app without size problems can access that functionality?

The answer is that there could be a lot of errors. Suppose some user doesn't have that update (support library) installed...

There is also the chance that as an update, it may not work as efficient as supposed to be, or may cause problems while integrating with the OS, as we already seen that each OS (windows, Linux, mac) comes with new versions, instead of just giving updates for life time for all new features.

What is an Android Support Library?

From the description of the support library:

The Support Package includes static "support libraries" that you can
add to your Android application in order to use APIs that are either
not available for older platform versions or that offer "utility" APIs
that aren't a part of the framework APIs. The goal is to simplify your
development by offering more APIs that you can bundle with your
application so you can worry less about platform versions.

Off course you have to use only the lower SDK available functions.
You should also look the Google Support Library thats make available some new functions for older SDK.
http://developer.android.com/tools/extras/support-library.html

When to use support library

Here is your answer—Always!

The following reasoning is copied straight from Big Nerd Ranch's Android Dev book. Emphasis mine:

This book uses the support library implementation of fragments over the implementation built into the Android OS, which may seem like an unusual choice. After all, the support library implementation of fragments was initially created so that developers could use fragments on old versions of Android that do not support the API. Today, most developers can exclusively work with versions of Android that do include support for fragments.
We still prefer support fragments. Why? Support fragments are superior because you can update the version of the support library in your application and ship a new version of your app at any time. New releases of the support library come out multiple times a year. When a new feature is added to the fragment API, that feature is also added to the support library fragment API along with any available bug fixes. To use this new goodness, just update the version of the support library in your application.
As an example, official support for fragment nesting (hosting a fragment in a fragment) was added in Android 4.2. If you are using the Android OS implementation of fragments and supporting Android 4.0 and newer, you cannot use this API on all devices that your app supports. If you are using the support library, you can update the version of the library in your app and nest fragments until you run out of memory on the device.
There are no significant downsides to using the support library’s fragments. The implementation of fragments is nearly identical in the support library as it is in the OS. The only real downside is that you have to include the support library in your project and it has a nonzero size. However, it is currently under a megabyte – and you will likely use the support library for some of its other features as well.
We take a practical approach in this book and in our own application development. The support library is king.

So... There will always be a support library because you will almost always have to support older devices for a variety of reasons:

Device owners may not be able to update to the latest version because:

Service providers and manufacturers are not bothered about updating a non-flagship type phone - costs money to regression test their bloatware on top of a new version of Android.
Some device owners (thankfully not all!) care very little about the Android version on their phone. Totally different situation with the Tinder app though.
Device owners may not have the resources to upgrade to a latest/newer device. App developers in developing countries probably face this issue. Google's Platform Versions statistics are not region specific, even though they probably should be!

Anyway, here is the gist: support libraries have the exact same functionality as OS/framework APIs and they have a compact size—since they have to be included in your APK, they don't increase the size very much. So we have established that there is no downside to using/including them. Now, the upsides are tremendous - look at the Fragment example above.

Is the support library provided in the android API the only means to include the newer android version features on older devices?

Talking about the two picture-in-picture (PIP) and notifications channel references you have given
Those are introduced in Android O and supposed to use from to above API level and won't support and unfortunately, there are no support libraries for this feature.
And for notifications you don't need channels it's another feature that Android has in API 26 otherwise your notifications may be dropped by the system to avoid we use notifications channel otherwise for the back support we don't need such requirement.

But other features supported are available as Android Support Library

Here is full list of API and features introduced in Android O

How does Android support library work with target SDK level?

However, does the newest SDK version (Lollipop, for example) use these support libraries as well, or does it use native elements?

The Android framework does not use the support libraries.

if I run the app on a Lollipop device, will it use native or support elements?

If I am interpreting what you mean by "native", it uses native element. The Android framework does not use the support libraries.

I can't, for example, chose to create one file for ICS, and other for Lollipop

You are certainly welcome to detect the running API level and elect to instantiate some level-specific class. You will see this used occasionally in the framework, though it is much more common in the Android support package, particularly for ...Compat classes.

so how does the system know which elements to use?

There is only one version of Android per Android device. Hence, there is only one set of framework "elements" for the framework to use.

Some aspects of the look of the widgets are driven by themes, and each Android version ships with support for whatever stock themes existed, going back to Theme from API Level 1. If the developer has chosen to use a different theme based upon running API level (e.g., use Theme.Material as a base on Android 5.0+ but use Theme.Holo as a base on Android 4.0-4.4), that is driven by resource set qualifiers (e.g., res/values-v21/styles.xml).

Can I use library that uses Androidx with support library project?

Using support libraries is not a recommended practice anymore, and you should migrate to androidx as soon as possible. Migration is easy, and Android Studio takes care of the heavy lifting for you.

What is AndroidX?

AndroidX - Android Extension Library

From AndroidX documentation

We are rolling out a new package structure to make it clearer which
packages are bundled with the Android operating system, and which are
packaged with your app's APK. Going forward, the android.* package
hierarchy will be reserved for Android packages that ship with the
operating system. Other packages will be issued in the new androidx.*
package hierarchy as part of the AndroidX library.

Need of AndroidX

AndroidX is a redesigned library to make package names more clear. So from now on android hierarchy will be for only android default classes, which comes with android operating system and other library/dependencies will be part of androidx (makes more sense). So from now on all the new development will be updated in androidx.

com.android.support.** : androidx.

com.android.support:appcompat-v7 : androidx.appcompat:appcompat
com.android.support:recyclerview-v7 : androidx.recyclerview:recyclerview
com.android.support:design : com.google.android.material:material

Complete Artifact mappings for AndroidX packages

AndroidX uses Semantic-version

Previously, support library used the SDK version but AndroidX uses the Semantic-version. It’s going to re-version from 28.0.0 → 1.0.0.

How to migrate current project

In Android Studio 3.2 (September 2018), there is a direct option to migrate existing project to AndroidX. This refactor all packages automatically.

Before you migrate, it is strongly recommended to backup your project.

Existing project

Android Studio > Refactor Menu > Migrate to AndroidX...
It will analyze and will open Refractor window in bottom. Accept changes to be done.

New project

Put these flags in your gradle.properties

android.enableJetifier=true
android.useAndroidX=true

Check @Library mappings for equal AndroidX package.

Check @Official page of Migrate to AndroidX

What is Jetifier?

Bugs of migrating

If you build app, and find some errors after migrating, then you need to fix those minor errors. You will not get stuck there, because that can be easily fixed.
3rd party libraries are not converted to AndroidX in directory, but they get converted at run time by Jetifier, so don't worry about compile time errors, your app will run perfectly.

Support 28.0.0 is last release?

From Android Support Revision 28.0.0

This will be the last feature release under the android.support
packaging, and developers are encouraged to migrate to AndroidX 1.0.0

So go with AndroidX, because Android will update only androidx package from now.

How Do The Android Support Libraries Work