summaryrefslogtreecommitdiffstats
path: root/docs/html/training/multiple-apks/multiple.jd
diff options
context:
space:
mode:
Diffstat (limited to 'docs/html/training/multiple-apks/multiple.jd')
-rw-r--r--docs/html/training/multiple-apks/multiple.jd12
1 files changed, 6 insertions, 6 deletions
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,