Chrome app manifest support for action handlers.

extensions/common/api/_manifest_features.json

 // Copyright 2014 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 // This features file defines manifest keys implemented under src/extensions.
 // See chrome/common/extensions/api/_features.md to understand this file, as
 // well as feature.h, simple_feature.h, and base_feature_provider.h.
 
 {
+  "action_handlers": {
+    "channel": "stable",

[Devlin, 2017/01/17 21:42:01]

Let's not launch this to stable just yet - it's usually good practice to have it
in dev for awhile and let people fool around with it before we finalize
everything and ship it.

[jdufault, 2017/01/20 20:31:47]

How long of an incubation period? The changes here seem pretty low-risk, and the
user can already select custom Android apps, so it would be nice to have feature
parity. Launching directly to stable seems reasonable to me since we will have
the normal test cycle, but I'm not familiar with the typical extension API
process.

Also, changing this value to "dev" causes the unit tests to fail. Any idea why?

[Devlin, 2017/01/30 21:19:59]

Mostly, we want the consumers of this API to have a chance to try it out and see
if it works, and be able to make API changes if it doesn't.  Once we document
that it's available on stable, we try very hard to never change the API in a
non-backwards compatible way.

Re why the unittest fails, you probably need to set the channel in the test. 
See also ScopedCurrentChannel
(https://cs.chromium.org/chromium/src/extensions/common/features/feature_chann...).

+    "extension_types": ["platform_app"]
+  },

[Devlin, 2017/01/17 21:42:01]

should we restrict this to chromeos?

[jdufault, 2017/01/20 20:31:47]

Done.

   "app": {
     "channel": "stable",
     "extension_types": ["legacy_packaged_app", "hosted_app", "platform_app"]
   },
   // The default platform app CSP can only be overridden by whitelisted apps.
   // This is a separate key from the top-level content_security_policy one since
   // we can't combine type restrictions with whitelisted ID restrictions. If
   // there is a need for additional whitelisted entries, the feature system
   // should instead be extended to support OR-ing of restrictions.
   "app.content_security_policy": {
@@ skipping 302 matching lines @@
       "extension_types": ["platform_app"],
       "location": "component"
     }
   ],
   "webview": {
     "channel": "stable",
     "extension_types": ["platform_app"],
     "min_manifest_version": 2
   }
 }