diff options
Diffstat (limited to 'docs/html')
| -rw-r--r-- | docs/html/community/index.jd | 8 | ||||
| -rw-r--r-- | docs/html/guide/guide_toc.cs | 4 | ||||
| -rw-r--r-- | docs/html/guide/topics/appwidgets/index.jd | 487 | ||||
| -rw-r--r-- | docs/html/images/appwidget.png | bin | 0 -> 17414 bytes | |||
| -rw-r--r-- | docs/html/sdk/ndk/1.5-r1/index.jd | 311 | ||||
| -rw-r--r-- | docs/html/sdk/sdk_toc.cs | 6 |
6 files changed, 725 insertions, 91 deletions
diff --git a/docs/html/community/index.jd b/docs/html/community/index.jd index ab1599a..91c54aa 100644 --- a/docs/html/community/index.jd +++ b/docs/html/community/index.jd @@ -74,6 +74,14 @@ phrasing your questions, read <a href="http://www.catb.org/%7Eesr/faqs/smart-que </ul> </li> +<li><b>Android ndk</b> - A place for discussing the Android NDK and topics related to using native code in Android applications. +<ul> +<li>Subscribe using Google Groups: <a href="http://groups.google.com/group/android-ndk">android-ndk</a></li> +<li>Subscribe via email: <a href="mailto:android-ndk-subscribe@googlegroups.com">android-ndk-subscribe@googlegroups.com</a><a href="mailto:android-platform-subscribe@googlegroups.com"> + </a></li> +</ul> +</li> + <li><b>Android security discuss</b> - A place for open discussion on secure development, emerging security concerns, and best practices for and by android developers. Please don't disclose vulnerabilities directly on this list, you'd be putting all Android users at risk. <ul> <li>Subscribe using Google Groups: <a href="http://groups.google.com/group/android-security-discuss">android-security-discuss</a></li> diff --git a/docs/html/guide/guide_toc.cs b/docs/html/guide/guide_toc.cs index 5367cb2..a044cea 100644 --- a/docs/html/guide/guide_toc.cs +++ b/docs/html/guide/guide_toc.cs @@ -95,7 +95,7 @@ </ul> </li> --> <!-- <li><a style="color:gray;">Localization</a></li> --> - <li><a href="<?cs var:toroot ?>guide/topics/appwidgets/index.html">AppWidgets</a></li> + <li><a href="<?cs var:toroot ?>guide/topics/appwidgets/index.html">App Widgets</a></li> </ul> </li> @@ -146,7 +146,7 @@ <li class="toggle-list"> <div><a href="<?cs var:toroot ?>guide/practices/ui_guidelines/index.html">UI Guidelines</a></div> <ul> - <li><a href="<?cs var:toroot ?>guide/practices/ui_guidelines/widget_design.html">Widget Design</a></li> + <li><a href="<?cs var:toroot ?>guide/practices/ui_guidelines/widget_design.html">App Widget Design</a></li> </ul> </li> <li><a href="<?cs var:toroot ?>guide/practices/design/performance.html">Designing for Performance</a></li> diff --git a/docs/html/guide/topics/appwidgets/index.jd b/docs/html/guide/topics/appwidgets/index.jd index f9db356..01a9648 100644 --- a/docs/html/guide/topics/appwidgets/index.jd +++ b/docs/html/guide/topics/appwidgets/index.jd @@ -1,4 +1,4 @@ -page.title=AppWidgets +page.title=App Widgets @jd:body <div id="qv-wrapper"> @@ -6,131 +6,338 @@ page.title=AppWidgets <h2>Key classes</h2> <ol> <li>{@link android.appwidget.AppWidgetProvider}</li> - <li>{@link android.appwidget.AppWidgetHost}</li> + <li>{@link android.appwidget.AppWidgetProviderInfo}</li> + <li>{@link android.appwidget.AppWidgetManager}</li> </ol> <h2>In this document</h2> <ol> - <li><a href="#Providers">AppWidget Providers</a> + <li><a href="#Basics">The Basics</a></li> + <li><a href="#Manifest">Declaring an App Widget in the Manifest</a></li> + <li><a href="#MetaData">Adding the AppWidgetProviderInfo Metadata</a></li> + <li><a href="#CreatingLayout">Creating the App Widget Layout</a></li> + <li><a href="#AppWidgetProvider">Using the AppWidgetProvider Class</a> <ol> - <li><a href="#provider_manifest">Declaring a widget in the AndroidManifest</a></li> - <li><a href="#provider_meta_data">Adding the AppWidgetProviderInfo meta-data</a></li> - <li><a href="#provider_AppWidgetProvider">Using the AppWidgetProvider class</a></li> - <li><a href="#provider_configuration">AppWidget Configuration UI</a></li> - <li><a href="#provider_broadcasts">AppWidget Broadcast Intents</a></li> + <li><a href="#ProviderBroadcasts">Receiving App Widget broadcast Intents</a></li> + </ol> + </li> + <li><a href="#Configuring">Creating an App Widget Configuration Activity</a> + <ol> + <li><a href="#UpdatingFromTheConfiguration">Updating the App Widget from + the configuration Activity</a></li> </ol> </li> - <li><a href="#Hosts">AppWidget Hosts</a></li> </ol> <h2>See also</h2> <ol> + <li><a href="{@docRoot}guide/practices/ui_guidelines/widget_design.html">App Widget Design + Guidelines</a></li> <li><a href="http://android-developers.blogspot.com/2009/04/introducing-home-screen-widgets-and.html">Introducing - home screen widgets and the AppWidget framework »</a></li> + home screen widgets and the AppWidget framework »</a></li> </ol> </div> </div> -<p>AppWidgets are miniature application views that can be embedded in other applications -(e.g., the Home). These views are called "widgets" and you can publish one with -an "AppWidget provider." An application component that is able to hold other widgets is -called an "AppWidget host."</p> +<p>App Widgets are miniature application views that can be embedded in other applications +(such as the Home screen) and receive periodic updates. These views are referred +to as Widgets in the user interface, +and you can publish one with an App Widget provider. An application component that is +able to hold other App Widgets is called an App Widget host. The screenshot below shows +the Music App Widget.</p> +<img src="{@docRoot}images/appwidget.png" alt="" /> +<p>This document describes how to publish an App Widget using an App Widget provider.</p> -<h2 id="Providers">AppWidget Providers</h2> -<p>Any application can publish widgets. All an application needs to do to publish a widget is -to have a {@link android.content.BroadcastReceiver} that receives the {@link -android.appwidget.AppWidgetManager#ACTION_APPWIDGET_UPDATE AppWidgetManager.ACTION_APPWIDGET_UPDATE} intent, -and provide some meta-data about the widget. Android provides the -{@link android.appwidget.AppWidgetProvider} class, which extends BroadcastReceiver, as a convenience -class to aid in handling the broadcasts. +<h2 id="Basics">The Basics</h2> -<h3 id="provider_manifest">Declaring a widget in the AndroidManifest</h3> +<p>To create an App Widget, you need the following:</p> -<p>First, declare the {@link android.content.BroadcastReceiver} in your application's -<code>AndroidManifest.xml</code> file. +<dl> + <dt>{@link android.appwidget.AppWidgetProviderInfo} object</dt> + <dd>Describes the metadata for an App Widget, such as the App Widget's layout, update frequency, + and the AppWidgetProvider class. This should be defined in XML.</dd> + <dt>{@link android.appwidget.AppWidgetProvider} class implementation</dt> + <dd>Defines the basic methods that allow you to programmatically interface with the App Widget, + based on broadcast events. Through it, you will receive broadcasts when the App Widget is updated, + enabled, disabled and deleted.</dd> + <dt>View layout</dt> + <dd>Defines the initial layout for the App Widget, defined in XML.</dd> +</dl> -{@sample frameworks/base/tests/appwidgets/AppWidgetHostTest/AndroidManifest.xml AppWidgetProvider} +<p>Additionally, you can implement an App Widget configuration Activity. This is an optional +{@link android.app.Activity} that launches when the user adds your App Widget and allows him or her +to modify App Widget settings at create-time.</p> -<p> -The <code><receiver></code> element has the following attributes: -<ul> - <li><code>android:name</code> - specifies the - {@link android.content.BroadcastReceiver} or {@link android.appwidget.AppWidgetProvider} - class.</li> - <li><code>android:label</code> - specifies the string resource that - will be shown by the widget picker as the label.</li> - <li><code>android:icon</code> - specifies the drawable resource that - will be shown by the widget picker as the icon.</li> -</ul> +<p>The following sections describe how to setup each of these components.</p> + + +<h2 id="Manifest">Declaring an App Widget in the Manifest</h2> + +<p>First, declare the {@link android.appwidget.AppWidgetProvider} class in your application's +<code>AndroidManifest.xml</code> file. For example:</p> -<p> -The <code><intent-filter></code> element tells the {@link android.content.pm.PackageManager} -that this {@link android.content.BroadcastReceiver} receives the {@link -android.appwidget.AppWidgetManager#ACTION_APPWIDGET_UPDATE AppWidgetManager.ACTION_APPWIDGET_UPDATE} broadcast. -The widget manager will send other broadcasts directly to your widget provider as required. -It is only necessary to explicitly declare that you accept the {@link -android.appwidget.AppWidgetManager#ACTION_APPWIDGET_UPDATE AppWidgetManager.ACTION_APPWIDGET_UPDATE} broadcast. - -<p> -The <code><meta-data></code> element tells the widget manager which xml resource to -read to find the {@link android.appwidget.AppWidgetProviderInfo} for your widget provider. It has the following -attributes: +<pre> +<receiver android:name="ExampleAppWidgetProvider" > + <intent-filter> + <action android:name="android.appwidget.action.APPWIDGET_UPDATE" /> + </intent-filter> + <meta-data android:name="android.appwidget.provider" + android:resource="@xml/example_appwidget_info" /> +</receiver> +</pre> + +<p>The <code><receiver></code> element requires the <code>android:name</code> +attribute, which specifies the {@link android.appwidget.AppWidgetProvider} used +by the App Widget.</p> + +<p>The <code><intent-filter></code> element must include an <code><action></code> +element with the <code>android:name</code> attribute. This attribute specifies +that the {@link android.appwidget.AppWidgetProvider} accepts the {@link +android.appwidget.AppWidgetManager#ACTION_APPWIDGET_UPDATE ACTION_APPWIDGET_UPDATE} broadcast. +This is the only broadcast that you must explicitly declare. The {@link android.appwidget.AppWidgetManager} +automatically sends all other App Widget broadcasts to the AppWidgetProvider as necessary.</p> + +<p>The <code><meta-data></code> element specifies the +{@link android.appwidget.AppWidgetProviderInfo} resource and requires the +following attributes:</p> <ul> - <li><code>android:name="android.appwidget.provider"</code> - identifies this meta-data - as the {@link android.appwidget.AppWidgetProviderInfo} descriptor.</li> - <li><code>android:resource</code> - is the xml resource to use as that descriptor.</li> + <li><code>android:name</code> - Specifies the metadata name. Use <code>android.appwidget.provider</code> + to identify the data as the {@link android.appwidget.AppWidgetProviderInfo} descriptor.</li> + <li><code>android:resource</code> - Specifies the {@link android.appwidget.AppWidgetProviderInfo} + resource location.</li> </ul> -<h3 id="provider_meta_data">Adding the AppWidgetProviderInfo meta-data</h3> +<h2 id="MetaData">Adding the AppWidgetProviderInfo Metadata</h2> -<p>For a widget, the values in the {@link android.appwidget.AppWidgetProviderInfo} structure are supplied -in an XML resource. In the example above, the xml resource is referenced with -<code>android:resource="@xml/appwidget_info"</code>. That XML file would go in your application's -directory at <code>res/xml/appwidget_info.xml</code>. Here is a simple example. +<p>The {@link android.appwidget.AppWidgetProviderInfo} defines the essential +qualities of an App Widget, such as its minimum layout dimensions, its initial layout resource, +how often to update the App Widget, and (optionally) a configuration Activity to launch at create-time. +Define the AppWidgetProviderInfo object in an XML resource using a single +<code><appwidget-provider></code> element and save it in the project's <code>res/xml/</code> +folder.</p> -{@sample frameworks/base/tests/appwidgets/AppWidgetHostTest/res/xml/appwidget_info.xml AppWidgetProviderInfo} +<p>For example:</p> -<p>The attributes are as documented in the -{@link android.appwidget.AppWidgetProviderInfo} class. +<pre> +<appwidget-provider xmlns:android="http://schemas.android.com/apk/res/android" + android:minWidth="294dp" <!-- density-independent pixels --> + android:minHeight="72dp" + android:updatePeriodMillis="86400000" <!-- once per day --> + android:initialLayout="@layout/example_appwidget" + android:configure="com.example.android.ExampleAppWidgetConfigure" > +</appwidget-provider> +</pre> +<p>Here's a summary of the <code><appwidget-provider></code> attributes:</p> +<ul> + <li>The values for the <code>minWidth</code> and <code>minHeight</code> attributes specify the minimum + area required by the App Widget's layout. + <p>The default Home screen positions App Widgets in its window based on a grid of + cells that have a defined height and width. If the values for an App Widget's minimum width + or height don't match the dimensions of the cells, + then the App Widget dimensions round <em>up</em> to the nearest cell size. + (See the <a href="{@docRoot}guide/practices/ui_guidelines/widget_design.html">App Widget Design + Guidelines</a> for more information on the Home screen cell sizes.)</p> + <p>Because the Home screen's layout orientation (and thus, the cell sizes) can change, + as a rule of thumb, you should assume the worst-case cell size of 74 pixels for the height + <em>and</em> width of a cell. However, you must subtract 2 from the final dimension to account + for any integer rounding errors that occur in the pixel count. To find your minimum width + and height in density-independent pixels (dp), use this formula:<br/> + <code>(number of cells * 74) - 2</code><br/> + Following this formula, you should use 72 dp for a height of one cell, 294 dp and for a width of four cells.</p> + </li> + <li>The <code>updatePerdiodMillis</code> attribute defines how often the App Widget framework should + request an update from the {@link android.appwidget.AppWidgetProvider} by calling the + {@link android.appwidget.AppWidgetProvider#onUpdate(Context,AppWidgetManager,int[]) + onUpdate()} method. The actual update is not guaranteed to occur exactly on time with this value + and we suggest updating as infrequently as possible—perhaps no more than once an hour to + conserve the battery. You might also allow the user to adjust the frequency in a + configuration—some people might want a stock ticker to update every 15 minutes, or maybe + only four times a day.</li> + <li>The <code>initialLayout</code> attribute points to the layout resource that defines the + App Widget layout.</li> + <li>The <code>configure</code> attribute defines the {@link android.app.Activity} to launch when + the user adds the App Widget, in order for him or her to configure App Widget properties. This is optional + (read <a href="#Configuring">Creating an App Widget Configuration Activity</a> below).</li> +</ul> -<h3 id="provider_AppWidgetProvider">Using the AppWidgetProvider class</h3> +<p>See the {@link android.appwidget.AppWidgetProviderInfo} class for more information on the +attributes accepted by the <code><appwidget-provider></code> element.</p> -<p>The AppWidgetProvider class is the easiest way to handle the widget provider intent broadcasts. -See the <code>src/com/example/android/apis/appwidget/ExampleAppWidgetProvider.java</code> -sample class in ApiDemos for an example. -<p class="note">Keep in mind that since the the AppWidgetProvider is a BroadcastReceiver, -your process is not guaranteed to keep running after the callback methods return. See -<a href="../../../guide/topics/fundamentals.html#broadlife">Application Fundamentals > -Broadcast Receiver Lifecycle</a> for more information. +<h2 id="CreatingLayout">Creating the App Widget Layout</h2> +<p>You must define an initial layout for your App Widget in XML and save it in the project's +<code>res/layout/</code> directory. You can design your App Widget using the View objects listed +below, but before you begin designing your App Widget, please read and understand the +<a href="{@docRoot}guide/practices/ui_guidelines/widget_design.html">App Widget Design +Guidelines</a>.</p> +<p>Creating the App Widget layout is simple if you're +familiar with <a href="{@docRoot}guide/topics/ui/declaring-layout.html">Declaring Layout in XML</a>. +However, you must be aware that App Widget layouts are based on {@link android.widget.RemoteViews}, +which do not support every kind of layout or view widget.</p> -<h3 id="provider_configuration">AppWidget Configuration UI</h3> +<p>A RemoteViews object (and, consequently, an App Widget) can support the +following layout classes:</p> -<p> -Widget hosts have the ability to start a configuration activity when a widget is instantiated. -The activity should be declared as normal in AndroidManifest.xml, and it should be listed in -the AppWidgetProviderInfo XML file in the <code>android:configure</code> attribute. +<ul class="nolist"> + <li>{@link android.widget.FrameLayout}</li> + <li>{@link android.widget.LinearLayout}</li> + <li>{@link android.widget.RelativeLayout}</li> +</ul> -<p>The activity you specified will be launched with the {@link -android.appwidget.AppWidgetManager#ACTION_APPWIDGET_CONFIGURE} action. See the documentation for that -action for more info. +<p>And the following widget classes:</p> +<ul class="nolist"> + <li>{@link android.widget.AnalogClock}</li> + <li>{@link android.widget.Button}</li> + <li>{@link android.widget.Chronometer}</li> + <li>{@link android.widget.ImageButton}</li> + <li>{@link android.widget.ImageView}</li> + <li>{@link android.widget.ProgressBar}</li> + <li>{@link android.widget.TextView}</li> +</ul> -<p>See the <code>src/com/example/android/apis/appwidget/ExampleAppWidgetConfigure.java</code> -sample class in ApiDemos for an example. +<p>Descendants of these classes are not supported.</p> +<h2 id="AppWidgetProvider">Using the AppWidgetProvider Class</h2> -<h3 id="provider_broadcasts">AppWidget Broadcast Intents</h3> +<div class="sidebox-wrapper"> + <div class="sidebox-inner"> + <p>You must declare your AppWidgetProvider class implementation as a broadcast receiver + using the <code><receiver></code> element in the AndroidManifest (see + <a href="#Manifest">Declaring an App Widget in the Manifest</a> above).</p> + </div> +</div> + +<p>The {@link android.appwidget.AppWidgetProvider} class extends BroadcastReceiver as a convenience +class to handle the App Widget broadcasts. The AppWidgetProvider receives only the event broadcasts that +are relevant to the App Widget, such as when the App Widget is updated, deleted, enabled, and disabled. +When these broadcast events occur, the AppWidgetProvider receives the following method calls:</p> + +<dl> + <dt>{@link android.appwidget.AppWidgetProvider#onUpdate(Context,AppWidgetManager,int[])}</dt> + <dd>This is called to update the App Widget at intervals defined by the <code>updatePeriodMillis</code> + attribute in the AppWidgetProviderInfo (see <a href="#MetaData">Adding the + AppWidgetProviderInfo Metadata</a> above). This method is also called + when the user adds the App Widget, so it should perform the essential setup, + such as define event handlers for Views and start a temporary + {@link android.app.Service}, if necessary. However, if you have declared a configuration + Activity, <strong>this method is not called</strong> when the user adds the App Widget, + but is called for the subsequent updates. It is the responsibility of the + configuration Activity to perform the first update when configuration is done. + (See <a href="#Configuring">Creating an App Widget Configuration Activity</a> below.)</dd> + <dt>{@link android.appwidget.AppWidgetProvider#onDeleted(Context,int[])}</dt> + <dd>This is called every time an App Widget is deleted from the App Widget host.</dd> + <dt>{@link android.appwidget.AppWidgetProvider#onEnabled(Context)}</dt> + <dd>This is called when an instance the App Widget is created for the first time. For example, if the user + adds two instances of your App Widget, this is only called the first time. + If you need to open a new database or perform other setup that only needs to occur once + for all App Widget instances, then this is a good place to do it.</dd> + <dt>{@link android.appwidget.AppWidgetProvider#onDisabled(Context)}</dt> + <dd>This is called when the last instance of your App Widget is deleted from the App Widget host. + This is where you should clean up any work done in + {@link android.appwidget.AppWidgetProvider#onEnabled(Context)}, + such as delete a temporary database.</dd> + <dt>{@link android.appwidget.AppWidgetProvider#onReceive(Context,Intent)}</dt> + <dd>This is called for every broadcast and before each of the above callback methods. + You normally don't need to implement this method because the default AppWidgetProvider + implementation filters all App Widget broadcasts and calls the above + methods as appropriate.</dd> +</dl> + +<p class="warning"><strong>Note:</strong> In Android 1.5, there is a known issue in which the +<code>onDeleted()</code> method will not be called when it should be. To work around this issue, +you can implement {@link android.appwidget.AppWidgetProvider#onReceive(Context,Intent) +onReceive()} as described in this +<a href="http://groups.google.com/group/android-developers/msg/e405ca19df2170e2">Group post</a> +to receive the <code>onDeleted()</code> callback. +</p> + +<p>The most important AppWidgetProvider callback is +{@link android.appwidget.AppWidgetProvider#onUpdate(Context,AppWidgetManager,int[]) +onUpdated()} because it is called when each App Widget is added to a host (unless you use +a configuration Activity). If your App Widget accepts any +user interaction events, then you need to register the event handlers in this callback. +If your App Widget doesn't create temporary +files or databases, or perform other work that requires clean-up, then +{@link android.appwidget.AppWidgetProvider#onUpdate(Context,AppWidgetManager,int[]) +onUpdated()} may be the only callback method you need to define. For example, if you want an App Widget +with a button that launches an Activity when clicked, you could use the following +implementation of AppWidgetProvider:</p> + +<pre> +public class ExampleAppWidgetProvider extends AppWidgetProvider { + + public void onUpdate(Context context, AppWidgetManager appWidgetManager, int[] appWidgetIds) { + final int N = appWidgetIds.length; + + // Perform this loop procedure for each App Widget that belongs to this provider + for (int i=0; i<N; i++) { + int appWidgetId = appWidgetIds[i]; + + // Create an Intent to launch ExampleActivity + Intent intent = new Intent(context, ExampleActivity.class); + PendingIntent pendingIntent = PendingIntent.getActivity(context, 0, intent, 0); + + // Get the layout for the App Widget and attach an on-click listener to the button + RemoteViews views = new RemoteViews(context.getPackageName(), R.layout.appwidget_provider_layout); + views.setOnClickPendingIntent(R.id.button, pendingIntent); + + // Tell the AppWidgetManager to perform an update on the current App Widget + appWidgetManager.updateAppWidget(appWidgetId, views); + } + } +} +</pre> + +<p>This AppWidgetProvider defines only the +{@link android.appwidget.AppWidgetProvider#onUpdate(Context,AppWidgetManager,int[]) +onUpdated()} method for the purpose +of defining a {@link android.app.PendingIntent} that launches an {@link android.app.Activity} +and attaching it to the App Widget's button +with {@link android.widget.RemoteViews#setOnClickPendingIntent(int,PendingIntent)}. +Notice that it includes a loop that iterates through each entry in <code>appWidgetIds</code>, which +is an array of IDs that identify each App Widget created by this provider. +In this way, if the user creates more than one instance of the App Widget, then they are +all updated simultaneously. However, only one <code>updatePeriodMillis</code> schedule will be +managed for all instances of the App Widget. For example, if the update schedule is defined +to be every two hours, and a second instance +of the App Widget is added one hour after the first one, then they will both be updated +on the period defined by the first one and the second update period will be ignored +(they'll both be updated every two hours, not every hour).</p> + +<p class="note"><strong>Note:</strong> Because the AppWidgetProvider is a BroadcastReceiver, +your process is not guaranteed to keep running after the callback methods return (see +<a href="{@docRoot}guide/topics/fundamentals.html#broadlife">Application Fundamentals > +Broadcast Receiver Lifecycle</a> for more information). If your App Widget setup process can take several +seconds (perhaps while performing web requests) and you require that your process continues, +consider starting a {@link android.app.Service} +in the {@link android.appwidget.AppWidgetProvider#onUpdate(Context,AppWidgetManager,int[]) +onUpdated()} method. From within the Service, you can perform your own updates to the App Widget +without worrying about the AppWidgetProvider closing down due to an +<a href="{@docRoot}guide/practices/design/responsiveness.html">Application Not Responding</a> +(ANR) error. See the +<a href="http://code.google.com/p/wiktionary-android/source/browse/trunk/Wiktionary/src/com/example/android/wiktionary/WordWidget.java">Wiktionary +sample's AppWidgetProvider</a> for an example of an App Widget running a {@link android.app.Service}.</p> + +<p>Also see the <a +href="{@docRoot}guide/samples/ApiDemos/src/com/example/android/apis/appwidget/ExampleAppWidgetProvider.html"> +ExampleAppWidgetProvider.java</a> sample class.</p> + + +<h3 id="ProviderBroadcasts">Receiving App Widget broadcast Intents</h3> <p>{@link android.appwidget.AppWidgetProvider} is just a convenience class. If you would like -to receive the widget broadcasts directly, you can. The four intents you need to care about are: +to receive the App Widget broadcasts directly, you can implement your own +{@link android.content.BroadcastReceiver} or override the +{@link android.appwidget.AppWidgetProvider#onReceive(Context,Intent)} callback. +The four Intents you need to care about are:</p> <ul> <li>{@link android.appwidget.AppWidgetManager#ACTION_APPWIDGET_UPDATE}</li> <li>{@link android.appwidget.AppWidgetManager#ACTION_APPWIDGET_DELETED}</li> @@ -138,17 +345,119 @@ to receive the widget broadcasts directly, you can. The four intents you need t <li>{@link android.appwidget.AppWidgetManager#ACTION_APPWIDGET_DISABLED}</li> </ul> -<p>By way of example, the implementation of -{@link android.appwidget.AppWidgetProvider#onReceive} is quite simple:</p> -{@sample frameworks/base/core/java/android/appwidget/AppWidgetProvider.java onReceive} + +<h2 id="Configuring">Creating an App Widget Configuration Activity</h2> + +<p>If you would like the user to configure settings when he or she adds a new App Widget, +you can create an App Widget configuration Activity. This {@link android.app.Activity} +will be automatically launched by the App Widget host and allows the user to configure +available settings for the App Widget at create-time, such as the App Widget color, size, +update period or other functionality settings.</p> + +<p>The configuration Activity should be declared as a normal Activity in the Android manifest file. +However, it will be launched by the App Widget host with the {@link +android.appwidget.AppWidgetManager#ACTION_APPWIDGET_CONFIGURE ACTION_APPWIDGET_CONFIGURE} action, +so the Activity needs to accept this Intent. For example:</p> + +<pre> +<activity android:name=".ExampleAppWidgetConfigure"> + <intent-filter> + <action android:name="android.appwidget.action.APPWIDGET_CONFIGURE" /> + </intent-filter> +</activity> +</pre> + +<p>Also, the Activity must be declared in the AppWidgetProviderInfo XML file, with the +<code>android:configure</code> attribute (see <a href="#MetaData">Adding +the AppWidgetProvierInfo Metadata</a> above). For example, the configuration Activity +can be declared like this:</p> + +<pre> +<appwidget-provider xmlns:android="http://schemas.android.com/apk/res/android" + ... + android:configure="com.example.android.ExampleAppWidgetConfigure" + ... > +</appwidget-provider> +</pre> + +<p>Notice that the Activity is declared with a fully-qualified namespace, because +it will be referenced from outside your package scope.</p> + +<p>That's all you need to get started with a configuration Activity. Now all you need is the actual +Activity. There are, however, two important things to remember when you implement the Activity:</p> +<ul> + <li>The App Widget host calls the configuration Activity and the configuration Activity should always + return a result. The result should include the App Widget ID + passed by the Intent that launched the Activity (saved in the Intent extras as + {@link android.appwidget.AppWidgetManager#EXTRA_APPWIDGET_ID}).</li> + <li>The {@link android.appwidget.AppWidgetProvider#onUpdate(Context,AppWidgetManager,int[]) + onUpdate()} method <strong>will not be called</strong> when the App Widget is created + (the system will not send the ACTION_APPWIDGET_UPDATE broadcast when a configuration Activity + is launched). It is the responsibility of the configuration Activity to request an update from the + AppWidgetManager when the App Widget is first created. However, + {@link android.appwidget.AppWidgetProvider#onUpdate(Context,AppWidgetManager,int[]) + onUpdate()} will be called for subsequent updates—it is only skipped the first time.</li> +</ul> + +<p>See the code snippets in the following section for an example of how to return a result +from the configuration and update the App Widget.</p> + + +<h3 id="UpdatingFromTheConfiguration">Updating the App Widget from the configuration Activity</h3> + +<p>When an App Widget uses a configuration Activity, it is the responsibility of the Activity +to update the App Widget when configuration is complete. +You can do so by requesting an update directly from the +{@link android.appwidget.AppWidgetManager}.</p> + +<p>Here's a summary of the procedure to properly update the App Widget and close +the configuration Activity:</p> + +<ol> + <li>First, get the App Widget ID from the Intent that launched the Activity: +<pre> +Intent intent = getIntent(); +Bundle extras = intent.getExtras(); +if (extras != null) { + mAppWidgetId = extras.getInt( + AppWidgetManager.EXTRA_APPWIDGET_ID, + AppWidgetManager.INVALID_APPWIDGET_ID); +} +</pre> + </li> + <li>Perform your App Widget configuration.</li> + <li>When the configuration is complete, get an instance of the AppWidgetManager by calling + {@link android.appwidget.AppWidgetManager#getInstance(Context)}: +<pre> +AppWidgetManager appWidgetManager = AppWidgetManager.getInstance(context); +</pre> + </li> + <li>Update the App Widget with a {@link android.widget.RemoteViews} layout by calling + {@link android.appwidget.AppWidgetManager#updateAppWidget(int,RemoteViews)}: +<pre> +RemoteViews views = new RemoteViews(context.getPackageName(), R.layout.example_appwidget); +appWidgetManager.updateAppWidget(mAppWidgetId, views); +</pre> + </li> + <li>Finally, create the return Intent, set it with the Activity result, and finish the Activity:</li> +<pre> +Intent resultValue = new Intent(); +resultValue.putExtra(AppWidgetManager.EXTRA_APPWIDGET_ID, mAppWidgetId); +setResult(RESULT_OK, resultValue); +finish(); +</pre> + </li> +</ol> + +<p class="note"><strong>Tip:</strong> When your configuration Activity first opens, set +the Activity result to RESULT_CANCELED. This way, if the user backs-out of the Activity before +reaching the end, the App Widget host is notified that the configuration was cancelled and the +App Widget will not be added.</p> + +<p>See the <a +href="{@docRoot}guide/samples/ApiDemos/src/com/example/android/apis/appwidget/ExampleAppWidgetConfigure.html"> +ExampleAppWidgetConfigure.java</a> sample class in ApiDemos for an example.</p> -<h2 id="Hosts">AppWidget Hosts</h2> -<p>Widget hosts are the containers in which widgets can be placed. Most of the look and feel -details are left up to the widget hosts. For example, the home screen has one way of viewing -widgets, but the lock screen could also contain widgets, and it would have a different way of -adding, removing and otherwise managing widgets.</p> -<p>For more information on implementing your own widget host, see the -{@link android.appwidget.AppWidgetHost AppWidgetHost} class.</p> diff --git a/docs/html/images/appwidget.png b/docs/html/images/appwidget.png Binary files differnew file mode 100644 index 0000000..b72b80b --- /dev/null +++ b/docs/html/images/appwidget.png diff --git a/docs/html/sdk/ndk/1.5-r1/index.jd b/docs/html/sdk/ndk/1.5-r1/index.jd new file mode 100644 index 0000000..3d3137c --- /dev/null +++ b/docs/html/sdk/ndk/1.5-r1/index.jd @@ -0,0 +1,311 @@ +ndk=true +ndk.version=1.5 +ndk.rel.id=1 +ndk.date=May 2009 + +ndk.win_download=android-ndk-1.5_r1-windows.zip +ndk.win_bytes=22450814 +ndk.win_checksum=7b7836f705ec7e66225794edda34000f + +ndk.mac_download=android-ndk-1.5_r1-darwin-x86.zip +ndk.mac_bytes=17165450 +ndk.mac_checksum=214ccfd704c0307609fbabeb7bf86acc + +ndk.linux_download=android-ndk-1.5_r1-linux-x86.zip +ndk.linux_bytes=15976032 +ndk.linux_checksum=808fd4d6a7e45f76d546ba04ab9ef060 + +ndk.linux_64_download=android-ndk-1.5_r1-linux-x86_64.zip +ndk.linux_64_bytes=18112300 +ndk.linux_64_checksum=f8664c187b3ae077bcfe2b44294d0758 + +page.title=Android 1.5 NDK, Release 1 +@jd:body + +<h2>What is the NDK?</h2> + +<p>The Android 1.5 NDK provides tools that allow Android application developers +to embed and deploy native code within their Android applications. It +provides:</p> + +<ul> +<li>A set of tools and build files used to generate native code libraries from C +and C++ sources</li> +<li>A way to embed the corresponding native libraries into application package +files (.apks) that can be deployed on Android devices</li> +<li>A set of native system headers and libraries that will be supported in all +future versions of the Android platform, starting from Android 1.5 </li> +</ul> + +<p>This release of the NDK release supports the ARMv5TE machine instruction set +and provides stable headers for libc (the C library), libm (the Math library) +and the JNI interface.</p> + +<p>Using the NDK may not be relevant for all Android applications. As a +developer, you will need to balance its benefits (faster execution) and its +drawbacks (no portability, JNI overhead, no access to system libraries, and +difficult debugging). Typical good candidates for the NDK are CPU-intensive +operations that don't allocate too much memory, such as signal processing, +physics simulation, custom bytecode/instruction interpreters, and so on.</p> + +<p>Please note that the NDK <em>does not</em> enable you to develop native-only +applications. Android's primary runtime remains the Dalvik virtual machine.</p> + +<h2 id="contents">Contents of the NDK</h2> + +<h4>Development tools</h4> + +<p>The NDK includes a set of cross-toolchains (compilers, linkers, etc..) that +can generate native ARM binaries on Linux, OS X, and Windows (with Cygwin) +platforms.</p> + +<p>It provides a set of system headers for stable native APIs that are +guaranteed to be supported in all later releases of the platform:</p> + +<ul> +<li>libc (C library) headers</li> +<li>libm (Math library) headers</li> +<li>JNI interface headers</li> +</ul> + +<p>The NDK also provides a build system that lets you work efficiently with your +sources, without having to handle the toolchain/platform/CPU/ABI details. You +create very short build files to describe which sources to compile and which +Android application will use them — the build system compiles the sources +and places the shared libraries directly in your application project. </p> + +<p class="caution"><strong>Important:</strong> With the exception of the +libraries listed above, native system libraries in the Android 1.5 platform are +<em>not</em> stable and may change in future platform versions. +Your applications should <em>only</em> make use of the stable native system +libraries provided in this NDK. </p> + +<h4>Documentation</h4> + +<p>The NDK package includes a set of documentation that describes the +capabilities of the NDK and how to use it to create shared libraries for your +Android applications. In this release, the documentation is provided only in the +downloadable NDK package. You can find the documentation in the +<code><ndk>/docs/</code> directory. Included are these files:</p> + +<ul> +<li>INSTALL.TXT — describes how to install the NDK and configure it for +your host system</li> +<li>OVERVIEW.TXT — provides an overview of the NDK capabilities and +usage</li> +<li>ANDROID-MK.TXT — describes the use of the Android.mk file, which +defines the native sources you want to compile</li> +<li>APPLICATION-MK.TXT — describes the use of the Application.mk file, +which describes the native sources required by your Android application</li> +</ul> + +<h4>Sample applications</h4> + +<p>The NDK includes two sample Android applications that illustrate how to use +native code in your Android applications:</p> + +<ul> +<li><code>hello-jni</code> — A simple application that loads a string from +a native method implemented in a shared library and then displays it in the +application UI. </li> +<li><code>two-libs</code> — A simple application that loads a shared +library dynamically and calls a native method provided by the library. In this +case, the method is implemented in a static library that is imported by the +shared library. </li> +</ul> + +<p>For more information, see <a href="#samples">Using the Sample +Applications</a>.</p> + +<h2 id="requirements">System and Software Requirements</h2> + +<p>The sections below describe the system and software requirements for using +the Android NDK, as well as platform compatibility considerations that affect +appplications using libraries produced with the NDK. </p> + +<h4>The Android SDK</h4> +<ul> + <li>A complete Android SDK installation (including all dependencies) is +required.</li> + <li>Android 1.5 SDK or later version is required.</li> +</ul> + +<h4>Supported operating systems</h4> +<ul> + <li>Windows XP (32-bit) or Vista (32- or 64-bit)</li> + <li>Mac OS X 10.4.8 or later (x86 only)</li> + <li>Linux (32- or 64-bit, tested on Linux Ubuntu Dapper Drake)</li> +</ul> + +<h4>Required development tools</h4> +<ul> + <li>For all development platforms, GNU Make 3.81 or later is required. Earlier +versions of GNU Make might work but have not been tested.</li> + <li>For Windows, a recent release of <a +href="http://www.cygwin.com">Cygwin</a> is required.</li> +</ul> + +<h4>Android platform compatibility</h4> +<ul> + <li>The native libraries created by the Android NDK can only be used on +devices running the Android 1.5 platform version or later. This is due to subtle +toolchain and ABI related changes that make the native libraries incompatible +with 1.0 and 1.1 system images.</li> + <li>For this reason, you should use native libraries produced with the NDK in +applications that are deployable to devices running the Android 1.5 platform +version or later. To ensure compatibility, an application using a native library +produced with the NDK must declare a <code><uses-library></code> element +in its manifest file, with the attribute +<code>android:minSdkVersion="3"</code>.</li> +</ul> + +<h2 id="installing">Installing the NDK</h2> + +<p>Installing the NDK on your development computer is straightforward and +involves extracting the NDK from its download package and running a host-setup +script. </p> + +<p>Before you get started make sure that you have downloaded the latest <a +href="{@docRoot}sdk/index.html">Android SDK</a> and upgraded your applications +and environment as needed. The NDK will not work with older versions of the +Android SDK. Also, take a moment to review the <a href="#requirements">System +and Software Requirements</a> for the NDK, if you haven't already. </p> + +<p>To install the NDK, follow these steps:</p> + +<ol> +<li>From the table at the top of this page, select the NDK package that is +appropriate for your development computer and download the package.</li> +<li>Uncompress the NDK download package using tools available on your computer. +When uncompressed, the NDK files are contained in a directory called +<code>android-ndk-<version></code>. You can rename the NDK directory if +necessary and you can move it to any location on your computer. This +documentation refers to the NDK directory as <code><ndk></code>. </li> +<li>Open a terminal, change to the NDK directory, and run the host-setup script. +The script sets up your environment and generates a host configuration file used +later, when building your shared libraries. The path to the host-setup script +is: + +<p><code><ndk>/build/host-setup.sh</code></p> + +<p>If the script completes successfully, it prints a "Host setup complete." +message. If it fails, it prints instructions that you can follow to correct any +problems. </p> +</li> +</ol> + +<p>Once you have run the host-setup script, you are ready start working with the +NDK. </p> + +<h2 id="gettingstarted">Getting Started with the NDK</h2> + +<p>Once you've installed the NDK successfully, take a few minutes to read the +documentation included in the NDK. You can find the documentation in the +<code><ndk>/docs/</code> directory. In particular, please read the +OVERVIEW.TXT document completely, so that you understand the intent of the NDK +and how to use it.</p> + +<p>Here's the general outline of how you work with the NDK tools:</p> + +<ol> +<li>Place your native sources under +<code><ndk>/sources/<my_src>/...</code>. If you want, you can place +a symlink to your sources, rather than the sources themselves. The sources you +reference here are not strictly associated with a specific shared library or +Android application. Instead, they are accessible to any build configuration and +can be used to produce any number of shared libraries that can be used by any +Android application.</li> +<li>Create <code><ndk>/sources/<my_src>/Android.mk</code> to +describe your native sources to the NDK build system</li> +<li>Create <code><ndk>/apps/<my_app>/Application.mk</code> to +describe your Android application and native sources it needs to the NDK build +system. This file sets up the link between an Android SDK application project +and any number of shared libraries defined in the +<code><ndk>/sources/</code> folder and it specifies the path to the +application project that will receive the shared library built from the +sources.</li> +<li>Build your native code by running this make command from the top-level NDK +directory: + +<p><code>$ make APP=<my_app></code></p> + +<p>The build tools copy the stripped, shared libraries needed by your +application to the proper location in the application's project directory.</p> +</li> + +<li>Finally, compile your application using the SDK tools in the usual way. The +SDK build tools will package the shared libraries in the application's +deployable .apk file. </p></li> + +</ol> + +<p>For complete information on all of the steps listed above, please see the +documentation included with the NDK package. </p> + + +<h2 id="samples">Using the Sample Applications</h2> + +<p>The NDK includes two sample applications that illustrate how to use native +code in your Android applications:</p> + +<ul> +<li><code>hello-jni</code> — A simple application that loads a string from +a native method implemented in a shared library and then displays it in the +application UI. </li> +<li><code>two-libs</code> — A simple application that loads a shared +library dynamically and calls a native method provided by the library. In this +case, the method is implemented in a static library imported by the shared +library. </li> +</ul> + +<p>For each sample, the NDK includes an Android application project, as well as +the corresponding C source code and the necessary Android.mk and Application.mk +files. The application projects are provided in +<code><ndk>/apps/<app_name>/project/</code> and the C source for +each application is provided in +<code><ndk>/sources/samples/<library>/</code>.</p> + +<p>Once you have installed the NDK, you can build the shared libraries from the +NDK by using these commands from the root of the NDK directory:</p> +<ul> +<li><code>$ make APP=hello-jni</code> — compiles +<code><ndk>/sources/samples/hello-jni/hello-jni.c</code> and outputs a +shared library to +<code><ndk>/apps/hello-jni/project/libs/armeabi/libhello-jni.so</code>. +</li> +<li><code>$ make APP=two-libs</code> — compiles +<code><ndk>/sources/samples/two-libs/second.c</code> and +<code>first.c</code> and outputs a shared library to +<code><ndk>/apps/two-libs/project/libs/armeabi/libtwolib-second.so</code>. +</li> +</ul> + +<p>Next, build the sample Android applications that use the shared +libraries:</p> + +<ul> +<li>If you are developing in Eclipse with ADT, use the New Project Wizard to +create a new Android project for each sample, using the "Import from Existing +Source" option and importing the source from +<code><ndk>/apps/<app_name>/project/</code>. Then, set up an AVD, if +necessary, and build/run the application in the emulator. For more information +about creating a new Android project in Eclipse, see <a +href="{@docRoot}guide/developing/eclipse-adt.html">Developing in +Eclipse</a>.</li> +<li>If you are developing with Ant, use the <code>android</code> tool to create +the build file for each of the sample projects at +<code><ndk>/apps/<app_name>/project/</code>. Then set up an AVD, if +necessary, build your project in the usual way, and run it in the emulator. +For more information, see <a +href="{@docRoot}guide/developing/other-ide.html">Developing in Other +IDEs</a>.</li> +</ul> + +<h2>Discussion Forum and Mailing List</h2> + +<p>If you have questions about the NDK or would like to read or contribute to +discussions about it, please visit the <a +href="http://groups.google.com/group/android-ndk">android-ndk</a> group and +mailing list.</p> + + diff --git a/docs/html/sdk/sdk_toc.cs b/docs/html/sdk/sdk_toc.cs index 1e5122f..4b55b56 100644 --- a/docs/html/sdk/sdk_toc.cs +++ b/docs/html/sdk/sdk_toc.cs @@ -27,6 +27,12 @@ </ul> </li> <li> + <h2>Native Development Tools</h2> + <ul> + <li><a href="<?cs var:toroot ?>sdk/ndk/1.5-r1/index.html">Android 1.5 NDK, r1</a></li> + </ul> + </li> + <li> <h2>Previous SDK Releases</h2> <ul> <li><a href="<?cs var:toroot ?>sdk/1.1_r1/index.html">Android 1.1 SDK, r1</a></li> |
