This commit is the result of a comprehensive permissions review for
MR1 release. It addresses a number of deviations from spec and from
MR0's behavior, bringing MR1 into sync with both.
It also cleans up the concept of "location resolution permission",
representing it internally as an enumerated access level to reduce
reliance on cumbersome string manipulation. There's a function to
convert the enum int into a permission string where needed, too.
Additionally, this confines caller-identity-sensitive calls to the
hopefully-obviously-named "getCallerAllowedResolutionLevel()". This
should make it much easier to prove correctness with respect to
accidentally calling functions that depend upon the caller's identity
after identity has already been shed by Binder.clearCallingIdentity().
Change-Id: I446169aee8fb2fde26ac6d04b479b40253782acb
If a provider is unknown, return null in
LocationManagerService.getProviderProperties() instead of throwing a
security exception, so that LocationManager.getProvider() returns null
in this case, as specified by the javadoc.
Bug: 7359960
Change-Id: I1b8b74745f66717a3439a1d353a46a23272cc313
During testing it's possible to mock a location provider, but the fused
location provider wasn't being inserted into the "mRealProviders" map so
when the fused location provider was unmocked, it would disappear
permanently from the list until the next reboot.
Bug: 6949478
Change-Id: I4993aa7fbbd21cea16bdbf2722d637c909b1cd73
LocationManagerService now keeps track of the current user ID and
denies location requests made by all but the foreground user.
Additionally, location settings are now user-specific, rather than
global to the device. Location provider services now run as specific
users, and when the device's foreground user changes, we rebind to
appropriately-owned providers.
Bug: 6926385
Bug: 7247203
Change-Id: I346074959e96e52bcc77eeb188dffe322b690879
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
Add a case for isAllowedProviderSafe() to handle providers that are not
GPS/Passive/Network/Fused. For example, this is useful for mock
providers.
Bug: 7047435
Change-Id: If4799aa90a5338889c47582d45cbfc25772c9c53
This allows primary/secondary users to have different "Google
Location Services" preferences. It also reenables LocationBlacklist,
which is fixed elsewhere.
Bug: 7213502
Bug: 7248239
Change-Id: I94837682f95920c225c00b7da2de6dd1418a673e
There is now only a single config value pointing
at a list of packages to get certs from. The old
system was a bit confusing.
The fused location provider also now builds
against SDK 17, and the meta data service version
tag was renamed from the overly generic "version"
to "serviceVersion".
Bug: 7242814
Change-Id: I00d27c9cbd5cc31a37bb4a98160435d15a72e19e
In MR0, we did not allow applications to query enabled status of
location providers they did not have permission to use. Some
applications counted on this behavior, using the thrown
SecurityException to determine whether or not they have permission
to use the specified provider.
Reverting to this behavior fixes the regressions seen in those
applications.
Bug: 7251459
Change-Id: I8b0cfd5862c80f0c831a4ab544c3fa7408bc84a0
getAllProviders() should return all locators, including those not
allowed or not enabled (according to the existing javadoc, at least).
The checkPermission() call prevented this behavior by throwing a
security exception. We restore the previous behavior by removing the
call.
Bug: 6950369
Change-Id: I0c6bc676d4c4db482bb68f1ab7fa5c93675118b4
Oops, looks like we were spinning up a secondary thread to run some
tasks that will just happen on the main thread regardless. Removed
the secondary thread and fixed up initialisation order regarding
mHandler and things that post to it. Also reordered GPS and
PASSIVE provider initialisation order since GPS depends on PASSIVE.
This should be both safer and easier to read.
Bug: 7248029
Change-Id: I8630caf0a7bd1b2c401603075676f13dda5be4fa
This takes the easy way around notifying the correct users
about GPS state transitions by notifying ALL the users(!).
I've also laid groundwork for proper multiuser support in
LocationManager and did a tiny bit of cleanup in
GpsNetInitiatedHandler while I was looking at notifications.
Bug: 7213552
Change-Id: I2d6dc65c459e55d110ac0f5f79ae7a87ad638ede
Preferring the GPS location provider over NLP should produce better
average and worst-case results than NLP, which is very accurate in
certain conditions and completely useless in others.
Bug: 7182301
Change-Id: If7d50f0d3ac663cbfd84b7033adc204c11bcaca4
This restores MR0's behavior in this regard - apps calling
LocationManager.getProviders() or LocationManager.getBestProvider()
will no longer receive a SecurityException if they do not have
any location permissions. Instead, as was the behavior in MR0, they
only receive providers that their permissions grant them access to,
including an empty list if they have no permission whatsoever.
Bug: 7207864
Change-Id: I027df425e258d436c4821c34a25bc46a2a292824
FusionEngine now attaches a secondary location that has never seen
GPS data to its result. LocationFudger uses the GPS-less location so
that COARSE apps never see data from the GPS provider.
When the previous location is updated, the previous GPS-less location
is carried over if the location update was GPS-only.
Additionally, apps without FINE permission are not notified when GPS
location changes, and any attempt to use GPS_PROVIDER without FINE
permission is met by a stern SecurityException.
Bug: 7153659
Change-Id: I12f26725782892038ce1133561e1908d91378a4a
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
