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
# Via Android (Google) Code Review (1) and Todd Poynor (1)
* commit 'afae9d248ade0cb0b719f680804acfb9d20ca36b':
BatteryService: Treat USB charging ports and charging accessories as AC
# Via Android (Google) Code Review (1) and Todd Poynor (1)
* commit 'b86d026a7f4108caefa080cf9e0c0b4b5e275a84':
BatteryService: Allow power supplies to switch type between AC and USB
Accomodate power_supply drivers that switch between MAINS and USB type
according to the current power source. Re-read the type attribute when the
power supply is online.
Switch to String8 type for strings stored locally.
Change-Id: Iacce49bf3ad85f35a7295a54df43aff7f94f3100
# Via Android (Google) Code Review (1) and Satoshi Kataoka (1)
* commit 'da01da176d4798d293c90d6280ddc59c780baaa3':
Do not turn on imes unexpectedly with unit tests
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
# Via Android (Google) Code Review (1) and Svetoslav (1)
* commit '91488eed1745ea0426a73306f133e02d62580f1a':
AccessibilityNodeINfo cache not cleared when accessibility is disabled.
Display magnifier does not release its surface on destroy.
This is called from Settings that has a button to clear secure
adb public keys installed on the device.
Change-Id: I63ef499c049766ef13ea6cb0594ed6719f35e5f3
# Via Android (Google) Code Review (1) and Benoit Goby (1)
* commit '4daf9b1ba5d898ac874197543dbd949360edcc45':
UsbDeviceManager: Don't start UsbDebuggingManager when data is encrypted
Use static native methods.
Release the native looper objects as soon as the Looper quits
instead of waiting until the GC finalizer to take care of it.
Change-Id: I02783e48782a8f972ec2138862f700ade33d8e78
# Via Android (Google) Code Review (1) and Dianne Hackborn (1)
* commit '93f770b59fa1bd0f2a5c18fcfaffd2a1fc54f585':
Fix bug where we could get stuck repeatedly launching an activity.
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
# Via Android (Google) Code Review (1) and Victoria Lease (1)
* commit 'de07d41f6396f9f040fed2b6780932d8e5dbb482':
Annotate Locations coming from mock providers
# Via Android (Google) Code Review (1) and Dianne Hackborn (1)
* commit 'b9781fe08c5b1afba086857aa18b46862550ae88':
App ops: you can now turn off operations.
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
# Via Android (Google) Code Review (1) and Dianne Hackborn (1)
* commit 'd8ba6cc9217e2e042106870e9d2e70cfd80426d6':
Add new API to propagate contextual data to the assist action
# Via Android (Google) Code Review (1) and Dianne Hackborn (1)
* commit '51ff575d1bd0337a68ae173ee699ff8298ddb703':
Fix issue #7649720: ANR occur when OTA with lower version...
# Via Android (Google) Code Review (1) and Dianne Hackborn (1)
* commit '846dda3fa7a194b57acdb977e443c93c7cddcea1':
Add new disabled state for "optional" built-in apps.
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
