I am developing an application for a recognized financial institution. It is very important for them to manage security, and one of the requirements is that the application cannot run in the background. It was specifically requested that if a phone call is received, the application must get killed.
I tried using BroadcasterReceiver, by starting an activity when I hang up a call but apparently it runs as a service, and while my application is no longer running the activity is always started.
Is there any way to avoid background processing, like in iOS?
onPause() is called when your activity is going into the background.
If you overrode onPause() and stopped any sensitive activity in there, you would always catch the Activity going into the background.
Related
I have a long running background task that I would like to start when the app launches and shutdown when the application shuts down. I'm already quite aware of the activity life cycle and what gets called when an activity gets created and destroyed.
I'm coming from an iOS background, and over there we have some calls that are made during application startup and shutdown. Is there something similar in the android world? I've searched a lot and all I'm finding are answers relating to an activity, not the entire application.
(Android is relatively new to me, so I may just not know the correct terminology to search for.)
EDIT:
I'll try an be a bit more specific. I have a background task that needs to be continuously running while the user is using the application. It will be streaming data from a server continuously while the application is active. It does not need to run when the application is in the background. It doesn't seem to make sense to me to tie the startup / shutdown of this background process to any one single activity since it may not be the same one activity that starts up when the application becomes active.
I am (possibly mistakenly) assuming that the OS takes care of starting / stopping background threads when the application resumes and pauses. If that is, in fact, the case, then all I really need to do is spin up the background task when the application first launches, i.e. when it is loaded into memory and becomes active for the first time that session.
It doesn't seem to make sense to me to tie the startup / shutdown of this background task to any one single activity since it may not be the same one activity that starts up when the application becomes active.
That's reasonable. It is somewhat difficult to implement, though.
I am (possibly mistakenly) assuming that the OS takes care of starting / stopping background threads when the application resumes and pauses.
You have it exactly backwards. Android pays not one whit of attention to any threads that you fork yourself, directly or via thin wrappers like AsyncTask.
In addition to that point of confusion, you appear to be equating "user switching to another app" with "app shutdown". Those may be the same thing in single-tasking operating systems. They are not the same thing in Windows, OS X, Linux, Android, etc.
So, what you seem to be seeking is having a background thread running doing this streaming work while your UI is in the foreground, and then stop when your UI is in the background. The problem is that there really isn't a straightforward way of accomplishing that in Android.
One close approximation would be to create and register a custom Application class, where you override onTrimMemory(), and stop your background work when you get to TRIM_MEMORY_UI_HIDDEN, TRIM_MEMORY_BACKGROUND, TRIM_MEMORY_MODERATE, or TRIM_MEMORY_COMPLETE -- whichever of those that you encounter first. If, when one of those arrives, you determine that your streaming thread is still outstanding, shut it down.
In terms of startup, you could use onCreate() on that same Application singleton. The problem is that this will be called on any process creation, which may include scenarios in which you do not have UI (e.g., you are responding to some system broadcast, like ACTION_BOOT_COMPLETED), or possibly your process is going to parts of your UI that do not depend on the streaming. If you have none of those scenarios, then onCreate() in Application would be fine. Otherwise, kick off the streaming in onCreate() of whatever activities need it.
While normally we manage long-running threads with a Service, that is for cases where we explicitly want the thread to continue after our UI is in the background. Since you do not want that, you could skip the service.
It depends on what you want to do exactly. When you're just interested in the app starting for the first time you could #Override onCreate().
Or maybe you want to use onResume() as this will get called whenever a user brings the app to the foreground.
But this really depends on what exactly your background task is doing and what you want to do with it, to get an exact answer you need to provide more details.
Here is an overview for the actiity life cycle that should help you:
You can extend the default Application class and implement it's onCreate() method to detect when the app is launched. There is no corresponding method for when the app gets closed though.
Do not forget to specify it in the Manifest file.
In Android the application isn't shut down unless the system runs low on memory. You won't get a warning about that, it will just call your Service's onDestroy lifecycle method. If you want to do it when the Activity is visible on screen, use onStart and onStop. If you want to do it when the Activity is resident in memory, use onCreate and onDestroy.
I have been searching the net for hours. I am trying to make an application that has a UI interface and a service running in the background for SIP phone communication, kind of like Skype.
The UI starts and stops the service based on UI events, and the service stays logged in with a internet server in the background. I have found many articles talking about running the service on a separate thread(done), using startService as opposed to binding the service(done) but whenever I use the task manager to kill the application as a user might, I get an error popup saying my application has crashed and the service no longer runs.
How do programs like Skype, Facebook, or email clients do this?
Do I have to run these as separate applications using implicit intents?
Is there some settings I have to set in the manifest file other than declaring the service and it's name?
Better yet, is there a link to some page or source example using this kind of service?
EDIT: Sorry, I guess I wasn't clear. The service is stopping, and I don't want it to. I am trying to keep the service running in the background even after a user kills the application with the application manager.
One of the more confusing things with Service is that it is not run in a separate thread by default. Calling startService() as opposed to bindService() makes no difference in this regard. However, the binder mechanism will cause the Service exposed methods to be called in arbitrary thread context. In both cases, your Service is part of your application's process. If you kill it via the task manager or it crashes then the Service dies as well.
When you kill the app via the task manager and it pops up the message about the app dying, you have something misbehaving. Check logcat and it will point you at exactly where the crash happened.
If you need to have your Service running regardless of the UI, then don't stop the Service when your UI exits. You will still call startService() when your UI starts to re-connect (and possibly re-start it), but don't stop it unless you really want it stopped. Starts do not "stack". If something calls start 5x it doesn't take 5 stops to terminate the Service, only 1.
I have an application that I wants it to keep running when user puts it in the background. I was wondering what would be the difference between an application put in the background (so onPause() is called) and a Service? They seem both to be working in the background
Thanks
From the docs:
A Service is an application component that can perform long-running
operations in the background
When your Activity goes into onPause, there is no guarantee from the system that it will not be destroyed next. In your case, you aren't seeing it perhaps because you have enough memory available, but under different circumstances and on different phones, the Activity can be destroyed, even if you are doing work. Therefore you should use the service for background tasks.
You should use a Service. Even though your Activity can continue to execute code after onPause() or onStop(), you should use a service. A Service is not meant to have a UI and the system prioritizes them differently when deciding to kill components that are no longer in use if the system needs to reclaim memory.
In the app I'm developing atm. I use asynctasks to upload videos to a website, as it stands now if the application process is killed (User returning to home screen using the back key), those asynctasks are lost. ideally I would want the uploads to carry on despite the application process being killed, but I don't think that is possible.
I wonder if there is a way to retain their progress somehow (Maybe support from the website API is necessary?), or if not at least save the details of the asynctask and restart it when the app is opened again.
Vimeos application seems to have been able to resume video uploads, even after having killed the application process, thats exactly what I'm hoping to achieve.
Appreciate any ideas and suggestions.
I think you may be using the wrong architecture.
Anything that needs to survive in between Activity transitions is more suited for a Service. A service runs in the background (possibly even after the app is closed) and lets you do long running things such as performing uploads.
To kill the app process but have the Service continue to run, you can assign the service to a separate Android process using android:process in the manifest.
http://developer.android.com/guide/topics/manifest/service-element.html#proc
See this thread too:
How to keep a service running in background even after user quits the app?
I have created an application in Android. This application should never die (even when sent to the background).
Currently, after a while the Service manager returns "No longer want..." and terminates it.
I've read that one solution whould be to create a service. However my application is way to complicated to be splitted into two functionality sets (one for the service and one for the application).
Is there any "trick" in order to keep my application running at all time?
Could I create a dummy service inside my application that might force the android to keep my application alive?
Is there any other way?
FYI: 1) It's a customized application that will not be released on the Market. 2) Handsets can't be rootted.
Thanks
You must create a Service to have a persistently running app, even after all your Activities have been sent to the background due to user pressing the Back button, answering a call, switching to another app, etc. You should review the Android Process Lifecycle which states that:
Sometimes an Activity may need to do a long-running operation that
exists independently of the activity lifecycle itself. An example may
be a camera application that allows you to upload a picture to a web
site. The upload may take a long time, and the application should
allow the user to leave the application will it is executing. To
accomplish this, your Activity should start a Service in which the
upload takes place. This allows the system to properly prioritize your
process (considering it to be more important than other non-visible
applications) for the duration of the upload, independent of whether
the original activity is paused, stopped, or finished.