<li><a href="#relnotes">Revisions</a></li>
<li><a href="#api">API Overview</a></li>
<li><a href="#Honeycomb">Previous APIs</a></li>
- <li><a href="#api-diff">API Differences Report</a></li>
<li><a href="#api-level">API Level</a></li>
<li><a href="#apps">Built-in Applications</a></li>
<li><a href="#locs">Locales</a></li>
<p><em>API Level:</em> <strong>{@sdkPlatformApiLevel}</strong></p>
-<p>Android 4.0 (Ice Cream Sandwich) is a major platform release that adds new
-capabilities for users and developers. The sections below provide an overview
-of the new features and developer APIs.</p>
-
-<p>For developers, the Android {@sdkPlatformVersion} platform is available as a
-downloadable component for the Android SDK. The downloadable platform includes
+<p>Android 4.0 is a major platform release that adds a variety of new features for users and app
+developers. Besides all the new features and APIs discussed below, Android 4.0 is an important
+platform release because it brings the extensive set of APIs and Holographic themes from Android 3.x
+to smaller screens. As an app developer, you now have a single platform and unified API framework
+that enables you to develop and publish your application with a single APK that provides an
+optimized user experience for handsets, tablets, and more, when running the same version of
+Android—Android 4.0 (API level 14) or greater. </p>
+
+<p>The Android {@sdkPlatformVersion} platform is available as a
+downloadable component for the Android SDK so you can begin developing and testing your
+applications on Android 4.0 with the Android emulator. The downloadable platform includes
an Android library and system image, as well as a set of emulator skins and
-more. The downloadable platform includes no external libraries.</p>
+more. The downloadable platform does not include any external libraries.</p>
<p>To start developing or testing against Android {@sdkPlatformVersion},
use the Android SDK Manager to download the platform into your SDK. For more
soon as possible to be sure your application provides the best
experience possible on the latest Android-powered devices.</p>
-<p>For a high-level introduction to the new user and developer features in Android 4.0, see the
+<p>For a high-level overview of the new user and developer features in Android 4.0, see the
<a href="http://developer.android.com/sdk/android-4.0-highlights.html">Platform Highlights</a>.</p>
+
<h2 id="relnotes">Revisions</h2>
<p>To determine what revision of the Android {@sdkPlatformVersion} platform you
<div class="toggle-content-toggleme" style="padding-left:2em;">
<ol class="toc" style="margin-left:-1em">
- <li><a href="#Contacts">Contact Provider</a></li>
+ <li><a href="#Contacts">Social APIs in Contacts Provider</a></li>
<li><a href="#Calendar">Calendar Provider</a></li>
<li><a href="#Voicemail">Voicemail Provider</a></li>
- <li><a href="#Camera">Camera</a></li>
<li><a href="#Multimedia">Multimedia</a></li>
- <li><a href="#Bluetooth">Bluetooth</a></li>
+ <li><a href="#Camera">Camera</a></li>
<li><a href="#AndroidBeam">Android Beam (NDEF Push with NFC)</a></li>
<li><a href="#WiFiDirect">Wi-Fi Direct</a></li>
+ <li><a href="#Bluetooth">Bluetooth Health Devices</a></li>
+ <li><a href="#A11y">Accessibility</a></li>
+ <li><a href="#SpellChecker">Spell Checker Services</a></li>
+ <li><a href="#TTS">Text-to-speech Engines</a></li>
<li><a href="#NetworkUsage">Network Usage</a></li>
<li><a href="#RenderScript">RenderScript</a></li>
- <li><a href="#A11y">Accessibility</a></li>
<li><a href="#Enterprise">Enterprise</a></li>
<li><a href="#Sensors">Device Sensors</a></li>
- <li><a href="#TTS">Text-to-speech Engines</a></li>
- <li><a href="#SpellChecker">Spell Checker Services</a></li>
<li><a href="#ActionBar">Action Bar</a></li>
<li><a href="#UI">User Interface and Views</a></li>
+ <li><a href="#Input">Input Framework</a></li>
<li><a href="#Properties">Properties</a></li>
<li><a href="#HwAccel">Hardware Acceleration</a></li>
<li><a href="#Jni">JNI Changes</a></li>
-<h3 id="Contacts">Contact Provider</h3>
+<h3 id="Contacts">Social APIs in Contacts Provider</h3>
-<p>The contact APIs that are defined by the {@link android.provider.ContactsContract} provider have
-been extended to support new features such as a personal profile for the device owner, high
-resolution contact photos, and the ability for users to invite individual contacts to social
-networks that are installed on the device.</p>
+<p>The contact APIs defined by the {@link android.provider.ContactsContract} provider have been
+extended to support new social-oriented features such as a personal profile for the device owner and
+the ability for users to invite individual contacts to social networks that are installed on the
+device.</p>
<h4>User Profile</h4>
skeptical of apps that request it.</p>
-<h4>Large photos</h4>
-
-<p>Android now supports high resolution photos for contacts. Now, when you push a photo into a
-contact record, the system processes it into both a 96x96 thumbnail (as it has previously) and a
-256x256 "display photo" that's stored in a new file-based photo store (the exact dimensions that the
-system chooses may vary in the future). You can add a large photo to a contact by putting a large
-photo in the usual {@link android.provider.ContactsContract.CommonDataKinds.Photo#PHOTO} column of a
-data row, which the system will then process into the appropriate thumbnail and display photo
-records.</p>
-
-
<h4>Invite Intent</h4>
<p>The {@link android.provider.ContactsContract.Intents#INVITE_CONTACT} intent action allows an app
file).</p>
+<h4>Large photos</h4>
+
+<p>Android now supports high resolution photos for contacts. Now, when you push a photo into a
+contact record, the system processes it into both a 96x96 thumbnail (as it has previously) and a
+256x256 "display photo" that's stored in a new file-based photo store (the exact dimensions that the
+system chooses may vary in the future). You can add a large photo to a contact by putting a large
+photo in the usual {@link android.provider.ContactsContract.CommonDataKinds.Photo#PHOTO} column of a
+data row, which the system will then process into the appropriate thumbnail and display photo
+records.</p>
+
+
<h4>Contact Usage Feedback</h4>
<p>The new {@link android.provider.ContactsContract.DataUsageFeedback} APIs allow you to help track
<h3 id="Voicemail">Voicemail Provider</h3>
-<p>The new voicemail APIs allows applications to add voicemails to a content provider on the device.
-Because the APIs currently do not allow third party apps to read all the voicemails from the system,
-the only third-party apps that should use the voicemail APIs are those that have voicemail to
-deliver to the user. For instance, it’s possible that a user has multiple voicemail sources, such as
-one provided by the phone’s service provider and others from VoIP or other alternative voice
-services. These apps can use the APIs to add their voicemails to the system for quick playback. The
-built-in Phone application presents all voicemails from the Voicemail Provider with a single list.
+<p>The new Voicemail Provider allows applications to add voicemails to the
+device, in order to present all the user's voicemails in a single visual presentation. For instance,
+it’s possible that a user has multiple voicemail sources, such as
+one from the phone’s service provider and others from VoIP or other alternative voice
+services. These apps can use the Voicemail Provider APIs to add their voicemails to the device. The
+built-in Phone application then presents all voicemails to the user in a unified presentation.
Although the system’s Phone application is the only application that can read all the voicemails,
each application that provides voicemails can read those that it has added to the system (but cannot
read voicemails from other services).</p>
+<p>Because the APIs currently do not allow third-party apps to read all the voicemails from the
+system, the only third-party apps that should use the voicemail APIs are those that have voicemail
+to deliver to the user.</p>
+
<p>The {@link android.provider.VoicemailContract} class defines the content provider for the
-voicemail APIs. The subclasses {@link android.provider.VoicemailContract.Voicemails} and {@link
-android.provider.VoicemailContract.Status} provide tables in which the Voicemail Providers can
+Voicemail Provder. The subclasses {@link android.provider.VoicemailContract.Voicemails} and {@link
+android.provider.VoicemailContract.Status} provide tables in which apps can
insert voicemail data for storage on the device. For an example of a voicemail provider app, see the
<a href="{@docRoot}resources/samples/VoicemailProviderDemo/index.html">Voicemail Provider
Demo</a>.</p>
+
+<h3 id="Multimedia">Multimedia</h3>
+
+<p>Android 4.0 adds several new APIs for applications that interact with media such as photos,
+videos, and music.</p>
+
+
+<h4>Media Effects</h4>
+
+<p>A new media effects framework allows you to apply a variety of visual effects to images and
+videos. For example, image effects allow you to easily fix red-eye, convert an image to grayscale,
+adjust brightness, adjust saturation, rotate an image, apply a fisheye effect, and much more. The
+system performs all effects processing on the GPU to obtain maximum performance.</p>
+
+<p>For maximum performance, effects are applied directly to OpenGL textures, so your application
+must have a valid OpenGL context before it can use the effects APIs. The textures to which you apply
+effects may be from bitmaps, videos or even the camera. However, there are certain restrictions that
+textures must meet:</p>
+<ol>
+<li>They must be bound to a {@link android.opengl.GLES20#GL_TEXTURE_2D} texture image</li>
+<li>They must contain at least one mipmap level</li>
+</ol>
+
+<p>An {@link android.media.effect.Effect} object defines a single media effect that you can apply to
+an image frame. The basic workflow to create an {@link android.media.effect.Effect} is:</p>
+
+<ol>
+<li>Call {@link android.media.effect.EffectContext#createWithCurrentGlContext
+EffectContext.createWithCurrentGlContext()} from your OpenGL ES 2.0 context.</li>
+<li>Use the returned {@link android.media.effect.EffectContext} to call {@link
+android.media.effect.EffectContext#getFactory EffectContext.getFactory()}, which returns an instance
+of {@link android.media.effect.EffectFactory}.</li>
+<li>Call {@link android.media.effect.EffectFactory#createEffect createEffect()}, passing it an
+effect name from @link android.media.effect.EffectFactory}, such as {@link
+android.media.effect.EffectFactory#EFFECT_FISHEYE} or {@link
+android.media.effect.EffectFactory#EFFECT_VIGNETTE}.</li>
+</ol>
+
+<p>You can adjust an effect’s parameters by calling {@link android.media.effect.Effect#setParameter
+setParameter()} and passing a parameter name and parameter value. Each type of effect accepts
+different parameters, which are documented with the effect name. For example, {@link
+android.media.effect.EffectFactory#EFFECT_FISHEYE} has one parameter for the {@code scale} of the
+distortion.</p>
+
+<p>To apply an effect on a texture, call {@link android.media.effect.Effect#apply apply()} on the
+{@link
+android.media.effect.Effect} and pass in the input texture, it’s width and height, and the output
+texture. The input texture must be bound to a {@link android.opengl.GLES20#GL_TEXTURE_2D} texture
+image (usually done by calling the {@link android.opengl.GLES20#glTexImage2D glTexImage2D()}
+function). You may provide multiple mipmap levels. If the output texture has not been bound to a
+texture image, it will be automatically bound by the effect as a {@link
+android.opengl.GLES20#GL_TEXTURE_2D} and with one mipmap level (0), which will have the same
+size as the input.</p>
+
+<p>All effects listed in {@link android.media.effect.EffectFactory} are guaranteed to be supported.
+However, some additional effects available from external libraries are not supported by all devices,
+so you must first check if the desired effect from the external library is supported by calling
+{@link android.media.effect.EffectFactory#isEffectSupported isEffectSupported()}.</p>
+
+
+<h4>Remote control client</h4>
+
+<p>The new {@link android.media.RemoteControlClient} allows media players to enable playback
+controls from remote control clients such as the device lock screen. Media players can also expose
+information about the media currently playing for display on the remote control, such as track
+information and album art.</p>
+
+<p>To enable remote control clients for your media player, instantiate a {@link
+android.media.RemoteControlClient} with its constructor, passing it a {@link
+android.app.PendingIntent} that broadcasts {@link
+android.content.Intent#ACTION_MEDIA_BUTTON}. The intent must also declare the explicit {@link
+android.content.BroadcastReceiver} component in your app that handles the {@link
+android.content.Intent#ACTION_MEDIA_BUTTON} event.</p>
+
+<p>To declare which media control inputs your player can handle, you must call {@link
+android.media.RemoteControlClient#setTransportControlFlags setTransportControlFlags()} on your
+{@link android.media.RemoteControlClient}, passing a set of {@code FLAG_KEY_MEDIA_*} flags, such as
+{@link android.media.RemoteControlClient#FLAG_KEY_MEDIA_PREVIOUS} and {@link
+android.media.RemoteControlClient#FLAG_KEY_MEDIA_NEXT}.</p>
+
+<p>You must then register your {@link android.media.RemoteControlClient} by passing it to {@link
+android.media.AudioManager#registerRemoteControlClient MediaManager.registerRemoteControlClient()}.
+Once registered, the broadcast receiver you declared when you instantiated the {@link
+android.media.RemoteControlClient} will receive {@link android.content.Intent#ACTION_MEDIA_BUTTON}
+events when a button is pressed from a remote control. The intent you receive includes the {@link
+android.view.KeyEvent} for the media key pressed, which you can retrieve from the intent with {@link
+android.content.Intent#getParcelableExtra getParcelableExtra(Intent.EXTRA_KEY_EVENT)}.</p>
+
+<p>To display information on the remote control about the media playing, call {@link
+android.media.RemoteControlClient#editMetadata editMetaData()} and add metadata to the returned
+{@link android.media.RemoteControlClient.MetadataEditor}. You can supply a bitmap for media artwork,
+numerical information such as elapsed time, and text information such as the track title. For
+information on available keys see the {@code METADATA_KEY_*} flags in {@link
+android.media.MediaMetadataRetriever}.</p>
+
+<p>For a sample implementation, see the <a
+href="{@docRoot}resources/samples/RandomMusicPlayer/index.html">Random Music Player</a>, which
+provides compatibility logic such that it enables the remote control client on Android 4.0
+devices while continuing to support devices back to Android 2.1.</p>
+
+
+<h4>Media player</h4>
+
+<ul>
+<li>Streaming online media from {@link android.media.MediaPlayer} now requires the {@link
+android.Manifest.permission#INTERNET} permission. If you use {@link android.media.MediaPlayer} to
+play content from the Internet, be sure to add the {@link android.Manifest.permission#INTERNET}
+permission to your manifest or else your media playback will not work beginning with Android
+4.0.</li>
+
+<li>{@link android.media.MediaPlayer#setSurface(Surface) setSurface()} allows you define a {@link
+android.view.Surface} to behave as the video sink.</li>
+
+<li>{@link android.media.MediaPlayer#setDataSource(Context,Uri,Map) setDataSource()} allows you to
+send additional HTTP headers with your request, which can be useful for HTTP(S) live streaming</li>
+
+<li>HTTP(S) live streaming now respects HTTP cookies across requests</li>
+</ul>
+
+
+<h4>Media types</h4>
+
+<p>Android 4.0 adds support for:</p>
+<ul>
+<li>HTTP/HTTPS live streaming protocol version 3 </li>
+<li>ADTS raw AAC audio encoding</li>
+<li>WEBP images</li>
+<li>Matroska video</li>
+</ul>
+<p>For more info, see <a href="{@docRoot}guide/appendix/media-formats.html">Supported Media
+Formats</a>.</p>
+
+
+
+
+
<h3 id="Camera">Camera</h3>
<p>The {@link android.hardware.Camera} class now includes APIs for detecting faces and controlling
to {@link android.hardware.Camera.Parameters#setFocusMode setFocusMode()}. When ready to capture
a photo, call {@link android.hardware.Camera#autoFocus autoFocus()}. Your {@link
android.hardware.Camera.AutoFocusCallback} immediately receives a callback to indicate whether
-focus was acheived. To resume CAF after receiving the callback, you must call {@link
+focus was achieved. To resume CAF after receiving the callback, you must call {@link
android.hardware.Camera#cancelAutoFocus()}.</p>
<p class="note"><strong>Note:</strong> Continuous auto focus is also supported when capturing
-<h3 id="Multimedia">Multimedia</h3>
-
-<p>Android 4.0 adds several new APIs for applications that interact with media such as photos,
-videos, and music.</p>
+<h3 id="AndroidBeam">Android Beam (NDEF Push with NFC)</h3>
+<p>Android Beam is a new NFC feature that allows you to send NDEF messages from one device to
+another (a process also known as “NDEF Push"). The data transfer is initiated when two
+Android-powered devices that support Android Beam are in close proximity (about 4 cm), usually with
+their backs touching. The data inside the NDEF message can contain any data that you wish to share
+between devices. For example, the People app shares contacts, YouTube shares videos, and Browser
+shares URLs using Android Beam.</p>
-<h4>Media player</h4>
+<p>To transmit data between devices using Android Beam, you need to create an {@link
+android.nfc.NdefMessage} that contains the information you want to share while your activity is in
+the foreground. You must then pass the {@link android.nfc.NdefMessage} to the system in one of two
+ways:</p>
<ul>
-<li>Streaming online media from {@link android.media.MediaPlayer} now requires the {@link
-android.Manifest.permission#INTERNET} permission. If you use {@link android.media.MediaPlayer} to
-play content from the Internet, be sure to add the {@link android.Manifest.permission#INTERNET}
-permission to your manifest or else your media playback will not work beginning with Android
-4.0.</li>
-
-<li>{@link android.media.MediaPlayer#setSurface(Surface) setSurface()} allows you define a {@link
-android.view.Surface} to behave as the video sink.</li>
-
-<li>{@link android.media.MediaPlayer#setDataSource(Context,Uri,Map) setDataSource()} allows you to
-send additional HTTP headers with your request, which can be useful for HTTP(S) live streaming</li>
+<li>Define a single {@link android.nfc.NdefMessage} to push while in the activity:
+<p>Call {@link android.nfc.NfcAdapter#setNdefPushMessage setNdefPushMessage()} at any time to set
+the message you want to send. For instance, you might call this method and pass it your {@link
+android.nfc.NdefMessage} during your activity’s {@link android.app.Activity#onCreate onCreate()}
+method. Then, whenever Android Beam is activated with another device while the activity is in the
+foreground, the system sends the {@link android.nfc.NdefMessage} to the other device.</p></li>
-<li>HTTP(S) live streaming now respects HTTP cookies across requests</li>
+<li>Define the {@link android.nfc.NdefMessage} to push at the time that Android Beam is initiated:
+<p>Implement {@link android.nfc.NfcAdapter.CreateNdefMessageCallback}, in which your
+implementation of the {@link
+android.nfc.NfcAdapter.CreateNdefMessageCallback#createNdefMessage createNdefMessage()}
+method returns the {@link android.nfc.NdefMessage} you want to send. Then pass the {@link
+android.nfc.NfcAdapter.CreateNdefMessageCallback} implementation to {@link
+android.nfc.NfcAdapter#setNdefPushMessageCallback setNdefPushMessageCallback()}.</p>
+<p>In this case, when Android Beam is activated with another device while your activity is in the
+foreground, the system calls {@link
+android.nfc.NfcAdapter.CreateNdefMessageCallback#createNdefMessage createNdefMessage()} to retrieve
+the {@link android.nfc.NdefMessage} you want to send. This allows you to define the {@link
+android.nfc.NdefMessage} to deliver only once Android Beam is initiated, in case the contents
+of the message might vary throughout the life of the activity.</p></li>
</ul>
+<p>In case you want to run some specific code once the system has successfully delivered your NDEF
+message to the other device, you can implement {@link
+android.nfc.NfcAdapter.OnNdefPushCompleteCallback} and set it with {@link
+android.nfc.NfcAdapter#setOnNdefPushCompleteCallback setNdefPushCompleteCallback()}. The system will
+then call {@link android.nfc.NfcAdapter.OnNdefPushCompleteCallback#onNdefPushComplete
+onNdefPushComplete()} when the message is delivered.</p>
-<h4>Media types</h4>
-
-<p>Android 4.0 adds support for:</p>
-<ul>
-<li>HTTP/HTTPS live streaming protocol version 3 </li>
-<li>ADTS raw AAC audio encoding</li>
-<li>WEBP images</li>
-<li>Matroska video</li>
-</ul>
-<p>For more info, see <a href="{@docRoot}guide/appendix/media-formats.html">Supported Media
-Formats</a>.</p>
-
+<p>On the receiving device, the system dispatches NDEF Push messages in a similar way to regular NFC
+tags. The system invokes an intent with the {@link android.nfc.NfcAdapter#ACTION_NDEF_DISCOVERED}
+action to start an activity, with either a URL or a MIME type set according to the first {@link
+android.nfc.NdefRecord} in the {@link android.nfc.NdefMessage}. For the activity you want to
+respond, you can declare intent filters for the URLs or MIME types your app cares about. For more
+information about Tag Dispatch see the <a
+href="{@docRoot}guide/topics/nfc/index.html#dispatch">NFC</a> developer guide.</p>
+<p>If you want your {@link android.nfc.NdefMessage} to carry a URI, you can now use the convenience
+method {@link android.nfc.NdefRecord#createUri createUri} to construct a new {@link
+android.nfc.NdefRecord} based on either a string or a {@link android.net.Uri} object. If the URI is
+a special format that you want your application to also receive during an Android Beam event, you
+should create an intent filter for your activity using the same URI scheme in order to receive the
+incoming NDEF message.</p>
-<h4>Remote control client</h4>
-
-<p>The new {@link android.media.RemoteControlClient} allows media players to enable playback
-controls from remote control clients such as the device lock screen. Media players can also expose
-information about the media currently playing for display on the remote control, such as track
-information and album art.</p>
-
-<p>To enable remote control clients for your media player, instantiate a {@link
-android.media.RemoteControlClient} with its constructor, passing it a {@link
-android.app.PendingIntent} that broadcasts {@link
-android.content.Intent#ACTION_MEDIA_BUTTON}. The intent must also declare the explicit {@link
-android.content.BroadcastReceiver} component in your app that handles the {@link
-android.content.Intent#ACTION_MEDIA_BUTTON} event.</p>
-
-<p>To declare which media control inputs your player can handle, you must call {@link
-android.media.RemoteControlClient#setTransportControlFlags setTransportControlFlags()} on your
-{@link android.media.RemoteControlClient}, passing a set of {@code FLAG_KEY_MEDIA_*} flags, such as
-{@link android.media.RemoteControlClient#FLAG_KEY_MEDIA_PREVIOUS} and {@link
-android.media.RemoteControlClient#FLAG_KEY_MEDIA_NEXT}.</p>
-
-<p>You must then register your {@link android.media.RemoteControlClient} by passing it to {@link
-android.media.AudioManager#registerRemoteControlClient MediaManager.registerRemoteControlClient()}.
-Once registered, the broadcast receiver you declared when you instantiated the {@link
-android.media.RemoteControlClient} will receive {@link android.content.Intent#ACTION_MEDIA_BUTTON}
-events when a button is pressed from a remote control. The intent you receive includes the {@link
-android.view.KeyEvent} for the media key pressed, which you can retrieve from the intent with {@link
-android.content.Intent#getParcelableExtra getParcelableExtra(Intent.EXTRA_KEY_EVENT)}.</p>
-
-<p>To display information on the remote control about the media playing, call {@link
-android.media.RemoteControlClient#editMetadata editMetaData()} and add metadata to the returned
-{@link android.media.RemoteControlClient.MetadataEditor}. You can supply a bitmap for media artwork,
-numerical information such as elapsed time, and text information such as the track title. For
-information on available keys see the {@code METADATA_KEY_*} flags in {@link
-android.media.MediaMetadataRetriever}.</p>
-
-<p>For a sample implementation, see the <a
-href="{@docRoot}resources/samples/RandomMusicPlayer/index.html">Random Music Player</a>, which
-provides compatibility logic such that it enables the remote control client on Android 4.0
-devices while continuing to support devices back to Android 2.1.</p>
-
-
-<h4>Media Effects</h4>
-
-<p>A new media effects framework allows you to apply a variety of visual effects to images and
-videos. For example, image effects allow you to easily fix red-eye, convert an image to grayscale,
-adjust brightness, adjust saturation, rotate an image, apply a fisheye effect, and much more. The
-system performs all effects processing on the GPU to obtain maximum performance.</p>
-
-<p>For maximum performance, effects are applied directly to OpenGL textures, so your application
-must have a valid OpenGL context before it can use the effects APIs. The textures to which you apply
-effects may be from bitmaps, videos or even the camera. However, there are certain restrictions that
-textures must meet:</p>
-<ol>
-<li>They must be bound to a {@link android.opengl.GLES20#GL_TEXTURE_2D} texture image</li>
-<li>They must contain at least one mipmap level</li>
-</ol>
-
-<p>An {@link android.media.effect.Effect} object defines a single media effect that you can apply to
-an image frame. The basic workflow to create an {@link android.media.effect.Effect} is:</p>
-
-<ol>
-<li>Call {@link android.media.effect.EffectContext#createWithCurrentGlContext
-EffectContext.createWithCurrentGlContext()} from your OpenGL ES 2.0 context.</li>
-<li>Use the returned {@link android.media.effect.EffectContext} to call {@link
-android.media.effect.EffectContext#getFactory EffectContext.getFactory()}, which returns an instance
-of {@link android.media.effect.EffectFactory}.</li>
-<li>Call {@link android.media.effect.EffectFactory#createEffect createEffect()}, passing it an
-effect name from @link android.media.effect.EffectFactory}, such as {@link
-android.media.effect.EffectFactory#EFFECT_FISHEYE} or {@link
-android.media.effect.EffectFactory#EFFECT_VIGNETTE}.</li>
-</ol>
-
-<p>Not all devices support all effects, so you must first check if the desired effect is supported
-by calling {@link android.media.effect.EffectFactory#isEffectSupported isEffectSupported()}.</p>
-
-<p>You can adjust an effect’s parameters by calling {@link android.media.effect.Effect#setParameter
-setParameter()} and passing a parameter name and parameter value. Each type of effect accepts
-different parameters, which are documented with the effect name. For example, {@link
-android.media.effect.EffectFactory#EFFECT_FISHEYE} has one parameter for the {@code scale} of the
-distortion.</p>
-
-<p>To apply an effect on a texture, call {@link android.media.effect.Effect#apply apply()} on the
-{@link
-android.media.effect.Effect} and pass in the input texture, it’s width and height, and the output
-texture. The input texture must be bound to a {@link android.opengl.GLES20#GL_TEXTURE_2D} texture
-image (usually done by calling the {@link android.opengl.GLES20#glTexImage2D glTexImage2D()}
-function). You may provide multiple mipmap levels. If the output texture has not been bound to a
-texture image, it will be automatically bound by the effect as a {@link
-android.opengl.GLES20#GL_TEXTURE_2D} and with one mipmap level (0), which will have the same
-size as the input.</p>
-
-
-
-
-
-
-
-<h3 id="Bluetooth">Bluetooth</h3>
-
-<p>Android now supports Bluetooth Health Profile devices, so you can create applications that use
-Bluetooth to communicate with health devices that support Bluetooth, such as heart-rate monitors,
-blood meters, thermometers, and scales.</p>
-
-<p>Similar to regular headset and A2DP profile devices, you must call {@link
-android.bluetooth.BluetoothAdapter#getProfileProxy getProfileProxy()} with a {@link
-android.bluetooth.BluetoothProfile.ServiceListener} and the {@link
-android.bluetooth.BluetoothProfile#HEALTH} profile type to establish a connection with the profile
-proxy object.</p>
-
-<p>Once you’ve acquired the Health Profile proxy (the {@link android.bluetooth.BluetoothHealth}
-object), connecting to and communicating with paired health devices involves the following new
-Bluetooth classes:</p>
-<ul>
-<li>{@link android.bluetooth.BluetoothHealthCallback}: You must extend this class and implement the
-callback methods to receive updates about changes in the application’s registration state and
-Bluetooth channel state.</li>
-<li>{@link android.bluetooth.BluetoothHealthAppConfiguration}: During callbacks to your {@link
-android.bluetooth.BluetoothHealthCallback}, you’ll receive an instance of this object, which
-provides configuration information about the available Bluetooth health device, which you must use
-to perform various operations such as initiate and terminate connections with the {@link
-android.bluetooth.BluetoothHealth} APIs.</li>
-</ul>
-
-<p>For more information about using the Bluetooth Health Profile, see the documentation for {@link
-android.bluetooth.BluetoothHealth}.</p>
-
-
-
-<h3 id="AndroidBeam">Android Beam (NDEF Push with NFC)</h3>
-
-<p>Android Beam is a new NFC feature that allows you to send NDEF messages from one device to
-another (a process also known as “NDEF Push"). The data transfer is initiated when two
-Android-powered devices that support Android Beam are in close proximity (about 4 cm), usually with
-their backs touching. The data inside the NDEF message can contain any data that you wish to share
-between devices. For example, the People app shares contacts, YouTube shares videos, and Browser
-shares URLs using Android Beam.</p>
-
-<p>To transmit data between devices using Android Beam, you need to create an {@link
-android.nfc.NdefMessage} that contains the information you want to share while your activity is in
-the foreground. You must then pass the {@link android.nfc.NdefMessage} to the system in one of two
-ways:</p>
-
-<ul>
-<li>Define a single {@link android.nfc.NdefMessage} to push while in the activity:
-<p>Call {@link android.nfc.NfcAdapter#setNdefPushMessage setNdefPushMessage()} at any time to set
-the message you want to send. For instance, you might call this method and pass it your {@link
-android.nfc.NdefMessage} during your activity’s {@link android.app.Activity#onCreate onCreate()}
-method. Then, whenever Android Beam is activated with another device while the activity is in the
-foreground, the system sends the {@link android.nfc.NdefMessage} to the other device.</p></li>
-
-<li>Define the {@link android.nfc.NdefMessage} to push at the time that Android Beam is initiated:
-<p>Implement {@link android.nfc.NfcAdapter.CreateNdefMessageCallback}, in which your
-implementation of the {@link
-android.nfc.NfcAdapter.CreateNdefMessageCallback#createNdefMessage createNdefMessage()}
-method returns the {@link android.nfc.NdefMessage} you want to send. Then pass the {@link
-android.nfc.NfcAdapter.CreateNdefMessageCallback} implementation to {@link
-android.nfc.NfcAdapter#setNdefPushMessageCallback setNdefPushMessageCallback()}.</p>
-<p>In this case, when Android Beam is activated with another device while your activity is in the
-foreground, the system calls {@link
-android.nfc.NfcAdapter.CreateNdefMessageCallback#createNdefMessage createNdefMessage()} to retrieve
-the {@link android.nfc.NdefMessage} you want to send. This allows you to define the {@link
-android.nfc.NdefMessage} to deliver only once Android Beam is initiated, in case the contents
-of the message might vary throughout the life of the activity.</p></li>
-</ul>
-
-<p>In case you want to run some specific code once the system has successfully delivered your NDEF
-message to the other device, you can implement {@link
-android.nfc.NfcAdapter.OnNdefPushCompleteCallback} and set it with {@link
-android.nfc.NfcAdapter#setOnNdefPushCompleteCallback setNdefPushCompleteCallback()}. The system will
-then call {@link android.nfc.NfcAdapter.OnNdefPushCompleteCallback#onNdefPushComplete
-onNdefPushComplete()} when the message is delivered.</p>
-
-<p>On the receiving device, the system dispatches NDEF Push messages in a similar way to regular NFC
-tags. The system invokes an intent with the {@link android.nfc.NfcAdapter#ACTION_NDEF_DISCOVERED}
-action to start an activity, with either a URL or a MIME type set according to the first {@link
-android.nfc.NdefRecord} in the {@link android.nfc.NdefMessage}. For the activity you want to
-respond, you can declare intent filters for the URLs or MIME types your app cares about. For more
-information about Tag Dispatch see the <a
-href="{@docRoot}guide/topics/nfc/index.html#dispatch">NFC</a> developer guide.</p>
-
-<p>If you want your {@link android.nfc.NdefMessage} to carry a URI, you can now use the convenience
-method {@link android.nfc.NdefRecord#createUri createUri} to construct a new {@link
-android.nfc.NdefRecord} based on either a string or a {@link android.net.Uri} object. If the URI is
-a special format that you want your application to also receive during an Android Beam event, you
-should create an intent filter for your activity using the same URI scheme in order to receive the
-incoming NDEF message.</p>
-
-<p>You should also pass an “Android application record" with your {@link android.nfc.NdefMessage} in
-order to guarantee that your application handles the incoming NDEF message, even if other
-applications filter for the same intent action. You can create an Android application record by
-calling {@link android.nfc.NdefRecord#createApplicationRecord createApplicationRecord()}, passing it
-your application’s package name. When the other device receives the NDEF message with the
-application record and multiple applications contain activities that handle the specified intent,
-the system always delivers the message to the activity in your application (based on the matching
-application record). If the target device does not currently have your application installed, the
-system uses the Android application record to launch Android Market and take the user to the
-application in order to install it.</p>
+<p>You should also pass an “Android application record" with your {@link android.nfc.NdefMessage} in
+order to guarantee that your application handles the incoming NDEF message, even if other
+applications filter for the same intent action. You can create an Android application record by
+calling {@link android.nfc.NdefRecord#createApplicationRecord createApplicationRecord()}, passing it
+your application’s package name. When the other device receives the NDEF message with the
+application record and multiple applications contain activities that handle the specified intent,
+the system always delivers the message to the activity in your application (based on the matching
+application record). If the target device does not currently have your application installed, the
+system uses the Android application record to launch Android Market and take the user to the
+application in order to install it.</p>
<p>If your application doesn’t use NFC APIs to perform NDEF Push messaging, then Android provides a
default behavior: When your application is in the foreground on one device and Android Beam is
application installed, the system launches it; if it’s not installed, Android Market opens and takes
the user to your application in order to install it.</p>
-<p>For some example code, see the <a
+<p>You can read more about Android Beam and other NFC features in the <a
+href="{@docRoot}guide/topics/nfc/nfc.html">NFC Basics</a> developer guide. For some example code
+using Android Beam, see the <a
href="{@docRoot}resources/samples/AndroidBeamDemo/src/com/example/android/beam/Beam.html">Android
-Beam Demo</a> sample app.</p>
+Beam Demo</a>.</p>
+
-<h3 id="NetworkUsage">Network Usage</h3>
-
-<p>Android 4.0 gives users precise visibility of how much network data their applications are using.
-The Settings app provides controls that allow users to manage set limits for network data usage and
-even disable the use of background data for individual apps. In order to avoid users disabling your
-app’s access to data from the background, you should develop strategies to use use the data
-connection efficiently and adjust your usage depending on the type of connection available.</p>
-
-<p>If your application performs a lot of network transactions, you should provide user settings that
-allow users to control your app’s data habits, such as how often your app syncs data, whether to
-perform uploads/downloads only when on Wi-Fi, whether to use data while roaming, etc. With these
-controls available to them, users are much less likely to disable your app’s access to data when
-they approach their limits, because they can instead precisely control how much data your app uses.
-If you provide a preference activity with these settings, you should include in its manifest
-declaration an intent filter for the {@link android.content.Intent#ACTION_MANAGE_NETWORK_USAGE}
-action. For example:</p>
+<h3 id="Bluetooth">Bluetooth Health Devices</h3>
-<pre>
-<activity android:name="DataPreferences" android:label="@string/title_preferences">
- <intent-filter>
- <action android:name="android.intent.action.MANAGE_NETWORK_USAGE" />
- <category android:name="android.intent.category.DEFAULT" />
- </intent-filter>
-</activity>
-</pre>
-
-<p>This intent filter indicates to the system that this is the activity that controls your
-application’s data usage. Thus, when the user inspects how much data your app is using from the
-Settings app, a “View application settings" button is available that launches your
-preference activity so the user can refine how much data your app uses.</p>
-
-<p>Also beware that {@link android.net.ConnectivityManager#getBackgroundDataSetting()} is now
-deprecated and always returns true—use {@link
-android.net.ConnectivityManager#getActiveNetworkInfo()} instead. Before you attempt any network
-transactions, you should always call {@link android.net.ConnectivityManager#getActiveNetworkInfo()}
-to get the {@link android.net.NetworkInfo} that represents the current network and query {@link
-android.net.NetworkInfo#isConnected()} to check whether the device has a
-connection. You can then check other connection properties, such as whether the device is
-roaming or connected to Wi-Fi.</p>
-
-
-
-
-
-
-
-
-<h3 id="RenderScript">RenderScript</h3>
+<p>Android now supports Bluetooth Health Profile devices, so you can create applications that use
+Bluetooth to communicate with health devices that support Bluetooth, such as heart-rate monitors,
+blood meters, thermometers, and scales.</p>
-<p>Three major features have been added to RenderScript:</p>
+<p>Similar to regular headset and A2DP profile devices, you must call {@link
+android.bluetooth.BluetoothAdapter#getProfileProxy getProfileProxy()} with a {@link
+android.bluetooth.BluetoothProfile.ServiceListener} and the {@link
+android.bluetooth.BluetoothProfile#HEALTH} profile type to establish a connection with the profile
+proxy object.</p>
+<p>Once you’ve acquired the Health Profile proxy (the {@link android.bluetooth.BluetoothHealth}
+object), connecting to and communicating with paired health devices involves the following new
+Bluetooth classes:</p>
<ul>
- <li>Off-screen rendering to a framebuffer object</li>
- <li>Rendering inside a view</li>
- <li>RS for each from the framework APIs</li>
+<li>{@link android.bluetooth.BluetoothHealthCallback}: You must extend this class and implement the
+callback methods to receive updates about changes in the application’s registration state and
+Bluetooth channel state.</li>
+<li>{@link android.bluetooth.BluetoothHealthAppConfiguration}: During callbacks to your {@link
+android.bluetooth.BluetoothHealthCallback}, you’ll receive an instance of this object, which
+provides configuration information about the available Bluetooth health device, which you must use
+to perform various operations such as initiate and terminate connections with the {@link
+android.bluetooth.BluetoothHealth} APIs.</li>
</ul>
-<p>The {@link android.renderscript.Allocation} class now supports a {@link
-android.renderscript.Allocation#USAGE_GRAPHICS_RENDER_TARGET} memory space, which allows you to
-render things directly into the {@link android.renderscript.Allocation} and use it as a framebuffer
-object.</p>
-
-<p>{@link android.renderscript.RSTextureView} provides a means to display RenderScript graphics
-inside of a {@link android.view.View}, unlike {@link android.renderscript.RSSurfaceView}, which
-creates a separate window. This key difference allows you to do things such as move, transform, or
-animate an {@link android.renderscript.RSTextureView} as well as draw RenderScript graphics inside
-a view that lies within an activity layout.</p>
-
-<p>The {@link android.renderscript.Script#forEach Script.forEach()} method allows you to call
-RenderScript compute scripts from the VM level and have them automatically delegated to available
-cores on the device. You do not use this method directly, but any compute RenderScript that you
-write will have a {@link android.renderscript.Script#forEach forEach()} method that you can call in
-the reflected RenderScript class. You can call the reflected {@link
-android.renderscript.Script#forEach forEach()} method by passing in an input {@link
-android.renderscript.Allocation} to process, an output {@link android.renderscript.Allocation} to
-write the result to, and a {@link android.renderscript.FieldPacker} data structure in case the
-RenderScript needs more information. Only one of the {@link android.renderscript.Allocation}s is
-necessary and the data structure is optional.</p>
-
+<p>For more information about using the Bluetooth Health Profile, see the documentation for {@link
+android.bluetooth.BluetoothHealth}.</p>
-<h4>Accessibility services</h4>
-<p>If you're developing an accessibility service, the information about various accessibility events
-has been significantly expanded to enable more advanced accessibility feedback for users. In
-particular, events are generated based on view composition, providing better context information and
-allowing accessibility services to traverse view hierarchies to get additional view information and
-deal with special cases.</p>
+<h4>Accessibility services</h4>
+
+<p>If you're developing an accessibility service, the information about various accessibility events
+has been significantly expanded to enable more advanced accessibility feedback for users. In
+particular, events are generated based on view composition, providing better context information and
+allowing accessibility services to traverse view hierarchies to get additional view information and
+deal with special cases.</p>
+
+<p>If you're developing an accessibility service (such as a screen reader), you can access
+additional content information and traverse view hierarchies with the following procedure:</p>
+<ol>
+<li>Upon receiving an {@link android.view.accessibility.AccessibilityEvent} from an application,
+call the {@link android.view.accessibility.AccessibilityEvent#getRecord(int)
+AccessibilityEvent.getRecord()} to retrieve a specific {@link
+android.view.accessibility.AccessibilityRecord} (there may be several records attached to the
+event).</li>
+
+<li>From either {@link android.view.accessibility.AccessibilityEvent} or an individual {@link
+android.view.accessibility.AccessibilityRecord}, you can call {@link
+android.view.accessibility.AccessibilityRecord#getSource() getSource()} to retrieve a {@link
+android.view.accessibility.AccessibilityNodeInfo} object.
+ <p>An {@link android.view.accessibility.AccessibilityNodeInfo} represents a single node
+of the window content in a format that allows you to query accessibility information about that
+node. The {@link android.view.accessibility.AccessibilityNodeInfo} object returned from {@link
+android.view.accessibility.AccessibilityEvent} describes the event source, whereas the source from
+an {@link android.view.accessibility.AccessibilityRecord} describes the predecessor of the event
+source.</p></li>
+
+<li>With the {@link android.view.accessibility.AccessibilityNodeInfo}, you can query information
+about it, call {@link
+android.view.accessibility.AccessibilityNodeInfo#getParent getParent()} or {@link
+android.view.accessibility.AccessibilityNodeInfo#getChild getChild()} to traverse the view
+hierarchy, and even add child views to the node.</li>
+</ol>
+
+<p>In order for your application to publish itself to the system as an accessibility service, it
+must declare an XML configuration file that corresponds to {@link
+android.accessibilityservice.AccessibilityServiceInfo}. For more information about creating an
+accessibility service, see {@link
+android.accessibilityservice.AccessibilityService} and {@link
+android.accessibilityservice.AccessibilityService#SERVICE_META_DATA
+SERVICE_META_DATA} for information about the XML configuration.</p>
+
+
+<h4>Other accessibility APIs</h4>
+
+<p>If you're interested in the device's accessibility state, the {@link
+android.view.accessibility.AccessibilityManager} has some new APIs such as:</p>
+<ul>
+ <li>{@link android.view.accessibility.AccessibilityManager.AccessibilityStateChangeListener}
+is an interface that allows you to receive a callback whenever accessibility is enabled or
+disabled.</li>
+ <li>{@link android.view.accessibility.AccessibilityManager#getEnabledAccessibilityServiceList
+ getEnabledAccessibilityServiceList()} provides information about which accessibility services
+ are currently enabled.</li>
+ <li>{@link android.view.accessibility.AccessibilityManager#isTouchExplorationEnabled()} tells
+ you whether the explore-by-touch mode is enabled.</li>
+</ul>
+
+
+
+
+
+
+<h3 id="SpellChecker">Spell Checker Services</h3>
+
+<p>A new spell checker framework allows apps to create spell checkers in a manner similar to the
+input method framework (for IMEs). To create a new spell checker, you must implement a service that
+extends
+{@link android.service.textservice.SpellCheckerService} and extend the {@link
+android.service.textservice.SpellCheckerService.Session} class to provide spelling suggestions based
+on text provided by the interface's callback methods. In the {@link
+android.service.textservice.SpellCheckerService.Session} callback methods, you must return the
+spelling suggestions as {@link android.view.textservice.SuggestionsInfo} objects. </p>
+
+<p>Applications with a spell checker service must declare the {@link
+android.Manifest.permission#BIND_TEXT_SERVICE} permission as required by the service.
+The service must also declare an intent filter with {@code <action
+android:name="android.service.textservice.SpellCheckerService" />} as the intent’s action and should
+include a {@code <meta-data>} element that declares configuration information for the spell
+checker. </p>
+
+<p>See the <a href="{@docRoot}resources/samples/SampleSpellCheckerService/index.html">Spell
+Checker</a> sample app for example code.</p>
+
+
+
+
+<h3 id="TTS">Text-to-speech Engines</h3>
+
+<p>Android’s text-to-speech (TTS) APIs have been significantly extended to allow applications to
+more easily implement custom TTS engines, while applications that want to use a TTS engine have a
+couple new APIs for selecting an engine.</p>
+
+
+<h4>Using text-to-speech engines</h4>
+
+<p>In previous versions of Android, you could use the {@link android.speech.tts.TextToSpeech} class
+to perform text-to-speech (TTS) operations using the TTS engine provided by the system or set a
+custom engine using {@link android.speech.tts.TextToSpeech#setEngineByPackageName
+setEngineByPackageName()}. In Android 4.0, the {@link
+android.speech.tts.TextToSpeech#setEngineByPackageName setEngineByPackageName()} method has been
+deprecated and you can now specify the engine to use with a new {@link
+android.speech.tts.TextToSpeech} constructor that accepts the package name of a TTS engine.</p>
+
+<p>You can also query the available TTS engines with {@link
+android.speech.tts.TextToSpeech#getEngines()}. This method returns a list of {@link
+android.speech.tts.TextToSpeech.EngineInfo} objects, which include meta data such as the engine’s
+icon, label, and package name.</p>
+
+
+<h4>Building text-to-speech engines</h4>
+
+<p>Previously, custom engines required that the engine be built using an undocumented native header
+file. In Android 4.0, there is a complete set of framework APIs for building TTS engines. </p>
+
+<p>The basic setup requires an implementation of {@link android.speech.tts.TextToSpeechService} that
+responds to the {@link android.speech.tts.TextToSpeech.Engine#INTENT_ACTION_TTS_SERVICE} intent. The
+primary work for a TTS engine happens during the {@link
+android.speech.tts.TextToSpeechService#onSynthesizeText onSynthesizeText()} callback in a service
+that extends {@link android.speech.tts.TextToSpeechService}. The system delivers this method two
+objects:</p>
+<ul>
+<li>{@link android.speech.tts.SynthesisRequest}: This contains various data including the text to
+synthesize, the locale, the speech rate, and voice pitch.</li>
+<li>{@link android.speech.tts.SynthesisCallback}: This is the interface by which your TTS engine
+delivers the resulting speech data as streaming audio. First the engine must call {@link
+android.speech.tts.SynthesisCallback#start start()} to indicate that the engine is ready to deliver
+the audio, then call {@link android.speech.tts.SynthesisCallback#audioAvailable audioAvailable()},
+passing it the audio data in a byte buffer. Once your engine has passed all audio through the
+buffer, call {@link android.speech.tts.SynthesisCallback#done()}.</li>
+</ul>
+
+<p>Now that the framework supports a true API for creating TTS engines, support for the native code
+implementation has been removed. Look for a blog post about a compatibility layer
+that you can use to convert your old TTS engines to the new framework.</p>
+
+<p>For an example TTS engine using the new APIs, see the <a
+href="{@docRoot}resources/samples/TtsEngine/index.html">Text To Speech Engine</a> sample app.</p>
+
+
+
+
+
+
+<h3 id="NetworkUsage">Network Usage</h3>
+
+<p>Android 4.0 gives users precise visibility of how much network data their applications are using.
+The Settings app provides controls that allow users to manage set limits for network data usage and
+even disable the use of background data for individual apps. In order to avoid users disabling your
+app’s access to data from the background, you should develop strategies to use use the data
+connection efficiently and adjust your usage depending on the type of connection available.</p>
+
+<p>If your application performs a lot of network transactions, you should provide user settings that
+allow users to control your app’s data habits, such as how often your app syncs data, whether to
+perform uploads/downloads only when on Wi-Fi, whether to use data while roaming, etc. With these
+controls available to them, users are much less likely to disable your app’s access to data when
+they approach their limits, because they can instead precisely control how much data your app uses.
+If you provide a preference activity with these settings, you should include in its manifest
+declaration an intent filter for the {@link android.content.Intent#ACTION_MANAGE_NETWORK_USAGE}
+action. For example:</p>
+
+<pre>
+<activity android:name="DataPreferences" android:label="@string/title_preferences">
+ <intent-filter>
+ <action android:name="android.intent.action.MANAGE_NETWORK_USAGE" />
+ <category android:name="android.intent.category.DEFAULT" />
+ </intent-filter>
+</activity>
+</pre>
+
+<p>This intent filter indicates to the system that this is the activity that controls your
+application’s data usage. Thus, when the user inspects how much data your app is using from the
+Settings app, a “View application settings" button is available that launches your
+preference activity so the user can refine how much data your app uses.</p>
+
+<p>Also beware that {@link android.net.ConnectivityManager#getBackgroundDataSetting()} is now
+deprecated and always returns true—use {@link
+android.net.ConnectivityManager#getActiveNetworkInfo()} instead. Before you attempt any network
+transactions, you should always call {@link android.net.ConnectivityManager#getActiveNetworkInfo()}
+to get the {@link android.net.NetworkInfo} that represents the current network and query {@link
+android.net.NetworkInfo#isConnected()} to check whether the device has a
+connection. You can then check other connection properties, such as whether the device is
+roaming or connected to Wi-Fi.</p>
+
+
+
+
+
+
+
+
+<h3 id="RenderScript">RenderScript</h3>
+
+<p>Three major features have been added to RenderScript:</p>
+
+<ul>
+ <li>Off-screen rendering to a framebuffer object</li>
+ <li>Rendering inside a view</li>
+ <li>RS for each from the framework APIs</li>
+</ul>
+
+<p>The {@link android.renderscript.Allocation} class now supports a {@link
+android.renderscript.Allocation#USAGE_GRAPHICS_RENDER_TARGET} memory space, which allows you to
+render things directly into the {@link android.renderscript.Allocation} and use it as a framebuffer
+object.</p>
+
+<p>{@link android.renderscript.RSTextureView} provides a means to display RenderScript graphics
+inside of a {@link android.view.View}, unlike {@link android.renderscript.RSSurfaceView}, which
+creates a separate window. This key difference allows you to do things such as move, transform, or
+animate an {@link android.renderscript.RSTextureView} as well as draw RenderScript graphics inside
+a view that lies within an activity layout.</p>
-<p>If you're developing an accessibility service (such as a screen reader), you can access
-additional content information and traverse view hierarchies with the following procedure:</p>
-<ol>
-<li>Upon receiving an {@link android.view.accessibility.AccessibilityEvent} from an application,
-call the {@link android.view.accessibility.AccessibilityEvent#getRecord(int)
-AccessibilityEvent.getRecord()} to retrieve a specific {@link
-android.view.accessibility.AccessibilityRecord} (there may be several records attached to the
-event).</li>
+<p>The {@link android.renderscript.Script#forEach Script.forEach()} method allows you to call
+RenderScript compute scripts from the VM level and have them automatically delegated to available
+cores on the device. You do not use this method directly, but any compute RenderScript that you
+write will have a {@link android.renderscript.Script#forEach forEach()} method that you can call in
+the reflected RenderScript class. You can call the reflected {@link
+android.renderscript.Script#forEach forEach()} method by passing in an input {@link
+android.renderscript.Allocation} to process, an output {@link android.renderscript.Allocation} to
+write the result to, and a {@link android.renderscript.FieldPacker} data structure in case the
+RenderScript needs more information. Only one of the {@link android.renderscript.Allocation}s is
+necessary and the data structure is optional.</p>
-<li>From either {@link android.view.accessibility.AccessibilityEvent} or an individual {@link
-android.view.accessibility.AccessibilityRecord}, you can call {@link
-android.view.accessibility.AccessibilityRecord#getSource() getSource()} to retrieve a {@link
-android.view.accessibility.AccessibilityNodeInfo} object.
- <p>An {@link android.view.accessibility.AccessibilityNodeInfo} represents a single node
-of the window content in a format that allows you to query accessibility information about that
-node. The {@link android.view.accessibility.AccessibilityNodeInfo} object returned from {@link
-android.view.accessibility.AccessibilityEvent} describes the event source, whereas the source from
-an {@link android.view.accessibility.AccessibilityRecord} describes the predecessor of the event
-source.</p></li>
-<li>With the {@link android.view.accessibility.AccessibilityNodeInfo}, you can query information
-about it, call {@link
-android.view.accessibility.AccessibilityNodeInfo#getParent getParent()} or {@link
-android.view.accessibility.AccessibilityNodeInfo#getChild getChild()} to traverse the view
-hierarchy, and even add child views to the node.</li>
-</ol>
-<p>In order for your application to publish itself to the system as an accessibility service, it
-must declare an XML configuration file that corresponds to {@link
-android.accessibilityservice.AccessibilityServiceInfo}. For more information about creating an
-accessibility service, see {@link
-android.accessibilityservice.AccessibilityService} and {@link
-android.accessibilityservice.AccessibilityService#SERVICE_META_DATA
-SERVICE_META_DATA} for information about the XML configuration.</p>
-<h4>Other accessibility APIs</h4>
-<p>If you're interested in the device's accessibility state, the {@link
-android.view.accessibility.AccessibilityManager} has some new APIs such as:</p>
-<ul>
- <li>{@link android.view.accessibility.AccessibilityManager.AccessibilityStateChangeListener}
-is an interface that allows you to receive a callback whenever accessibility is enabled or
-disabled.</li>
- <li>{@link android.view.accessibility.AccessibilityManager#getEnabledAccessibilityServiceList
- getEnabledAccessibilityServiceList()} provides information about which accessibility services
- are currently enabled.</li>
- <li>{@link android.view.accessibility.AccessibilityManager#isTouchExplorationEnabled()} tells
- you whether the explore-by-touch mode is enabled.</li>
-</ul>
users must manually enable it in the system settings.</p>
-<h4>Device restrictions</h4>
+<h4>Device policies</h4>
<p>Applications that manage the device restrictions can now disable the camera using {@link
android.app.admin.DevicePolicyManager#setCameraDisabled setCameraDisabled()} and the {@link
deprecated. You should use the {@link android.hardware.Sensor#TYPE_AMBIENT_TEMPERATURE} sensor
instead.</p>
-<p>Additionally, Android’s three synthetic sensors have been improved so they now have lower latency
-and smoother output. These sensors include the gravity sensor ({@link
+<p>Additionally, Android’s three synthetic sensors have been greatly improved so they now have lower
+latency and smoother output. These sensors include the gravity sensor ({@link
android.hardware.Sensor#TYPE_GRAVITY}), rotation vector sensor ({@link
android.hardware.Sensor#TYPE_ROTATION_VECTOR}), and linear acceleration sensor ({@link
android.hardware.Sensor#TYPE_LINEAR_ACCELERATION}). The improved sensors rely on the gyroscope
-<h3 id="TTS">Text-to-speech Engines</h3>
-
-<p>Android’s text-to-speech (TTS) APIs have been significantly extended to allow applications to
-more easily implement custom TTS engines, while applications that want to use a TTS engine have a
-couple new APIs for selecting an engine.</p>
-
-
-<h4>Using text-to-speech engines</h4>
-
-<p>In previous versions of Android, you could use the {@link android.speech.tts.TextToSpeech} class
-to perform text-to-speech (TTS) operations using the TTS engine provided by the system or set a
-custom engine using {@link android.speech.tts.TextToSpeech#setEngineByPackageName
-setEngineByPackageName()}. In Android 4.0, the {@link
-android.speech.tts.TextToSpeech#setEngineByPackageName setEngineByPackageName()} method has been
-deprecated and you can now specify the engine to use with a new {@link
-android.speech.tts.TextToSpeech} constructor that accepts the package name of a TTS engine.</p>
-
-<p>You can also query the available TTS engines with {@link
-android.speech.tts.TextToSpeech#getEngines()}. This method returns a list of {@link
-android.speech.tts.TextToSpeech.EngineInfo} objects, which include meta data such as the engine’s
-icon, label, and package name.</p>
-
-
-<h4>Building text-to-speech engines</h4>
-
-<p>Previously, custom engines required that the engine be built using an undocumented native header
-file. In Android 4.0, there is a complete set of framework APIs for building TTS engines. </p>
-
-<p>The basic setup requires an implementation of {@link android.speech.tts.TextToSpeechService} that
-responds to the {@link android.speech.tts.TextToSpeech.Engine#INTENT_ACTION_TTS_SERVICE} intent. The
-primary work for a TTS engine happens during the {@link
-android.speech.tts.TextToSpeechService#onSynthesizeText onSynthesizeText()} callback in a service
-that extends {@link android.speech.tts.TextToSpeechService}. The system delivers this method two
-objects:</p>
-<ul>
-<li>{@link android.speech.tts.SynthesisRequest}: This contains various data including the text to
-synthesize, the locale, the speech rate, and voice pitch.</li>
-<li>{@link android.speech.tts.SynthesisCallback}: This is the interface by which your TTS engine
-delivers the resulting speech data as streaming audio. First the engine must call {@link
-android.speech.tts.SynthesisCallback#start start()} to indicate that the engine is ready to deliver
-the audio, then call {@link android.speech.tts.SynthesisCallback#audioAvailable audioAvailable()},
-passing it the audio data in a byte buffer. Once your engine has passed all audio through the
-buffer, call {@link android.speech.tts.SynthesisCallback#done()}.</li>
-</ul>
-
-<p>Now that the framework supports a true API for creating TTS engines, support for the native code
-implementation has been removed. Look for a blog post about a compatibility layer
-that you can use to convert your old TTS engines to the new framework.</p>
-
-<p>For an example TTS engine using the new APIs, see the <a
-href="{@docRoot}resources/samples/TtsEngine/index.html">Text To Speech Engine</a> sample app.</p>
-
-
-
-
-
-
-<h3 id="SpellChecker">Spell Checker Services</h3>
-
-<p>A new spell checker framework allows apps to create spell checkers in a manner similar to the
-input method framework. To create a new spell checker, you must implement a service that extends
-{@link android.service.textservice.SpellCheckerService} and extend the {@link
-android.service.textservice.SpellCheckerService.Session} class to provide spelling suggestions based
-on text provided by interface callback methods. In the {@link
-android.service.textservice.SpellCheckerService.Session} callback methods, you must return the
-spelling suggestions as {@link android.view.textservice.SuggestionsInfo} objects. </p>
-
-<p>Applications with a spell checker service must declare the {@link
-android.Manifest.permission#BIND_TEXT_SERVICE} permission as required by the service, such that
-other services must have this permission in order for them to bind with the spell checker service.
-The service must also declare an intent filter with {@code <action
-android:name="android.service.textservice.SpellCheckerService" />} as the intent’s action and should
-include a {@code <meta-data>} element that declares configuration information for the spell
-checker. </p>
-
-
-
-
-
-
-
-
-
<h3 id="ActionBar">Action Bar</h3>
<p>The {@link android.app.ActionBar} has been updated to support several new behaviors. Most
<p>Android 4.0 introduces a variety of new views and other UI components.</p>
-<h4>System UI</h4>
-
-<p>Since the early days of Android, the system has managed a UI component known as the <em>status
-bar</em>, which resides at the top of handset devices to deliver information such as the carrier
-signal, time, notifications, and so on. Android 3.0 added the <em>system bar</em> for tablet
-devices, which resides at the bottom of the screen to provide system navigation controls (Home,
-Back, and so forth) and also an interface for elements traditionally provided by the status bar. In
-Android 4.0, the system provides a new type of system UI called the <em>navigation bar</em>. The
-navigation bar shares some qualities with the system bar, because it provides navigation controls
-for devices that don’t have hardware counterparts for navigating the system, but the navigation
-controls is all that the navigation bar offers (a device with the navigation bar, thus, also
-includes the status bar at the top of the screen).</p>
-
-<p>To this day, you can hide the status bar on handsets using the {@link
-android.view.WindowManager.LayoutParams#FLAG_FULLSCREEN} flag. In Android 4.0, the APIs that control
-the system bar’s visibility have been updated to better reflect the behavior of both the system bar
-and navigation bar:</p>
-<ul>
-<li>The {@link android.view.View#SYSTEM_UI_FLAG_LOW_PROFILE} flag replaces View.STATUS_BAR_HIDDEN
-flag. When set, this flag enables “low profile" mode for the system bar or
-navigation bar. Navigation buttons dim and other elements in the system bar also hide.</li>
-
-<li>The {@link android.view.View#SYSTEM_UI_FLAG_VISIBLE} flag replaces the {@code
-STATUS_BAR_VISIBLE} flag to request the system bar or navigation bar be visible.</li>
-
-<li>The {@link android.view.View#SYSTEM_UI_FLAG_HIDE_NAVIGATION} is a new flag that requests that
-the navigation bar hide completely. Take note that this works only for the <em>navigation bar</em>
-used by some handsets (it does <strong>not</strong> hide the system bar on tablets). The navigation
-bar returns as soon as the system receives user input. As such, this mode is generally used for
-video playback or other cases in which the whole screen is needed but user input is not
-required.</li>
-</ul>
-
-<p>You can set each of these flags for the system bar and navigation bar by calling {@link
-android.view.View#setSystemUiVisibility setSystemUiVisibility()} on any view in your activity. The
-window manager will combine (OR-together) all flags from all views in your window and
-apply them to the system UI as long as your window has input focus. When your window loses input
-focus (the user navigates away from your app, or a dialog appears), your flags cease to have effect.
-Similarly, if you remove those views from the view hierarchy their flags no longer apply.</p>
-
-<p>To synchronize other events in your activity with visibility changes to the system UI (for
-example, hide the action bar or other UI controls when the system UI hides), you should register a
-{@link android.view.View.OnSystemUiVisibilityChangeListener} to be notified when the visibility
-of the system bar or navigation bar changes.</p>
-
-<p>See the <a
-href="{@docRoot}resources/samples/ApiDemos/src/com/example/android/apis/view/OverscanActivity.html">
-OverscanActivity</a> class for a demonstration of different system UI options.</p>
-
-
<h4>GridLayout</h4>
<p>{@link android.widget.GridLayout} is a new view group that places child views in a rectangular
android.preference.SwitchPreference} for the Wi-Fi and Bluetooth settings.</p>
+
+<h4>System themes</h4>
+
+<p>The default theme for all applications that target Android 4.0 (by setting either <a
+href="{@docRoot}guide/topics/manifest/uses-sdk-element.html#target">{@code targetSdkVersion}</a> or
+<a href="{@docRoot}guide/topics/manifest/uses-sdk-element.html#min">{@code minSdkVersion}</a> to
+{@code “14"} or higher) is now the
+"device default" theme: {@link android.R.style#Theme_DeviceDefault Theme.DeviceDefault}. This may be
+the dark Holo theme or a different dark theme defined by the specific device.</p>
+
+<p>The {@link android.R.style#Theme_Holo Theme.Holo} family of themes are guaranteed to not change
+from one device to another when running the same version of Android. If you explicitly
+apply any of the {@link android.R.style#Theme_Holo Theme.Holo} themes to your activities, you can
+rest assured that these themes will not change character on different devices within the same
+platform version.</p>
+
+<p>If you wish for your app to blend in with the overall device theme (such as when different OEMs
+provide different default themes for the system), you should explicitly apply themes from the {@link
+android.R.style#Theme_DeviceDefault Theme.DeviceDefault} family.</p>
+
+
+<h4>Options menu button</h4>
+
+<p>Beginning with Android 4.0, you'll notice that handsets no longer require a Menu hardware button.
+However, there's no need for you to worry about this if your existing application provides an <a
+href="{@docRoot}guide/topics/ui/menus.html#options-menu">options menu</a> and expects there to be a
+Menu button. To ensure that existing apps continue to work as they expect, the system provides an
+on-screen Menu button for apps that were designed for older versions of Android.</p>
+
+<p>For the best user experience, new and updated apps should instead use the {@link
+android.app.ActionBar} to provide access to menu items and set <a
+href="{@docRoot}guide/topics/manifest/uses-sdk-element.html#target">{@code targetSdkVersion}</a> to
+{@code "14"} to take advantage of the latest framework default behaviors.</p>
+
+
+
+<h4>Controls for system UI visibility</h4>
+
+<p>Since the early days of Android, the system has managed a UI component known as the <em>status
+bar</em>, which resides at the top of handset devices to deliver information such as the carrier
+signal, time, notifications, and so on. Android 3.0 added the <em>system bar</em> for tablet
+devices, which resides at the bottom of the screen to provide system navigation controls (Home,
+Back, and so forth) and also an interface for elements traditionally provided by the status bar. In
+Android 4.0, the system provides a new type of system UI called the <em>navigation bar</em>. You
+might consider the navigation bar a re-tuned version of the system bar designed for
+handsets—it provides navigation controls
+for devices that don’t have hardware counterparts for navigating the system, but it leaves out the
+system bar's notification UI and setting controls. As such, a device that provides the navigation
+bar also has the status bar at the top.</p>
+
+<p>To this day, you can hide the status bar on handsets using the {@link
+android.view.WindowManager.LayoutParams#FLAG_FULLSCREEN} flag. In Android 4.0, the APIs that control
+the system bar’s visibility have been updated to better reflect the behavior of both the system bar
+and navigation bar:</p>
+<ul>
+<li>The {@link android.view.View#SYSTEM_UI_FLAG_LOW_PROFILE} flag replaces the {@code
+STATUS_BAR_HIDDEN} flag. When set, this flag enables “low profile" mode for the system bar or
+navigation bar. Navigation buttons dim and other elements in the system bar also hide. Enabling
+this is useful for creating more immersive games without distraction for the system navigation
+buttons.</li>
+
+<li>The {@link android.view.View#SYSTEM_UI_FLAG_VISIBLE} flag replaces the {@code
+STATUS_BAR_VISIBLE} flag to request the system bar or navigation bar be visible.</li>
+
+<li>The {@link android.view.View#SYSTEM_UI_FLAG_HIDE_NAVIGATION} is a new flag that requests
+the navigation bar hide completely. Be aware that this works only for the <em>navigation bar</em>
+used by some handsets (it does <strong>not</strong> hide the system bar on tablets). The navigation
+bar returns to view as soon as the system receives user input. As such, this mode is useful
+primarily for video playback or other cases in which the whole screen is needed but user input is
+not required.</li>
+</ul>
+
+<p>You can set each of these flags for the system bar and navigation bar by calling {@link
+android.view.View#setSystemUiVisibility setSystemUiVisibility()} on any view in your activity. The
+window manager combines (OR-together) all flags from all views in your window and
+apply them to the system UI as long as your window has input focus. When your window loses input
+focus (the user navigates away from your app, or a dialog appears), your flags cease to have effect.
+Similarly, if you remove those views from the view hierarchy their flags no longer apply.</p>
+
+<p>To synchronize other events in your activity with visibility changes to the system UI (for
+example, hide the action bar or other UI controls when the system UI hides), you should register a
+{@link android.view.View.OnSystemUiVisibilityChangeListener} to be notified when the visibility
+of the system bar or navigation bar changes.</p>
+
+<p>See the <a
+href="{@docRoot}resources/samples/ApiDemos/src/com/example/android/apis/view/OverscanActivity.html">
+OverscanActivity</a> class for a demonstration of different system UI options.</p>
+
+
+
+
+
+<h3 id="Input">Input Framework</h3>
+
+<p>Android 4.0 adds support for cursor hover events and new stylus and mouse button events.</p>
+
<h4>Hover events</h4>
<p>The {@link android.view.View} class now supports “hover" events to enable richer interactions
</ul>
+<div class="special" style="margin-top:3em">
+<p>For a detailed view of all API changes in Android {@sdkPlatformVersion} (API Level
+{@sdkPlatformApiLevel}), see the <a
+href="{@docRoot}sdk/api_diff/{@sdkPlatformApiLevel}/changes.html">API Differences Report</a>.</p>
+</div>
+
<h2 id="Honeycomb">Previous APIs</h2>
<p>In addition to everything above, Android 4.0 naturally supports all APIs from previous releases.
-Because the Android 3.x (Honeycomb) platform is available only for large-screen devices, if you've
+Because the Android 3.x platform is available only for large-screen devices, if you've
been developing primarily for handsets, then you might not be aware of all the APIs added to Android
in these recent releases.</p>
the activity window. It includes the application logo in the left corner and provides a new
interface for menu items. See the
<a href="{@docRoot}guide/topics/ui/actionbar.html">Action Bar</a> developer guide.</li>
- <li>{@link android.content.Loader}: A framework component that facilitates asynchronour
+ <li>{@link android.content.Loader}: A framework component that facilitates asynchronous
loading of data in combination with UI components to dynamically load data without blocking the
main thread. See the
<a href="{@docRoot}guide/topics/fundamentals/loaders.html">Loaders</a> developer guide.</li>
-
-
-<h2 id="api-diff">API Differences Report</h2>
-
-<p>For a detailed view of all API changes in Android {@sdkPlatformVersion} (API Level
-{@sdkPlatformApiLevel}), see the <a
-href="{@docRoot}sdk/api_diff/{@sdkPlatformApiLevel}/changes.html">API Differences Report</a>.</p>
-
-
-
<h2 id="api-level">API Level</h2>
<p>The Android {@sdkPlatformVersion} API is assigned an integer
OSDN Git Service
