Android: do BroadcastReceivers stop if an app is killed? - android

If a declare a BroadcastReceiver in AndroidManifest.xml, the reciever works, as it should, even on device boot when my application hasn't started yet, but if I force my app to stop from Settings the receiver seems to break down too.
Can it be that "Force stop" in Android 2.2 also makes some cleanup after the application (including BroadcastReceivers or maybe alarms set by the app in AlarmManager which should broadcast the intents I receive)?
By the way, how can I see in Eclipse all broadcasts being sent in the device?

Psycho,
Force Stop should not be used to attempt to test your app from a "non-running" state. I would say the behavior is "undefined" at best. It is not uncommon that after using Force Stop on an app, that you must manually restart it to get ANY of its usability back (including BroadcastReceiver). If your app is able to receive BroadcastReceiverevents including the BOOT_COMPLETE Broadcast than you shouldn't really need to test it further.
I believe the intended purpose of Force Stop was to completely stop an annoying app's functionality. If an app is running in the background often because its receiving a lot of broadcasts and restarting, wouldn't you think Force Stop should prevent that behavior until the app is manually restarted by the user?
Also, I don't believe there is a way to view Broadcast events from Eclipse.

In eclipse there is no way to see the "broadcast is sent"
Also If you have registered the Broadcast in manifest for which you want to receive the event then system will call onReceived method

Related

Android broadcast receiver to get status of installation even app is closed

Hi I am working with android.Firstly I am not familiar with broadcast receiver. I need to create an app in which, if anyone installed my app a broadcast receiver will run which check the installation status like ACTION_PACKAGE_INSTALL and android.intent.action.PACKAGE_REMOVED
.But How can i get these status even my app is closed ?? Is it possible with broadcast receiver ?? Please help me, thanks in advance :)
basically, BroadcastReceiver can receives broadcasts even if your app is not in foreground, or even if your application's process is not alive.
this can be done by declaring the receiver within your application's Manifest.xml file
when you declare a receiver in the Manifest file - then the system would wake up your application and invoke your receiver if it set with the appropriate intent filter that responding to the broadcast that been sent (in your case - ACTION_PACKAGE_INSTALL and PACKAGE_REMOVED actions..)
but unfortunately there are also bad news for you:
from Android ICS and above - you cannot receive any broadcasts until you application launched explicitly by the user at least once!
this is due to security reasons Google decided is necessary, to prevent from malicious apps doing staff entirely transparent without the user launched them at all even once..
so the answer basically is - no! you can't perform any code and receive any events from your app until it launched at least once.
by the way - you wouldn't received ACTION_PACKAGE_INSTALL and PACKAGE_REMOVED broadcasts for your own app that been installed or uninstalled anyway.
by reading your question again, honestly I'm not sure what is that you expects to happend:
it is no make any sense to "check your application installed status" if it unistalled or not. after all - if it uninstalled - then it can't run (and perform any code) anyway.

Android receiver cannot always get broadcast correctly

I have a package added receiver in my Android application, and has been distributed for a couple months.
Recently I found that not all the PACKAGE_ADDED broadcasts can be received by my receiver.
looked up a while, someone said that if your app had been killed by users or system, then you will no longer get broadcasts.
My questions are:
Is that true?
confirmed, if you terminate your app from Settings->Applications --> force stop
then your application wont receive any broadcast.
How can I prevent this happening, or is there a work around?
1.Yes that is true.
2.Take a look at WakefulBroadcastReceiver that will wake up when it receives an Intent. Then make sure you spawn eg. an IntentService so it will process your work in the background.
Take a look at CommonsWare's WakefulIntentService for implementation example.

Android service that was running when the phone was shut down starts automatically when the phone is booted

I am currently developing an Android telephony application that includes a service to handle all the SIP signaling for making and receiving calls.
I want this service to start exclusively when the user has correctly logged into the application. However, I am observing an undesired behavior: if the device is shut down while the app is running, the service is automatically started after the phone boots. This does not happen if the application is closed at the moment of shutting down the phone.
I have been reading about it but no answer comes up. Could anybody explain why this happens and how to prevent it?
Thank you in advance.
Thanks to CommonsWare comment I have quickly found the answer:
[...] The only way a service starts up is if somebody starts it, and the OS will not do that on its own.
I was so blinded thinking the OS was responsible for it that I didn't notice it was being done on purpose, as an undocumented feature inherited from a former version of the app.
There was a BroadcastReceiver listening to the android.intent.action.BOOT_COMPLETED action. This receiver was, among other things, restarting the service on start up when the app had not been properly shut down.
Thank you CommonsWare for your help.
Update
After preventing the BroadcastReceiver from listening to the BOOT_COMPLETE action, I still experience the same behavior.
The reason is that this BroadcastReceiver is also listening to connectivity changes to restart the SIP service when the WIFI or a data connection becomes active, only when the app is running. Wether the application was closed or not is stored in the app preferences, but this value was not properly set when the phone was shut down while the app was running.
That is why the service was still unwantedly starting on boot: because the BroadcastReceiver detected an android.net.conn.CONNECTIVITY_CHANGE at start up and the preference telling wether the app was still running or had been quit was not properly updated.

Android BOOT_COMPLETED

I have a question concerning the BOOT_COMPLETED event.
I need a service to be running at all time (done via AlarmManager) but I wonder if I have to start the service manually the first time the application is installed as the BOOT_COMPLETED event is sent only after the device is restarted. How is this commonly handled, it seems like no one is having this problem, am I getting something wrong here?
the user should be the one deciding on if the service is running or not when its first installed and not you, so yes it should be started manually when they launch the app for the first time

Android receive screen off/on events when application is not running

I've registered the Intent.action_screen_off/on in my oncreate method of my application, and i can receive the events when my application is running. But when my application exits i get an broadcast intent leaked exception (off the top of my head i think thats what its called, either way its caused by not unregistering my receiver when my app exits)
How can i receive these events when my application is not running? i'd prefer not to use a service or something like that, i've seen other apps do it without services or background processes.
i've seen other apps do it without services or background processes.
That's not possible. The only way to register a BroadcastReceiver other than in running code is to declare it in the AndroidManifest.xml with the relevant <intent-filter>. As it's not possible to do that for either Intent.ACTION_SCREEN_OFF or Intent.ACTION_SCREEN_ON, the apps you've seen MUST have some running component(s) in order to receive the broadcasts.
In short, use a Service - I'm not quite sure why you say you'd prefer not to.

Categories

Resources