| b1b9a8ac07ea7d438eda613f4c798dd8b10a66ce |
|
29-Mar-2013 |
Brian Colonna <bcolonna@google.com> |
FUL now restarts when flipping tablet 180 (bug 7484464)
When a tablet rotates, FUL must be stopped and restarted in a new
position. 90 degree rotations cause a configuration change, causing
FUL to be automatically reconstructed in the new location. However,
a 180 degree rotation is not a configuration change, so FUL was not
restarting. A 180 degree rotation happens more often than one might
think. If you set the tablet down and later picked it up in the
opposite orientation, FUL would not work prior to this fix.
This change adds a rotation watcher to KeyguardFaceUnlockView. It
watches for 180 degree rotations and stops and restarts FUL
accordingly.
The rotation watcher callback must be unregistered when
KeyguardFaceUnlockView is recreated (as during 90 degree rotation
changes), otherwise the number of rotation watcher callbacks will keep
growing and they will never go away. This is a problem not just
because there are many callbacks hanging around, but also because the
old callbacks end up trying to access biometric unlock views that no
longer exist, resulting in crashes. So, a simple function was added
to the window manager to unregister a rotation watcher.
Change-Id: Ie1ef20a9a22b8f4e39918987dff2b8ad444fcfd1
/frameworks/base/tools/layoutlib/bridge/src/android/view/IWindowManagerImpl.java
|
| f3d46ce88f0777dddfbecebc9bd7f2f216206365 |
|
27-Mar-2013 |
Dianne Hackborn <hackbod@google.com> |
Fix build.
Change-Id: I51b87ee5f0b7f396aad7e239893d9f0764f04bb6
/frameworks/base/tools/layoutlib/bridge/src/android/view/IWindowManagerImpl.java
|
| 2ad920759b1981eaf526fd37a314fbc5a3ed90ae |
|
26-Feb-2013 |
Craig Mautner <cmautner@google.com> |
Revert ActivityManager changes for tasks. DO NOT MERGE
Keeping all activity=>task changes in master and removing them
from jb-mr2.
Revert "Update histories simultaneously."
Revert "Add null check to setAppGroupId."
Revert "Fix crashing bug in validator."
Revert "Switch topRunning* and moveTaskTo*"
Revert "Begin switch over to task based history."
Revert "Reset and reuse Iterators and don't new() one."
Revert "Remove AppWindowToken lists."
Revert "Fix build."
Revert "Remove unused App methods."
Revert "Stop using AppToken movement and start using Task."
Revert "Replace access to mAppTokens with AppTokenIterator"
Revert "Refactor setAppOpVisibility implementation."
Revert "Add AppWindowTokens to TaskList."
Revert "Make ActivityStack.mHistory private."
Revert "Migrate AppWindowToken lists into DisplayContent."
Change-Id: I5722c9a4956dccb52864207e2967690bc58e4ebb
/frameworks/base/tools/layoutlib/bridge/src/android/view/IWindowManagerImpl.java
|
| ee973c27e339a23e0b93d816a97b33954af66bea |
|
19-Feb-2013 |
Dianne Hackborn <hackbod@google.com> |
Fix build.
Change-Id: I277de38a70f3a2e5c1997a3fe5c2e825692ae9e1
/frameworks/base/tools/layoutlib/bridge/src/android/view/IWindowManagerImpl.java
|
| b0c0b1fd70e3edeb724e2b2fb2c7063eb943f05e |
|
14-Feb-2013 |
Craig Mautner <cmautner@google.com> |
Remove unused App methods.
Now that the Task methods have replaced the App methods remove
the App methods.
Change-Id: I0e7432f2c6f99708759ed8c871d20eb5bd38c3c2
/frameworks/base/tools/layoutlib/bridge/src/android/view/IWindowManagerImpl.java
|
| f5f7d9751a43b699b6e1c2e41ea0519bc54e39cd |
|
29-Jan-2013 |
Svetoslav <svetoslavganov@google.com> |
Fixing the build
Change-Id: I8d47c7094efc8ff458cdac58a761d5f187c8fc32
/frameworks/base/tools/layoutlib/bridge/src/android/view/IWindowManagerImpl.java
|
| 2ec5093e5a908cea532e571aead6a5c024c553f7 |
|
15-Dec-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Fixing the build
Change-Id: I01349d65ac5915da090cfb018f99e0a508f9d5ad
/frameworks/base/tools/layoutlib/bridge/src/android/view/IWindowManagerImpl.java
|
| 152e9bb81aa5b2ab4637f4b2dae04b3ce89fa891 |
|
13-Oct-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Refactoring of the screen magnification feature.
1. The screen magnification feature was implemented entirely as a part of the accessibility
manager. To achieve that the window manager had to implement a bunch of hooks for an
external client to observe its internal state. This was problematic since it dilutes
the window manager interface and allows code that is deeply coupled with the window
manager to reside outside of it. Also the observer callbacks were IPCs which cannot
be called with the window manager's lock held. To avoid that the window manager had
to post messages requesting notification of interested parties which makes the code
consuming the callbacks to run asynchronously of the window manager. This causes timing
issues and adds unnecessary complexity.
Now the magnification logic is split in two halves. The first half that is responsible
to track the magnified portion of the screen and serve as a policy which windows can be
magnified and it is a part of the window manager. This part exposes higher level APIs
allowing interested parties with the right permissions to control the magnification
of a given display. The APIs also allow a client to be registered for callbacks on
interesting changes such as resize of the magnified region, etc. This part servers
as a mediator between magnification controllers and the window manager.
The second half is a controller that is responsible to drive the magnification
state based on touch interactions. It also presents a highlight when magnified to
suggest the magnified potion of the screen. The controller is responsible for auto
zooming out in case the user context changes - rotation, new actitivity. The controller
also auto pans if a dialog appears and it does not interesect the magnified frame.
bug:7410464
2. By design screen magnification and touch exploration work separately and together. If
magnification is enabled the user sees a larger version of the widgets and a sub section
of the screen content. Accessibility services use the introspection APIs to "see" what
is on the screen so they can speak it, navigate to the next item in response to a
gesture, etc. Hence, the information returned to accessibility services has to reflect
what a sighted user would see on the screen. Therefore, if the screen is magnified
we need to adjust the bounds and position of the infos describing views in a magnified
window such that the info bounds are equivalent to what the user sees.
To improve performance we keep accessibility node info caches in the client process.
However, when magnification state changes we have to clear these caches since the
bounds of the cached infos no longer reflect the screen content which just got smaller
or larger.
This patch propagates not only the window scale as before but also the X/Y pan and the
bounds of the magnified portion of the screen to the introspected app. This information
is used to adjust the bounds of the node infos coming from this window such that the
reported bounds are the same as the user sees not as the app thinks they are. Note that
if magnification is enabled we zoom the content and pan it along the X and Y axis. Also
recomputed is the isVisibleToUser property of the reported info since in a magnified
state the user sees a subset of the window content and the views not in the magnified
viewport should be reported as not visible to the user.
bug:7344059
Change-Id: I6f7832c7a6a65c5368b390eb1f1518d0c7afd7d2
/frameworks/base/tools/layoutlib/bridge/src/android/view/IWindowManagerImpl.java
|
| 4eeb4f664ac6b5901a8e874dcf70c0382295f792 |
|
08-Nov-2012 |
Jim Miller <jaggies@google.com> |
Add mechanism to kick keyguard to show the assistant
Fixes bug 7499778
Change-Id: Ic9ea514feb489feeee6716f40bdb9792842f9515
/frameworks/base/tools/layoutlib/bridge/src/android/view/IWindowManagerImpl.java
|
| bfec0a8616bc197ee3b7b71be6fed1939d0c3c4d |
|
06-Nov-2012 |
Jim Miller <jaggies@google.com> |
Add isSafeModeEnabled() API to WindowManagerService
This adds a means of determining when the device is in safe mode,
as required by keyguard to disabled some features.
Change-Id: I31d357e6738c92e1837f9e0263e5f3f4de66315a
/frameworks/base/tools/layoutlib/bridge/src/android/view/IWindowManagerImpl.java
|
| 6dfd0b39a63559999a769f93d5cdb48abe675344 |
|
15-Oct-2012 |
Xavier Ducrohet <xav@android.com> |
Fix SDK layout rendering in Eclipse.
Change-Id: I0e9e85632012c0929b987ee9d0ccf7c25eece322
/frameworks/base/tools/layoutlib/bridge/src/android/view/IWindowManagerImpl.java
|