833bdcedceee60a873694a77587393abfc830eb5 |
|
16-May-2016 |
Yohei Yukawa <yukawa@google.com> |
Make IMS#clearInsetOfPreviousIme() reliable. This is a follow-up to my previous CL [1] for Bug 15922840 so that we can clear the following variables in a more reliable way. - PhoneWindowManager#mLastInputMethodWindow - PhoneWindowManager#mLastInputMethodTargetWindow The idea behind CL [2] is that when InputMethodManagerService (IMMS) is switching from an IME to another IME, IMMS can send a signal to WindowManagerService (WMS) to remember the current IME's inset so that the system can continue using it to reduce jank until the new inset is specified by the next IME. As summarized in Bug 28781358, however, if the next IME does not show the window after the IME switch, WMS (or PhoneWindowManager to be precise) keeps using the previous IME's inset unexpectedly until the new IME shows its window. All we have seen in Bug 15922840 and Bug 26663589 fall into this category. The idea of this CL is just adding a hidden API to InputMethodManager so that InputMethodService#clearInsetOfPreviousIme() can surely terminate the IME transition state managed in PhoneWindowManager, rather than relying on a hack of calling SoftInputWindow#show() and SoftInputWindow#hide(), which actually does not work for Bug 26663589. [1]: Ib04967f39b2529251e4835c42e9f99dba2cf43f2 2977eb7b6ce82309a1bb1ba4ab698f503cb0388a [2]: I5723f627ce323b0d12bd7b93f5b35fc4d342b50c 792faa2c16d319e874a1d633f964a78266d5f3f2 Note that addressing all the corner cases in [2] still requires lots of non-trivial change. Hence this CL focuses only on Bug 26663589 (and the case we handled in Bug 15922840). Bug: 26663589 Change-Id: Ib567daa009c1139858dccadcfc6a04465ebecf36
/frameworks/base/core/java/android/view/WindowManagerInternal.java
|
70439244ba1abc4f32357d2ee8ff38f73158fe37 |
|
11-Mar-2016 |
Phil Weaver <pweaver@google.com> |
Fix several accessibility magnification issues. Clarifying region used for magnification as "magnificationRegion", both in the public API and in the code. There's been significant confusion about what "magnfifiedRegion" means. Removing "availableRegion" from everywhere except where it's required, as that region was identical to magnified/magnification region. Trying to shut down magnification was a complex situation where animations in progress and new magnification requests were tricky to handle correctly. It was not possible to guarantee that the magnification callbacks were unregistered consistently. There were at least two situations that led to phone restarts: 1. If a triple tap was detected between unregistering the callbacks and shutting down the input filter. In this case the magnification request would go through. 2. If an animation had just started when magnification was turned off, so the current magnification was 1.0 but the animator was about to change it. In this case the callbacks would be unregistered, and then the animator would start changing the magnification. This change makes registering and unregistering magnification atomic. It also makes MagnificationController stick around indefinitely once it is created, registering and unregistering as needed to support magnification gestures and services that control magnification. Services that merely query the status of magnification no longer register for callbacks. One part of shutting down is turning off the animation and guaranteeing that it won't try to make further changes. Adding a flag to SpecAnimationBridge and a lock in that class so we can guarantee that nothing happens when we aren't registered for magnification callbacks. Also reconfiguring all accessibility options when a service stops to make sure that only the features required by the current configuration are enabled. Bug: 27497138 Bug: 27821103 Change-Id: If697cbd34b117d82c8eee1ba7d0254089ee4241d
/frameworks/base/core/java/android/view/WindowManagerInternal.java
|
59e53a164e1e8d19830f16b6e3a743c7ebe0c1aa |
|
28-Mar-2016 |
Alan Viverette <alanv@google.com> |
Various fixes for MagnificationController - Ensure initial magnified and available regions are set - Correctly offset magnified bounds by left coordinate - Cancel ongoing animations before unregistering callbacks Bug: 22718911 Bug: 27871383 Change-Id: Iaff63be856598d1f8edb2d94158bbd75045c86ec
/frameworks/base/core/java/android/view/WindowManagerInternal.java
|
9511b0f1e9ac629a4a747a0c9373d33ab33cfc32 |
|
30-Jan-2016 |
Jorim Jaggi <jjaggi@google.com> |
Fix bug where surface was not clipped off during resizing When dragging the divider in a way such the task size goes through the following transition - Half size - Full screen - Half size the surface wasn't clipped off anymore. This was because in full screen configuration, computeDragResizing() == false thus when going full screen -> half size, we reset the draw state to DRAW_PENDING to get notified when it has finished drawn. However, this also broke clipping. In order to fix this, we always put the window into a resizing mode no matter whether the bounds are fullscreen or not. However, this introduces an ugly flickering on the navigation bar, when going into docked mode, because the app doesn't draw navigation bar background in resize mode. To fix that, we calculate the presence of navigation bar whether the window is fullscreen, and not just whether it's resizing. For that, we need to calculate the presence in BackdropFrameRenderer, by using the insets just sent by window manager. Change-Id: Idf56df4ae7fefe67d068bc2eeda8dc4d83bbefb7
/frameworks/base/core/java/android/view/WindowManagerInternal.java
|
214fb68767502f5fede643a062c1dc5975d75b27 |
|
17-Nov-2015 |
Alan Viverette <alanv@google.com> |
APIs for querying and controlling display magnification Also separates magnification state and touch event handling. Moves callbacks for window manager changes and display state changes into the magnification controller. Bug: 22718911 Change-Id: I3a8ba060a07d8f1f51856855a5f85601766fd45d
/frameworks/base/core/java/android/view/WindowManagerInternal.java
|
6e94a9eb8709ddd3127e3c0103cd6a0f550f6e74 |
|
08-Oct-2015 |
Wale Ogunwale <ogunwale@google.com> |
Added rules for status/nav bar customization when in multi-window mode Status & nav bars are always visible and opaque when freeform or docked stack is visible We still need to refactor the code to allow force opaque to be updated independently for the status bar and nav. bar. Once that is done, the status bar should be transcluent if freeform stack is visible and docked stack isn't and the status bar should be opaque if freeform & docked stack are both visible. Bug: 24365214 Change-Id: I48ecc6067c9b0f7239c12c98eb46f3fcefacd4f9
/frameworks/base/core/java/android/view/WindowManagerInternal.java
|
7309b123c423504bb18e3d78dd22a36f7271676a |
|
18-Aug-2015 |
Seigo Nonaka <nona@google.com> |
Leverage WindowManagerInternal for private communication. This CL changes following four methods from direct calling of WindowManagerService to calling via WindowManagerInternal. - getInputMethodWindowVisibleHeight (introduced by I0e920ee79c526c3aea6872b063cf294e2ab081c8) - saveLastInputMethodWindowForTransition (introduced by Idf7700271cf882dfbf35c9d16f0f173a791221bc) - isHardKeyboardAvailable (introduced by I8a6a4a7efce50bfaec114117e33f97f27b1ef950) - setOnHardKeyboardStatusChangeListener (introduced by Ica768083f95c33dc1e494a28ba7d8b6eb989b0ef) This CL does mechanical code moving and does not change any behaviors. Bug: 22285167 Change-Id: I08e506050a0e495d62236b46e487848c967d185d
/frameworks/base/core/java/android/view/WindowManagerInternal.java
|
24bec7ce7adc3c0d693cfadcb4b28f5fc41555ae |
|
04-Feb-2015 |
Jorim Jaggi <jjaggi@google.com> |
Implement nice transitions for light status bar - When the flag changes, apply an animation from the current value - When the flag change is caused by an app transition, synchronize the status bar animation with the app transition animation. PhoneWindowManager calculates the timings based on some heuristics of the app transition animations and supplies these timings to StatusBarService. Bug: 19233606 Change-Id: I4f99afba8f1eebb3524699ed4d7fbafee5463a37
/frameworks/base/core/java/android/view/WindowManagerInternal.java
|
77ba4803a510717032181e7cf0beca9d07f09733 |
|
18-Feb-2015 |
Jorim Jaggi <jjaggi@google.com> |
Add AppTransitionListener Introduces the concept of a listener to be notified about app transition events. The only client at the moment is window manager which notifies activity manager about completed transitions, but this can be used for various clients, including the status bar. Bug: 19233606 Change-Id: Ia6fec5837b6eb4db90f3cb1c999d3f157ba6dd4a
/frameworks/base/core/java/android/view/WindowManagerInternal.java
|
3a5c721072c60c7ed9c8a95d0a65d0e3cb4eb9bb |
|
14-Oct-2014 |
Svetoslav <svetoslavganov@google.com> |
APIs for an accessibility service to put interaction tracking overlays. An accessibility service may register to observe the interactive windows on the primary display. These windows are the one that has input focus and ones a sighted user can touch. It is sometimes beneficial for an accessibility service to overlay a window to intercept user interaction and based on that introspect and perform an action on the windows that are on the screen. This is problematic as overlaying a full screen window that is touchable prevents the accessibility service to introspect the content under this window. This change adds a special type of window that only an accessibility service can place which does not affect what an accessibility service can "see" on the screen. Hence, even putting such a window full screen the service will be able to interact with the other interactive windows it covers. Change-Id: I053ccc3a5c6360a98dc40bdb172b54dab35d8b31
/frameworks/base/core/java/android/view/WindowManagerInternal.java
|
e34560b21989eea54a139a0586d156ba573cc2ea |
|
10-Jul-2014 |
Alan Viverette <alanv@google.com> |
Add accessibility action to open power long-press dialog Also fixes an infinite recursion bug in the WindowManagerService implementation of WindowManagerInternal. BUG: 16129909 Change-Id: I4f9d32f4e6c3ad460652c5e5271540fa5032a1f5
/frameworks/base/core/java/android/view/WindowManagerInternal.java
|
13f6ea78b0aa98ffea6ea644770e4320ec9a2242 |
|
23-Jun-2014 |
Craig Mautner <cmautner@google.com> |
Avoid unnecessary timeouts. And fix a couple of other inefficiencies. Fixes bug 15444410. Change-Id: Idad95d4e4d70bc7d2965e1bd6ff3d3135b73dd9c
/frameworks/base/core/java/android/view/WindowManagerInternal.java
|
8a0da0184f6c5c95d94ab6adfee79bace4040abd |
|
01-Jun-2014 |
Craig Mautner <cmautner@google.com> |
Force all windows to redraw before unblanking screen The screen turning on would show windows as they were when the screen turned off. This fix forces all showing windows to redraw first and only then allow the screen to turn on. Fixes bug 15092354. Change-Id: I52c3f47438176a5ac00ba9a4d5205b56a5aa48f9
/frameworks/base/core/java/android/view/WindowManagerInternal.java
|
8e3feb15c5aec2c72b0ef120a1da325e1e8f0dda |
|
24-Feb-2014 |
Svetoslav <svetoslavganov@google.com> |
Added accessibility APIs for introspecting interactive windows. 1. The old introspection model was allowing querying only the active window which is the one the user is touching or the focused one if no window is touched. This was limiting as auto completion drop downs were not inspectable, there was not way to know when the IME toggles, non-focusable windows were not inspectable if the user taps them as until a screen-reader starts introspecting the users finger is up, accessibility focus was limited to only one window and the user couldn't use gestures to visit the whole UI, and other things I can't remember right now. The new APIs allow getting all interactive windows, i.e. ones that a sighted user can interact with. This prevents an accessibility service from interacting with content a sighter user cannot. The list of windows can be obtained from an accessibility service or the host window from an accessibility node info. Introspecting windows obey the same rules for introspecting node, i.e. the service has to declare this capability in its manifest. When some windows change accessibility services receive a new type of event. Initially the types of windows is very limited. We provide the bounds in screen, layer, and some other properties which are enough for a client to determined the spacial and hierarchical relationship of the windows. 2. Update the documentation in AccessibilityService for newer event types. 3. LongArray was not removing elements properly. 4. Composite accessibility node ids were not properly constructed as they are composed of two ints, each taking 32 bits. However, the values for undefined were -1 so composing a 64 long from -1, -1 prevents from getting back these values when unpacking. 5. Some apps were generating inconsistent AccessibilityNodeInfo tree. Added a check that enforces such trees to be well formed on dev builds. 6. Removed an necessary code for piping the touch exploration state to the policy as it should just use the AccessibilityManager from context. 7. When view's visibility changed it was not firing an event to notify clients it disappeared/appeared. Also ViewGroup was sending accessibility events for changes if the view is included for accessibility but this is wrong as there may be a service that want all nodes, hence events from them. The accessibility manager service takes care of delivering events from not important for accessibility nodes only to services that want such. 8. Several places were asking for prefetching of sibling but not predecessor nodes which resulted in prefetching of unconnected subtrees. 9. The local AccessibilityManager implementation was relying on the backing service being ready when it is created but it can be fetched from a context before that. If that happens the local manager was in a broken state forever. Now it is more robust and starts working properly once the backing service is up. Several places were lacking locking. bug:13331285 Change-Id: Ie51166d4875d5f3def8d29d77973da4b9251f5c8
/frameworks/base/core/java/android/view/WindowManagerInternal.java
|
4ccb823a9f62e57f9d221f83a97e82967e79a9e5 |
|
17-Jan-2014 |
Jeff Brown <jeffbrown@google.com> |
Refactor display manager service to new pattern. Transform DisplayManagerService into a SystemService and start cleaning up other local services that it uses from window manager and input manager. Clean up service thread initialization. Remove unnecessary static variables from ActivityManagerService. It's starting to become clear that we really need a better way to manage service dependencies. Boot phases don't quite cut it. Change-Id: If319dbd7cbfbd4812fe55ece969e818d4b20755b
/frameworks/base/core/java/android/view/WindowManagerInternal.java
|