Build.VERSION_CODES

October 2008: The original, first, version of Android. Yay!

February 2009: First Android update, officially called 1.1.

May 2009: Android 1.5.

Magic version number for a current development build, which has not yet turned into an official release.

September 2009: Android 1.6.

Applications targeting this or a later release will get these new changes in behavior:

• They must explicitly request the WRITE_EXTERNAL_STORAGE permission to be able to modify the contents of the SD card. (Apps targeting earlier versions will always request the permission.)
• They must explicitly request the READ_PHONE_STATE permission to be able to be able to retrieve phone state info. (Apps targeting earlier versions will always request the permission.)
• They are assumed to support different screen densities and sizes. (Apps targeting earlier versions are assumed to only support medium density normal size screens unless otherwise indicated). They can still explicitly specify screen support either way with the supports-screens manifest tag.

November 2009: Android 2.0

Applications targeting this or a later release will get these new changes in behavior:

• The Service.onStartCommand function will return the new START_STICKY behavior instead of the old compatibility START_STICKY_COMPATIBILITY.
• The Activity class will now execute back key presses on the key up instead of key down, to be able to detect canceled presses from virtual keys.
• The TabWidget class will use a new color scheme for tabs. In the new scheme, the foreground tab has a medium gray background the background tabs have a dark gray background.

December 2009: Android 2.0.1

January 2010: Android 2.1

June 2010: Android 2.2

November 2010: Android 2.3

February 2011: Android 2.3.3.

February 2011: Android 3.0.

Applications targeting this or a later release will get these new changes in behavior:

• The default theme for applications is now dark holographic: Theme_Holo.
• The activity lifecycle has changed slightly as per Activity.
• When an application requires a permission to access one of its components (activity, receiver, service, provider), this permission is no longer enforced when the application wants to access its own component. This means it can require a permission on a component that it does not itself hold and still access that component.

May 2011: Android 3.1.

June 2011: Android 3.2.

Update to Honeycomb MR1 to support 7 inch tablets, improve screen compatibility mode, etc.

As of this version, applications that don't say whether they support XLARGE screens will be assumed to do so only if they target HONEYCOMB or later; it had been GINGERBREAD or later. Applications that don't support a screen size at least as large as the current screen will provide the user with a UI to switch them in to screen size compatibility mode.

This version introduces new screen size resource qualifiers based on the screen size in dp: see screenWidthDp, screenHeightDp, and smallestScreenWidthDp. Supplying these in <supports-screens> as per requiresSmallestWidthDp, compatibleWidthLimitDp, and largestWidthLimitDp is preferred over the older screen size buckets and for older devices the appropriate buckets will be inferred from them.

New FEATURE_SCREEN_PORTRAIT and FEATURE_SCREEN_LANDSCAPE features are introduced in this release. Applications that target previous platform versions are assumed to require both portrait and landscape support in the device; when targeting Honeycomb MR1 or greater the application is responsible for specifying any specific orientation it requires.

Android 4.0.

Applications targeting this or a later release will get these new changes in behavior:

• For devices without a dedicated menu key, the software compatibility menu key will not be shown even on phones. By targeting Ice Cream Sandwich or later, your UI must always have its own menu UI affordance if needed, on both tablets and phones. The ActionBar will take care of this for you.
• 2d drawing hardware acceleration is now turned on by default. You can use android:hardwareAccelerated to turn it off if needed, although this is strongly discouraged since it will result in poor performance on larger screen devices.
• The default theme for applications is now the "device default" theme: Theme_DeviceDefault. This may be the holo dark theme or a different dark theme defined by the specific device. The Theme_Holo family must not be modified for a device to be considered compatible. Applications that explicitly request a theme from the Holo family will be guaranteed that these themes will not change character within the same platform version. Applications that wish to blend in with the device should use a theme from the Theme_DeviceDefault family.
• Managed cursors can now throw an exception if you directly close the cursor yourself without stopping the management of it; previously failures would be silently ignored.
• The fadingEdge attribute on views will be ignored (fading edges is no longer a standard part of the UI). A new requiresFadingEdge attribute allows applications to still force fading edges on for special cases.