summaryrefslogtreecommitdiff
path: root/services/java/com/android/server/LocationManagerService.java
Commit message (Collapse)AuthorAgeFilesLines
...
* Maybe fix issue #7596986: Frequent runtime restarts; IAE at...Dianne Hackborn2012-11-291-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ...android.os.Parcel.nativeAppendFrom(Native Method) The failing stack trace is: 11-20 20:29:04.365 19154 19170 E AndroidRuntime: java.lang.IllegalArgumentException 11-20 20:29:04.365 19154 19170 E AndroidRuntime: at android.os.Parcel.nativeAppendFrom(Native Method) 11-20 20:29:04.365 19154 19170 E AndroidRuntime: at android.os.Parcel.appendFrom(Parcel.java:428) 11-20 20:29:04.365 19154 19170 E AndroidRuntime: at android.os.Bundle.writeToParcel(Bundle.java:1613) 11-20 20:29:04.365 19154 19170 E AndroidRuntime: at android.os.Parcel.writeBundle(Parcel.java:605) 11-20 20:29:04.365 19154 19170 E AndroidRuntime: at android.location.Location.writeToParcel(Location.java:903) 11-20 20:29:04.365 19154 19170 E AndroidRuntime: at android.os.Parcel.writeParcelable(Parcel.java:1254) 11-20 20:29:04.365 19154 19170 E AndroidRuntime: at android.os.Parcel.writeValue(Parcel.java:1173) 11-20 20:29:04.365 19154 19170 E AndroidRuntime: at android.os.Parcel.writeMapInternal(Parcel.java:591) 11-20 20:29:04.365 19154 19170 E AndroidRuntime: at android.os.Bundle.writeToParcel(Bundle.java:1619) 11-20 20:29:04.365 19154 19170 E AndroidRuntime: at android.os.Parcel.writeBundle(Parcel.java:605) 11-20 20:29:04.365 19154 19170 E AndroidRuntime: at android.location.Location.writeToParcel(Location.java:903) 11-20 20:29:04.365 19154 19170 E AndroidRuntime: at android.os.Parcel.writeParcelable(Parcel.java:1254) 11-20 20:29:04.365 19154 19170 E AndroidRuntime: at android.os.Parcel.writeValue(Parcel.java:1173) 11-20 20:29:04.365 19154 19170 E AndroidRuntime: at android.os.Parcel.writeMapInternal(Parcel.java:591) 11-20 20:29:04.365 19154 19170 E AndroidRuntime: at android.os.Bundle.writeToParcel(Bundle.java:1619) 11-20 20:29:04.365 19154 19170 E AndroidRuntime: at android.os.Parcel.writeBundle(Parcel.java:605) 11-20 20:29:04.365 19154 19170 E AndroidRuntime: at android.content.Intent.writeToParcel(Intent.java:6660) 11-20 20:29:04.365 19154 19170 E AndroidRuntime: at android.app.ApplicationThreadProxy.scheduleReceiver(ApplicationThreadNative.java:763) 11-20 20:29:04.365 19154 19170 E AndroidRuntime: at com.android.server.am.BroadcastQueue.processCurBroadcastLocked(BroadcastQueue.java:230) 11-20 20:29:04.365 19154 19170 E AndroidRuntime: at com.android.server.am.BroadcastQueue.processNextBroadcast(BroadcastQueue.java:777) This is odd because where we do Bundle.writeToParcel(), we are just writing the Parcel we have with its current length. There is no way this should be able to fail like this... unless the Bundle is changed while we are running? Hm. It looks like the location manager is holding on to Location objects which have a Bundle of extras. It is that Bundle of extras that the crash is happening on. And the bundle extras can be changed as it operates. And there are places where the raw Location object is returned from the location manager, which means the caller can be olding on to a Location object whose extras can be changed at any time by other threads in the location manager. So that seem suspicious. This change should take care of all these places in the location manager, by making sure to copy the location object before it goes out of the location manager. In addition, add some code to the activity manager to not bring down the entire system if there is a problem trying to send one of these broadcasts. There is no need, we can just skip the broadcast as bad. Change-Id: I3043c1e06f9d2931a367f831b6a970d71b0d0621
* Resolve LocationManager + ActivityManager conflictVictoria Lease2012-11-131-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | LocationManagerService was serially stuffing the same Location into multiple Intents, which it would immediately hand off to ActivityManagerService, running as a different thread in the same process. LocationManager would continue to work with that Location while ActivityManagerService worked with a Parceled version of it. However, Location.mExtras is also a Bundle, and both ActivityManagerService and LocationManagerService ended up working with references to the same Bundle. ActivityManagerService needs it in Parceled form (ie mParceledData != null), but LocationManagerService was triggering Bundle.unparcel() when referencing the data contained within. As a result, LocationManagerService was able to trigger NPE (or worse) in ActivityManagerService by manipulating the mExtras member of a Location that was in the process of being reported to listeners. To resolve this issue, I copy-construct a new Location to report to each listener. This should prevent ActivityManagerService and LocationManagerService from referencing the same Bundle data, as Location's copy constructor also copyconstructs the mExtras member, rather than simply share references. Bug: 7518371 Change-Id: I1a92615cba361831494447d5de085a8d910b6b2c
* Remove extraneous logs.Dianne Hackborn2012-11-081-3/+3
| | | | Change-Id: I4c47d36748de91bd6fddc419afbf59552bf63e9a
* disable geofences for secondary usersVictoria Lease2012-11-061-0/+5
| | | | | | | Geofences are broken in multiuser, and need to be fixed before reenabling the feature for secondary users. Change-Id: Ief3008a294deed47760ee25efcf1cdef5371b038
* Decrement number of updates in LocationRequestLaurent Tu2012-11-021-4/+16
| | | | | | | | | Decrement the number of updates after a location fix has been sent to a a listener. This is necessary for respecting calls such as requestSingleUpdate(). Bug: 7460868 Change-Id: Iea207ab494b93b936ca434d59652bb2cb6404cef
* Revert "make FLP play nicely with multiuser"Victoria Lease2012-10-291-49/+20
| | | | | | This reverts commit e5601ce9bfa4effbddb84186f0fe1bfe4ad50301 Change-Id: Icd12f2d2c18f2eeeb2c367a885fb6d170ce426ae
* make FLP play nicely with multiuserVictoria Lease2012-10-261-20/+49
| | | | | | | | | | | | | Frameworks' FusedLocationProvider runs as a specific user so that it can join a specific process. The solution that works for NLP, run one copy per user as that user, does not work for FLP. To make FLP play nicely with multiuser, I've allowed SYSTEM_UID to operate in the background and included a hardcoded exception to prevent ServiceWatcher from trying to launch one FLP per user. Bug: 7279799 Change-Id: I573ea5226d8d00777421b39c5c3fb0899bf09b4d
* Merge "Changes to support updating location providers." into jb-mr1-devJeff Hamilton2012-10-181-7/+77
|\
| * Changes to support updating location providers.Jeff Hamilton2012-10-181-7/+77
| | | | | | | | | | | | | | This reverts commit 20de160ca32a8f2936a80ffd70551a22e2371d25. Bug: 7242814 Change-Id: I9ec49a14feb835b6683186fc6da4a74ae19fbae2
* | LocationManager permissions cleanupVictoria Lease2012-10-181-101/+142
|/ | | | | | | | | | | | | | | | | | | 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
* Handle unknown case in LocationManager.getProviderLaurent Tu2012-10-161-0/+4
| | | | | | | | | | 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
* fix crashing appsVictoria Lease2012-10-151-44/+55
| | | | | Bug: 7349330 Change-Id: Iea61bce23cb197c7a28d574098253823df73a99b
* Merge "Add fused location provider to real provider list" into jb-mr1-devKenny Root2012-10-091-0/+1
|\
| * Add fused location provider to real provider listKenny Root2012-10-091-0/+1
| | | | | | | | | | | | | | | | | | | | 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
* | Merge "Multiuser love for LocationManager" into jb-mr1-devVictoria Lease2012-10-091-73/+111
|\ \ | |/ |/|
| * Multiuser love for LocationManagerVictoria Lease2012-10-081-73/+111
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
| * Revert "Changes to support updating location providers."Jeff Hamilton2012-10-051-3/+7
| | | | | | | | This reverts commit c19efc204aee1f0f3164dc21bd2ef3fdd4259c71.
| * Merge "Changes to support updating location providers." into jb-mr1-devJeff Hamilton2012-10-041-7/+3
| |\
| | * Changes to support updating location providers.Jeff Hamilton2012-10-041-7/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | | Last position improvements for GeofenceManagerLaurent Tu2012-10-041-2/+5
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | Merge "Handle other providers in isAllowedProviderSafe()" into jb-mr1-devVictoria Lease2012-10-041-0/+20
|\ \
| * | Handle other providers in isAllowedProviderSafe()Laurent Tu2012-10-041-0/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | | Merge "multiuser support for LocationBlacklist" into jb-mr1-devVictoria Lease2012-10-041-0/+1
|\ \ \
| * | | multiuser support for LocationBlacklistVictoria Lease2012-10-041-0/+1
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | | Merge "throw SecurityException in isProviderEnabled()" into jb-mr1-devVictoria Lease2012-10-041-1/+6
|\ \ \ | |_|/ |/| |
| * | throw SecurityException in isProviderEnabled()Victoria Lease2012-10-041-1/+6
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* / Remove checkPermission() call in getAllProviders().Laurent Tu2012-10-021-3/+2
|/ | | | | | | | | | | | 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
* Merge "Route GPS notifications to all users." into jb-mr1-devVictoria Lease2012-10-011-0/+32
|\
| * Route GPS notifications to all users.Victoria Lease2012-10-011-0/+32
| | | | | | | | | | | | | | | | | | | | | | | | 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
* | Avoid NPE in GpsLocationProviderVictoria Lease2012-10-011-6/+6
|/ | | | | | | | | | | | | 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
* Fix for bug: #7173350. elapsedRealtimeNano() -> elapsedRealtimeNanos()Philip Milne2012-09-261-8/+1
| | | | Change-Id: Ie38952bbaace080e81e41e61350cda172951d548
* Merge "getBestProvider() prefers GPS over NLP" into jb-mr1-devVictoria Lease2012-09-261-3/+3
|\
| * getBestProvider() prefers GPS over NLPVictoria Lease2012-09-241-3/+3
| | | | | | | | | | | | | | | | | | 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
* | Merge "Allow apps to getProviders() without location permissions." into ↵Victoria Lease2012-09-241-13/+29
|\ \ | | | | | | | | | jb-mr1-dev
| * | Allow apps to getProviders() without location permissions.Victoria Lease2012-09-231-13/+29
| |/ | | | | | | | | | | | | | | | | | | | | | | 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
* / Do not use passive GPS data for COARSE only apps.Victoria Lease2012-09-211-36/+75
|/ | | | | | | | | | | | | | | | 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
* Require ACCESS_FINE_LOCATION for Geofence use.Victoria Lease2012-09-131-2/+13
| | | | | Bug: 7153226 Change-Id: I49236379e739fcda66bbc9a31cfdca9a87122aec
* Secure setting for LocationFudger's accuracyVictoria Lease2012-09-121-1/+1
| | | | | | | | | 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
* Fix GPS settings change listener in LocManagerBrian Muramatsu2012-09-041-22/+19
| | | | | | | | | | | | | | | 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
* Improve multi-user broadcasts.Dianne Hackborn2012-08-301-1/+3
| | | | | | | | | | | | | | | | | | | 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
* Remove unused IntentFilter in LocationManagerBrian Muramatsu2012-08-241-4/+0
| | | | | | | This intent filter isn't used anymore, since GpsLocationProvider handles the CONNECTIVITY_ACTION broadcasts now.. Change-Id: I593a9916aa6f8086b4d684cc3e25286c1cb137cc
* Fix some location issues exposed by CTS.Nick Pelly2012-08-211-1/+2
| | | | Change-Id: I5859ee2c9db5745b0a3bc8abfa8f08728fb25059
* Fix addGeofence() and addProximityAlert().Nick Pelly2012-08-171-4/+17
| | | | | | | Need to clear the callers identity before calling into geofence manager because it in turn calls fused location API's. Change-Id: I7993b0b8b2a947ff93c37a7c9d29ca0e7c95f9a8
* Port location blacklist code to MR1.Nick Pelly2012-08-171-5/+23
| | | | | | | | | | | | | | | | | | | | | | | | 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
* Add javadoc for new location API's.Nick Pelly2012-08-161-4/+9
| | | | Change-Id: If15024ee88421c07ba3a174747774fc451fd002e
* Improve coarse locations.Nick Pelly2012-08-161-121/+25
| | | | | | | | | | 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
* Fix a couple of bugs from the location overhaul.Nick Pelly2012-08-101-4/+0
| | | | | | | | | | Marshall LocationRequest array correctly. Observe reportLocation from FusionEngine. Actually deliver the setRequest message to fusion engine. Change-Id: Iff64596fdd42f9fb06e563591dda9fbe0241533a
* Location overhaul, major commit.Nick Pelly2012-08-101-1119/+807
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Pass changed NetworkInfo to LocationProvider.Jeff Sharkey2012-08-031-3/+2
| | | | | | | | LocationProviders often rely on non-default networks, so pass the network that actually changed, instead of the default. Bug: 6929692 Change-Id: I31d9eec792e07259282aa1bb57ec66c01962df64
* Improve Location object.Nick Pelly2012-07-201-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
generated by cgit v1.2.3 (git 2.25.1) at 2026-01-13 16:19:11 +0000