Move chrome.bluetoothLowEnergy out of //chrome.

extensions/browser/api/extensions_api_client.h

Index: extensions/browser/api/extensions_api_client.h
diff --git a/extensions/browser/api/extensions_api_client.h b/extensions/browser/api/extensions_api_client.h
index 126b6e0f86f40298580195067ae17a9a2d6bcd1b..1459be0d966f3974d48ab29c9ed2e18be63e5f1c 100644
--- a/extensions/browser/api/extensions_api_client.h
+++ b/extensions/browser/api/extensions_api_client.h
@@ -35,6 +35,7 @@ class ContentRulesRegistry;
 class DevicePermissionsPrompt;
 class ExtensionOptionsGuest;
 class ExtensionOptionsGuestDelegate;
+class KioskDelegate;
 class ManagementAPIDelegate;
 class MimeHandlerViewGuest;
 class MimeHandlerViewGuestDelegate;
@@ -127,6 +128,9 @@ class ExtensionsAPIClient {
   // Creates a delegate for handling the management extension api.
   virtual ManagementAPIDelegate* CreateManagementAPIDelegate() const;
 
+  // Returns a delegate that provides kiosk mode functionality.
+  virtual KioskDelegate* GetKioskDelegate();

[asargent_no_longer_on_chrome, 2016/09/28 19:58:15]

Most of the rest of these functions are named Create* and return std::unique_ptr
which gets stored somewhere, often in a BrowserContextKeyedAPI member variable.
Can this follow that same pattern?

Or does this perhaps belong in ExtensionsBrowserClient, ExtensionSystem, or as
its own KeyedService?

[Rahul Chaturvedi, 2016/09/28 20:26:47]

So the difference is that the rest of the functions need their delegates to be
context keyed. So we create a new delegate every time they ask, and they save it
to their browser context keyed API state.

This delegate is actually global, hence which is why we don't really need to
create a different delegates but need to create one just once. Which is why it
makes sense to have one global instance per extension client and return it to
anyone who needs it.

Ideally, we probably should have had all of these as
GetXXXDelegate(content::BrowserContext) calls with us managing the storage to
the context keyed state, but that may be too much refactoring to do at this
point.

[asargent_no_longer_on_chrome, 2016/09/28 20:45:19]

Thinking about this some more, does the KioskDelegate have anything to do with a
particular API? The stated purpose of the ExtensionsAPIClient is for an embedder
to "customize its support for API features", and most of the functions here
indeed have something to do with a particular API. The KioskDelegate interface
so far just has IsAutoLaunchedKioskApp, which seems sort of orthogonal to any
particular API. 

Since the KioskDelegate is global and not BrowserContext-dependent, maybe a good
fit would be to put it in ExtensionsClient ("Sets up global state for the
extensions system")? Or possibly just have a static KioskDelegate::Get() method?

[Rahul Chaturvedi, 2016/09/28 21:10:29]

I really don't want to have a global ::Get. This code gets to leverage the
mechanisms in place already for getting the correct [Chrome|Shell] delegate with
using the API|extensions client.

ExtensionsClient does work but it feels a bit wrong. This code may be used by
several APIs but it will still be used to API specific code. It just so happens
that many APIs will need the information it provides.

Looking at all the methods in ExtensionsClient, this seems to fit better with
the ExtensionsApiClient methods.

[asargent_no_longer_on_chrome, 2016/09/28 21:49:41]

I'd still prefer that we put this in ExtensionsClient (or
ExtensionsBrowserClient, if it will eventually need to know about browser
process concepts)- I agree that the rest of the methods in ExtensionsClient are
a little different, but I still think it fits better with the stated purpose of
ExtensionsClient than the stated purpose of ExtensionsAPIClient. 

[Rahul Chaturvedi, 2016/09/28 23:00:10]

Moved to ExtensionsBrowserClient (since ExtensionsClient has a dependency issue
with //c/b/chromeos).
Done.

+
   // NOTE: If this interface gains too many methods (perhaps more than 20) it
   // should be split into one interface per API.
 };