Doc change: cleanup filtering sidebars and api level table. Changes links pointing to billing and other play docs that have moved.

Change-Id: I5528e82a6f97eb25f2ec2db5dfe1e178d9580f3c

8 files changed, 23 insertions, 23 deletions

diff --git a/docs/html/training/articles/security-tips.jd b/docs/html/training/articles/security-tips.jd
index 88d6017..11e25af 100644
--- a/docs/html/training/articles/security-tips.jd
+++ b/docs/html/training/articles/security-tips.jd
@@ -296,7 +296,7 @@ any responses to intents issued against HTTP.</p>
 <p>The <acronym title="Short Message Service">SMS</acronym> protocol was primarily designed for
 user-to-user communication and is not well-suited for apps that want to transfer data.
 Due to the limitations of SMS, we strongly recommend the use of <a
-href="{@docRoot}guide/google/gcm/index.html">Google Cloud Messaging</a> (GCM)
+href="{@docRoot}google/gcm/index.html">Google Cloud Messaging</a> (GCM)
 and IP networking for sending data messages from a web server to your app on a user device.</p>
 
 <p>Beware that SMS is neither encrypted nor strongly
diff --git a/docs/html/training/cloudsync/gcm.jd b/docs/html/training/cloudsync/gcm.jd
index df26d34..fa395e4 100644
--- a/docs/html/training/cloudsync/gcm.jd
+++ b/docs/html/training/cloudsync/gcm.jd
@@ -20,7 +20,7 @@ previous.link=backupapi.html
     </ol>
     <h2>You should also read</h2>
     <ul>
-      <li><a href="http://developer.android.com/guide/google/gcm/index.html">Google
+      <li><a href="http://developer.android.com/google/gcm/index.html">Google
       Cloud Messaging for Android</a></li>
     </ul>
   </div>
@@ -37,7 +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="{@docRoot}guide/google/gcm/demo.html">GCM demo app tutorial</a>.</p>
+  href="{@docRoot}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
@@ -53,7 +53,7 @@ disaster alerts or sports scores, where a 30 minute interval might render the
 information useless.</p>
 
 <p>Taking advantage of this functionality is easy.  If you're using the <a
-  href="http://developer.android.com/guide/google/gcm/gs.html#libs">GCM helper
+  href="{@docRoot}google/gcm/gs.html#libs">GCM helper
   library</a> for Java, simply provide a <code>List<String></code> collection of
 registration IDs to the <code>send</code> or <code>sendNoRetry</code> method,
 instead of a single registration ID.</p>
@@ -97,7 +97,7 @@ GCM-defined parameters.  The endpoint for this HTTP POST message will be
 </pre>
 
 <p>For a more thorough overview of the format of multicast GCM messages, see the <a
-  href="http://developer.android.com/guide/google/gcm/gcm.html#send-msg">Sending
+  href="{@docRoot}google/gcm/gcm.html#send-msg">Sending
   Messages</a> section of the GCM guide.</pre>
 
 <h2 id="collapse">Collapse Messages that Can Be Replaced</h2>
diff --git a/docs/html/training/efficient-downloads/regular_updates.jd b/docs/html/training/efficient-downloads/regular_updates.jd
index 262d676..8e3842a 100644
--- a/docs/html/training/efficient-downloads/regular_updates.jd
+++ b/docs/html/training/efficient-downloads/regular_updates.jd
@@ -22,7 +22,7 @@ next.link=redundant_redundant.html
 <h2>You should also read</h2>
 <ul>
   <li><a href="{@docRoot}training/monitoring-device-state/index.html">Optimizing Battery Life</a></li>
-  <li><a href="{@docRoot}guide/google/gcm/index.html">Google Cloud Messaging for Android</a></li>
+  <li><a href="{@docRoot}google/gcm/index.html">Google Cloud Messaging for Android</a></li>
 </ul>
 
 </div>
@@ -38,7 +38,7 @@ next.link=redundant_redundant.html
  
 <p>Every time your app polls your server to check if an update is required, you activate the wireless radio, drawing power unnecessarily, for up to 20 seconds on a typical 3G connection.</p>
 
-<p><a href="{@docRoot}guide/google/gcm/index.html">Google Cloud Messaging for Android (GCM)</a> is a lightweight mechanism used to transmit data from a server to a particular app instance. Using GCM, your server can notify your app running on a particular device that there is new data available for it.</p>
+<p><a href="{@docRoot}google/gcm/index.html">Google Cloud Messaging for Android (GCM)</a> is a lightweight mechanism used to transmit data from a server to a particular app instance. Using GCM, your server can notify your app running on a particular device that there is new data available for it.</p>
 
 <p>Compared to polling, where your app must regularly ping the server to query for new data, this event-driven model allows your app to create a new connection only when it knows there is data to download.</p>
 
diff --git a/docs/html/training/multiple-apks/api.jd b/docs/html/training/multiple-apks/api.jd
index 1a2593a..f43dcae 100644
--- a/docs/html/training/multiple-apks/api.jd
+++ b/docs/html/training/multiple-apks/api.jd
@@ -33,7 +33,7 @@ next.link=screensize.html
 <!-- other docs (NOT javadocs) -->
 <h2>You should also read</h2>
 <ul>
-  <li><a href="http://developer.android.com/guide/google/play/publishing/multiple-apks.html">Multiple APK
+  <li><a href="http://developer.android.com/google/play/publishing/multiple-apks.html">Multiple APK
 Support</a></li>
   <li><a
 href="http://android-developers.blogspot.com/2010/07/how-to-have-your-cupcake-and-eat-it-too.html">
@@ -57,7 +57,7 @@ necessary to make maintaining a multiple APK codebase as painless as possible.</
 platform, naturally you want your application to take advantage of new features on new devices,
 without sacrificing backwards compatibility.  It may seem at the outset as though multiple APK
 support is the best solution, but this often isn’t the case.  The <a
-href="{@docRoot}guide/google/play/publishing/multiple-apks.html#ApiLevelOptions">Using Single APK
+href="{@docRoot}google/play/publishing/multiple-apks.html#ApiLevelOptions">Using Single APK
 Instead</a> section of the multiple APK developer guide includes some useful information on how to
 accomplish this with a single APK, including use of our support library. You can also learn how to
 write code that runs only at certain API levels in a single APK, without resorting to
@@ -279,7 +279,7 @@ green &#8805; blue.  Therefore we can effectively collapse the chart to look lik
 
 <p>
 Now, let’s further assume that the Red APK has some requirement on it that the other two don’t.  
-<a href="{@docRoot}guide/google/play/filters.html">Filters on Google Play</a> page of
+<a href="{@docRoot}google/play/filters.html">Filters on Google Play</a> page of
 the Android Developer guide has a whole list of possible culprits.  For the
 sake of example, let’s assume that red requires a front-facing camera.  In fact, the entire point of
 the red APK is to combine the front-facing camera with sweet new functionality that was added in API
@@ -296,7 +296,7 @@ APK that supported that particular API level.</p>
 
 <p>  In order to keep all your APKs on separate "tracks", it’s important to have a good version code
 scheme.  The recommended one can be found on the <a
-href="{@docRoot}guide/google/play/publishing/multiple-apks.html#VersionCodes">Version Codes</a> area of
+href="{@docRoot}google/play/publishing/multiple-apks.html#VersionCodes">Version Codes</a> area of
 our developer guide.  Since the example set of APKs is only dealing with one of 3 possible
 dimensions, it would be sufficient to separate each APK by 1000, set the first couple digits to the
 minSdkVersion for that particular APK, and increment from there.  This might look like:</p>
diff --git a/docs/html/training/multiple-apks/index.jd b/docs/html/training/multiple-apks/index.jd
index 1f2fee8..37286c3 100644
--- a/docs/html/training/multiple-apks/index.jd
+++ b/docs/html/training/multiple-apks/index.jd
@@ -23,7 +23,7 @@ account</li>
 <!-- related docs (NOT javadocs) -->
 <h2>You should also read</h2>
 <ul>
-  <li><a href="http://developer.android.com/guide/google/play/publishing/multiple-apks.html">Multiple APK
+  <li><a href="http://developer.android.com/google/play/publishing/multiple-apks.html">Multiple APK
 Support</a></li>
 </ul>
 
diff --git a/docs/html/training/multiple-apks/multiple.jd b/docs/html/training/multiple-apks/multiple.jd
index 25938da..ccee397 100644
--- a/docs/html/training/multiple-apks/multiple.jd
+++ b/docs/html/training/multiple-apks/multiple.jd
@@ -33,7 +33,7 @@ previous.link=texture.html
 <!-- other docs (NOT javadocs) -->
 <h2>You should also read</h2>
 <ul>
-  <li><a href="http://developer.android.com/guide/google/play/publishing/multiple-apks.html">Multiple APK
+  <li><a href="http://developer.android.com/google/play/publishing/multiple-apks.html">Multiple APK
 Support</a></li>
 </ul>
 
@@ -54,7 +54,7 @@ devices, naturally you want your application look its best on each individual de
 take advantage of the space of large screens but still work on small ones, to use new Android API
 features or visual textures available on cutting edge devices but not abandon older ones.  It may
 seem at the outset as though multiple APK support is the best solution, but this often isn’t the
-case.  The <a href="{@docRoot}guide/google/play/publishing/multiple-apks.html#ApiLevelOptions">Using
+case.  The <a href="{@docRoot}google/play/publishing/multiple-apks.html#ApiLevelOptions">Using
 Single APK Instead</a> section of the multiple APK guide includes some useful information on how to
 accomplish all of this with a single APK, including use of our <a
 href="http://android-developers.blogspot.com/2011/03/fragments-for-all.html">support library</a>,
@@ -329,7 +329,7 @@ preference as follows:</p>
 Purple &#8805; Red &#8805; Green &#8805; Blue
 </p><p>
 Why allow all the overlap?  Let’s pretend that the Purple APK has some requirement on it that the
-other two don’t.  The <a href="{@docRoot}guide/google/play/filters.html">Filters on Google Play</a> page
+other two don’t.  The <a href="{@docRoot}google/play/filters.html">Filters on Google Play</a> page
 of the Android Developer guide has a whole list of possible culprits.  For the sake of example,
 let’s assume that Purple requires a front-facing camera.  In fact, the entire point of Purple is to
 use entertaining things with the front-facing camera!  But, it turns out, not all API 11+ devices
@@ -345,7 +345,7 @@ API level.</p>
 
 <p>  In order to keep all your APKs on separate "tracks", it’s important to have a good version code
 scheme.  The recommended one can be found on the <a
-href="{@docRoot}guide/google/play/publishing/multiple-apks.html#VersionCodes">Version Codes</a> area of
+href="{@docRoot}google/play/publishing/multiple-apks.html#VersionCodes">Version Codes</a> area of
 our developer guide.  It’s worth reading the whole section, but the basic gist is for this set of
 APKs, we’d use two digits to represent the minSDK, two to represent the min/max screen size, and 3
 to represent the build number.  That way, when the device upgraded to a new version of Android,
diff --git a/docs/html/training/multiple-apks/screensize.jd b/docs/html/training/multiple-apks/screensize.jd
index ea793db..c7941c4 100644
--- a/docs/html/training/multiple-apks/screensize.jd
+++ b/docs/html/training/multiple-apks/screensize.jd
@@ -34,7 +34,7 @@ next.link=texture.html
 <!-- other docs (NOT javadocs) -->
 <h2>You should also read</h2>
 <ul>
-  <li><a href="http://developer.android.com/guide/google/play/publishing/multiple-apks.html">Multiple APK
+  <li><a href="http://developer.android.com/google/play/publishing/multiple-apks.html">Multiple APK
 Support</a></li>
   <li><a href="{@docRoot}guide/practices/screens_support.html">Supporting Multiple Screens</a></li>
 </ul>
@@ -56,7 +56,7 @@ make maintaining a multiple APK codebase as painless as possible.</p>
 naturally you want your application to take advantage of all the available space on larger devices,
 without sacrificing compatibility or usability on the smaller screens.  It may seem at the outset as
 though multiple APK support is the best solution, but this often isn’t the case.  The <a
-href="{@docRoot}guide/google/play/publishing/multiple-apks.html#ApiLevelOptions">Using Single APK
+href="{@docRoot}google/play/publishing/multiple-apks.html#ApiLevelOptions">Using Single APK
 Instead</a> section of the multiple APK developer guide includes some useful information on how to
 accomplish this with a single APK, including use of our support library. You should also read the 
 guide to <a href="{@docRoot}guide/practices/screens_support.html">supporting multiple screens</a>,
@@ -227,7 +227,7 @@ each APK such that red &#8805; green &#8805; blue, the chart effectively collaps
 </table>
 <p>
 Now, let’s further assume that the Red APK has some requirement on it that the other two don’t.  The
-<a href="{@docRoot}guide/google/play/filters.html">Filters on Google Play</a> page of the Android
+<a href="{@docRoot}google/play/filters.html">Filters on Google Play</a> page of the Android
 Developer guide has a whole list of possible culprits.  For the sake of example, let’s assume that
 red requires a front-facing camera.  In fact, the entire point of the red APK is to use the extra
 available screen space to do entertaining things with that front-facing camera.  But, it turns out,
@@ -243,7 +243,7 @@ size.</p>
 
 <p>  In order to keep all your APKs on separate "tracks", it’s important to have a good version code
 scheme.  The recommended one can be found on the <a
-href="{@docRoot}guide/google/play/publishing/multiple-apks.html#VersionCodes">Version Codes</a> area of
+href="{@docRoot}google/play/publishing/multiple-apks.html#VersionCodes">Version Codes</a> area of
 our developer guide.  Since the example set of APKs is only dealing with one of 3 possible
 dimensions, it would be sufficient to separate each APK by 1000 and increment from there.  This
 might look like:</p>
diff --git a/docs/html/training/multiple-apks/texture.jd b/docs/html/training/multiple-apks/texture.jd
index 70ad1e0..e4ea72b 100644
--- a/docs/html/training/multiple-apks/texture.jd
+++ b/docs/html/training/multiple-apks/texture.jd
@@ -33,7 +33,7 @@ next.link=multiple.html
 <!-- other docs (NOT javadocs) -->
 <h2>You should also read</h2>
 <ul>
-  <li><a href="http://developer.android.com/guide/google/play/publishing/multiple-apks.html">Multiple APK
+  <li><a href="http://developer.android.com/google/play/publishing/multiple-apks.html">Multiple APK
 Support</a></li>
 </ul>
 
@@ -49,10 +49,10 @@ Support</a></li>
 devices, naturally you want your application look its best on each individual device, regardless of
 the fact they don’t all support the same set of GL textures.  It may seem at the outset as though
 multiple APK support is the best solution, but this often isn’t the case.  The <a
-href="{@docRoot}guide/google/play/publishing/multiple-apks.html#ApiLevelOptions">Using Single APK
+href="{@docRoot}google/play/publishing/multiple-apks.html#ApiLevelOptions">Using Single APK
 Instead</a> section of the multiple APK developer guide includes some useful information on how to
 accomplish this with a single APK, including how to <a
-href="{@docRoot}guide/google/play/publishing/multiple-apks.html#TextureOptions">detect supported texture
+href="{@docRoot}google/play/publishing/multiple-apks.html#TextureOptions">detect supported texture
 formats at runtime</a>.  Depending on your situation, it might be easier to bundle all formats with
 your application, and simply pick which one to use at runtime.</p>