Chrome app manifest support for action handlers.

extensions/common/api/_manifest_features.json

Index: extensions/common/api/_manifest_features.json
diff --git a/extensions/common/api/_manifest_features.json b/extensions/common/api/_manifest_features.json
index 05cbbe97aa935ba6603c5b40bf28f6d783fa6b49..673f2a95db0f9741cc16bf21938a1880686438bb 100644
--- a/extensions/common/api/_manifest_features.json
+++ b/extensions/common/api/_manifest_features.json
@@ -7,6 +7,10 @@
 // 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"]