| Age | Commit message (Collapse) | Author |
|---|
|
Refactored the directory structure so that services can be optionally
excluded. This is step 1. Will be followed by another change that makes
it possible to remove services from the build.
Change-Id: Ideacedfd34b5e213217ad3ff4ebb21c4a8e73f85
|
|
This commit prevents a system_server crash when applications attempt
to use the fused location provider on systems that do not have a
network location provider available.
Bug: 10845061
Change-Id: I85b33806e05566e8b68ee2ccc401b1c565fd7b9a
|
|
Changed public constants from integers to strings. Internally
everything is still integers, since we want that more efficient
representation for most things.
Changed the Callback interface to OnOpChangedListener. We also
have a private versin that again takes an int, and tricks to
make both work.
Reworked the class documentation to be appropriate to the SDK
(as much as it can be); most of the existing documentation is
moved to the private implementation. Also added documentation
of the MODE constants.
Change-Id: I4f7e73cc99fe66beff9194e960e072e2aa9458f8
|
|
Change-Id: I97df15ea7d349e0224e1830d7327dde87e840a51
|
|
- LocationManager.isProviderEnabled() no longer throws SecurityException:
the caller could already circumvent the permission check by calling
Secure.isLocationProviderEnabled()
Change-Id: I5abd04264299671ed35ce4594b5be46d86378767
|
|
- Currently redundant with PROVIDERS_CHANGED_ACTION, but that may
change in the future
- Part of fix for b/10409275
Change-Id: I12daaf20e6546fd9e9dc71c599967fa0ad95e27f
|
|
Change-Id: Ic201f7112dd9c746fe71995fcc1a533ff4a582f2
|
|
is disabled, we don't mark an app as actively using location just because it's requested that provider. Also updates the concept of high power to support third party custom providers (doesn't hard code gps but looks at the provider's actual stated power requirement)." into klp-dev
|
|
If a provider is disabled, we don't mark an app as
actively using location just because it's requested
that provider. Also updates the concept of high
power to support third party custom providers
(doesn't hard code gps but looks at the provider's
actual stated power requirement).
Change-Id: Ie01243bf04d7301962ea9cdb25fb7d8d97566e02
|
|
Change-Id: I0fb0e276d3a06322697bb5d46323779aca1f78c5
|
|
Change-Id: I50889599fdc5938a19b8bff4f11e64f44bcebdbf
|
|
Change-Id: Ia3a57d869dfb3f067a1b95fa66d54f311ddcfdc3
|
|
Move icon to right side of the screen and synchronize status with
AppOpsManager.OP_MONITOR_HIGH_POWER_LOCATION.
Change-Id: Iea2570501cb18be0489669fd4ea240dc63f9567a
|
|
AppOps monitoring as long as the client as the appropriate
permission (UPDATE_DEVICE_STATS).
Change-Id: I7223a53bc1551e6498302a22eb310c8c5b5684b0
|
|
This is a new op parallel to the existing OP_MONITOR_LOCATION
but only tracks those requests deemed to be above a
power threshold.
Change-Id: I76fe4d9d2e550293b9da6d5cf902a5b4dd499f0f
|
|
|
|
Change-Id: I0fbbad0879b87ecc75a503bf7963356595bf4b96
|
|
http://b/8245654
Change-Id: I2ff95b3b9e138b57bc630f760476bbb7d748342a
|
|
1. Now a user state has ins own spooler since the spooler app is
running per user. The user state registers an observer for the state
of the spooler to get information needed to orchestrate unbinding
from print serivces that have no work and eventually unbinding from
the spooler when all no service has any work.
2. Abstracted a remote print service from the perspective of the system
in a class that is transparently managing binding and unbinding to
the remote instance.
3. Abstracted the remote print spooler to transparently manage binding
and unbinding to the remote instance when there is work and when
there is no work, respectively.
4. Cleaned up the print document adapter (ex-PrintAdapter) APIs to
enable implementing the all callbacks on a thread of choice. If
the document is really small, using the main thread makes sense.
Now if an app that does not need the UI state to layout the printed
content, it can schedule all the work for allocating resources, laying
out, writing, and releasing resources on a dedicated thread.
5. Added info class for the printed document that is now propagated
the the print services. A print service gets an instance of a
new document class that encapsulates the document info and a method
to access the document's data.
6. Added APIs for describing the type of a document to the new document
info class. This allows a print service to do smarts based on the
doc type. For now we have only photo and document types.
7. Renamed the systemReady method for system services that implement
it with different semantics to systemRunning. Such methods assume
the the service can run third-party code which is not the same as
systemReady.
8. Cleaned up the print job configuration activity.
9. Sigh... code clean up here and there. Factoring out classes to
improve readability.
Change-Id: I637ba28412793166cbf519273fdf022241159a92
|
|
The new location monitoring op is to tell us when an application
is monitoring for any location changes. It may be useful information
in addition to the more explicitly information about when location
data actually goes to the app.
Also make parts of AppOpsManager public for use by gcore. It is
not available to third party apps.
Change-Id: Ib639f704258ffdd7f3acd7567350ed2539da628a
|
|
process" into jb-mr2-dev
* commit 'a79aaeae551b6ae9d94437505d88bfe3f1bf56ec':
Maybe fix issue #9296868: Crash in system process
|
|
There were some paths in LocationManagerService where
mRecivers was being accessed/modified without the lock held.
Update method names to indicate they need to be called with
lock held to make it more clear in the future when such a
problem may happen.
Change-Id: Ie2a9d019155ac7cedd1db298caca75b8fe382ca7
|
|
This commit splits LocationManagerService's monolithic WakeLock into
per-LocationManagerService.Receiver WakeLocks, for better WorkSource
accounting. This should make it easier to debug location-related
power issues.
Change-Id: I0d2897c305a38099f9663dc1bc9354ce4bbe1077
(cherry picked from commit 0aa28602d51bf41e46d18ffefe724ebc3ff7a704)
|
|
This commit splits LocationManagerService's monolithic WakeLock into
per-LocationManagerService.Receiver WakeLocks, for better WorkSource
accounting. This should make it easier to debug location-related
power issues.
Change-Id: I0d2897c305a38099f9663dc1bc9354ce4bbe1077
|
|
Cherry-pick of I0c383eb82ed041e57a7d32321df2d67b462d4e21 from master
Oops, it seems the fused location provider was being denied access
to locations when any user other than the primary device owner is
logged in. This was breaking the fused location provider entirely
for all secondary users of a given device.
Bug: 8766225
Change-Id: Ic0db5f2094828c897a405abb0dca6ac39a2ca526
|
|
Oops, it seems the fused location provider was being denied access
to locations when any user other than the primary device owner is
logged in. This was breaking the fused location provider entirely
for all secondary users of a given device.
Bug: 8766225
Change-Id: I0c383eb82ed041e57a7d32321df2d67b462d4e21
|
|
This introduces four generic thread that services can
use in the system process:
- Background: part of the framework for all processes, for
work that is purely background (no timing constraint).
- UI: for time-critical display of UI.
- Foreground: normal foreground work.
- IO: performing IO operations.
I went through and moved services into these threads in the
places I felt relatively comfortable about understanding what
they are doing. There are still a bunch more we need to look
at -- lots of networking stuff left, 3 or so different native
daemon connectors which I didn't know how much would block,
audio stuff, etc.
Also updated Watchdog to be aware of and check these new
threads, with a new API for other threads to also participate
in this checking.
Change-Id: Ie2f11061cebde5f018d7383b3a910fbbd11d5e11
|
|
Fixed b/8276827
Vendor might want to provide their own implementation of "network
location", "fused location" and "geocoder" service. Location manager now
allows those service to be replaced by packages that have the same
signature as one of the packages in config_locationProviderPackageNames.
Such behavior might not be desirable on some devices. This change
make this behavior configurable by 3 boolean flags.
Details:
- Added three boolean flags in core/res/res/values/config.xml to enable
or disable NLP/FLP/Geocoder overlay
- Added 3 package name for the stock NLP/FLP/Geocoder. They are needed
only when overlay is disabled because LocationManagerService need to
know which package is preferred when searching for
NLP/FLP/Geocoder service.
- Made ServiceWatcher able to handle non-overlayable services.
- Fixed an NPE isue in ServiceWatcher. mPm.queryIntentServicesAsUser
might return null.
- Fixed an bug: justCheckThisPackage in bindBestPackageLocked is always
ignored.
Change-Id: Id221961ac7c3aa8ad44b894f9523f04f770ae237
|
|
can get location updates too frequently by repeatedly calling getLastKnownLocation
or by registering/unregistering location updates frequently.
Change-Id: Ibd9ce28b0401372b995a0dbfb2f0a984dd11c0b1
|
|
Add support for doing geofencing in hardware.
Change-Id: I6d5015190e8d84e1f4beb1010ed977a71c1622d0
|
|
Change-Id: If4d7b6c814d946806838cee7dcaccba4c65c3d0f
|
|
|
|
Change-Id: I273e82bdad66ada3bf0f7ec9176bc304b9ee1ee8
|
|
|
|
|
|
.detrevni saw tset ()sseccAnoitacoLkcehc eht smees tI
Bug: 8131283
Change-Id: I91ded29338c93aa7ab35d849fc5338b3f6d6590b
|
|
|
|
This commit splits LocationManagerService.isAllowedBySettingsLocked()
into isAllowedByUserSettingsRogkei(), which takes a UID argument, and
isAllowedByCurrentUserSettingsLocked(), which does not. This removes
the need to generate synthetic UIDs with arbitrary application IDs
and makes more explicit when LocationManagerService is acting on
behalf of a caller and when it is acting on behalf of the device's
current active user.
Change-Id: I2cb8fb52687d2629848e5a4b66a4bda8f0f66fe1
|
|
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
|
|
|
|
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
|
|
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
|
|
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
|
|
Use this to track the package name of applications
accessing GPS.
And now the app ops service can enforce that callers
must provide valid package names.
Change-Id: I842a0abe236ea85f77926d708547f0f95c24bd49
|
|
Initial implementation, tracking use of the vibrator, GPS,
and location reports.
Also includes an update to battery stats to also keep track of
vibrator usage (since I had to be in the vibrator code anyway
to instrument it).
The service itself is only half-done. Currently no API to
retrieve the data (which once there will allow us to show you
which apps are currently causing the GPS to run and who has
recently accessed your location), it doesn't persist its data
like it should, and no way to tell it to reject app requests
for various operations.
But hey, it's a start!
Change-Id: I05b8d76cc4a4f7f37bc758c1701f51f9e0550e15
|
|
systemReady() was returning before the LocationManagerService was
actually ready. Applications making LocationManager transactions
during their startup could possibly hit a race condition with the
yet-uninitialised LocationManagerService.
To guarantee that LocationManagerService is actually ready before
returning from systemReady(), we simply do the startup work on the
thread that called systemReady(), rather than spin up a secondary
thread to do the work asynchronously.
LocationWorkerHandler still needs a thread to do its work on, so
rather than have it run on the secondary thread that was
previously used for systemReady()'s work, we create a HandlerThread
for it.
Additionally, LocationManagerService.init() really needed to grab
lock for some of the things it was doing. I moved all of the code
that could benefit from mutex protection to a single section of
systemReady() and wrapped it up with a lock while I was at it.
Bug: 7723944
Change-Id: I51d480e2781622c3a14769c3a2019a2407dcfd8a
|
|
This is a more complete solution for this issue that disables
location providers when expiring their last request *and* adjusts
update intervals when expiring any request. This should help
further limit battery drain when a high-frequency-update app
exits, as it allows the system to throttle the update interval
back down to something appropriate for the remaining listeners.
Bug: 7611837
Change-Id: I88b419c92940b7e536d48b26e5fc0f72f3c9e73d
|
|
Location providers were not being notified of the change in status
when the last UpdateRecord was removed due to numUpdates exhaustion
or request expiry. Oops! Enjoy some free battery life!
Bug: 7611837
Change-Id: Id48151eb7de40164258cde7da220a4d6bb34b89a
|
|
Change-Id: Ibf93833697c865904f29821e5778853127e5fb00
Signed-off-by: You Kim <you.kim72@gmail.com>
Conflicts:
services/java/com/android/server/LocationManagerService.java
|
