I am new to Android and making my first real app and it uses the socket.io Java Client for communicating with my Node.JS server instance. I have recently discovered while testing that the OS can kill background apps whenever it feels necessary calling onSaveInstanceState() on the active Activity then when you switch back to the app it recreates the previous state using the Bundle passed as an argument in the onCreate() method.
So now that I know that, I need to implement a solution that would keep the app working as it should so I expect I will have to test a few solutions before I get the right one. And since it would be so time-consuming to just lock my screen and watch the server logs waiting for the
User disconnected
(which can take a lot of time for each try), I wondered if anyone here ever was in the same situation and figured a way to make the OS kill the app as soon as I lock the screen or hit the Volume Down button or something like that.
Related
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 an app that sends TCP messages. I need the messages to be sent as long as the app is alive. So, I granted access to battery optimization and added all the required wake_locks and everything seems to work fine even when screen is off.
The problem is that I noticed that every time that I leave my phone with the app in the background, when I come back after few hours(or less) no messages are being sent, and when I enter my app it loads as new instance and not like an app coming from background. What can I do to have my app not being killed by Android?
I guess that this is what happens
You need to use a foreground Service; a service started via startForeground().
The service does not "re-open" your activity; it is a component of your application that may be long-lived. You might prefer to think of it as an activity without any views.
Yes, as the others mention you have to use Service for background execution.
Additionally, also, keep in mind of the Background Execution Limits for Oreo and above.
You can also look at JobScheduler for managing asynchronous tasks efficiently.
Create a 1px*1px transparent view on the desktop, such as toast.(the Android os will level up your priority as a foreground process)
Suggest your user to add your app in the white list.(in some rom)
Always put your app`s notification in the notification bar.(also need a service)
create a guard process, when your app die, send a broadcast to guard and let guard restart your app. when guard die, send a broadcast to app and let app restart your guard.
Be careful of battery consumption and don`t trouble your users too much
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.
I'm making an Android app that act as an IOT host (I use serial communication and send it to Arduino). Is there a way to always set Android to run this activity (never sleep & always inside the activity)? It is important for it to not leave the activity since all the control and db access is done through it. So far what I've found already available is kiosk app in which it act as a launcher with limited app and such but none of the lock the android to an activity.
Thanks for answers & comment!
If you're curious :) The reason I use Android is that it needs a control panel UI and connection to a database, using RPI and other stuff would just get it to be more expensive.
there a way to always set android to run this activity (never sleep & always inside the activity)?
Not really. You are somehow looking for kiosk mode, or you can make your app acting as launcher (but it all depends on use case - if your app is only one on the device then this is all fine, otherwise you would need to put a lot of efforts to jail user)
it is important for it to not leave the activity since all the control and db access is done through it.
It sounds like your app architecture is just designed wrong.
I am developing an app which requires the gdk program to continue running as-is even after the device is removed from the head. Currently the program is paused when this happens seemingly by default, but I need the program to stay running because it is constantly uploading video. The desired result is that the program will continue to run and upload a video stream even if the glass is removed from the user's head.
What can I do to change this behavior?
thank you.
You probably want to perform the long running upload in a background service. Android's activity model makes it such that you can't really depend on the life of the activity to always be in the foreground and you need to use a service for tasks that shouldn't be paused.
Also if you have an activity you want to return to when you put Glass back on, ensure you specify android:immersive="true" within your declared <activity>. Without this, your activity could be completely destroyed when the screen turns off.