This replaces the ACCURACY_METERS constant and all derived values with
a secure setting. This value defaults to 2km and has a hardcoded floor
of 500m.
Bug: 6982024
Change-Id: Ibf97ab57145abf28c4a9747444f40250adddf23c
Bug 7051185
- Register a ContentObserver to track settings changes rather than
opening up a Cursor with a ContentQueryMap.
- Move updateProvidersLocked into init to assure that the
ContentObserver does not miss any changes.
- Move blacklist and fudger creation before loadProvidersLocked to
improve code readability.
Change-Id: I4d3e19fa33401c384bc2b00658d4336ea119e0e5
You can now use ALL and CURRENT when sending broadcasts, to specify
where the broadcast goes.
Sticky broadcasts are now correctly separated per user, and registered
receivers are filtered based on the requested target user.
New Context APIs for more kinds of sending broadcasts as users.
Updating a bunch of system code that sends broadcasts to explicitly
specify which user the broadcast goes to.
Made a single version of the code for interpreting the requested
target user ID that all entries to activity manager (start activity,
send broadcast, start service) use.
Change-Id: Ie29f02dd5242ef8c8fa56c54593a315cd2574e1c
This intent filter isn't used anymore, since GpsLocationProvider handles
the CONNECTIVITY_ACTION broadcasts now..
Change-Id: I593a9916aa6f8086b4d684cc3e25286c1cb137cc
Need to clear the callers identity before calling into geofence manager
because it in turn calls fused location API's.
Change-Id: I7993b0b8b2a947ff93c37a7c9d29ca0e7c95f9a8
I had to re-do this change for MR1 because LocationManagerService changed
so much. Here is the original change description:
Add package-name-prefix blacklist for location updates.
The Settings.Secure value locationPackagePrefixBlacklist and
locationPackagePrefixWhitelist contains comma seperated package-name
prefixes.
Location & geo-fence updates are silently dropped if the receiving
package name has a prefix on the blacklist. Status updates are
not affected. All other API's work as before.
A content observer is used so run-time updates to the blacklist
apply immediately. There is both a blacklist and a whitelist.
The blacklist applies first, and then exemptions are allowed
from the whitelist. In other words, if your package name prefix
matches both the black AND white list, then it is allowed.
Bug: 6986553
Change-Id: I1e151e08bd7143e47db005bc3fe9795076398df7
Fix a couple of bugs, and modify the behavior of the random offset.
The random offset now slowly changes over time, to mitigate against
applications averaging out the offset over time while at a
grid boundary.
Change-Id: Iecffff29145b8c2b30d1eca1662cf9d3e8cff756
Themes: Fused Location, Geofencing, LocationRequest.
API changes
o Fused location is always returned when asking for location by Criteria.
o Fused location is never returned as a LocationProvider object, nor returned
as a provider String. This wouldn't make sense because the current API
design assumes that LocationProvider's have fixed properties (accuracy, power
etc).
o The fused location engine will tune itself based on the criteria passed
by applications.
o Deprecate LocationProvider. Apps should use fused location (via Criteria
class), instead of enumerating through LocationProvider objects. It is
also over-engineered: designed for a world with a plethora of location
providers that never materialized.
o The Criteria class is also over-engineered, with many methods that aren't
currently used, but for now we won't deprecate them since they may have
value in the future. It is now used to tune the fused location engine.
o Deprecate getBestProvider() and getProvider().
o Add getLastKnownLocation(Criteria), so we can return last known
fused locations.
o Apps with only ACCESS_COARSE_LOCATION _can_ now use the GPS, but the location
they receive will be fudged to a 1km radius. They can also use NETWORK
and fused locatoins, which are fudged in the same way if necessary.
o Totally deprecate Criteria, in favor of LocationRequest.
Criteria was designed to map QOS to a location provider. What we
really need is to map QOS to _locations_.
The death knell was the conflicting ACCURACY_ constants on
Criteria, with values 1, 2, 3, 1, 2. Yes not a typo.
o Totally deprecate LocationProvider.
o Deprecate test/mock provider support. They require a named provider,
which is a concept we are moving away from. We do not yet have a
replacement, but I think its ok to deprecate since you also
need to have 'allow mock locations' checked in developer settings.
They will continue to work.
o Deprecate event codes associated with provider status. The fused
provider is _always_ available.
o Introduce Geofence data object to provide an easier path fowards
for polygons etc.
Implementation changes
o Fused implementation: incoming (GPS and NLP) location fixes are given
a weight, that exponentially decays with respect to age and accuracy.
The half-life of age is ~60 seconds, and the half-life of accuracy is
~20 meters. The fixes are weighted and combined to output a fused
location.
o Move Fused Location impl into
frameworks/base/packages/FusedLocation
o Refactor Fused Location behind the IProvider AIDL interface. This allow us
to distribute newer versions of Fused Location in a new APK, at run-time.
o Introduce ServiceWatcher.java, to refactor code used for run-time upgrades of
Fused Location, and the NLP.
o Fused Location is by default run in the system server (but can be moved to
any process or pacakge, even at run-time).
o Plumb the Criteria requirements through to the Fused Location provider via
ILocation.sendExtraCommand(). I re-used this interface to avoid modifying the
ILocation interface, which would have broken run-time upgradability of the
NLP.
o Switch the geofence manager to using fused location.
o Clean up 'adb shell dumpsys location' output.
o Introduce config_locationProviderPackageNames and
config_overlay_locationProviderPackageNames to configure the default
and overlay package names for Geocoder, NLP and FLP.
o Lots of misc cleanup.
o Improve location fudging. Apply random vector then quantize.
o Hide internal POJO's from clients of com.android.location.provider.jar
(NLP and FLP). Introduce wrappers ProviderRequestUnbundled and
ProviderPropertiesUnbundled.
o Introduce ProviderProperties to collapse all the provider accuracy/
bearing/altitude/power plumbing (that is deprecated anyway).
o DELETE lots of code: DummyLocationProvider,
o Rename the (internal) LocationProvider to LocationProviderBase.
o Plumb pid, uid and packageName throughout
LocationManagerService#Receiver to support future features.
TODO: The FLP and Geofencer have a lot of room to be more intelligent
TODO: Documentation
TODO: test test test
Change-Id: Iacefd2f176ed40ce1e23b090a164792aa8819c55
LocationProviders often rely on non-default networks, so pass the
network that actually changed, instead of the default.
Bug: 6929692
Change-Id: I31d9eec792e07259282aa1bb57ec66c01962df64
Add getElapsedRealtimeNano():
Currently Location just has getTime() and setTime() based on UTC time.
This is entirely unreliable since it is not guaranteed monotonic.
There is a lot of code that compares fix age based on deltas -
and it is all broken in the case of a system clock change. System
clock can change when switching cellular networks (and in some
cases when switching towers).
Document the meaning of getAccuracy():
It is the horizontal, 95% confidence radius.
Make some fields mandatory if they are reported by a LocationProvider:
All Locations returned by a LocationProvider must include at the
minimum a lat, long, timestamps, and accuracy. This is necessary
to perform fused location. There are no public API's for applications
to feed locations into a location provider so this should not cause
any breakage.
If a LocationProvider does not fill in enough fields on a Location
object then it is dropped, and logged.
Bug: 4305998
Change-Id: I7df77125d8a64e174d7bc8c2708661b4f33461ea
Previously any geofence (proximity alert) would turn the GPS on at full rate.
Now, we modify the GPS interval with the distance to the nearest geofence.
A speed of 100m/s is assumed to calculate the next GPS update.
Also
o Major refactor of geofencing code, to make it easier to continue to improve.
o Discard proximity alerts when an app is removed.
o Misc cleanup of nearby code. There are other upcoming changes
that make this a good time for some house-keeping.
TODO:
The new geofencing heuristics are much better than before, but still
relatively naive. The next steps could be:
- Improve boundary detection
- Improve update thottling for large geofences
- Consider velocity when throttling
Change-Id: Ie6e23d2cb2b931eba5d2a2fc759543bb96e2f7d0
Use config_netowrkLocationProviderPackageName and
config_geocodeProviderPackageName as intial packages. If another
package exists (or is later installed) that also implements a
provider, and has the same signatures as the original providers,
and has a hgiher version number, then use that instead.
The old code used a funky fix of package name substring checks
and service checks that was broken and not upgradeable.
Bug: 6499445
Change-Id: Ic58f09cf85d31d9abf47707093e22f31dda25cf0
There is a long history in Android, on both GED and non GED devices
of GPS providers ignoring the minTime parameter making location updates
every second. The problem is usually poor GPS drivers that claim to
do scheduling but then do not.
By making the minTime parameter strict (instead of a hint) we can add
a CTS test to ensure that udpates to not occur too frequently. I believe
this is the desired behavior from apps. If apps want to take advantage
of more frequent updates when another application asks for those updates
then it can use the passive provider.
The CTS test for GPS has already been submitted (as part of CTS Verifier).
Bug: 6424983
Change-Id: I163b9e44ea7ab71530b86fc2282614e0150e90f1
Because the NetworkInfo included in CONNECTIVITY_ACTION broadcast
extra does not reflect the state applicable to the calling UID, and
the last sticky broadcast may have stale state, transition to calling
ConnectivityManager.getActiveNetworkInfo() directly.
Change-Id: I86b316fbedd0273585ad5f1248b091bc3a3a5520
Location manager now checks for such intents, and logs a warning when
they are given to it. Nothing thrown yet, it needs to check the
targetSdkVersion of the caller somehow.
When sending the pending intent, we require that the recipient hold the
appropriate permission. This should pretty much close the security hole.
Includes a bunch of infrastructure in the activity manager needed to
support all this.
Change-Id: I4dba7a98a7b8bbb9e347666451aa9cb1efad1848
getBestProvider should only return location providers that the client
has permission to use.
BUG: 3124614
Change-Id: I065091d0445092563bc53fb4f7d93a1ab6bebb9a
Signed-off-by: Mike Lockwood <lockwood@android.com>
The proxy must ensure that enable/disable calls are not reordered when
proxied; this change adds synchronization to prevent such reordering
that could happen following an onServiceConnected() callback, and to
ensure cross-thread visibility of writes.
Also, when the package is updated, the old service instance must be
unbound and the new one bound. This changes uses a separate
Connection object per service instance (package version) to avoid
confusing the binder objects.
Change-Id: I0907f7eed211b97ccfffa395754f1eb8ea8d8fec
Also rename Geocoder.isImplemented() to Geocoder.isPresent()
BUG: 3000738
BUG: 3001413
Change-Id: I56bb4e9a9c59f8b79de585eeb168f74c3ff1a853
Signed-off-by: Mike Lockwood <lockwood@android.com>
This fixes a problem where applications could ask the location
manager to do very heavy-weight things (like... say... update
location every minute), which would get accounted against the
system instead of the application because ultimately it is the
system making the heavy calls (wake locks, etc).
To solve this, we introduce a new class WorkSource representing
the source of some work. Wake locks and Wifi locks allow you
to set the source to use (but only if you are system code and thus
can get the permission to do so), which is what will be reported
to the battery stats until the actual caller.
For the initial implementation, the location manager keeps track
of all clients requesting periodic updates, and tells its providers
about them as a WorkSource param when setting their min update time.
The network location provider uses this to set the source on the
wake and wifi locks it acquires, when doing work because of the
update period.
This should also be used elsewhere, such as in the GPS provider,
but this is a good start.
Change-Id: I2b6ffafad9e90ecf15d7c502e2db675fd52ae3cf
See e.g. http://code.google.com/p/android/issues/detail?id=10042
This is also needed by the power control widget, which has no reliable
way otherwise of staying in-sync.
Change-Id: I8f2b6b79b1843329bae952a25ea56f15e3cf92aa
Merge commit '27ef0f732c5a97ba88a699b7490045e5370cf51f'
* commit '27ef0f732c5a97ba88a699b7490045e5370cf51f':
Don't throw an exception from isProviderEnabled and getLastKnownLocation
if the location provider does not exist. Instead use the same behavior
as if the provider were disabled in settings
(return false for isProviderEnabled and null from getLastKnownLocation).
This eliminates for a lot of exception handling around some simple
queries to the location manager.
BUG: 2841014
Change-Id: I4fbe0c088e915c90969e13083201dd3e7f4029cb
Signed-off-by: Mike Lockwood <lockwood@android.com>
The Geocorder interface is not part of the Android core. It
requires a backend service which may or may not be available
on a device. The new isImplemented static method allows
apps to discover whether the Geocorder is in fact available
on the device.
Change-Id: I2b5cf7bcc9cce4766bcbb156e91edf34b01f9296
Use MS-Assisted mode for single shot GPS fixes if it is supported.
Add finer grained control over accuracy to the android.location.Criteria class
and location criteria logic from LocationManager to LocationManagerService
Change-Id: I156b1f6c6a45d255c87ff917cf3e9726a6d7a75b
Signed-off-by: Mike Lockwood <lockwood@android.com>
Merge commit 'd2084bb689bb680eb886d5cfbd27adc6f2e9da1c' into kraken
* commit 'd2084bb689bb680eb886d5cfbd27adc6f2e9da1c':
LocationManagerService: Call updateNetworkState on providers that are disabled.
Fixes a problem with Network Location not working after SetupWizard until the
network state changes.
Change-Id: Ief81b76beb5cc90b2ca7d8aa2d4c99221898f01d
BUG: 2671347
Signed-off-by: Mike Lockwood <lockwood@android.com>
