Mojo framework for AndroidOverlay.

media/base/android/android_overlay.h

Index: media/base/android/android_overlay.h
diff --git a/media/base/android/android_overlay.h b/media/base/android/android_overlay.h
index bc60356745ea88f50e05516c59fb3624ccc9204b..24201f10a9d0c0578c3062742244c0da4498d676 100644
--- a/media/base/android/android_overlay.h
+++ b/media/base/android/android_overlay.h
@@ -8,6 +8,7 @@
 #include "base/android/scoped_java_ref.h"
 #include "base/callback.h"
 #include "base/macros.h"
+#include "base/unguessable_token.h"
 #include "media/base/media_export.h"
 #include "ui/gfx/geometry/rect.h"
 #include "ui/gl/android/scoped_java_surface.h"
@@ -54,6 +55,9 @@ class MEDIA_EXPORT AndroidOverlay {
     Config(const Config&);
     ~Config();
 
+    // Implementation-specific token.
+    base::UnguessableToken routing_token;

[liberato (no reviews please), 2017/03/11 21:39:36]

it turns out that not only is (frame id, pid) a layering violation, it's also
implementation specific.  CVV-based overlay (currently used in AVDA) requires a
different integer token to work.  i hadn't thought of it that way before doing
the CVV => AndroidOverlay work last week.

so, i've removed (frame id, pid) from the mojo-specific code, and made a generic
token part of the AndroidOverlay config.

RenderFrameImpl will negotiate with RFHI to get a token for the mojo impl of
AndroidOverlay, which hides all of it from media and removes the need for
anybody to worry about the pid.

+
     gfx::Rect rect;
 
     ReadyCB ready_cb;