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 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
When user reset password their password,
if password doesn't match target quality of device,
DPM print a log why can't reset password.
however log message isn't correct information.
in log context, it have to exist current quality
and target quality. this patch can help print correct log.
Change-Id: I5c8fb1c77ddbe1bdbc76e35038c897e2e8efb077
Use a Bundle for persisting and passing to the application, but use a
list to return data back from an application that's exposing restrictions.
Changed the xml reading/writing code to store the value type in the Bundle
so that it can be reproduced when reading. Earlier we were assuming only
String and String[].
Bug: 8633967
Change-Id: I523d5553728edcf28a1e9d432f490b4956f34215
We're missing some (small fraction of) native crash reports from
debuggerd. It looks like under high system load the debuggerd
reporting code just isn't quite timely enough for the very short
timeouts initially deployed, so lengthen those a bit.
Bug 8552010
Change-Id: Icbc5b6517de3bb98fff1af2ea42ffd208ef20412
For the purposes of deciding whether or not to invoke the
"fallback vibrate", that is. (RingtonePicker will return
content://settings/system/notification_sound when "Default"
is chosen, so if the app pops this Uri directly into
Notification.sound, we should treat it like DEFAULT_SOUND
and look to see whether the system notification sound is
not None before running the fallback vibration.)
Bug: 8627641
Change-Id: Ia469b8e4d5d7647ce1a8a179f591ed7a3443b5c5
- Max 250 notifications preserved (was 1000)
- Known heavyweight extras are removed
- print some of 'em out in dumpstate, while we're at it
Bug: 8280039
Bug: 8537938
Change-Id: I9239128c32a1d9f5ef4e0dc62dc2d23e190871e9
* commit 'feedb1b095f94e4bd153aeee78da07d963892071':
Fix security issues with LocationManager where apps with coarse permissions can get location updates too frequently by repeatedly calling getLastKnownLocation or by registering/unregistering location updates frequently.
It is possible that an accessibility service's package was force stopped
during whose handling the death recipient is unlinked and still get a call
on binderDied since the call was made before we unlink but was waiting on
the lock we held during the force stop handling. Added a check whether the
service is already disconnected and if so do nothing.
bug:8600388
Change-Id: I4a9ca305b9863d986b930a7c1ec8f9006b16a333
