I have a call recording app that reacts to call state changes from a dedicated BroadcastReceiver.
BroadcastReceiver is registered correctly in my manifest, along with the PROCESS_OUTGOING_CALLS and READ_PHONE_STATE permissions.
My issue is that for some reason, in some of the calls I get the CALL_STATE_OFFHOOK state broadcast several minutes after call has already ended.
It seems that the broadcasts are somehow stuck, and then triggered after a while. The 'CALL_STATE_IDLE' subsequent broadcast is received approximately after X time since CALL_STATE_OFFHOOK broadcast, where X is the time the actual call took.
My logs verify that previous onReceive calls are not hanging the process or the BroadcastReceiver.
What can be the cause for such behavior?
UPDATE:
I found that this occurs after I turn my Wi-Fi on or off and start a call relatively close to Wi-Fi change.
Is this the cause for the issue or a symptom of the actual issue?
In Android System, broadcast are processed internally.
Sometimes, due to system loading/ restart/ high runtime, the broadcast receiver gets time to receive some intent
Workaround is, to add Flag FLAG_RECEIVER_FOREGROUND to intent sending broadcast
intent.addFlags(Intent.FLAG_RECEIVER_FOREGROUND);
This will speed up the broadcast delivery much than before in problem scenario
It turned out to be a bug in the Broadcast sending by android (or alternatively some malfunctional receiver). Investigating log cat showed that some system receivers did get broadcasts on time while others (prior to mine) received it after a long time.
This happens frequently whenever Wi-Fi state changes during call start.
What I did was creating an ITelephony proxy (credit to End call in android programmatically) and monitor its state.
Thanks for the helpers :)
Related
If I declare a BroadcastReceiver via the mainfest file for a system broadcast (let's say for example ACTION_POWER_DISCONNECTED) the the system will call it every time the specific broadcast is send so the lifetime of the BroadcastReceiver is unrestricted.
But there are also broadcasts which can not be registered via the manifest file. For these broadcasts we have to call context.registerReceiver with a corresponding IntentFilter. Let's say I create a BroadcastReceiver for BOOT_COMPLETED and call context.registerReceiver from it and never call unregisterReceiver does this receiver also lives forever (until the phone is rebooted)?
Apps that target Android O can no longer register broadcast receivers for implicit broadcasts in their manifest. An implicit broadcast is a broadcast that does not target that app specifically.
If my conjecture from above is right this would be an easy workaround for the system change (of course you shouldn't do it this way but it would be possible). So does a BroadcastReceiver which is registered after a BOOT_COMPLETED broadcast have the same lifetime (stays until the next reboot) as a BroadcastReceiver which is automatically registered via the manifest?
Let's say I create a BroadcastReceiver for BOOT_COMPLETED and call context.registerReceiver from it and never call unregisterReceiver does this receiver also lives forever (until the phone is rebooted)?
First, BOOT_COMPLETED is one of those actions, that still will behave like they were before, meaning restriction introduced in "O" do not concern to that action.
As soon as the process of your app is killed by the system or as soon as system clears your app's memory (as a result of low-memory of device), your broadcast registration will be lost. Otherwise I cannot see how this limitation will result in a better battery experience.
So does a BroadcastReceiver which is registered after a BOOT_COMPLETED broadcast have the same lifetime (stays until the next reboot) as a BroadcastReceiver which is automatically registered via the manifest?
If above mentioned cases are not met, i.e. the process of your app stays alive and app is not cleared from memory because of memory shortage - then yes. Once entered into cached state (the state with no active Android component) the registration will be lost again.
This short video by Nasir Khan will be helpful.
I want to detect calls and delete certain numbers from call log from background. Below are the options I have considered. Please advise if any of these or another is a better/workable solution.
Register phone state broadcast receiver. Delete number from call log in onReceive. The problem is that the call log may not have been updated at this point and thus the delete will have no effect.
Register phone state broadcast receiver. In onReceive somehow add a delay and try to delete the call log after some time. The delay would give the system enough time to add a call log entry. This approach seems a bit hacky to me, not keen on this.
Register phone state broadcast receiver. In onReceive register content observer for call logs. My understanding is that after on receive the process may get killed at any time so content observers onChange will not get called if the process has been killed.
Register phone state broadcast receiver. In onReceive start my service (if not already running) which then has a content observer registered. Delete call log entries matching certain numbers in content observer onChange.
Thanks,
Option 4 is a perfect way to do it.
I would suggest that you stop your service after finishing the work and let the broadcast receiver restart it whenever required.
Edit : You may also note that BroadcastReceiver is only for performing some small or light work so delaying is not an option here. :)
I'm reading the documentation now, and I have 1 thing to be fixed - please, tell me, what is difference between broadcast receiver and activity (without the fact that activity can show UI)? Broadcast receiver gets announcements using intent-filter, but Activity can do it too! Please, make me clear. Thank you.
Activity is something which work on your input or require an user intruption for launching any task but with the help of broadcast reciever you can listen the system services as once a broadcast receiver is started for listening incoming calls then each time when a incoming call it will launch your method what you have written for that for more explanation check these
http://developer.android.com/reference/android/content/BroadcastReceiver.html
http://www.vogella.de/articles/AndroidServices/article.html
You basically have it. An Activity is intended to be associated with a UI. By contrast a Broadcast receiver only 'catches' intents broadcast through the app / system. However, there are also implications for how the object is loaded into the system, and how long it sticks around. From the BroadcastReciever documentation:
A BroadcastReceiver object is only valid for the duration of the call to onReceive(Context, Intent). Once your code returns from this function, the system considers the object to be finished and no longer active.
This has important repercussions to what you can do in an onReceive(Context, Intent) implementation: anything that requires asynchronous operation is not available, because you will need to return from the function to handle the asynchronous operation, but at that point the BroadcastReceiver is no longer active and thus the system is free to kill its process before the asynchronous operation completes.
Keeping these differences in mind, the system may be able to more efficiently execute pieces of your app...
Activity is only active when you open it. When it is moved to the background, it is either paused or shut down.
A listener is always active on the background. The only thing that can "activate" a listener, is the thing it is listening for. Ex.: a broadcastlistener will detect (and react) when you receive a phonecall/sms, but will ignore the fact that you set your alarm (since it only pays attention to incoming/outgoing broadcasts)
the intent filter does pretty much the same thing for both, the difference is just how it is called. With activities, it requires the user to do something; with listeners, it requires the listener to be triggered.
I'm trying to write a Service which sits and waits for SMS messages (using a BroadcastReceiver which the server registers) and will take some action depending on the details of the SMS message. I use an Activity to startService() and stopService() for the Service. After I close the Activity, the Service continues to sit there with its state kept and its BroadcastReceiver waiting, as it should... However, I find that over time, randomly, the Service will restart itself. That is, onCreate() and onStartCommand() will be called even when the Service has already been started. This happens sometimes when my phone sits idle overnight...
Can anyone provide insight on why this is (phone requests resources and kills a service?), what I can do to prevent it, or what I can do to prevent the state of the service from being lost?
Thanks in advance.
I don't think you need to start service from activity at all. Have a broadcast receiver that listens to your SMS messages and starts the service. After work is done, service should call stopSelf();
I'll try Service.startForeground()
Android sometimes (when it's low on resources, mem/cpu) removes running services and once it's high on resources again brings them back. This is why you see that your services has been restarted a couple of times during night.
I'm trying to figure out if a system event broadcast is broadcasted
using ordered broadcast or normal..
The event is EVENT_REMINDER and in the source for the calendarprovider
i noticed it sets up a alarmmanager to sent the broadcast.
I can't find how the alarmmanager sends it.
My guess would be as a normal broadcast ,
But while i was trying some things i noticed i could delay the
system's notification (tried up to 10 sec) by building a sleep in my
broadcastreceiver.
This would indicate that they are handled ordered , and the systems
receiver is only called when mine has finished.
But can i be sure of this behavour?? (in all 1.5> sdk versions)
the docs state that in some cases normal broadcasts are also handled
ordered..due to spare of resources.
All thoughts on this are welcome....
Thanks , arnold
You can check the isOrderedBroadcast flag in the BroadcastReceiver.