Develop Reference

Purpose of Android Support Library

I am getting started with Android. I am quite confused with what support library actually does . I am following a book and in the book it is mentioned that :
If an app is installed on a minimum SDK system, and our Java code
contains any calls to classes that are not present in minimum SDK ,
our app will crash
I read an article about support libraries here:
Tutorials Point
If Support libraries provide backward compatibility, doesn't it mean when they should prevent app crash?(may be by wrapping up those newer classes and making them backward compatible). What does support library actually do? Please explain.

When should I use the Android Support Library?
As new versions of Android are released, some style and behaviors may change. 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.
What does support library actually do?
There are many devices still running in Jelly bean and below versions. So you need to give the same importance for old and new devices While making an app. Otherwise, the App in old devices looks dull when compared to new ones. That may affect the app’s market. To avoid this trouble, Android introduced the Support library. These are set of code libraries provides backward compatibility
Example:
Fragment API was introduced in API 11 HONEYCOMB .android.app.Fragment is the Fragment class introduced in API 11 and android.support.v4.app.Fragment is the Fragment class in the android support library,
If you want to make your app use fragments, and want to target devices before API 11, you must use android.support.v4.app.Fragment. However, if you want only targeting devices >=API 11 ,you can use android.app.Fragment.Therefore, android.support.v4.app.FragmentManager is used to deliver newer features to older platforms.
For more info about android support library:doc

1.Suppose you want to create an app which runs on platform comes after marshmallow.
then minimum sdk of your app will be marshmallow.
2.While creating your app you call a method which is present in oreo or later version then you app will have chances to crash on marshmallow and nougat.

Android app with support library, which code execute on run time on newer OS

Even that this is a general question, I'll ask it with an example that it would be easier to understand.
Scenarios:
I'm using support library 7 and using the action bar feature. A user is installing the app on a device with Android 2.2 (API 8).
I'm using support library 7 and using the action bar feature. A user is installing the app on a device with Android 4.3 (API 18).
It is obvious that at run time scenario 1 would run the code of the supported library. But what will happen on scenario 2? Would it run the OS code or the support library code.
I really hope that it runs the OS code.
EDIT
I know that the way Java work is that methods are resolved by their fully qualified name determined at build time (as #adelphus wrote). And therefore the Support library code will run. But if I was the one that implementing the support library, I would have been doing the following:
Check the version of the OS on run time
In case that the OS has the current object/method I would call to the OS implementation (Actually in this case the support library is only a wrapper for the OS functionality).
In case that this is an old OS, I would have implementing the behavior myself
So, does it act on newer version as a wrapper, or on both cases it using the internal implementation?
Thanks

It will run the support library.
The way Java (and therefore Android Apps) work is that methods are resolved by their fully qualified name determined at build time. Since you would have built the App against the support library, that is what will be called, regardless of the version of Android it is executing on.
In reality, it should make no difference to the end user. The point of the support libraries is to provide the same behavior for older versions of Android which don't have the functionality of the new versions. Why would you care whether it is calling the support library or not if the end result is the same?

Platform compatibility issue

Android platform sample codes and reference from the Android developer site is based on platform 1.5 I understand that newer platforms can support applications developed on older platforms but the reciprocal is not applicable which makes sense but is the coding different? Are codes that were used for developing 1.5 apps still useful in newer platforms or have newer classes and methods replaced them? It seems that eclipse is producing a lot of coding errors in its samples in relation to classes and methods also if a app that was developd by a IME is unable to be viewed on the emulator or how can it be tested or retrieved on the device? Any advice is welcome...sorry it's so long

If you look in the SDK folders, on windows it will be c:\<SDK location>\samples\android-x the samples are located according to api level so they will definitely be compatible there so I would look at these.
To answer your other questions, yes there are api changes as you go up an api level so they should cause warnings or compilation errors and some classes may even be completely removed. Generally the lower level stuff shouldn't change too much but the most important thing is that the semantics change rarely unless there was a design flaw in the original implementations.
The release notes for each version usually points out what has changed and the online documentation is generally superb in my opinion in informing you what exactly is deprecated. If you are just targeting old devices then your emulator is just set to target those api levels but if you are concerned about functionality then you could code using api 1.5 say, and run an ICS api level 15 emulator and check everything works OK, if not then you decide what the best strategy should be. Generally I would advise to target Android 2.2 and above for mobile devices and 3.0 for tablets but really it is up to you.

three are classes that are deprecated and can't be used anymore, like Contacts.People. There are also classes that are deprecated, they can still be used but they should be avoided in new projects. And there are new classes that were not available before. In some cases like for Fragment there are compatibility support libs to use the new features on the old platform but this is not true for classes like for example PreferenceFragment that are not supported on old platforms.

Android SDK version

I'm quite confused how application behaves when launched on different Android versions.
Let's say I'm compiling it using SDK level 4. Is it compiled in the code and when running it on phone with SDK 10 will still use the old SDK 4, or it will use SDK 10?
A simple example is Service's setForeground()-method, which was deprecated. If I run such code on phone with SDK 10, will the function have no effect or it will use the version from SDK 4?
The same goes for onStart() being deprecated. Is it going to be ignored on SDK 10 and it will try to call onStartCommand()?
I'd be thankful if somebody could explain me what's gonna happen here and why.

Is it compiled in the code and when running it on phone with SDK 10 will still use the old SDK 4, or it will use SDK 10?
SDK means Software Development Kit, thus devices do not run anything using the SDK. On the other hand, devices have different kind of OS which belongs to a specific API.
If you run a build compiled using SDK 4, and run it in a device which runs API 10, it will run it using the new API (that's called, backwards compatibility).
Usually, deprecated functions are supported on newer versions of the SDK. Most of them will work, but you must try to not use them. Of course, there are cases where you have no choice, for instance, when the method you are using is deprecated but there is no replacement in the old SDK that you are using.

Your service is just compiled bytecode - with own classes and references to other classes and methods. When it is deployed on newer android version, it (android, OS) will do whatever it sees fit - you have no influence there. As other java based systems, it will rely on proper class names / packages / interfaces, and try to resolve methods with certain signatures ( parameters and return values). If it behaves socially, it would first check if there is method from newer interface ( i.e. onStartCommand() ), and if it is available it will be called. Then it may (or not) fallback to older method. But usually you can rely that reverse compatibility is maintained pretty long time.

Most deprecated api calls on most phones will work...
However, some, like your given example of setForeground() have been removed due to the fact that developers have misused it (setting a service into the foreground without notifying users). So they WILL NOT work.
Unfortunately, there is no documentation to which ones are supported and which ones aren't so it's a trial and error thing...
Also, there are differences between different implementations (phone manufacturers / models) for some reason.
A good example is the old Contacts APi (pre V2.0) which works on some newer phones with Android 2.2/2.3 and doesn't work on others with the same OS versions...
The best bet would be NOT to use deprecated methods, and to adjust according to the current popularity of the Android OS version (currently 2.1, 2.2, 2.3.2, 2.3.3 are the popular versions: http://developer.android.com/resources/dashboard/platform-versions.html).

Confused about Android API's and compatability

I have purchased an HTC Incredible and have dived into the world of android! Only to find myself totally confused about the API levels and backward compatibility.
My device runs the 2.1 OS, but I know that most of the devices out there run 1.5 or 1.6; and soon the 2.2 OS will be running on new devices. The SDK has gone through such enormous changes, that even constants have been renamed (from VIEW_ACTION to ACTION_VIEW for example). Methods have been added and removed (onPause replacing the earlier call, etc al).
So, If I want to write an application that will work from 1.6+, does that mean I have to install and write my code using the 1.6 API; then test on later versions? Or can I write using the 2.1 SDK and just set the minSDK level and not use "new" features?
I have never worked with an SDK that changes SO drastically from release to release! So I am not sure what to do....
I read through an article on the Android Development site(and this posting on stack overflow that references it: Should a legacy Android application be rebuilt using SDK 2.1?), but it was still not very clear to me.
Any help would be appreciated

The SDK has gone through such enormous
changes, that even constants have been
renamed (from VIEW_ACTION to
ACTION_VIEW for example). Methods have
been added and removed (onPause
replacing the earlier call, etc al).
Those were two years ago, on a beta version of the platform, before there were any shipping devices. Since Android 1.0, there has been very little that breaks forward compatibility, mostly in the area of settings that were moved into a secure API so SDK applications cannot mess with them.
So, If I want to write an application
that will work from 1.6+, does that
mean I have to install and write my
code using the 1.6 API; then test on
later versions? Or can I write using
the 2.1 SDK and just set the minSDK
level and not use "new" features?
You make it seem like those are mutually exclusive. In fact, they are largely identical.
Keep your toolset on the latest version of the Android development tools
Put the minSdkVersion in your manifest to state what is the lowest API level you want to support
Put the targetSdkVersion in your manifest to state what your "target" API level is, so Android can apply some compatibility helpers if your app runs on a newer version of Android (typically, you "target" the then-current API level)
Write your code mostly to the API level you specified in minSdkVersion, optionally using reflection or conditional class loading to access newer APIs on devices that support them
Test on everything you can get your hands on, at least emulators for the different API levels

You can use the current SDK and set minSDK level to whatever level you want. If you do this then you cannot use any functionality that is not in the minSDK. It is also a good idea though to test it on all versions of the SDK with the emulator.
<uses-sdk minSDK="4" targetSDK="8"/>
That lets it know that you are targeting 2.2 but the minimum SDK level you want your app to run on is 1.6. By doing that you can use some of the new xml stuff in the newer versions like supports-screen and different drawables for different screens, etc.