Causes the current thread to wait until another thread invokes the
notify() method or the
notifyAll() method for this object, or
some other thread interrupts the current thread, or a certain
amount of real time has elapsed.

DONUT

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.

An application will crash if it does not call through
to the super implementation of its
Activity.onPause() method.

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.

HONEYCOMB_MR2

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.

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

New FEATURE_SCREEN_PORTRAIT
and FEATURE_SCREEN_LANDSCAPE
features were 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.

ICE_CREAM_SANDWICH

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.

In WebView, apps targeting earlier versions will have
JS URLs evaluated directly and any result of the evaluation will not replace
the current page content. Apps targetting KITKAT or later that load a JS URL will
have the result of that URL replace the content of the current page

AlarmManager.set becomes interpreted as
an inexact value, to give the system more flexibility in scheduling alarms.

Your application processes will not be killed when the device density changes.

Drag and drop. After a view receives the
ACTION_DRAG_ENTERED event, when the drag shadow moves into
a descendant view that can accept the data, the view receives the
ACTION_DRAG_EXITED event and won’t receive
ACTION_DRAG_LOCATION and
ACTION_DROP events while the drag shadow is within that
descendant view, even if the descendant view returns false from its handler
for these events.