summaryrefslogtreecommitdiffstats
path: root/location
Commit message (Collapse)AuthorAgeFilesLines
* Annotate Locations coming from mock providersVictoria Lease2013-01-222-3/+28
| | | | | | | | | | 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
* New "app ops" service.Dianne Hackborn2013-01-092-3/+3
| | | | | | | | | | | | | | | | | | | | 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
* Revert "Move location provider lib to frameworks/ex - 1"Laurent Tu2012-12-118-0/+637
| | | | This reverts commit 578081f9da7ddb056b9b98524c639acd9194ecb6.
* Move location provider lib to frameworks/ex - 1Laurent Tu2012-12-058-637/+0
| | | | | | | | | Move location provider lib to frameworks/ex so it can be re-used in GmsCore. This is the frameworks/base part of the change (1). Change-Id: Ifc31a6809876e9c9afb6ed841b66cf06de7e8964
* am 4b77660b: am 7023b3b0: Merge "clarify Geofence.createCircle() param ↵Victoria Lease2012-11-291-2/+2
|\ | | | | | | | | | | | | ranges" into jb-mr1.1-dev * commit '4b77660b38cfff2ffb67c15db4c9e20adaac41d7': clarify Geofence.createCircle() param ranges
| * clarify Geofence.createCircle() param rangesVictoria Lease2012-11-271-2/+2
| | | | | | | | | | | | | | | | This commit adds the valid ranges to the latitude/longitude parameters in Geofence.createCircle()'s javadoc. Bug: 7172696 Change-Id: Iff6e3c3723d3fd9b6393bbc827ec5755c0d034af
* | am 768d9e1a: Merge "Correct executable bit for source files"Kenny Root2012-11-073-0/+0
|\ \ | |/ |/| | | | | * commit '768d9e1a72ceee7d4a5f608776b87b62d6ce4a04': Correct executable bit for source files
| * Correct executable bit for source filesKenny Root2012-11-073-0/+0
| | | | | | | | | | | | | | | | | | Many media files and source code files were marked as executable in Git. Remove those. Also a shell script and python script were not marked as executable. Change-Id: Ieb51bafb46c895a21d2e83696f5a901ba752b2c5
| * DO NOT MERGE. Add package-name-prefix blacklist for location updates.Nick Pelly2012-07-302-13/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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. Change-Id: I4ea2ad56fa6bd75d32151bc250ac25c26a5777c4
* | Hide new location APIs and undeprecate old onesLaurent Tu2012-11-018-153/+162
| | | | | | | | | | | | | | | | | | Hide all new location APIs related to LocationRequest/Geofence and undeprecate all deprecated APIs consequently to the LocationRequest and Geofence introduction. Also introduce LocationRequestUnbundled for LocationProviders to use. Change-Id: I5b116c7d342041f45b341c88a4b6813571118018
* | Merge "fix NLP for COARSE applications, build FLP with SDK" into jb-mr1-devVictoria Lease2012-11-012-0/+25
|\ \
| * | fix NLP for COARSE applications, build FLP with SDKVictoria Lease2012-11-012-0/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In this commit, we provide a means for unbundled location providers to attach an EXTRA_NO_GPS_LOCATION to the Locations that they report. We also build FusedLocation against the SDK rather than the internal tree. Used in conjunction with I394ded497b8de40d1f85618bff282553cdf378cb to fix NLP for applications with only ACCESS_COARSE_LOCATION permission. Bug: 7453355 Change-Id: Ie696f7abff9ef5237740ab87fe9f537a1c812c54
* | | docs: Clarify the callback mechanisms for LocationRequestScott Main2012-11-012-2/+10
|/ / | | | | | | | | | | and clarify horizontal geofencing Change-Id: I8ff264d7a12c8ec3c79854e008aeeb5f922ad459
* | revise android.location.Geofence documentationVictoria Lease2012-10-241-3/+1
| | | | | | | | | | Bug: 7172696 Change-Id: Ib1a104ee4a97c51996200b8d456face66178115f
* | LocationManager javadoc permission fixesVictoria Lease2012-10-221-23/+9
| | | | | | | | | | | | | | | | | | The javadoc mistakenly claimed that GPS and PASSIVE location providers could be used with ACCESS_COARSE_LOCATION permissions. That was incorrect, and the javadoc has been amended. Bug: 7389249 Change-Id: I6f6489bb539679a962c67ae7263857700df33c82
* | LocationManager permissions cleanupVictoria Lease2012-10-181-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | Prevent overflow in LocationRequest.setExpireIn()Laurent Tu2012-10-041-1/+9
| | | | | | | | | | | | | | | | Prevent overflow in LocationRequest.setExpireIn(), for example, when we pass in Long.MAX_VALUE. Bug: 7047435 Change-Id: Ie56928a59fb387173fbd3887c0ef9aede00f8152
* | Route GPS notifications to all users.Victoria Lease2012-10-011-6/+3
| | | | | | | | | | | | | | | | | | | | | | | | 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
* | Fix for bug: #7173350. elapsedRealtimeNano() -> elapsedRealtimeNanos()Philip Milne2012-09-262-16/+16
| | | | | | | | Change-Id: Ie38952bbaace080e81e41e61350cda172951d548
* | Fix for bug: #7172778. Javadoc errors in LocationManager.Philip Milne2012-09-251-13/+17
| | | | | | | | Change-Id: Iaebd4cf00c8a33bcf4fc74eaa1dfec9675032826
* | Merge "Revert "Fix for bug: #7173350. elapsedRealtimeNano() -> ↵Philip Milne2012-09-241-2/+2
|\ \ | | | | | | | | | elapsedRealtimeNanos()"" into jb-mr1-dev
| * | Revert "Fix for bug: #7173350. elapsedRealtimeNano() -> elapsedRealtimeNanos()"Philip Milne2012-09-241-2/+2
| | | | | | | | | | | | | | | | | | This reverts commit 2f6d8829524dfca3a77e9a57c3b9c3862209877d Change-Id: Id5af767a09fc319127c4ebef837c5b7a7f75cb01
* | | Merge "Fix for bug: #7173350. elapsedRealtimeNano() -> ↵Philip Milne2012-09-241-2/+2
|\ \ \ | |/ / | | | | | | elapsedRealtimeNanos()" into jb-mr1-dev
| * | Fix for bug: #7173350. elapsedRealtimeNano() -> elapsedRealtimeNanos()Philip Milne2012-09-211-2/+2
| | | | | | | | | | | | Change-Id: I71c24ea10093ece07a0780e97bc641ff548c1a44
* | | Merge "Do not use passive GPS data for COARSE only apps." into jb-mr1-devVictoria Lease2012-09-232-1/+43
|\ \ \ | |/ / |/| |
| * | Do not use passive GPS data for COARSE only apps.Victoria Lease2012-09-212-1/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | | API REVIEW: Undeprecate Location.dump()Romain Guy2012-09-211-5/+1
|/ / | | | | | | | | | | Bug #7173109 Change-Id: Ia2f4a5b6255dae7ace4702f7d66ec30a077c9c79
* | Require ACCESS_FINE_LOCATION for Geofence use.Victoria Lease2012-09-131-5/+22
| | | | | | | | | | Bug: 7153226 Change-Id: I49236379e739fcda66bbc9a31cfdca9a87122aec
* | Fix some location issues exposed by CTS.Nick Pelly2012-08-211-1/+1
| | | | | | | | Change-Id: I5859ee2c9db5745b0a3bc8abfa8f08728fb25059
* | Print timestamp (instead of age) in Location#toString()Nick Pelly2012-08-211-3/+2
| | | | | | | | | | | | Age was a bad idea, since it depends when toString() was called Change-Id: Ica0b6bfa9a93b5a452ba3def5fbb2b0a0194c401
* | Port location blacklist code to MR1.Nick Pelly2012-08-172-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 documentation for com.android.location.provider shared library.Nick Pelly2012-08-165-13/+61
| | | | | | | | Change-Id: I222d61811c88272e84a85512623210c0238337e5
* | Add javadoc for new location API's.Nick Pelly2012-08-165-509/+828
| | | | | | | | Change-Id: If15024ee88421c07ba3a174747774fc451fd002e
* | Improve coarse locations.Nick Pelly2012-08-161-14/+0
| | | | | | | | | | | | | | | | | | | | 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-102-6/+9
| | | | | | | | | | | | | | | | | | | | Marshall LocationRequest array correctly. Observe reportLocation from FusionEngine. Actually deliver the setRequest message to fusion engine. Change-Id: Iff64596fdd42f9fb06e563591dda9fbe0241533a
* | Remove LocationManager#getLastKnownLocation(Criteria).Nick Pelly2012-08-101-30/+0
| | | | | | | | | | | | | | | | | | | | | | This was never a public API, so we don't need to follow an orderly deprecation. And it breaks a CTS test: cts/tests/tests/location/src/android/location/cts/LocationManagerTest.java:521: reference to getLastKnownLocation is ambiguous, both method getLastKnownLocation(java.lang.String) in android.location.LocationManager and method getLastKnownLocation(android.location.Criteria) in android.location.LocationManager match mManager.getLastKnownLocation(null); ^ Change-Id: I503267e4fa577ce4bf684239da777f11b0e511f5
* | Location overhaul, major commit.Nick Pelly2012-08-1020-872/+1711
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | Improve Location object.Nick Pelly2012-07-202-10/+118
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | Improve geofencing: throttle location updates with distance to fence.Nick Pelly2012-07-163-6/+28
|/ | | | | | | | | | | | | | | | | | | | | 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
* docs: fix several linksScott Main2012-06-221-1/+1
| | | | Change-Id: I89d9fd64dc22c90680bb05415cc966c255165af9
* Enforce the minTime parameter in LocationManager#requestLocationUpdatesNick Pelly2012-05-171-134/+259
| | | | | | | | | | | | | | | | | | 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
* docs: Add developer guide cross-references, Project ACRE, round 4Joe Fernandez2011-12-223-3/+17
| | | | Change-Id: I1b43414aaec8ea217b39a0d780c80a25409d0991
* Cherry-picking Id45abeba and Ia065dec6 for MR1Makoto Onuki2011-12-131-4/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | ------------------------------------------------------- MCC detection fixes for CountryDetector - Don't get and cache phone tpe at the initialization time. At this point TelephonyManager is probably not ready yet. - Refresh MCC whenever we get the service state changed callback, even when the state hasn't actually changed, in order to make sure we get refresh country properly when MCC changes. - Also remove the initialization of mPhoneStateListener, which prevented us from registering phone state listener properly. - Also fix tests which were already failing. Bug 5670680 ------------------------------------------------------- Add logging to country detector logic This is for debugging purposes to verify the effects of change Id45abeba1b1e843053ac2c946861b439ca568de4. Bug: 5670680 Change-Id: I238d953484e2c8135f7dac70fce8662c8300a286
* Acknowledge that the platform guarantees UTF-8 and UTF-16.Jesse Wilson2011-07-191-2/+2
| | | | | | | | These log statements were dead code. That isn't much of a problem, except that the 'e.getMessage()' that was being logged could be null, and that would cause a real problem. Change-Id: I8573bc687a7eda73782bd028e8ddc048a1954dc5
* am e0009bb0: am 98395483: am 9f2cbf14: am e06749e1: Merge "Add ↵Conley Owens2011-07-011-1/+1
|\ | | | | | | | | | | | | FLAG_AUTO_CANCEL flag for multiple supl notifications." * commit 'e0009bb0b700dcfeba3ff77f8c33113499674432': Add FLAG_AUTO_CANCEL flag for multiple supl notifications.
| * am 98395483: am 9f2cbf14: am e06749e1: Merge "Add FLAG_AUTO_CANCEL flag for ↵Conley Owens2011-06-301-1/+1
| |\ | | | | | | | | | | | | | | | | | | multiple supl notifications." * commit '98395483e4309f7b92348136491575861008b3c0': Add FLAG_AUTO_CANCEL flag for multiple supl notifications.
| | * Add FLAG_AUTO_CANCEL flag for multiple supl notifications.Anshuman Pandey2011-06-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | Added FLAG_AUTO_CANCEL to notification flags in GpsNetInitiatedHandler.java. This is done to clear consecutive notifications in UI Change-Id: I84be36af0b556f43ffd7d51ac04ff12300090ca5 Signed-off-by: Anshuman Pandey <anshuman.pandey@stericsson.com> Signed-off-by: Christian Bejram <christian.bejram@stericsson.com>
| * | Fix the javadoc for LocationManager.requestSingleUpdate()Amith Yamasani2011-03-291-22/+26
| | | | | | | | | | | | | | | | | | It was saying the same thing as requestLocationUpdates(), but it only provides a single update. Change-Id: I0a0f612104a946b7db96928505bb95673377a335
* | | Use upper case country codes in Country.javaDaisuke Miyakawa2011-06-271-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously external/libphonenumber accepted lower case country codes (e.g. "us") but now it doesn't for performance reason. Actually ISO 3166-1 doesn't allow lower cases, so we should not rely on them. Need to fix unit tests for PhoneNumberUtils, as it implicitly relies on the previous behavior. See also I3a3e6db84ed0d24290b1be19651fa9a82de4cc39 Bug: 4941319 Change-Id: If16f6531f274a0faf5e28724854409ca9b00a669
* | | Use passive provider for location based country detectionDaisuke Miyakawa2011-04-281-3/+3
| | | | | | | | | | | | | | | Bug: 4345419 Change-Id: Ia3e071b97c6971538ea994fdee6029db928201d6
generated by cgit v1.1 at 2024-12-26 17:22:48 +0000