android: Introduce DisplayAndroid

android: Introduce DisplayAndroid

DisplayAndroid is the Display abstraction. It will eventually
replace all usage of DeviceDisplayInfo. Main difference is
DeviceDisplayInfo assumes there is only one display, whereas
DisplayAndroid can support many.

Move ScreenOrientationListener to the ui layer as an
implementation detail. Rewrote the tests to use
CallbackHelper.

BUG=625089
Committed: https://crrev.com/16136c0600c027d8dac41a3871f687851fd8d773
Cr-Commit-Position: refs/heads/master@{#423363}

[boliu, 2016-09-30 02:04:54]

The CQ bit was checked by boliu@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-09-30 02:05:24]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-09-30 03:30:26]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-09-30 03:30:27]

Dry run: Try jobs failed on following builders:
  android_clang_dbg_recipe on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_clan...)

[boliu, 2016-09-30 03:47:37]

Description was changed from

==========
android: Introduce DisplayAndroid

WORK IN PROGRESS

uploaded for back up

BUG=625089
==========

to

==========
android: Introduce DisplayAndroid

DisplayAndroid is the Display abstraction. It will eventually
replace all usage of DeviceDisplayInfo. Main difference is
DeviceDisplayInfo assumes there is only one display, whereas
DisplayAndroid can support many.

Move ScreenOrientationListener to the ui layer as an
implementation detail. Rewrote the tests to use
CallbackHelper.

BUG=625089
==========

[boliu, 2016-09-30 03:49:20]

boliu@chromium.org changed reviewers:
+ mlamouri@chromium.org, tedchoc@chromium.org

[boliu, 2016-09-30 03:49:21]

PTAL

tedchoc to review everything
mlamouri since I'm moving and rewriting your code :p

[boliu, 2016-10-02 04:19:02]

The CQ bit was checked by boliu@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-10-02 04:19:14]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[boliu, 2016-10-02 04:23:00]

The CQ bit was unchecked by boliu@chromium.org

[boliu, 2016-10-02 04:25:32]

The CQ bit was checked by boliu@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-10-02 04:25:40]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-10-02 05:00:16]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-10-02 05:00:17]

Dry run: Try jobs failed on following builders:
  android_clang_dbg_recipe on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_clan...)

[boliu, 2016-10-03 18:02:17]

Removed explicit refcounting and just use onDisplayRemoved instead, as Ted
suggested in person.

Also fixed deps to fix clang compile

PTAL

[boliu, 2016-10-04 06:16:01]

The CQ bit was checked by boliu@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-10-04 06:16:09]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-10-04 07:50:52]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-10-04 07:50:53]

Dry run: Try jobs failed on following builders:
  linux_android_rel_ng on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/linux_androi...)

[Ted C, 2016-10-04 20:01:13]

https://codereview.chromium.org/2361633002/diff/190001/ui/android/java/src/or...
File ui/android/java/src/org/chromium/ui/display/DisplayAndroid.java (right):

https://codereview.chromium.org/2361633002/diff/190001/ui/android/java/src/or...
ui/android/java/src/org/chromium/ui/display/DisplayAndroid.java:28: private
static final Observer[] sEmptyObserverArray = new Observer[0];
static final should go at the top.

following by static, followed by final, followed by everything else

And while neither chromium nor android are consistent, I think in this case I
would use CAPITAL_UPPERCASE naming.

I think the s<...> naming should be reserved for mutable containers.

https://codereview.chromium.org/2361633002/diff/190001/ui/android/java/src/or...
ui/android/java/src/org/chromium/ui/display/DisplayAndroid.java:39: Display
display = getDisplayFromContext(context);
random thoughts...

pre-SDK-17, did Android support multiple displays?

If we could detect them being attached, detached correctly, I was thinking maybe
we should proactively register for all displays and make this consistent with
displaymanager.

https://codereview.chromium.org/2361633002/diff/190001/ui/android/java/src/or...
ui/android/java/src/org/chromium/ui/display/DisplayAndroid.java:88: public
interface Observer {
like my comment in the other file, I would prefer DisplayChangeObserver or
something that is easier to grok w/o the leading class name.

https://codereview.chromium.org/2361633002/diff/190001/ui/android/java/src/or...
File ui/android/java/src/org/chromium/ui/display/DisplayAndroidListener.java
(right):

https://codereview.chromium.org/2361633002/diff/190001/ui/android/java/src/or...
ui/android/java/src/org/chromium/ui/display/DisplayAndroidListener.java:21: *
DisplayAndroidListener is a class that informs its observers when the
I think we need to update this comment since it's not just about screen
orientation.

https://codereview.chromium.org/2361633002/diff/190001/ui/android/java/src/or...
ui/android/java/src/org/chromium/ui/display/DisplayAndroidListener.java:25:
interface Observer {
I prefer to have the name fully qualified to make it easier to grok in the
consuming file.  DisplayAndroidChangeObserver.

Also, some sort of javadoc would be good here

https://codereview.chromium.org/2361633002/diff/190001/ui/android/java/src/or...
ui/android/java/src/org/chromium/ui/display/DisplayAndroidListener.java:28: void
onConfigurationChanged();  // Old Android version only.
Is there any way we can isolate these different behaviors to inside this class?

Seems like we could have onDisplayChanged(Display display) and
onConfigurationChanged and onDisplayChanged could do getDisplayFromId and
getDisplayFromContext inside here.

Or we could synthesize a display ID for older versions and maybe this class
could have a get display for ID that could handle it.

https://codereview.chromium.org/2361633002/diff/190001/ui/android/java/src/or...
ui/android/java/src/org/chromium/ui/display/DisplayAndroidListener.java:38:
private interface ScreenOrientationListenerBackend {
Should we be updating the documentation and naming of these now that it's not
necessarily tied so tightly w/ screen orientation?

Same for all the subsequent classes.

https://codereview.chromium.org/2361633002/diff/190001/ui/android/java/src/or...
ui/android/java/src/org/chromium/ui/display/DisplayAndroidListener.java:76:
private class ScreenOrientationConfigurationListener
I would probably name this classes with SDK based names as that is the true
reason to use one and not the other.

DeviceOrientationJellybeanListener or something that actually doesn't look gross
and is consistent with our other similar naming (if we have such a consistency)

[boliu, 2016-10-04 23:11:31]

https://codereview.chromium.org/2361633002/diff/190001/ui/android/java/src/or...
File ui/android/java/src/org/chromium/ui/display/DisplayAndroid.java (right):

https://codereview.chromium.org/2361633002/diff/190001/ui/android/java/src/or...
ui/android/java/src/org/chromium/ui/display/DisplayAndroid.java:28: private
static final Observer[] sEmptyObserverArray = new Observer[0];
On 2016/10/04 20:01:13, Ted C wrote:
> static final should go at the top.
> 
> following by static, followed by final, followed by everything else
> 
> And while neither chromium nor android are consistent, I think in this case I
> would use CAPITAL_UPPERCASE naming.
> 
> I think the s<...> naming should be reserved for mutable containers.

Done.

https://codereview.chromium.org/2361633002/diff/190001/ui/android/java/src/or...
ui/android/java/src/org/chromium/ui/display/DisplayAndroid.java:39: Display
display = getDisplayFromContext(context);
On 2016/10/04 20:01:13, Ted C wrote:
> random thoughts...
> 
> pre-SDK-17, did Android support multiple displays?

I don't think so. Presentation as added in 17:
https://developer.android.com/reference/android/app/Presentation.html

> 
> If we could detect them being attached, detached correctly, I was thinking
maybe
> we should proactively register for all displays and make this consistent with
> displaymanager.

I don't think it matters much either way?

https://codereview.chromium.org/2361633002/diff/190001/ui/android/java/src/or...
ui/android/java/src/org/chromium/ui/display/DisplayAndroid.java:88: public
interface Observer {
On 2016/10/04 20:01:13, Ted C wrote:
> like my comment in the other file, I would prefer DisplayChangeObserver or
> something that is easier to grok w/o the leading class name.

So same thing as the other one. I expect clients to not import this directly,
but do DisplayAndroid.Observer instead.

Do you feel strongly about this?

https://codereview.chromium.org/2361633002/diff/190001/ui/android/java/src/or...
File ui/android/java/src/org/chromium/ui/display/DisplayAndroidListener.java
(right):

https://codereview.chromium.org/2361633002/diff/190001/ui/android/java/src/or...
ui/android/java/src/org/chromium/ui/display/DisplayAndroidListener.java:21: *
DisplayAndroidListener is a class that informs its observers when the
On 2016/10/04 20:01:13, Ted C wrote:
> I think we need to update this comment since it's not just about screen
> orientation.

Done.

https://codereview.chromium.org/2361633002/diff/190001/ui/android/java/src/or...
ui/android/java/src/org/chromium/ui/display/DisplayAndroidListener.java:25:
interface Observer {
On 2016/10/04 20:01:13, Ted C wrote:
> I prefer to have the name fully qualified to make it easier to grok in the
> consuming file.  DisplayAndroidChangeObserver.

I actually don't agree with this one.

Won't all the use cases outside of this file be DisplayAndroidListener.Observer?
Then having to type DisplayAndroidListener.DisplayAndroidChangeObserver is just
more verbose..

> 
> Also, some sort of javadoc would be good here

Added some javadoc, but this whole file is supposed to only be package visible,
ie an implementation detail of DisplayAndroid

https://codereview.chromium.org/2361633002/diff/190001/ui/android/java/src/or...
ui/android/java/src/org/chromium/ui/display/DisplayAndroidListener.java:28: void
onConfigurationChanged();  // Old Android version only.
On 2016/10/04 20:01:13, Ted C wrote:
> Is there any way we can isolate these different behaviors to inside this
class?
> 
> Seems like we could have onDisplayChanged(Display display) and
> onConfigurationChanged and onDisplayChanged could do getDisplayFromId and
> getDisplayFromContext inside here.
> 
> Or we could synthesize a display ID for older versions and maybe this class
> could have a get display for ID that could handle it.

There is no need to synthesize display ID. There is an ID for the one and only
display on API 16 as well

But again, this is an internal implementation, and this change is just moving
the getting the context and retrieving the correct display from DisplayAndroid
to here. Seems kinda pointless to me?

https://codereview.chromium.org/2361633002/diff/190001/ui/android/java/src/or...
ui/android/java/src/org/chromium/ui/display/DisplayAndroidListener.java:38:
private interface ScreenOrientationListenerBackend {
On 2016/10/04 20:01:13, Ted C wrote:
> Should we be updating the documentation and naming of these now that it's not
> necessarily tied so tightly w/ screen orientation?
> 
> Same for all the subsequent classes.

Err, yes. Changed to DisplayListnerBackend, and the like. And purged the word
"orientation" from this file.

https://codereview.chromium.org/2361633002/diff/190001/ui/android/java/src/or...
ui/android/java/src/org/chromium/ui/display/DisplayAndroidListener.java:76:
private class ScreenOrientationConfigurationListener
On 2016/10/04 20:01:13, Ted C wrote:
> I would probably name this classes with SDK based names as that is the true
> reason to use one and not the other.
> 
> DeviceOrientationJellybeanListener or something that actually doesn't look
gross
> and is consistent with our other similar naming (if we have such a
consistency)

DisplayListenerAPI16..? JB has a lot of api levels..

https://codereview.chromium.org/2361633002/diff/190001/ui/android/java/src/or...
ui/android/java/src/org/chromium/ui/display/DisplayAndroidListener.java:273:
private void notifyObservers() {
renamed this to updateDeviceDisplayInfo, and actually still call this

[boliu, 2016-10-04 23:20:20]

https://codereview.chromium.org/2361633002/diff/190001/ui/android/java/src/or...
File ui/android/java/src/org/chromium/ui/display/DisplayAndroid.java (right):

https://codereview.chromium.org/2361633002/diff/190001/ui/android/java/src/or...
ui/android/java/src/org/chromium/ui/display/DisplayAndroid.java:39: Display
display = getDisplayFromContext(context);
On 2016/10/04 23:11:30, boliu wrote:
> On 2016/10/04 20:01:13, Ted C wrote:
> > random thoughts...
> > 
> > pre-SDK-17, did Android support multiple displays?
> 
> I don't think so. Presentation as added in 17:
> https://developer.android.com/reference/android/app/Presentation.html
> 
> > 
> > If we could detect them being attached, detached correctly, I was thinking
> maybe
> > we should proactively register for all displays and make this consistent
with
> > displaymanager.
> 
> I don't think it matters much either way?

Hmm, actually. It allows having exactly one DisplayAndroidListener.Observer and
get rid of the observer lists in DisplayAndroidListener. hmm...

[boliu, 2016-10-04 23:23:04]

https://codereview.chromium.org/2361633002/diff/190001/ui/android/java/src/or...
File ui/android/java/src/org/chromium/ui/display/DisplayAndroid.java (right):

https://codereview.chromium.org/2361633002/diff/190001/ui/android/java/src/or...
ui/android/java/src/org/chromium/ui/display/DisplayAndroid.java:39: Display
display = getDisplayFromContext(context);
On 2016/10/04 23:20:19, boliu wrote:
> On 2016/10/04 23:11:30, boliu wrote:
> > On 2016/10/04 20:01:13, Ted C wrote:
> > > random thoughts...
> > > 
> > > pre-SDK-17, did Android support multiple displays?
> > 
> > I don't think so. Presentation as added in 17:
> > https://developer.android.com/reference/android/app/Presentation.html
> > 
> > > 
> > > If we could detect them being attached, detached correctly, I was thinking
> > maybe
> > > we should proactively register for all displays and make this consistent
> with
> > > displaymanager.
> > 
> > I don't think it matters much either way?
> 
> Hmm, actually. It allows having exactly one DisplayAndroidListener.Observer
and
> get rid of the observer lists in DisplayAndroidListener. hmm...

Ok, I like that, doing it!

[boliu, 2016-10-05 01:30:21]

Ok, all done as discussed in person I think. But split into multiple patch sets
to make review easier.

PS14 does the "DisplayAndroidManager" refactor, except it doesn't rename, so you
can still diff the same file.
The PS15 renames to DisplayAndroidManager
And PS16 renames Observer to DisplayAndroidObserver

[Ted C, 2016-10-05 16:47:27]

this definitely feels right to me...last round of comments and I think we're
good to go

https://codereview.chromium.org/2361633002/diff/290001/content/public/android...
File
content/public/android/java/src/org/chromium/content/browser/ContentViewCore.java
(right):

https://codereview.chromium.org/2361633002/diff/290001/content/public/android...
content/public/android/java/src/org/chromium/content/browser/ContentViewCore.java:707:
onRotationChanged(windowAndroid.getDisplay().getRotation());
is this a change in behavior?  i.e. are we going to be announcing rotation
changing more often?

If so, should we cache the last rotation and only notify if it changed.  or one
of those things that is an early optimization that we shouldn't worry about for
now.

https://codereview.chromium.org/2361633002/diff/290001/ui/android/java/src/or...
File ui/android/java/src/org/chromium/ui/display/DisplayAndroid.java (right):

https://codereview.chromium.org/2361633002/diff/290001/ui/android/java/src/or...
ui/android/java/src/org/chromium/ui/display/DisplayAndroid.java:39:
sDisplayAndroidManager = new DisplayAndroidManager();
should we make the manager a singleton within it's own class and just expose a
getInstance...seems more common of a pattern

https://codereview.chromium.org/2361633002/diff/290001/ui/android/java/src/or...
ui/android/java/src/org/chromium/ui/display/DisplayAndroid.java:89: public
interface DisplayAndroidObserver {
I would move this to the top of the class

https://codereview.chromium.org/2361633002/diff/290001/ui/android/java/src/or...
ui/android/java/src/org/chromium/ui/display/DisplayAndroid.java:164: void
onDisplayChanged() {
I would get rid of onDisplayChanged and onConfigurationChanged and have
updateFromDisplay be called directly from the manager.

https://codereview.chromium.org/2361633002/diff/290001/ui/android/java/src/or...
File ui/android/java/src/org/chromium/ui/display/DisplayAndroidManager.java
(right):

https://codereview.chromium.org/2361633002/diff/290001/ui/android/java/src/or...
ui/android/java/src/org/chromium/ui/display/DisplayAndroidManager.java:1: //
Copyright 2014 The Chromium Authors. All rights reserved.
2016

https://codereview.chromium.org/2361633002/diff/290001/ui/android/java/src/or...
ui/android/java/src/org/chromium/ui/display/DisplayAndroidManager.java:27: *
DisplayListenerBackend is an interface that abstract the
can you update the javadoc to wrap at 100 chars

https://codereview.chromium.org/2361633002/diff/290001/ui/android/java/src/or...
ui/android/java/src/org/chromium/ui/display/DisplayAndroidManager.java:70:
private int mAccurateCount = 0;
no need for = 0

https://codereview.chromium.org/2361633002/diff/290001/ui/android/java/src/or...
ui/android/java/src/org/chromium/ui/display/DisplayAndroidManager.java:156:
mIdMap.remove(sdkDisplayId);
should we notify the display that is was removed?  drop its observers,
potentially have an observer method to tell others that it has been removed?  I
guess we don't need it now and can add it later.

https://codereview.chromium.org/2361633002/diff/290001/ui/android/java/src/or...
ui/android/java/src/org/chromium/ui/display/DisplayAndroidManager.java:207:
mMainSdkDisplayId = display.getDisplayId();
could DisplayListenerAPI16 take the id as an input and we could better isolate
that within that class?

https://codereview.chromium.org/2361633002/diff/290001/ui/android/java/src/or...
ui/android/java/src/org/chromium/ui/display/DisplayAndroidManager.java:211:
public DisplayAndroid getDisplayAndroid(int sdkDisplayId) {
should all of these be package protected?  I guess it doesn't matter since the
class is.

[boliu, 2016-10-05 20:05:08]

https://codereview.chromium.org/2361633002/diff/290001/content/public/android...
File
content/public/android/java/src/org/chromium/content/browser/ContentViewCore.java
(right):

https://codereview.chromium.org/2361633002/diff/290001/content/public/android...
content/public/android/java/src/org/chromium/content/browser/ContentViewCore.java:707:
onRotationChanged(windowAndroid.getDisplay().getRotation());
On 2016/10/05 16:47:26, Ted C wrote:
> is this a change in behavior?  i.e. are we going to be announcing rotation
> changing more often?
> 
> If so, should we cache the last rotation and only notify if it changed.  or
one
> of those things that is an early optimization that we shouldn't worry about
for
> now.

No. This logic used to live in OrientationListener, when you add an observer,
the observer gets immediately informed of the current orientation. Also the "if
changed" check is in ContentViewCoreImpl::SendOrientationChangeEvent. Saving a
JNI call probalby isn't worth it?

https://codereview.chromium.org/2361633002/diff/290001/ui/android/java/src/or...
File ui/android/java/src/org/chromium/ui/display/DisplayAndroid.java (right):

https://codereview.chromium.org/2361633002/diff/290001/ui/android/java/src/or...
ui/android/java/src/org/chromium/ui/display/DisplayAndroid.java:39:
sDisplayAndroidManager = new DisplayAndroidManager();
On 2016/10/05 16:47:26, Ted C wrote:
> should we make the manager a singleton within it's own class and just expose a
> getInstance...seems more common of a pattern

Done. Kept this method though, since it's shorter to type everywhere :p

https://codereview.chromium.org/2361633002/diff/290001/ui/android/java/src/or...
ui/android/java/src/org/chromium/ui/display/DisplayAndroid.java:89: public
interface DisplayAndroidObserver {
On 2016/10/05 16:47:26, Ted C wrote:
> I would move this to the top of the class

Done.

https://codereview.chromium.org/2361633002/diff/290001/ui/android/java/src/or...
ui/android/java/src/org/chromium/ui/display/DisplayAndroid.java:164: void
onDisplayChanged() {
On 2016/10/05 16:47:26, Ted C wrote:
> I would get rid of onDisplayChanged and onConfigurationChanged and have
> updateFromDisplay be called directly from the manager.

good call, much cleaner

https://codereview.chromium.org/2361633002/diff/290001/ui/android/java/src/or...
File ui/android/java/src/org/chromium/ui/display/DisplayAndroidManager.java
(right):

https://codereview.chromium.org/2361633002/diff/290001/ui/android/java/src/or...
ui/android/java/src/org/chromium/ui/display/DisplayAndroidManager.java:1: //
Copyright 2014 The Chromium Authors. All rights reserved.
On 2016/10/05 16:47:27, Ted C wrote:
> 2016

if you squint hard enough, this is actually a moved file! ok ok, 2016

https://codereview.chromium.org/2361633002/diff/290001/ui/android/java/src/or...
ui/android/java/src/org/chromium/ui/display/DisplayAndroidManager.java:27: *
DisplayListenerBackend is an interface that abstract the
On 2016/10/05 16:47:27, Ted C wrote:
> can you update the javadoc to wrap at 100 chars

Done.

https://codereview.chromium.org/2361633002/diff/290001/ui/android/java/src/or...
ui/android/java/src/org/chromium/ui/display/DisplayAndroidManager.java:70:
private int mAccurateCount = 0;
On 2016/10/05 16:47:26, Ted C wrote:
> no need for = 0

Done.

https://codereview.chromium.org/2361633002/diff/290001/ui/android/java/src/or...
ui/android/java/src/org/chromium/ui/display/DisplayAndroidManager.java:156:
mIdMap.remove(sdkDisplayId);
On 2016/10/05 16:47:26, Ted C wrote:
> should we notify the display that is was removed?  drop its observers,
> potentially have an observer method to tell others that it has been removed? 
I
> guess we don't need it now and can add it later.

Yeah I think add it later is good. I think if chrome decides to support multi
display, a lot of that information will come implicitly, like say the
Presentation being destroyed, something like that.

https://codereview.chromium.org/2361633002/diff/290001/ui/android/java/src/or...
ui/android/java/src/org/chromium/ui/display/DisplayAndroidManager.java:211:
public DisplayAndroid getDisplayAndroid(int sdkDisplayId) {
On 2016/10/05 16:47:27, Ted C wrote:
> should all of these be package protected?  I guess it doesn't matter since the
> class is.

Done.

[Ted C, 2016-10-05 23:24:27]

lgtm

[boliu, 2016-10-05 23:37:46]

The CQ bit was checked by boliu@chromium.org

[boliu, 2016-10-05 23:37:47]

The patchset sent to the CQ was uploaded after l-g-t-m from tedchoc@chromium.org
Link to the patchset: https://codereview.chromium.org/2361633002/#ps330001
(title: "test comments")

[commit-bot: I haz the power, 2016-10-05 23:38:32]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-10-06 00:55:47]

Description was changed from

==========
android: Introduce DisplayAndroid

DisplayAndroid is the Display abstraction. It will eventually
replace all usage of DeviceDisplayInfo. Main difference is
DeviceDisplayInfo assumes there is only one display, whereas
DisplayAndroid can support many.

Move ScreenOrientationListener to the ui layer as an
implementation detail. Rewrote the tests to use
CallbackHelper.

BUG=625089
==========

to

==========
android: Introduce DisplayAndroid

DisplayAndroid is the Display abstraction. It will eventually
replace all usage of DeviceDisplayInfo. Main difference is
DeviceDisplayInfo assumes there is only one display, whereas
DisplayAndroid can support many.

Move ScreenOrientationListener to the ui layer as an
implementation detail. Rewrote the tests to use
CallbackHelper.

BUG=625089
==========

[commit-bot: I haz the power, 2016-10-06 00:55:48]

Committed patchset #18 (id:330001)

[commit-bot: I haz the power, 2016-10-06 00:58:36]

Description was changed from

==========
android: Introduce DisplayAndroid

DisplayAndroid is the Display abstraction. It will eventually
replace all usage of DeviceDisplayInfo. Main difference is
DeviceDisplayInfo assumes there is only one display, whereas
DisplayAndroid can support many.

Move ScreenOrientationListener to the ui layer as an
implementation detail. Rewrote the tests to use
CallbackHelper.

BUG=625089
==========

to

==========
android: Introduce DisplayAndroid

DisplayAndroid is the Display abstraction. It will eventually
replace all usage of DeviceDisplayInfo. Main difference is
DeviceDisplayInfo assumes there is only one display, whereas
DisplayAndroid can support many.

Move ScreenOrientationListener to the ui layer as an
implementation detail. Rewrote the tests to use
CallbackHelper.

BUG=625089

Committed: https://crrev.com/16136c0600c027d8dac41a3871f687851fd8d773
Cr-Commit-Position: refs/heads/master@{#423363}
==========

[commit-bot: I haz the power, 2016-10-06 00:58:37]

Patchset 18 (id:??) landed as
https://crrev.com/16136c0600c027d8dac41a3871f687851fd8d773
Cr-Commit-Position: refs/heads/master@{#423363}