Hook up RendererMediaSessionManager with browser side

content/browser/media/android/browser_media_session_manager.cc

+// Copyright 2015 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.
+
+#include "content/browser/media/android/browser_media_session_manager.h"
+
+#include "content/common/media/media_session_messages_android.h"
+#include "content/public/browser/render_frame_host.h"
+
+namespace content {
+
+BrowserMediaSessionManager::BrowserMediaSessionManager(
+    RenderFrameHost* render_frame_host)
+    : render_frame_host_(render_frame_host) {}
+
+void BrowserMediaSessionManager::OnActivate(int session_id, int request_id) {
+  NOTIMPLEMENTED();

[Mike West, 2015/12/09 17:39:59]

What are these eventually going to do? It's difficult to evaluate the privilege
this grants to a renderer without code. ;)

Basically, I want to know what a corrupted renderer could do if it could send
this message to the browser process. Skimming the spec, discussion of "keys"
worries me. What kinds of keys would a user/renderer process gain access to?

[davve, 2015/12/10 08:28:38]

I can't blame you. :) (To some extent considering security implications
must be an ongoing process, not just a one-off when adding the IPC
messages?)

These two specific messages will activate and deactivate media
sessions on android. This boils down to requesting audio focus as
described in:

http://developer.android.com/training/managing-audio/audio-focus.html

This is already done implicitly when starting media playback. What
these messages enable is a javascript API to explicitly request audio
focus without actually playing. The API is promise based and the
return messages are for knowing when activation and deactivation have
completed.
Multimedia keys. On Android, one example is the play/pause button on
your headphones. The renderer process doesn't get access to the keys
themselves, but might enable or disable them for certain ongoing media
playback.

https://code.google.com/p/chromium/codesearch#chromium/src/content/browser/me...

will do the actual work, perhaps with a little more of its guts
exposed to allow activating at will.

I don't see a new attack surface exposed, except from annoying the
user that their background Spotify went quiet for some to them unknown
reason.

+  Send(new MediaSessionMsg_DidActivate(GetRoutingID(), request_id, false));
+}
+
+void BrowserMediaSessionManager::OnDeactivate(int session_id, int request_id) {
+  NOTIMPLEMENTED();
+  Send(new MediaSessionMsg_DidDeactivate(GetRoutingID(), request_id));
+}
+
+int BrowserMediaSessionManager::GetRoutingID() const {
+  return render_frame_host_->GetRoutingID();
+}
+
+bool BrowserMediaSessionManager::Send(IPC::Message* msg) {
+  return render_frame_host_->Send(msg);
+}
+
+}  // namespace content