| 044d52934e57a337665f707aa4be1d423ee3fb29 |
|
06-Nov-2014 |
Winson Chung <winsonc@google.com> |
Adding bounce animation for affiliated tasks. (Bug 16656169)
Change-Id: I39e4a57c4e6b707d15513dacde2d40c23bb05058
/frameworks/base/core/java/android/view/IWindowManager.aidl
|
| 2e7f3bdcc9ec0b3e95b565b943ecee2210f4b937 |
|
05-Sep-2014 |
Winson Chung <winsonc@google.com> |
Removing unnecessary delays, ensuring transition thumbnail is the size of the header. (Bug. 16987565)
Change-Id: Ic104876c5fe16997eca00e0a2b3d8644c927120c
/frameworks/base/core/java/android/view/IWindowManager.aidl
|
| a4ccb86ddc8f9f486aee25fb836f4aff97bf7679 |
|
23-Aug-2014 |
Winson Chung <winsonc@google.com> |
Multiple performance changes to speed recents invocation/app launching time. (Bug 16987565)
- Reverting changes to the existing thumbnail transition to prevent breaking applications
that currently depend on that transition. As a result, we need to create a new, hidden,
aspect-scaled thumbnail transition, and instead use that thumbnail to animate the
recents header so that we don't have to wait to do that inside the Recents activity.
In order for this to work, we also have to ensure that the thumbnail surface destruction
is synchronized with the application that is currently closing (when going down to
recents) or opening (when coming back up). The current thumbnail is destroyed when the
animation ends, but that can be at least 1 frame before the surface for the animating
window is destroyed. We change this by deferring destruction of this thumbnail window
to the animation that is being closed.
Especially on the way up, not having to wait for us to hide the header before doing the
transition up can save us the duration of that first animation (> 100ms).
- Other optimizations:
* No longer creating a new stack view on each transition to calculate the target rect
* Removing unnecessary call to get the thumbnail when transitioning up/down (the actual
window does its own animation.
* We reduced numerous system calls per task by adding a flag to ignore home-stack tasks
and caching the activity label and icon (and task description icon). These caches
follow the same eviction schemes as the thumbnail and icon cache.
- Also tweaked the touch slop for the nav bar swiping gesture to prevent conflicting with
tapping on home (Bug 17109581)
Change-Id: Ica697aad788051a9203edd9351c583e1cb038a71
/frameworks/base/core/java/android/view/IWindowManager.aidl
|
| 84a3e7aacf6dbeccf4afb36a29f2f069dca7d486 |
|
13-Aug-2014 |
Jorim Jaggi <jjaggi@google.com> |
Use different unlock animation when going to full shade
Also fixes a bug that the notify flag was not reset, and fix the
transition for the phone/camera affordance (in these cases, no
animation is needed).
Bug: 15991916
Change-Id: Idbb4fa40f86bda597cd66cc38da838ef4f75514d
/frameworks/base/core/java/android/view/IWindowManager.aidl
|
| a87863a8bddb033ca9ace11e7d78932d70d08ce3 |
|
29-Jul-2014 |
Sander Alewijnse <salewijnse@google.com> |
Fix deadlock window manager and device policy manager.
Removed all communication from wm to device policy manager.
Added initialization of cache in wm by dpms.
Change-Id: Ifa0b8bfcd625464b156d5cc0fb66d342deda1c27
/frameworks/base/core/java/android/view/IWindowManager.aidl
|
| d2a1eec400128f39e1b223a720a88dbd395f3e6e |
|
09-Jul-2014 |
Sander Alewijnse <salewijnse@google.com> |
Add Device Policy API to disable screen capture.
WindowManager will set secure flag on SurfaceControl for
all windows of a flagged user to prevent screen capture.
API is consistent with the camera disable API.
Change-Id: Ib180f67f1ad827b6f4aca2af615274256cce58f4
/frameworks/base/core/java/android/view/IWindowManager.aidl
|
| bb742462781a73bb25516067c8fe6311c1c8a93e |
|
08-Jul-2014 |
Craig Mautner <cmautner@google.com> |
Launch activity behind launching task.
Use ActivityOptions.makeLaunchTaskBehindAnimation() to launch tasks
behind the current task. Includes animations for launching and
launched tasks.
Fixes bug 16157517.
Change-Id: I0a94af70b4748592e94673b958ee824cfb3d7ec0
/frameworks/base/core/java/android/view/IWindowManager.aidl
|
| eb94fa7975b1e8742f3b00cec6bd4f9d6b329e3a |
|
04-Jun-2014 |
Dianne Hackborn <hackbod@google.com> |
Improvements to low power mode.
Add new public API for monitoring low power mode.
BatteryService now puts device in to low power mode when
battery level is low.
Window manager now watches low power mode to turn off
animations.
Modifying the animator scale now gets propagated to all
processes.
Change-Id: I8fa566994764ddd4e1977631e28381ab9409f8ee
/frameworks/base/core/java/android/view/IWindowManager.aidl
|
| 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/IWindowManager.aidl
|
| 219d7a50fb7a269fe54dd9d70587c269d217336f |
|
29-May-2014 |
Craig Mautner <cmautner@google.com> |
Merge "Add methods to coordinate unlock animation." into lmp-preview-dev
|
| e30e02f5d9a9141c9ee70c712d4f9d52c88ea969 |
|
28-May-2014 |
Dianne Hackborn <hackbod@google.com> |
Add system layer for voice interaction services.
New window layer that voice interaction service windows
go in to. Includes a new voice-specific content rectangle
that voice activities are placed in to.
Add specific animations for this layer, sliding down from
the top (though this can be customized by the voice interaction
service).
Also add the concept of activities running for voice interaction
services for purposes of adjusting the animation used for them,
again sliding from the top, but not (yet?) customizable by the
voice interaction service.
Change-Id: Ic9e0e8c843c2e2972d6abb4087dce0019326155d
/frameworks/base/core/java/android/view/IWindowManager.aidl
|
| 0d674623facfbd3e9c520d2be4ed98977b92a1a2 |
|
21-May-2014 |
Jorim Jaggi <jjaggi@google.com> |
Add methods to coordinate unlock animation.
Introduce IWindowManager.keyguardGoingAway to notify that Keyguard
wants to dismiss it self. This method starts the state machine in
WindowAnimator which animates in the activity behind the keyguard.
Animating out the keyguard is done by the StatusBar/Keyguard
software when it receives the startKeyguardExitAnimation() callback.
Bug: 14118756
Change-Id: Id3b8f41189410bad808b4892fbec74245e59efce
/frameworks/base/core/java/android/view/IWindowManager.aidl
|
| dd137a85d3e0295989b5b9d1f67ff32027be867d |
|
10-Apr-2014 |
Svetoslav <svetoslavganov@google.com> |
resolved conflicts for merge of 6be2f952 to master-lockscreen-dev
Conflicts:
core/java/android/view/IWindowManager.aidl
tools/layoutlib/bridge/src/android/view/IWindowManagerImpl.java
Change-Id: Idcbc581294cc52b53eabefd61e5c20cbcea611db
|
| 1376d600d8e0eefdbc0aa11d398cf7517fc77129 |
|
13-Mar-2014 |
Svetoslav <svetoslavganov@google.com> |
Adding render stats APIs to UiAutomation (framework).
bug:12927198
Change-Id: Iae21481c75ae58dcdab3731bf5f1e2844e29d434
/frameworks/base/core/java/android/view/IWindowManager.aidl
|
| cff0acb6b1eea23c3f44a078a0a5e81c11faea35 |
|
31-Mar-2014 |
Jorim Jaggi <jjaggi@google.com> |
Wait for Keyguard to be drawn after boot.
The old logic with waiting for the Keyguard to be drawn assumed that
it is in an own window, and just checked for the visibility. This is
no longer possible as the Keyguard is in the status bar, and the status
bar might have been drawn without the Keyguard. So we have to wait
explicitely until Keyguard told PhoneWindowManager that it has now been
drawn and we can turn on the screen.
In addition, the starting logic of SystemUI is moved into
SystemUIApplication such the we can make sure that the status bar
already exists when the callbacks from PhoneWindowManager reach
KeyguardService. This simplifies the logic a lot.
Bug: 13635952
Change-Id: Ifd6ba795647edcf3501641e39052e4d04bc826fb
/frameworks/base/core/java/android/view/IWindowManager.aidl
|
| 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/IWindowManager.aidl
|
| 5d9f547720e07a2715d34320a9e11004654cede6 |
|
12-Nov-2013 |
Craig Mautner <cmautner@google.com> |
Relayout windows that handle their own config change.
If a window claims to handle its own configuration change then we
won't destroy and recreate its window on a configuration change.
Normally that recreation triggers the first layout following
orientation change because mHaveFrame is false. Windows that handle
their own configuration changes never got a relayout pass following a
change in orientation.
This change passes the configuration changes that an application
handles into the AppWindowToken. If the app says it handles
orientation or screen size changes then a relayout will occur when the
configuration has changed.
Fixes bug 11647107.
Change-Id: Ie8d49fd050442ebbdcf0b805087894e3a2fc4be9
/frameworks/base/core/java/android/view/IWindowManager.aidl
|
| e7c285725d1b6af76e7655a79a3e71f3809fdd9f |
|
29-Oct-2013 |
John Spurlock <jspurlock@google.com> |
Optimize sysui ui queue during keyguard unlock.
Target the two biggest offenders:
- Coalesce keyguard setHidden(false) calls during unlock.
- Make sysui->WM call async.
Found during investigation into b/11221659.
Bug: 11221659
Change-Id: Icab48376bc356a933e0f9940bc2f924e2e77ab22
/frameworks/base/core/java/android/view/IWindowManager.aidl
|
| 5a0f4eccfb1e1774c4aac825bf39bcc4f5fc00e0 |
|
08-Oct-2013 |
Alan Viverette <alanv@google.com> |
Ignore certain WindowManager flags when touch exploration is enabled
Specifically, ignore any flags that alter the visibility of the navigation
bar and transparency.
BUG: 11082573
Change-Id: I17264dc55a1c6c3cb9b9cf92d5121799cecee5b8
/frameworks/base/core/java/android/view/IWindowManager.aidl
|
| 172e87ce5113d75afbf894aef83bd30b43c98f5e |
|
03-Oct-2013 |
John Reck <jreck@google.com> |
Reduce max recents on lowram
Bug: 10918599
Reduce the number of recent tasks to 10 on lowram devices
Use RGB_565 on low ram devices for thumbnails instead of ARGB_8888
Combined this saves ~9MB across system_process and systemui
Change-Id: Ieddcb512c7341a90097bc7cbc72d7355a775b416
/frameworks/base/core/java/android/view/IWindowManager.aidl
|
| 6c9df5054a25f179ea7359a1a5e59e7d5d8da122 |
|
20-Sep-2013 |
Jim Miller <jaggies@google.com> |
Fix permissions on WindowManagerService.showAssistant()
Since binder call permissions are not transitive by design,
the proper way to fix this is to have the call talk directly
to keyguard from the navigation bar.
Fixes bug 9409008
Change-Id: Ibd90a79bb638c969b514455a2ad93c6ff668222d
/frameworks/base/core/java/android/view/IWindowManager.aidl
|
| ac6f843c917b68ea8805711965b149a9338e3a0e |
|
17-Jul-2013 |
Craig Mautner <cmautner@google.com> |
Fix home activity and user switch interactions.
- Make sure Home activity goes in the correct task and on the correct
stack.
- Do not allow different users to be in the same task.
- Do not set stacks aside for each user.
Fixes bug 9775492.
Change-Id: I0e7954e917aac8482a1015a36923e02914e2b692
/frameworks/base/core/java/android/view/IWindowManager.aidl
|
| 80f00c1f2375796dab09bc4ed5b7631c62f7e158 |
|
13-Jun-2013 |
John Spurlock <jspurlock@google.com> |
Remove concept of system bar from window manager.
It was already hardcoded to false, this change removes the dead code.
Change-Id: I5e543344e60f69cb9882a70ba29f7c09404ad9fc
/frameworks/base/core/java/android/view/IWindowManager.aidl
|
| 04fe6ebb9f919f196ec06a19bebc09b8e943f95b |
|
31-May-2013 |
Adam Powell <adamp@google.com> |
Fix a bug resolving the correct icon/logo in action bars
Remove some abstraction-breaking magic in ActionBarView and replace it
with proper resolution of the icon/logo when creating a window. The
old implementation relied on the ActionBarView's context being an
Activity.
Bug 9171554
Change-Id: Idbbb1942622195dcb55e8119f2d64287b07bb509
/frameworks/base/core/java/android/view/IWindowManager.aidl
|
| c849fbcf3ddd3cbb08840c72f7f325294c5d2802 |
|
02-Apr-2013 |
Brian Colonna <bcolonna@google.com> |
resolved conflicts for merge of 5856ee4b to master
Change-Id: I60ba85bc246b9cf25d467b2099535aad47f82ca7
|
| 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/core/java/android/view/IWindowManager.aidl
|
| 5ab6d905782562995f1755f03c3716887fba53b8 |
|
27-Mar-2013 |
Dianne Hackborn <hackbod@google.com> |
am a4820789: am 5871b258: Merge "Change wm commands to return size and density info." into jb-mr2-dev
* commit 'a4820789136c814e1e9ae26d5a0712e1c7fd4dd5':
Change wm commands to return size and density info.
|
| 672cf45de7aa5ad6fd1f75512ee5a451a16c0b39 |
|
26-Mar-2013 |
Dianne Hackborn <hackbod@google.com> |
Change wm commands to return size and density info.
Change-Id: Id25722fe5f0cd9470d04d657f067e5ad29927c98
/frameworks/base/core/java/android/view/IWindowManager.aidl
|
| c00204b4d14d49a0417b44ca21aee4f0d4c466e0 |
|
06-Mar-2013 |
Craig Mautner <cmautner@google.com> |
Start moving Tasks from DisplayContent to TaskStack
- Create new classes for Stacks on WindowManager.
- Stop using DisplayContent methods and members:
addAppToken(),
removeAppToken(),
setAppTaskId(),
removeTask(),
mTaskIdToDisplayContents,
mTaskIdToTask.
- Start using WindowManagerService.createTask().
- Establish hierarchy of references: AppWindowToken=>Task=>
TaskStack=>StackBox=>DisplayContent.
- Clean up StackBox, TaskStack, and Task.
Change-Id: I798990aa7966784d22f4a43822087d8bb0404dd6
/frameworks/base/core/java/android/view/IWindowManager.aidl
|
| 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/core/java/android/view/IWindowManager.aidl
|
| 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/IWindowManager.aidl
|
| 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/core/java/android/view/IWindowManager.aidl
|
| 80943d8daa6ab31ab5c486d57aea406aa0730d58 |
|
02-Jan-2013 |
Svetoslav Ganov <svetoslavganov@google.com> |
Adding UI test automation APIs.
This change adds APIs support for implementing UI tests. Such tests do
not rely on internal application structure and can span across application
boundaries. UI automation APIs are encapsulated in the UiAutomation object
that is provided by an Instrumentation object. It is initialized by the
system and can be used for both introspecting the screen and performing
interactions simulating a user. UI test are normal instrumentation tests
and are executed on the device.
UiAutomation uses the accessibility APIs to introspect the screen and
a special delegate object to perform privileged operations such as
injecting input events. Since instrumentation tests are invoked by a shell
command, the shell program launching the tests creates a delegate object and
passes it as an argument to started instrumentation. This delegate
allows the APK that runs the tests to access some privileged operations
protected by a signature level permissions which are explicitly granted
to the shell user.
The UiAutomation object also supports running tests in the legacy way
where the tests are run as a Java shell program. This enables existing
UiAutomator tests to keep working while the new ones should be implemented
using the new APIs. The UiAutomation object exposes lower level APIs which
allow simulation of arbitrary user interactions and writing complete UI test
cases. Clients, such as UiAutomator, are encouraged to implement higher-
level APIs which minimize development effort and can be used as a helper
library by the test developer.
The benefit of this change is decoupling UiAutomator from the system
since the former was calling hidden APIs which required that it is
bundled in the system image. This prevented UiAutomator from being
evolved separately from the system. Also UiAutomator was creating
additional API surface in the system image. Another benefit of the new
design is that now test cases have access to a context and can use
public platform APIs in addition to the UiAutomator ones. Further,
third-parties can develop their own higher level test APIs on top
of the lower level ones exposes by UiAutomation.
bug:8028258
Also this change adds the fully qualified resource name of the view's
id in the emitted AccessibilityNodeInfo if a special flag is set while
configuring the accessibility service. Also added is API for looking
up node infos by this id. The id resource name is relatively more stable
compared to the generaed id number which may change from one build to
another. This API facilitate reuing the already defined ids for UI
automation.
bug:7678973
Change-Id: I589ad14790320dec8a33095953926c2a2dd0228b
/frameworks/base/core/java/android/view/IWindowManager.aidl
|
| 545252f4fde6fbb70b07e97a120c7d1405758017 |
|
11-Dec-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Refactoring of the screen magnification feature.
1. This patch takes care of the case where a magnified window is covering an unmagnigied
one. One example is a dialog that covers the IME window.
bug:7634430
2. Ensuring that the UI automator tool can connect and correctly dump the screen.
bug:7694696
3. Removed the partial implementation for multi display magnification. It adds
unnecessary complexity since it cannot be implemented without support for
input from multiple screens. We will revisit when necessary.
4. Moved the magnified border window as a surface in the window manager.
5. Moved the mediator APIs on the window manager and the policy methods on the
WindowManagerPolicy.
6. Implemented batch event processing for the accessibility input filter.
Change-Id: I4ebf68b94fb07201e124794f69611ece388ec116
/frameworks/base/core/java/android/view/IWindowManager.aidl
|
| 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/core/java/android/view/IWindowManager.aidl
|
| 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/core/java/android/view/IWindowManager.aidl
|
| 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/core/java/android/view/IWindowManager.aidl
|
| 33877e15b8bfc50bd874027689a4794aa93b923d |
|
07-Oct-2012 |
Craig Mautner <cmautner@google.com> |
Merge "Adds showWhenLocked attribute to Activities." into jb-mr1-dev
|
| 5962b12bedc4a1d0354816c1cd6b06ba04f6d807 |
|
05-Oct-2012 |
Craig Mautner <cmautner@google.com> |
Adds showWhenLocked attribute to Activities.
The new attribute allows an Activity such as the alarm to appear
on all users screens.
Bug: 7213805 fixed.
Change-Id: If7866b13d88c04af07debc69e0e875d0adc6050a
/frameworks/base/core/java/android/view/IWindowManager.aidl
|
| c38c9be031ddad5cf551b55458889f11e01dc5b2 |
|
04-Oct-2012 |
Jeff Brown <jeffbrown@google.com> |
Coordinate screen on with the window manager.
Bug: 7267457
Change-Id: Ic2c322253639e1f0b2e4e72a7b145025d0240f93
/frameworks/base/core/java/android/view/IWindowManager.aidl
|
| f752202bee88e31ce765483ba2efa6999ae9c9ad |
|
04-Oct-2012 |
Adam Cohen <adamcohen@google.com> |
Plumbing to allow keyguard to be shown with user switcher (issue 7175023)
-> Also reduced calls to lockNow, and moved this call in ActivityManagerService
Change-Id: I9ba34ca902f7c0f71fa4ec302104688ca8d11f55
/frameworks/base/core/java/android/view/IWindowManager.aidl
|
| 9ba2a188919e6e5bf8c042b26527fc090de677ef |
|
11-Sep-2012 |
Jeff Brown <jeffbrown@google.com> |
Merge changes I4ad08873,If0562677,I5fe6ba32 into jb-mr1-dev
* changes:
Don't auto-discover peers until scan requested.
Use wfdInfo to filter available sinks.
Allow adb shell am display-size to use bigger sizes.
|
| 9d9ece3c1e16001b63244459cdf4b428f4272d2e |
|
11-Sep-2012 |
Dianne Hackborn <hackbod@google.com> |
Animations for user switching.
The window manager now has a facility to provide a full-screen
animation, which the activity manager uses every time a user
switch happens.
The current animation is just a simple dumb slide until we get
a design from UX.
Also some cleanup: moved the portrait task animations to the
default config so we always have an animation for them, and finally
got the java symbol stuff out of public.xml.
Change-Id: I726f77422b2ef5f2d98f961f8da003e045f0ebe8
/frameworks/base/core/java/android/view/IWindowManager.aidl
|
| 43aa15912891930833edfc101615a9c881de54a1 |
|
11-Sep-2012 |
Jeff Brown <jeffbrown@google.com> |
Allow adb shell am display-size to use bigger sizes.
We now support scaling the logical display to fit the
physical display, whatever size it is. So we can allow
adb shell am display-size to use more or less arbitrary sizes
although we do enforce an upper and lower bound to
protect the user.
Change-Id: I5fe6ba32ad1f9e4fbcd6915f7d36850b987bbcc0
/frameworks/base/core/java/android/view/IWindowManager.aidl
|
| 1cf70bbf96930662cab0e699d70b62865766ff52 |
|
06-Aug-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Screen magnification - feature - framework.
This change is the initial check in of the screen magnification
feature. This feature enables magnification of the screen via
global gestures (assuming it has been enabled from settings)
to allow a low vision user to efficiently use an Android device.
Interaction model:
1. Triple tap toggles permanent screen magnification which is magnifying
the area around the location of the triple tap. One can think of the
location of the triple tap as the center of the magnified viewport.
For example, a triple tap when not magnified would magnify the screen
and leave it in a magnified state. A triple tapping when magnified would
clear magnification and leave the screen in a not magnified state.
2. Triple tap and hold would magnify the screen if not magnified and enable
viewport dragging mode until the finger goes up. One can think of this
mode as a way to move the magnified viewport since the area around the
moving finger will be magnified to fit the screen. For example, if the
screen was not magnified and the user triple taps and holds the screen
would magnify and the viewport will follow the user's finger. When the
finger goes up the screen will clear zoom out. If the same user interaction
is performed when the screen is magnified, the viewport movement will
be the same but when the finger goes up the screen will stay magnified.
In other words, the initial magnified state is sticky.
3. Pinching with any number of additional fingers when viewport dragging
is enabled, i.e. the user triple tapped and holds, would adjust the
magnification scale which will become the current default magnification
scale. The next time the user magnifies the same magnification scale
would be used.
4. When in a permanent magnified state the user can use two or more fingers
to pan the viewport. Note that in this mode the content is panned as
opposed to the viewport dragging mode in which the viewport is moved.
5. When in a permanent magnified state the user can use three or more
fingers to change the magnification scale which will become the current
default magnification scale. The next time the user magnifies the same
magnification scale would be used.
6. The magnification scale will be persisted in settings and in the cloud.
Note: Since two fingers are used to pan the content in a permanently magnified
state no other two finger gestures in touch exploration or applications
will work unless the uses zooms out to normal state where all gestures
works as expected. This is an intentional tradeoff to allow efficient
panning since in a permanently magnified state this would be the dominant
action to be performed.
Design:
1. The window manager exposes APIs for setting accessibility transformation
which is a scale and offsets for X and Y axis. The window manager queries
the window policy for which windows will not be magnified. For example,
the IME windows and the navigation bar are not magnified including windows
that are attached to them.
2. The accessibility features such a screen magnification and touch
exploration are now impemented as a sequence of transformations on the
event stream. The accessibility manager service may request each
of these features or both. The behavior of the features is not changed
based on the fact that another one is enabled.
3. The screen magnifier keeps a viewport of the content that is magnified
which is surrounded by a glow in a magnified state. Interactions outside
of the viewport are delegated directly to the application without
interpretation. For example, a triple tap on the letter 'a' of the IME
would type three letters instead of toggling magnified state. The viewport
is updated on screen rotation and on window transitions. For example,
when the IME pops up the viewport shrinks.
4. The glow around the viewport is implemented as a special type of window
that does not take input focus, cannot be touched, is laid out in the
screen coordiates with width and height matching these of the screen.
When the magnified region changes the root view of the window draws the
hightlight but the size of the window does not change - unless a rotation
happens. All changes in the viewport size or showing or hiding it are
animated.
5. The viewport is encapsulated in a class that knows how to show,
hide, and resize the viewport - potentially animating that.
This class uses the new animation framework for animations.
6. The magnification is handled by a magnification controller that
keeps track of the current trnasformation to be applied to the screen
content and the desired such. If these two are not the same it is
responsibility of the magnification controller to reconcile them by
potentially animating the transition from one to the other.
7. A dipslay content observer wathces for winodw transitions, screen
rotations, and when a rectange on the screen has been reqeusted. This
class is responsible for handling interesting state changes such
as changing the viewport bounds on IME pop up or screen rotation,
panning the content to make a requested rectangle visible on the
screen, etc.
8. To implement viewport updates the window manger was updated with APIs
to watch for window transitions and when a rectangle has been requested
on the screen. These APIs are protected by a signature level permission.
Also a parcelable and poolable window info class has been added with
APIs for getting the window info given the window token. This enables
getting some useful information about a window. There APIs are also
signature protected.
bug:6795382
Change-Id: Iec93da8bf6376beebbd4f5167ab7723dc7d9bd00
/frameworks/base/core/java/android/view/IWindowManager.aidl
|
| 832cb229cd748505c90f74ae8154fc3557d61a73 |
|
13-Apr-2012 |
Michael Jurka <mikejurka@google.com> |
Adding a thumbnail scale down animation
Recents animation will temporarily look a bit
wrong, but a subsequent change will fix this.
/frameworks/base/core/java/android/view/IWindowManager.aidl
|
| 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/IWindowManager.aidl
|
| 59c009776dae5ccbdfb93d7151ff2065ca049dc3 |
|
30-Jul-2012 |
Craig Mautner <cmautner@google.com> |
Introduce multiple displays with DisplayContent.
Fix a couple of bugs that turned up.
Remove touch/focus from display. Add iterators for access.
Respond to comments. Remove TODOs, and some deviceId parameters.
Change-Id: Idcdb4f1979aa7b14634d450fd0333d6eff26994d
/frameworks/base/core/java/android/view/IWindowManager.aidl
|
| 6881a10557acf3b0270de54799d6f19437acf584 |
|
27-Jul-2012 |
Craig Mautner <cmautner@google.com> |
Small step towards supporting multiple displays
Change-Id: I353449c2b464394988c7e0203656b5851a0c9127
/frameworks/base/core/java/android/view/IWindowManager.aidl
|
| 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/IWindowManager.aidl
|
| c9c9a48e7bafae63cb35a9aa69255e80aba83988 |
|
16-Jul-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Removing a workaround for incorrect window position on window move.
1. The window manager was not notifying a window when the latter
has been moved. This was causing incorrect coordinates of the
nodes reported to accessibility services. To workaround that
we have carried the correct window location when making a
call from the accessibility layer into a window. Now the
window manager notifies the window when it is moved and the
workaround is no longer needed. This change takes it out.
2. The left and right in the attach info were not updated properly
after a report that the window has moved.
3. The accessibility manager service was calling directly methods
on the window manager service without going through the interface
of the latter. This leads to unnecessary coupling and in the
long rung increases system complexity and reduces maintability.
bug:6623031
Change-Id: Iacb734b1bf337a47fad02c827ece45bb2f53a79d
/frameworks/base/core/java/android/view/IWindowManager.aidl
|
| 84375876fcef73c5fa9c3de205c7db908ee14e15 |
|
02-Jun-2012 |
Dianne Hackborn <hackbod@google.com> |
Work on issue #6579997: Mariner entrance animation
Add a new variation of ActivityOptions that allows you to
supply custom animation resources and get a callback when the
animation starts.
Use this in SearchPanelView to determine when to start hiding
the search panel instead of having a fixed delay.
Fix some issues in the activity manager where we would cancel
the options in cases where we should actually keep them to give
to the window manager for a transition. (Basically when the
activity being started is not actually ending up launched, but
just results in a shift in the activity stack.)
Note that this is not quite what the design calls for -- the
entire search UI is waiting and then disappearing when the
animation starts, instead of the ring first disappearing while
waiting for the time to fade out the circle.
Change-Id: Iee9a404ba530908d73cdbd4a9d0d2907ac03428f
/frameworks/base/core/java/android/view/IWindowManager.aidl
|
| 21385cd83d7d7938b57a4acbaa236dd4c7804ed4 |
|
03-May-2012 |
Michael Jurka <mikejurka@google.com> |
Making transition out of recents look better
- Fading out recents first, then scaling up app
thumbnail
- Fade Recents out over 130ms
- Delay the window animation for 200ms first,
then animate for 200ms (previously we didn't delay
and then animated for 300ms)
Bug: 6390075
Change-Id: Ia8c753bf7ee03d2acef6eb2772b28d88fe10a682
/frameworks/base/core/java/android/view/IWindowManager.aidl
|
| 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/IWindowManager.aidl
|
| eabfb3a36e9469c5e219f92b39b7200104319185 |
|
17-Apr-2012 |
Dianne Hackborn <hackbod@google.com> |
Add new scale-up window manager animation.
Like zoom thumbnail, but without the thumbnail.
Change-Id: I9486dd204398b87c9e70ff0d05d03f4a22449cd6
/frameworks/base/core/java/android/view/IWindowManager.aidl
|
| ac14351e16e1258f1cb54e2bf772b8be004eb2b8 |
|
06-Apr-2012 |
Jeff Brown <jeffbrown@google.com> |
Move some APIs from window manager to input manager.
Simplified input injection API down to just one call.
Removed all input state reading API. It was only used by the
window manager policy and required a permission that applications
could not obtain. READ_INPUT_STATE is now unused and deprecated.
Change-Id: I41278141586ddee9468cae0fb59ff0dced6cbc00
/frameworks/base/core/java/android/view/IWindowManager.aidl
|
| f87d19621dc2a30232bba1f51862a0b671eb9729 |
|
04-Apr-2012 |
Dianne Hackborn <hackbod@google.com> |
Clean up status bar, system bar, navigation bar management.
The status bar and navigation bar are two completely separate
elements, with their own semantics. The system bar now classifies
itself as a navigation bar, since that is really how it behaves.
This required rewriting the HDMI resizing code, so that it is
all done by PhoneWindowManager since that is what is responsible
for the size of the navigation bar (and thus now system bar). This
actually gets rid of a fair amount of code, and means we can also
do the same thing for a pure navigation bar.
Likewise the system bar now has the navigation bar ability to be
hidden when requested by system UI flags. To get the behavior
we want on Xoom, we only allow the nav bar to be hidden when it
will help provide a better aspect ratio for showing widescreen
videos.
Finally the nav/system bar now animates when hidden and shown.
Change-Id: Ie927154b68376a0b61802f99171ff56b8da92e7a
/frameworks/base/core/java/android/view/IWindowManager.aidl
|
| 8078d8c8a282ca81344febe7256f63b1e805e3aa |
|
20-Mar-2012 |
Dianne Hackborn <hackbod@google.com> |
Add new thumbnail animation.
Use it for recent tasks switching.
Not perfect yet by far, but something.
Also fix issue #6186758: Twitter crashes after tapping on a tweet on JRM75D
Change-Id: I49bf6c94aafde875ac652dedaf96d6c08cc9e7d2
/frameworks/base/core/java/android/view/IWindowManager.aidl
|
| 93c518e4f8abd98f87cda1712b30a5a86cfa60dd |
|
18-Jan-2012 |
Jim Miller <jaggies@google.com> |
Fix 5863053: Add method to lock screen immediately.
This fixes a bug where the device fails to lock when DevicePolicyManagerService
requests the device to be locked and the screen was off because the user hit
the power button.
The change allows DPMS to directly invoke screen lock, bypasssing the screen state.
Change-Id: Iecdda6fc61e9c519119de495be23c69c3b983921
/frameworks/base/core/java/android/view/IWindowManager.aidl
|
| 0c4ccff36930ff4f0292b94ad51e164c9fa060a3 |
|
19-Oct-2011 |
Daniel Sandler <dsandler@android.com> |
Add hasNavigationBar() to the window manager.
It is no longer sufficient to check the value of
internal.R.bool.config_showNavigationBar to determine if a
navigation bar (separate from the status bar) is shown on a
device, because the emulator needs to be able to override
this value (now possible by setting qemu.hw.mainkeys to "1"
or "0", for navbar or no navbar, respectively).
This logic is now contained in PhoneWindowManager, and any
clients wishing to know whether the system has a software
nav bar should consult the new hasNavigationBar() method.
Bug: 5404945
Change-Id: I119d32a8c84b88b2ef46f63244e7f11dc5de0359
/frameworks/base/core/java/android/view/IWindowManager.aidl
|
| 4dfce20cac7492882d366d053006795aefad59da |
|
05-Oct-2011 |
Jeff Brown <jeffbrown@google.com> |
Make SENSOR orientation modes trump rotation lock.
Bug: 5371750
Change-Id: I4d18b6c8ba1de0afd5929ddb8d7123272e35fbe2
/frameworks/base/core/java/android/view/IWindowManager.aidl
|
| 90c52de28691ca0bbbf7c039ef20f85ce46882cc |
|
23-Sep-2011 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #5173952: Opening a Notification From Lock Screen...
...Should Skip Unsecure Lockscreen (ICS)
Also while I am in there, clean up logging of intent objects to include
even less sensitive information, while showing the true Intent in dump
output (since apps can't get to that).
Change-Id: I35fed714645b21e4304ba38a11ebb9c4c963538e
/frameworks/base/core/java/android/view/IWindowManager.aidl
|
| 01a98ddbdfbaf1f0d2bc602537e6e314364902a3 |
|
21-Sep-2011 |
Jeff Brown <jeffbrown@google.com> |
Handle orientation changes more systematically.
Bug: 4981385
Simplify the orientation changing code path in the
WindowManager. Instead of the policy calling setRotation()
when the sensor determined orientation changes, it calls
updateRotation(), which figures everything out. For the most
part, the rotation actually passed to setRotation() was
more or less ignored and just added confusion, particularly
when handling deferred orientation changes.
Ensure that 180 degree rotations are disallowed even when
the application specifies SCREEN_ORIENTATION_SENSOR_*.
These rotations are only enabled when docked upside-down for
some reason or when the application specifies
SCREEN_ORIENTATION_FULL_SENSOR.
Ensure that special modes like HDMI connected, lid switch,
dock and rotation lock all cause the sensor to be ignored
even when the application asks for sensor-based orientation
changes. The sensor is not relevant in these modes because
some external factor (or the user) is determining the
preferred rotation.
Currently, applications can still override the preferred
rotation even when there are special modes in play that
might say otherwise. We could tweak this so that some
special modes trump application choices completely
(resulting in a letter-boxed application, perhaps).
I tested this sort of tweak (not included in the patch)
and it seems to work fine, including transitions between
applications with varying orientation.
Delete dead code related to animFlags.
Handle pausing/resuming orientation changes more precisely.
Ensure that a deferred orientation change is performed when
a drag completes, even if endDragLw() is not called because the
drag was aborted before the drop happened. We pause
the orientation change in register() and resume in unregister()
because those methods appear to always be called as needed.
Change-Id: If0a31de3d057251e581fdee64819f2b19e676e9a
/frameworks/base/core/java/android/view/IWindowManager.aidl
|
| 38e29a61d0c87fe3e391d24e2eb11dd1800d107d |
|
18-Sep-2011 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #5242779: Device not responding to touch on unlock screen
Rework how we decide when it is okay to turn on the screen by having
the policy call back to the power manager when it knows the lock screen
has been drawn.
Change-Id: Ie8f3f72111dcf7f168723e6dce24e0343b4afe5d
/frameworks/base/core/java/android/view/IWindowManager.aidl
|
| 29aae6f36e565b8f2a99f2193597b964bb800ee8 |
|
19-Aug-2011 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #4279860: previous UI flashes before showing lock screen...
...(when turning display on after recently turning it off)
Also clean up when we decide to turn the screen on to improve that
transition. There are still problems here with turning it on
before the wallpaper gets dispayed.
Change-Id: I2bc56c12e5ad75a1ce5a0546f43a845bf0823e66
/frameworks/base/core/java/android/view/IWindowManager.aidl
|
| dfee59afb3e4cdcde38f6338f9360655de76da92 |
|
06-Aug-2011 |
Adam Powell <adamp@google.com> |
Fix bug 5011824 - New Holo overflow menu for physical menu key devices
The new Holo-style overflow menu now appears from the edge of the screen
where the device's physical menu key can be found. The policy determining
this lives in getPreferredOptionsPanelGravity() in WindowManagerService.
Change-Id: I8851a2265547156591e82044e50b5cfc58d3eefa
/frameworks/base/core/java/android/view/IWindowManager.aidl
|
| 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/IWindowManager.aidl
|
| 1a84fd1fb7a51f3fe4f8865e1cdd09f3490f696c |
|
02-Jun-2011 |
Jeff Brown <jeffbrown@android.com> |
Add a preference panel for mouse speed.
Bug: 4124987
Change-Id: I3ce175d268a1d043cf5878481261b1049a15a149
/frameworks/base/core/java/android/view/IWindowManager.aidl
|
| 2f0b17573d4324832f7a20402a3d2b5920bc4866 |
|
01-Jun-2011 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #4502672: Wrong xml resources used for homescreen widgets.
There was a race in the system process between applying the initial
configuration and executing code in higher-level system services
like the app widget service that relies on the config. For some
reason it starting showing up more after my code changes; it should
now be completely fixed.
Also fix the activity starting window to run in compatibility mode
if its application is going to be in compatibility mode.
And some various cleanup and small fixes.
Change-Id: I0566933bf1bbb4259c1d99a60c0a3c19af1542e5
/frameworks/base/core/java/android/view/IWindowManager.aidl
|
| 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/IWindowManager.aidl
|
| 7916ac65dc492e4e1431879875c77d7121fbf82e |
|
17-May-2011 |
Dianne Hackborn <hackbod@google.com> |
Add new command line option to change global screen size.
For example:
adb shell am display-size 1024x600
Change-Id: I5df462acd3323bdaaaefa3126faea7dd8595b726
/frameworks/base/core/java/android/view/IWindowManager.aidl
|
| 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/IWindowManager.aidl
|
| 520d8bc1d840966b5519195aaa514597a662c053 |
|
18-Feb-2011 |
Mike Lockwood <lockwood@android.com> |
KeyguardManager: Add isKeyguardLocked() and isKeyguardSecure()
BUG: 3402847
Change-Id: I725838c9d96617dd4497f9c80417cd623eceb846
Signed-off-by: Mike Lockwood <lockwood@android.com>
/frameworks/base/core/java/android/view/IWindowManager.aidl
|
| 664644d9e012aa2a28ac96f305b1ce6499ec8806 |
|
24-Jan-2011 |
Joe Onorato <joeo@google.com> |
visibility ("lights out") API.
1. Views may setSystemUiVisibility() to recommend that
the system chrome (status bar or other UI) show or hide
itself. (This functionality was previously available only
via the FLAG_FULLSCREEN window flag for some SystemUI
implementations.)
2. Views may register a OnSystemUiVisibilityChangedListener
on a view, and find out when the system UI actually
appears or disappears, allowing apps to coordinate the
appearance of their own UI if desired.
Bug: 3241144
Change-Id: Ia1758d94099182d49a1e3688ea2738ae4995b829
/frameworks/base/core/java/android/view/IWindowManager.aidl
|
| d2835935d2df8be70d1b37d3ef3b2fe0155b3422 |
|
14-Dec-2010 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #3258849: Grab thumbnail when exiting an app via back
Also issue #3281400: Rotating a retained instance fragment leaks the fragment manager
And turn off fragment debug logging.
Change-Id: Ibdd7db82bb35618021bcba421ba92ced7cd691c2
/frameworks/base/core/java/android/view/IWindowManager.aidl
|
| 7da6ac33a9de82be52e22846d5f22d502452854c |
|
10-Dec-2010 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #3272051: Use backward transition when going backwards.
Also know as:
Issue #3272051 Contacts edit view: Tapping the in-app back button
results in a forward transition
Yeah more complexity in deciding which animation to use.
Also reduce complexity in deciding which app's animation set to use,
to balance things out (and make it have less stupid behavior).
Change-Id: I78c6c5c5249a96206f7e03ce587c1dcb9a7dc14f
/frameworks/base/core/java/android/view/IWindowManager.aidl
|
| 0aae2d4e0075fd699cf40b26dca0eb2c3b3e37d2 |
|
08-Dec-2010 |
Dianne Hackborn <hackbod@google.com> |
Rework activity lifecycle so onSaveInstanceState() is after onPause().
The goal is to fix a bunch of fragment-related bugs caused by various
things trying to do fragment transactions after onPause()... which
currently throws an exception, since this is after the activity's state
has been saved so the new fragment state can be lost.
The basic change is relatively simple -- we now consider processes
hosting paused or stopping activities to be unkillable, and the client
code now does the onSaveInstanceState() as part of stopping the
activity.
For compatibility, if an app's targetSdkVersion is < HONEYCOMB, the
client side will still call onSaveInstanceState() prior to onPause()
and just hold on to that state until it needs to report it in once
being stopped.
Also included here is a change to generate thumbnails by taking
screenshots. The code for generating thumbnails by re-rendering
the view hierarchy is thus removed.
Change-Id: Iac1191646bd3cadbfe65779297795f22edf7e74a
/frameworks/base/core/java/android/view/IWindowManager.aidl
|
| c1a968a8ed45181312f7d4bcdbba0cc8ddc201ba |
|
24-Nov-2010 |
Brad Fitzpatrick <bradfitz@android.com> |
Option to enable StrictMode flashing on userdebug builds.
Change-Id: Ifc8e733ea0e0f6bda234a18ad84bcd230879e802
/frameworks/base/core/java/android/view/IWindowManager.aidl
|
| 6804433b0af50f33a338307ae8ddb50bc49e886b |
|
23-Nov-2010 |
Brad Fitzpatrick <bradfitz@android.com> |
StrictMode visual notification support.
Change-Id: I64a5adb683060d9649f1132414547bb3c346a2a8
/frameworks/base/core/java/android/view/IWindowManager.aidl
|
| 7eec10e6c99c30d5ee061fec08ac89ad4254ac32 |
|
13-Nov-2010 |
Dianne Hackborn <hackbod@google.com> |
Get rid of the extended themes.
We now decide whether to use a bitmap background based on whether the
window's drawing is hardware accelerated. To do this, there is a new
"state_accelerated" that state list drawables can be parameterized on,
and the standard window background uses this to select a solid color
or bitmap drawable as appropriate.
Introduces a little hackery to have wm preview windows pretend like
they are hardware accelerated even if they aren't, so the preview looks
closer to the actual app.
Also Add a DialogWhenLarge variation for the light theme.
Change-Id: I215a79d5df65ba3eed52ab363cade9d8218a6588
/frameworks/base/core/java/android/view/IWindowManager.aidl
|
| b73617de462579f7c12c25a4c2747c576f00f6a2 |
|
17-Aug-2010 |
Daniel Sandler <dsandler@google.com> |
Rotation lock.
IWindowManager now supports two new methods,
freezeRotation() and thawRotation(), that allow a caller to
temporarily stash the device's current rotation as the
default rotation (when no other constraints are present).
The system bar uses this to implement a user-accessible
rotation lock by calling freezeRotation() and then turning
off accelerometer-based display rotation; unless overridden
by an app, the display will continue to appear in the frozen
rotation until the rotation is unlocked by the user (either
via the rotation lock icon in the system bar or by checking
"rotate screen automatically" in Settings).
Bug: 2949639
Change-Id: Icd21c169d1053719590e72401f229424b254622f
/frameworks/base/core/java/android/view/IWindowManager.aidl
|
| 8d60866e2100db70ecf0502c14768a384514d7e9 |
|
30-Aug-2010 |
Jeff Brown <jeffbrown@google.com> |
Input device calibration and capabilities.
Finished the input device capability API.
Added a mechanism for calibrating touch devices to obtain more
accurate information about the touch contact area.
Improved pointer location to show new coordinates and capabilities.
Optimized pointer location display and formatting to avoid allocating large
numbers of temporary objects. The GC churn was causing the application to
stutter very badly when more than a couple of fingers were down).
Added more diagnostics.
Change-Id: Ie25380278ed6f16c5b04cd9df848015850383498
/frameworks/base/core/java/android/view/IWindowManager.aidl
|
| a41ca77fabe1c7ad12ebb9b69b9e786c07d49fa0 |
|
11-Aug-2010 |
Jeff Brown <jeffbrown@google.com> |
Add support for the PointerLocation overlay.
This change involves adding a new method to IWindowManager,
monitorInput() that returns an InputChannel to receive a copy of all
input that is dispatched to applications. The caller must have
the READ_INPUT_STATE permission to make this request (similar to
other window manager methods such as getKeycodeState).
Change-Id: Icd14d810174a5b2928671ef16de73af88302aea0
/frameworks/base/core/java/android/view/IWindowManager.aidl
|
| 6ec402b5ae33c8927694d8522b4cc6a5c8ba974e |
|
29-Jul-2010 |
Jeff Brown <jeffbrown@google.com> |
DO NOT MERGE: Fix input event injection ANRs on UI thread.
Added a new asynchronous injection mode and made the existing
synchronization mechanism more robust.
Change-Id: Ia4aa04fd9b75ea2461a844c5b7933c831c1027e6
/frameworks/base/core/java/android/view/IWindowManager.aidl
|
| e36d6e277e49475076b7872d36ea6a5c5b996e9d |
|
18-Feb-2010 |
Dianne Hackborn <hackbod@google.com> |
Work on issue #2263557: PMF3000 showing hybrid of portrait and landscape modes
This is a bunch of reworking of how configuration changes are handled:
- When orientation is changing (for whatever reason), the window manager no
longer tries to pre-emptively compute a new configuration. Instead, it
just determines change is happening and tells the window manager.
- The activity manager is now responsible for giving the window manager the
final configuration it is using. This is both so it knows whem the
activity manager is done with its configuration updates, and so the window
manager can use the "real" configuration.
- When an orientation or other configuration change is happening, freeze the
screen and keep it frozen until the activity manager has given us the
final configuration.
- The window manager can now send new configurations to its clients during
its layout pass, as part of a resize, if it has determined that it has
changed. This allows for a new View.onConfigurationChanged() API for any
view to easily find out when the configuration has changed.
- ViewRoot now also works with the activity thread to make sure the process's
current resources are updated to the new configuration when it receives one
from a window. This ensures that at the time onConfigurationChanged() and
other view callbacks are happening, the correct configuration is in force.
- There is now a sequence number associated with Configuration, which
ActivityThread uses to avoid using stale configurations. This is needed now
that it can receive configurations asynchronously from both the window
manager and activity manager.
- The hack for keeping the locale has been removed, and underlying problem
fixed by having Configuration initialize its locale to "unknown" instead of
a valid default value.
/frameworks/base/core/java/android/view/IWindowManager.aidl
|
| 1d62ea9d8c2646d198b6967e2c6ae3dad5c18f9e |
|
17-Nov-2009 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #2249821: Unable to start passion in safe mode
Holding down the trackball now works.
Also fix a little API check warning from Intent.
Change-Id: Icb1f901535cb521917bf7f847a93c4ff7861d20e
/frameworks/base/core/java/android/view/IWindowManager.aidl
|
| 3b3e145d3c41fd68974e08f799b1fd1f8f060cf0 |
|
25-Sep-2009 |
Dianne Hackborn <hackbod@google.com> |
A variety of work on animations.
- The lock screen now fades in and out.
- Fixed a bug where we would accidentally freeze the screen when switching
to an activity with a different orientation than the current (but
the screen itself is in the current orientation). This would mess up
the animations on the car dock.
- New API to force a particular animation for an activity transition
(untested).
- New wallpaper animations.
- Resources now uses the next API version when in a development build,
to help applications being developed against such builds.
Change-Id: I2d9998f8400967ff09a04d693dc4ce55f0dbef5b
/frameworks/base/core/java/android/view/IWindowManager.aidl
|
| ffa424800d0338b8b894aef2ea1e3e3344cbda7a |
|
24-Sep-2009 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #2133206: dialogs/menus should auto-dismiss when screen turns off
Lot of infrastructure for more things to go away when "clear system dialogs"
happens, and now do this when we turn on the lock screen.
Change-Id: I567130296fe47ce82df065ed58ef21b37416ceaf
/frameworks/base/core/java/android/view/IWindowManager.aidl
|
| c8a0a75e1c61d1ab24bd46a8243041c107e738ac |
|
11-Aug-2009 |
Dianne Hackborn <hackbod@google.com> |
Implement support for scrolling a wallpaper.
This currently only works for a wallpaper that is larger than the
screen. Set the scroll position with the new wallpaper API. Right
now only does jump scrolls.
/frameworks/base/core/java/android/view/IWindowManager.aidl
|
| e4fbd6235c8d1c5b0ed4883ec275dd3fc9c919fb |
|
28-Mar-2009 |
Dianne Hackborn <> |
AI 143318: am: CL 143169 am: CL 142870 Fix issue #1724917 (Applications (browser, maps, gmail) fail to retain their landscape state after coming out of sleep mode). We now rely on the listeners last known orientation, and make sure to clear it when enabling/disabling.
Also do most of the work for issue #1732012 (Only show screen rotation animation when triggered by sensor). This just needs to be hooked up to the surface flinger API when that appears.
Original author: hackbod
Merged from: //branches/cupcake/...
Original author: android-build
Merged from: //branches/donutburger/...
Automated import of CL 143318
/frameworks/base/core/java/android/view/IWindowManager.aidl
|
| 105925376f8d0f6b318c9938c7b83ef7fef094da |
|
19-Mar-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //branches/cupcake_rel/...@140373
/frameworks/base/core/java/android/view/IWindowManager.aidl
|
| 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/IWindowManager.aidl
|
| 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/IWindowManager.aidl
|
| d24b8183b93e781080b2c16c487e60d51c12da31 |
|
11-Feb-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //branches/cupcake/...@130745
/frameworks/base/core/java/android/view/IWindowManager.aidl
|
| 9266c558bf1d21ff647525ff99f7dadbca417309 |
|
16-Jan-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //branches/cupcake/...@126645
/frameworks/base/core/java/android/view/IWindowManager.aidl
|
| f013e1afd1e68af5e3b868c26a653bbfb39538f8 |
|
18-Dec-2008 |
The Android Open Source Project <initial-contribution@android.com> |
Code drop from //branches/cupcake/...@124589
/frameworks/base/core/java/android/view/IWindowManager.aidl
|
| 54b6cfa9a9e5b861a9930af873580d6dc20f773c |
|
21-Oct-2008 |
The Android Open Source Project <initial-contribution@android.com> |
Initial Contribution
/frameworks/base/core/java/android/view/IWindowManager.aidl
|