5 files changed, 25 insertions, 25 deletions
diff --git a/docs/html/training/multiple-apks/api.jd b/docs/html/training/multiple-apks/api.jd
index 3492245..1a2593a 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/market/publishing/multiple-apks.html">Multiple APK
+  <li><a href="http://developer.android.com/guide/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/market/publishing/multiple-apks.html#ApiLevelOptions">Using Single APK
+href="{@docRoot}guide/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
@@ -85,7 +85,7 @@ application.</p>
 
 <p>Start off by creating a simple chart to quickly determine how many APKs you need, and what API
 range each APK covers.  For handy reference, the <a
-href="{@docRoot}resources/dashboard/platform-versions.html">Platform Versions</a> page of the
+href="{@docRoot}about/dashboards/index.html">Platform Versions</a> page of the
 Android Developer website provides data about the relative number of active devices running a given
 version of the Android platform.  Also, although it sounds easy at first, keeping track of which set
 of API levels each APK is going to target gets difficult rather quickly, especially if there’s going
@@ -153,10 +153,10 @@ include library projects are beyond the scope of this lesson, you can get up to
 their creation at the following links:</p>
 <ul>
 <li><a
-href="{@docRoot}guide/developing/projects/projects-eclipse.html#SettingUpLibraryProject">Setting up
+href="{@docRoot}tools/projects/projects-eclipse.html#SettingUpLibraryProject">Setting up
 a library project (Eclipse)</a></li>
 <li><a
-href="{@docRoot}guide/developing/projects/projects-cmdline.html#SettingUpLibraryProject">Setting up
+href="{@docRoot}tools/projects/projects-cmdline.html#SettingUpLibraryProject">Setting up
 a library project (Command line)</a></li>
 </ul>
 
@@ -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/appendix/market-filters.html">Filters on Google Play</a> page of
+<a href="{@docRoot}guide/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/market/publishing/multiple-apks.html#VersionCodes">Version Codes</a> area of
+href="{@docRoot}guide/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 d92c106..1f2fee8 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/market/publishing/multiple-apks.html">Multiple APK
+  <li><a href="http://developer.android.com/guide/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 b30068f..25938da 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/market/publishing/multiple-apks.html">Multiple APK
+  <li><a href="http://developer.android.com/guide/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/market/publishing/multiple-apks.html#ApiLevelOptions">Using
+case.  The <a href="{@docRoot}guide/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>,
@@ -182,10 +182,10 @@ include library projects are beyond the scope of this lesson, you can get up to
 their creation at the following links:</p>
 <ul>
 <li><a
-href="{@docRoot}guide/developing/projects/projects-eclipse.html#SettingUpLibraryProject">Setting up
+href="{@docRoot}tools/projects/projects-eclipse.html#SettingUpLibraryProject">Setting up
 a library project (Eclipse)</a></li>
 <li><a
-href="{@docRoot}guide/developing/projects/projects-cmdline.html#SettingUpLibraryProject">Setting up
+href="{@docRoot}tools/projects/projects-cmdline.html#SettingUpLibraryProject">Setting up
 a library project (Command line)</a></li>
 </ul>
 
@@ -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/appendix/market-filters.html">Filters on Google Play</a> page
+other two don’t.  The <a href="{@docRoot}guide/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/market/publishing/multiple-apks.html#VersionCodes">Version Codes</a> area of
+href="{@docRoot}guide/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 ac679a7..ea793db 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/market/publishing/multiple-apks.html">Multiple APK
+  <li><a href="http://developer.android.com/guide/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/market/publishing/multiple-apks.html#ApiLevelOptions">Using Single APK
+href="{@docRoot}guide/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>,
@@ -130,10 +130,10 @@ include library projects are beyond the scope of this lesson, you can get up to
 their creation at the following links:</p>
 <ul>
 <li><a
-href="{@docRoot}guide/developing/projects/projects-eclipse.html#SettingUpLibraryProject">Setting up
+href="{@docRoot}tools/projects/projects-eclipse.html#SettingUpLibraryProject">Setting up
 a library project (Eclipse)</a></li>
 <li><a
-href="{@docRoot}guide/developing/projects/projects-cmdline.html#SettingUpLibraryProject">Setting up
+href="{@docRoot}tools/projects/projects-cmdline.html#SettingUpLibraryProject">Setting up
 a library project (Command line)</a></li>
 </ul>
 
@@ -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/appendix/market-filters.html">Filters on Google Play</a> page of the Android
+<a href="{@docRoot}guide/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/market/publishing/multiple-apks.html#VersionCodes">Version Codes</a> area of
+href="{@docRoot}guide/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 497d6b8..70ad1e0 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/market/publishing/multiple-apks.html">Multiple APK
+  <li><a href="http://developer.android.com/guide/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/market/publishing/multiple-apks.html#ApiLevelOptions">Using Single APK
+href="{@docRoot}guide/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/market/publishing/multiple-apks.html#TextureOptions">detect supported texture
+href="{@docRoot}guide/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>
 
@@ -113,10 +113,10 @@ include library projects are beyond the scope of this lesson, you can get up to
 their creation at the following links:</p>
 <ul>
 <li><a
-href="{@docRoot}guide/developing/projects/projects-eclipse.html#SettingUpLibraryProject">Setting up
+href="{@docRoot}tools/projects/projects-eclipse.html#SettingUpLibraryProject">Setting up
 a library project (Eclipse)</a></li>
 <li><a
-href="{@docRoot}guide/developing/projects/projects-cmdline.html#SettingUpLibraryProject">Setting up
+href="{@docRoot}tools/projects/projects-cmdline.html#SettingUpLibraryProject">Setting up
 a library project (Command line)</a></li>
 </ul>