This call should be analogous to calling
setHomeActionContentDescription(null) and not throw an exception.
Bug 8657256
Change-Id: Ifa9c7b999f4bf1a31fba43f869e234b1f1861512
bug:8649215
Previously we prevented ops with non-translate transforms from
merging, but missed the case of the first op in a merging batch
containing a non-translate transform.
This fulfills the assumption of drawText's non-immediate mode that
merged ops will have pure translate transforms.
Change-Id: I6f6db341aff3f7e84e74b4c3ccf970d585a2db1a
This is a regression in which the input filter of the accessibility
manager service is not set if magnification is enabled but accessibility
is not - i.e. no accessibility serivces are enabled. Fixed the logic to
install the input filter if magnification is on but services are not
enabled in addition to services being enabled.
bug:8652765
Change-Id: Ia73e1064035f95ba0f246f4cabcc42d58c12a11f
When something that affects the state of accessibility in the sysytem
changes, we run a reolve method that reloads all relevant information and
if it changed we call a method that makes everyting right. One of the
interesting properties we read is the isntalled accessibliity services.
We are using equals to figure out whether these services have changed
but this is not correct since AccessibilityServiceInfo does not use all
internal members for equals and using all memthis is not reasible since
some of these internal members do not support equals propertly, for
example ResolveInfo.
Therefore, when a package is reinstalled we remove all installed services
from the list of ones we know about which forces them to be reloaded,
thus capturing the current state of a reinstalled package.
bug:8621960
Change-Id: Ie1ef4bf1036d8d6e033cd9528ea2292ce24e5320
Right now this only works if you go through the front door
(using setNotificationsEnabledForPackage()); if you set the
AppOps for a package otherwise the existing notifications
will not be cleared (but new ones will be blocked). Since
there's no UI for modifying AppOps today this shouldn't be a
problem.
Bug: 8489214
Change-Id: I84f8c76a0d03959127e9076ab2b7d37dbdaebb17
While it's still not generally appropriate for the home key
to do anything other than take you home, a car is a somewhat
different context: because of the user's reduced ability to
interact with the device, it's especially useful to
temporarily replace the launcher with a car-optimized
variant. While it would be ideal for the entire system
(particularly the user's everyday Launcher) to dynamically
reconfigure their UIs upon entering car mode, it's not the
case today, and car home apps are a useful compromise.
Quick test:
$ adb shell am broadcast \
-a android.intent.action.DOCK_EVENT \
--ei android.intent.extra.DOCK_STATE 2
This reverts commit 7c135205f2f4c192299ad0215276e9e481bccaa5.
Bug: 8234767
Change-Id: I17588fff46e7f5e3773d3ad202601a5642943444
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
