I have to work on a project Where I have to upload users' locations every 15 minutes. For that, I searched a lot and found Recurring work with PeriodicWorkRequest. But the problem is that the WorkManager might not work when the app is closed/killed per the answer given here. Then I found about Service in android.
So I want to know If I want to send users' locations every 15 min even when the app is killed then how to approach this?
If an application is Force Stopped, the OS cancel all the Job related to that application. This is not a WorkManager only problem. The OS interprets a Force Stop as an user request to the OS that they don't want this application to run anymore.
Even if you use JobScheduler or a Service, the application is gone. But a force stop should be a user decision.
Some OEMs have implemented in the past some changes to the Android OS so that a swipe out of an application from the launcher was interpreted as a force stop with all the negative effects on scheduled jobs. This is where the problems start.
WorkManager is this case has implemented some mitigation, but the application cannot do anything if it is force stopped till the user launch it again.
If have a problem with a specific OEMs, please open an issue on the Android issuetracker as this maybe a CDD violation. Google can contact the OEM and request that they fix the ROM. This is going to take time, in the meanwhile, you can take a look at sites like don't kill my app to understand what are the constraints on a specific device and use a library like autostarter to help the user to navigate to the right setting.
Related
I want to get the location of the device once when the service is running in the background (the tracker monitors the change in the database and then executes the code that should get the geolocation of the phone). I encountered a problem: the program receives location data when the application is running, but when it goes into the background, the location data stops being received in a few seconds. I tried all the codes and options that I could find, but everything stops working when the program goes into the background. For this I use AndroidStudio Java. So how do I implement this and is it even possible? Thanks.
On Android there are two types of Services- foreground and background. Background (the default) on modern Android are killed 2 minutes after your app is no longer in the foreground. Foreground services are kept for longer, require you to have a notification so the user knows you're tacking him (think of Uber and the notification you can't swipe away you get while its running), but can still be killed for resources if other apps need it. You cannot rely on any Service running permanently.
So the answer is going to be either Foreground Service, or its going to be a completely different architecture for your program. The second really depends on exactly when and why you want to get the location.
There are many limitations on getting on getting location in background, refer to this
Do you target API level 29 or up? if yes, have you add ACCESS_BACKGROUND_LOCATION permission in manifest? If this is not declared, app can only access location while in foreground.
Even after declaring ACCESS_BACKGROUND_LOCATION permission, app can only get location data a few time in an hour due to limitations. Maybe you can consider using foreground service instead to avoid such limitations.
Some users report an issue: they launch the app, the splash screen appears, but nothing else happens. Splash screen just stays on without ANR or errors.
I can't see any logs because no loggers were initialized yet, and I don't even know if the onCreate method was called.
Important notes:
99% of users don't experience this
users that report such issue say that it's persistent - they can't use the app at all
some users say if they launch google play store first and then launch app - it works fine, but without that step it always freezes at the splash screen, so they have to launch google play store each time before launching the app
To send any data anywhere I need to initialize a bunch of dependencies, but looks like it doesn't even get to that point. App works fine on millions of devices, but a few thousand users reported this issue. Cannot post application initialization code as it's huge.
Questions:
What can possibly be the reason of this?
Where would be the best place to start searching for the bug?
Is there a way to determine the first line of code where the app is not launching as it should?
Is there something that the google play store triggers that applications need to launch properly?
It was because of googlePlayStoreAppUpdateManager.appUpdateInfo check for updates that returns a Task, but sometimes it doesn't actually call nor success nor fail listeners, so we hang forever. Solution was to add RxJava wrapper with timeout and limit waiting time for Google to answer to some reasonable time.
It looks like some devices, like Xiaomi or Honor are not allowing google play manager to check for updates unless explicitly started by the user, so this check should be done carefully.
I am a beginner in android development. I want to know that is it possible to know the app which is opened currently. I came to know that finding the apps which are running currently through Activity Manager (getRunningTasks()) is now removed from the Android studio. So I want to know is there any other way to know? I just want to know the app which is opened and running currently on the mobile but not the apps running in the background Could somebody please help me in this case?
You can use AccessibilityService to get event notification. But AccessibilityService are specifically for accessibility uses. If you use the service for other purposes, then the application will more likely to be downed/removed for PlayStore due to policies. Another viable option is UsageStatsManager, but with some limitations.
UsageStatsManager is not push event based system. You have to poll in few mills(depends upon the use-case)
Usage Access Permission grant/deny is not straight forward. You have to start Setting Activity with Settings#ACTION_USAGE_ACCESS_SETTINGS action and have to rely on the users understanding of how to grant permission(Since permission list may contain other applications).
In my app, I have Activity A ( home activity) --->> then Activity B --->> Then foreground service.
Application runs for an hour then in notification bar I get "This app is consuming power > 40mhA". Within another hour the app is killed.
Reference to this, it's possible to keep the service running even after killing the app , but this is not the target.
My question: is it possible to keep the app running and overcome system killing?
Thanks
As far as I know, if the OS has decided to kill your application due to power consumption - there is nothing you can do to keep it running.
The best thing you can do is check why it consumes that much battery and optimize it through your code.
I know that sometimes it seems like there is nothing you can do to optimize it, but trust me, there is.
Maybe you are using a service in a wrong way that abuses it?
If you will post your code here we can try help you fix it :)
The background services are not encouraged any more from Android Oreo (>25). I want the socket to keep connected in my chat application even when the app is closed.
How can I implement new changes to android 26?
Some people says, use JobIntentService
Some people says, use JobService
Some people says, use JobScheduler
Some people says, start service as Foreground Service
Any help would be appreciated.
I faced the exact same problem working on a chat application so I know your pain. Our conclusion was:
you don't keep a connection alive 24/7, if you need to deliver a
message to an user that has no connection alive, send a push message
via Firebase.
If you want to keep a connection alive in background, you will face many problems. The first one, targeting Oreo, is that if your app is in background (definition of "background" in this context is here) it won't be allowed to run except for small time windows.
You can definitely use JobScheduler to run periodic tasks, they won't be executed at exact intervals or times to reduce battery usage (which is good) but it won't help you in keeping a connection alive. At best, you can use JobScheduler to periodically pull messages from you server. In order to use JobScheduler you need to create a JobService class.
JobIntentService is a new class introduced in API 26 of support library. It is a replacement for IntentService, it will run as a JobService on android API 26+ and as a Service (similar to IntentService in the sense that it will execute code in a background thread) on older APIs. On Oreo its background execution will still be limited so it won't help you in keeping a connection alive.
Using a foreground Service can really help you reducing the likelihood of the process being killed, but, you will need to display a permanent notification. It doesn't sound like a good solution for a chat app.
If you still think that having a 24/7 connection alive is a viable option, you need to consider also doze mode. You could ask the user to whitelist your app to run even in doze mode but you should have a very good reason to do that. Again, you would face the other bg execution limit in Oreo.
Another issue you will face is other apps. There are resources management apps that will aggressively kill other apps in bg to reduce memory and battery usage. For instance, I cursed this one quite a bit.
Another issue is created by android. When the system is running low on memory, it will start killing processes of apps in bg. There is a an order in which they're killed, if I recall correctly should take into account last time it was in fg and current memory usage. Not the worst of the problems but still, it happens.
Then, if I still haven't convinced you in giving up the idea of the permanent connection, let me share with you yet another problem you would face. Some vendors implements extremely aggressive policies when it comes to killing bg processes, so that they're battery will last longer. For instance, Xiaomi.
Last tip, unrelated, but it took us a while to figure this out so I'm going to share it. If the user force stops your app from settings, your app is dead (that is, "stopped state") until the user actively launches it again, it won't even receive Firebase push messages.
If your server is configured on XMPP, then it would be easy for you.
Actually, there isn't any need to keep the socket alive at all the time. This is very expensive for the battery and I'm sure you don't want that.
Case: You are working on a Messaging app.
If your socket is broken, then the client will receive the message in the form of Google FIREBASE notification. And the moment your client will receive a notification from firebase, just enable the socket, and you'll be back on track.
The reason I suggested you to use XMPP is because XMPP maintains a queue of undelivered/offline messages. And when your socket is connected again, you simply pull the offline messages from the server.
I don't think this will help you out, but this may make a room for some another idea for you.