# By Jorge Ruesga
# Via Android Git Automerger (2) and others
* commit 'fb2b5e04a02669c764e4ebd7a6daf9846d596435':
DateView: Use Intent.ACTION_LOCALE_CHANGED to refresh notification bar clock
# By Jorge Ruesga
# Via Gerrit Code Review (1) and Jorge Ruesga (1)
* commit '1a1e9b317ac2d737ad92a35c4d806f0fda1ede70':
DateView: Use Intent.ACTION_LOCALE_CHANGED to refresh notification bar clock
# By Yevgen Pronenko
# Via Android Git Automerger (2) and others
* commit '3c239d7e8d78570b1e17ad968c408506e73a8f3f':
Disable usage of WAL in DatabaseHelper
# By Yevgen Pronenko
# Via Gerrit Code Review (1) and Johan Redestig (1)
* commit '88ba2f48a2d1193f3877575b2589897a7804aa75':
Disable usage of WAL in DatabaseHelper
insertForUser takes a specified user and attempts to adjust that user's
settings, first looking at their existing settings to determine the difference.
However it was querying the settings for the calling user, rather than for
the user whose settings were being changed.
Also add a test that exercises the fix.
Change-Id: I6ed6fd79154ac1b6e6ab880769ac9081dfff6b80
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
# Via Android (Google) Code Review (1) and Daniel Sandler (1)
* commit 'fc12f1e37bfa0f9240ed5f6af999a9fbba507fb0':
Log messages to debug stuck status bars.
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
# Via Android (Google) Code Review (1) and Svetoslav (1)
* commit 'ec695824af7ab263eaae613b87f2c0b24f176f91':
Remove "enhance web scripts" from settings and make it requested by plug-ins.
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
Bug #8066455
ViewRootImpl was properly detecting that the renderer was not
ready to draw but would simply schedule another frame, thus sending
the systemui into an inifite redraw loop. This change reinitializes
the renderer if needed (if the renderer is requested but not enabled.)
This CL also fixes an issue caused by the default wallpaper. Since it
never calls eglTerminate(), managed contexts are never reclaimed.
Change-Id: Idb8caa672be8ee35f6e6a7e942d9abd8aa100967
# Via Android (Google) Code Review (1) and Fabrice Di Meglio (1)
* commit 'de71ce1ab3cda6030b5838f4cadb4fe974d522c2':
Fix recent apps item text position in RTL mode
# Via Android (Google) Code Review (1) and Fabrice Di Meglio (1)
* commit '5e3b0452667e2f73b16bfffde873334525582308':
Fix SystemUI navigation bar in RTL mode
# Via Android (Google) Code Review (1) and Dianne Hackborn (1)
* commit 'd8ba6cc9217e2e042106870e9d2e70cfd80426d6':
Add new API to propagate contextual data to the assist action
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
