Fix for bug 8656899 API REVIEW:
android.util.PropertyValueModel/ValueModel,
android.widget.ValueEditor etc
Revert the change that added this API to remove it outright.
This reverts commit 989709a973
Change-Id: I9018cd8dadb1b1a54ad8749c816bd02bb7e7a38b
It seems some applications rely on Looper.quit() terminating the
loop immediately without processing all messages. Rather than
risk breaking them, make the safer behavior optional.
Also take care to properly drain the message queue before quitting
so that all of the Message instances are recycled. This may
help release storage sooner in case the Looper doesn't get GC'd
promptly and its remaining queue of undelivered messages sticks
around.
Improve docs on runWithScissors.
Bug: 8596303
Change-Id: I8cbeb6f7a5f6b8e618b5109f87a03defc1486b9f
- in RTL mode only and if you have left/start or right/end at the same time,
the initial left/right padding (coming from the background drawable or from
some explicit definition) was still used.
- now, override the background left/right initial pading by the left/right one
only and only if there is no start/end padding defined at the same time
(because when start/end are defined, we do not care about left/right padding
except the background ones)
Change-Id: Icc6e69c95ace1307b0c5e9673cbdf3b611b62733
Accessibility services can perform special operations such as retrieve
the screen content, enable explore by touch, etc. To ensure the user
is aware that the service will perform special operations we were using
permissions. However, the special operations cannot be performed unless
the service is really enabled by the user and it is at this point that
we want to notify the user about the service capabilities.
This change adds capability attributes to the accessibility service's
meta-data XML file. The service has to declare the capability and when
it is enabled we show the user the capabilities in the warining dialog.
bug:8633951
Change-Id: Id3442dc71dad018e606888afdc40834682fdb037
This checkin has preliminary API (in flux, definitely changes still
to be made) and implementation for a new "Scenes & Transitions" feature.
The current implementation allows you to define different Scenes
(via layout resource IDs or callbacks) and Transitions to be used when
changing to those scenes. By default, scene changes will use AutoTransition,
which generally does the right thing.
There are no overview docs or tutorials yet. The best way to learn how things
work is to see the code for the various tests in
frameworks/base/tests/TransitionTests.
Expect the API to change. Expect the implementation to change (mostly to add
more functionality). Expect bugs, but tell me if things do not work
as expected.
Change-Id: Ib025a9f565678b225afa4759325cf6d496cc7215
Fix a few typos in InputFilter. Fix reference in InputEvent currently
causing public documentation breakage.
Change-Id: I6268ad165f11d4d9d5a4a66ed97f1538e174cf84
b/8631678
1.GeofenceRequest object created.
2.MonitorState moved to a new callback
3.getTypeAndStatus separated to 2 calls.
4.Binder death implemented
5.geofenceChange callback name changed.
6.Parameters rearranged in some calls.
Change-Id: I8fe9621186aeb49efeb0eef1821a2556afe03cfc
