| 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
|