diff options
Diffstat (limited to 'docs/html/training')
| -rw-r--r-- | docs/html/training/camera/photobasics.jd | 4 | ||||
| -rw-r--r-- | docs/html/training/camera/videobasics.jd | 2 | ||||
| -rw-r--r-- | docs/html/training/id-auth/custom_auth.jd | 2 | ||||
| -rw-r--r-- | docs/html/training/multiple-apks/api.jd | 21 | ||||
| -rw-r--r-- | docs/html/training/multiple-apks/index.jd | 6 | ||||
| -rw-r--r-- | docs/html/training/multiple-apks/multiple.jd | 20 | ||||
| -rw-r--r-- | docs/html/training/multiple-apks/screensize.jd | 20 | ||||
| -rw-r--r-- | docs/html/training/multiple-apks/texture.jd | 14 | ||||
| -rw-r--r-- | docs/html/training/sharing/receive.jd | 2 |
9 files changed, 46 insertions, 45 deletions
diff --git a/docs/html/training/camera/photobasics.jd b/docs/html/training/camera/photobasics.jd index e6ab43e..3420918 100644 --- a/docs/html/training/camera/photobasics.jd +++ b/docs/html/training/camera/photobasics.jd @@ -55,7 +55,7 @@ for you.</p> <h2 id="TaskManifest">Request Camera Permission</h2> <p>If an essential function of your application is taking pictures, then restrict -its visibility in Android Market to devices that have a camera. To advertise +its visibility on Google Play to devices that have a camera. To advertise that your application depends on having a camera, put a <a href="{@docRoot}guide/topics/manifest/uses-feature-element.html"> {@code <uses-feature>}</a> tag in your manifest file:</p> @@ -68,7 +68,7 @@ href="{@docRoot}guide/topics/manifest/uses-feature-element.html"> {@code </pre> <p>If your application uses, but does not require a camera in order to function, add {@code -android:required="false"} to the tag. In doing so, Android Market will allow devices without a +android:required="false"} to the tag. In doing so, Google Play will allow devices without a camera to download your application. It's then your responsibility to check for the availability of the camera at runtime by calling {@link android.content.pm.PackageManager#hasSystemFeature hasSystemFeature(PackageManager.FEATURE_CAMERA)}. diff --git a/docs/html/training/camera/videobasics.jd b/docs/html/training/camera/videobasics.jd index a3512b0..f8ce03c 100644 --- a/docs/html/training/camera/videobasics.jd +++ b/docs/html/training/camera/videobasics.jd @@ -62,7 +62,7 @@ records video. In this lesson, you make it do this for you.</p> </pre> <p>If your application uses, but does not require a camera in order to function, add {@code -android:required="false"} to the tag. In doing so, Android Market will allow devices without a +android:required="false"} to the tag. In doing so, Google Play will allow devices without a camera to download your application. It's then your responsibility to check for the availability of the camera at runtime by calling {@link android.content.pm.PackageManager#hasSystemFeature hasSystemFeature(PackageManager.FEATURE_CAMERA)}. diff --git a/docs/html/training/id-auth/custom_auth.jd b/docs/html/training/id-auth/custom_auth.jd index e2bd778..0509c6e 100644 --- a/docs/html/training/id-auth/custom_auth.jd +++ b/docs/html/training/id-auth/custom_auth.jd @@ -181,6 +181,6 @@ multiple copies of it taking up space on your user's device.</p> <p>One solution is to place the service in one small, special-purpose APK. When an app wishes to use your custom account type, it can check the device to see if your custom account service is available. If not, it can direct the user to -Android Market to download the service. This may seem like a great deal of +Google Play to download the service. This may seem like a great deal of trouble at first, but compared with the alternative of re-entering credentials for every app that uses your custom account, it's refreshingly easy.</p> diff --git a/docs/html/training/multiple-apks/api.jd b/docs/html/training/multiple-apks/api.jd index d8588d4..8b731bd 100644 --- a/docs/html/training/multiple-apks/api.jd +++ b/docs/html/training/multiple-apks/api.jd @@ -44,7 +44,7 @@ How to have your (Cup)cake and eat it too</a></li> </div> -<p>When developing your Android application to take advantage of multiple APKs on Android Market, +<p>When developing your Android application to take advantage of multiple APKs on Google Play, it’s important to adopt some good practices from the get-go, and prevent unnecessary headaches further into the development process. This lesson shows you how to create multiple APKs of your app, each covering a slightly different range of API levels. You will also gain some tools @@ -198,7 +198,7 @@ initialization procedures that don’t change much from APK to APK.</p> <h2 id="AdjustManifests">Adjust the Manifests</h2> -<p>When a user downloads an application which uses multiple APKs through Android Market, the correct +<p>When a user downloads an application which uses multiple APKs through Google Play, the correct APK to use is chosen using two simple rules:</p> <ul> <li>The manifest has to show that particular APK is eligible</li> @@ -278,19 +278,20 @@ green ≥ blue. Therefore we can effectively collapse the chart to look lik </table> <p> -Now, let’s further assume that the Red APK has some requirement on it that the other two don’t. The -Market Filters page of the Android Developer guide has a whole list of possible culprits. For the +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 +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 11. But, it turns out, not all devices that support API 11 even HAVE front-facing cameras! The horror!</p> -<p>Fortunately, if a user is browsing Market from one such device, Android Market will look at the +<p>Fortunately, if a user is browsing Google Play from one such device, Google Play will look at the manifest, see that Red lists the front-facing camera as a requirement, and quietly ignore it, having determined that Red and that device are not a match made in digital heaven. It will then see that Green is not only forward-compatible with devices with API 11 (since no maxSdkVersion was defined), but also doesn’t care whether or not there’s a front-facing camera! The app can still be downloaded -from Android Market by the user, because despite the whole front-camera mishap, there was still an +from Google Play by the user, because despite the whole front-camera mishap, there was still an 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 @@ -330,7 +331,7 @@ Red:11001, 11002, 11003, 11004...</p> </pre> <h2 id="PreLaunch">Go Over Pre-launch Checklist</h2> -<p> Before uploading to Android Market, double-check the following items. Remember that these are specifically relevant to multiple APKs, and in no way represent a complete checklist for all applications being uploaded to Android Market.</p> +<p> Before uploading to Google Play, double-check the following items. Remember that these are specifically relevant to multiple APKs, and in no way represent a complete checklist for all applications being uploaded to Google Play.</p> <ul> <li>All APKs must have the same package name</li> @@ -342,7 +343,7 @@ Red:11001, 11002, 11003, 11004...</p> </ul> <p>It’s also worth inspecting the compiled APK before pushing to market, to make sure there aren’t -any surprises that could hide your application in Market. This is actually quite simple using the +any surprises that could hide your application on Google Play. This is actually quite simple using the "aapt" tool. Aapt (the Android Asset Packaging Tool) is part of the build process for creating and packaging your Android applications, and is also a very handy tool for inspecting them. </p> @@ -370,10 +371,10 @@ densities: '120' '160' '240' supports-screens and compatible-screens, and that you don’t have unintended "uses-feature" values that were added as a result of permissions you set in the manifest. In the example above, the APK won’t be visible to very many devices.</p> -<p>Why? By adding the required permission SEND_SMS, the feature requirement of android.hardware.telephony was implicitly added. Since API 11 is Honeycomb (the version of Android optimized specifically for tablets), and no Honeycomb devices have telephony hardware in them, Market will filter out this APK in all cases, until future devices come along which are higher in API level AND possess telephony hardware. +<p>Why? By adding the required permission SEND_SMS, the feature requirement of android.hardware.telephony was implicitly added. Since API 11 is Honeycomb (the version of Android optimized specifically for tablets), and no Honeycomb devices have telephony hardware in them, Google Play will filter out this APK in all cases, until future devices come along which are higher in API level AND possess telephony hardware. </p> <p>Fortunately this is easily fixed by adding the following to your manifest:</p> <pre> <uses-feature android:name="android.hardware.telephony" android:required="false" /> </pre> -<p>Once you’ve completed the pre-launch checklist, upload your APKs to Android Market. It may take a bit for the application to show up when browsing Android Market, but when it does, perform one last check. Download the application onto any test devices you may have, to make sure that the APKs are targeting the intended devices. Congratulations, you’re done!</p> +<p>Once you’ve completed the pre-launch checklist, upload your APKs to Google Play. It may take a bit for the application to show up when browsing Google Play, but when it does, perform one last check. Download the application onto any test devices you may have, to make sure that the APKs are targeting the intended devices. Congratulations, you’re done!</p> diff --git a/docs/html/training/multiple-apks/index.jd b/docs/html/training/multiple-apks/index.jd index f9b2b43..d92c106 100644 --- a/docs/html/training/multiple-apks/index.jd +++ b/docs/html/training/multiple-apks/index.jd @@ -16,7 +16,7 @@ next.link=api.html <ul> <li>Android 1.0 and higher</li> - <li>You must have an <a href="http://market.android.com/publish">Android Market</a> publisher + <li>You must have an <a href="http://play.google.com/apps/publish">Google Play</a> publisher account</li> </ul> @@ -30,7 +30,7 @@ Support</a></li> </div> </div> -<p>Multiple APK support is a feature in Android Market that allows you to publish multiple APKs +<p>Multiple APK support is a feature of Google Play that allows you to publish multiple APKs under the same application listing. Each APK is a complete instance of your application, optimized to target specific device configurations. Each APK can target a specific set of GL textures, API levels, screen sizes, or some combination thereof.</p> @@ -39,7 +39,7 @@ textures, API levels, screen sizes, or some combination thereof.</p> configuration variables. Each lesson covers basics about how to organize your codebase and target the right devices, as well as the smart way to avoid pitfalls such as unnecessary redundancy across your codebase, and making mistakes in your manifest that could render an APK invisible to all -devices in Android Market. By going through any of these lessons, you'll know how to develop +devices on Google Play. By going through any of these lessons, you'll know how to develop multiple APKs the smart way, make sure they're targeting the devices you want them to, and know how to catch mistakes <em>before</em> your app goes live.</p> diff --git a/docs/html/training/multiple-apks/multiple.jd b/docs/html/training/multiple-apks/multiple.jd index 26a3a93..0c49705 100644 --- a/docs/html/training/multiple-apks/multiple.jd +++ b/docs/html/training/multiple-apks/multiple.jd @@ -40,7 +40,7 @@ Support</a></li> </div> </div> -<p>When developing your Android application to take advantage of multiple APKs on Android Market, +<p>When developing your Android application to take advantage of multiple APKs on Google Play, it’s important to adopt some good practices from the get-go, and prevent unnecessary headaches further into the development process. This lesson shows you how to create multiple APKs of your app, each covering a different class of screen size. You will also gain some tools necessary to @@ -227,7 +227,7 @@ initialization procedures that don’t change much from APK to APK.</p> <h2 id="AdjustManifests">Adjust the Manifests</h2> -<p>When a user downloads an application which uses multiple APKs through Android Market, the correct +<p>When a user downloads an application which uses multiple APKs through Google Play, the correct APK to use is chosen using two simple rules: <ul> @@ -329,17 +329,17 @@ preference as follows:</p> Purple ≥ Red ≥ Green ≥ 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">Market Filters page</a> +other two don’t. The <a href="{@docRoot}guide/appendix/market-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 even HAVE front-facing cameras! The horror!</p> -<p>Fortunately, if a user is browsing Market from one such device, Android Market will look at the +<p>Fortunately, if a user is browsing Google Play from one such device, Google Play will look at the manifest, see that Purple lists the front-facing camera as a requirement, and quietly ignore it, having determined that Purple and that device are not a match made in digital heaven. It will then see that Red is not only compatible with xlarge devices, but also doesn’t care whether or not -there’s a front-facing camera! The app can still be downloaded from Android Market by the user, +there’s a front-facing camera! The app can still be downloaded from Google Play by the user, because despite the whole front-camera mishap, there was still an APK that supported that particular API level.</p> @@ -420,9 +420,9 @@ automatically set to false, since that size didn’t exist yet. So be explicit! </p> <h2 id="PreLaunch">Go Over Pre-launch Checklist</h2> -<p> Before uploading to Android Market, double-check the following items. Remember that these are +<p> Before uploading to Google Play, double-check the following items. Remember that these are specifically relevant to multiple APKs, and in no way represent a complete checklist for all -applications being uploaded to Android Market.</p> +applications being uploaded to Google Play.</p> <ul> <li>All APKs must have the same package name.</li> <li>All APKs must be signed with the same certificate.</li> @@ -439,7 +439,7 @@ customizable device emulators in the business sitting on your development machin </ul> <p>It’s also worth inspecting the compiled APK before pushing to market, to make sure there aren’t -any surprises that could hide your application in Market. This is actually quite simple using the +any surprises that could hide your application on Google Play. This is actually quite simple using the "aapt" tool. Aapt (the Android Asset Packaging Tool) is part of the build process for creating and packaging your Android applications, and is also a very handy tool for inspecting them. </p> @@ -467,11 +467,11 @@ densities: '120' '160' '240' supports-screens and compatible-screens, and that you don’t have unintended "uses-feature" values that were added as a result of permissions you set in the manifest. In the example above, the APK will be invisible to most, if not all devices.</p> -<p>Why? By adding the required permission SEND_SMS, the feature requirement of android.hardware.telephony was implicitly added. Since most (if not all) xlarge devices are tablets without telephony hardware in them, Market will filter out this APK in these cases, until future devices come along which are both large enough to report as xlarge screen size, and possess telephony hardware. +<p>Why? By adding the required permission SEND_SMS, the feature requirement of android.hardware.telephony was implicitly added. Since most (if not all) xlarge devices are tablets without telephony hardware in them, Google Play will filter out this APK in these cases, until future devices come along which are both large enough to report as xlarge screen size, and possess telephony hardware. </p> <p>Fortunately this is easily fixed by adding the following to your manifest:<p> <pre> <uses-feature android:name="android.hardware.telephony" android:required="false" /> </pre> -<p>Once you’ve completed the pre-launch checklist, upload your APKs to Android Market. It may take a bit for the application to show up when browsing Android Market, but when it does, perform one last check. Download the application onto any test devices you may have to make sure that the APKs are targeting the intended devices. Congratulations, you’re done!</p> +<p>Once you’ve completed the pre-launch checklist, upload your APKs to Google Play. It may take a bit for the application to show up when browsing Google Play, but when it does, perform one last check. Download the application onto any test devices you may have to make sure that the APKs are targeting the intended devices. Congratulations, you’re done!</p> diff --git a/docs/html/training/multiple-apks/screensize.jd b/docs/html/training/multiple-apks/screensize.jd index 0ed972a..cbf17c5 100644 --- a/docs/html/training/multiple-apks/screensize.jd +++ b/docs/html/training/multiple-apks/screensize.jd @@ -43,7 +43,7 @@ Support</a></li> </div> -<p>When developing your Android application to take advantage of multiple APKs on Android Market, +<p>When developing your Android application to take advantage of multiple APKs on Google Play, it’s important to adopt some good practices from the get-go, and prevent unnecessary headaches further into the development process. This lesson shows you how to create multiple APKs of your app, each covering a different class of screen size. You will also gain some tools necessary to @@ -178,7 +178,7 @@ initialization procedures that don’t change much from APK to APK.</p> <h2 id="AdjustManifests">Adjust the Manifests</h2> -<p>When a user downloads an application which uses multiple APKs through Android Market, the correct +<p>When a user downloads an application which uses multiple APKs through Google Play, the correct APK to use is chosen using two simple rules:</p> <ul> <li>The manifest has to show that particular APK is eligible</li> @@ -227,17 +227,17 @@ each APK such that red ≥ green ≥ 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">Market Filters page</a> of the Android +<a href="{@docRoot}guide/appendix/market-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, not all xlarge devices even HAVE front-facing cameras! The horror!</p> -<p>Fortunately, if a user is browsing Market from one such device, Android Market will look at the +<p>Fortunately, if a user is browsing Google Play from one such device, Google Play will look at the manifest, see that Red lists the front-facing camera as a requirement, and quietly ignore it, having determined that Red and that device are not a match made in digital heaven. It will then see that Green is not only compatible with xlarge devices, but also doesn’t care whether or not there’s a -front-facing camera! The app can still be downloaded from Android Market by the user, because +front-facing camera! The app can still be downloaded from Google Play by the user, because despite the whole front-camera mishap, there was still an APK that supported that particular screen size.</p> @@ -300,9 +300,9 @@ So be explicit! </p> <h2 id="PreLaunch">Go Over Pre-launch Checklist</h2> -<p> Before uploading to Android Market, double-check the following items. Remember that these are +<p> Before uploading to Google Play, double-check the following items. Remember that these are specifically relevant to multiple APKs, and in no way represent a complete checklist for all -applications being uploaded to Android Market.</p> +applications being uploaded to Google Play.</p> <ul> <li>All APKs must have the same package name</li> <li>All APKs must be signed with the same certificate</li> @@ -317,7 +317,7 @@ customizable device emulators in the business sitting on your development machin </ul> <p>It’s also worth inspecting the compiled APK before pushing to market, to make sure there aren’t -any surprises that could hide your application in Market. This is actually quite simple using the +any surprises that could hide your application on Google Play. This is actually quite simple using the "aapt" tool. Aapt (the Android Asset Packaging Tool) is part of the build process for creating and packaging your Android applications, and is also a very handy tool for inspecting them. </p> @@ -345,11 +345,11 @@ densities: '120' '160' '240' supports-screens and compatible-screens, and that you don’t have unintended "uses-feature" values that were added as a result of permissions you set in the manifest. In the example above, the APK will be invisible to most, if not all devices.</p> -<p>Why? By adding the required permission SEND_SMS, the feature requirement of android.hardware.telephony was implicitly added. Since most (if not all) xlarge devices are tablets without telephony hardware in them, Market will filter out this APK in these cases, until future devices come along which are both large enough to report as xlarge screen size, and possess telephony hardware. +<p>Why? By adding the required permission SEND_SMS, the feature requirement of android.hardware.telephony was implicitly added. Since most (if not all) xlarge devices are tablets without telephony hardware in them, Google Play will filter out this APK in these cases, until future devices come along which are both large enough to report as xlarge screen size, and possess telephony hardware. </p> <p>Fortunately this is easily fixed by adding the following to your manifest:</p> <pre> <uses-feature android:name="android.hardware.telephony" android:required="false" /> </pre> -<p>Once you’ve completed the pre-launch checklist, upload your APKs to Android Market. It may take a bit for the application to show up when browsing Android Market, but when it does, perform one last check. Download the application onto any test devices you may have to make sure that the APKs are targeting the intended devices. Congratulations, you’re done!</p> +<p>Once you’ve completed the pre-launch checklist, upload your APKs to Google Play. It may take a bit for the application to show up when browsing Google Play, but when it does, perform one last check. Download the application onto any test devices you may have to make sure that the APKs are targeting the intended devices. Congratulations, you’re done!</p> diff --git a/docs/html/training/multiple-apks/texture.jd b/docs/html/training/multiple-apks/texture.jd index 2bbe511..0dbee61 100644 --- a/docs/html/training/multiple-apks/texture.jd +++ b/docs/html/training/multiple-apks/texture.jd @@ -40,7 +40,7 @@ Support</a></li> </div> </div> -<p>When developing your Android application to take advantage of multiple APKs on Android Market, it’s important to adopt some good practices from the get-go, and prevent unnecessary headaches further into the development process. This lesson shows you how to create multiple APKs of your app, each supporting a different subset of OpenGL texture formats. You will also gain some tools necessary to make maintaining a multiple APK codebase as painless as possible.</p> +<p>When developing your Android application to take advantage of multiple APKs on Google Play, it’s important to adopt some good practices from the get-go, and prevent unnecessary headaches further into the development process. This lesson shows you how to create multiple APKs of your app, each supporting a different subset of OpenGL texture formats. You will also gain some tools necessary to make maintaining a multiple APK codebase as painless as possible.</p> <h2 id="Confirm">Confirm You Need Multiple APKs</h2> @@ -158,7 +158,7 @@ initialization procedures that don’t change much from APK to APK.</p> <h2 id="AdjustManifests">Adjust the Manifests</h2> -<p>When a user downloads an application which uses multiple APKs through Android Market, the correct +<p>When a user downloads an application which uses multiple APKs through Google Play, the correct APK to use is chosen using some simple rules:</p> <ul> @@ -246,9 +246,9 @@ following:</p> </pre> <h2 id="PreLaunch">Go Over Pre-launch Checklist</h2> -<p>Before uploading to Android Market, double-check the following items. Remember that these are +<p>Before uploading to Google Play, double-check the following items. Remember that these are specifically relevant to multiple APKs, and in no way represent a complete checklist for all -applications being uploaded to Android Market.</p> +applications being uploaded to Google Play.</p> <ul> <li>All APKs must have the same package name</li> @@ -262,7 +262,7 @@ customizable device emulators in the business sitting on your development machin </ul> <p>It’s also worth inspecting the compiled APK before pushing to market, to make sure there aren’t -any surprises that could hide your application in Market. This is actually quite simple using the +any surprises that could hide your application on Google Play. This is actually quite simple using the "aapt" tool. Aapt (the Android Asset Packaging Tool) is part of the build process for creating and packaging your Android applications, and is also a very handy tool for inspecting them. </p> @@ -290,10 +290,10 @@ densities: '120' '160' '240' supports-screens and compatible-screens, and that you don’t have unintended "uses-feature" values that were added as a result of permissions you set in the manifest. In the example above, the APK will be invisible to most, if not all devices.</p> -<p>Why? By adding the required permission SEND_SMS, the feature requirement of android.hardware.telephony was implicitly added. Since most (if not all) xlarge devices are tablets without telephony hardware in them, Market will filter out this APK in these cases, until future devices come along which are both large enough to report as xlarge screen size, and possess telephony hardware. +<p>Why? By adding the required permission SEND_SMS, the feature requirement of android.hardware.telephony was implicitly added. Since most (if not all) xlarge devices are tablets without telephony hardware in them, Google Play will filter out this APK in these cases, until future devices come along which are both large enough to report as xlarge screen size, and possess telephony hardware. </p> <p>Fortunately this is easily fixed by adding the following to your manifest:</p> <pre> <uses-feature android:name="android.hardware.telephony" android:required="false" /> </pre> -<p>Once you’ve completed the pre-launch checklist, upload your APKs to Android Market. It may take a bit for the application to show up when browsing Android Market, but when it does, perform one last check. Download the application onto any test devices you may have to make sure that the APKs are targeting the intended devices. Congratulations, you’re done!</p> +<p>Once you’ve completed the pre-launch checklist, upload your APKs to Google Play. It may take a bit for the application to show up when browsing Google Play, but when it does, perform one last check. Download the application onto any test devices you may have to make sure that the APKs are targeting the intended devices. Congratulations, you’re done!</p> diff --git a/docs/html/training/sharing/receive.jd b/docs/html/training/sharing/receive.jd index cc55967..a0a5bc8 100644 --- a/docs/html/training/sharing/receive.jd +++ b/docs/html/training/sharing/receive.jd @@ -34,7 +34,7 @@ Intent Filters</a></li> from applications. Think about how users interact with your application, and what data types you want to receive from other applications. For example, a social networking application would likely be interested in receiving text content, like an interesting web URL, from another app. The -<a href="https://market.android.com/details?id=com.google.android.apps.plus">Google+ Android +<a href="https://play.google.com/store/details?id=com.google.android.apps.plus">Google+ Android application</a> accepts both text <em>and</em> single or multiple images. With this app, a user can easily start a new Google+ post with photos from the Android Gallery app.</p> |