bfa81adfbe1819d55737dbbb2fb9157e50dbe022 |
|
25-May-2017 |
Wale Ogunwale <ogunwale@google.com> |
Fix unnecessary relaunches when unlocking with fingerprint sensor. When the device is unlocked using the fingerprint sensor in an orientation opposite to the lockscreen orientation, the app that will be visible is first relaunched in the current lockscreen orientation and then later relaunched in the correct orientation. If the keygaurd is going away then: - Don't let keyguard affect device orientation. We want to use the orientation of the app that will be visible. - Allow the rotation sensor to be enabled even though draw isn't complete so window manager can get the updated or last rotation reading. - Don't clear the previous proposed sensor reading to allow window manager to use the information to update the orientation as needed vs. falling back to the previous orientation. Change-Id: I8369723d6a77f2c602f1ef080371fa7cd9ee094e Fixes: 38494778 Test: Launch an app that doesn't fix orientation like clock, hold the device in landscape, press the power button, unlock the device using the fingerprint sensor, and verify the the app isn't relaunched.
/frameworks/base/core/java/android/view/WindowManagerInternal.java
|
d6475a682d9651a651f60856baef9b17b4633b13 |
|
17-Apr-2017 |
Yohei Yukawa <yukawa@google.com> |
A new power button mode to hide the IME when shown As discussed in Bug 33038203 on certain platforms there is a demand that the power button can change the behavior depending on whether an IME window is shown on the screen or not. The behavior requested here can be summarized into two parts: * Hide the IME window if it is shown [1] * Go to the home screen if no IME window is shown This CL implements the above request by introducing a new config mode for config_shortPressOnPowerBehavior. Note the definition of when an IME is shown is often tricky than people would expect. The way this CL is implemented is to propagate IME window state from InputMethodManagerService (IMMS) to PhoneWindowManager via WindowManagerService regarding when the back button on the NavBar for phones/tablets should be shown as an IME dismiss key [2]. [1]: Even with this CL the IME still is allowed to ignore the request to hide the software keyboard. Currently there is no official protocol to forcefully hide the software keyboard. How to deal with such a situation is a long standing TODO task. [2]: Internally this is controlled by the following IMMS fields: - InputMethodManagerService#mImeWindowVis - InputMethodManagerService#mBackDisposition Note that those fields rely on self-report from the IME. To be precise, the base implementation of InputMethodService is responsible for report back its internal state to IMMS when necessary. The important point is that, although this could allow a malicious IME to confuse the system UI to some extent, supporting malicious IMEs is not clearly a goal of Android. Anyway, the definition of when an IME is shown is a kind of hot topic in several system services recently. Hopefully we can come up with better definition and reliable mechanism in a future release. Fixes: 33824860 Test: Manually verified as follows 1. Change config_shortPressOnPowerBehavior to "5" 2. Rebuilt the OS image and flash it to the device 3. Make sure that the power button works like a home button if software keyboard is not shown. 4. Open dialer and focus in to the text field shown on top 5. Make sure that the AOSP keyboard is shown. 6. Run 'adb shell dumpsys input_method' to observe the following line: mImeWindowVis=Active|Visible 7. Tap the power button to make sure that the AOSP keyboard gets dismissed. 8. Tap the power button again to make sure that it works as if a home button. Test: Manually tested as follows 1. Open dialer and focus in to the text field to show an IME 2. Run 'adb shell dumpsys window policy' to make sure mDismissImeOnBackKeyPressed=true 3. Tap the back button to dismiss the IME 4. Run 'adb shell dumpsys window policy' to make sure mDismissImeOnBackKeyPressed=false Change-Id: I20721547c73360a70b5fc5cbe06824d577d1768a
/frameworks/base/core/java/android/view/WindowManagerInternal.java
|
74922c63e1dfba074aa9219034e48a161bdfba5b |
|
13-Feb-2017 |
Casey Burkhardt <caseyburkhardt@google.com> |
Display magnification via the nav bar Accessibility Button Adds support for invoking display magnification by first selecting the Accessibility Button, then touching an area of the screen to magnify. Bug: 30960346 Test: Manual Change-Id: Ifd8a355562f204182e34bd37f71a3637d85cf0e1
/frameworks/base/core/java/android/view/WindowManagerInternal.java
|
ee2a7ed3d971f83134a2b28258dd2e56f9634f94 |
|
16-Feb-2017 |
Yohei Yukawa <yukawa@google.com> |
Allow setImeWindowStatus with null startInputToken This is a follow up CL to my previous CL [1], which caused an unexpected side effect that leads the current IME to crash due to a too strict requiremnt. It turns out that it was too early for us to start requiring non-null StartInputToken in InputMethodManagerService#setImeWindowStatus() because in many places we have assumed that an IME can show/hide its software keyboard even before an IME target window is associated with the IME. There are two major cases that we missed: - InputMethodManager#showSoftInputFromInputMethod(IBinder, int): This method does not require that the calling IME is already bound to an IME target window. - InputMethodManager#showSoftInputUnchecked(int ,ResultReceiver): This @hide method allows the caller application to let current IME show the software keyboard with bypassing all the normal focus management tasks in InputMethodManager. We should seriously consider to deprecate this @hide method, but to do that we have to clean up some internal components and SearchView in the support library that still rely on this method. Bug 35395372 is triggered by the second scenario, but until we sort out all the possible corner cases, we should allow null startInputToken as a valid request, like we had have done so before the CL [1] introduced such a validation. [1]: I9921b381e02106dbffff5e0b3d13f0a1245ce807 6db3bfe33d92127d203ec872a0b353585a99f256 Test: Made sure Bug 35395372 is no longer reproducible, that is, 1. Flash a new image and complete the setup wizard on a direct-boot unaware device. 2. Set a device password and require it upon each device boot. 3. adb reboot 4. Observe the default IME does not crash because of InvalidParameterException thrown by IMMS. Test: Made sure IMM#showSoftInputFromInputMethod(IBinder, int) does not throw an InvalidParameterException even in an extreme case. 1. Rebuild LatinIME with the following code in LatinIME.java @Override public AbstractInputMethodImpl onCreateInputMethodInterface() { return new InputMethodService.InputMethodImpl() { @Override public void attachToken(IBinder token) { super.attachToken(token); final InputMethodManager imm = getSystemService(InputMethodManager.class); final IBinder imeToken = getWindow().getWindow().getAttributes().token; imm.showSoftInputFromInputMethod(imeToken, 0); } }; } 2. adb install -r LatinIME.apk 3. adb shell ime enable com.android.inputmethod.latin/.LatinIME 4. adb shell ime set com.android.inputmethod.latin/.LatinIME 5. Tap any text field. 4. Observe LatinIME does not crash because of InvalidParameterException thrown by IMMS. Bug: 34628091 Bug: 35079353 Fixes: 35395372 Change-Id: Ib9448c551d9a30776a999c27a5ff20f1a095633a
/frameworks/base/core/java/android/view/WindowManagerInternal.java
|
69e68024220d3f18b08cbb314c7991f8f76cbe49 |
|
13-Feb-2017 |
Yohei Yukawa <yukawa@google.com> |
Propagate setImeWindowStatus() to WMS setImeWindowStatus() introduced in the previous CL [1] can help WindowManagerService (WMS) address Bug 34628091. As a preparation this CL has InputMethodManagerService propagate relevant information to WMS WMS for later use. [1]: I9921b381e02106dbffff5e0b3d13f0a1245ce807 db2afde0e584904ee4ce115ce176a4dfe1773990 Test: Verified the callback in WindowManagerService as follows: 1. Rebuild the system with DEBUG_INPUT_METHOD=true 2. adb logcat -s WindowManager:* to make sure the visibility passed to WindowManagerService#updateInputMethodWindowStatus matches to the actual IME window visibility Bug: 34628091 Bug: 35079353 Change-Id: I54fb1faf513883a54293a756e4c9d2ae9453d778
/frameworks/base/core/java/android/view/WindowManagerInternal.java
|
ac2561e8206ac42921bb6ddbb0a5972fb360e394 |
|
01-Nov-2016 |
Wale Ogunwale <ogunwale@google.com> |
Make window token add/remove APIs require displayId Window tokens can now only be on one display, so we now require clients that want to add/remove window tokens to specify the display they would like the token to be created on. This simplifies the token handling code in WM and will be useful moving forward for clients that want to add windows to external displays. Test: Existing tests pass Change-Id: I6b2d8d58a913b3624f1a9a7bebbb99315613f103
/frameworks/base/core/java/android/view/WindowManagerInternal.java
|
fe762344f4475a3a336bb46aef2d59c1fabf32ab |
|
13-Oct-2016 |
Jorim Jaggi <jjaggi@google.com> |
The big keyguard transition refactor (1/n) The heart of this change are two things: 1) Instead of using the force hide mechanism to hide windows behind Keyguard, we actually make the activities invisible in activity manager. 2) When Keyguard is going away, we change the visibilities in activity manager and run an app transition. At the very core we move the responsibility of hiding activities to ActivityStack, which checks whether Keyguard is showing, and then hides all non-show-when-locked activities. For that, we need to check whether any window of an activity has SHOW_WHEN_LOCKED set. We introduce a callback from WM -> AM in case these Keyguard flags have changed. Furthermore, we decide whether to occlude Keyguard in KeyguardController, which just checks whether the top activity has SHOW_WHEN_LOCKED set. When this state changes, we prepare an occlude/unocclude app transition, and in PWM we just inform the Keyguard about the animation so SysUI can play along this animations in a mostly synchronized manner. Since we now use an app transition when unlocking the phone, we get lockscreen launch animations for free - window manager automatically waits until the activity is drawn, or directly executes the transition if there is nothing to animate. Thus, we can remove all the infrastructure around "waitingForActivityDrawn". The logic to show/hide non-app windows is moved to policy, and we add the ability to run animations on non-app windows when executing an app transition. Test: 1) runtest frameworks-services -c com.android.server.wm.AppTransitionTests 2) Manually test unlocking Keyguard: 2a) Without security 2b) With security 2c) With security but trusted 2d) Portrait while activity behind is in landscape 3) Test launching things from Keyguard 3a) Without security 3b) With security 3c) Launch camera without security 3d) Launch camera with security 3e) Launch camera with securtiy and trusted 3f) Launch voice affordance 4) Set no notifications on lockscreen, drag down, make sure you get the correct animation 5) Test clicking "emergency" on bouncer 5b) Test "Emergency info" on emergency dialer 5c) Test clicking edit button on emergency info, should show pattern on Keyguard Bug: 32057734 Change-Id: Icada03cca74d6a612c1f988845f4d4f601087558
/frameworks/base/core/java/android/view/WindowManagerInternal.java
|
fd138896d5fc0c4ec3e46ad923fa4935ceaabdeb |
|
14-Jul-2016 |
Svetoslav Ganov <svetoslavganov@google.com> |
Update windows before sending a window state change event Change-Id: Ie25b75ccc739dcacbbffd2b3a32fe65086882c64
/frameworks/base/core/java/android/view/WindowManagerInternal.java
|
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
|