Also fix a build.
And fix a bug that I think was introduced in the multi-user work
that removed the permission check for writing to settings...!
Change-Id: I5945682faa789ffc78fd3546c0df7d03693f106d
We use an input filter to manipulate the event stream in accessibility
mode. Some input events, i.e. touch and hover events, are delivered
to a touch explorer, if touch exploration is enabled, and to a magnifier,
if screen magnification is enabled. It is possible that at the moment
each of these features is enabled we are in the middle of a touch or
hover gesture. The touch explorer and screen magnifier expect to receive
an event stream that starts with an event that denotes the stream start.
This change ensures that hover or touch events are dispatched to the
touch explorer and the magnifier only after the start of the first
well-formed hover or touch sequence.
Change-Id: I8cd0ad8e1844c59fd55cf1dfacfb79af6a8916df
Instead of hardcoding true/false in the code:
setprop log.LocationManagerService DEBUG
works just fine. Or the reboot-proof version in userdebug/eng builds:
cat > /data/local.prop <<eof
log.tag.LocationManagerService=DEBUG
eof
Change-Id: If4efad1c3adc401c0cb5d1a3cc449b53224ead08
This changelist revises LocationManager's previous multiuser system.
Location provider services that are not multiuser-aware continue to
run as before: ServiceWatcher binds to location provider services as
the current active user. When the device switches from one user to
another, ServiceWatcher unbinds from the old user's location provider
service and binds to the new user's instance.
Now, location provider services that are multiuser-aware or
user-agnostic can declare "serviceIsMultiuser" metadata in their
AndroidManifest.xml to prevent ServiceWatcher from performing this
switching. These services will run as singleton services and will be
expected to handle user switches on their own.
With this feature in, I was able to switch FusedLocationProvider to
run in multiuser mode, sharing the system_server process instead of
running in its own process. The NetworkLocationProvider is unchanged,
still running in singleuser mode, cheerfully oblivious to the
possibility that there might be any user on the device besides the
one it services.
Bug: 8028045
Change-Id: I1a5bd032918419bab6edb46c62ff8c6811170654
Improve handling of vibration op, so that apps are
better blamed (there is now a hidden vibrator API that
supplies the app to blame, and the system now uses this
when vibrating on behalf of an app).
Add operation for retrieving neighboring cell information.
Add a new op for calling a phone number. This required
plumbing information about the launching package name through
the activity manager, which required changing the internal
startActivity class, which required hitting a ton of code that
uses those internal APIs.
Change-Id: I3f8015634fdb296558f07fe654fb8d53e5c94d07
Currently text editing is pretty hard (certain operations even
impossible) for a blind person. To address the issue this change
adds APIs that enable an accessibility service to perform basic
text editing operations such as copy, paste, cut, set selection,
extend selection while moving at a given granularity.
The new APIs enable an accessibility service to expose a gesture
driven efficient text editing facility.
bug:8098384
Change-Id: I82b200138a3fdf4c0c316b774fc08a096ced29d0
Also add a hook for ConfigUpdateInstallReciever subclasses to
change the delivery of data- in this case, from raw text to
b64 encoded binary.
Change-Id: I4859c8db1cc97c2427310a108b2fef03975df2b4
The file that defines default preferred apps is now more
robust. It is no longer a raw dump of the package
manager settings, but instead a more general list of a
target activity and filter. When reading it, the remaining
information (match value, set of potential matches) is
determined dynamically.
Change-Id: I0edc6e0d2ed3dd2a6e2238992f18f7fc1f51d8d4
Currently we have an "enhance web accessibility" setting that has to be
enabled to make sure web content is accessible. We added the setting to
get user consent because we are injecting JavaScript-based screen-reader
pulled from the Google infrastructure. However, many users do not know
that and (as expected) do not read the user documentation, resulting in
critique for lacking accessibility support in WebViews with JavaScript
enabled (Browser, Gmail, etc).
To smoothen the user experience now "enhance web accessibility" is a
feature an accessibility plug-in can request, similarly to explore by
touch. Now a user does not need to know that she has to explicitly
enable the setting and web accessibility will work out-of-the-box.
Before we were showing a dialog when a plug-in tries to put the device
in a touch exploration mode. However, now that we have one more feature
a plug-in can request, showing two dialogs (assume a plug-in wants both
features) will mean that a user should potentially deal with three
dialogs, one for enabling the service, and one for each feature. We
could merge the dialogs but still the user has to poke two dialogs.
It seems that the permission mechanism is a perfect fit for getting
user permission for an app to do something, in this case to enable
an accessibility feature. We need a separate permission for explore
by touch and enhance web accessibility since the former changes the
interaction model and the latter injects JavaScript in web pages. It
is critical to get user consent for the script injection part so we
need a well-documented permission rather a vague umbrella permission
for poking accessibility features. To allow better grouping of the
accessibility permissions this patch adds a permission group as well.
bug:8089372
Change-Id: Ic125514c34f191aea0416a469e4b3481ab3200b9
This is called from Settings that has a button to clear secure
adb public keys installed on the device.
Change-Id: I63ef499c049766ef13ea6cb0594ed6719f35e5f3
A previous change to avoid losing activities if their process
happens to be gone at the point of launch (by counting that
activity as having its state saved) has resulted in a problem
where an activity that crashes during launch will be repeatedly
relaunched.
This is fixed here by explicitly keeping track of our attempts
to launch the activity since it was last able to save its state,
and not keeping it around if it looks like the launch is
repeatedly failing.
Change-Id: Icefd952443b7eb1222f233db95e0157fc3dd72d1
Also add new ops for calendar and wi-fi scans, finish
implementing rejection of content provider calls, fix
issues with rejecting location calls, fix bug in the
new pm call to retrieve apps with permissions.
Change-Id: I29d9f8600bfbbf6561abf6d491907e2bbf6af417
Fix the issue where GpsLocationProvider.isEnabled() returns true when it
is really false (and the other way around), when the handler hasn't
processed the enable/disable messages yet.
This can be systematically reproduced when the caller code is using the
same thread as the thread of the handler in GpsLocationProvider.
For example, this was happening in LocationManagerService.switchUser().
It would start by disabling all the providers (with
updateProviderListenersLocked()), then re-enable them in
updateProvidersLocked() only when isEnalbed()==false, which was in the
wrong state since the GpsLocationProvider.ENABLE message hadn't been
processed yet. As a result, the GpsLocationProvider was disabled upon
startup of the phone.
This is a slight problem for the enable() contract, which specifies that
getStatus() must be handled, getStatus() will be handled but might have
slighty not-up-to-date info in this case.
Bug: 8028017
Change-Id: Iff91a11cc150e9029a6db85b64a10a926e12b0ba
When launching an assist, we have a new API allowing the
current foreground activity/application to provide additional
arbitrary contextual information that is stuffed in the
assist intent before it is launched.
Change-Id: I0b2a6f5a266dc42cc0175327fa76774f814af3b4
...of Play Store is included
The issue is that the name of the play store apk on the system
image has changed, and the package manager has a bug when this
happens and it is being hidden by an updated version of the
application that is still a newer version. In this case it
doesn't do the normal scan of the system apk, but just leaves
its old disabled state. However if the code path has changed,
this will trip up other code that thinks the system apk has
disappeared (since when it checks for the existence of the apk
with the stored code path, it doesn't find anything).
The fix here is to add a special case to make sure the code
path is updated even if we are otherwise ignoring the hidden
system image package data.
Change-Id: Ic5118f94c078da7a30b53b9cadf7c9844f7ba866
