I have a working broadcast receiver for C2DM, which normally works perfectly, but in some cases in the field, it just stops being invoked by the system. My question is:
Under what circumstances would Android suddenly stop sending intents to a particular application, even if the app is currently running?
Given that it works the majority of the time, I'm trying to figure out if there's some way for the broadcast receiver to "go bad" or the process be marked bad etc. I have verified that Google is happy with the C2DM (i.e. it's not rate-limited due to quota or anything like that).
I am having exactly the same problem and what helps me is toggling wifi on and off, when it reconnects it starts receiving again. For me this is only the case when using C2DM, not tested with other broadcastreceivers. I know that this is not really an exact answer to the problem.
There also happens to be a problem with C2DM not working very good over wifi. So are you using your wifi connection or mobile-internet? Try only using your mobile internet for a while and see if the receiver still stops receiving.
Let me know if one of these tips got you any further!
Dino
just change one line in manifest.
receiver android:name=".MyBoardCastReceiver" android:enabled="true"
Related
I have been trying to do something similar to truecaller app, where my app is supposed to show a screen after a call gets hung up. Was achieving this by registering android.intent.action.PHONE_STATE implicit broadcast in the manifest file.
But it is not working if I change the app to target Android O, because of the Android O broadcast limitation, and I'm trying to figure out an alternative solution to this use case.
Alternative solutions suggested in android docs: Job scheduler or register a service with context.
Job scheduler: Because of the Job scheduler optimizations there will be some delay to receive the callback. So it will affect the user experience if our app screen is shown a few min after the phone call and polling to check for new call logs every few seconds causes battery drain issue.
Register service with context in Java: I want the behavior to work even if the app is not active or alive. This will not work if the system kills the Service.
Register a Foreground Service: This requires a notification to be shown to the user all the time, which would be spam the user, and running a service 24/7 consumes lots of resources which defeats the whole purpose of broadcast limitation.
Please suggest an alternate solution so that the user experience remains the same.
Thanks in advance
Eventually, the action was added to the "Implicit Broadcast Exceptions" list so you can add ACTION_PHONE_STATE_CHANGED to your manifest and it will work:
https://developer.android.com/guide/components/broadcast-exceptions
ACTION_CARRIER_CONFIG_CHANGED,
TelephonyIntents.ACTION_*_SUBSCRIPTION_CHANGED,
"TelephonyIntents.SECRET_CODE_ACTION", ACTION_PHONE_STATE_CHANGED,
ACTION_PHONE_ACCOUNT_REGISTERED, ACTION_PHONE_ACCOUNT_UNREGISTERED
OEM
telephony apps may need to receive these broadcasts.
You have only one solution, use a foreground service and register the broadcast receiver in the service.
As there is NO proper solution to read the PHONE_STATE from Android O. The best alternative we can go for is to trigger a job on new call log entry from the content provider. By this, the behaviour is maintained of showing a screen(with a few sec of delay) after the call ends.
NOTE : The disadvantage is we cannot get the state of the phone call(Ringing or off_the_hook etc.,). The call back will only be received after the new call log has been added to the System DB.
For me, and my production app, the solution would be to avoid targeting api 25 and above, until a better workaround/api comes up.
If your app targets level 24 or below, you're not affected by the new Implicit Broadcast Limitations and your app can still listen to PHONE_STATE broadcasts even when your app is not running.
An app targeting lower APIs can still be downloaded and installed normally on new Android versions, the only reason to update your sdkTarget value is if your app requires usage of new APIs.
There seems to be an broadcast exception for ACTION_NEW_OUTGOING_CALL but not one for incoming call (or when call ends). It seems like a bug to have one for outgoing but not one for incoming. There's been a bug report filed in google issue tracker. Hopefully their answer will clarify what we should be doing.
I'll update this answer if/when the bug tracker gets updated.
As mentioned here: https://issuetracker.google.com/37273064#comment4, ACTION_PHONE_STATE_CHANGED (android.intent.action.PHONE_STATE) will be whitelisted for the Android O release. Though they may be replaced with a different mechanism in a future release.
Two devices are connected to a Chromecast receiver and disconnecting from one also disconnects the other device. Recently upgraded the SDK version to 9.8.0 and post that only this issue got visible. Any insights for this?
You need to look at your receiver app and see what logic you are using there that could cause this behavior. On the receiver side, onSenderDisconnected() is called when a sender disconnects and at that point, you need to see if there is any other connected sender left there and only if there is none, you should close the receiver. You can take a look at the reference receiver sample to see how that can be done, or read about it here. If you are using the Default or a Styled receiver, then you need to make sure that you are not calling stopApplication() from your sender side.
I'm guessing this is a really rookie question, so I'm hoping someone can steer me in the right direction quickly & easily.
I have an app that receives GCM messages. The code that contains the GcmListenerService-derived class is located within my app. Because of this, the user MUST run my app after starting their phone in order for my listener to start listening (verified by restarting my phone, sending a test from Postman, and NOT getting the message / notification until I launch my app).
Do I need to create some type of service or something that will allow my app to get new GCM messages, even after restarting the phone (and not launching the app)?
Thanks!
Yes. You will need a broadcast receiver which listens on the BOOT_COMPLETED broadcast message and launches the push notification service. However, you still have to start the app once to register the receiver. It will also not work if the user force quit the app. There are some approaches, which also will restart the app automatically if the user killed the app, but I think it is a bad practice. In some circumstances the user wants to stop the app and keep it closed.
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.
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.