| 5e45ee6752528791deb66b83d76250685de15d47 |
|
25-Jan-2013 |
Dianne Hackborn <hackbod@google.com> |
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
/frameworks/base/services/java/com/android/server/location/GeofenceManager.java
|
| 4cd0a50b26eeb68517d03bc0cafc18e98bfc1fec |
|
03-Nov-2012 |
Victoria Lease <violets@google.com> |
Fires geofence if the device is already in the geofence area.
Process the location of the fence as soon as it is added.
Clarified how the distance to the fence was being used.
Added more debug logs (disabled by default).
Fixed a numerical overflow in the location request if the
distance to the border of the nearest fence was greater
than about 2000Km.
Removed a useless call to request location updates passively
when the geofence manager is initialized. We have no need
of location updates unless there are active geofences.
The effect of this call was undone the next time the location
request was updated anyhow.
Changed the location request to always request a fastest update
interval of 0 which accomplishes the goal of passively
monitoring all updates. This does not increase the power
consumption because we are conservative about choosing
a minimum location update interval. We're simply stating
that the geofence manager is willing to handle a higher
report rate which is very important.
Subject location to a "freshness test" - only use relatively
recent locations for geofence testing.
Run all geofence updates on the handler and avoid making
multiple redundant calls into the location manager when
updating the provider requirements.
Ensure that we update geofences correctly even if we don't
know the initial location of the device at the time the
geofence is created.
Pin update interval value to the range [1m..2hr].
Distance to fence is now distance to fence's border, not
distance to fence's centre.
Bug: 7466334
Change-Id: I28e571ecfc508d5ceb9bb2afcabaaf05abb26369
/frameworks/base/services/java/com/android/server/location/GeofenceManager.java
|
| 60ec50a850ac7265b662df3c872583b6ef581ef8 |
|
05-Oct-2012 |
Laurent Tu <laurentt@google.com> |
Last position improvements for GeofenceManager
Use LocationManager.getLastPosition() in GeofenceManager instead of
keeping track of it manually. Keeping track of it in GeofenceManager
doesn't handle the case where we install a fence, and cross it just
after that based on the last position before we installed the fence.
Also shuffle around some code in LocationManagerService to remember the
last position even if there are no UpdateRecords. This is useful in the
GeofenceManager for example.
Bug: 7047435
Change-Id: Ia8acc32e357ecc2e1bd689432a5beb1ea7dcd1c7
/frameworks/base/services/java/com/android/server/location/GeofenceManager.java
|
| 4035f5a7c191a68bc9a5912ce44c43c82e9e5dbf |
|
17-Aug-2012 |
Nick Pelly <npelly@google.com> |
Port location blacklist code to MR1.
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
/frameworks/base/services/java/com/android/server/location/GeofenceManager.java
|
| 6fa9ad4afcd762aea519ff61811386c23d18ddb2 |
|
16-Jul-2012 |
Nick Pelly <npelly@google.com> |
Location overhaul, major commit.
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
/frameworks/base/services/java/com/android/server/location/GeofenceManager.java
|
| e0fd693c6098f59004f9e96ad75c058e26c337b0 |
|
11-Jul-2012 |
Nick Pelly <npelly@google.com> |
Improve geofencing: throttle location updates with distance to fence.
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
/frameworks/base/services/java/com/android/server/location/GeofenceManager.java
|