Android's Minsdkversion,targetsdkversion,maxsdkversion

Android MINSDKVERSION,TARGETSDKVERSION,MAXSDKVERSION-EDISONLG column-Blog channel-csdn.net
http://blog.csdn.net/edisonlg/article/details/7855898

API level is an integer value that represents a specific version of Android Publishing, and the new API level adds the following to the old API level:
* added, modified, or even deleted APIs for new classes or existing classes
* The newly defined XML tag
* New Definition Intent
* New definition of permission
* Other ...


The API level and version have the following correspondence:
Platform Version API Level
Android 3.0 11
Android 2.3.3 10
Android 2.3 9
Android 2.2 8
Android 2.1 7
Android 2.0.1 6
Android 2.0 5
Android 1.6 4
Android 1.5 3
Android 1.1 2
Android 1.0 1


Let's talk about the usefulness of minsdkversion:
The new version of the public in the old version of the interface is not, if I write an app with only the new version of the interface, it must not be allowed to run in the old version of the SDK, or will be error. How does Android guarantee this? This is achieved by defining minsdkversion. For example, if I define the <USES-SDK android:minsdkversion= "8" .../>, the build apk is not installed on Android 2.1 (API level 7) system, you will be prompted: ERROR: Application requires API version 8. Device API version is 7.

If not written in Androidmanifest.xml, the default minsdkversion = 1 means that the program can be installed at least, and the author also wants it to run on Android 1.0.

Now let's talk about the usefulness of targetsdkversion:
In general, newer versions are compatible with older versions, which is why many of the interfaces in Android are still in the new SDK, even though they are obsolete (deprecated), so in most cases, applications developed for older versions can run on the new SDK. But there are some exceptions, mainly the following three types of problems:

1. The old interface has been deleted or modified (this case has, but rarely), this article does not concern
2. The same interface, but the implementation of the new and old version is different. For example, some APIs were poorly thought out early in the design and the new version was improved.
3. Even if no interface calls are involved, but due to the expansion of the physical device, the same apk needs to be fitted with more physical devices on the new version, thus providing new features

For the second type of problem, specifying Targetsdkversion as a specific API level means that the calling interface will only invoke the API of that version implementation, not the earlier version of the API.
For the third kind of problem, this letter encountered the situation, Google from the development of Android 1.6 (API level 4) began to realize that the program needs to take into account the phone screen size, the resolution is different. As a result, support for multiple screens has been introduced from 1.6, which defines a correspondence between different screen sizes and resolution and density. Note that Google only realized that it was developed under the medium density screen (MDPI), so resources and layouts such as 1.5 and previous versions of picture icons were designed according to the medium density screen.

Starting with Android 1.6, Google offers multiple sets of resources (LDPI, MDPI, hdpi) support for built-in applications and framework resources (such as controls), and the system can decide to package only a specific density of resources at compile time (defined in product_ LOCALES, to N1, should be product_locales: = hdpi ... ）。

For SDK-based applications, Eclipse lacks the capital to pack all the density resources, running on Android 1.6, and selecting the corresponding density resources at runtime based on the actual density of the physical device.

If Targetsdkversion <= 3 is defined in an app, it means that the app doesn't have the ability to use the multi-screen support that Android 1.6 has, so even if the app itself contains hdpi,mdpi,ldpi resources, However, when running to HDPI's physical device, only the MDPI resources will be loaded, and of course the display will not be normal.
Note: If a system-level resource (such as a control) is also used in the app, it is generally possible that a particular physical device is only hdpi,mdpi, ldpi (later, such as XDPI), so only one DPI resource is loaded, so the display system control should not have any problems. However, if the image is not optimized and contains all the resources, the control display is not normal.

To get back to the point, why does the program compiled under Eclipse Run and show different results from Ubuntu under compilation?

Compiled under Ubuntu, the system thinks that you compile the built-in application, the built-in application under normal circumstances will not be stripped out of the abnormal people to put on other devices, so there is no installation compatibility problem, minsdkversion default is the current physical device's existing SDK version. In addition, since it is built-in, it works best on the current physical device, so targetsdkversion defaults to current SDK version of the physical device as well. When the APK is packaged at compile time, the build system first detects whether the two values are set or not, and it will add it for you if it is not set.

Compile under Eclipse, the system thinks you compile third-party application, forget to write is your wrong, minsdkversion and targetsdkversion default is 1, so there will be the above mentioned tragedy.

Conclusion:
1. For built-in applications, do not set minsdkversion and targetsdkversion yourself;
2. Based on the SDK development, according to their actual situation, we must set minsdkversion and targetsdkversion;
3. Just did not say maxsdkversion, we do not define it, may later OTA upgrade the entire Android system, defined It is a tragedy for us

Android's Minsdkversion,targetsdkversion,maxsdkversion