9

I have noticed than whenever I manually kill my application by longpressing the back button of my cellphone my broadcast receiver stops working. The receiver is in charge of displaying a notification every time the user hangs up a phone call and the same is registered in the manifest.xml.

Is this the normal/expected behaviour? I thought the receiver should continue to work even if the user decides to kill my application... Is there a way to prevent this?

Thanks.

Edit

Here's the manifest entry for the receiver:

<receiver android:name=".BroadcastReceivers.CallReceiver" android:enabled="true">
   <intent-filter>
       <action android:name="android.intent.action.NEW_OUTGOING_CALL" />
       <action android:name="android.intent.action.PHONE_STATE" />
   </intent-filter>
</receiver>
mradzinski
  • 614
  • 1
  • 8
  • 21
  • Are you starting the broadcast receiver from an activity? – alanv Jul 25 '14 at 00:56
  • Not actually, it's defined on the manifest. – mradzinski Jul 25 '14 at 00:57
  • Could you paste the entry from your manifest? – alanv Jul 25 '14 at 01:02
  • 1
    You would need to start by asking your device manufacturer what a long-press of the BACK button does for your device. I am not aware that it does anything other than what a regular BACK button press does in standard Android. – CommonsWare Jul 25 '14 at 01:03
  • @CommonsWare I'm running under CM now, however I tried the same using a task killer on a standard Android KitKat (I know, it's not recommended, was just experimenting a bit) and obtained the same result: Kill = BroadcastReceiver dies. – mradzinski Jul 25 '14 at 01:12

2 Answers2

13

There are ~7 billion people on the planet. Only you know what you mean by "kill".

The symptoms that you are describing, though, are consistent with a "force stop". A user normally force-stops an application by going to Settings, finding your app in the list of installed apps, and tapping on the "Force Stop" button for your app. There are some devices and firmware builds that make "Force Stop" more readily accessible than this -- such devices and firmware builds were written by drooling idiots IMHO.

If your app is force-stopped, your code will never run again, until something uses an explicit Intent to start one of your components. Usually, the user does this by tapping on your app's icon in the home screen's launcher. Until the user does this, your BroadcastReceiver will not work, and there is nothing you can do about it.

Rather than using some on-device feature to "kill" your app, try terminating its process via DDMS. If your app continues to work in that case, then however you elected to "kill" your app before is doing a "force-stop". Merely having your process be terminated, such as due to low memory conditions, should not prevent you from receiving future broadcasts.

CommonsWare
  • 986,068
  • 189
  • 2,389
  • 2,491
  • 1
    kill is quite a broadly adopted term for what you described as a force-stop. It is so broadly adopted that there are even a group of applications like task-killers that take the term as part of their name. Aside from that, I'll try the DDMS way although you answered my biggest concern which was memory related. Thanks. – mradzinski Jul 25 '14 at 10:14
  • 4
    @mradzinski "kill is quite a broadly adopted term for what you described as a force-stop" -- not really. "that there are even a group of applications like task-killers that take the term as part of their name" -- task killers and task managers do not do a "force stop". They terminate background processes. That is not a "force stop", which not only terminates the process but removes your alarms and prevents your app from running again automatically. SDK applications cannot do a "force stop". That is only possible via the firmware, which is why it is normally only accessible via Settings. – CommonsWare Jul 25 '14 at 11:00
  • Thanks for clearing up the difference between `process kill` & 'force stop'. – Muhammad Babar Sep 25 '14 at 06:07
  • 1
    One question. If a kill the app process from `DDMS` will my previously registered `BroadcastReceiver` act like `STICKY`? or i have to start the app again to registered the receiver again? – Muhammad Babar Sep 25 '14 at 06:09
  • 2
    @MuhammadBabar: "will my previously registered BroadcastReceiver act like STICKY?" -- well, receivers registered in the manifest will still work. Receivers registered via `registerReceiver()` will not, until you get a new process and run through the `registerReceiver()` code again. – CommonsWare Sep 25 '14 at 11:48
  • @CommonsWare What if someone force stops an application and a GCM intent is sent to it. I have a wakefulBroadcastReceiver as a receiver to GCM that works even when user "force stops" the application. So does that mean broadcastReceivers can work even after force stop? – VipulKumar Jan 15 '15 at 07:10
  • 2
    @VipulKumar: It should work, mainly because an explicit `Intent` is being used to deliver the GCM message to your app. The actual GCM communications are being managed by the Play Services process. When it gets a message, it finds your `BroadcastReceiver` using a lookup based on registration ID (I presume), and then it crafts an explicit `Intent` to get the message to you. We know that it must be an explicit `Intent`, as otherwise everybody would get everybody's GCM messages. Explicit `Intents` move apps out of the stopped state. – CommonsWare Jan 15 '15 at 12:10
  • @CommonsWare So this is a pretty good strategy to prevent app (especially services) from being stopped. What I am doing in my receiver is that I start the service on every GCM intent and voila! Thank you for explaining. I was missing the "managed by Play services process" part. – VipulKumar Jan 15 '15 at 12:38
  • @CommonsWare are there any exceptions for "Connection State change" broadcast? I registered to it from manifest, then I started the app and killed its process, then I turn on and off the air-plain mode and made sure that I can access the browser after-wise. But I didn't got connection broadcast. Is there any special rule for them? – Ilya Gazman Nov 12 '15 at 15:25
  • @Ilya_Gazman: "are there any exceptions for "Connection State change" broadcast?" -- not that I am aware of. – CommonsWare Nov 12 '15 at 15:32
  • @CommonsWare For sorry this is not happening, when I stop the application via [ Stop app Ctrl+F2 ] the implicit broadcast receiver (To monitor install and uninstall app) is not working (it's registered in the manifest), I have to start application so it works again. I'm testing on Android 5.0, using targetSdkVersion 25 – Jack Oct 18 '18 at 02:43
1

I know that some devices (like my ASUS) are deleting static receivers when you stop an application, yours is probably one of those. The only thing you can do is trying with emulator or other device.

Alpacah
  • 39
  • 8