Develop Reference

When to use PreferenceFragment and PreferenceFragmentCompat?

I am just a beginner but i have some questions regarding the support library.
Every time google team add's a new Support version it deprecated the use in new Version, so because of this we have to redo the code again just to support new API level.Can't it be like this , you can have this library but you will be not getting extra features .Instead of just deprecating the entire work ? Because of this there is a lot of extra work to do while making android app.
Why was PreferenceFragment deprecated in Android P and what are the support versions for both libraries PreferenceFragment and PreferenceFragmentCompat also what addition features to do you get?
Android platform is amazing but it's difficult to understand this things . If a developer has made an app what is the guaranty it will work when android releases new version ? With every release something is deprecated either the feature or the whole library.

Every time google team add's a new Support version it deprecated the use in new Version, so because of this we have to redo the code again just to support new API level.
That is not the case. "Deprecated" in Android usually means "we have something that we would prefer that you use". So, while eventually you should try to move off of deprecated APIs, "eventually" could be on the order of a couple of years.
Why was PreferenceFragment deprecated in Android P
The native android.preference.PreferenceFragment was deprecated in Android 9.0, mostly because it inherits from android.app.Fragment, which was deprecated in Android 9.0. The fragment code has had lots of bugs over the years. Google is trying to steer developers towards using a library-supplied fragment implementation, as the libraries can be kept up to date, while older Android devices (unfortunately) do not get updates.
There is nothing stopping you from using android.preference.PreferenceFragment in Android 9.0 if you wish. Ideally, over time, you stop using it, but you do not need to drop everything and change your code tomorrow.
what are the support versions for both libraries PreferenceFragment and PreferenceFragmentCompat
AFAIK android.support.v14.preference.PreferenceFragment should also be marked as deprecated, as it too inherits from android.app.Fragment.
android.support.v7.preference.PreferenceFragmentCompat extends from android.support.v4.app.Fragment, and so AFAIK this is the one that you should be using in the short term.
The whole preference fragment stuff is a bit of a mess at the moment — I am hoping that Google settles this out and provides clearer instructions as part of the migration to androidx over the next few months.

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).

Activity, AppCompatActivity, FragmentActivity, and ActionBarActivity: When to Use Which?

I'm coming from iOS where it's easy and you simply use a UIViewController. However, in Android things seem much more complicated, with certain UIComponents for specific API Levels. I'm reading BigNerdRanch for Android (the book is roughly 2 years old) and they suggest I use Activity to host my FragmentActivities. However, I thought Activity was deprecated.
So for API Level 22 (with a minimum support for API Level 15 or 16), what exactly should I use both to host the components, and for the components themselves? Are there uses for all of these, or should I be using one or two almost exclusively?

I thought Activity was deprecated
No.
So for API Level 22 (with a minimum support for API Level 15 or 16), what exactly should I use both to host the components, and for the components themselves? Are there uses for all of these, or should I be using one or two almost exclusively?
Activity is the baseline. Every activity inherits from Activity, directly or indirectly.
FragmentActivity is for use with the backport of fragments found in the support-v4 and support-v13 libraries. The native implementation of fragments was added in API Level 11, which is lower than your proposed minSdkVersion values. The only reason why you would need to consider FragmentActivity specifically is if you want to use nested fragments (a fragment holding another fragment), as that was not supported in native fragments until API Level 17.
AppCompatActivity is from the appcompat-v7 library. Principally, this offers a backport of the action bar. Since the native action bar was added in API Level 11, you do not need AppCompatActivity for that. However, current versions of appcompat-v7 also add a limited backport of the Material Design aesthetic, in terms of the action bar and various widgets. There are pros and cons of using appcompat-v7, well beyond the scope of this specific Stack Overflow answer.
ActionBarActivity is the old name of the base activity from appcompat-v7. For various reasons, they wanted to change the name. Unless some third-party library you are using insists upon an ActionBarActivity, you should prefer AppCompatActivity over ActionBarActivity.
So, given your minSdkVersion in the 15-16 range:
If you want the backported Material Design look, use AppCompatActivity
If not, but you want nested fragments, use FragmentActivity
If not, use Activity
Just adding from comment as note: AppCompatActivity extends FragmentActivity, so anyone who needs to use features of FragmentActivity can use AppCompatActivity.

Activity is the base class of all other activities, I don't think it will be deprecated. The relationship among them is:
Activity <- FragmentActivity <- AppCompatActivity <- ActionBarActivity
'<-' means inheritance here. The reference said ActionBarActivity is deprecated, use AppCompatActivity instead.
So basically, using AppCompatActivity is always the right choice. The differences between them are:
Activity is the basic one.
Based on Activity, FragmentActivity provides the ability to use Fragment.
Based on FragmentActivity, AppCompatActivity provides features to ActionBar.

2019: Use AppCompatActivity
At the time of this writing (check the link to confirm it is still true), the Android Documentation recommends using AppCompatActivity if you are using an App Bar.
This is the rational given:
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.
The general directions for adding a ToolBar are
Add the v7 appcompat support library
Make all your activities extend AppCompatActivity
In the Manifest declare that you want NoActionBar.
Add a ToolBar to each activity's xml layout.
Get the ToolBar in each activity's onCreate.
See the documentation directions for more details. They are quite clear and helpful.

For a minimum API level of 15, you'd want to use AppCompatActivity. So for example, your MainActivity would look like this:
public class MainActivity extends AppCompatActivity {
....
....
}
To use the AppCompatActivity, make sure you have the Google Support Library downloaded (you can check this in your Tools -> Android -> SDK manager). Then just include the gradle dependency in your app's gradle.build file:
compile 'com.android.support:appcompat-v7:22:2.0'
You can use this AppCompat as your main Activity, which can then be used to launch Fragments or other Activities (this depends on what kind of app you're building).
The BigNerdRanch book is a good resource, but yeah, it's outdated. Read it for general information on how Android works, but don't expect the specific classes they use to be up to date.

Activity class is the basic class. (The original) It supports Fragment management (Since API 11). Is not recommended anymore its pure use because its specializations are far better.
ActionBarActivity was in a moment the replacement to the Activity class because it made easy to handle the ActionBar in an app.
AppCompatActivity is the new way to go because the ActionBar is not encouraged anymore and you should use Toolbar instead (that's currently the ActionBar replacement). AppCompatActivity inherits from FragmentActivity so if you need to handle Fragments you can (via the Fragment Manager). AppCompatActivity is for ANY API, not only 16+ (who said that?). You can use it by adding compile 'com.android.support:appcompat-v7:24:2.0' in your Gradle file. I use it in API 10 and it works perfect.

There is a lot of confusion here, especially if you read outdated sources.
The basic one is Activity, which can show Fragments. You can use this combination if you're on Android version > 4.
However, there is also a support library which encompasses the other classes you mentioned: FragmentActivity, ActionBarActivity and AppCompat. Originally they were used to support fragments on Android versions < 4, but actually they're also used to backport functionality from newer versions of Android (material design for example).
The latest one is AppCompat, the other 2 are older. The strategy I use is to always use AppCompat, so that the app will be ready in case of backports from future versions of Android.

Since the name is likely to change in future versions of Android (currently the latest is AppCompatActivity but it will probably change at some point), I believe a good thing to have is a class Activity that extends AppCompatActivity and then all your activities extend from that one. If tomorrow, they change the name to AppCompatActivity2 for instance you will have to change it just in one place.

Appropriate way to use Android Support Library

When I created a new app, I got this
class NewApplicationActivity extends ActionBarActivity{... }
So I have read that, if you want to use a new feature from a newer API level, you better make it such that there is an alternative option for the App to combat any situation for the minSDKVersion that you plan to support.
Assuming this is true, lets say I decide to build my App against targetSDKVersion = 21(which I did in the above example), I would get the base Activity class as ActionBarActivity. Now this is from support library and works for older version(down to Android 2.1 I guess..).
The thing is, I am stuck with these alternative set of support libraries rather than platform libraries. Am I gonna miss something significant if this happens? Will I get a chance to incorporate the platform specific code from API 21 into my App ever? The majority of Apps are made with compatibility in mind. How do you people handle this?

Support Libraries such as AppCompat (which is what ActionBarActivity and its replacement AppCompatActivity are part of) are designed to reflect the latest platform changes and backport as much as possible. Thereby by using AppCompat, you are already using a large number of API 21 features (such as material theme).
Of course, there is nothing stopping you including any API from any level in your application: just make sure that they are guarded by the appropriate API level checks: this is exactly what many of the Compat classes in Support v4 such as NotificationCompat and ViewCompat do for you.

"The type TabActivity is deprecated" For app tab

"The type TabActivity is deprecated"?
I am making the Tabs of app following tutorial book.
I've checked from the android developer.com website, but i have no ideas on the significance of the following message : This class is deprecated.
New applications should use Fragments instead of this class; to continue to run on older devices, you can use the v4 support library which provides a version of the Fragment API that is compatible down to DONUT."* (http://developer.android.com/reference/android/app/TabActivity.html)
What is v4 support library?
How to finish the tab functions?

You can still use a deprecated package. It is however recommended to use Fragments, and thus the support package. You can read more about it here. However, if you are a beginner at java and android development, I would recommend ignoring the deprecation for now and come back to this when you have completed the tutorial you are currently using if you find it educating.
If you want to watch a nice example of tabbed navigation using Fragments, then create a new project in Eclipse using android 4.0 or later. Make sure your android-plugin is updated. You will get the option to create a project with basic navigation already implemented.

"Deprecated" means that the api developers don't recommend using it anymore, probably because its not a good model, or inefficient, etc. Fragments were introduced in Honeycomb and can be used to provide a similar functionality as tabs and is more in-line with android's current design philosophy.
Since Fragment was introduced in Android 3.0 Honeycomb, you might think you cannot use that for pre-Honeycomb devices. Enter Support Libraries. They are libraries which you can include in your application which needs to run on pre-Honeycomb and still use this class.
So if you want to, you can finish the TabActivity as described in whatever tutorial you are following, it'll probably work on a few more upcoming android versions. But it is recommended that you start using Fragments.