Revert of Android: support multiple displays on C++ side

Revert of Android: support multiple displays on C++ side (patchset #32 id:690001 of https://codereview.chromium.org/2416403002/ )

Reason for revert:
Revert to see whether it fixes failures in webkit_tests, e.g.
https://uberchromegw.corp.google.com/i/chromium.webkit/builders/WebKit%20Android%20%28Nexus4%29/builds/57004

see http://crbug.com/666420

unexpected_failures:
svg/batik/text/textAnchor3.svg
images/paletted-png-with-color-profile.html
svg/W3C-SVG-1.1-SE/coords-dom-02-f.svg
svg/as-background-image/svg-width-100p-as-background.html

Original issue's description:
> Android: support multiple displays on C++ side
>
> Starting with API 17 Android can have multiple displays.
>
> CL https://codereview.chromium.org/2361633002 introduced the map
> of DisplayAndroid objects on Java side. This CL uses the information
> from Java layer to maintain a similar map on the native side.
>
> Similar to other platforms, an individual display is represented
> by a Display object, and the collection of all displays in the
> system is the Screen object. The Screen object for Android
> maintains the mapping between the Android display ID and Display
> and receives updates from DisplayAndroidManager.java through JNI.
> Therefore the Screen implementation is placed in DisplayAndroidManager
> class.
>
> The Screen interface assumes the existence of the primary display.
> To support this we always add the primary display on the Java side
> (it is propagated to native) during the initialization of
> DisplayAndroidManager.java
>
> Native DisplayAndroidManager obtains the display ID from WindowAndroid
> and thus depends on /ui/android. This CL places the manager in /ui/android
> as well. Because of this we have to explicitly initialize the Screen
> singleton by calling SetScreenAndroid() (similar to
> other platforms) instead of creating the Screen object on demand.
>
> The explicit initialization of the Screen happens on most platforms,
> and required some tests modification.
>
> Note: the explicit initialization of the Android Screen object required
> some tests modification. Since the screen used to be created on demand,
> we could have missed some tests that run on Android and not
> covered by CQ.
>
> BUG=625089
>
> Committed: https://crrev.com/3da850c3bfadcf3d83407bb4aa9b1e047cbd44a8
> Cr-Commit-Position: refs/heads/master@{#432310}

TBR=boliu@chromium.org,tedchoc@chromium.org,mthiesse@chromium.org,sky@chromium.org,derat@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=625089
Committed: https://crrev.com/ece04082b79fd30261b48ad895e7f05beeda7823
Cr-Commit-Position: refs/heads/master@{#433108}

[Tima Vaisburd, 2016-11-18 00:20:57]

The CQ bit was checked by timav@chromium.org

[Tima Vaisburd, 2016-11-18 00:20:57]

Created Revert of Android: support multiple displays on C++ side

[commit-bot: I haz the power, 2016-11-18 00:23:15]

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-11-18 04:39:19]

Description was changed from

==========
Revert of Android: support multiple displays on C++ side (patchset #32 id:690001
of https://codereview.chromium.org/2416403002/ )

Reason for revert:
Revert to see whether it fixes failures in webkit_tests, e.g.
https://uberchromegw.corp.google.com/i/chromium.webkit/builders/WebKit%20Andr...

see http://crbug.com/666420


unexpected_failures:
svg/batik/text/textAnchor3.svg
images/paletted-png-with-color-profile.html
svg/W3C-SVG-1.1-SE/coords-dom-02-f.svg
svg/as-background-image/svg-width-100p-as-background.html

Original issue's description:
> Android: support multiple displays on C++ side
> 
> Starting with API 17 Android can have multiple displays.
> 
> CL https://codereview.chromium.org/2361633002 introduced the map
> of DisplayAndroid objects on Java side. This CL uses the information
> from Java layer to maintain a similar map on the native side.
> 
> Similar to other platforms, an individual display is represented
> by a Display object, and the collection of all displays in the
> system is the Screen object. The Screen object for Android
> maintains the mapping between the Android display ID and Display
> and receives updates from DisplayAndroidManager.java through JNI.
> Therefore the Screen implementation is placed in DisplayAndroidManager
> class.
> 
> The Screen interface assumes the existence of the primary display.
> To support this we always add the primary display on the Java side
> (it is propagated to native) during the initialization of
> DisplayAndroidManager.java
> 
> Native DisplayAndroidManager obtains the display ID from WindowAndroid
> and thus depends on /ui/android. This CL places the manager in /ui/android
> as well. Because of this we have to explicitly initialize the Screen
> singleton by calling SetScreenAndroid() (similar to
> other platforms) instead of creating the Screen object on demand.
> 
> The explicit initialization of the Screen happens on most platforms,
> and required some tests modification.
> 
> Note: the explicit initialization of the Android Screen object required
> some tests modification. Since the screen used to be created on demand,
> we could have missed some tests that run on Android and not
> covered by CQ.
> 
> BUG=625089
> 
> Committed: https://crrev.com/3da850c3bfadcf3d83407bb4aa9b1e047cbd44a8
> Cr-Commit-Position: refs/heads/master@{#432310}

TBR=boliu@chromium.org,tedchoc@chromium.org,mthiesse@chromium.org,sky@chromiu...
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=625089
==========

to

==========
Revert of Android: support multiple displays on C++ side (patchset #32 id:690001
of https://codereview.chromium.org/2416403002/ )

Reason for revert:
Revert to see whether it fixes failures in webkit_tests, e.g.
https://uberchromegw.corp.google.com/i/chromium.webkit/builders/WebKit%20Andr...

see http://crbug.com/666420


unexpected_failures:
svg/batik/text/textAnchor3.svg
images/paletted-png-with-color-profile.html
svg/W3C-SVG-1.1-SE/coords-dom-02-f.svg
svg/as-background-image/svg-width-100p-as-background.html

Original issue's description:
> Android: support multiple displays on C++ side
> 
> Starting with API 17 Android can have multiple displays.
> 
> CL https://codereview.chromium.org/2361633002 introduced the map
> of DisplayAndroid objects on Java side. This CL uses the information
> from Java layer to maintain a similar map on the native side.
> 
> Similar to other platforms, an individual display is represented
> by a Display object, and the collection of all displays in the
> system is the Screen object. The Screen object for Android
> maintains the mapping between the Android display ID and Display
> and receives updates from DisplayAndroidManager.java through JNI.
> Therefore the Screen implementation is placed in DisplayAndroidManager
> class.
> 
> The Screen interface assumes the existence of the primary display.
> To support this we always add the primary display on the Java side
> (it is propagated to native) during the initialization of
> DisplayAndroidManager.java
> 
> Native DisplayAndroidManager obtains the display ID from WindowAndroid
> and thus depends on /ui/android. This CL places the manager in /ui/android
> as well. Because of this we have to explicitly initialize the Screen
> singleton by calling SetScreenAndroid() (similar to
> other platforms) instead of creating the Screen object on demand.
> 
> The explicit initialization of the Screen happens on most platforms,
> and required some tests modification.
> 
> Note: the explicit initialization of the Android Screen object required
> some tests modification. Since the screen used to be created on demand,
> we could have missed some tests that run on Android and not
> covered by CQ.
> 
> BUG=625089
> 
> Committed: https://crrev.com/3da850c3bfadcf3d83407bb4aa9b1e047cbd44a8
> Cr-Commit-Position: refs/heads/master@{#432310}

TBR=boliu@chromium.org,tedchoc@chromium.org,mthiesse@chromium.org,sky@chromiu...
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=625089
==========

[commit-bot: I haz the power, 2016-11-18 04:39:19]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2016-11-18 04:45:07]

Description was changed from

==========
Revert of Android: support multiple displays on C++ side (patchset #32 id:690001
of https://codereview.chromium.org/2416403002/ )

Reason for revert:
Revert to see whether it fixes failures in webkit_tests, e.g.
https://uberchromegw.corp.google.com/i/chromium.webkit/builders/WebKit%20Andr...

see http://crbug.com/666420


unexpected_failures:
svg/batik/text/textAnchor3.svg
images/paletted-png-with-color-profile.html
svg/W3C-SVG-1.1-SE/coords-dom-02-f.svg
svg/as-background-image/svg-width-100p-as-background.html

Original issue's description:
> Android: support multiple displays on C++ side
> 
> Starting with API 17 Android can have multiple displays.
> 
> CL https://codereview.chromium.org/2361633002 introduced the map
> of DisplayAndroid objects on Java side. This CL uses the information
> from Java layer to maintain a similar map on the native side.
> 
> Similar to other platforms, an individual display is represented
> by a Display object, and the collection of all displays in the
> system is the Screen object. The Screen object for Android
> maintains the mapping between the Android display ID and Display
> and receives updates from DisplayAndroidManager.java through JNI.
> Therefore the Screen implementation is placed in DisplayAndroidManager
> class.
> 
> The Screen interface assumes the existence of the primary display.
> To support this we always add the primary display on the Java side
> (it is propagated to native) during the initialization of
> DisplayAndroidManager.java
> 
> Native DisplayAndroidManager obtains the display ID from WindowAndroid
> and thus depends on /ui/android. This CL places the manager in /ui/android
> as well. Because of this we have to explicitly initialize the Screen
> singleton by calling SetScreenAndroid() (similar to
> other platforms) instead of creating the Screen object on demand.
> 
> The explicit initialization of the Screen happens on most platforms,
> and required some tests modification.
> 
> Note: the explicit initialization of the Android Screen object required
> some tests modification. Since the screen used to be created on demand,
> we could have missed some tests that run on Android and not
> covered by CQ.
> 
> BUG=625089
> 
> Committed: https://crrev.com/3da850c3bfadcf3d83407bb4aa9b1e047cbd44a8
> Cr-Commit-Position: refs/heads/master@{#432310}

TBR=boliu@chromium.org,tedchoc@chromium.org,mthiesse@chromium.org,sky@chromiu...
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=625089
==========

to

==========
Revert of Android: support multiple displays on C++ side (patchset #32 id:690001
of https://codereview.chromium.org/2416403002/ )

Reason for revert:
Revert to see whether it fixes failures in webkit_tests, e.g.
https://uberchromegw.corp.google.com/i/chromium.webkit/builders/WebKit%20Andr...

see http://crbug.com/666420

unexpected_failures:
svg/batik/text/textAnchor3.svg
images/paletted-png-with-color-profile.html
svg/W3C-SVG-1.1-SE/coords-dom-02-f.svg
svg/as-background-image/svg-width-100p-as-background.html

Original issue's description:
> Android: support multiple displays on C++ side
>
> Starting with API 17 Android can have multiple displays.
>
> CL https://codereview.chromium.org/2361633002 introduced the map
> of DisplayAndroid objects on Java side. This CL uses the information
> from Java layer to maintain a similar map on the native side.
>
> Similar to other platforms, an individual display is represented
> by a Display object, and the collection of all displays in the
> system is the Screen object. The Screen object for Android
> maintains the mapping between the Android display ID and Display
> and receives updates from DisplayAndroidManager.java through JNI.
> Therefore the Screen implementation is placed in DisplayAndroidManager
> class.
>
> The Screen interface assumes the existence of the primary display.
> To support this we always add the primary display on the Java side
> (it is propagated to native) during the initialization of
> DisplayAndroidManager.java
>
> Native DisplayAndroidManager obtains the display ID from WindowAndroid
> and thus depends on /ui/android. This CL places the manager in /ui/android
> as well. Because of this we have to explicitly initialize the Screen
> singleton by calling SetScreenAndroid() (similar to
> other platforms) instead of creating the Screen object on demand.
>
> The explicit initialization of the Screen happens on most platforms,
> and required some tests modification.
>
> Note: the explicit initialization of the Android Screen object required
> some tests modification. Since the screen used to be created on demand,
> we could have missed some tests that run on Android and not
> covered by CQ.
>
> BUG=625089
>
> Committed: https://crrev.com/3da850c3bfadcf3d83407bb4aa9b1e047cbd44a8
> Cr-Commit-Position: refs/heads/master@{#432310}

TBR=boliu@chromium.org,tedchoc@chromium.org,mthiesse@chromium.org,sky@chromiu...
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=625089

Committed: https://crrev.com/ece04082b79fd30261b48ad895e7f05beeda7823
Cr-Commit-Position: refs/heads/master@{#433108}
==========

[commit-bot: I haz the power, 2016-11-18 04:45:08]

Patchset 1 (id:??) landed as
https://crrev.com/ece04082b79fd30261b48ad895e7f05beeda7823
Cr-Commit-Position: refs/heads/master@{#433108}

[Matt Giuca, 2016-11-18 04:57:05]

On 2016/11/18 04:45:08, commit-bot: I haz the power wrote:
> Patchset 1 (id:??) landed as
> https://crrev.com/ece04082b79fd30261b48ad895e7f05beeda7823
> Cr-Commit-Position: refs/heads/master@{#433108}

It finally landed!

PS: Please set BUG= when creating a revert to include the tracking bug for the
test failure (i.e., in this case 666420), so that when it lands it shows up in
that bug.