Develop Reference

Writing an Android library: use AppCompat?

When writing an Android library, should I use the AppCompat or Support variants provided by the support library?
For example, should a method take an Activity or an AppCompatActivity? support.v4.Fragment or android.app.Fragment?

In general you should use the AppCompat libraries wherever possible. The library provides backporting for some new features (whatever is practical), and fixes bugs in various version specific versions. For Activities and Fragments its particularly important, as Fragments at least had major differences between versions.

AppCompatActivity is the base class that support Support library ActionBar while Activity is actually the parent of AppCompatActivity. Depending on your purpose of library, if you have no intention of using the Support library ActionBar / Fragment related feature in your library, I would say, in general, the activity class is sufficient for your library.
android.app.Fragment has been deprecated now with API 28. So just go for the support Fragment version.

What should my activity extend when application's minSdkVersion is 21?

I am quite new to Android and Android Studio. I have created a new project and I have specified the minSdkVersion as 21 and target to 23.
After AS is done with creating the activity I see that MainActivity is extending AppCompatActivity by default.
I read about AppCompatActivity here
It says that it is the Base class for activities that use the support library action bar features.
Now my question is:
Since my app's minSdkVersion is 21 why do I need my activity to extend AppCompatActivity?
Why does AS make my activity extend AppCompatActivity by default?
Is it necessary for my activity to extend AppCompatActivity or just extending Activity is enough considering my minSdkVerion?
What would I miss if my actvity don't extend AppCompatActivity?
Any explanation would be very helpful. Thanks

I think you should extend AppCompatActivity if you are using action bar
Read more here
Beginning with Android 3.0 (API level 11), all activities that use the default theme have an ActionBar as an app bar. However, app bar features have gradually been added to the native ActionBar over various Android releases. As a result, the native ActionBar behaves differently depending on what version of the Android system a device may be using. By contrast, the most recent features are added to the support library's version of Toolbar, and they are available on any device that can use the support library.
For this reason, you should use the support library's Toolbar class to implement your activities' app bars. Using the support library's toolbar helps ensure that your app will have consistent behavior across the widest range of devices. For example, the Toolbar widget provides a material design experience on devices running Android 2.1 (API level 7) or later, but the native action bar doesn't support material design unless the device is running Android 5.0 (API level 21) or later.

AppCompatActivity gives you the additional functionality of ActionBar after api level 7.
Activity helps you avoid extra libraries but doesnt provide actiobBar feature.
Prior to revision 22.1.0 the Action bar was provided by extending ActionBarActivity which is deprecated now

Well, as you said, indeed it is. We don't have to extends AppCompatActivity. But a lot of open source libs using AppCompatActivity to grab the feature to lower API level projects, and the third part libs are going to ask your MainActivity to extends AppCompatActivity. So, either you can implement your own lib or extends AppCompatActivity.

AppCompatActivity is a part of support library, so you also have the benefit of using support library. In short, your activity which extended AppCompatActivity will have the capability of the Activity in the recent API (but as long as the implementation of the capability is builded in the support library).
You can read the following from documentation:
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 a 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).

android: getFragmentManger and getSupportFragmentManger

from some of the answer such as
Using getFragmentManager() vs getSupportFragmentManager()?
I find that getFragmentManager() is used for API>=14,
and getSupportFragmentManager() will be used in support lib such as v4 which also support older API.
So my question is should I just use getSupportFragmentManager (import the support.v4 for each classes) so that my application can be used in any API version?
And are there any different I should know between these 2 FragmentManager?

If you are interested in supporting API versions that do not have Fragments, then by all means use the FragmentActivity and getSupportFragmentManager() patterns.
Even if you are not targeting an API below 14, it may be a good idea to use the support library. Classes in the support library can be updated by you, the developer, whenever Google releases a bugfix/feature in the library that you are interested in. If you use a framework class, you only get the updates when your users get a firmware update, which we all know can take a while. Using the support library means all users are using the same "latest-and-greatest" classes.

Yes, for Fragment, just use getSupportFragmentManager, then your app for Fragment can be compatible backward to old API levels, normally minSDKversion = 7 is enough. However if you really want your app to get compitability with most API levels, then there still many other components your app concerning need use support library, such as ActionBar, etc..
For more info, please go through Android Docs: Support Library Features

Which fragment library should I import?

I am implementing fragments with a DrawerLayout. I have 2 options when I import Fragments
android.support.v4.app
android.app
Which one should I use ? I dont see any difference except it seems like the android.support.v4.app has no support for objectAnimator.
What do you suggest ?
Edit: I only plan on supporting API level 14 and higher...

It depends on whether you are using Support Library.
If you are using fragments below api level 11 then use android.support.v4.app. In this case you will extend FragmentActivity which is the base class of support based fragments.
If you are using fragments in api level 11 and above use android.app. In this case you will extend standard Activity.
Take a look at the below link and decide on what versions your app should run. Depending on that decide whether you need support library or not.
https://developer.android.com/about/dashboards/index.html
I only plan on supporting API level 14 and higher...
Then there is no need to use support library. Use
import android.app.Fragment
and extend standard Activity.

If you are using support libary for drawerlayout then you should use android.support.v4.app for fragments.

You can use open-source "AndroidX" Support Library nowadays.
You can start from here AndroidX

not able to use calls in Fragment ever thought i import the corresponding library

SO here is my understanding of the purpose of importing fragment library(the v4.jar).
Because the developer wants to use and follow the new Fragment's way of coding, but using this will result compatibility issue on older devices that runs on android 2.xx, therefore, in the project that uses fragment, the developer has to import the v4.jar library so that the older devices know what fragment APIs and are able to call them in the app.
If this is correct, I suppose after importing the library, the android:minSdkVersion should be able to set to older version such as 8 (93% of the market), not l0, because the project had already import the library.
But When I am using the method from the fragment, for example, the instantiate method, I got this error:
Call requires API level 11 (current min is 8): android.app.Fragment#instantiate
So apparent the sdk wants me to switch my android:minSdkVersion to 11, but then what is the purpose of importing the library? And by doing so older device that running on android 2.xx will not be able to use this app.
Can someone explain this issue ?

It sounds like you're importing the wrong Fragment library.
This one requires API level 11 (Android 3.0):
http://developer.android.com/reference/android/app/Fragment.html
This one, as available in the support library, requires API level 4 (Android 1.6):
http://developer.android.com/reference/android/support/v4/app/Fragment.html
Also, you should be aware that you need to use the FragmentManager available in the support library.
There are no drawbacks to using the support Fragment APIs on Android 3.0+.