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

Docs: Migration of app-links doc from Preview to permanent Android 6.0 location

Browse Source 
Bug: 23623573

Change-Id: Ie5748494af893a872241f21e4137f768ff4ca1ff
This commit is contained in:
David Friedman
2015-09-28 10:31:30 -07:00
parent 1c9f69fab6
commit 73ff05fb39
2 changed files with 196 additions and 229 deletions
Download Patch File Download Diff File Expand all files Collapse all files

344
docs/html/training/app-links/index.jd
View File

@@ -1,4 +1,4 @@
page.title=App Links
page.title=Handling App Links
page.image=images/cards/card-app-linking_2x.png
page.keywords=applinking, deeplinks, intents
@jd:body
@@ -7,11 +7,11 @@ page.keywords=applinking, deeplinks, intents
<div id="tb">
<h2>This lesson teaches you to</h2>
<ol>
<li><a href="#url-handling">Understanding URL Request Handling</a> </li>
<li><a href="#intent-handler">Create an Intent Handler for URLs</a></li>
<li><a href="#url-handling">Understand URI Request Handling</a> </li>
<li><a href="#intent-handler">Create an Intent Handler for URIs</a></li>
<li><a href="#request-verify">Request App Links Verification</a></li>
<li><a href="#web-assoc">Declare Website Associations</a></li>
<li><a href="#testing">Testing App Links</a></li>
<li><a href="#testing">Test App Links</a></li>
</ol>
</div>
</div>
@@ -19,124 +19,125 @@ page.keywords=applinking, deeplinks, intents
<p>
The M Developer Preview introduces a new option for handling website links. It allows clicked
links to go directly to the website's official app &mdash; instead of asking the user to choose
how to handle the link. This feature saves users' time and helps developers deliver a better
experience. Users can also select whether an app should always open specific types of links
automatically, or prompt each time.
Users following web links on devices are frequently presented with confusing choices. Tapping a
link often results in the system asking the user which app should handle that link. For example,
clicking a URI in an email from a bank might result in a dialog asking the user whether to use
the browser, or the bank's own app, to open the link. Android 6.0 (API level 23) and higher allow
an app to designate itself as the default handler of a given type of link. If the user doesn't
want the app to be the default handler, they can override this behavior from
<strong>Settings</strong>.
</p>
<p>
Handling links automatically requires the cooperation of app developers and website owners.
Developers must configure their apps to declare connections with websites and request
verification. Website owners should publish a Digital Asset Links file
to allow Android to verify the association of apps with their sites. The general steps for
creating verified app links are as follows:
Automatic handling of links requires the cooperation of app developers and website owners.
A developer must configure their app to declare associations with one or more websites, and to
request that the system verify those associations. A website owner must, in turn, provide
that verification by publishing a <a href="developers.google.com/digital-asset-links/"><i>Digital
Asset Links</i></a> file. The general steps for creating verified app links are as follows:
</p>
<ol>
<li>Create intent filters within your app for your website URLs.</li>
<li>In your app manifest, create intent filters for your website URIs.</li>
<li>Configure your app to request verification of app links.</li>
<li>Publish a Digital Asset Links JSON file on your websites.</li>
<li>Test that the Android system can verify your app.</li>
<li>Publish a Digital Asset Links JSON file on your websites to provide verification.</li>
</ol>
<h2 id="url-handling">Understanding URL Request Handling</h2>
<h2 id="url-handling">Understand URI Request Handling</h2>
<p>
The app links feature allows your app to become the default handler for your website URLs, as
long as the user has not already chosen an app to handle that URL pattern. When a web URI intent
is invoked through a clicked link or programmatic request, the Android system determines what app
is used to handle the intent. The system uses these criteria, in order, to determine how to handle
the request:
The app links feature allows your app to become the default handler for the website URIs you
specify, as long as the user has not already chosen a default app to handle that URI pattern.
When a clicked link or programmatic request invokes a web URI intent, the Android system
uses the following criteria, in descending order, to determine how to handle the request:
</p>
<ol>
<li>
<strong>The user has set up a matching app link association</strong>. If the user has designated
an app to handle app links, the system passes the web URI request to that app. The user sets
this association by opening
<strong>Settings &gt; Apps &gt; Configure apps (gear icon) &gt; App links</strong>, and
then selecting an app to use and configuring its <strong>App links</strong> property to the
<em>Open in this app</em> option.
<strong>The user has set app link associations</strong>: If the user has designated an app to
handle app links, the system passes the web URI request to that app. A user can set this
association in one of two ways: clicking <strong>Always</strong> when selecting an app
from an app-selection dialog; or, opening <em>Settings &gt; Apps &gt; (gear icon)
&gt; App links</em>, selecting an app to use, and setting the app's
<strong>App links</strong> property to the <strong>Open in this app</strong> option.
</li>
<li>
<strong>The user has not set up an association, and there is a single supporting app</strong>.
If the user has not set a preference that matches the web URI request, and there is only one app
declaring support for the intent’s URI pattern, the system passes the request to that app.
<strong>The user has set no association, and there is one supporting app</strong>: If the user
has not set a preference that matches the web URI request, and there is only one app declaring
support for the intent’s URI pattern, the system automatically passes the request to that app.
</li>
<li>
<strong>The user has not set up an association, and there are multiple supporting apps</strong>.
If there is no explicit user preference and there are multiple apps declaring support for the
web URI pattern, the system prompts the user to select one of the available apps.
<strong>The user has set no association, and there are multiple supporting apps</strong>: If
there are multiple apps declaring support for the web URI pattern, the system displays an
app-selection dialog, prompting the user to select the most appropriate app.
</li>
</ol>
<p>
In the second case, if an app is newly installed and verified
as a handler for this type of link, the system sets it as the default handler. In the other two
cases, the system behavior is the same, regardless of the presence of a verified app link
handler.
In case 2, if the user has newly installed the app, and the system has
verified it as a handler for this type of link, the system sets the app as the default handler. In
the other two cases, the presence of a verified app link handler has no effect on system behavior.
</p>
<h2 id="intent-handler">Create an Intent Handler for URLs</h2>
<h2 id="intent-handler">Create an Intent Handler for URIs</h2>
<p>
App links are based on the <a href="{@docRoot}guide/components/intents-filters.html">Intent</a>
framework, which enables apps to handle requests from the system or other apps. Multiple apps may
declare matching web link URI patterns in their intent filters. When a user clicks a web link
declare the same web link URI patterns in their intent filters. When a user clicks on a web link
that does not have a default launch handler, the platform selects an app to handle the request,
based on the criteria described in the previous section.
using the criteria described in <a href="#url-handling">Understanding URI Request Handling</a>.
</p>
<p>
To enable your app to handle links, use intent filters in your app manifest to declare the URI
patterns to be handled by your app. The following sample code shows an intent filter that can
patterns that your app handles. The following example shows an intent filter that can
handle links to {@code http://www.android.com} and {@code https://www.android.com}:
</p>
<pre>
&lt;activity ...&gt;
&lt;intent-filter&gt;
&lt;action android:name="android.intent.action.VIEW" /&gt;
&lt;category android:name="android.intent.category.DEFAULT" /&gt;
&lt;category android:name="android.intent.category.BROWSABLE" /&gt;
&lt;data android:scheme="http" /&gt;
&lt;data android:scheme="https" /&gt;
&lt;data android:host="www.android.com" /&gt;
&lt;/intent-filter&gt;
&lt;/activity&gt;
&lt;activity ...&gt;
&lt;intent-filter&gt;
&lt;action android:name="android.intent.action.VIEW" /&gt;
&lt;category android:name="android.intent.category.DEFAULT" /&gt;
&lt;category android:name="android.intent.category.BROWSABLE" /&gt;
&lt;data android:scheme="http" /&gt;
&lt;data android:scheme="https" /&gt;
&lt;data android:host="www.android.com" /&gt;
&lt;/intent-filter&gt;
&lt;/activity&gt;
</pre>
<p>
As shown in this example, intent filters for app links must declare an {@code android:scheme}
value of {@code http}, {@code https}, or both. The filter should not declare
As this example shows, intent filters for app links must declare an {@code android:scheme}
value of {@code http}, {@code https}, or both. The filter must not declare
any other schemes. The filter must also include the {@code android.intent.action.VIEW} and
{@code android.intent.category.BROWSABLE} category names.
</p>
<p>
This manifest declaration defines the connection between your app and a website. However,
to have the system treat your app as the default handler for a set of URLs, you must
also request that the system verify this connection, which is explained in the next section.
This manifest declaration defines the connection between your app and a website. However, in
order to have the system treat your app as the default handler for a set of URIs, you must
also request that the system verify this connection.
The next section explains how to implement this verification.
</p>
<h2 id="request-verify">Request App Links Verification</h2>
<p>
In addition to declaring an association between your app and a website by using intent filters,
your app must also request automatic verification with an additional manifest declaration. When
this declaration is set, the Android system attempts to verify your app after it's installed.
If the verification succeeds, and the user has not set a preference for your website URLs, the
system automatically routes those URL requests to your app.
In addition to using intent filters to declare an association between your app and a website,
your manifest must also include an additional declaration for requesting automatic verification.
When this declaration is present, the Android system attempts to verify your app after
installation. If the verification succeeds, and the user has not set an alternate
preference for handling your website URIs, the system automatically routes those URI requests to
your app.
</p>
<p>
The system performs app link verifications by comparing the hostnames in the data elements of
The system performs app-link verifications by comparing the host names in the data elements of
the app’s intent filters against the Digital Asset Links files ({@code assetlinks.json}) hosted
on the respective web domains. To enable the system to verify a host, make sure that your intent
filter declarations include the {@code android.intent.action.VIEW} intent action and {@code
@@ -157,7 +158,7 @@ page.keywords=applinking, deeplinks, intents
&lt;intent-filter <strong>android:autoVerify="true"</strong>&gt;
&lt;action android:name="android.intent.action.VIEW" /&gt;
&lt;category android:name="android.intent.category.DEFAULT" /&gt;
&lt;category android:name="android.intent.category.DEFAULT"gt;
&lt;category android:name="android.intent.category.BROWSABLE" /&gt;
&lt;data android:scheme="http" android:host="www.android.com" /&gt;
&lt;data android:scheme="https" android:host="www.android.com" /&gt;
@@ -167,9 +168,9 @@ page.keywords=applinking, deeplinks, intents
</pre>
<p>
When the {@code android:autoVerify} attribute is set, the system attempts to verify all hosts
associated with web URIs in all of your app's intent filters when the app is installed. The
system treats your app as the default handler for the specified URI pattern only if it
When the {@code android:autoVerify} attribute is present, installing your app causes the system
to attempt to verify all hosts associated with the web URIs in all of your app's intent filters.
The system treats your app as the default handler for the specified URI pattern only if it
successfully verifies <em>all</em> app link patterns declared in your manifest.
</p>
@@ -177,11 +178,11 @@ page.keywords=applinking, deeplinks, intents
<h3 id="multi-host">Supporting app linking for multiple hosts</h3>
<p>
The system must be able to verify each host specified in the data elements of the app’s web URI
intent filters against the Digital Asset Links files hosted on the respective web domains. If any
verification fails, the app is not verified to be a default handler for any of the web URL
patterns defined in its intent filters. For example, an app with the following intent filters
would fail verification if an {@code assetlinks.json} file were not found at both
The system must be able to verify every host specified in the app’s web URI intent filters’ data
elements against the Digital Asset Links files hosted on the respective web domains. If any
verification fails, the app is not verified to be a default handler for any of the web URI
patterns defined in the app's intent filters. For example, an app with the following intent
filters would fail verification if an {@code assetlinks.json} file were not found at both
{@code https://www.domain1.com/.well-known/assetlinks.json} and
{@code https://www.domain2.com/.well-known/assetlinks.json}:
</p>
@@ -189,7 +190,7 @@ page.keywords=applinking, deeplinks, intents
<pre>
&lt;application&gt;
&lt;activity android:name="MainActivity"&gt;
&lt;activity android:name=”MainActivity”&gt;
&lt;intent-filter <strong>android:autoVerify="true"</strong>&gt;
&lt;action android:name="android.intent.action.VIEW" /&gt;
&lt;category android:name="android.intent.category.DEFAULT" /&gt;
@@ -198,7 +199,7 @@ page.keywords=applinking, deeplinks, intents
&lt;data android:scheme="https" android:host="www.domain1.com" /&gt;
&lt;/intent-filter&gt;
&lt;/activity&gt;
&lt;activity android:name="SecondActivity"&gt;
&lt;activity android:name=”SecondActivity”&gt;
&lt;intent-filter&gt;
&lt;action android:name="android.intent.action.VIEW" /&gt;
&lt;category android:name="android.intent.category.DEFAULT" /&gt;
@@ -207,7 +208,7 @@ page.keywords=applinking, deeplinks, intents
&lt;/intent-filter&gt;
&lt;/activity&gt;
&lt;/application&gt;
&lt;/application
</pre>
@@ -216,7 +217,7 @@ page.keywords=applinking, deeplinks, intents
<p>
The Digital Asset Links protocol treats subdomains as unique, separate hosts. If your intent
filter lists both the {@code www.example.com} and {@code mobile.example.com} subdomains as
schemes, you must host a separate {@code assetlink.json} file on each subdomain. For example, an
hosts, you must host a separate {@code assetlink.json} file on each subdomain. For example, an
app with the following intent filter declaration would pass verification only if the website
owner published valid {@code assetlinks.json} files at both
{@code https://www.example.com/.well-known/assetlinks.json} and
@@ -225,7 +226,7 @@ page.keywords=applinking, deeplinks, intents
<pre>
&lt;application&gt;
&lt;activity android:name="MainActivity"&gt;
&lt;activity android:name=”MainActivity”&gt;
&lt;intent-filter <strong>android:autoVerify="true"</strong>&gt;
&lt;action android:name="android.intent.action.VIEW" /&gt;
&lt;category android:name="android.intent.category.DEFAULT" /&gt;
@@ -247,47 +248,50 @@ page.keywords=applinking, deeplinks, intents
</p>
<pre>
https://<em>domain</em>[:<em>optional_port</em>]/.well-known/assetlinks.json
https://<em>domain</em>[:<em>optional_port</em>]/.well-known/assetlinks.json
</pre>
<p class="note">
<strong>Important:</strong> With M Preview 3 and the Android 6.0 (API level 23) release, the JSON
file is verified through the encrypted HTTPS protocol. Make sure that your hosted file can be
accessed over an HTTPS connection, regardless of whether your app's intent filter declares an
{@code android:scheme} setting of {@code http}, {@code https}, or both.
<strong>Important:</strong> The system verifies the JSON file via the encrypted HTTPS protocol.
Make sure that your hosted file is accessible over an HTTPS connection, regardless of whether
your app's intent filter includes {@code https}.
</p>
<p>
A Digital Asset Links JSON file indicates the Android apps that are associated with the website.
The JSON file identifies associated apps with the following fields:
The JSON file uses the following fields to identify associated apps:
</p>
<ul>
<li>{@code package_name} - The package name declared in the app's manifest.</li>
<li>{@code package_name}: The package name declared in the app's manifest.</li>
<li>{@code sha256_cert_fingerprints}: The SHA256 fingerprints of your app’s signing certificate.
You can use the following command to generate the fingerprint via the Java keytool:
<pre class="no-pretty-print">
$ keytool -list -v -keystore my-release-key.keystore
</pre>
<li>{@code sha256_cert_fingerprints} - The SHA256 fingerprints of your app’s signing certificate.
You can use the Java keytool to generate the fingerprint using the following command:
<pre>keytool -list -v -keystore my-release-key.keystore</pre>
This field supports multiple fingerprints, which can be used to support different versions
of your app, such as debug and production builds.
</li>
</ul>
<p>
The following example {@code assetlinks.json} file grants link opening rights to a
{@code com.example} Android application:
The following example {@code assetlinks.json} file grants link-opening rights to a
{@code com.example} Android app:
</p>
<pre>
[{
"relation": ["delegate_permission/common.handle_all_urls"],
"target": {
"namespace": "android_app",
"package_name": "com.example",
"sha256_cert_fingerprints":
["14:6D:E9:83:C5:73:06:50:D8:EE:B9:95:2F:34:FC:64:16:A0:83:42:E6:1D:BE:A8:8A:04:96:B2:3F:CF:44:E5"]
}
}]
[{
"relation": ["delegate_permission/common.handle_all_urls"],
"target": {
"namespace": "android_app",
"package_name": "com.example",
"sha256_cert_fingerprints":
["14:6D:E9:83:C5:73:06:50:D8:EE:B9:95:2F:34:FC:64:16:A0:83:42:E6:1D:BE:A8:8A:04:96:B2:3F:CF:44:E5"]
}
}]
</pre>
@@ -296,7 +300,7 @@ page.keywords=applinking, deeplinks, intents
<p>
A website can declare associations with multiple apps within the same {@code assetlinks.json}
file. The following file listing shows an example of a statement file that declares association
with two separate apps and is hosted at
with two apps, separately, and resides at
<code>https://www.example.com/.well-known/assetlinks.json</code>:
</p>
@@ -322,10 +326,8 @@ page.keywords=applinking, deeplinks, intents
</pre>
<p>
When multiple apps handle links to the same host, the system determines which one to use for
a given link based on the intent filters defined in each app’s manifest. Different apps may
handle links for different resources under the same web host. For example, app1 may
declare an intent filter for {@code https://example.com/articles}, and app2 may declare
Different apps may handle links for different resources under the same web host. For example,
app1 may declare an intent filter for {@code https://example.com/articles}, and app2 may declare
an intent filter for {@code https://example.com/videos}.
</p>
@@ -340,7 +342,8 @@ page.keywords=applinking, deeplinks, intents
<p>
Multiple websites can declare associations with the same app in their respective {@code
assetlinks.json} files. The following file listings show an example of how to declare the
association of domain1 and domain2 with app1:
association of domain1 and domain2 with app1. The first listing shows the association of
domain1 with app1:
</p>
<pre>
@@ -357,6 +360,9 @@ https://www.domain1.com/.well-known/assetlinks.json
}]
</pre>
<p>The next listing shows the association of domain2 with app1. Only the very last line, which
specifies the URL, is different:</p>
<pre>
https://www.domain2.com/.well-known/assetlinks.json
@@ -371,13 +377,11 @@ https://www.domain2.com/.well-known/assetlinks.json
}]
</pre>
<h2 id="testing">Testing App Links</h2>
<h2 id="testing">Test App Links</h2>
<p>
When implementing the app linking feature, you should test the linking functionality to
make sure that your app can be successfully associated with your websites and handle URL requests
make sure the system can associate your app with your websites, and handle URI requests,
as you expect.
</p>
@@ -386,8 +390,8 @@ https://www.domain2.com/.well-known/assetlinks.json
<p>
When testing, you should confirm the list of associated hosts that the system should verify
for your app. Make a list of all web URIs in intent-filters in your manifest that
include all of the following:
for your app. Make a list of all web URIs whose corresponding intent filters include the following
attributes and elements:
</p>
<ul>
@@ -410,8 +414,8 @@ https://www.domain2.com/.well-known/assetlinks.json
<h3 id="test-dal-files">Confirm the Digital Asset Links files</h3>
<p>
For each website, confirm that the Digital Asset Links JSON file is properly hosted and
defined by using the Digital Asset Links API:
For each website, use the Digital Asset Links API to confirm that the Digital Asset Links JSON
file is properly hosted and defined:
</p>
<pre>
@@ -424,10 +428,10 @@ https://digitalassetlinks.googleapis.com/v1/statements:list?
<h3 id="test-intent">Testing a web URI intent</h3>
<p>
After you've confirmed the list of websites to associate with your app, and confirmed
Once you have confirmed the list of websites to associate with your app, and you have confirmed
that the hosted JSON file is valid, install the app on your device. Wait at least 20 seconds for
the asynchronous verification process to complete. Use the following command to check
if the system verified your app and set the correct link handling policies:
whether the system verified your app and set the correct link handling policies:
</p>
<pre>
@@ -441,13 +445,14 @@ adb shell am start -a android.intent.action.VIEW \
<p>
As part of your testing process, you can check the current system settings for link handling.
Use the following command to get a listing of link-handling policies for all applications:
Use the following command to get a listing of existing link-handling policies for all
applications:
</p>
<pre>
adb shell dumpsys package domain-preferred-apps
--or--
adb shell dumpsys package d
adb shell dumpsys package domain-preferred-apps
--or--
adb shell dumpsys package d
</pre>
<p class="note">
@@ -457,7 +462,7 @@ adb shell am start -a android.intent.action.VIEW \
<p>
The command returns a listing of each user or profile defined on the device,
indicated by a header in the following format:
preceded by a header in the following format:
</p>
<pre>
@@ -465,7 +470,8 @@ App linkages for user 0:
</pre>
<p>
Following this heading, the output lists the link-handling settings for that user in this format:
Following this header, the output uses the following format to list the link-handling settings
for that user:
</p>
<pre>
@@ -474,28 +480,30 @@ Domains: play.google.com market.android.com
Status: always : 200000002
</pre>
<p>This listing indicates the apps associated with domains for that user:</p>
<p>This listing indicates which apps are associated with which domains for that user:</p>
<ul>
<li>{@code Package} - Identifies an app by its package name, as declared in its manifest.
</li>
<li>{@code Domains} - Shows the full list of hosts whose web links this app handles.
<li>{@code Domains} - Shows the full list of hosts whose web links this app handles, using
blank spaces as delimiters.
</li>
<li>{@code Status} - Shows the current link-handling setting for this app. An app that set the
{@code android:autoVerify="true"} value and passed verification is shown with a status of {@code
always}. The hexadecimal number after this status indicates the Android system's record of
the user’s app linkage preferences. This value is not relevant for interpreting whether the
verification operation passed.
<li>{@code Status} - Shows the current link-handling setting for this app. An app that has
passed verification, and whose manifest contains {@code android:autoVerify="true"}, shows a status
of {@code always}. The hexadecimal number after this status is related to the Android system's
record of the user’s app linkage preferences. This value does not indicate whether verification
succeeded.
</li>
</ul>
<p class="note">
<strong>Note:</strong> It's possible for a user to change the app link settings for an app
before the verification operation has completed. If this
situation occurs, you may see a false positive for a successful verification, even if
verification has failed. However, the user has already explicitly enabled the app to open
supported links without asking. In this case, no dialog is shown and the link goes directly to
your app, but only because explicit user preferences take precedence.
<strong>Note:</strong> If a user changes the app link settings for an app before verification
is complete, you may see a false positive for a successful verification, even though
verification has failed. This verification failure, however, does not matter if the user
explicitly enabled the app to open supported links without asking. This is because
user preferences take precedence over programmatic verification (or lack of it). As a result,
the link goes directly to your app, without showing a dialog, just as if verification had
succeeded.
</p>
@@ -504,38 +512,38 @@ Status: always : 200000002
<p>
For app link verification to succeed, the system must be able to verify your app with all of
the websites referenced in your app’s intent filters that meet the criteria for app links.
The following example manifest snippet shows an app configuration with several app links defined:
the websites that you specify in your app’s intent filters, and that meet the criteria for app
links. The following example shows a manifest configuration with several app links defined:
</p>
<pre>
&lt;application&gt;
&lt;application&gt;
&lt;activity android:name="MainActivity"&gt;
&lt;intent-filter <strong>android:autoVerify="true"</strong>&gt;
&lt;action android:name="android.intent.action.VIEW" /&gt;
&lt;category android:name="android.intent.category.DEFAULT" /&gt;
&lt;category android:name="android.intent.category.BROWSABLE" /&gt;
&lt;data android:scheme="http" android:host="www.example.com" /&gt;
&lt;data android:scheme="https" android:host="mobile.example.com" /&gt;
&lt;/intent-filter&gt;
&lt;intent-filter&gt;
&lt;action android:name="android.intent.action.VIEW" /&gt;
&lt;category android:name="android.intent.category.BROWSABLE" /&gt;
&lt;data android:scheme="http" android:host="www.example2.com" /&gt;
&lt;/intent-filter&gt;
&lt;/activity&gt;
&lt;activity android:name=”MainActivity”&gt;
&lt;intent-filter <strong>android:autoVerify="true"</strong>&gt;
&lt;action android:name="android.intent.action.VIEW" /&gt;
&lt;category android:name="android.intent.category.DEFAULT" /&gt;
&lt;category android:name="android.intent.category.BROWSABLE" /&gt;
&lt;data android:scheme="http" android:host="www.example.com" /&gt;
&lt;data android:scheme="https" android:host="mobile.example.com" /&gt;
&lt;/intent-filter&gt;
&lt;intent-filter&gt;
&lt;action android:name="android.intent.action.VIEW" /&gt;
&lt;category android:name="android.intent.category.BROWSABLE" /&gt;
&lt;data android:scheme="http" android:host="www.example2.com" /&gt;
&lt;/intent-filter&gt;
&lt;/activity&gt;
&lt;activity android:name="SecondActivity"&gt;
&lt;intent-filter&gt;
&lt;action android:name="android.intent.action.VIEW" /&gt;
&lt;category android:name="android.intent.category.DEFAULT" /&gt;
&lt;category android:name="android.intent.category.BROWSABLE" /&gt;
&lt;data android:scheme="http" android:host="account.example.com" /&gt;
&lt;/intent-filter&gt;
&lt;/activity&gt;
&lt;activity android:name=”SecondActivity”&gt;
&lt;intent-filter&gt;
&lt;action android:name="android.intent.action.VIEW" /&gt;
&lt;category android:name="android.intent.category.DEFAULT" /&gt;
&lt;category android:name="android.intent.category.BROWSABLE" /&gt;
&lt;data android:scheme="http" android:host="account.example.com" /&gt;
&lt;/intent-filter&gt;
&lt;/activity&gt;
&lt;activity android:name="ThirdActivity"&gt;
&lt;activity android:name=”ThirdActivity”&gt;
&lt;intent-filter&gt;
&lt;action android:name="android.intent.action.VIEW" /&gt;
&lt;category android:name="android.intent.category.DEFAULT" /&gt;
@@ -552,21 +560,21 @@ Status: always : 200000002
</pre>
<p>
The list of hosts that the platform would attempt to verify from this manifest is:
The list of hosts that the platform would attempt to verify from the above manifest is:
</p>
<pre>
www.example.com
mobile.example.com
www.example2.com
account.example.com
www.example.com
mobile.example.com
www.example2.com
account.example.com
</pre>
<p>
The list of hosts that the platform would not attempt to verify based on the manifest is:
The list of hosts that the platform would not attempt to verify from the above manifest is:
</p>
<pre>
map.example.com (it does not have android.intent.category.BROWSABLE)
market://example.com (it does not have either an “http” or “https” scheme)
map.example.com (it does not have android.intent.category.BROWSABLE)
market://example.com (it does not have either an “http” or “https” scheme)
</pre>

81
docs/html/training/training_toc.cs
View File

@@ -281,31 +281,6 @@ include the action bar on devices running Android 2.1 or higher."
</ul>
</li>
<li class="nav-section">
<div class="nav-section-header">
<a href="<?cs var:toroot ?>training/permissions/index.html"
description=
"How to declare that your app needs access to features and
resources outside of its 'sandbox', and how to request those
privileges at runtime."
>Working with System Permissions</a>
</div>
<ul>
<li><a href="<?cs var:toroot ?>training/permissions/declaring.html">
Declaring Permissions
</a>
</li>
<li><a href="<?cs var:toroot ?>training/permissions/requesting.html">
Requesting Permissions at Run Time
</a>
</li>
<li><a href="<?cs var:toroot ?>training/permissions/best-practices.html">
Best Practices for Runtime Permissions
</a>
</li>
</ul>
</li>
</ul>
</li><!-- end getting started -->
<li class="nav-section">
@@ -836,7 +811,7 @@ include the action bar on devices running Android 2.1 or higher."
<div class="nav-section-header">
<a href="<?cs var:toroot ?>training/building-userinfo.html">
<span class="small">Building Apps with</span><br/>
Contacts &amp; Sign-In
User Info &amp; Sign-In
</a>
</div>
<ul>
@@ -1336,6 +1311,8 @@ include the action bar on devices running Android 2.1 or higher."
</li>
</ul>
</li>
<li class="nav-section">
<div class="nav-section-header">
<a href="<?cs var:toroot ?>training/swipe/index.html"
@@ -1354,6 +1331,8 @@ include the action bar on devices running Android 2.1 or higher."
</li>
</ul>
</li>
<li class="nav-section">
<div class="nav-section-header">
<a href="<?cs var:toroot ?>training/search/index.html"
@@ -1392,17 +1371,26 @@ results."
</a>
</li>
<li><a href="<?cs var:toroot ?>training/app-indexing/enabling-app-indexing.html">
Specifying App Content for Indexing
Specifying App Content for Indexing
</a>
</li>
</ul>
</li>
</ul>
</li>
<li class="nav-section">
<div class="nav-section">
<a href="<?cs var:toroot ?>training/app-links/index.html"
description=
"How to enable the system to handle web requests by taking the user directly
to your app instead of your website."
>Handling App Links</a>
</div>
</li>
<!-- End Interaction and Engagement -->
</ul>
<li class="nav-section">
<div class="nav-section-header">
@@ -1413,6 +1401,7 @@ results."
</div>
<ul>
<li class="nav-section">
<div class="nav-section-header">
<a href="<?cs var:toroot ?>training/multiscreen/index.html"
@@ -1448,27 +1437,6 @@ results."
</ul>
</li>
<li class="nav-section">
<div class="nav-section-header">
<a href="<?cs var:toroot ?>training/appbar/index.html"
description=
"How to use the support library's toolbar widget to implement an
app bar that displays properly on a wide range of devices."
>Adding the App Bar</a>
</div>
<ul>
<li><a href="<?cs var:toroot ?>training/appbar/setting-up.html"
>Setting Up the App Bar</a>
</li>
<li><a href="<?cs var:toroot ?>training/appbar/actions.html"
>Adding and Handling Actions</a>
</li>
<li><a href="<?cs var:toroot ?>training/appbar/up-action.html"
>Adding an Up Action</a>
</li>
</ul>
</li>
<li class="nav-section">
<div class="nav-section-header">
<a href="<?cs var:toroot ?>training/custom-views/index.html"
@@ -1851,9 +1819,6 @@ results."
</a>
</div>
<ul>
<li><a href="<?cs var:toroot ?>training/monitoring-device-state/doze-standby.html"
>Optimizing for Doze and App Standby</a>
</li>
<li><a href="<?cs var:toroot ?>training/monitoring-device-state/battery-monitoring.html"
zh-cn-lang="监控电池电量和充电状态"
ja-lang="電池残量と充電状態の監視"
@@ -2049,12 +2014,6 @@ results."
</ul>
</li>
</ul>
<ul>
<li><a href="<?cs var:toroot ?>training/testing/performance.html"
description="How to automate UI performance testing.">
<span class="en">Testing Display Performance</span>
</a></li>
<ul>
</li>
<!-- End best Testing -->