Update documentation for "file_system_provider" manifest section.

chrome/common/extensions/docs/templates/intros/fileSystemProvider.html

Index: chrome/common/extensions/docs/templates/intros/fileSystemProvider.html
diff --git a/chrome/common/extensions/docs/templates/intros/fileSystemProvider.html b/chrome/common/extensions/docs/templates/intros/fileSystemProvider.html
index 7ca0ab38c80a3907636ac3abf58904e6b9a74e6c..f331a6de648acccac2188dc4b9f41b0ef4ca818f 100644
--- a/chrome/common/extensions/docs/templates/intros/fileSystemProvider.html
+++ b/chrome/common/extensions/docs/templates/intros/fileSystemProvider.html
@@ -1,19 +1,38 @@
 <h2 id="manifest">Manifest</h2>
-<p>You must declare the "fileSystemProvider" permission
+<p>You must declare the "fileSystemProvider" permission and section
 in the <a href="manifest">extension manifest</a>
 to use the File System Provider API.
 For example:</p>
 <pre data-filename="manifest.json">
 {
-  "name": "My extension",
+  "name": "My {{platform}}",
   ...
-  <b>"permissions": [
+  "permissions": [
     "fileSystemProvider"
-  ]</b>,
+  ],
+  ...
+  "file_system_provider_capabilities": [
+    "configurable": true,
+    "multiple_mounts": true,
+    <a name="manifest-source"></a>"source": "network"

[not at google - send to devlin, 2015/05/12 20:58:34]

is this to get an anchor target? Another reasonable way to do that is with <span
id="manifest-source">...</span>, i'm not sure which is more idiomatic, but
creating an empty <a> element always seemed a bit weird to me.

[mtomasz, 2015/05/13 00:48:18]

Good point. <a name> seems deprecated in html5. Replaced with <span id>. Done.

+  ],
   ...
 }
 </pre>
 
+<p class="api_reference">
+The <code>file_system_provider</code> section must be declared as follows:
+{{+partials.manifest_type
+   type:apis.extensions.manifestTypes.byName.FileSystemProviderCapabilities /}}
+</p>
+<p>
+Files app uses above information in order to render related UI elements
+approprietly. For example, if <code>configurable</code> is set to
+</code>true</code>, then a menu item for configuring volumes will be rendered.
+Similarly, if <code>multiple_mounts</code> is set to <code>true</code>, then
+Files app will allow to add more than one mount points from the UI.
+</p>
+
 <h2 id="overview">Overview</h2>
 <p>
 File System Provider API allows extensions to support virtual file systems,
@@ -22,33 +41,81 @@ Use cases include decompressing archives and accessing files in a cloud
 service other than Drive.
 </p>
 
-<h2 id="archives">File handlers</h2>
+<h2 id="archives">Mounting file systems</h2>
 <p>
-Provided file systems can either provide file system contents from an external
-source (such as a remote server), or using a local file (such as an archive) as
-its input.
+Providing extensions can either provide file system contents from an external
+source (such as a remote server or a USB device), or using a local file (such as
+an archive) as its input.
 </p>
 <p>
-In the second case, the providing extension should have a
+{{?is_apps}}
+For file handlers, the providing extension should have a
 <a href="manifest/file_handlers">file_handlers</a> manifest entry in order
 to be launched when the file is selected in the file manager.
 When the extension is executed with a file to be handled, it has to mount a
 file system and start serving contents from the provided file.
+{{:is_apps}}
+In order to write file systems which are file handlers (source is
+<code>"file"</code>) the provider must be a packaged app, as the
+<code>onLaunched</code>event is not available to extensions.
+{{/is_apps}}
+</p>
+<p>
+If the source is network or a device, then the file system should be mounted
+when $(ref:onMountRequested) event is called.
+</p>
+<p>
+  <table id="source-table">
+    <tr>
+      <th>
+        <a href="#manifest-source">Source</a> of the file system data
+      </th>
+      <th>Entry point</th>
+    </tr>
+    <tr>
+      <td>
+        <code>"file"</code>
+      </td>
+      <td>
+        {{?is_apps}}
+          $(ref:app.runtime.onLaunched)
+        {{:is_apps}}
+          Available to <a href="/apps/fileSystemProvider#source-table">packaged
+          apps</a> only.
+        {{/is_apps}}
+      </td>
+    </tr>
+    <tr>
+      <td>
+        <code>"device"</code> or <code>"network"</code>
+      </td>
+      <td>
+        $(ref:onMountRequested)
+      </td>
+    </tr>
+  </table>
+</p>
+
+<h2 id="archives">Configuring file systems</h2>
+<p>
+Provided file systems once mounted can be configured via the
+$(ref:onConfigureRequested) event. It's especially useful for file systems which
+provide contents via network in order to set proper credentials. Handling this
+event is optional.
 </p>
 
 <h2 id="archives">Life cycle</h2>
 <p>
 Provided file systems once mounted are remembered by Chrome and remounted
 automatically after reboot or restart. Hence, once a file system is
-<a href="method-mount">mounted</a> by a providing extension, it will stay until
-either the extension is unloaded, or the extension calls the
-<a href="#method-unmount"> unmount</a> method.
+$(ref:mount mounted) by a providing extension, it will stay until either the
+extension is unloaded, or the extension calls the $(ref:unmount) method.
 </p>
+{{?is_apps}}
 <p>
 In case of acting as a file handler, the handled file may need to be stored
 to access it after either a reboot, or suspending and resuming an event page
-of the providing extension. In such case
-<a href="fileSystem#method-retainEntry">chrome.fileSystem.retainEntry</a> and
-<a href="fileSystem#method-restoreEntry">chrome.fileSystem.restoreEntry</a>
-should be used.
+of the providing extension. In such case $(ref:fileSystem.retainEntry) and
+$(ref:fileSystem.restoreEntry) should be used.
 </p>
+{{/is_apps}}