am 07613835: am e7d60078: Add old blog posts as articles, batch 1
* commit '076138357027189f1bb90caf8c2e1a09497d78ac':
Add old blog posts as articles, batch 1
diff --git a/docs/html/guide/topics/fundamentals/services.jd b/docs/html/guide/topics/fundamentals/services.jd
index a9dd315..468a417 100644
--- a/docs/html/guide/topics/fundamentals/services.jd
+++ b/docs/html/guide/topics/fundamentals/services.jd
@@ -49,6 +49,13 @@
LocalService}</a></li>
</ol>
+<h2>Articles</h2>
+<ol>
+ <li><a href="{@docRoot}resources/articles/multitasking-android-way.html">Multitasking the Android Way</a></li>
+ <li><a href="{@docRoot}resources/articles/service-api-changes-starting-with.html">Service API changes starting
+ with Android 2.0</a></li>
+</ol>
+
<h2>See also</h2>
<ol>
<li><a href="{@docRoot}guide/topics/fundamentals/bound-services.html">Bound Services</a></li>
diff --git a/docs/html/guide/topics/fundamentals/tasks-and-back-stack.jd b/docs/html/guide/topics/fundamentals/tasks-and-back-stack.jd
index cfed742..95ee129 100644
--- a/docs/html/guide/topics/fundamentals/tasks-and-back-stack.jd
+++ b/docs/html/guide/topics/fundamentals/tasks-and-back-stack.jd
@@ -27,6 +27,11 @@
</li>
</ol>
+<h2>Articles</h2>
+<ol>
+ <li><a href="{@docRoot}resources/articles/multitasking-android-way.html">Multitasking the Android Way</a></li>
+</ol>
+
<h2>See also</h2>
<ol>
<li><a><a href="{@docRoot}videos/index.html#v=fL6gSd4ugSI">Application Lifecycle video</a></li>
@@ -566,4 +571,4 @@
respond, continue with the <b><a
href="{@docRoot}guide/topics/intents/intents-filters.html">Intents and Intent
Filters</a></b> document.</p>
--->
\ No newline at end of file
+-->
diff --git a/docs/html/resources/articles/images/service-api-changes-starting-with_runningservices.png b/docs/html/resources/articles/images/service-api-changes-starting-with_runningservices.png
new file mode 100644
index 0000000..e159fff
--- /dev/null
+++ b/docs/html/resources/articles/images/service-api-changes-starting-with_runningservices.png
Binary files differ
diff --git a/docs/html/resources/articles/images/service-api-changes-starting-with_stopservice.png b/docs/html/resources/articles/images/service-api-changes-starting-with_stopservice.png
new file mode 100644
index 0000000..cc8f0a2
--- /dev/null
+++ b/docs/html/resources/articles/images/service-api-changes-starting-with_stopservice.png
Binary files differ
diff --git a/docs/html/resources/articles/multitasking-android-way.jd b/docs/html/resources/articles/multitasking-android-way.jd
new file mode 100644
index 0000000..0dc8627
--- /dev/null
+++ b/docs/html/resources/articles/multitasking-android-way.jd
@@ -0,0 +1,103 @@
+page.title=Multitasking the Android Way
+parent.title=Articles
+parent.link=../browser.html?tag=article
+@jd:body
+
+<div id="qv-wrapper">
+<div id="qv">
+
+ <h2>See also</h2>
+ <ol>
+ <li><a href="{@docRoot}guide/topics/fundamentals/tasks-and-back-stack.html">Tasks and Back Stack</a></li>
+ <li><a href="{@docRoot}guide/topics/fundamentals/services.html">Services</a></li>
+ </ol>
+
+ <h2>Key classes</h2>
+ <ol>
+ <li>{@link android.app.Service}</li>
+ <li>{@link android.content.BroadcastReceiver}</li>
+ </ol>
+
+</div>
+</div>
+
+<p>Android is fairly unique in the ways it allows multiple applications to run at the same time. Developers coming from a different platform may find the way it operates surprising. Understanding its behavior is important for designing applications that will work well and integrate seamlessly with the rest of the Android platform. This article covers the reasons for Android's multitasking design, its impact on how applications work, and how you can best take advantage of Android's unique features.</p>
+<h3>Design considerations</h3>
+<p>Mobile devices have technical limitations and user experience requirements not present in desktop or web systems. Here are the four key constraints we were working under as we designed Android's multitasking:</p>
+<ul>
+ <li>
+ <p>We did not want to require that users close applications when "done" with them. Such a usage pattern does not work well in a mobile environment, where usage tends to involve repeated brief contact with a wide variety of applications throughout the day.</p>
+ </li>
+ <li>
+ <p>Mobile devices don't have the luxury of swap space, so have fairly hard limits on memory use. Robert Love has <a href="http://blog.rlove.org/2010/04/why-ipad-and-iphone-dont-support.html">a very good article</a> covering the topic.</p>
+ </li>
+ <li>
+ <p>Application switching on a mobile device is extremely critical; we target significantly less than 1 second to launch a new application. This is especially important when the user is switching between a few applications, such as switching to look at a new SMS message while watching a video, and then returning to that video. A noticeable wait in such situations will quickly make users hate you.</p>
+ </li>
+ <li>
+ <p>The available APIs must be sufficient for writing the built-in Google applications, as part of our "all applications are created equal" philosophy. This means background music playback, data syncing, GPS navigation, and application downloading must be implemented with the same APIs that are available to third party developers.</p>
+ </li>
+</ul>
+<p>The first two requirements highlight an interesting conflict. We don't want users to worry about closing their apps, but rather make it appear that all of the applications are always running. At the same time, mobile devices have hard limits on memory use, so that a system will degrade or even start failing very quickly as it needs more RAM than is available; a desktop computer, with swap, in contrast will simply start slowing down as it needs to page RAM to its swap space. These competing constraints were a key motivation for Android's design.</p>
+<h3>When does an application "stop"?</h3>
+<p>A common misunderstanding about Android multitasking is the difference between a process and an application. In Android these are not tightly coupled entities: applications may seem present to the user without an actual process currently running the app; multiple applications may share processes, or one application may make use of multiple processes depending on its needs; the process(es) of an application may be kept around by Android even when that application is not actively doing something.</p>
+<p>The fact that you can see an application's process "running" does not mean the application is running or doing anything. It may simply be there because Android needed it at some point, and has decided that it would be best to keep it around in case it needs it again. Likewise, you may leave an application for a little bit and return to it from where you left off, and during that time Android may have needed to get rid of the process for other things.</p>
+<p>A key to how Android handles applications in this way is that processes don't shut down cleanly. When the user leaves an application, its process is kept around in the background, allowing it to continue working (for example downloading web pages) if needed, and come immediately to the foreground if the user returns to it. If a device never runs out of memory, then Android will keep all of these processes around, truly leaving all applications "running" all of the time.</p>
+<p>Of course, there is a limited amount of memory, and to accommodate this Android must decide when to get rid of processes that are not needed. This leads to Android's <a href="{@docRoot}guide/topics/fundamentals.html#proclife">process lifecycle</a>, the rules it uses to decide how important each process is and thus the next one that should be dropped. These rules are based on both how important a process is for the user's current experience, as well as how long it has been since the process was last needed by the user.</p>
+<p>Once Android determines that it needs to remove a process, it does this brutally, simply force-killing it. The kernel can then immediately reclaim all resources needed by the process, without relying on that application being well written and responsive to a polite request to exit. Allowing the kernel to immediately reclaim application resources makes it a lot easier to avoid serious out of memory situations.</p>
+<p>If a user later returns to an application that's been killed, Android needs a way to re-launch it in the same state as it was last seen, to preserve the "all applications are running all of the time" experience. This is done by keeping track of the parts of the application the user is aware of (the Activities), and re-starting them with information about the last state they were seen in. This last state is generated each time the user leaves that part of the application, not when it is killed, so that the kernel can later freely kill it without depending on the application to respond correctly at that point.</p>
+<p>In some ways, Android's process management can be seen as a form of swap space: application processes represent a certain amount of in-use memory; when memory is low, some processes can be killed (swapped out); when those processes are needed again, they can be re-started from their last saved state (swapped in).</p>
+<h3>Explicitly running in the background</h3>
+<p>So far, we have a way for applications to implicitly do work in the background, as long as the process doesn't get killed by Android as part of its regular memory management. This is fine for things like loading web pages in the background, but what about features with harder requirements? Background music playback, data synchronization, location tracking, alarm clocks, etc.</p>
+<p/>
+<p>For these tasks, the application needs a way to tell Android "I would explicitly like to run at this point." There are two main facilities available to applications for this, represented by two kinds of components they can publish in their manifest: <span style="font-style:italic;">broadcast receivers</span> and <span style="font-style:italic;">services</span>.</p>
+<h4>Broadcast Receivers</h4>
+<p>A BroadcastReceiver allows an application to run, for a brief amount of time, in the background as a result of something else happening. It can be used in many ways to build higher-level facilities: for example the AlarmManager allows an application to have a broadcast sent at a certain time in the future, and the LocationManager can send a broadcast when it detects interesting changes in location. Because information about the receiver is part of an application's manifest, Android can find and launch the application even if it isn't running; of course if it already has its process available in the background, the broadcast can very efficiently be directly dispatched to it.</p>
+<p>When handling a broadcast, the application is given a fixed set of time (currently 10 seconds) in which to do its work. If it doesn't complete in that time, the application is considered to be misbehaving, and its process immediately tossed into the background state to be killed for memory if needed.</p>
+<p>Broadcast receivers are great for doing small pieces of work in response to an external stimulus, such as posting a notification to the user after being sent a new GPS location report. They are very lightweight, since the application's process only needs to be around while actively receiving the broadcast. Because they are active for a deterministic amount of time, fairly strong guarantees can be made about not killing their process while running. However they are not appropriate for anything of indeterminate length, such as networking.</p>
+<h4>Services</h4>
+<p>A Service allows an application to implement longer-running background operations. There are actually a lot of other functions that services provide, but for the discussion here their fundamental purpose is for an application to say "hey I would like to continue running even while in the background, until I say I am done." An application controls when its service runs by explicitly starting and stopping the service.</p>
+<p>While services do provide a rich client-server model, its use is optional. Upon starting an application's services, Android simply instantiates the component in the application's process to provide its context. How it is used after that is up to the application: it can put all of the needed code inside of the service itself without interacting with other parts of the application, make calls on other singleton objects shared with other parts of the app, directly retrieve the Service instance from elsewhere if needed, or run it in another process and do a full-blown RPC protocol if that is desired.</p>
+<p>Process management for services is different than broadcast receivers, because an unbounded number of services can ask to be running for an unknown amount of time. There may not be enough RAM to have all of the requesting services run, so as a result no strong guarantees are made about being able to keep them running.</p>
+<p>If there is too little RAM, processes hosting services will be immediately killed like background processes are. However, if appropriate, Android will remember that these services wish to remain running, and restart their process at a later time when more RAM is available. For example, if the user goes to a web page that requires large amounts of RAM, Android may kill background service processes like sync until the browser's memory needs go down.</p>
+<p>Services can further negotiate this behavior by requesting they be considered "foreground." This places the service in a "please don't kill" state, but requires that it include a notification to the user about it actively running. This is useful for services such as background music playback or car navigation, which the user is actively aware of; when you're playing music and using the browser, you can always see the music-playing glyph in the status bar. Android won't try to kill these services, but as a trade-off, ensures the user knows about them and is able to explicitly stop them when desired.</p>
+<h3>The value of generic components</h3>
+<p>Android's generic broadcast receiver and service components allow developers to create a wide variety of efficient background operations, including things that were never originally considered. In Android 1.0 they were used to implement nearly all of the background behavior that the built-in and proprietary Google apps provided:</p>
+<ul>
+ <li>
+ Music playback runs in a service to allow it to continue operating after the user leaves the music application.
+ </li>
+ <li>
+ The alarm clock schedules a broadcast receiver with the alarm manager, to go off at the next set alarm time.
+ </li>
+ <li>
+ The calendar application likewise schedules an alarm to display or update its notification at the appropriate time for the next calendar event.
+ </li>
+ <li>
+ Background file download is implemented a service that runs when there are any downloads to process.
+ </li>
+ <li>
+ The e-mail application schedules an alarm to wake up a service at regular intervals that looks for and retrieves any new mail.
+ </li>
+ <li>
+ The Google applications maintain a service to receive push notifications from the network; it in turn sends broadcasts to individual apps when it is told that they need to do things like synchronize contacts.</p>
+ </li>
+</ul>
+<p>As the platform has evolved, these same basic components have been used to implement many of the major new developer features:
+<ul>
+ <li>
+ Input methods are implemented by developers as a Service component that Android manages and works with to display as the current IME.
+ </li>
+ <li>
+ Application widgets are broadcast receivers that Android sends broadcasts to when it needs to interact with them. This allows app widgets to be quite lightweight, by not needing their application's process remain running.
+ </li>
+ <li>
+ Accessibility features are implemented as services that Android keeps running while in use and sends appropriate information to about user interactions.
+ </li>
+ <li>
+ Sync adapters introduced in Android 2.0 are services that are run in the background when a particular data sync needs to be performed.
+ </li>
+ <li>
+ Live wallpapers are a service started by Android when selected by the user.
+ </li>
+</ul>
diff --git a/docs/html/resources/articles/service-api-changes-starting-with.jd b/docs/html/resources/articles/service-api-changes-starting-with.jd
new file mode 100644
index 0000000..7bafd81
--- /dev/null
+++ b/docs/html/resources/articles/service-api-changes-starting-with.jd
@@ -0,0 +1,177 @@
+page.title=Service API changes starting with Android 2.0
+parent.title=Articles
+parent.link=../browser.html?tag=article
+@jd:body
+
+
+<div id="qv-wrapper">
+<div id="qv">
+
+ <h2>See also</h2>
+ <ol>
+ <li><a href="{@docRoot}guide/topics/fundamentals/services.html">Services</a></li>
+ </ol>
+
+ <h2>Key classes</h2>
+ <ol>
+ <li>{@link android.app.Service}</li>
+ </ol>
+
+</div>
+</div>
+
+<p>Watching developers use the Android platform the last year has shown a number of trouble areas in the Service API as well as growing issues in the ways services operate. As a result, Android 2.0 introduced a number of changes and improvements in this area for both developers and users.</p>
+<p>The three main changes to be aware of are:</p>
+<ul>
+ <li>Service.setForeground() is now deprecated and in 2.0 does nothing.</li>
+ <li>There were many edge cases in the service lifecycle that made it very easy to accidentally leave a service running; new APIs in 2.0 make this much easier to deal with.</li>
+ <li>Android 2.0 also introduces a new UI for end users to monitor and manage the running services on their device.</li>
+</ul>
+<h3>Background on services</h3>
+<p>Before going into the details of 2.0, it may be useful to go over a quick summary of services. The Service API in Android is one of the key mechanisms for applications to do work in the background. Due to the way Android is designed, once an application is no longer visible to the user it is generally considered expendable and a candidate to be killed by the system if it ever needs memory elsewhere. The main way applications get around this is by starting a Service component, which explicitly tells the system that they are doing some valuable work and would prefer that the system not kill their process if it doesn't truly need to.</p>
+<p>This is a very powerful facility but along with that power comes some responsibility: an actively running service is taking resources away from other things that can run (including inactive processes in the background that don't need to be initialized the next time the user visits them). It is thus important that developers take care when designing their services that they only run when truly needed and avoid any bugs where they may accidentally leave the service running for long durations.</p>
+<h3>Redesigning Service.setForeground()</h3>
+<p>During the final stabilization period of Android 1.6 we started to see more issues due to an increasing number of applications using the Service.setForeground() API when they shouldn't be. This is an API that we haven't advertised much because it should not be used by most applications and can be very hard on the system: it asks that the service's process be treated as in the foreground, essentially making it unkillable and thus more difficult for the system to recover from low memory situations.</p>
+<p>At that point in 1.6 it was too late to make any significant changes to the behavior here, but in 2.0 we have done so: Service.setForeground() now does nothing. The API was always intended to be something a service would do in conjunction with putting up an ongoing notification for the user; by saying you are in the foreground, the user should be "aware" that the service is running in some way and know how to stop it. Thus in place of the old API Andriod 2.0 introduces two new APIs that require a notification go along with being in the foreground:</p>
+<pre class="prettyprint">
+public final void startForeground(int id, Notification notification);
+public final void stopForeground(boolean removeNotification);
+</pre>
+<p>This also not coincidentally makes it much easier to manage the notification state along with the service, since the system can now guarantee that there is always a notification while the service is in the foreground, and that the notification goes away whenever the service does.</p>
+<p>Many developers will want to write a service that works on older platforms as well as 2.0 and later; this can be accomplished by using something like the following code to selectively call the new APIs when they are available.</p>
+<pre class="prettyprint">
+private static final Class[] mStartForegroundSignature = new Class[] {
+ int.class, Notification.class};
+private static final Class[] mStopForegroundSignature = new Class[] {
+ boolean.class};
+
+private NotificationManager mNM;
+private Method mStartForeground;
+private Method mStopForeground;
+private Object[] mStartForegroundArgs = new Object[2];
+private Object[] mStopForegroundArgs = new Object[1];
+
+@Override
+public void onCreate() {
+ mNM = (NotificationManager)getSystemService(NOTIFICATION_SERVICE);
+ try {
+ mStartForeground = getClass().getMethod("startForeground",
+ mStartForegroundSignature);
+ mStopForeground = getClass().getMethod("stopForeground",
+ mStopForegroundSignature);
+ } catch (NoSuchMethodException e) {
+ // Running on an older platform.
+ mStartForeground = mStopForeground = null;
+ }
+}
+
+/**
+ * This is a wrapper around the new startForeground method, using the older
+ * APIs if it is not available.
+ */
+void startForegroundCompat(int id, Notification notification) {
+ // If we have the new startForeground API, then use it.
+ if (mStartForeground != null) {
+ mStartForegroundArgs[0] = Integer.valueOf(id);
+ mStartForegroundArgs[1] = notification;
+ try {
+ mStartForeground.invoke(this, mStartForegroundArgs);
+ } catch (InvocationTargetException e) {
+ // Should not happen.
+ Log.w("MyApp", "Unable to invoke startForeground", e);
+ } catch (IllegalAccessException e) {
+ // Should not happen.
+ Log.w("MyApp", "Unable to invoke startForeground", e);
+ }
+ return;
+ }
+
+ // Fall back on the old API.
+ setForeground(true);
+ mNM.notify(id, notification);
+}
+
+/**
+ * This is a wrapper around the new stopForeground method, using the older
+ * APIs if it is not available.
+ */
+void stopForegroundCompat(int id) {
+ // If we have the new stopForeground API, then use it.
+ if (mStopForeground != null) {
+ mStopForegroundArgs[0] = Boolean.TRUE;
+ try {
+ mStopForeground.invoke(this, mStopForegroundArgs);
+ } catch (InvocationTargetException e) {
+ // Should not happen.
+ Log.w("MyApp", "Unable to invoke stopForeground", e);
+ } catch (IllegalAccessException e) {
+ // Should not happen.
+ Log.w("MyApp", "Unable to invoke stopForeground", e);
+ }
+ return;
+ }
+
+ // Fall back on the old API. Note to cancel BEFORE changing the
+ // foreground state, since we could be killed at that point.
+ mNM.cancel(id);
+ setForeground(false);
+}
+</pre>
+<h3>Service lifecycle changes</h3>
+<p>Another situation we were increasingly seeing in 1.6 was that, even ignoring the services that inappropriately make themselves foreground, we had a growing number of devices with a large number of services running in the background all fighting each other over the available memory.</p>
+<p>Part of this problem is services that are running more than they should or there simply being too much stuff trying to be done on the device. However, we also found many issues in the interaction between services and the platform that made it easy for an application to leave a service running even when it is trying to do the right thing. Consider this typical scenario:</p>
+<ol>
+ <li>An application calls startService().</li>
+ <li>That service gets onCreate(), onStart(), and then spawns a background thread to do some work.</li>
+ <li>The system is tight on memory, so has to kill the currently running service.</li>
+ <li>Later when memory is free, the service is restarted, and gets onCreate() called but not onStart() because there has not been another call to startService() with a new Intent command to send it.</li>
+</ol>
+<p>Now the service will sit there created, not realizing it used to be doing some work, and so not knowing it should stop itself at some point.</p>
+<p>To address this, in Android 2.0 Service.onStart() as been deprecated (though still exists and operates as it used to in previous versions of the platform). It is replaced with a new {@link android.app.Service#onStartCommand(android.content.Intent, int, int)} callback that allows the service to better control how the system should manage it. The key part here is a new result code returned by the function, telling the system what it should do with the service if its process is killed while it is running:</p>
+<ul>
+ <li>{@link android.app.Service#START_STICKY} is basically the same as the previous behavior, where the service is left "started" and will later be restarted by the system. The only difference from previous versions of the platform is that it if it gets restarted because its process is killed, onStartCommand() will be called on the next instance of the service with a null Intent instead of not being called at all. Services that use this mode should always check for this case and deal with it appropriately.</li>
+ <li>{@link android.app.Service#START_NOT_STICKY} says that, after returning from onStartCreated(), if the process is killed with no remaining start commands to deliver, then the service will be stopped instead of restarted. This makes a lot more sense for services that are intended to only run while executing commands sent to them. For example, a service may be started every 15 minutes from an alarm to poll some network state. If it gets killed while doing that work, it would be best to just let it be stopped and get started the next time the alarm fires.</li>
+ <li>{@link android.app.Service#START_REDELIVER_INTENT} is like START_NOT_STICKY, except if the service's process is killed before it calls stopSelf() for a given intent, that intent will be re-delivered to it until it completes (unless after some number of more tries it still can't complete, at which point the system gives up). This is useful for services that are receiving commands of work to do, and want to make sure they do eventually complete the work for each command sent.</li>
+</ul>
+<p>For compatibility with existing applications, the default return code for applications that are targeting an earlier version of the platform is a special {@link android.app.Service#START_STICKY_COMPATIBILITY} code that provides the old behavior of not calling onStart() with a null intent. Once you start targeting API version 5 or later, the default mode is START_STICKY and you must be prepared to deal with onStart() or onStartCommand() being called with a null Intent.</p>
+<p>You can also easily write a Service that uses both the old and new APIs, depending on the platform. All you need to do is compile against the 2.0 SDK with this code:</p>
+<pre class="prettyprint">
+// This is the old onStart method that will be called on the pre-2.0
+// platform. On 2.0 or later we override onStartCommand() so this
+// method will not be called.
+@Override
+public void onStart(Intent intent, int startId) {
+ handleStart(intent, startId);
+}
+
+@Override
+public int onStartCommand(Intent intent, int flags, int startId) {
+ handleStart(intent, startId);
+ return START_NOT_STICKY;
+}
+
+void handleStart(Intent intent, int startId) {
+ // do work
+}
+</pre>
+<h3>New "running services" user interface</h3>
+<p>Our final issue to address is the case where there are simply too many service running in the amount of memory available on a device. This may be due to bugs or design flaws in installed applications, or the user simply trying to do too much. Historically users have had no visibility into what is going on at this level in the system, but it has become important to expose this, at least for lower-end devices, as the use of services has had an increasing impact on the user experience.</p>
+<p>To help address this, Android 2.0 introduces a new "Running Services" activity available from the Application system settings. When brought up, it looks something like this:</p>
+<img src="images/service-api-changes-starting-with_runningservices.png" width="192" height="320" alt="Running Services"/>
+<p>The main content is a list of all running services that may be of interest to the user, organized by the processes they run in. In the example here, we see three services:</p>
+<ul>
+ <li><b>GTalkService</b> is part of the standard Google application suit; it is running in Google's "gapps" process, which currently consumes 6.8MB. It has been started for 3 hours 55 minutes, which on this device is the time from when it was first booted.</li>
+ <li><b>ActivityService</b> is part of the Phonebook app, and its process consumes 4MB. This also has been running since boot.</li>
+ <li><b>SoftKeyboard</b> is a third party input method. It has been running since I switched to it, about 4 minutes ago.</li>
+</ul>
+<p>The user can tap on any of these services to control it; for normal services that are running because they were explicitly started, this will present a dialog allowing the user to explicitly stop it:</p>
+<img src="images/service-api-changes-starting-with_stopservice.png" height="320" width="192" alt="Stop Service"/>
+<p>Some other services, like the input method, are running for other reasons. For these, tapping on the service will go to the corresponding UI to manage it (in this case the system's input settings).</p>
+<p>Finally, along the bottom of the screen are some obscure numbers. If you know how to interpret them, this gives you a lot of information on the memory status of your device:</p>
+<ul>
+ <li><b>Avail: 38MB+114MB in 25</b> says that the device has 38MB of completely free (or likely used for unrequired caches) memory, and has another 114MB of available memory in 25 background processes it can kill at any time.</li>
+ <li><b>Other: 32MB in 3</b> says that the device has 32MB of unavailable memory in 3 unkillable processes (that is, processes that are currently considered to be foreground and must be kept running)</li>
+</ul>
+<p>For most users, this new user interface should be a much more effective way to manage the background applications on their device than the existing "task killer" applications. In the vast majority of cases the reason for a slow running device is too many services trying to run. This prevents the system from being able to run any background processes (which speed up app switching), and ultimately can result in thrashing through the services when not even they can all be kept running. The Running Services UI is intended to provide very specific information about the services that are running, to help make a good decision about what should be stopped. It also does not use the API to force stop an application, which can unintentionally break applications in numerous ways.</p>
+<p>For developers, this is an important tool to ensure your services are well behaved. As you develop your app, be sure to keep an eye on Running Services to ensure that you are not accidentally leaving your services running when they shouldn't be. You should also now keep in mind that users may freely stop any of your services as they wish, without your control, and account for that.</p>
+<p>Android's Services are a very powerful tool, but one of the main and subtle ways that application developers can harm the overall experience a user has with their phone.</p>
diff --git a/docs/html/resources/resources-data.js b/docs/html/resources/resources-data.js
index 7751c82..eeb62ed 100644
--- a/docs/html/resources/resources-data.js
+++ b/docs/html/resources/resources-data.js
@@ -20,6 +20,7 @@
'intent': 'Intents',
'layout': 'Layouts/Views',
'media': 'Multimedia',
+ 'multitasking': 'Multi-tasking',
'newfeature': 'New Features',
'performance': 'Performance',
'search': 'Search',
@@ -201,6 +202,16 @@
}
},
{
+ tags: ['article', 'bestpractice', 'multitasking'],
+ path: 'articles/multitasking-android-way.html',
+ title: {
+ en: 'Multitasking the Android Way'
+ },
+ description: {
+ en: 'This article describes best practices and user experience guidelines for multi-tasking on Android.'
+ }
+ },
+ {
tags: ['article', 'input'],
path: 'articles/on-screen-inputs.html',
title: {
@@ -241,6 +252,16 @@
}
},
{
+ tags: ['article', 'compatibility', 'multitasking'],
+ path: 'articles/service-api-changes-starting-with.html',
+ title: {
+ en: 'Service API changes starting with Android 2.0'
+ },
+ description: {
+ en: 'This article describes the changes and improvements to services introduced in Android 2.0, as well as strategies for compatibility with older versions of the platform.'
+ }
+ },
+ {
tags: ['article', 'ui'],
path: 'articles/touch-mode.html',
title: {
