I need to send what businesses the user is currently at every 5 minutes. I am using the Google Places library and can successfully grab the businesses. The problem is this service needs to be going 24/7.
My solution so far is to use a service called from my main activity. This service will subscribe to background location updates every 5 minutes. Once the location update comes through, it will ask the Google Place library for the businesses the user is currently at. I am using the Google Play Services to subscribe to these location updates. I read that using an Alarm for something like this isn't recommended, that is why I am subscribing to location updates to give me a pseudo setTimeout(5mins) behavior. I am actually not even using the GPS returned, just the function callback to ask GooglePlaces.
The problem is that this service is unbelievably unreliable. I am running Android 8.0 with 11.2.0 play services installed. The service's OnDestroy is called within a few minutes and is never restarted even though I return Start_sticky from the service OnStartCommand. Are services supposed to get killed this quickly? I have no other apps open and the service is 99% of the time just idle waiting for the location tick to come through.
Is there a better way to do this? All I really need is a function called every 5 minutes so I can ask Google Place where the user is at. It doesn't even have to be location related. The only requirements are it runs even when the app is closed.
Try to use AlarmManager with service... try this once maybe it will solve your problem.
Thanks!!!
My solution was to use AlarmManager started from my Activity. No Services needed.
Related
I am working on tracking app where i get the location update in background mode from gps.
I have search on google i found that Android 12 - Foreground service launch restrictions.
So you have use Work manager insted of foreground intentService.
And workManager minimum limit is 15 minutues for WorkManager Periodicity. Then how can i get location update every seconds in background mode.
Because workmanager request not run every seconds.
Thank you.
When you are actively tracking the user you should use a Foreground Service. WorkManager is for cases where you care for the Work to finish, but the priority will be to save the battery.
I can assure you that WorkManager is the wrong API for you.
Why do you need to start the service from the background? What is your exact use case?
Check here:
https://developer.android.com/guide/background#replacing-foregound
Some use cases for using foreground services directly are as follows:
Media playback
Activity tracking
Location sharing
Voice or video calls
I have an application that is required to log the user's location every couple of seconds, the entire time it is on.
On does not mean in the foreground,or that even the Android's screen is on.
What is the suggested way to accomplish it?
I've heard of background and foreground services, and also saw something about Jobs. I also saw this was possible with a WakeLock.
I am not sure what is the best method of choice.
The need to conserve Battery life is of course an issue.
You should use Service, you can choose that the service wil keep running even after your app was closed.
YET if the device is low on resources it might close your service.
you can use FOREGROUND service if you want to minimize the chance android will close your service.
inside the service use LocationManager / FusedLocation to get the location every X time.
you set it up with LocationListener so everytime it set onLocationChanged you upload to firebase.
Useful links:
Make your app loaction aware
Services
My goal
Get user location updates for quite long time (e.g. 8 hours) with quite high frequency (e.g. every 30 seconds) even when the application is not running in foreground (meaning the activity where the location tracking was started might be destroyed).
Issue
I've found many articles regarding location tracking in Android apps.
The newer ones usually explain how to use Google Play Services' location APIs.
The problem is that in most cases, they demonstrate getting location updates in co-operation with Activity and LocationListener. For example in Google's tutorial. It's obvious this is not what I need. The only approach for long-running background location updates was based on periodical starting (via AlarmManager) of a service that run until it got accurate enough location update. However, this approach doesn't seem right for the frequency I need.
So, I ended up with custom idea how to solve the topic, but your critique would be welcomed. Here it is:
Idea of a possible solution
MainActivity - used just for starting/stopping the tracking by starting/stopping the MonitoringService
MonitoringService - a foreground service, where the whole connecting to LocationServices from Google Play services happens. Also, once connected a requestLocationUpdates method is called, but its variant with PendingIntent object. The pending intent contains intent invoking MyWakefulBroadcastReceiver class. Also, the service holds a partial wake_lock to prevent the device going to sleep and interrupting receiving of the location updates. Here, I'm not sure if holding the wake lock really helps.
MyWakefulBroadcastReceiver - extends WakefulBroadcastReceiver, just starts LocationProcessingIntentService via the startWakefulService
LocationProcessingIntentService - processes the location update passed via intent to it. Network communication performed here. Therefore, it is done in separate service and not directly in the MonitoringService
Currently, I have the solution described above implemented without acquiring the partial wake lock in the MonitoringService. When connected to debugger in Android Studio, I see the processing of the location updates work. However, I'm not sure what it will do after e.g. 4 hours of running without being connected to laptop (like it is for the debugging purposes)
Questions
Is this approach OK from architecture/performance/battery life point of view?
Should I use the wake lock for being sure the device won't go to sleep?
If answer to 2. is yes, do I still need to use WakefulBroadcastReceiver for starting the IntentService processing the location updates?
Any other recommendations?
What you have is mostly fine. You don't need the MonitoringService. The PendingIntent will wake your BroadcastReceiver, regardless of the state of your app. You don't need a permanent wake-lock. Just use the PendingIntent in your setup Activity to requestLocationUpdates.
Remember that the location services are already running in the background (as long as the user has enabled location services), so you don't need to run your permanent wake-lock service also (you can wake-lock after BroadcastReceiver#onReceive(), but don't forget to release the wake-lock after processing).
The only time you might have to worry about the PendingIntent not waking your BroadcastReceiver is if the user force-stops your app. In that case, you could choose to respect the user's decision. You can also explore using intent.addFlags(Intent.FLAG_INCLUDE_STOPPED_PACKAGES); which should wake your BroadcastReceiver from the stopped state, but I haven't tested this flag in this scenario.
I would like to notify my users of new content available in the latest version of my android game without using an external service like Push Notifications.
What I would like to do as a first step to achieve this is to just create a standard notification on application update.
This brings me to my question: is it possible to start a service the first time a user launches the game and then just keep it running indefinitely? I want to even keep it running after an update completes. Since it is possible that the code for the service may have changed between versions, would I need to stop the old version of the service manually and start the new version? Is it possible to even do something like this where the event that drives initiation of the service is the completion of an app upate?
My plan is to have this service check some persisted data about the last time the user was notified about new content and based on this I will be able to determine if a notification should be created for them after they update.
It's important that they are not required to go back into the game after update in order for the notification to be created. This is the problem that I am having now. Auto-updates occur and they don't know and hence also don't know that there are new stages, etc, available so they never go back into the game if they were already done with the previously available content.
It seems that games like Family Guy have got this approach working, but I am not sure if they implemented it in this way. Even after I update it, I will still get notifications even if I have not actually executed the app since update.
Services are mostly killed when other process needs the resources. Therefore use
startForground(...)
for running Services indefintly on background.
See here: http://developer.android.com/reference/android/app/Service.html#startForeground(int, android.app.Notification)
What you can do is use the AlarmManager in your service that notifies you at certain time. Start the service, do the task and set again an alarm to notify you. In this way, you'll be able to run your service infinitely at periodic time.
I started redacting this answer on GameDev Stack Exchange before you
deleted the question. Unlike the guy who told you to delete, i thought it was an interesting question even for game dev stack exchange.
What you describe is a bad practice on android. I don't believe any game do that. What's more, android require "service" app to run as ForegroundService (This force you to display you app icon in the notification bar, so that users are always aware of running services) It can also be randomly be killed when the system lacks memory. However it can be implemented nicely using Alarms and AlarmManager.
Services and Notifications :
You can however schedule intents when the app is running, with AlarmManager, this is the good practice. Let's take a simple exemple : Candy Crush.
In Candy Crush, when you lose your last life, every 30 minutes you regain one, and have a limit of 5 lives. You want to notify the user when all his lives are back. How to do that ?
Exemple 1 :
When the user lose his last life or quit the game, schedule an intent with AlarmManager in (5-number_of_life)*30 minutes that will fire a local notification.
Exemple 2 :
Schedule an intent with AlarmManager every 30 minutes to check the number of lives, and fire a notification when the user have 5 lives again.
Using a Boot receiver may also allow you to schedule things as soon as the device boot.
However, users expects to be able to disable this kind of features.
Updates :
If you want your app to notify users when an update is available, you'll need to somehow check on the internet with a request on your server. You may schedule an intent again with alarm manager to check regularly if the update is available. If the user is ingame, you can also check it more regularly.
A lot of "online" games do that, and simply force the user to download the new update from the Play Store, before they can play again.
I need to keep rough track of a users position, but not really in real time. It's sufficient to handle the location updates when the app is started. However, I still need to know where the user was when the app wasn't running.
Is there a way to get the location history in an app?
I don't really want to have a service just polling last known location all the time since that would be a waste of battery power.
However, I still need to know where the user was when the app wasn't running.
That is not possible.
I don't really want to have a service just polling last known location all the time since that would be a waste of battery power.
Then eliminate your requirement for location history. You only get the locations that you request.
Rough Track can mean you get location of the user (lastKnown or Fresh) after every n-hours. Doing this will not require a service, simply a recurring alarm and receiver will do. In the onReceive method of receiver, you can manage a stack of locations in your app.
You will have to reset the alarm though when the device re-boots. I guess this is an add-on, rest should work fine.
you can not get current location without running your app...
the second way is to make background service ..wich you don't wan't to make...
The other way is to run background service using Alarammanager whenever you want after getting location you can stop the service...like you can make call every hour or 2 times per day...