Merge "fix misc doc bugs from external issues" into jb-dev

docs/html/guide/components/bound-services.jd

@@ -640,12 +640,6 @@ href="{@docRoot}resources/samples/ApiDemos/index.html">ApiDemos</a>.</p>
 
 <h2 id="Lifecycle">Managing the Lifecycle of a Bound Service</h2>
 
-<div class="figure" style="width:588px">
-<img src="{@docRoot}images/fundamentals/service_binding_tree_lifecycle.png" alt="" />
-<p class="img-caption"><strong>Figure 1.</strong> The lifecycle for a service that is started
-and also allows binding.</p>
-</div>
-
 <p>When a service is unbound from all clients, the Android system destroys it (unless it was also
 started with {@link android.app.Service#onStartCommand onStartCommand()}). As such, you don't have
 to manage the lifecycle of your service if it's purely a bound
@@ -667,6 +661,12 @@ onRebind()} returns void, but the client still receives the {@link android.os.IB
 {@link android.content.ServiceConnection#onServiceConnected onServiceConnected()} callback.
 Below, figure 1 illustrates the logic for this kind of lifecycle.</p>
 
+
+<img src="{@docRoot}images/fundamentals/service_binding_tree_lifecycle.png" alt="" />
+<p class="img-caption"><strong>Figure 1.</strong> The lifecycle for a service that is started
+and also allows binding.</p>
+
+
 <p>For more information about the lifecycle of an started service, see the <a
 href="{@docRoot}guide/components/services.html#Lifecycle">Services</a> document.</p>
 

docs/html/guide/components/services.jd

@@ -755,15 +755,6 @@ stopSelf()} does not actually stop the service until all clients unbind. </p>
 changes in the service's state and perform work at the appropriate times. The following skeleton
 service demonstrates each of the lifecycle methods:</p>
 
-
-<div class="figure" style="width:432px">
-<img src="{@docRoot}images/service_lifecycle.png" alt="" />
-<p class="img-caption"><strong>Figure 2.</strong> The service lifecycle. The diagram on the left
-shows the lifecycle when the service is created with {@link android.content.Context#startService
-startService()} and the diagram on the right shows the lifecycle when the service is created
-with {@link android.content.Context#bindService bindService()}.</p>
-</div>
-
 <pre>
 public class ExampleService extends Service {
     int mStartMode;       // indicates how to behave if the service is killed
@@ -804,6 +795,12 @@ public class ExampleService extends Service {
 <p class="note"><strong>Note:</strong> Unlike the activity lifecycle callback methods, you are
 <em>not</em> required to call the superclass implementation of these callback methods.</p>
 
+<img src="{@docRoot}images/service_lifecycle.png" alt="" />
+<p class="img-caption"><strong>Figure 2.</strong> The service lifecycle. The diagram on the left
+shows the lifecycle when the service is created with {@link android.content.Context#startService
+startService()} and the diagram on the right shows the lifecycle when the service is created
+with {@link android.content.Context#bindService bindService()}.</p>
+
 <p>By implementing these methods, you can monitor two nested loops of the service's lifecycle: </p>
 
 <ul>

docs/html/guide/webapps/targeting.jd

@@ -270,7 +270,7 @@ density.</p>
 
 <p>The density of a device's screen is based on the screen resolution, as defined by the number of
 dots per inch (dpi). There are three screen
-density categories supported by Android: low (ldpi), medium (mdpi), and high (mdpi). A screen
+density categories supported by Android: low (ldpi), medium (mdpi), and high (hdpi). A screen
 with low density has fewer available pixels per inch, whereas a screen with high density has more
 pixels per inch (compared to a medium density screen). The Android Browser and {@link
 android.webkit.WebView} target a medium density screen by default.</p>

docs/html/tools/help/adb.jd

@@ -88,13 +88,14 @@ Emulator 2, adb: 5557 ...
 	<li>Serial number &mdash; A string created by adb to uniquely identify an emulator/device instance by its 
         console port number. The format of the serial number is <code>&lt;type&gt;-&lt;consolePort&gt;</code>. 
         Here's an example serial number: <code>emulator-5554</code></li>
-	<li>State &mdash; The connection state of the instance. Three states are supported: 
+	<li>State &mdash; The connection state of the instance may be one of the following:
 		<ul>
 		<li><code>offline</code> &mdash; the instance is not connected to adb or is not responding.</li>
 		<li><code>device</code> &mdash; the instance is now connected to the adb server. Note that this state does not 
                     imply that the Android system is fully booted and operational, since the instance connects to adb 
                     while the system is still booting. However, after boot-up, this is the normal operational state of 
                     an emulator/device instance.</li>
+                <li><code>no device</code> &mdash; there is no emulator/device connected.
 		</ul>
 	</li>
 </ul>
@@ -111,7 +112,6 @@ emulator-5554&nbsp;&nbsp;device
 emulator-5556&nbsp;&nbsp;device
 emulator-5558&nbsp;&nbsp;device</pre>
 
-<p>If there is no emulator/device running, adb returns <code>no device</code>.</p>
 
 
 <a name="directingcommands"></a>

docs/html/training/accessibility/service.jd

@@ -175,7 +175,7 @@ In that method, use {@link
 android.view.accessibility.AccessibilityEvent#getEventType} to determine the
 type of event, and {@link
 android.view.accessibility.AccessibilityEvent#getContentDescription} to extract
-any label text associated with the fiew that fired the event.</pre>
+any label text associated with the view that fired the event.</pre>
 
 <pre>
 &#64;Override

docs/html/training/basics/firstapp/starting-activity.jd

@@ -226,7 +226,7 @@ the original {@code MainActivity.java} file.</p>
 
 <p>Open the {@code DisplayMessageActivity.java} file. If you used Eclipse to create it, the class
 already includes an implementation of the required {@link android.app.Activity#onCreate onCreate()}
-method. There's also an implemtation of the {@link android.app.Activity#onCreateOptionsMenu
+method. There's also an implementation of the {@link android.app.Activity#onCreateOptionsMenu
 onCreateOptionsMenu()} method, but
 you won't need it for this app so you can remove it. The class should look like this:</p>
 

docs/html/training/basics/intents/sending.jd

@@ -31,11 +31,11 @@ next.link=result.html
 <p>One of Android's most important features is an app's ability to send the user to another app
 based on an "action" it would like to perform. For example, if
 your app has the address of a business that you'd like to show on a map, you don't have to build
-an activity in your app that shows a map. Instead, you can send a out a request to view the address
-using an {@link android.content.Intent}. The Android system then starts an app that's able to view
+an activity in your app that shows a map. Instead, you can create a request to view the address
+using an {@link android.content.Intent}. The Android system then starts an app that's able to show
 the address on a map.</p>
 
-<p>As shown in the first class, <a href="{@docRoot}training/basics/firstapp/index.html">Building
+<p>As explained in the first class, <a href="{@docRoot}training/basics/firstapp/index.html">Building
 Your First App</a>, you must use intents to navigate between activities in your own app. You
 generally do so with an <em>explicit intent</em>, which defines the exact class name of the
 component you want to start. However, when you want to have a separate app perform an action, such

docs/html/training/basics/network-ops/managing.jd

@@ -116,7 +116,7 @@ background data.</p>
 follows. The method {@link
 android.net.ConnectivityManager#getActiveNetworkInfo() getActiveNetworkInfo()}
 returns a {@link android.net.NetworkInfo} instance representing the first
-connected network interface it can find, or <code>null</code> if none if the
+connected network interface it can find, or <code>null</code> if none of the
 interfaces is connected (meaning that an
 internet connection is not available):</p>
 

docs/html/training/cloudsync/gcm.jd

@@ -37,8 +37,7 @@ your server.</p>
 <p>This lesson covers some of the best practices
 for integrating GCM into your application, and assumes you are already familiar
 with basic implementation of this service.  If this is not the case, you can read the <a
-  href="http://developer.google.com/android/gcm/demo">GCM
-  Tutorial</a>.</p>
+  href="{@docRoot}guide/google/gcm/demo.html">GCM demo app tutorial</a>.</p>
 
 <h2 id="multicast">Send Multicast Messages Efficiently</h2>
 <p>One of the most useful features in GCM is support for up to 1,000 recipients for

docs/html/training/managing-audio/audio-focus.jd

@@ -135,7 +135,7 @@ those events—and abandoning your audio focus. At that point, you would exp
 (pressing play in your app) to be required before you resume playing audio.</p>
 
 <p>In the following code snippet, we pause the playback or our media player object if the audio
-loss is transien and resume it when we have regained the focus. If the loss is permanent, it
+loss is transient and resume it when we have regained the focus. If the loss is permanent, it
 unregisters our media button event receiver and stops monitoring audio focus changes.<p>
 
 <pre>
@@ -169,7 +169,7 @@ lose focus, then returns it to its previous level when we regain focus.</p>
 <pre>
 OnAudioFocusChangeListener afChangeListener = new OnAudioFocusChangeListener() {
     public void onAudioFocusChange(int focusChange) {
-        if (focusChange == AUDIOFOCUS_LOSS_TRANSIENT_CAN_DUCK
+        if (focusChange == AUDIOFOCUS_LOSS_TRANSIENT_CAN_DUCK) {
             // Lower the volume
         } else if (focusChange == AudioManager.AUDIOFOCUS_GAIN) {
             // Raise it back to normal