Search engines and Android developer website didn't help and I guess you can help with my problem.
I want to make an app for personal use, which is supposed to run all the time on my old tablet (powered all the time). The app will have several features requiring user interaction but independent of those, it should run a background job to check something continuously (real time!) for instance sound detection. It should also always try to connect another device on the network.
That means that job needs to run almost eternally without being killed. Some comments I have found suggested AlarmManager or BroadcastReceiver. But those are triggered by very defined triggers (either time or broadcast). I don't want that, because it should perform its task continuously all the time. This background job should also be able to communicate with the main Activity of my app to report what it is doing and allow user to interact with it (change settings of the job for instance).
Do you know any way how to accomplish this? Is IntentService correct choice for this (hoping that it won't get killed or maybe I should let the Activity to restart it?)
Thanks!
Do you know any way how to accomplish this?
Build your own custom ROM, with a modified version of Android that contains your code as a native Linux daemon.
Otherwise, what you want is technically impossible.
You can come fairly close by using a foreground Service (not an IntentService) and returning START_STICKY or START_REDELIVER_INTENT from onStartCommand(). Android may terminate your process from time to time, but it should restart your service automatically after a short while. That service can use its own background threads to do whatever it is that you are trying to do.
Related
I made an android application with a runnable that checks something ever minute.
But the problem is the application goes [DEAD] after a couple hours without an error messages or anything.
Anybody have any idea what the problem could be?
That is not a problem, that is actually expected behaviour.
The lifecycle of all apps is managed by the Android OS. It decides whether to terminate an app in order to free resources and keep the system responsive. Apps that are currently is use have priority over paused and background ones. I think in your case the OS just decides to shut down the app because it thinks it's not needed anymore.
There are ways to get around this, but it all depends on what your app actually does. I don't know your implementation details, but may want to look into sticky Services or the JobScheduler in order to achieve what you want. Keep in mind that there is no such thing as a perpetually running background task that comes out of the box in Android (not should there be one) and usually implementations have certain limitations.
It could be the Android OS itself closing the app. If the OS requires more memory it will start to kill of other processes that have not been used for a long time (i.e. interacted with). You haven't stated how the check happens but it shouldn't be done directly within the app, but it sounds like it is something that a background service should be doing the work which would likely prevent this from happening.
You should NOT use Runnables for background processes, as they get suspended/killed by the OS as soon as your app goes off-screen.
If you want to let some processes run regularly, you have to stick with AlarmManager / BroadcastReceiver combination
I just started working on an application for Android, to be specific - a service.
I would like to create a service (background service, forcing itself to run, hidden, so it can't be shut down). and I don't have idea on how to construct it. How it is then launched and how to make it fit to those requirements. It needs to start running from the Android start, so I guess it would be created similarly to system services (or as a system service).
You may ask why I need that - I would like it to periodically send some data to MySQL DB without any user interaction - therefore it needs to run continuously.
It would be really helpful if You could give me a great start, a tutorial maybe or some structure drawing with crucial information.
One more thing - I am targetting Android 2.3, but if it's impossible, I'd like it to be the lowest possible Android version.
Thanks in advance guys!
I would like to create a service (background service, forcing itself to run, hidden, so it can't be shut down).
Fortunately, this is not possible. Users have control over their device, not you, and they can shut down whatever they want.
It needs to start running from the Android start, so I guess it would be created similarly to system services (or as a system service).
System services are part of the operating system and cannot be created via the Android SDK.
You may ask why I need that - I would like it to periodically send some data to MySQL DB without any user interaction - therefore it needs to run continuously.
It does not need "to run continuously". That would be a singularly poor implementation.
If you want to do something periodically, use AlarmManager for the scheduling. The work should be done by an IntentService, so the service can go away when the work is done, so you are not tying up memory all of the time and making it more likely that the user will shut you down. If you plan on waking up the device out of sleep mode to do the work, you should look into WakefulBroadcastReceiver, or possibly my WakefulIntentService.
Alright, I found the answer myself, but thanks for help to any of You who contributed :)
I am aware that it's not the best approach, but I need to do it that way, so I found this for running a service and restart after stopped, also found that for start the service/application on boot.
Both tested and worked for me.
I hope it is going to help anyone who needs it.
Do you want this service to be executed daily??
You need alarm manager .. that will help you in to start you service with android start and will execute your service after specified time delay.. You can specify the time for delay also. Dont forget to add permissions for alarm manager in manifest file.
my knowledge of services in any operating system, is that they usually run in the background and perform whatever work they have to do.
but the first time I got familiarized with android services, I got confused.
it appears they only run when the application is working, and that for me, makes them no more then sophisticated threads.
do I have this all wrong? how do I make a service that runs when the application doesn't? (so that I can check for updates and create notifications for the user that will then lead him to the application if he chooses to open them).
does push notifications have anything to do with it?
Edit:
thank you guys for your answers so far.
my problem seems to be the fact that the service is only started officialy when the device is booted up. I do call startService when the app starts, but that doesn't seem to help. the service still dies when the app is turned off (unless it was booted)
also I never call stopService
If you are trying to implement a long running task that is performed in a (background) service, you have to start one or more threads within your service. So the service just gives you the opportunity to have an application context without having to have a user interface ;) you can consider it as a kind of container.
This page give you a nice overview about different thread approaches in Android. As you can see a service has not its own thread.
Anyway, in your case it seems that an AlarmManager is probably the better option. Running services for polling information all the time can be quite CPU and battery consuming (see this post for instance). So try to avoid having threads that run all the time.
If you can push information about updates from a server it's just fine. Check out Googles Cloud Messaging in this case.
Michael who commented on my question first was right in his comment about startService()
so it goes like this:
my receiver is only activated on boot, and uses an AlarmManager to
time the service to certain intervals.
what I did was to bind the activities to the service. if the service
was off and I binded it and unbinded it, then by the time the app was
terminated, there was nothing keeping it alive.
by simply making sure that the service was started properly with
startService if it is not already on, I managed to keep the service
alive at all times
also thanks to Trinimon who gave a very nice explanation on what
services are, and the importance of not overloading the CPU with
excessive polling. (which is kind of a trade off situation)
good luck to all :)
I did a search before asking so please don't tell me to do that.
I'm relatively new to Android so I get confused easily.
I'm making a simple app that changes the ringer volume according to time. For this purpose, I know I need a service that keeps running in the bg and monitor time. However, I really don't know how to approach this. I have the Professional Android Application Development book but haven't found anything that helps in there.
My question:
How to constantly check time without destroying the battery
If my code is needed (as proof of me actually working on this), I'll post.
You don't need a service. Use the AlarmManager class. Its like an alarm clock and it exactly what you need for this type of app.
need a service that keeps running in the bg and monitor time
No. Actually that's not how to do it. Services on android are different than your normal windows service/unix daemon. They should do their job and then stop themself until they get started again - to save battery.
You should start your service at a certain point in time by using the AlarmManager, it sends the launch intent to run the service. When the service is finished doing what it's supposed to do (change the rintone volume here), use Service.stopSelf() to kill it.
I currently have programmed a normal Andorid-App (no Service). It contains a timer for periodic checks. To avoid hassle with a service and communication between Service and App I ask myself whether there is a way to keep an App that is no longer in foreground alive.
Currently when I "close" the App, it is still alive until Android OS decides to kill it. Is there a way to avoid this kill - e.g. by a certain command in "onDestroy" or a certain App-flag?
My App is quite complex and I do not want to implement a Service as this -especially the communication/binding- increases the complexity. Is there an "easy way" or am I really forced to use Service+App? Maybe there is a trick to register the App for sth. special that has the side-effect that Android OS does not kill it when it is in the background.
Edit for better understanding: It is ok that the GUI can go into the background (vanish) when the user wants it, so my question is not how to let the GUI of my App permanently in the foreground. All I want is that the timer stays intact without the need for an additional Service.
Thank you all for ideas in advance!
Android is very unpredictable by the nature of the OS's killing selection and by the market fragmentation. I would not count 100% on anything being kept alive if it is crucial. However you can gamble and be pretty successful. This is what would help you:
Use very good "Best Practices" to keep your string pool and heap at a minimum as Android looks to kill memory hogs first off (and because you love what you do).
Add the persistent attribute to your application manifest tag.
To really help yourself out, run as a, or run a service because they are long running processes, are very light (if implemented well), and Android looks to kill these off lastly.
Give your service priority by running it as a foreground service.
Doing these things will increase the likely-hood that Android will not kill your application.
I don't think there is anything like that available. I suggest looking at AlarmManager for periodic tasks - this may mean you won't need to use a service.
The apps being available in the background is simply a caching measure by the android OS to avoid having to relaunch a frequenly used app from scratch. If you want to be able to count on your app running in the background, a Service is the correct solution. Its not the answer you are looking for, but I am not aware of any tricks to staying alive in the cache, and if there were any, I would not feel good about recommending them.