Introduce lock screen app context to extension features

extensions/common/extension.h

Index: extensions/common/extension.h
diff --git a/extensions/common/extension.h b/extensions/common/extension.h
index 89e9a26b39c035b17527e03730ff585f5151d525..0d0e2e9fbbed06b74c7c0d0446d76697c39213f4 100644
--- a/extensions/common/extension.h
+++ b/extensions/common/extension.h
@@ -157,6 +157,13 @@ class Extension : public base::RefCountedThreadSafe<Extension> {
     // before they are fully installed and enabled.
     MAY_BE_UNTRUSTED = 1 << 12,
 
+    // |RUN_ON_LOCK_SCREEN| indicates that this extension will be run on lock
+    // screen. It's primarily set for lock screen action handler platform apps.
+    // The apps will be able to create a window on top of Chrome OS lock screen
+    // and will have resticted access to extension APIs. The apps will be
+    // installed in a browser context not associated with any user.
+    RUNS_ON_LOCK_SCREEN = 1 << 13,

[Devlin, 2017/05/23 16:51:53]

I'm not sure we want a creation flag for this, but it doesn't seem to be used
anywhere.  Is there a reason you wanted to take this approach?

[tbarzic, 2017/05/23 17:30:23]

I'll add code that uses the flag in later cls.

The reason for this approach is that it works with how apps will be set up for
handling actions on lock screen.
The app would be added to a profile not associated with any user (current plan
is to use sign-in profile), and when the app has to be launched, onLaunced
events would be sent to the app in that profile.
Given that the app instances would be designated to handle lock screen requests,
it makes sense  to make that a property of the app instance. And since
'runs_on_lock_screen' value would remain unchanged during the app's lifetime, I
figured to set this value as a creation flag.

basically the meaning of the flag would be "installed into lock-screen profile
with intent to handle actions on lock screen".

[Devlin, 2017/05/25 20:42:02]

Sorry for the delay.

I'd prefer we don't have this as a creation flag; it doesn't seem like quite the
right place for it.  My understanding is that the app will still be able to
communicate (in some way) with its non-lock-screen counterpart, and having
different, semi-transitive creation flags seems weird.

Out of curiosity, do we need to store a bit on the extension at all?  If we're
adding this to a lock screen profile, isn't the fact that it's added indicative
of it running on the lock screen?

+
     // When adding new flags, make sure to update kInitFromValueFlagBits.
   };
 
@@ -324,6 +331,10 @@ class Extension : public base::RefCountedThreadSafe<Extension> {
     return (creation_flags_ & WAS_INSTALLED_BY_OEM) != 0;
   }
 
+  bool runs_on_lock_screen() const {
+    return (creation_flags_ & RUNS_ON_LOCK_SCREEN) != 0;
+  }
+
   // Type-related queries. These are all mutually exclusive.
   //
   // The differences between the types of Extension are documented here: