d6a5660a2c9f70c9a363d388a091542a378d57d1 |
|
21-Sep-2016 |
Santos Cordon <santoscordon@google.com> |
Add Brightness setting for VR Mode. This change saves and loads a different brightness setting when the user goes in and out of VR Mode. Bug: 30984614 Change-Id: If3c3e81b592e0c6fd037e5783559683e5cb58379
/frameworks/base/core/java/android/view/Display.java
|
966045d0702ca36df6e8c1e4597aaeb37436ca2f |
|
27-Dec-2016 |
Selim Cinek <cinek@google.com> |
DO NOT MERGE Revert "Add Brightness setting for VR Mode." This reverts commit 84980c7a93e93e7134c0198212e222e11eb5ccbd. Bug: 33895226 Bug: 30984614 Change-Id: I2652e77512bc870190e2172a629abac9341b2c4f
/frameworks/base/core/java/android/view/Display.java
|
84980c7a93e93e7134c0198212e222e11eb5ccbd |
|
21-Sep-2016 |
Santos Cordon <santoscordon@google.com> |
Add Brightness setting for VR Mode. This change saves and loads a different brightness setting when the user goes in and out of VR Mode. Bug: 30984614 Merged-In: Ie5578bbd6ea346f0eb34fe4abbfd604a5d7c0c93 Change-Id: Ie5578bbd6ea346f0eb34fe4abbfd604a5d7c0c93
/frameworks/base/core/java/android/view/Display.java
|
16ae0423516ec1146ff191b4e856e1a6f88ea495 |
|
26-Jul-2016 |
Michael Wright <michaelwr@google.com> |
Actually compare supported color modes. Also, provide an equals implemenation for HdrCapabilities. Bug: 30311415 Bug: 30367543 Change-Id: Ib8b9c9283519ae9baa48ecfecb8035848a9b29f0
/frameworks/base/core/java/android/view/Display.java
|
1c9977b762b4bac46b4470f04c898bfd17da5d90 |
|
12-Jul-2016 |
Michael Wright <michaelwr@google.com> |
Rename color transform to color mode and persist the value. Also, standardize on a set of possible modes for the displays to enter and separate the configuration of the color mode from the configuration of the display mode. Bug: 29044347 Change-Id: I6af0a7d1f11bc72d4cefc380f115c1fb00788864
/frameworks/base/core/java/android/view/Display.java
|
5f57a3d6d8a8ae97aa431386b76e35a70dbb9314 |
|
29-Jun-2016 |
Andrii Kulian <akulian@google.com> |
Clarify documentation of Display#getSize() Bug: 25945436 Change-Id: I8574faf56427f4a6fb7155c08e31ef1e0bdb2cfa
/frameworks/base/core/java/android/view/Display.java
|
1e7d1aa6a6bdee2c92245b5bef5aaa7167b8a311 |
|
17-May-2016 |
Hangyu Kuang <hkuang@google.com> |
Hide HdrCapabilities constructor. Bug:25684127 Change-Id: I1a30ab3c162d8891c8aea1447757c85942033a0d
/frameworks/base/core/java/android/view/Display.java
|
da802f5100fe2b19b5cb898efc2c66bdd7e19fd1 |
|
07-Apr-2016 |
Hangyu Kuang <hkuang@google.com> |
Unhide getHdrCapabilities and HdrCapabilities. Bug:25684127 Change-Id: Ibeefc566213da5b76deba13eb2224916a4fefd13
/frameworks/base/core/java/android/view/Display.java
|
9ff94c0251722c44eece7c3561b4ed36b286d4a8 |
|
31-Mar-2016 |
Michael Wright <michaelwr@google.com> |
Plumb HDR capabilities to Display Bug: 25684127 Change-Id: I0a4fcdc59aa1a7b295c8df03699466685300e735
/frameworks/base/core/java/android/view/Display.java
|
54ac21918481fe6f7aac1c0effde51f9e9860ae3 |
|
25-Apr-2016 |
Hangyu Kuang <hkuang@google.com> |
Revert "Revert "Hook up HDR capabilities from native SurfaceControl"" This reverts commit 2c38f45f27079492697a391e0a6221f77f485fbc. Bug:25684127
/frameworks/base/core/java/android/view/Display.java
|
2c38f45f27079492697a391e0a6221f77f485fbc |
|
18-Apr-2016 |
Dan Stoza <stoza@google.com> |
Revert "Hook up HDR capabilities from native SurfaceControl" This reverts commit 49d438ebdfcb7f2c202c80c820e32d1cde4bcf36. Change-Id: Ic41e3006f06784a9fe6adaba6445bb18f2e7fad1
/frameworks/base/core/java/android/view/Display.java
|
49d438ebdfcb7f2c202c80c820e32d1cde4bcf36 |
|
28-Mar-2016 |
Dan Stoza <stoza@google.com> |
Hook up HDR capabilities from native SurfaceControl Change-Id: Icb62d67adcec142fafe9e71097d4c7db36978806
/frameworks/base/core/java/android/view/Display.java
|
a052cbda8099d6665e77076ae86a3f1265306caa |
|
15-Mar-2016 |
Ronghua Wu <ronghuawu@google.com> |
Merge "core: add hdr capabilities to display" into nyc-dev
|
f173c323449840771312afe5cbec03a71281e6ff |
|
29-Feb-2016 |
Ronghua Wu <ronghuawu@google.com> |
core: add hdr capabilities to display Bug: 25684127 Change-Id: I6f86a77cf9507576e871bf20a2a99148deb45b5a
/frameworks/base/core/java/android/view/Display.java
|
a4bb9d3f527663862bcc2abc1cd81489bfc6754e |
|
11-Mar-2016 |
Andrii Kulian <akulian@google.com> |
Update Display#getRealMetrics() behaviour Update behaviour of the method to actually return real size of the display independent of current configuration. Bug: 27548818 Bug: 26986895 Change-Id: I64ba65f305801d97d30aed1c9a6cf6881c94ceda
/frameworks/base/core/java/android/view/Display.java
|
58e829f71d2c525309e5bb5a1c02dc64397df221 |
|
15-Sep-2015 |
Michael Wright <michaelwr@google.com> |
Add support for setting color transforms Bug: 24038268 Change-Id: I05275c906e02eb9e67331f6f909166eb08ad5536
/frameworks/base/core/java/android/view/Display.java
|
26698514fbac587675221149aca98f3ea6414d55 |
|
06-Jun-2015 |
Wale Ogunwale <ogunwale@google.com> |
Use DisplayAdjustments when creating display in ResourceManager We were previous only taking the Configuration into account when creating Display objects in the ResourceManager. This led to the Display object not containing critical CompatibilityInfo. We now take the entire DisplayAdjustment into account. Bug: 21637615 Change-Id: Ide5ff49bfa12791ad17993764f312836216b1dd8
/frameworks/base/core/java/android/view/Display.java
|
49e7ff9647e6547c2b852944a5435a05794b9951 |
|
15-May-2015 |
Adam Powell <adamp@google.com> |
Add Configuration data for round displays Add round values to the screenLayout field for Configuration and a convenience method to check roundness. Plumb this through the DisplayManager, making roundness the property of a DisplayAdapter. The built-in main display will read the configuration resource config_mainBuiltInDisplayIsRound to determine its roundness. Device-specific resource overlays should set this to true for devices with round primary displays. By default, this config resource inherits from the existing config_windowIsRound value currently used by some Android Wear device configurations. This change awaits another for aapt/native resources code to make the resource filtering system aware of this property. Change-Id: I1daced7ca6d6e172789e7c32bebfd43753bfa2ae
/frameworks/base/core/java/android/view/Display.java
|
b3b9eb3cfc5b3b3609a5d01258315798b38a5cf9 |
|
12-May-2015 |
P.Y. Laligand <pylaligand@google.com> |
DO NOT MERGE - Display mode switches. Knowledge of the various modes of a display is now available to apps, and they can request a specific mode for their windows. b/18241736 Change-Id: I8eb16ff713e878512faca3ca6662254f08a9be7f (cherry picked from commit 5c7773d86484aac5737667c604bd8fe8150c2136)
/frameworks/base/core/java/android/view/Display.java
|
d46747a1c64b6ca3282e8841833980ab91829436 |
|
16-Apr-2015 |
Jeff Brown <jeffbrown@google.com> |
Add support for disabling display scaling for development. Added two new options to the wm command. 1. Set the screen size based on dips rather than pixels using the current screen density. eg. adb shell wm size 320dpx320dp 2. Disable automatic scaling of the contents of the display. When combined with the previous command, this is useful for seeing how the UI would behave if the screen remained at its current density but changed physical size. eg. adb shell wm scaling off Bug: 19899223 Change-Id: I545f893ba4861494e995cf0457ebeba1050d28dc
/frameworks/base/core/java/android/view/Display.java
|
7c72668f19d404b01412abc67937b1b5c660df71 |
|
07-Feb-2015 |
Wale Ogunwale <ogunwale@google.com> |
Adjust activity display metrics based on stack configuration. Apps normally use context.getResources().getDisplayMetrics() or getWindowManager().getDefaultDisplay() to get information about the screen dimensions. Not all the screen space is available for apps in a multi-window environment, so we limit the dimensions of the display object exposed to the app to that of the containing stack. Bug: 19225079 Bug: 19354838 Change-Id: I8dc3a6c9b99ecedcca28fc4ddaba9f31feb4f871
/frameworks/base/core/java/android/view/Display.java
|
3f145a2f958320766ae9240c7a57debc20d578aa |
|
23-Jul-2014 |
Michael Wright <michaelwr@google.com> |
Add supported refresh rate to displays Change-Id: I51231dd6dd231d57dd1ac499349d6335121f07d5
/frameworks/base/core/java/android/view/Display.java
|
970d4132ea28e748c1010be39450a98bbf7466f3 |
|
19-Jul-2014 |
Jeff Brown <jeffbrown@google.com> |
Allow dreams to control screen state and brightness. Added setDozeScreenState() and setDozeScreenBrightness() methods to DreamService. The values specified here only take effect once startDozing is called and can be changed while dozing. This required some significant rework of the display power controller but the result seems quite nice and better represents the policy we want to apply. Changed the test dream a little bit to make it flash the screen every minute using the new functions. Bug: 15903322 Change-Id: I83bcc34503f1b87727d2b2b3c0ef08507f9f0808
/frameworks/base/core/java/android/view/Display.java
|
5dc219142a756d57355b511c8f8ab913c01710da |
|
18-Jul-2014 |
Jeff Brown <jeffbrown@google.com> |
Add new Display.STATE_DOZE_SUSPEND power state. Change-Id: Ia62f4f0d25234281dc600d0b7f08b3c6a312db7a
/frameworks/base/core/java/android/view/Display.java
|
77db7d09ff61ae4de5f75cd507d6e93cb2f4410a |
|
18-Jun-2014 |
Andy McFadden <fadden@android.com> |
Make two Display methods public Un-hide getAppVsyncOffsetNanos() and getPresentationDeadlineNanos(). Bug 14612039 Change-Id: I76bee166b7bda3b96db36ffcb8d946d2b713ac09
/frameworks/base/core/java/android/view/Display.java
|
e8b1aeb51e1e5da64f1d4fd40f2ee1e815886fe5 |
|
13-Jun-2014 |
Andy McFadden <fadden@android.com> |
Add two new display info fields This adds SurfaceFlinger's app VSYNC offset and buffer deadline values to DisplayInfo. The values will be available to apps through queries on a Display object (currently hidden). Bug 14612039 Change-Id: I48760f58a9d74d99651b02a9d595f420410f2bb5
/frameworks/base/core/java/android/view/Display.java
|
4e5c089ef3e62e7f658e71c0be262d09bd3e399b |
|
11-Apr-2014 |
Jeff Brown <jeffbrown@google.com> |
resolved conflicts for merge of 337e764d to master Change-Id: I8168dbf42b68c2f7b5ccb300e0080dddc627af26
|
037c33eae74bee2774897d969d48947f9abe254f |
|
09-Apr-2014 |
Jeff Brown <jeffbrown@google.com> |
Plumb display power state through display manager. Declare a new method, Display.getState() to retrieve the actual power state of a display. Improved documentation for Intent.ACTION_SCREEN_ON and Intent.ACTION_SCREEN_OFF to clarify what they really mean in terms of the interactive state of the device. Deprecated PowerManager.isScreenOn() and replaced it with PowerManager.isInteractive() with a more suggestive name and better documentation. Redirect display power state changes to go through the display manager first and only then head over to the power manager for legacy compatibility. Eliminated the bright here and woke here policy flags since they were unused. Simplified the input dispatch policy somewhat. Ensure that screen wake locks are respected up until the point when dozing really begins. Fixed a regression in DreamService where onDreamingStarted might be called before onWindowAttached. Bug: 13133142 Bug: 13472578 Bug: 13929355 Bug: 13760290 Change-Id: Iabef96921dd554ce3768fb18619cefc3230b5fb0
/frameworks/base/core/java/android/view/Display.java
|
7da5bbedc75d7143d5b2cf36c4876f7b09a88807 |
|
08-Nov-2013 |
Jeff Brown <jeffbrown@google.com> |
am c2b652fd: am 5182ea4b: am d40a4d74: Merge "Add media router service and integrate with remote displays." into klp-dev * commit 'c2b652fd4d386b79dc99af249b6ad3844e53fdf1': Add media router service and integrate with remote displays.
|
69b07161bebdb2c726e3a826c2268866f1a94517 |
|
07-Nov-2013 |
Jeff Brown <jeffbrown@google.com> |
Add media router service and integrate with remote displays. This change adds a new media router service whose purpose is to track global state information associated with media routes. This service publishes routes to the media router instance in application processes and handles requested state changes such as selecting or unselecting global routes. The service also binds to remote display provider services which can offer new remote display routes to the system. Includes a test application for manually verifying certain aspects of the operation of the media router service. The remote display provider interface is essentially a stripped down media route provider interface as defined in the support library media router implementation. For now, it is designed to be used only by first parties to publish remote display routes to the system so it is not exposed as public API in the SDK. In the future, the remote display provider interface will most likely be deprecated and replaced with a more featureful media route provider interface for third party integration, similar to what is in the support library today. Further patch sets integrate these new capabilities into the System UI and Settings for connecting remote displays. Bug: 11257292 Change-Id: I31109f23f17b474d17534d0f5f4503e388b081c2
/frameworks/base/core/java/android/view/Display.java
|
d9273d6f289d9b55da3fd0db2f659fdfb48106a8 |
|
31-May-2013 |
Tor Norbye <tnorbye@google.com> |
Add typedefs and nullness annotations. This changeset adds in typedef annotations (custom annotations marked with @IntDef) for various int parameters and return values in the API. It also adds nullness annotations for cases where the documentation explicitly mentioned null policy, or where it was blindingly obvious from the context. Also fixed some typos in the documentation. Change-Id: Ica27c01368895818e26237544edd8483007155bb
/frameworks/base/core/java/android/view/Display.java
|
7d00affce6e25b22fd8fc135933b3bf6b547a0dc |
|
03-Aug-2013 |
Jeff Brown <jeffbrown@google.com> |
Support public virtual displays. Refactor the new private virtual display API to also support creating public virtual displays with various characteristics. This feature requires special permissions and is only intended for use by the system. Change-Id: I44dd19f37cf76ea6d6e313afe42f4a412bd96663
/frameworks/base/core/java/android/view/Display.java
|
1abaa53dccccc5c94a395bad5fa54cf6783b6974 |
|
28-Jun-2013 |
Craig Mautner <cmautner@google.com> |
Do not reuse DisplayAdjustment in Display. Because the DisplayAdjustment in Display can be modified it should not use the reference of the DisplayAdjustment that is passed in to construct the Display. Copy the members of the DisplayAdjustment instead. Fixes bug 9622994 Change-Id: I8201b02eba3ef35af3e01f10402cd5dafec1fb23
/frameworks/base/core/java/android/view/Display.java
|
48d0d1886731ff19ed3fb47a5997be5df0d1bba8 |
|
11-Jun-2013 |
Craig Mautner <cmautner@google.com> |
Add activity token to display system. First step in adding activity specific information to displays. Replace CompatibilityInfoHolder with DisplayAdjustmentsHolder that holds an activity token in addition to the CompatibilityInfo. Change-Id: Ie113cd8dd9c62e0b5311204e039a4829096bea68
/frameworks/base/core/java/android/view/Display.java
|
a506a6ec94863a35acca9feb165db76ddac3892c |
|
04-Jun-2013 |
Jeff Brown <jeffbrown@google.com> |
Add an API to allow for creating private virtual displays. This change enables applications to create a private virtual display that renders its content to a surface of its own creation. The display is private in the sense that only the application that owns the display is allowed to place windows upon it. Mirroring and blanking is also disabled for these displays. Bug: 9192512 Change-Id: I852ea07f0c7df1d244e354e3daca3a6960285ca0
/frameworks/base/core/java/android/view/Display.java
|
c652de8141f5b8e3c6bcf8916842b6e106413b1a |
|
16-Feb-2013 |
Dianne Hackborn <hackbod@google.com> |
Implement display overscan support. The window manager now keeps track of the overscan of each display, with an API to set it. The overscan impacts how it positions windows in the display. There is a new set of APIs for windows to say they would like to go into the overscan region. There is a call into the window manager to set the overscan region for a display, and it now has a concept of display settings that it stores presistently. Also added a new "wm" command, moving the window manager specific commands from the "am" command to there and adding a new now to set the overscan region. Change-Id: Id2c8092db64fd0a982274fedac7658d82f30f9ff
/frameworks/base/core/java/android/view/Display.java
|
92130f6407dc51c58b3b941d28a6daf4e04b8d62 |
|
25-Oct-2012 |
Jeff Brown <jeffbrown@google.com> |
Add MediaRouter API to get presentation display. This new API makes it possible for an application to ask on which Display it should show a Presentation based on the currently selected media route. Also added a new API on DisplayManager to query displays that support a certain category of uses. Improved the documentation of the Presentation class to explain how to choose an appropriate Display for presentation. Bug: 7409073 Change-Id: Iab451215e570ae55f3718fc228303143c800fe51
/frameworks/base/core/java/android/view/Display.java
|
f0681b34dffc1510cbd9c3da5c3a7e695553fa8d |
|
24-Oct-2012 |
Jeff Brown <jeffbrown@google.com> |
Secure windows, secure surface views and secure displays. Add new API to determine whether a display is secure. Add new API to make a SurfaceView secure. Clarify documentation. Bug: 7368436 Change-Id: I7068c34c910e43b4bc72e43fa0dded59a25f0fe2
/frameworks/base/core/java/android/view/Display.java
|
77aebfdbae489c3712ae3f9bca29d01fb1f09dc2 |
|
02-Oct-2012 |
Jeff Brown <jeffbrown@google.com> |
Add new Display API for secure video capabilities. Added a new API to determine whether the display supports protected buffers so that an application can choose a different content stream or change how it decodes the content so that it will be viewable on the display. At present, wifi display does not fully support protected buffers although this may be enhanced in the future. Bug: 6986623 Change-Id: If53a53d72b0ec92753cc4b29f99fcb131e00449b
/frameworks/base/core/java/android/view/Display.java
|
565f0425ba60ced217ebe44422a1f2b2c62e2850 |
|
14-Sep-2012 |
Jeff Brown <jeffbrown@google.com> |
Fixup a comment. Change-Id: I7b73f7e0f0aa903e5cd02d1cdb678e65a6d40e0c
/frameworks/base/core/java/android/view/Display.java
|
c5df37c285221d0fb113f55b9e78b35632241d3f |
|
13-Sep-2012 |
Jeff Brown <jeffbrown@google.com> |
Add preliminary API for reporting display capabilities. Change-Id: Ie18dce5b5d130f9a7cdfca08cddbf9b099312277
/frameworks/base/core/java/android/view/Display.java
|
4ed8fe75e1dde1a2b9576f3862aecc5a572c56b5 |
|
31-Aug-2012 |
Jeff Brown <jeffbrown@google.com> |
More improvements to the display manager. Added more complete support for logical displays with support for mirroring, rotation and scaling. Improved the overlay display adapter's touch interactions. A big change here is that the display manager no longer relies on a single-threaded model to maintain its synchronization invariants. Unfortunately we had to change this so as to play nice with the fact that the window manager wants to own the surface flinger transaction around display and surface manipulations. As a result, the display manager has to be able to update displays from the context of any thread. It would be nice to make this process more cooperative. There are already several components competing to perform surface flinger transactions including the window manager, display manager, electron beam, overlay display window, and mouse pointer. They are not manipulating the same surfaces but they can collide with one another when they make global changes to the displays. Change-Id: I04f448594241f2004f6f3d1a81ccd12c566bf296
/frameworks/base/core/java/android/view/Display.java
|
bd6e1500aedc5461e832f69e76341bff0e55fa2b |
|
28-Aug-2012 |
Jeff Brown <jeffbrown@google.com> |
Add initial multi-display support. Split the DisplayManager into two parts. One part is bound to a Context and takes care of Display compatibility and caching Display objects on behalf of the Context. The other part is global and takes care of communicating with the DisplayManagerService, handling callbacks, and caching DisplayInfo objects on behalf of the process. Implemented support for enumerating Displays and getting callbacks when displays are added, removed or changed. Elaborated the roles of DisplayManagerService, DisplayAdapter, and DisplayDevice. We now support having multiple display adapters registered, each of which can register multiple display devices and configure them dynamically. Added an OverlayDisplayAdapter which is used to simulate secondary displays by means of overlay windows. Different configurations of overlays can be selected using a new setting in the Developer Settings panel. The overlays can be repositioned and resized by the user for convenience. At the moment, all displays are mirrors of display 0 and no display transformations are applied. This will be improved in future patches. Refactored the way that the window manager creates its threads. The OverlayDisplayAdapter needs to be able to use hardware acceleration so it must share the same UI thread as the Keyguard and window manager policy. We now handle this explicitly as part of starting up the system server. This puts us in a better position to consider how we might want to share (or not share) Loopers among components. Overlay displays are disabled when in safe mode or in only-core mode to reduce the number of dependencies started in these modes. Change-Id: Ic2a661d5448dde01b095ab150697cb6791d69bb5
/frameworks/base/core/java/android/view/Display.java
|
bf5740e75efd87ae0213486e78e029403804c6f0 |
|
20-Aug-2012 |
Jeff Brown <jeffbrown@google.com> |
Improve display manager debugging. Change-Id: Iae794fe99a7cf9809f64eafb216091126a2f7e39
/frameworks/base/core/java/android/view/Display.java
|
98365d7663cbd82979a5700faf0050220b01084d |
|
20-Aug-2012 |
Jeff Brown <jeffbrown@google.com> |
Refactor for multi-display support. Split WindowManagerImpl into two parts, the WindowManager interface implementation remains where it is but the global communications with the window manager are now handled by the WindowManagerGlobal class. This change greatly simplifies the challenge of having separate WindowManager instances for each Context. Removed WindowManagerImpl.getDefault(). This represents the bulk of this change. Most of the usages of this method were either to perform global functions (now handled by WindowManagerGlobal) or to obtain the default display (now handled by DisplayManager). Explicitly associate each new window with a display and make the Display object available to the View hierarchy. Add stubs for some new display manager API features. Start to split apart the concepts of display id and layer stack. since they operate at different layers of abstraction. While it's true that each logical display uniquely corresponds to a surface flinger layer stack, it is not necessarily the case that they must use the same ids. Added Display.getLayerStack() and started using it in places where it was relatively easy to do. Change-Id: I29ed909114dec86807c4d3a5059c3fa0358bea61
/frameworks/base/core/java/android/view/Display.java
|
2ab1b7d9abc1b720b63ae01abcf1df0dc780eed4 |
|
08-Aug-2012 |
Jeff Brown <jeffbrown@google.com> |
Make display info accessible from hidden api. Change-Id: I83f3899b9ef10da4fe9a71f40dee8e940b32ec46
/frameworks/base/core/java/android/view/Display.java
|
dde331cebd87982faded6818ad5f9927ff994c96 |
|
03-Aug-2012 |
Dianne Hackborn <hackbod@google.com> |
We can now (kind-of) change screen density on the fly. Preloaded drawables now have a density associated with them, so we can load the correct drawable if we are using a different density. Window manager now formally keeps track of the density for each screen, allowing it to be overridden like you can already do with size, and relies on this density to drive itself internally and the configurations it reports. There are a new set of Bitmap constructors where you provide a DisplayMetrics so they can be constructed with the correct density. (This will be for when you can have different windows in the same app running at different densities.) ActivityThread now watches for density changes, and pushes them to the DENSITY_DEVICE and Bitmap global density values for that process. A new am command allows you to change the density.
/frameworks/base/core/java/android/view/Display.java
|
fbe963f4ad8056c8615ce4bdfce5d1387fbf77ae |
|
03-Aug-2012 |
Jeff Brown <jeffbrown@google.com> |
Merge "Remove unnecessary code." into jb-mr1-dev
|
5098fd8a0e3d2da32d5c4ffa729959caf779fc75 |
|
03-Aug-2012 |
Jeff Brown <jeffbrown@google.com> |
Remove unnecessary code. Bug: 6926595 Change-Id: Ice3138675c024e9efe9c7922e1e0a05f19cdde54
/frameworks/base/core/java/android/view/Display.java
|
4f67ba6ba4e861b287a3ff0323c107aa77f66264 |
|
02-Aug-2012 |
Craig Mautner <cmautner@google.com> |
Refactor DisplayManagerService to be functional. Change-Id: Ieac1eca172be5dc5db45302d3afa26188acd4d6d
/frameworks/base/core/java/android/view/Display.java
|
908aecc3a63c5520d5b11da14a9383f885b7d126 |
|
01-Aug-2012 |
Dianne Hackborn <hackbod@google.com> |
Start moving away from DisplayMetrics.DENSITY_DEVICE. This puts in most of the infrastructure needed to allow us to switch between different densities at run time. The main remaining uses of the global are to initialize the Bitmap object (not sure what to do about that since it doesn't have anything passed in the constructor to get this information from), and being able to load drawables if we need a different density than what was preloaded by zygote. Change-Id: Ifdbfd6b7a5c59e6aa22e63b95b78d96af3d96848
/frameworks/base/core/java/android/view/Display.java
|
fa25bf5382467b1018bd9af7f1cb30a23d7d59f7 |
|
24-Jul-2012 |
Jeff Brown <jeffbrown@google.com> |
Add display manager skeleton. The purpose of this change is to remove direct reliance on SurfaceFlinger for describing the size and characteristics of displays. This patch also starts to make a distinction between logical displays and physical display devices. Currently, the window manager owns the concept of a logical display whereas the new display manager owns the concept of a physical display device. Change-Id: I7e0761f83f033be6c06fd1041280c21500bcabc0
/frameworks/base/core/java/android/view/Display.java
|
a8b9defade5b937d4ad64f9aff4bca792298f43c |
|
23-Jul-2012 |
Jeff Brown <jeffbrown@google.com> |
Stop using raw display size except in window manager. We don't actually need the raw size in these places. The logical size is good enough. Starting to move dependencies on surface flinger and window manager out of the Display class. Change-Id: I2065bee8e5bf7f42c5a452dd1e8479e40ebb0d37
/frameworks/base/core/java/android/view/Display.java
|
d32460c5b7bea7b06e345397fdbaca58d9732dcf |
|
21-Jul-2012 |
Jeff Brown <jeffbrown@google.com> |
Refactor local window manager implementation. The objective of this refactoring is to remove the reliance on WindowManager wrapper objects for compatibility mode and for managing sub-windows. Removed the WindowManager.isHardwareAccelerated() method since it is never used. Change-Id: I4840a6353121859a5e0c07d5cc307a437c595d63
/frameworks/base/core/java/android/view/Display.java
|
93de746e5554bc9397ca8109f57875d92e64eabc |
|
03-May-2012 |
Jeff Brown <jeffbrown@google.com> |
Separate the internal and external display rotations. When attached to an HDMI touch screen, the input system needs to know the size and rotation of the external display independent of the internal display. The size was already being reported separately but not the rotation. The inconsistency can cause problems if the internal display's natural rotation is portrait but the external display's natural rotation is landscape. Change-Id: Id344f04c1ba032625f6265766be66f9ddaa2cc0b
/frameworks/base/core/java/android/view/Display.java
|
68c33ca7ce1f142eb5f1e1f90118aeba4c9db1e3 |
|
19-Apr-2012 |
Dianne Hackborn <hackbod@google.com> |
Add new API to find smallest/largest screen size. Change-Id: I790801fceaf84ee2e3b1c9d32828285ad3231d0e
/frameworks/base/core/java/android/view/Display.java
|
36991744a221c30a47085442e6416bdde40b85e8 |
|
12-Oct-2011 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #5445966: WindowManager reporting -long on prime when it shouldn't be. The window manager now uses the app screen dimensions to compute the various configuration properties, as it should. This means that prime is official a "not long" device. Poor prime. It probably feels inadequate now. Because it is. Oh and all that other stuff? Debugging logs. Turned off. And why the heck not, debugging logs are great. Change-Id: Iaaf8ef270d986d34fd046d699ef4c0ecea1981fc
/frameworks/base/core/java/android/view/Display.java
|
30c845f9ca9e504d4d76099a8be111c99ac669f4 |
|
05-Oct-2011 |
Dianne Hackborn <hackbod@google.com> |
Turn off logging. Change-Id: I5b050e33fe918c08b24091c6ccb9c5fe2b01d496
/frameworks/base/core/java/android/view/Display.java
|
836e262aa8e2f66548231ab11eb3b3e91d0e7901 |
|
05-Oct-2011 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #5348948: Third Party app "Byki Turkish" shows... ...a tiny dialog (works fine in GB and HC) I found two problems: - When first binding an application, we were not correctly computing the compat configuration. - When retrieving the display metrics to hand to Resources, we were using the one with compat applied. This is not right, because Resources will apply the compat itself, so in some cases the compat scaling was applied twice. Change-Id: I22c9cfed9e271290c1a7544fa3ffa54a2e65daf9
/frameworks/base/core/java/android/view/Display.java
|
ec537457cd2869e52b9b2c99e8c01dd96a9682e2 |
|
15-Sep-2011 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #5155678: Portrait > Landscape full-screen transition... ...mode cuts off screen rendering The code for limiting application window sizes to not include the navigation bar was dead. Now it is back. Change-Id: Ic0bde56e3300fd0d9d225e19d8de2766d07e8780
/frameworks/base/core/java/android/view/Display.java
|
7f9f99ea11051614a7727dfb9f9578b518e76e3c |
|
11-Aug-2011 |
Xavier Ducrohet <xav@android.com> |
Make some methods/fields package private so that layoutlib can access them. Change-Id: I4aeadfbaf8a4f6a459fa19937c21ac23d9e5fb64
/frameworks/base/core/java/android/view/Display.java
|
bc68a59c024bdb745dac8e2ec7408a9f30595f1a |
|
25-Jul-2011 |
Jeff Brown <jeffbrown@google.com> |
Report the external display size to the input reader. The input reader needs this information so that it knows how to interpolate touches on an external touch screen. Changed Display so that it asks the WindowManager what the real display size is (as opposed to the raw display size). This means it now takes into the forced display size set by adb shell am display-size. Replaced all calls to getRealWidth() / getRealHeight() / getRealMetrics() in the WindowManager and replaced them with direct usages of the mCurDisplayWidth / mCurDisplayHeight so that the WM doesn't end up making a reentrant Binder call into itself. Fixed the table status bar HeightReceiver so that it updates the height on all configuration changes since it is possible that the display size changed independently of an external HDMI display being plugged / unplugged. Improved the Display class documentation to make the distinctions betweeen the various sizes clearer. Change-Id: I3f75de559d3ebffed532ab46c4ae52c5e7f1da2b
/frameworks/base/core/java/android/view/Display.java
|
2c1c4aa69f4ee0b3868b9ad9f0107bf678ffbb2a |
|
19-Jul-2011 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #4869092: ResolverActivity occasionally fails to display Change-Id: Ic632d08fcfa9138caeacb45fa4a00cbd4a943988
/frameworks/base/core/java/android/view/Display.java
|
2b31d53161789358de57fd396716a6503855c5da |
|
23-Jun-2011 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #4770360: older app compatibility mode is really tiny on ICS phones We were applying the density compat mode scaling multiple times to display metrics, causing bad values. Change-Id: Iafafd9a5e94b9d774cd2715bf968e91602a1bd82
/frameworks/base/core/java/android/view/Display.java
|
5fd2169eabd77e6bfafaf456e58051a3bafb2bca |
|
07-Jun-2011 |
Dianne Hackborn <hackbod@google.com> |
Work on issue #4518815: Compatibility mode introduces compatibility regression... ...for Market App iRunner There were a lot of serious issues with how we updated (or often didn't update) the display and resource state when switching compatibility mode in conjunction with restarting and updating application components. This addresses everything I could find. Unfortunately it does *not* fix this particular app. I am starting to think this is just an issue in the app. This change does fix a number of other problems I could repro, such as switching the compatibility mode of an IME. Also a few changes here and there to get rid of $#*&^!! debug logs. Change-Id: Ib15572eac9ec93b4b9966ddcbbc830ce9dec1317
/frameworks/base/core/java/android/view/Display.java
|
81e56d535c853d73ff537357da5b935f51cb779d |
|
26-May-2011 |
Dianne Hackborn <hackbod@google.com> |
Rework how we decide whether to use system or status bar. The PhoneWindowManager is now responsible for determing this, since it needs to do this before we can generate the configuration since we need to take into account the system bar size we will use. Also the Display should now report the screen height without including the system bar. Change-Id: I82dfcc5e327e4d13d82c373c6c870f557a99b757
/frameworks/base/core/java/android/view/Display.java
|
5be8de3420ba4c9d816b98e29bdec11715f6b626 |
|
25-May-2011 |
Dianne Hackborn <hackbod@google.com> |
More compatibility mode improvements. We now correctly adjust display metrics, fixing for example issues seen in Barcode Scanner. In addition the decision about when to use compatibility mode has a bug fixed where certain apps would not go out of compatibility mode even though they should be able to. Change-Id: I5971206323df0f11ce653d1c790c700f457f0582
/frameworks/base/core/java/android/view/Display.java
|
68066c2f38e47b56f0510c56eafd827731a0dc08 |
|
22-Apr-2011 |
Dianne Hackborn <hackbod@google.com> |
DO NOT MERGE. From main -- Start work on simulating landscape/portrait when orientation is locked. Not yet working, so turned off. Also fix a bug where the display size configuration became inconsistent after a configuration change -- we now figure out everything about the display size when computing a new configuration. Change-Id: Id155f133c0bf108508a225ef64ed3ca398a90a58
/frameworks/base/core/java/android/view/Display.java
|
ac8dea12c17aa047e03a358110aeb60401d36aa2 |
|
21-Apr-2011 |
Dianne Hackborn <hackbod@google.com> |
DO NOT MERGE. Integrate from master: Rework display size access. Applications now get the display size from the window manager. No behavior should be changed yet, this is just prep for some real changes. Change-Id: I47bf8b55ecd4476c25ed6482494a7bcc5fae45d2
/frameworks/base/core/java/android/view/Display.java
|
e2515eebf42c763c0a2d9f873a153711778cfc17 |
|
28-Apr-2011 |
Dianne Hackborn <hackbod@google.com> |
Better compat mode part one: start scaling windows. First step of improving app screen size compatibility mode. When running in compat mode, an application's windows are scaled up on the screen rather than being small with 1:1 pixels. Currently we scale the application to fill the entire screen, so don't use an even pixel scaling. Though this may have some negative impact on the appearance (it looks okay to me), it has a big benefit of allowing us to now treat these apps as normal full-screens apps and do the normal transition animations as you move in and out and around in them. This introduces fun stuff in the input system to take care of modifying pointer coordinates to account for the app window surface scaling. The input dispatcher is told about the scale that is being applied to each window and, when there is one, adjusts pointer events appropriately as they are being sent to the transport. Also modified is CompatibilityInfo, which has been greatly simplified to not be so insane and incomprehendible. It is now simple -- when constructed it determines if the given app is compatible with the current screen size and density, and that is that. There are new APIs on ActivityManagerService to put applications that we would traditionally consider compatible with larger screens in compatibility mode. This is the start of a facility to have a UI affordance for a user to switch apps in and out of compatibility. To test switching of modes, there is a new variation of the "am" command to do this: am screen-compat [on|off] [package] This mode switching has the fundamentals of restarting activities when it is changed, though the state still needs to be persisted and the overall mode switch cleaned up. For the few small apps I have tested, things mostly seem to be working well. I know of one problem with the text selection handles being drawn at the wrong position because at some point the window offset is being scaled incorrectly. There are probably other similar issues around the interaction between two windows because the different window coordinate spaces are done in a hacky way instead of being formally integrated into the window manager layout process. Change-Id: Ie038e3746b448135117bd860859d74e360938557
/frameworks/base/core/java/android/view/Display.java
|
99aac7beca18b6d73e40db5e8e49f52f94be638e |
|
26-Feb-2011 |
Dianne Hackborn <hackbod@google.com> |
You can now specify a custom display size as NxM. Change-Id: Ieb6df51aab009689f0f19b8887025261c5ceb69f
/frameworks/base/core/java/android/view/Display.java
|
4c7cc34127efa3308e1a09b28728868911b79789 |
|
17-Dec-2010 |
Dianne Hackborn <hackbod@google.com> |
Demo hack! To make a 800 tall screen run like a 720: adb shell setprop persist.demo.screensizehack 800=720 Note this is a persistent property, so it will (intentionally) remain across boots. Change-Id: I8a8a9f937399327444e8fb154b91f0e642db116e
/frameworks/base/core/java/android/view/Display.java
|
833533c9292f860e4dfc060a4eba6429cd259ed4 |
|
16-Aug-2010 |
Mathias Agopian <mathias@google.com> |
Improve Display javadoc slightly Change-Id: Iaa7d599e11d42d4aaf50e87b141f9b8d04ba445e
/frameworks/base/core/java/android/view/Display.java
|
4c904a3bf3dbe98607b5e3f706ee8ef8887ee104 |
|
26-Feb-2010 |
Joe Onorato <joeo@android.com> |
fix the build.
/frameworks/base/core/java/android/view/Display.java
|
5cb70b54156fb305d579a1cc167424c8705bfdf7 |
|
26-Feb-2010 |
Dianne Hackborn <hackbod@google.com> |
Rename Display.getOrientation() to Display.getRotation(). Update various docs.
/frameworks/base/core/java/android/view/Display.java
|
11ea33471e1a14a8594f0b2cd012d86340dd3bd8 |
|
23-Jul-2009 |
Dianne Hackborn <hackbod@google.com> |
Allow for screen density drawables in compatibility mode. This change allows us to use drawables that match the current screen density even when being loaded in compatibility mode. In this case, the bitmap is loaded in the screen density, and the bitmap and nine-patch drawables take care of accounting for the density difference. This should be safe for existing applications, for the most part, since they shouldn't really be pulling the bitmap out of the drawable. For the small rare chance of them breaking, it worth getting the correct graphics. Also this will only happen when there is actually a resource of the matching density, and no existing apps should have resources for anything besides the default density (though of course all of the framework resources will be available in the native density). As part of this, the bitmap density API has been changed to a single integer provider the DPI unit density.
/frameworks/base/core/java/android/view/Display.java
|
ddd12535f095d8d056716c3290faf50ec52a538a |
|
14-Jul-2009 |
Mitsuru Oshima <oshima@google.com> |
Return adjusted display for WindowManager.getDefaultDisplay()
/frameworks/base/core/java/android/view/Display.java
|
9066cfe9886ac131c34d59ed0e2d287b0e3c0087 |
|
04-Mar-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //depot/cupcake/@135843
/frameworks/base/core/java/android/view/Display.java
|
d83a98f4ce9cfa908f5c54bbd70f03eec07e7553 |
|
04-Mar-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //depot/cupcake/@135843
/frameworks/base/core/java/android/view/Display.java
|
54b6cfa9a9e5b861a9930af873580d6dc20f773c |
|
21-Oct-2008 |
The Android Open Source Project <initial-contribution@android.com> |
Initial Contribution
/frameworks/base/core/java/android/view/Display.java
|