Allow ViewPropertyAnimator animations to be started immediately, canceled,
and to have an optional startDelay. This is functionality parallel to that
in the base Animator class.
Change-Id: I391f1810bf697656999bd6e3e63a59e46eb7eb8a
This change compensates for changes in the parent hierarchy of
transitioning views. It automatically animates parents with the same
animations as those used for the CHANGING animations run on the container
children.
Change-Id: I86471d16a9070b024cc09c8f6e0f504a881fa99f
Added support for Linux multitouch protocol B (slots).
Added support for using the device's input properties as a hint
to determine the intended usage of a touch device.
Added support for the ABS_MT_DISTANCE axis.
Fixed a bug reporting the presence of the orientation axis.
Change-Id: Icf7b5a5a0f1a9cdf6ad2b35be8ea0c1a35815d48
If a view is not accelerated but has its layer type set to
LAYER_TYPE_HARDWARE, then the framework will use the old drawing cache
approach, to cache it in a bitmap. This works fine, but when the layer
is set to NONE, that drawing cache is not destroyed, as it would be were
the layer set to LAYER_TYPE_SOFTWARE. This prevents future invalidations on
the view from working correctly because the bitmap cache has never been
destroyed and recreated.
The fix is to always destroy the drawing cache when the layer type is
changed from SOFTWARE or HARDWARE, to make sure that it gets set appropriately
regardless of the state of the view's acceleration.
Change-Id: I449649e6d370477825015505da76564455a156e6
* commit '1d340a3c24913d8750900355cd92ef5742eea11f':
DO NOT MERGE. From main -- Start work on simulating landscape/portrait when orientation is locked.
* commit '0eac092766d7871b34927442ee0b6e27e7e1317b':
DO NOT MERGE. From main -- Start work on simulating landscape/portrait when orientation is locked.
Not yet working, so turned off.
Also fix a bug where the display size configuration became inconsistent
after a configuration change -- we now figure out everything about the
display size when computing a new configuration.
Change-Id: Id155f133c0bf108508a225ef64ed3ca398a90a58
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
1. Accessibility events were filled with data in
dispatchPopulateAccessibilityEvent and
onPopulateAccessibilityEvent. These events have
two axis of population 1) up the class
hierarchy to populate information for the event
source; 2) down the view hierarchy to populated
all the text contained in the source including
its descendants. These two axis of population
were done in on population pass now the populating
the source properties happens in initializeAccessiblityEvent
and the text in onPopulateAccessibilityEvent which
is called from dispatchPopulateAccessiblityEvent.
2. Removed the string description from events fired from
CompoundButton since the event has isChecked()
property and it is responsibility of the clients
to decide what utterrance to use and if to use such
for announcing the checked state.
Change-Id: I5d7f75cf8a87a7a4b3bb7b311e8e642ec9a0faa5
Added the concept of pointer properties in a MotionEvent.
This is currently used to track the pointer tool type to enable
applications to distinguish finger touches from a stylus.
Button states are also reported to application as part of touch events.
There are no new actions for detecting changes in button states.
The application should instead query the button state from the
MotionEvent and take appropriate action as needed.
A good time to check the button state is on ACTION_DOWN.
As a side-effect, applications that do not support multiple buttons
will treat primary, secondary and tertiary buttons identically
for all touch events.
The back button on the mouse is mapped to KEYCODE_BACK
and the forward button is mapped to KEYCODE_FORWARD.
Added basic plumbing for the secondary mouse button to invoke
the context menu, particularly in lists.
Added clamp and split methods on MotionEvent to take care of
common filtering operations so we don't have them scattered
in multiple places across the framework.
Bug: 4260011
Change-Id: Ie992b4d4e00c8f2e76b961da0a902145b27f6d83
First step of improving app screen size compatibility mode. When
running in compat mode, an application's windows are scaled up on
the screen rather than being small with 1:1 pixels.
Currently we scale the application to fill the entire screen, so
don't use an even pixel scaling. Though this may have some
negative impact on the appearance (it looks okay to me), it has a
big benefit of allowing us to now treat these apps as normal
full-screens apps and do the normal transition animations as you
move in and out and around in them.
This introduces fun stuff in the input system to take care of
modifying pointer coordinates to account for the app window
surface scaling. The input dispatcher is told about the scale
that is being applied to each window and, when there is one,
adjusts pointer events appropriately as they are being sent
to the transport.
Also modified is CompatibilityInfo, which has been greatly
simplified to not be so insane and incomprehendible. It is
now simple -- when constructed it determines if the given app
is compatible with the current screen size and density, and
that is that.
There are new APIs on ActivityManagerService to put applications
that we would traditionally consider compatible with larger screens
in compatibility mode. This is the start of a facility to have
a UI affordance for a user to switch apps in and out of
compatibility.
To test switching of modes, there is a new variation of the "am"
command to do this: am screen-compat [on|off] [package]
This mode switching has the fundamentals of restarting activities
when it is changed, though the state still needs to be persisted
and the overall mode switch cleaned up.
For the few small apps I have tested, things mostly seem to be
working well. I know of one problem with the text selection
handles being drawn at the wrong position because at some point
the window offset is being scaled incorrectly. There are
probably other similar issues around the interaction between
two windows because the different window coordinate spaces are
done in a hacky way instead of being formally integrated into
the window manager layout process.
Change-Id: Ie038e3746b448135117bd860859d74e360938557
