I want to get a hard location fix every certain minutes & a soft location fix every certain minutes and if user has moved more then certain meters. I been testing the logic with following piece of code walking (tried it with larger parameters as well while driving) but it doesn't really return me periodic location fixes. It would return a location fix right away when request starts then sometime return 1 location fix few minutes later that but then for up-to an hour it won't return a location fix.
LocationRequest locationRequest = LocationRequest.create();
int priority = PRIORITY_BALANCED_POWER_ACCURACY;
locationRequest.setPriority(priority);
locationRequest.setInterval(localInterval); //set to 6 minutes
locationRequest.setFastestInterval(localFastestInterval); //set to 3 minutes
locationRequest.setSmallestDisplacement(smallestDisplacement); //set to 10 meters
locationRequest.setNumUpdates(numUpdates); //set to Int.MAX_VALUE
locationRequest.setExpirationDuration(expirationDuration); // set to Long.MAX_VALUE
LocationServices.FusedLocationApi.requestLocationUpdates(locationClient, locationRequest, pendingIntent);
If I set displacement to 0 then I get periodic location updates. Any idea what is going on?
After long exhaustive testing & experimentation I've found that if you don't call setFastestInterval you will get periodic updates exactly according to the interval set with setInterval.
However as other applications can cause location fixes to be delivered very fast to you so just put a check for ignoring location fixes delivered faster than a certain threshold of time passed.
According to documentation: If setFastestInterval(long) is set slower than setInterval(long), then your effective fastest interval is setInterval(long) but that doesn’t happen: e.g. setting following parameters should give you a hard location fix every 1 minute but it does not (on Marshmallow at-least):
interval = 1 min
fastestInterval = 20 min
displacement = 0
If anyone can disprove my findings with a piece of code that would be great.
My requirement is to check the location of the device every 10 minutes using a background service. So the basic gist of what should happen every 10 minutes is this -
Start the service.
Wait a minute (maximum) for the listener to get a location, once the location is taken, remove the listener and then stop the service.
If the listener doesn't respond, use getLastKnownLocation(), remove the listener and then stop the service.
If the GPS is off, it reports to the app (this step is working fine)
What I have tried doing till now -
Made a service which is triggered every 10 minutes using an AlarmManager
Added a Location Listener inside this service.
onLocationChanged() from the LocationListener has the method - stopSelf() included, so that the service ends after receiving a location. However, this method is called a numerous times. I checked that while debugging. Is this because there are many instances of onLocationChanged() called ?
I don't need an entire code as the answer, I would rather appreciate a strategy I should adopt which will fulfil my requirements without hurting the battery much. As with my approach, unless and until the location is found, the GPS remains ON draining the battery constantly.
Instead of alarm manager which is scheduling each 10 min, use the FusedLocationAPI and location request in order to get accurate location.
LocationRequest mLocationRequest = LocationRequest.create();
mLocationRequest.setPriority(LocationRequest.PRIORITY_BALANCED_POWER_ACCURACY);//Change to PRIORITY_HIGH_ACCURACY for more accurate.
mLocationRequest.setInterval(600000); // Update location every 10 minute
LocationServices.FusedLocationApi.requestLocationUpdates(
mGoogleApiClient, mLocationRequest, this);
Call this method whenever you need the location
/**
* Get the Location Detail from Fused Location API.
* #param mContext
* #return
*/
private Location getLocationDetails(Context mContext) {
Location location = null;
if (mGoogleApiClient != null) {
if (ActivityCompat.checkSelfPermission(mContext, Manifest.permission.ACCESS_FINE_LOCATION) != PackageManager.PERMISSION_GRANTED && ActivityCompat.checkSelfPermission(mContext, Manifest.permission.ACCESS_COARSE_LOCATION) != PackageManager.PERMISSION_GRANTED) {
Log.d(TAG,"Location Permission Denied");
return null;
}else {
location = LocationServices.FusedLocationApi.getLastLocation(mGoogleApiClient);
}
}
return location;
}
try with this
// The minimum distance to change updates in meters
private static final long MIN_DISTANCE_CHANGE_FOR_UPDATES = 10; // 10 meters
// The minimum time between updates in milliseconds
private static final long MIN_TIME_BW_UPDATES = 1000 * 60 * 10; // 10 minute
for more info example try with this
Try with this link click here
onLocationChanged() from the LocationListener has the method - stopSelf() included, so that the service ends after receiving a location. However, this method is called a numerous times. I checked that while debugging. Is this because there are many instances of onLocationChanged() called ?
Basically, when you receive the first location, also stopping the service via stopSelf() thats okay too.
But how the onLocationChanged method being called numerous time ?
Dont you remove location updates when the service shutting down ?
I need to ensure the location I use is fresh:
Is there a way of finding out how old the location result returned by LocationServices.FusedLocationApi.getLastLocation is?
If not: if I register a location listener to the LocationServices.FusedLocationApi.requestLocationUpdates (with setNumUpdates(1) and setMaxWaitTime(0)) then will it update if the location has not changed from the one returned by LocationServices.FusedLocationApi.getLastLocation?
Yes, there is a very easy way. You can get the time of a Location fix by calling getTime() like this:
Location currentLocation = LocationServices.FusedLocationApi.getLastLocation(apiClient);
long locationAge = System.currentTimeMillis() - currentLocation.getTime();
if (locationAge <= 60 * 1000) { // not older than 60 seconds
// do something with the location
}
The documentation recommends not to use System.currentTimeMillis() for time comparisons, but I never experienced any flaws with this method. However, you should consider reading the (short) documentation:
https://developer.android.com/reference/android/location/Location.html#getTime()
To expand on Illiminat's answer, as of API 17 the getElapsedRealtimeNanos() method has been added. From the documentation of the method...
Return the time of this fix, in elapsed real-time since system boot.
This value can be reliably compared to SystemClock.elapsedRealtimeNanos(), to calculate the age of a fix and to compare Location fixes. This is reliable because elapsed real-time is guaranteed monotonic for each system boot and continues to increment even when the system is in deep sleep (unlike getTime().
https://developer.android.com/reference/android/location/Location.html#getElapsedRealtimeNanos()
Therefore the following should now be the most precise way of doing calculating this
Location currentLocation = LocationServices.FusedLocationApi.getLastLocation(apiClient);
long locationAge = SystemClock.elapsedRealtimeNanos() - currentLocation.getElapsedRealtimeNanos();
long ageLimitNanoSec = 60_000_000_000; // 60 seconds in nano seconds
if (locationAge <= ageLimitNanoSec) {
// do something with the location
}
Hi I want get user location for every 5sec and user can change that duration like 10sec, 15sec upto 30sec i have spinner to choose this option
this is my request
private static final LocationRequest REQUEST = LocationRequest.create()
.setInterval(5000) // 5 seconds
.setFastestInterval(16) // 16ms = 60fps
.setPriority(LocationRequest.PRIORITY_HIGH_ACCURACY);
this is initiate my start update
private void startPeriodicUpdates(int intervel) {
stopPeriodicUpdates();
REQUEST.setInterval(intervel);
mLocationClient.requestLocationUpdates(REQUEST, this);
// mConnectionState.setText(R.string.location_requested);
}
I can pass user selected interval to startPeriodicUpdates() method like startPeriodicUpdates(5000), startPeriodicUpdates(15000). But they location update duration working fine 15sec and more than 15sec
If i give 5sec or 10 sec the location update is running for every second
06-18 18:46:23.638: I/Location(2860): Location Changed Location[fused 65.966697,-18.533300 acc=4 et=+1h0m13s881ms alt=15.044444]
06-18 18:46:24.642: I/Location(2860): Location Changed Location[fused 65.966697,-18.533300 acc=4 et=+1h0m14s883ms alt=15.044444]
06-18 18:46:25.642: I/Location(2860): Location Changed Location[fused 65.966697,-18.533300 acc=4 et=+1h0m15s883ms alt=15.044444]
log show time interval for 23, 24, 25 please give your ideas.
The setInterval method is not exact. This is mentioned in the documentation.
Also, use the same interval for setFastestInterval and setInterval to prevent your app from receiving location updates faster than the the interval you specified in setInterval.
Just add REQUEST.setFastestInterval(intervel); to your startPeriodicUpdates method.
Edit: I'm rewriting this question because I apparently wasn't clear.
Sometimes the GPS service on Android phones takes a long time to get a fix. Sometimes it's fast, sometimes it takes hours. I know and accept this.
I have an application that does many things. One of the things it must do is allow the user to click a button to send their current coordinates to a server. What I need are the coordinates of the phone when the user clicks the button or within a reasonably short time thereafter.
Because I know that getting a GPS fix is not instant and I know that it could take minutes or hours (during which the user has moved a great distance), I need to code a timeout for this feature. For this feature, it is simply not acceptable to upload the GPS location of the user three minutes (for example) after they clicked the button. It's fine if it takes 45 seconds, not okay if it takes 75 seconds. It's fine to give the user an error notification if the feature failed to get a location fast enough.
I need a feature to 'get the GPS location and send it to the server, unless it takes more than one minute'.
My original code is below. I have changed some things since posting it. I have added a Timer in the onStartCommand() method. I start a TimerTask that after 60 seconds will call my stop() method. At the beginning of the onLocationChanged() method, I cancel the TimerTask.
My question is: Is the Timer scheme a good way of implementing this timeout? Is there a better way?
Original question:
I'm writing an Android application that, among other things, needs to send the current GPS coordinates to a server when the user tells it to. From a context menu, I run the service below. The service is a LocationListener and requests updates from the LocationManager. When it gets a location (onLocationChanged()), it removes itself as a listener and sends the coordinates off to the server. All of this is working.
However, if GPS coordinates are not quickly available, my service just keeps running until it gets some. It holds up the UI with a progress dialog, which is annoying. Worse, if the user has moved since starting the service, the first GPS coordinates might be wrong and the app will send bad data to the server.
I need a timeout on the service. Is there a good way to do that? I'm not very experienced with threads. I think I can run a Runnable in the onStartCommand() method that will somehow count down 30 seconds and then, if there is no GPS result yet, call my service's stop() method. Does that sound like the best way to do this?
Alternatively, is it possible to tell if the GPS cannot get a fix? How would I go about doing that?
Edit: To further clarify, I'm looking for the best way to "give up" on getting a Location after some amount of time.
public class AddCurrentLocation extends Service implements LocationListener {
Application app;
LocationManager mLocManager;
ProgressDialog mDialog;
#Override
public int onStartCommand(Intent intent, int arg0, int arg1) {
app = getApplication();
// show progress dialog
if (app.getScreen() != null) {
mDialog = ProgressDialog.show(app.getScreen(), "", "Adding Location. Please wait...", true);
}
// find GPS service and start listening
Criteria criteria = new Criteria();
criteria.setAccuracy(Criteria.ACCURACY_FINE);
mLocManager = (LocationManager) getSystemService(Context.LOCATION_SERVICE);
String bestProvider = mLocManager.getBestProvider(criteria, true);
mLocManager.requestLocationUpdates(bestProvider, 2000, 0, this);
return START_NOT_STICKY;
}
private void stop() {
mLocManager.removeUpdates(this);
if (mDialog != null) {
mDialog.dismiss();
}
stopSelf();
}
#Override
public void onLocationChanged(Location location) {
// done with GPS stop listening
mLocManager.removeUpdates(this);
sendLocation(location); // method to send info to server
stop();
}
// other required methods and sendLocation() ...
}
That's not really how it works. It will consistently take that long in most situations to get a GPS fix. But from that point on each update (every 2 sec in your code)will be the person's current position. And the first fix you get will be the person's current position, so the data will not be "out of date".
Another thing. If you are running this code in a service you shouldn't block the UI with a progress dialog and definitely not from the Service. That is a memory leak waiting to happen. You should only show progress if it is something that might take 5 sec at the most and is running in a thread in the Activity. Another option is to show the progress dialog in the title bar, and still let the user interact with the app (which is why you use a service anyway). Showing progresses for a long period of time really isn't that User Friendly. Especially if they somehow change orientation (maybe on accident) and then your app crashes because of the service handle to the dialog and they have to start over.
Take a look at the Google I/O 2010 app to see a great example of how an activity should work with a service. It uses a service to pull back data, and shows a progress in the title while the service is doing some work. And still lets you do other things in the app.
Scott, there are many factors that affect how long a first fix can take - or even whether a fix can be achieved, the most common being physical obstacles between the device and satellites (sucha s buildings, canyon walls, etc).
You can't control how long it takes for the GPS engine to deliver a fix, but you can tell how its doing, including time of first fix:
locationManager.addGpsStatusListener(gpsListener);
// this reports on the status of the GPS engine, but does not enable additional controls
private static final GpsStatus.Listener gpsListener = new GpsStatus.Listener() {
public void onGpsStatusChanged(int event) {
GpsStatus gpsStatus = locationManager.getGpsStatus(null);
switch (event) {
case GpsStatus.GPS_EVENT_STARTED:
Log.i(TAG, "onGpsStatusChanged(): GPS started");
break;
case GpsStatus.GPS_EVENT_FIRST_FIX:
Log.i(TAG, "onGpsStatusChanged(): time to first fix in ms = " + gpsStatus.getTimeToFirstFix());
break;
case GpsStatus.GPS_EVENT_SATELLITE_STATUS:
// int maxSatellites = gpsStatus.getMaxSatellites(); // appears fixed at 255
// if (H.DEBUG) Log.d(TAG, "onGpsStatusChanged(): max sats = " + maxSatellites);
if (H.VERBOSE) Log.d(TAG, "onGpsStatusChanged(): ##,used,s/n,az,el");
Iterable<GpsSatellite>satellites = gpsStatus.getSatellites();
Iterator<GpsSatellite>satI = satellites.iterator();
while (satI.hasNext()) {
GpsSatellite satellite = satI.next();
if (H.VERBOSE) Log.d(TAG, "onGpsStatusChanged(): " + satellite.getPrn() + "," + satellite.usedInFix() + "," + satellite.getSnr() + "," + satellite.getAzimuth() + "," + satellite.getElevation());
// http://en.wikipedia.org/wiki/Global_Positioning_System: the almanac consists of coarse orbit and status information for each satellite
// http://en.wikipedia.org/wiki/Ephemeris: the positions of astronomical objects in the sky at a given time
// + "," + satellite.hasAlmanac() + "," + satellite.hasEphemeris());
}
break;
case GpsStatus.GPS_EVENT_STOPPED:
Log.i(TAG, "onGpsStatusChanged(): GPS stopped");
break;
}
}
};
Events will be generated as the engine attempts to listen to available satellites. On a recent test of this with light obstacles I found it took 22.4 seconds to get an initial fix, during which 24 SATELLITE_STATUS events reporting the gradual access of 8 satellites before sufficiently clean signals were received to achieve the fix. Here is the last event:
06-08 23:23:25.147,D,GPS,22427,"onGpsStatusChanged(): ##,used,s/n,az,el"
06-08 23:23:25.147,D,GPS,22427,"onGpsStatusChanged(): 2,true,26.0,57.0,73.0"
06-08 23:23:25.147,D,GPS,22427,"onGpsStatusChanged(): 4,true,30.0,46.0,27.0"
06-08 23:23:25.147,D,GPS,22427,"onGpsStatusChanged(): 5,true,19.0,144.0,25.0"
06-08 23:23:25.155,D,GPS,22427,"onGpsStatusChanged(): 9,true,22.0,202.0,22.0"
06-08 23:23:25.155,D,GPS,22427,"onGpsStatusChanged(): 10,true,17.0,109.0,32.0"
06-08 23:23:25.155,D,GPS,22427,"onGpsStatusChanged(): 12,true,32.0,320.0,80.0"
06-08 23:23:25.155,D,GPS,22427,"onGpsStatusChanged(): 29,true,21.0,278.0,21.0"
06-08 23:23:25.155,D,GPS,22427,"onGpsStatusChanged(): 30,true,31.0,312.0,43.0"
06-08 23:23:25.163,D,GpsLocationProvider,1039,TTFF: 22457
06-08 23:23:25.194,I,GPS,22427,onGpsStatusChanged(): time to first fix in ms = 22457
Note that at fix time, you will be getting the current location, not where you once may have been. I think along with what you have already you can get there now. Or, check out how the pros do it here.
There is a example about get GPS location with timeout.
http://sikazi.blogspot.com/2010/09/android-gps-timeout.html#more
I have been struggling with a similar issue and recently switched from a timer to an AlarmManager, which appears to be much more robust. That might be overkill for your situation (I am using this for repeated location sampling), but you might want to at least use a Handler instead of the timer. (Use Handler.postDelayed.)