Adds the skeleton of a NativeViewport concept.

This is a platform-specific View (output surface and event sink). We listen for events and other disposition changes and forward them to app code. In this case I just do something ad-hoc (stringify some event metadata and post to our existing sample app). Once we have bindings, we can surface a better API here. I would also like for the app to request the NativeViewportService from the Service Service, and get a separate pipe for that, rather than reusing the one that is passed through MojoMain (which I think is supposed to only be for surfacing the ServiceService).

Anyway WDYT? If we agree on this I can figure out how to wrap the org.chromium.mojo_shell_apk.MojoView in a NativeViewport.

BUG=
R=abarth@chromium.org

Review URL: https://codereview.chromium.org/51373002

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@232210 0039d316-1c4b-4281-b951-d872f2087c98


CrOS-Libchrome-Original-Commit: ab900db95eaae7d5a3eb561c9adba605250e1778
10 files changed
tree: 336e48e5480580a647e638fb6a0aca2b640572e0
  1. base/
  2. build/
  3. components/
  4. dbus/
  5. ipc/
  6. mojo/
  7. testing/
  8. third_party/
  9. ui/