Age | Commit message (Collapse) | Author |
|
Move all of the pieces into a new com.android.server.wm package.
Change-Id: I942b7bcfb84ee0f843f47d58e55ffc5a93c0da94
|
|
@hides the View constant that designates a drag as cross-app, and also
forcibly ignores that flag on the system_server side even if it's passed
to startDrag() as a literal.
Change-Id: I6f321bdf0389db5bb44131fd0f8d6b92f049be52
|
|
race condition."
* commit '432ab6ac04f22a5e4c15aece04117b35bbf8869c':
Fixing possible race condition.
|
|
observed during an attempted..." into honeycomb
* commit '60a746426c62bf03b3b5fb494a9cddb9b1ae5166':
Fix issue #3414328: A couple panics observed during an attempted...
|
|
into honeycomb
* commit '94baff47975fb3ae1380333f23fc2de2dc65eb86':
Fix issue #3420898: More wallpaper issues
|
|
* commit '6b497a0446ebad24305d5e29d5fd5e65014b9778':
Fixing possible race condition.
|
|
* commit 'bb2e1ef87fe4c5123340035766c759155e6bb90c':
Fixing possible race condition.
|
|
|
|
Since there is no support for hardware GLES acceleration under
emulation, we disable the screen rotation animation when we detect
that we are in the emulator.
Note that ideally, we should only disable it when we detect that
GLES is implemented in software. However, I don't think there is
an easy way to test for this inside of the WindowManagerService.
Change-Id: Ic17719f7d0b14640bacb3b33b7b1a196006982ee
|
|
...pairing to IHF1700 - IKXEVEREST-3627
Change-Id: I3d5b42d65a03ed19b8460c607ff5de862bccb4e6
|
|
wallpaper is broken" into honeycomb
* commit 'dd95421291f590ec0b1d8e79b73264516e1da027':
Fix issue #3418265: Rotation animation on wallpaper is broken
|
|
- The ImageWallpaper wasn't watching for the desired dimensions to
change, at which point it needs to resize its surface.
- The system process has been running with the small dalvik heap
limit, which is too tight with these huge wallpapers; this would
cause switching wallpapers to eventually stop working as it
couldn't get the memory it needed to load the new one.
- The compatibility mode background surface had a bunch of issues,
such as moving its windows to the right by the window size to
make them disappear. This of course doesn't play well with the
now super-sized wallpaper surface. This code is re-worked to
not require such shenanigans.
Change-Id: I64fde4059645d8507f1c4761ba6c17b89877a5c0
|
|
Two problems:
1. The wallpaper offsets were being applied at the wrong place in the xform.
2. The background black needs become a clip around the newly revealed UI.
Change-Id: I3b46aea2ace3c8c5a36fc5e37b4e2b67fff1b289
|
|
breaks thumbnails." into honeycomb
* commit 'e40afdf7f44f30d78b0afc96717dae2bb883e3ea':
Fix issue #3415137: New wallpaper size breaks thumbnails.
|
|
Change-Id: I3ce4fa8f532cc378c390138bab0ff3126fe0f0c3
|
|
* commit 'a70154b0187603af3487bbe01b607818b12cc268':
Fix keyboard hidden flag.
|
|
That return statement is effectively a reading of asynchronously modified
field. The reading and writing is elsewhere protected by locking on thread
instance, except this one occurence. Moving 'return' statement into
synchronized block ensures that it reads updated value.
Don't be afraid of deadlock - wait() releases the lock and acquires it
back when notified.
Change-Id: I940c24c04a1a2d4508d14d11b6174ff4fb2ab7d5
|
|
Configuration.hardKeyboardHidden should be set to
HARDKEYBOARDHIDDEN_YES when no keyboard is present or when it is
disabled. The code in PhoneWindowManager.adjustConfigurationLw
does the right thing. It also takes care of setting keyboardHidden
correctly when only a soft keyboard is available.
So it turns out that all we need to do to disable the hard keyboard
is to set Configuration.keyboard to KEYBOARD_NOKEYS *before* asking
the policy to adjust the configuration.
Bug: 3406101
Change-Id: I3519d02af30d8068198cb3d6b8fdde601c2fe8b4
|
|
system UI properties." into honeycomb
* commit '75057b1507881625368f76b2f401097b606bd530':
Check for the STATUS_BAR permission for the system UI properties.
|
|
If the app doesn't have that permission, just mask out the bits.
Also makes the systemUiVisibility field visible in hierarchyviewer.
Change-Id: Ic3d3a3aed96b5c6448832755b4b2e6175117e5be
|
|
Change-Id: I49117966f43080d86763bab51848dbc50e55ecf8
|
|
honeycomb
|
|
* commit 'bdaee964f7d00806e714a7e453fff8d6a408c692':
Fix screen size compatibility mode.
|
|
Change-Id: I2c06bbb586b4e54fc7ec52ec914cf95a18006217
|
|
gingerbread
* commit 'c12cdda949e6b916dd9e6fa4b30ab8b0d1898faa':
DO NOT MERGE: Fix screen size compatibility mode.
|
|
Cherry-picked from HC.
Change-Id: Icce2a64f187a56deefcddc3d9b22fa94effce431
|
|
Bug: 3391067
Change-Id: I136087ca4f726d0068d5983d7d3686787ba60c55
|
|
|
|
Also adds a new flag constant, View.DRAG_FLAG_GLOBAL, which indicates that
the drag operation should be allowed to propagate the drag outside the
originating app. When this flag is specified, all visible windows will
be notified about the ongoing drag.
Bug 3322724
Change-Id: Iaa3412a97f83f4e763019c9a03b5f09ebf75453f
|
|
The framework had started using the LayoutInflator's factory
for itself, which breaks apps that want to use it. Add a hack for
the framework to insert its own private factory.
Also fix a deadlock in the system process.
Change-Id: Iaf80186a5d7e4029faf89e968e184abdaabe514a
|
|
...gallery while attaching picture to gmail message
In various places we could block switching the IME target incorrectly.
Change-Id: I7e647fb35f4ea6f2e39eb7efd911420ea9ee64fa
|
|
When task switching while dialog windows were up, the exit animation
wouldn't be seen. The animation needs to force Z-order its windows
to the top.
Also fix a bug where the lock screen fade-out was immediately
Z-ordering the wallpaper to the bottom if the activity behind was
not on top of the wallpaper.
Change-Id: Icd45cd8ccfff9829822c1682931413246eb9601b
|
|
Change-Id: I24d58a02f69ae40f03b133d487354a883585e93e
|
|
|
|
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
|
|
And also fix #3343369: EGL_BAD_DISPLAY and/or broadcast intent
TIME_SET before boot completion
And a few more tweaks to animations to keep the wallpaper displayed
when needed.
And make more use of the drag and drop "rotation disabled" thing to
also use it while animating the screen rotation, since if we try to
start a new rotation while doing the animation we end up with a mess.
Change-Id: I373af305a6e23a92835abed96229a83e173f67ce
|
|
|
|
Fixed a bug in WindowManagerService where it would set mSurfaceResized
to true even if the surface was just moved and not resized. As a result,
we would send dozens of spurious resize messages to all applications
during orientation changes since the rotation animation changes the
positions of surfaces as they swing into place. Among other things,
the spurious resizes caused the wallpaper to be redrawn dozens of time.
Change-Id: I2be7278c0d6a00aaef665a65e268d8da1771e51f
|
|
The activity manager was not performing the layout pass on the new window,
because its app token was still hidden, because the activity manager / window
manager were still waiting for it to be ready to show.
Just ignore whether the app token is hidden for this case.
Also fixes some problems with animations, and tweaks the ViewConfiguration
values for xlarge screens.
Change-Id: Icbe9c77ba8127d1e02df2d6f27b8e86ec842e50a
|
|
|
|
Change-Id: Ida9069dd58be2070f3c9d312aa9d868bd98eb8e2
|
|
Having it non-touchable was making it possible to e.g.
touch buttons and launch new activities out from under
an in-flight drag operation.
Bug 3370698
Change-Id: I46fe70a8fe8fbaa5cca48f6bb478ed7ded1f1cc3
|
|
In particular, if a new window was created out from under the drag,
the drag-move event dispatch logic would wind up blithly assuming
that it would find a valid touch-dispatchable window under the
finger. When this was untrue, it would NPE, but the NPE was caught
and discarded safely by higher-level guard code.
With this change, we now avoid the NPE entirely and report the
spurious condition as part of the debugging log stream.
(Also add the local-state object to DragEvent.toString()'s output.)
Change-Id: Idfa5f45d049e48415ee59c8b0ffb5b0ed4098ce3
|
|
1. ViewGroups being removed from the layout during a drag would wind up
crashing the app with an NPE at drag-ended time, due to blind dereference
of now-cleared object pointers.
2. Passing a 'null' ClipData to startDrag() would crash the system
process with an NPE. Should this even be valid? I'm inclined to say
yes, though it means that apps will need to guard against it.
Fixes bug 3369542
Change-Id: I168fc1284d6fd4403999946609725414cf254df0
|
|
The phone-oriented code for turning off animations when the screen is entirely
covered by the status bar was not appropriate for the tablet.
Change-Id: Ica3e0db989f16b9187eacd6ecf4ac3d17661dd6d
|
|
This enables the system bar to carve out a region through which
events will be sent to the IME behind it.
Bug: 3238092
Change-Id: I69b855a8d9b5b3ee525266c0861826e53e5b5028
|
|
|
|
Fixed a race condition during startup. We need to wait for the input
devices to actually be ready before trying to detect safe mode.
Fixed a problem during safe mode activation where we would try to add
the overlay window but the display was not initialized. Now we do it
after the system is ready.
Bug: 3134825
Change-Id: I4c043c142ae6bf0d865c79d266d36154eaf00709
|
|
|
|
...when the device's physical orientation is portrait.
We now hold off on computing app token orientation while preparing
to open or close app tokens.
Also clean up a few other little issues.
Change-Id: Iae125a975c7706fb4d068c872fd172e69854ff15
|