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.
The platform now knows how to deal with a platform key, which at this
point is "just like end call, but don't end a call."
Also improve the handling of virtual keys, to allow for canceling when
sliding off into the display and providing haptic feedback.
Finally fixes a bug where the raw x and y in motion event were not
always set which caused the status bar to not work.
Merge commit '11ea33471e1a14a8594f0b2cd012d86340dd3bd8'
* commit '11ea33471e1a14a8594f0b2cd012d86340dd3bd8':
Allow for screen density drawables in compatibility mode.
This change allows us to use drawables that match the current screen
density even when being loaded in compatibility mode. In this case,
the bitmap is loaded in the screen density, and the bitmap and
nine-patch drawables take care of accounting for the density difference.
This should be safe for existing applications, for the most part, since
they shouldn't really be pulling the bitmap out of the drawable. For
the small rare chance of them breaking, it worth getting the correct
graphics. Also this will only happen when there is actually a resource
of the matching density, and no existing apps should have resources for
anything besides the default density (though of course all of the
framework resources will be available in the native density).
As part of this, the bitmap density API has been changed to a single
integer provider the DPI unit density.
Merge commit '589cebe2d58591403de4a77077941c0454bc91bc'
* commit '589cebe2d58591403de4a77077941c0454bc91bc':
* Use the scaled size for surface view instead of native. The surface will be always scaled
Merge commit 'e0ef973b1358585d039989ee5572e16751078aaf'
* commit 'e0ef973b1358585d039989ee5572e16751078aaf':
* a best effort fix for apps that uses get/set Matrix API on canvas.
by surface flinger in compatiblity mode. The original approach confused the app because
the surface size and the view size were different.
* a few clean up. removed unsed arguments, obsolete conditions from getTranslator()
(expandable check was a bug)
- scale the matrix
- but don't scale if the matrix *looks* like obtained from the canvas itself. (typically to set it back to original matrix)
This is best effort change and not perfect (not even close), but works for one game,
and hopes it can handle many other apps that uses set/get Matrix. If you have an alternative idea, please let me know.
Merge commit '98a44df4b4cc8cd28276ad888a7e17f81353ae44'
* commit '98a44df4b4cc8cd28276ad888a7e17f81353ae44':
* Revert the change that I introduced while refactroing in SurfaceView#dispatchTouchEvent
The MotionEvent API should be fairly solid, but there is still a lot of
work to do in the input device code. In particular, right now we are
really stupid about watching how fingers change -- we just take whatever
the driver reports as down and dump that directly into the motion event.
The big remaning work is to assign pointer IDs so that applications have
help in determine which fingers go up and down, and adding support for
the official multi-touch driver protocol.
Merge commit '841f13c8e9ff3f7695b6c18a8abcec3c947983ff'
* commit '841f13c8e9ff3f7695b6c18a8abcec3c947983ff':
* Reverted the change in PackageParser that I checked by accident
* More surface view fix.
- correct event translation on surface view.
- use compatible window
* removed FLAG_NO_COMPATIBILITY_SCALE. It was my misunderstanding of how SurfaceView works, and this was not necessary.
* Added compatibility related info to package dumpsys
Merge commit '54f09101381fa63dca35ae4ea0ba3802ee863236'
* commit '54f09101381fa63dca35ae4ea0ba3802ee863236':
* Use Fede In/Out animation if one of opening/closing apps is in compatibility mode.
* preserve compatibility window flag when the app updates window's layout params.
* Added assertion in DEFAULT_COMPATIBILITY_INFO object to prevent unintentional modification.
* A few minor updates
* log/dump message improvement
* Removed unnecessary method in FadeInOutAnimator
* Fixed 100 char issue in WindwoManagerServer.java
ViewRoot keeps a reference to the previously focused View and use this reference
when trying to scroll the window to the focused rect. There situations however
in which the previously focused view might have been removed from the view
hierarchy. This happens on Home for instance when you trash an icon, or with
ListView's items. This change ensures the previously focused view is still part
of the view hierarchy.
