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
Related
I have a receiver which fires when boot is completes, using inter filter android.intent.action.BOOT_COMPLETED.
The problem is, when the user installs the app, i want this event to be fired. Without the user having to reboot the device. What is the best way to do this?
You cannot do this. In fact, the user must start your app manually at least 1 time before BOOT_COMPLETED will ever get delivered to your app. This is done by the framework to prevent apps from installing things which sit in the background without the user's knowledge.
I developed an app that receives the boot completed intent. From my tests I concluded that I must open the app at least once to start receiveing this intent.
Is this the correct behavior? If so, is there any way to start receiveing intents without starting my app at least once?
Thanks,
-George
The app must be opened before any code can be triggered, there is no way around this.
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.
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
I have Some Alarms set via AlarmManager to do some periodic jobs.
I set/reset them when user opens the app for the first time & on every boot_complete event.
But when the app is reinstalled via ADB then my alarms do not fire anymore. looks like the OS deletes the Alarms on reinstall of the app. I assume this will happen if the user updates the app from the market also.
If I can receive a broadcast or some sort of callback in the event of reinstall/upgrade etc of my application, I can set the alarms again. but i don't know if it is possible or how?
Can someone please help me out.
Yes, this is possible.
You can create a broadcast receiver that listens for any PACKAGE_* events the system sends, but you won't receive them for your own application except for when your application is being upgraded — you'll get PACKAGE_REMOVED followed soon after by PACKAGE_REPLACED.