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 :)
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 have been running into a problem with my application, which I have no idea why. The following is:
the application is a large, commercial project, which makes several connections to the database, with a login system and everything else
I noticed that if I leave the app in the background for about 10 minutes, for example, it terminates my connection and restarts everything again, forcing me to log in again.
The only guarantee I can give is that they are not connection problems with my server, as in my tests it never failed.
Anyone who might have any idea why?
(I know that the explanation of the problem was a little vague, but the situation is very vague even for me)
How did I find my problem?
The user of my application was using a bluetooth barcode reader, which was programmed to automatically turn off after a period of inactivity. I noticed that whenever the bluetooth device turned off, my application would lose its previous state if it was in the background. Using the LogCat tool, I realized that my process was being killed by the system itself. The messages always looked like these:
W/ActivityManager: Force finishing activity
my.project/.view.activities.MyActivity
I/ActivityManager: Process my.project (pid 12984) has died
After much research, I found that the Android system interprets some external events as configuration changes, eg screen rotation change, Bluetooth device connection/disconnection, etc.
When such a change happens, Android, by default, kills your app's process and restarts it completely again, so that the app adapts to the new behavior. In my case, there was a NullPointerException in the code, which I hadn't handled correctly, so the application went back to the beginning, losing its state data.
However, in other application screens the mentioned Exception didn't occur (so it doesn't go back to login when starting), but even so I lost some screen data, like something that was typed in an EditText, for example.
How did I solve it?
On researching again, I found that you can let Android handle these configuration changes itself, telling it not to restart its process. To do this, just add in your Manifest, in the desired activity, the line:
android: configChanges = "keyboard | keyboardHidden | navigation"
As in my case the problem was with a bluetooth keyboard, I added these options keyboard | keyboardHidden; some keyboard models, for some reason, also change Android navigation, so I added navigation. After this change, done! No more problems!
P.S. 1: Unfortunately, not everything always works out. Adding android: configChanges won't work if your activity has fragments (I'm still trying to figure out how to solve this).
P.S. 2: This is not a good practice, I need to make that clear to you. For me, it's okay to do it this way, as my application responds well to changes. After all, my app is simple. Only use this feature that I explained if it is your last option or, if like me, your application is not so complex. Remember: this is not a magic solution to problems; in my specific case it worked fine, but for you, it might break your application.
P.S. 3: I recommend taking a look at https://developer.android.com/guide/topics/manifest/activity-element#config, in the android subtopic: configChanges. Listed are all the configuration changes a device can make.
I am building an app that is needed for a research experiment.
The experiment is entirely based on users responding to notifications that are shown at somehow random intervals.
What is the best way to do this so that each notification will definitely be shown to the user?
WHAT IS DONE SO FAR
I have used AlarmManager and broadcast receiver but notifications stop showing up after some time. Notification Channels (with id) are used too.
I suspect the operating system removes the app after it has stayed in the background for a while.
Can anyone help to explain the best way to get the app to show notifications regardless?
Since this is an app for research, users are well aware of any slow performances, or battery usage. The only priority is to ensure that notifications show up. Without this, the whole experiment will fail.
Any help or pointers will be great! Thanks!
I'm not sure what method you've used to show notifications so I'm giving a general guidance.
You will need to use a background service which keeps running even after the app has closed. A background service can be killed by the android OS if its running low on memory, so you'll have to give permission to your app to autostart.
If you want even more reliability, you should use a Foreground service. This way you can give high priority to your notification service.
But it would be much simpler to integrate Firebase Cloud Messaging into your app than implementing your own NotificationBuilder service.
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.