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
This change adds APIs support for implementing UI tests. Such tests do
not rely on internal application structure and can span across application
boundaries. UI automation APIs are encapsulated in the UiAutomation object
that is provided by an Instrumentation object. It is initialized by the
system and can be used for both introspecting the screen and performing
interactions simulating a user. UI test are normal instrumentation tests
and are executed on the device.
UiAutomation uses the accessibility APIs to introspect the screen and
a special delegate object to perform privileged operations such as
injecting input events. Since instrumentation tests are invoked by a shell
command, the shell program launching the tests creates a delegate object and
passes it as an argument to started instrumentation. This delegate
allows the APK that runs the tests to access some privileged operations
protected by a signature level permissions which are explicitly granted
to the shell user.
The UiAutomation object also supports running tests in the legacy way
where the tests are run as a Java shell program. This enables existing
UiAutomator tests to keep working while the new ones should be implemented
using the new APIs. The UiAutomation object exposes lower level APIs which
allow simulation of arbitrary user interactions and writing complete UI test
cases. Clients, such as UiAutomator, are encouraged to implement higher-
level APIs which minimize development effort and can be used as a helper
library by the test developer.
The benefit of this change is decoupling UiAutomator from the system
since the former was calling hidden APIs which required that it is
bundled in the system image. This prevented UiAutomator from being
evolved separately from the system. Also UiAutomator was creating
additional API surface in the system image. Another benefit of the new
design is that now test cases have access to a context and can use
public platform APIs in addition to the UiAutomator ones. Further,
third-parties can develop their own higher level test APIs on top
of the lower level ones exposes by UiAutomation.
bug:8028258
Also this change adds the fully qualified resource name of the view's
id in the emitted AccessibilityNodeInfo if a special flag is set while
configuring the accessibility service. Also added is API for looking
up node infos by this id. The id resource name is relatively more stable
compared to the generaed id number which may change from one build to
another. This API facilitate reuing the already defined ids for UI
automation.
bug:7678973
Change-Id: I589ad14790320dec8a33095953926c2a2dd0228b
The disabled state allows you to make an app disabled
except for whatever parts of the system still want to
provide access to them and automatically enable them
if the user want to use it.
Currently the input method manager service is the only
part of the system that supports this, so you can put
an IME in this state and it will generally look disabled
but still be available in the IME list and once selected
switched to the enabled state.
Change-Id: I77f01c70610d82ce9070d4aabbadec8ae2cff2a3
The getServiceInfo() call directly to IPackageManager does not throw an exception.
The return value needed to be checked for null.
Bug: 8031032
Change-Id: I701b9e8cf3b2406a3b35a486183330489b3d46f5
LocationManagerService now annotates incoming Location objects that
have come from mock location providers. The new isFromMockProvider()
method can be called on any Location to determine whether the
provider that supplied the Location was a mock location provider.
Bug: 6813235
Change-Id: Ib5140e93ea427f2e0b0036151047f87a02b4d23a
Take advantage of this to return better information about
packages filtered by permissions -- include the permissions
they have in the requested array.
Also fix issue #8026793 (Contact picture shows default pic
while searching for a contact in qsb) by using the base
package name of the Context when reporting the app name
of an operation. Otherwise you could make a resource-only
context for another application and do calls through that
and get reported as the wrong app.
Change-Id: I5e0488bf773acea5a3d22f245641828e1a106fb8
Implemented reading and writing state to retain information
across boots, API to retrieve state from it, improved location
manager interaction to monitor both coarse and fine access
and only note operations when location data is being delivered
back to app (not when it is just registering to get the data at
some time in the future).
Also implement tracking of read/write ops on contacts and the
call log. This involved tweaking the content provider protocol
to pass over the name of the calling package, and some
infrastructure in the ContentProvider transport to note incoming
calls with the app ops service. The contacts provider and call
log provider turn this on for themselves.
This also implements some of the mechanics of being able to ignore
incoming provider calls... all that is left are some new APIs for
the real content provider implementation to be involved with
providing the correct behavior for query() (return an empty
cursor with the right columns) and insert() (need to figure out
what URI to return).
Change-Id: I36ebbcd63dee58264a480f3d3786891ca7cbdb4c
