Android/frameworks_base
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

am a18ff6f1: am f809e96f: am 1a15b24b: am 012ef92e: Merge "Doc change: Remove refs to Copy Protection and note EOL in GP." into jb-mr1-dev

Browse Source 
* commit 'a18ff6f1ae45c4553e7d2e0c65a5b347bbb370e4':
  Doc change: Remove refs to Copy Protection and note EOL in GP.
This commit is contained in:
Dirk Dougherty
2013-02-26 10:47:54 -08:00
committed by Android Git Automerger
parent c22657f8b1 a18ff6f1ae
commit 0db6a9e9a6
16 changed files with 53 additions and 276 deletions
Download Patch File Download Diff File Expand all files Collapse all files

21
docs/html/distribute/googleplay/about/distribution.jd
View File

@@ -125,7 +125,20 @@ download of the files as part of the normal APK installation.</p>
<h2 id="licensing">Protecting your App</h2>
<p>To help you protect your application against piracy, Google Play offers a
licensing service that you can implement in your app. It’s a network-based
service that lets an application query a trusted Google Play licensing server to
determine whether the application is licensed to the current device user.</p>
<p>Google Play provides two key features to help you protect your application
against piracy &mdash; Google Play Licensing and app encryption.</p>
<p> Google Play Licensing is a network-based service that you implement in your
app. The service lets your app query a trusted licensing server at runtime, to
determine whether the app is licensed to the current device user. You can use
the licensing service to protect any app, even apps that you distribute for
free. For an overview of the service, see <a
href="{@docRoot}google/play/licensing/index.html">Application
Licensing</a>.</p>
<p>Additionally, Google Play offers app encryption to help protect your priced
apps. When delivering your priced apps to devices running Android 4.1 or higher,
Google encrypts the app binary so that it can be run only by the user who
downloaded it, on the device to which it was originally downloaded. Your priced
apps benefit from app encryption automatically &mdash; there's no extra
development work or configuration needed.</p>

2
docs/html/google/play/billing/billing_reference.jd
View File

@@ -166,7 +166,7 @@ does not include tax.</td>
</tr>
<tr>
<td>{@code productId}</td>
<td>The item's product identifier. Every item has a product ID, which you must specify in the application's product list on the Google Play publisher site.</td>
<td>The item's product identifier. Every item has a product ID, which you must specify in the application's product list on the Google Play Developer Console.</td>
</tr>
<tr>
<td>{@code purchaseTime}</td>

8
docs/html/google/play/billing/billing_testing.jd
View File

@@ -18,7 +18,7 @@ parent.link=index.html
</div>
</div>
<p>The Google Play publisher site provides several tools that help you test your In-app Billing
<p>The Google Play Developer Console provides several tools that help you test your In-app Billing
implementation before it is published. You can use these tools to create test accounts and purchase
special reserved items that send static billing responses to your application.</p>
@@ -53,7 +53,7 @@ product ID android.test.purchased.</p>
<p>You do not need to list the reserved products in your application's product list. Google Play
already knows about the reserved product IDs. Also, you do not need to upload your application to
the publisher site to perform static response tests with the reserved product IDs. You can simply
the Developer Console to perform static response tests with the reserved product IDs. You can simply
install your application on a device, log into the device, and make billing requests using the
reserved product IDs.</p>
@@ -199,7 +199,7 @@ testing. You only need to upload your application as a draft application to perf
testing.</p>
<p>To test your In-app Billing implementation with actual in-app purchases, you will need to
register at least one test account on the Google Play publisher site. You cannot use your
register at least one test account on the Google Play Developer Console. You cannot use your
developer account to test the complete in-app purchase process because Google Checkout does not let
you buy items from yourself. If you have not set up test accounts before, see <a
href="{@docRoot}google/play/billing/billing_admin.html#billing-testing-setup">Setting up test
@@ -216,7 +216,7 @@ actual payouts to your merchant account.</p>
<p>To test your In-app Billing implementation with actual purchases, follow these steps:</p>
<ol>
<li><strong>Upload your application as a draft application to the publisher site.</strong>
<li><strong>Upload your application as a draft application to the Developer Console.</strong>
<p>You do not need to publish your application to perform end-to-end testing with real product
IDs; you only need to upload your application as a draft application. However, you must sign
your application with your release key before you upload it as a draft application. Also, the

6
docs/html/google/play/billing/v2/billing_integrate.jd
View File

@@ -204,7 +204,7 @@ following:</p>
<h3>Uploading the sample application</h3>
<p>After you build a release version of the sample application and sign it, you need to upload it as
a draft to the Google Play publisher site. You also need to create a product list for the in-app
a draft to the Google Play Developer Console. You also need to create a product list for the in-app
items that are available for purchase in the sample application. The following instructions show you
how to do this.</p>
<ol>
@@ -263,7 +263,7 @@ onto a device to run it. To run the sample application, do the following:</p>
<li><strong>Make one of your test accounts the primary account on your device.</strong>
<p>The primary account on your device must be one of the <a
href="{@docRoot}google/play/billing/billing_admin.html#billing-testing-setup">test accounts</a>
that you registered on the Google Play publisher site. If the primary account on your device is not a
that you registered on the Google Play Developer Console. If the primary account on your device is not a
test account, you must do a factory reset of the device and then sign in with one of your test
accounts. To perform a factory reset, do the following:</p>
<ol>
@@ -979,7 +979,7 @@ href="{@docRoot}google/play/billing/billing_best_practices.html">Security and De
<p>To help ensure the integrity of the transaction information that is sent to your application,
Google Play signs the JSON string that is contained in the <code>PURCHASE_STATE_CHANGED</code>
broadcast intent. Google Play uses the private key that is associated with your publisher account
to create this signature. The publisher site generates an RSA key pair for each publisher account.
to create this signature. The Developer Console generates an RSA key pair for each publisher account.
You can find the public key portion of this key pair on your account's profile page. It is the same
public key that is used with Google Play licensing.</p>

4
docs/html/google/play/billing/v2/billing_reference.jd
View File

@@ -143,7 +143,7 @@ pairs, which are summarized in table 7.</p>
<td>Required for <code>REQUEST_PURCHASE</code> requests.</td>
<td>The product ID of the item you are making a billing request for. Every in-app item that you
sell using Google Play's In-app Billing service must have a unique product ID, which you
specify on the Google Play publisher site.</td>
specify on the Google Play Developer Console.</td>
</tr>
<tr>
<td><code>NONCE</code></td>
@@ -380,7 +380,7 @@ a <code>PURCHASE_STATE_CHANGED</code> intent.</p>
<tr>
<td>productId</td>
<td>The item's product identifier. Every item has a product ID, which you must specify in the
application's product list on the Google Play publisher site.</td>
application's product list on the Google Play Developer Console.</td>
</tr>
<tr>
<td>purchaseTime</td>

13
docs/html/google/play/filters.jd
View File

@@ -192,7 +192,7 @@ default.</li>
Configuration: <br />
keyboard, navigation, touch screen</td>
<td valign="top"><p>An application can
request certain hardware features, and Google Play will show the app only on devices that have the required hardware.</p>
request certain hardware features, and Google Play will show the app only on devices that have the required hardware.</p>
<p><strong>Example 1<br />
</strong>The manifest includes <code>&lt;uses-configuration android:reqFiveWayNav=&quot;true&quot; /&gt;</code>, and a user is searching for apps on a device that does not have a five-way navigational control. <strong>Result</strong>: Google Play will not show the app to the user. </p>
<p><strong>Example 2<br />
@@ -399,12 +399,11 @@ country (as determined by SIM carrier) in which paid apps are available.</p></td
visible only on devices that support that platform. For details about the NDK and using
native libraries, see <a href="{@docRoot}tools/sdk/ndk/index.html#overview">What is the
Android NDK?</a></p> </tr> <tr>
<td valign="top">Copy-Protected Applications</td> <td valign="top"><p>To
copy protect an application, set copy protection to "On" when you configure publishing
options for your application. Google Play will not show copy-protected applications on
developer devices or unreleased devices.</p></td> </tr> </table>
<td valign="top">Copy-Protected Applications</td> <td valign="top"><p class="caution">Google
Play no longer supports the Copy Protection feature in the Developer Console and no longer
filters apps based on it. To secure your app, please use <a href="{@docRoot}google/play/licensing/index.html">
Application Licensing</a> instead. See <a href="{@docRoot}google/play/licensing/overview.html#CopyProtection">
Replacement for Copy Protection</a> for more information.</p></td> </tr> </table>
<h2 id="MultiApks">Publishing Multiple APKs with Different Filters</h2>

18
docs/html/google/play/licensing/adding-licensing.jd
View File

@@ -39,11 +39,7 @@ to close IPC connections</a></li>
</li>
<li><a href="#impl-DeviceLimiter">Implementing a DeviceLimiter</a></li>
<li><a href="#app-obfuscation">Obfuscating Your Code</a></li>
<li><a href="#app-publishing">Publishing a Licensed Application</a>
<ol>
<li><a href="#">Removing Copy Protection</a></li>
</ol>
</li>
<li><a href="#app-publishing">Publishing a Licensed Application</a></li>
<li><a href="#support">Where to Get Support</a></li>
</ol>
@@ -864,7 +860,7 @@ shared across all applications that are published through the account. Although
associated with a publisher account, the key pair is <em>not</em> the same as
the key that you use to sign your applications (or derived from it).</p>
<p>The Google Play publisher site exposes the public key for licensing to any
<p>The Google Play Developer Console exposes the public key for licensing to any
developer signed in to the publisher account, but it keeps the private key
hidden from all users in a secure location. When an application requests a
license check for an application published in your account, the licensing server
@@ -878,7 +874,7 @@ your account's public key for licensing:</p>
<ol>
<li>Go to the Google Play <a
href="http://play.google.com/apps/publish">publisher site</a> and sign in.
href="http://play.google.com/apps/publish">Developer Console</a> and sign in.
Make sure that you sign in to the account from which the application you are
licensing is published (or will be published). </li>
<li>In the account home page, locate the "Edit profile" link and click it. </li>
@@ -1003,14 +999,6 @@ href="{@docRoot}tools/publishing/app-signing.html">sign</a>, and then <a
href="{@docRoot}distribute/googleplay/publish/preparing.html">publish the application</a>.
</p>
<h3>Removing Copy Protection</h3>
<p>After uploading your licensed application, remember to remove copy protection
from the application, if it is currently used. To check and remove copy
protection, sign in to the publisher site and go the application's upload
details page. In the Publishing options section, make sure that the Copy
Protection radio button selection is "Off".</p>
<h2 id="support">Where to Get Support</h2>

2
docs/html/google/play/licensing/licensing-reference.jd
View File

@@ -233,7 +233,7 @@ implementation.</p>
href="{@docRoot}google/play/licensing/setting-up.html#test-env">
Setting Up The Testing Environment</a>, the response code can be manually
overridden for the application developer and any registered test users via the
Google Play publisher site.
Google Play Developer Console.
<br/><br/>
Additionally, as noted above, applications that are in draft mode (in other
words, applications that have been uploaded but have <em>never</em> been

22
docs/html/google/play/licensing/overview.jd
View File

@@ -215,21 +215,15 @@ href="{@docRoot}google/play/expansion-files.html">APK expansion files</a>.</li>
<p>Google Play Licensing is a flexible, secure mechanism for controlling
access to your applications. It effectively replaces the Copy Protection
mechanism offered on Google Play and gives you wider distribution
potential for your applications. </p>
mechanism (no longer supported) that was previously offered on Google Play and
gives you wider distribution potential for your applications. </p>
<ul>
<li>A limitation of the legacy Copy Protection mechanism on Google Play is
that applications using it can be installed only on compatible devices that
provide a secure internal storage environment. For example, a copy-protected
application cannot be downloaded from Google Play to a device that provides root
access, and the application cannot be installed to a device's SD card. </li>
<li>With Google Play licensing, you can move to a license-based model in
which access is not bound to the characteristics of the host device, but to your
publisher account on Google Play and the licensing policy that you define.
Your application can be installed and controlled on any compatible device on
any storage, including SD card.</li>
</ul>
<p>Licensing lets you move to a license-based model that is enforceable on
all devices that have access to Google Play. Access is not bound to the
characteristics of the host device, but to your
publisher account on Google Play (through the app's public key) and the
licensing policy that you define. Your application can be installed and
managed on any device on any storage, including SD card.</p>
<p>Although no license mechanism can completely prevent all unauthorized use,
the licensing service lets you control access for most types of normal usage,

8
docs/html/google/play/publishing/multiple-apks.jd
View File

@@ -103,7 +103,7 @@ consider your options before publishing multiple APKs.</p>
<h2 id="Concepts">Publishing Concepts</h2>
<p>Before you start publishing multiple APKs on Google Play, you must understand a few
concepts regarding how the Google Play publisher site works.</p>
concepts regarding how the Google Play Developer Console works.</p>
<h3 id="Active">Active APKs</h3>
@@ -118,7 +118,7 @@ button says <strong>Publish</strong>. Clicking it will publish any APKs listed a
Active, making them available on Google Play. Also while your application is new
or unpublished, clicking <strong>Save</strong> will save any changes you've made, such
as information added to the Product details and APKs you've uploaded, but nothing is made visible on
Google Play&mdash;this allows you to save your changes and sign out of the publisher site before
Google Play&mdash;this allows you to save your changes and sign out of the Developer Console before
deciding to publish.</p>
<p>Once you've published your application, the first button changes to
<strong>Unpublish</strong>. Clicking it in this state unpublishes your application so that none
@@ -144,7 +144,7 @@ already published).</p>
<h3 id="SimpleAndAdvanced">Simple mode and advanced mode</h3>
<p>The Google Play publisher site provides two modes for managing the APKs associated with
<p>The Google Play Developer Console provides two modes for managing the APKs associated with
your application: <em>simple mode</em> and <em>advanced mode</em>. You can switch between these by
clicking the
link at the top-right corner of the <strong>APK files</strong> tab.</p>
@@ -388,7 +388,7 @@ ARMv7 libraries, and not when comparing other native libraries.</li>
</ul>
<p>Failure to abide by the above rules results in an error on the Google Play publisher site
<p>Failure to abide by the above rules results in an error on the Google Play Developer Console
when you activate your APKs&mdash;you will be unable to publish your application until you
resolve the error.</p>

206
docs/html/guide/appendix/install-location.jd
View File

@@ -1,206 +0,0 @@
page.title=App Install Location
@jd:body
<div id="qv-wrapper">
<div id="qv">
<h2>Quickview</h2>
<ul>
<li>You can allow your application to install on the device's external storage.</li>
<li>Some types of applications should <strong>not</strong> allow installation on the external
storage.</li>
<li>Installing on the external storage is ideal for large applications that are not tightly
integrated with the system (most commonly, games).</li>
</ul>
<h2>In this document</h2>
<ol>
<li><a href="#Compatiblity">Backward Compatibility</a></li>
<li><a href="#ShouldNot">Applications That Should NOT Install on External Storage</a></li>
<li><a href="#Should">Applications That Should Install on External Storage</a></li>
</ol>
<h2>See also</h2>
<ol>
<li><code><a href="{@docRoot}guide/topics/manifest/manifest-element.html">
&lt;manifest&gt;</a></code></li>
</ol>
</div>
</div>
<p>Beginning with API Level 8, you can allow your application to be installed on the
external storage (for example, the device's SD card). This is an optional feature you can declare
for your application with the <a
href="{@docRoot}guide/topics/manifest/manifest-element.html#install">{@code
android:installLocation}</a> manifest attribute. If you do
<em>not</em> declare this attribute, your application will be installed on the internal storage
only and it cannot be moved to the external storage.</p>
<p>To allow the system to install your application on the external storage, modify your
manifest file to include the <a
href="{@docRoot}guide/topics/manifest/manifest-element.html#install">{@code
android:installLocation}</a> attribute in the <code><a
href="{@docRoot}guide/topics/manifest/manifest-element.html">&lt;manifest&gt;</a></code> element,
with a value of either "{@code preferExternal}" or "{@code auto}". For example:</p>
<pre>
&lt;manifest xmlns:android="http://schemas.android.com/apk/res/android"
android:installLocation="preferExternal"
... &gt;
</pre>
<p>If you declare "{@code preferExternal}", you request that your application be installed on the
external storage, but the system does not guarantee that your application will be installed on
the external storage. If the external storage is full, the system will install it on the internal
storage. The user can also move your application between the two locations.</p>
<p>If you declare "{@code auto}", you indicate that your application may be installed on the
external storage, but you don't have a preference of install location. The system will
decide where to install your application based on several factors. The user can also move your
application between the two locations.</p>
<p>When your application is installed on the external storage:</p>
<ul>
<li>There is no effect on the application performance so long
as the external storage is mounted on the device.</li>
<li>The {@code .apk} file is saved on the external storage, but all private user data,
databases, optimized {@code .dex} files, and extracted native code are saved on the
internal device memory.</li>
<li>The unique container in which your application is stored is encrypted with a randomly
generated key that can be decrypted only by the device that originally installed it. Thus, an
application installed on an SD card works for only one device.</li>
<li>The user can move your application to the internal storage through the system settings.</li>
</ul>
<p class="warning"><strong>Warning:</strong> When the user enables USB mass storage to share files
with a computer or unmounts the SD card via the system settings, the external storage is unmounted
from the device and all applications running on the external storage are immediately killed.</p>
<h2 id="Compatiblity">Backward Compatibility</h2>
<p>The ability for your application to install on the external storage is a feature available only
on devices running API Level 8 (Android 2.2) or greater. Existing applications that were built prior
to API Level 8 will always install on the internal storage and cannot be moved to the external
storage (even on devices with API Level 8). However, if your application is designed to support an
API Level <em>lower than</em> 8, you can choose to support this feature for devices with API Level 8
or greater and still be compatible with devices using an API Level lower than 8.</p>
<p>To allow installation on external storage and remain compatible with versions lower than API
Level 8:</p>
<ol>
<li>Include the {@code android:installLocation} attribute with a value of "{@code auto}" or
"{@code preferExternal}" in the <code><a
href="{@docRoot}guide/topics/manifest/uses-sdk-element.html">&lt;manifest&gt;</a></code>
element.</li>
<li>Leave your {@code android:minSdkVersion} attribute as is (something <em>less
than</em> "8") and be certain that your application code uses only APIs compatible with that
level.</li>
<li>In order to compile your application, change your build target to API Level 8. This is
necessary because older Android libraries don't understand the {@code android:installLocation}
attribute and will not compile your application when it's present.</li>
</ol>
<p>When your application is installed on a device with an API Level lower than 8, the {@code
android:installLocation} attribute is ignored and the application is installed on the internal
storage.</p>
<p class="caution"><strong>Caution:</strong> Although XML markup such as this will be ignored by
older platforms, you must be careful not to use programming APIs introduced in API Level 8
while your {@code minSdkVersion} is less than "8", unless you perform the work necessary to
provide backward compatibility in your code. For information about building
backward compatibility in your application code, see the <a
href="{@docRoot}resources/articles/backward-compatibility.html">Backward Compatibility</a>
article.</p>
<h2 id="ShouldNot">Applications That Should NOT Install on External Storage</h2>
<p>When the user enables USB mass storage to share files with their computer (or otherwise
unmounts or removes the external storage), any application
installed on the external storage and currently running is killed. The system effectively becomes
unaware of the application until mass storage is disabled and the external storage is
remounted on the device. Besides killing the application and making it unavailable to the user,
this can break some types of applications in a more serious way. In order for your application to
consistently behave as expected, you <strong>should not</strong> allow your application to be
installed on the external storage if it uses any of the following features, due to the cited
consequences when the external storage is unmounted:</p>
<dl>
<dt>Services</dt>
<dd>Your running {@link android.app.Service} will be killed and will not be restarted when
external storage is remounted. You can, however, register for the {@link
android.content.Intent#ACTION_EXTERNAL_APPLICATIONS_AVAILABLE} broadcast Intent, which will notify
your application when applications installed on external storage have become available to the
system again. At which time, you can restart your Service.</dd>
<dt>Alarm Services</dt>
<dd>Your alarms registered with {@link android.app.AlarmManager} will be cancelled. You must
manually re-register any alarms when external storage is remounted.</dd>
<dt>Input Method Engines</dt>
<dd>Your <a href="{@docRoot}resources/articles/on-screen-inputs.html">IME</a> will be
replaced by the default IME. When external storage is remounted, the user can open system settings
to enable your IME again.</dd>
<dt>Live Wallpapers</dt>
<dd>Your running <a href="{@docRoot}resources/articles/live-wallpapers.html">Live Wallpaper</a>
will be replaced by the default Live Wallpaper. When external storage is remounted, the user can
select your Live Wallpaper again.</dd>
<dt>Live Folders</dt>
<dd>Your <a href="{@docRoot}resources/articles/live-folders.html">Live Folder</a> will be
removed from the home screen. When external storage is remounted, the user can add your Live Folder
to the home screen again.</dd>
<dt>App Widgets</dt>
<dd>Your <a href="{@docRoot}guide/topics/appwidgets/index.html">App Widget</a> will be removed
from the home screen. When external storage is remounted, your App Widget will <em>not</em> be
available for the user to select until the system resets the home application (usually not until a
system reboot).</dd>
<dt>Account Managers</dt>
<dd>Your accounts created with {@link android.accounts.AccountManager} will disappear until
external storage is remounted.</dd>
<dt>Sync Adapters</dt>
<dd>Your {@link android.content.AbstractThreadedSyncAdapter} and all its sync functionality will
not work until external storage is remounted.</dd>
<dt>Device Administrators</dt>
<dd>Your {@link android.app.admin.DeviceAdminReceiver} and all its admin capabilities will
be disabled, which can have unforeseeable consequences for the device functionality, which may
persist after external storage is remounted.</dd>
<dt>Broadcast Receivers listening for "boot completed"</dt>
<dd>The system delivers the {@link android.content.Intent#ACTION_BOOT_COMPLETED} broadcast
before the external storage is mounted to the device. If your application is installed on the
external storage, it can never receive this broadcast.</dd>
<dt>Copy Protection</dt>
<dd>Your application cannot be installed to a device's SD card if it uses Google Play's
Copy Protection feature. However, if you use Google Play's
<a href="{@docRoot}google/play/licensing.html">Application Licensing</a> instead, your
application <em>can</em> be installed to internal or external storage, including SD cards.</dd>
</dl>
<p>If your application uses any of the features listed above, you <strong>should not</strong> allow
your application to install on external storage. By default, the system <em>will not</em> allow your
application to install on the external storage, so you don't need to worry about your existing
applications. However, if you're certain that your application should never be installed on the
external storage, then you should make this clear by declaring <a
href="{@docRoot}guide/topics/manifest/manifest-element.html#install">{@code
android:installLocation}</a> with a value of "{@code internalOnly}". Though this does not
change the default behavior, it explicitly states that your application should only be installed
on the internal storage and serves as a reminder to you and other developers that this decision has
been made.</p>
<h2 id="Should">Applications That Should Install on External Storage</h2>
<p>In simple terms, anything that does not use the features listed in the previous section
are safe when installed on external storage. Large games are more commonly the types of
applications that should allow installation on external storage, because games don't typically
provide additional services when inactive. When external storage becomes unavailable and a game
process is killed, there should be no visible effect when the storage becomes available again and
the user restarts the game (assuming that the game properly saved its state during the normal
<a href="{@docRoot}guide/components/activities.html#Lifecycle">Activity lifecycle</a>).</p>
<p>If your application requires several megabytes for the APK file, you should
carefully consider whether to enable the application to install on the external storage so that
users can preserve space on their internal storage.</p>

5
docs/html/guide/topics/data/install-location.jd
View File

@@ -164,11 +164,6 @@ persist after external storage is remounted.</dd>
<dd>The system delivers the {@link android.content.Intent#ACTION_BOOT_COMPLETED} broadcast
before the external storage is mounted to the device. If your application is installed on the
external storage, it can never receive this broadcast.</dd>
<dt>Copy Protection</dt>
<dd>Your application cannot be installed to a device's SD card if it uses Google Play's
Copy Protection feature. However, if you use Google Play's
<a href="{@docRoot}google/play/licensing/index.html">Application Licensing</a> instead, your
application <em>can</em> be installed to internal or external storage, including SD cards.</dd>
</dl>
<p>If your application uses any of the features listed above, you <strong>should not</strong> allow

8
docs/html/guide/topics/manifest/manifest-element.jd
View File

@@ -144,17 +144,11 @@ to either internal or external storage through the system settings.</td>
<td>"{@code preferExternal}"</td>
<td>The application prefers to be installed on the external storage (SD card). There is no
guarantee that the system will honor this request. The application might be installed on internal
storage if the external media is unavailable or full, or if the application uses the forward-locking
mechanism (not supported on external storage). Once installed, the user can move the application to
storage if the external media is unavailable or full. Once installed, the user can move the application to
either internal or external storage through the system settings.</td>
</tr>
</table>
<p class="caution"><strong>Caution:</strong> If your application uses Google Play's Copy
Protection feature, it cannot be installed to a device's SD card. However, if you use Google
Play's <a href="{@docRoot}google/play/licensing/index.html">Application Licensing</a> instead,
your application <em>can</em> be installed to internal or external storage, including SD cards.</p>
<p class="note"><strong>Note:</strong> By default, your application will be installed on the
internal storage and cannot be installed on the external storage unless you define this attribute
to be either "{@code auto}" or "{@code preferExternal}".</p>

2
docs/html/guide/topics/manifest/supports-gl-texture-element.jd
View File

@@ -162,7 +162,7 @@ an application declares its supported texture compression formats in
a device reports the formats it supports as read-only system properties.</li>
</ul>
<p>Each time you upload an application to the Google Play publisher site,
<p>Each time you upload an application to the Google Play Developer Console,
Google Play scans the application's manifest file and looks for any
<code>&lt;supports-gl-texture&gt;</code> elements. It extracts the
format descriptors from the elements and stores them internally as

2
docs/html/guide/topics/manifest/uses-feature-element.jd
View File

@@ -237,7 +237,7 @@ Package Manager for the list of features available on the device by calling
Store application then passes the features list up to Google Play
when establishing the session for the user.</p>
<p>Each time you upload an application to the Google Play publisher site,
<p>Each time you upload an application to the Google Play Developer Console,
Google Play scans the application's manifest file. It looks for
<code>&lt;uses-feature&gt;</code> elements and evaluates them in combination
with other elements, in some cases, such as <code>&lt;uses-sdk&gt;</code> and

2
docs/html/tools/extras/oem-usb.jd
View File

@@ -211,7 +211,7 @@ exact location of the
<h2 id="Drivers">OEM Drivers</h2>
<p class="note"><strong>Note:</strong> If your device is one of the Android Developer Phones
(purchased from the Google Play publisher site), a Nexus One, or a Nexus S, then you need
(purchased from the Google Play Developer Console), a Nexus One, or a Nexus S, then you need
the <a href="{@docRoot}sdk/win-usb.html">Google USB Driver</a>, instead of an OEM driver. The Galaxy
Nexus driver, however, is distributed by <a
href="http://www.samsung.com/us/support/downloads/verizon-wireless/SCH-I515MSAVZW">Samsung</a>