7bedf2449041a425899448cb672e91b0a5c97c62 |
|
08-Dec-2011 |
Jeff Brown <jeffbrown@google.com> |
Shortcut keys should be handled on down, not up. Bug: 5720360 Change-Id: I3afc278e576ea992c76f024c8b6bad14b214239c
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
b54980d1d4d903f68cdfa952256afff01902cd94 |
|
29-Nov-2011 |
Dianne Hackborn <hackbod@google.com> |
Merge "Fix issue #5588689: Black camera preview after coming back from gmail" into ics-mr1
|
08837c246c9c27902c59b41c8661c2f27a4aa2bc |
|
28-Nov-2011 |
Chet Haase <chet@google.com> |
Fix flashing wifi dialog after rotating back from landscape. There was an error in some of the OpenGL layer logic such that we would occasionally set up a layer for rendering and then not clean up when it was done. This caused future OpenGL rendering to go into that layer instead of to the buffers being displayed on the screen, resulting in artifacts including flashes and displaying of stale content. This happened specifically when using the wifi settings dialog with the InputMethod keyboard displayed, but it was probably visible in other situations as well. Issue #5628248: Flickering/flashing after entering password for WiFi Change-Id: I38139f620b310f4309570fa7224552d2ee633999
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
6d05fd3c795088ac60f86382df5a66d631e8a0cb |
|
19-Nov-2011 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #5588689: Black camera preview after coming back from gmail Make surface management between SurfaceView and the window manager much more controlled, to ensure that SurfaceView always gets to report the current surface is destroyed before the window manager actually destroys it. Also a small tweak to allow windows that have a wallpaper background to still have a preview window. This makes launching home after it has been killed feel much more responsive. Change-Id: I0d22cf178a499601a770cb1dbadef7487e392d85
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
31f2c2e94656530fbf6282803e62edb47e9a894d |
|
21-Nov-2011 |
Romain Guy <romainguy@google.com> |
Notify views when EGL resources are about to be destroyed Bug #5639899 Change-Id: I7c5d8bebf02294426f5b3ab1358a31c38a4fd064
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
8ff6b9ebeeb24a6161ec6098e6bfdf8790ee5695 |
|
10-Nov-2011 |
Romain Guy <romainguy@google.com> |
Terminate EGL when an app goes in the background This does not happen on high end gfx devices. This happens only if only one EGL context is initialized in the current process. Change-Id: Ibd1737efdf84eef8a84108b05795440d1ae9964e
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
1f4786bbe1ed7ae54b94cd52c0e1a4a826fecd68 |
|
02-Nov-2011 |
Chet Haase <chet@google.com> |
Improve Launcher drag performance. Launcher swiping looks choppy. It's because we deliver the motion events of the drags asynchronously, and sometimes we may get an event to redraw before the motion event is posted, so we end up drawing again without updating to the latest motion information. This fix makes input event processing more proactive. Every time we run ViewRootImpl.performTraversals() (which is what happens whenever we need to layout, measure, and/or draw), we first process all pending input events, ensuring that we are completely up-to-date with posted events prior to drawing, so that the drawing we do is synchronous with the events we've received. This eliminates the choppiness and means that we can now get the full refresh rate on the screen with drag events. The fix was done for Launcher, but it is pervasive in the system, so this may fix other laggy drag behavior as well. Change-Id: I8dbed6acadc2662f317f736e769f536f555701aa
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
af5b4f471df108ffbe1c3861d18b2141710d7bf8 |
|
28-Oct-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
Fixing a memory leak in accessibility enteraction APIs. 1. AccessibilityInteractionConnection was non-static inner class, hence keeping a handle to the enclosing ViewRootImpl resulting in leaking activities. bug:5525412 Change-Id: Ie438861663d623d503995844125d9e15d677fc32
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
972b7d2c3bbb54a61a505d9d78927a158356ffb6 |
|
21-Oct-2011 |
Gilles Debunne <debunne@google.com> |
Merge "Typo in ViewRootImpl"
|
5ac84423a28fea4924eb1c389d647defe1c1b93c |
|
19-Oct-2011 |
Gilles Debunne <debunne@google.com> |
Typo in ViewRootImpl Change-Id: I4a5acfb091ce05f56cdbaa0a56809f377cbf9b39
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
841d79497d9eff2d4df6948380b79db316d24dc3 |
|
18-Oct-2011 |
Chet Haase <chet@google.com> |
am 87bc53de: Merge "Make notification panel delete-all animation smoother" into ics-mr0 * commit '87bc53de2adf479ad5a5e226bf3d8fd31af6dc21': Make notification panel delete-all animation smoother
|
2f2022afa1eb85018368398bd150e9575fc099c9 |
|
11-Oct-2011 |
Chet Haase <chet@google.com> |
Make notification panel delete-all animation smoother Making the notfication delete-all animation smoother by carefully choreographing the various parts of it. The problem with the previous animation was that there was simply too much going on at the same time, causing things like layout and recreating display-lists in the middle of animations that became choppy as a result. This approach swipes all items off quickly, then scrolls the shade up to the top, making both sets of animations smoother as a result. Fixes #5431207: Notification delete-all should be smoother Change-Id: Iefe8ab5d661e05adcd10379dab85227d17904450
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
856d4e1a872b5aed6792b33e0360554cb3d19eed |
|
15-Oct-2011 |
Romain Guy <romainguy@google.com> |
Disable hardware acceleration for apps in compatibility mode Change-Id: I2d1c01a30c6fe6fff85c2a9bd6ee6de98e1ed422
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
85b9edf2da0534bc53d139bb88cda8866d265afe |
|
07-Oct-2011 |
Dianne Hackborn <hackbod@google.com> |
Merge "Fix issue #5371530: SYSTEMUI_FLAG_HIDE_NAVIGATION reasserts itself immediately"
|
9a230e01a1237749a8a19a5de8d46531b0c8ca6a |
|
06-Oct-2011 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #5371530: SYSTEMUI_FLAG_HIDE_NAVIGATION reasserts itself immediately This cleans up how ui flags are managed between the client and window manager. It still reports the global UI mode state to the callback, but we now only clear certain flags when the system goes out of a state (currently this just means the hide nav bar mode), and don't corrupt other flags in the application when the global state changes. Also introduces a sequence number between the app and window manager, to avoid using bad old data coming from the app during these transitions. Change-Id: I40bbd12d9b7b69fc0ff1c7dc0cb58a933d4dfb23
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
40e0383dce630ed9b2b1aa0e497709b89dfab6ef |
|
06-Oct-2011 |
Chet Haase <chet@google.com> |
Fix issue #5384631: hw windows not resizing correctly When the SystemUi becomes visible, the activity window resizes. The hardware renderer was not begin resized to suit, so it was drawing to a surface larger than that of the activity window, and some of the rendering (like the action bar) appeared off the screen. The fix is to keep track of the surface size in HardwareRenderer and to recreate the surface when the size changes. This change also removes the BUFFER_CHANGE flag from WindowManager.LayoutParams. The only reason the flag existed was to trigger a hardware surface recreation, but checking the old/new size is a more direct way of handling this. Change-Id: I9d6bf6385794886d1d93c60609c170864cdcdfab
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
2588a07730ff511329c87b5f61b20419b2443d48 |
|
04-Oct-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
Merge "The logic for not populating text to some accessibility events is scattered."
|
2cdedffcfa5594f9d516fa235d5edf4d4f92c21d |
|
03-Oct-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
Accessibility services cannot obtain the source of an event coming from a root namespace descendant. 1. The user can touch the screen at an arbitrary location potentially crossing the root namespace bounday which will send an accessibility event to accessibility services and they should be able to obtain the event source. Also accessibility ids are guaranteed to be unique in the window. Added a package scoped findViewByAccessibilityId method that dives into nested root namespaces. 2. Added accessibility support to the AnalogClock. bug:5405934 Change-Id: I84edcb554bae41aafcbbc2723c5e62c1ef8a6ddf
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
82e236d72ac197d6673d0b4d484fe5f0b9436731 |
|
30-Sep-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
The logic for not populating text to some accessibility events is scattered. 1. Some accessibility evenents should not and were not dispatched for text population but there was no centralized location for enforcing this - rather the system was firing them in a specific way or there were conditions in a few places enforcing that. Now this is centralized and clean. 2. Updated the documentation with some new event types the were lacking. 3. Explicitly stated in the documentaition which events are dispatched to the sub-tree of the source for text populatation. bug:5394527 Change-Id: I86e383807d777019ac98b970c7d9d02a2f7afac6
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
4f59f8be0e177435a9a493668a74c793971b3bb5 |
|
16-Sep-2011 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #5300880: setSystemUiVisibility() always triggers a surface reallocation Change-Id: Ia0a9d8acba6b62ef095e4c615099466c52eec8e4
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
ea515aeafa01de6f50c854ee381b972ef2478284 |
|
15-Sep-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
Update the public APIs for finding views by text to optionally use content description. 1. Added flags to the search method to specify whether to match text or content description or both. 2. Added test case for the seach by content description. 3. Updated the code in AccessibilityManager service to reflect the latest changes there so test automation service works - this is the fake service used for UI automation. Change-Id: I14a6779a920ff0430e78947ea5aaf876c2e66076
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
180c48489f07ebd748700a5a312070583fefdb45 |
|
13-Sep-2011 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #5309443: Ninjump crashes on boot with... ...java.lang.IllegalArgumentException: Window type can not be changed after the window is added Change-Id: I4e34622c99d721fa214fd534a9bbfc8006184770
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
aacbf9111b58f10f7474fbd3a8debb02713f8b18 |
|
08-Sep-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
Merge "Not visible view should not be announced or interacted with."
|
0b0a41d8e26eaf0f1d9d922621494daf40964a9a |
|
08-Sep-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
Not visible view should not be announced or interacted with. 1. Some invisible views' text was reported by accessibility events. 2. Accessibility actions could have been perfromed on invisible views. bug:5264355 Change-Id: I68184fb436a3e10e947ec6f1eae02aa3d0d1cb7f
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
d56c6951755a902a354e13e5fa05fb0984132cc6 |
|
07-Sep-2011 |
Chet Haase <chet@google.com> |
Add end functionality to LayoutTransition This new hidden API is called by ViewRootImpl when there is a pending transition but the parent window is not visible. Change-Id: Idd6a0959b391fae542e675e8740b6a16f8963678
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
3791dc9b1c849bfacbff6de7fb53b77f414d1e4b |
|
07-Sep-2011 |
Chet Haase <chet@google.com> |
Merge "Fix issue with LayoutTransition on non-visible windows."
|
61158c621d0834d6d4e1e0310596d9b7a1071178 |
|
07-Sep-2011 |
Chet Haase <chet@google.com> |
Fix issue with LayoutTransition on non-visible windows. There's a problem with how LayoutTransition cleans up after itself when the target view is in a Window that is not on the screen. The quick fix is to always start (and therefore properly end and clear) transitions, regardless of whether the window is in the tree. Change-Id: I23f4f4f04176f3943e5c6e1d78acba0190a96930
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
f21c9b0f52d5a1de5050f90f0818467fad014eaa |
|
07-Sep-2011 |
Romain Guy <romainguy@google.com> |
Don't destroy a window's buffers when moving it Change-Id: Ib08608373ae4299639c1b157421ba633e4293446
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
6b0c11da5a7a7ea236fd9dc409d1ce7a33bff9c2 |
|
03-Sep-2011 |
Dianne Hackborn <hackbod@google.com> |
Merge "Fix issue #5150899: Call activity takes 15MB we never get back."
|
3c4ce72c4d66d9ee041924259f20381b658c1529 |
|
03-Sep-2011 |
Chet Haase <chet@google.com> |
Fix artifact with LayoutTransitions on disappearing window. Logic in performTraversals() starts a transition running at the proper time. But when a view's parent window goes away, this transition may not start at that time because drawing gets canceled. But the transition still hung off of the ViewRoot, waiting until some later drawing operation to kick it off. This resulted in some weird animations like the Recents panel appearing and having a single item animate off of it. The fix is to delete pending transitions when drawing is skipped. Change-Id: I3ab7702c16e069644a163424f977350743e2cecc
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
5d927c2d8e832fcfcb0154c8741f896001141ef4 |
|
02-Sep-2011 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #5150899: Call activity takes 15MB we never get back. Persistent process can no longer use hardware acclerated drawing when running on a low-memory device. Change-Id: I3110335617af1c98fcede9bf41f4a1d0c20d0e87
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
08a1c04b9668e51ca3043a4e531b7649b018b245 |
|
01-Sep-2011 |
Romain Guy <romainguy@google.com> |
Merge "Dispatch onDetachedFromWindow before destroying everything Bug #5245686"
|
16260e73f6c1c9dc94acf0d328a3c564426b8711 |
|
01-Sep-2011 |
Romain Guy <romainguy@google.com> |
Dispatch onDetachedFromWindow before destroying everything Bug #5245686 Change-Id: I637178ee0bb47fbec9b59198b388bb8de22c1786
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
cc4f7db698f88b633a286d8ab1105b28a474cd09 |
|
31-Aug-2011 |
Jeff Brown <jeffbrown@google.com> |
Fix input channel leak. Bug: 5156144 Input channels could leak or simply live longer than they should in some cases. 1. Monitor channels (used by the pointer location overlay) are never unregistered, so they would leak. Added code to handle failures in the receive callback by closing the input channel. 2. The DragState held onto its input window and application handles even after the input channel was disposed. Added code to null these handles out when they are no longer needed. 3. Input channels previously used as input event targets would stick around until the targets were cleared (usually on the next event). Added code to detect when the input dispatcher is in an idle state and to proactively clear the targets then to ensure that resources are released promptly. 4. Native input window handles held onto the input channel even after the input window was removed from the input dispatcher. Consequently, the input channel would not be disposed until the input window handle itself was freed. Since the input window handle is held from managed code, this meant that the window's input channel could stick around until the next GC. Refactored the input window handle to separate the properties (info) and identify (handle) state into different objects. Then modified the dispatcher to release the properties (info) when no longer needed, including the input channel. 7. The pointer location overlay does not actually use its standard input channel, only the monitor input channel. Added INPUT_FEATURE_NO_INPUT_CHANNEL to allow windows to request that they not be provided with an input channel at all. Improved some of the error handling logic to emit the status code as part of the exception message. Change-Id: I01988d4391a70c6678c8b0e936ca051af680b1a5
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
eca9b1f53c2c291cbfb89b5f3cc45db7bdca6c7d |
|
26-Aug-2011 |
Romain Guy <romainguy@google.com> |
Prevent crash in VPN settings Bug #5217245 Change-Id: Ibacf4cbd40537cd417f1518b5ac4367a3f3d7d03
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
12bde60b39affbfdcb7ef6317e0a5f99c3f41b10 |
|
25-Aug-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
Merge "Intra-process view hierarchy interrogation does not work."
|
6ff0037792619c4441d9d3caa4f9ab4f45c11236 |
|
25-Aug-2011 |
Dianne Hackborn <hackbod@google.com> |
Merge "Fix to show the correct HW accel background in the preview window."
|
07213e6d8895af10951851435adf96a779863f6c |
|
25-Aug-2011 |
Dianne Hackborn <hackbod@google.com> |
Fix to show the correct HW accel background in the preview window. Also tweak wallpaper service to do a cleaner transition to a static wallpaper. Change-Id: I876a32091f92dd5a529d7fd809d3b8e730bb7d2a
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
fa6b35be126ffcc3b5818393c26aff724ac65daf |
|
25-Aug-2011 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #5050039: Launcher is sometimes rendering underneath the system/status bar It looks like this is caused by the change in HC to stop activities when the screen is off. ViewRootImpl (a.k.a. ViewRoot) has special code to avoid doing work when it is stopped, and it is now stopped when the screen is off. The problem here is if the window's activity is stopped when the window is first displayed, then it would never do the initial fitSystemWindows() with the status bar offsets given by the window manager, and never do this again until the status bar changes. Also included here is some re-arranging of the code dealing with the offsets changing, because it was dealt with in two places and only one had a bunch of code dealing with HW accelerated drawing and performing the fade transition between states. Now all of that is unified into one place. Change-Id: I9828f02664cc622dbf186effb1f685a8aa4456a1
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
8bd69610aafc6995126965d1d23b771fe02a9084 |
|
23-Aug-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
Intra-process view hierarchy interrogation does not work. The content retrieval APIs are synchronous from a client's perspective but internally they are asynchronous. The client thread calls into the system requesting an action and providing a callback to receive the result after which it waits up to a timeout for that result. The system enforces security and then delegates the request to a given view hierarchy where a message is posted (from a binder thread) describing what to be performed by the main UI thread the result of which it delivered via the mentioned callback. However, the blocked client thread and the main UI thread of the target view hierarchy can be the same one, for example an accessibility service and an activity run in the same process, thus they are executed on the same main thread. In such a case the retrieval will fail since the UI thread that has to process the message describing the work to be done is blocked waiting for a result is has to compute! To avoid this scenario when making a call the client also passes its process and thread ids so the accessed view hierarchy can detect if the client making the request is running in its main UI thread. In such a case the view hierarchy, specifically the binder thread performing the IPC to it, does not post a message to be run on the UI thread but passes it to the singleton interaction client through which all interactions occur and the latter is responsible to execute the message before starting to wait for the asynchronous result delivered via the callback. In this case the expected result is already received so no waiting is performed. bug:5138933 Change-Id: I382e2d8689f5189110226613c2387f553df98bd3
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
50d133e290468fd149b5c03e46549afca2ee05f8 |
|
13-Aug-2011 |
Romain Guy <romainguy@google.com> |
<blink/> is not an acceptable default behavior. Bug #5156334 Change-Id: I9f803b090e81f4e490d0cccd6347a0f9f64bd20f
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
70a3f677bf015d8641f41d149b76d362bb2b801c |
|
08-Aug-2011 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #5016544: IME keyboard hides folder rename text field. Tweak some issues in TextView with the focus rect used to determing where the scroll position needs to be. The ultimate problem was that in various situations it would use the right-most selection position cursor as the scroll location and when it adds 1 to make this a valid rect we end up with a rectangle that is outside of the view. Change-Id: Ia200c58e4e014d2a0a1be4761f9a1e5eb702a8e5
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
c3166e15f8898a2ba66fb177efbddb1d0edf6140 |
|
09-Aug-2011 |
Romain Guy <romainguy@google.com> |
Don't draw more than what we need. Change-Id: Ifeac66d379a48e8a1124188125e029421eb24226
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
1d0c708961f824ac5171238c205a7bf328d5d8a5 |
|
04-Aug-2011 |
Romain Guy <romainguy@google.com> |
Destroy the EGL surface when the ViewRootImpl surface is invalid Bug #5109839 Change-Id: Icebde9abf43b852397a73ffef519004993b46901
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
cf15efba0792b052dca5baa350d9fb00e6a60667 |
|
02-Aug-2011 |
Romain Guy <romainguy@google.com> |
Properly cancel pending buffers on window size change Change-Id: Id6108ce61a971673f3ebc8270e9dd00849c91ae5
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
c68c913d357e2955d4bd7ca52829071e531c7825 |
|
29-Jul-2011 |
Dianne Hackborn <hackbod@google.com> |
Various work on out of memory managment. - Improve how we handle processes that have shown UI, to take care of more cases where we want to push them into the background LRU list. - New trim memory level for when an application that has done UI is no longer visible to the user. - Add APIs to get new trim memory callback. - Add a host of new bind flags to tweak how the system will adjust the OOM level of the target process. Change-Id: I23ba354112f411a9f8773a67426b4dff85fa2439
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
ea83503e8683531fac2534047e50bc1e5979b6dd |
|
29-Jul-2011 |
Romain Guy <romainguy@google.com> |
Don't create hw layers when there's no hw context. Bug #5093805 Change-Id: Ia58b3381c83b9a200e80020e5c1b9c337ad6c35c
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
b6f7a27c59fd170b5d7617e43e21bfd8587f234e |
|
28-Jul-2011 |
Romain Guy <romainguy@google.com> |
Merge "Reclaim more memory, more often."
|
65b345fa22b878e141b8fd8ece9c208df00fa40f |
|
28-Jul-2011 |
Romain Guy <romainguy@google.com> |
Reclaim more memory, more often. Yay. Change-Id: I04557ad575c307a55088549f48f0e9ad994b7275
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
c8ec222cd8e7d7056b0f01018ac0c38d2c7204c0 |
|
28-Jul-2011 |
Romain Guy <romainguy@google.com> |
Merge "Destroy layers and flush layers cache when a window is destroyed."
|
6d7475d666baefaa3ba9f0dcee25238739454241 |
|
28-Jul-2011 |
Romain Guy <romainguy@google.com> |
Destroy layers and flush layers cache when a window is destroyed. Change-Id: I3fa1bc3ff50fb99e3d2e490925bd6b0a0f809fff
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
3d5a703db83265f7914eed8580de986106abfad2 |
|
28-Jul-2011 |
Jeff Brown <jeffbrown@google.com> |
Merge "Report the external display size to the input reader."
|
912a7b32d0c59ba38265c5dd6ff84ce93f909a7f |
|
27-Jul-2011 |
Romain Guy <romainguy@google.com> |
Make sure we have a current EGL context when invoking EGL Bug #5081795 Change-Id: Iee3382d362a71c1e6c5c498b319bf7f7bcf5a2f0
/frameworks/base/core/java/android/view/ViewRootImpl.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/ViewRootImpl.java
|
6dd005b48138708762bfade0081d031a2a4a3822 |
|
18-Jul-2011 |
Dianne Hackborn <hackbod@google.com> |
I. Can. Not. Stand. ViewAncestor. It was done so we would have the name "ViewRoot" available for a public API. However, the name "ViewAncestor" just makes no sense. So instead, change it to ViewRootImpl. Change-Id: If9599ca67896f339f6fefa7d1dde121201171d97
/frameworks/base/core/java/android/view/ViewRootImpl.java
|