Move ProfileKeyedAPI implementations to take BrowserContext in the constructor (part 1).

chrome/browser/chromeos/extensions/media_player_api.h

Index: chrome/browser/chromeos/extensions/media_player_api.h
diff --git a/chrome/browser/chromeos/extensions/media_player_api.h b/chrome/browser/chromeos/extensions/media_player_api.h
index 026ae87a24e2ec105fa39414aa7a0208fe3a93ce..5bde828f5b17d429f3813c772a119412d8679670 100644
--- a/chrome/browser/chromeos/extensions/media_player_api.h
+++ b/chrome/browser/chromeos/extensions/media_player_api.h
@@ -13,18 +13,20 @@
 #include "chrome/browser/extensions/api/profile_keyed_api_factory.h"
 #include "extensions/browser/extension_function.h"
 
-class Profile;
+namespace content {
+class BrowserContext;
+}
 
 namespace extensions {
 class MediaPlayerEventRouter;
 
 class MediaPlayerAPI : public ProfileKeyedAPI {
  public:
-  explicit MediaPlayerAPI(Profile* profile);
+  explicit MediaPlayerAPI(content::BrowserContext* context);
   virtual ~MediaPlayerAPI();
 
   // Convenience method to get the MediaPlayerAPI for a profile.
-  static MediaPlayerAPI* Get(Profile* profile);
+  static MediaPlayerAPI* Get(content::BrowserContext* context);
 
   MediaPlayerEventRouter* media_player_event_router();
 
@@ -34,7 +36,7 @@ class MediaPlayerAPI : public ProfileKeyedAPI {
  private:
   friend class ProfileKeyedAPIFactory<MediaPlayerAPI>;
 
-  Profile* const profile_;
+  content::BrowserContext* const context_;

[James Cook, 2014/02/20 17:47:21]

nit: I like to call member variables |browser_context_| because just |context_|
seems too generic.  (Is it a window context? A graphics context? A browser
context?)

I use |context| for function parameters, since you can quickly see from the
function signature that |context| is a BrowserContext.

[Yoyo Zhou, 2014/02/20 22:44:54]

This was actually easy to fix with sed and git cl format.

 
   // ProfileKeyedAPI implementation.
   static const char* service_name() {