This implements support for devices whose hardware can hide
their navigation keys. It works much like the existing keyboardHidden
configuration, and for compatibility uses the same configuration
change bit.
Also add FLAG_TURN_ON_SCREEN for windows, which has the system
cause the screen to be turned on when the window is displayed.
Great fun when used with FLAG_SHOW_WHEN_LOCKED!
Change-Id: I0b867f19af85cfd8786a14cea194b34f7bdd9b7a
This takes care of allowing us to cancel the back button. The
back button is a bear because it is strewn all over the place --
everywhere you can close something, there is some code looking
for the back button that now needs to deal with being canceled.
The main things changed are activity (of course), dialog,
input method, search dialog. There are some other misc places
in the framework (and some I missed here that I will get in a
second pass).
To facility all of this, the key dispatching APIs now provide
a lot more support for dealing with looking for cancelled keys,
and incidentally also provide an actual API for catching long
key presses. This also helped clean up the code in PhoneWindow
where it deals with all of the combinations of key pressed and
releases. (And also allows people to override
Activity.onKeyLongPress() to provide a different long press
action for a standard key like search.)
And while I was doing this, I reworked how we detect long
presses by having this be part of the key event delivered by
the window manager. This should greatly reduce (hopefully
outright eliminate) the problems with long presses being
mis-detected when an application is being slow.
Change-Id: Ia19066b8d588d573df3eee6d96e1c90fdc19f57d
First, fix some issues with the final wallpaper bitmap
we use: ensure it is always 16bpp, and make sure dithering
of its bitmap is turned off. We take of dithering
when loading, to make sure we don't use it when drawing.
Also add new APIs to return the wallpaper with the equivalent
of Launcher's old FastBitmapDrawable. As doing this, also load
the default wallpaper the same way as custom ones, taking care to
resize it as needed at load time.
Finally implement a mechanism for the window manager to wait
for the wallpaper to redraw at its new position before returning
from the application's call to change the offset. This ensures
that the wallpaper better tracks the application. Note that there
is a timeout in this wait that is relatively short, and if it
expires we will run for a while without waiting.
Change-Id: Ife449437746da85958bd447e0a6cf3d2223b398c
Remove the stuff that doesn't use preloaded drawables when in
compatibility mode, since this works fine ever since we were able
to deal with drawables in a different density than the canvas.
Change the snapshot function on View to return a snapshot at
the same size that will actually be drawn on screen (when in
compatibility mode), to be able to show scaling artifacts and
all.
This change was original an attempt to fix issue #2101917: Text
field edges appears to be improperly rounded. That turns out to
probably be something deeper in the graphics system, but also
included here is the debugging code I did to try to track down the
problem to make it easy to turn on again later.
Change-Id: I34bfca629639c7ff103f3989d88874112ef778d9
Actually being able to configure a wallpaper relies on additional
work in the launcher and wallpapers that will be in another change.
Also note that this breaks all existing wallpapers, since they now
need to include a meta-data item about themselves. This also
will be fixed in another change.
Change-Id: I97d2c2bd07237abc32f92b9147c32530a2f73c71
ViewRoot was using Surface.clear(), which has different behavior
in different processes -- in the system process it would kill the
surface, causing all windows in that process to immediately disappear
instead of animating away.
This change makes Surface.release() public and uses that instead. It
also renames Surface.clear() to Surface.destroy().
Also fixed some issues in the window manager that were causing the
wallpaper to not get immediately resized when the orientation changes
and its target window is removed and re-added.
Change-Id: I2a992e365cf5747511f0bf1193db32dc2525b218
This is work on the transitions with wallpapers. There are now new
animations specifically for leaving the wallpaper and returning to
it, which allow us to have a consistent animation when entering home
and returning to it. I also renamed the existing animations across
wallpapers, and cleaned up some junk in the various interpolators.
This also now hides the wallpaper surface when it is not visible,
to get rid of the wallpaper flickers people complained about albeit
in a somewhat brutal way. :) (Though really returning us to the
previous behavior with the same previous bugs and name back to them
not being very visible, yay!) There is are also some bug fixes
here and there about managing the wallpaper visibility that this
change revealed.
Change-Id: I913990a9a81651728122ed2e1101b75ed2c36fcb
- Reduce the amount that we ask processes to GC after a significant
operation occurs, but introducing a minimum time between GCs and
using this in various ways to schedule them.
- Don't spam all of the processes with onLowMemory(). Now deliver
these using the same gc facility, so we do the processes one at a
time, and don't allow the same process to get this call more than
once a minute.
- Increase the time a service must run before we will reset its
restart delay to 30 minutes (from 10).
- Increase the restart delay multiplication factor from 2 to 4.
- Ensure that we don't restart more than one service every 10 seconds
(unless some external event causes a service's process to be started
for some other reason of course).
- Increase the amount of time that a service must run before we
decide to lower it to a background process.
And some other things:
- Catch IllegalArgumentException in ViewRoot like we do for no
resources to avoid the system process crashing.
- Fix a number of places where we were missing breaks between the
activity manager's message dispatch func(!!).
- Fix reason printed for processes in the background.
- Print the list of processing waiting to GC.
The window manager now detects when a transition between two
wallpaper activities is happening, and switches to a new set
of animations for that. The animations I defined here are just
an arbitrary something that can work in this case.
The way View.post() is handled can cause potential leaks in ViewRoot. For instance,
if a View calls post(Runnable) just after being detached from the window (in an
onClickListener for instance,) it will enqueue a Runnable in ViewRoot.RunQueue.
Unfortunately the RunQueue is emptied only on the very first layout of the ViewRoot.
This change prevents the leak by rxecuting the enqueued Runnables on every layout request
The latter did not happen before and to keep views in a correct state I think it
is necessary to always ensure we run the Runnables sent via View.post().
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.
This is all of the basic pieces:
- The WallpaperService now creates a surface with the window manager for its
contents.
- There is a simple service that displays a bitmap.
- The wallpaper manager takes care of starting and stopping the service.
- The window manager knows about wallpaper windows and how to layer them with
the windows that want to be shown on top of wallpaper.
Lots and lots of issues remain, but at this point you can actually write a
wallpaper service, select it in the UI, and see it behind an activity.
The major things going on here:
- The MotionEvent API is now extended to included "pointer ID" information, for
applications to keep track of individual fingers as they move up and down.
PointerLocation has been updated to take advantage of this.
- The input system now has logic to generate MotionEvents with the new ID
information, synthesizing an identifier as new points are down and trying to
keep pointer ids consistent across events by looking at the distance between
the last and next set of pointers.
- We now support the new multitouch driver protocol, and will use that instead
of the old one if it is available. We do NOT use any finger id information
coming from the driver, but always synthesize pointer ids in user space.
(This is simply because we don't yet have a driver reporting this information
from which to base an implementation on.)
- Increase maximum number of fingers to 10. This code has only been used
with a driver that reports up to 2, so no idea how more will actually work.
- Oh and the input system can now detect and report physical DPAD devices.
Check the current enabled state before setting it, in case there's
no change. Otherwise some apps are repeatedly redrawing buttons based
on validation of some text field (like gmail or mms message bodies).
Should slightly improve the performance of soft keyboard text entry.
It turns out we were not returning the density for anything retrieved from a
TypedArray... which basically means any bitmap references from a layout or style...!!!
This is now fixed.
Also fiddle with the density compatibility mode to turn on smoothing in certain situations,
helping the look of things when they need to scale and we couldn't do the scaling at
load time.
