I am writing an app to receive the sms and display it on my screen. I declared a broadcast receiver and registered in my activity (in oncreate()). I haven't set any priority in my manifest file as well.
However during run time, my receiver is receiving the sms first then the systems message service is invoked first. Is this the behavior of custom broadcast receivers?
Thx!
Rahul.
Android sends ordered broadcasts for SMS messages. From the reference guide (emphasis mine)
Ordered broadcasts (sent with Context.sendOrderedBroadcast) are
delivered to one receiver at a time. As each receiver executes in
turn, it can propagate a result to the next receiver, or it can
completely abort the broadcast so that it won't be passed to other
receivers. The order receivers run in can be controlled with the
android:priority attribute of the matching intent-filter; receivers
with the same priority will be run in an arbitrary order.
I suspect that due to the lack of priority, the order is being chosen arbitrarily.
Related
Android developer portal states broadcasts which can be registered in manifest itself, but it gives a caution as under
Even though these implicit broadcasts still work in the background,
you should avoid registering listeners for them.
One such broadcast which is exempted is as under:
ACTION_LOCKED_BOOT_COMPLETED, ACTION_BOOT_COMPLETED
Exempted because
these broadcasts are only sent only once, at first boot, and many apps
need to receive this broadcast to schedule jobs, alarms, and so forth.
If we should avoid registering them (as per the above caution), then what is the right approach for ACTION_BOOT_COMPLETED ?
Use case: Sync data with the server and show a notification to user (if any)
If you need your app started at boot time, the only way to do this is to have a manifest-registered BroadcastReceiver.
I have a network change receiver class and it extends from broadcast Receiver, but I’m not pretty sure that it’s working in android Oreo, does Oreo support broadcast receiver, and if it doesn’t support, what’s the other way to do it
Oreo supports Broadcast Receivers but with some restrictions on Implicit broadcast that are declared in manifest.
Implicit vs Explicit Broadcast:
According to the documentation, an implicit broadcast is a broadcast that does not target that app specifically. For example, ACTION_PACKAGE_REPLACED is an implicit broadcast, since it is sent to all registered listeners, letting them know that some package on the device was replaced.
However, ACTION_MY_PACKAGE_REPLACED is not an implicit broadcast, since it is sent only to the app whose package was replaced, no matter how many other apps have registered listeners for that broadcast.
So any broadcast receivers that we have defined statically within our application manifest that are listening for implicit broadcasts will no longer receive those broadcasts.
The reason for this change is that implicit broadcasts would previously trigger any component that was listening for them within the manifest— this could have an adverse effect on application and device performance due to large numbers of applications registered to receive specific broadcasts all being triggered at the same time.
But there is a list of exceptions when it comes to implicit broadcasts — this means that there are still some which you can register to receive broadcasts for. They are all listed below:
So if the broadcast that you have registered receivers for is on this list, then it will still function as it did previously. However, if the broadcast that you have registered to receive is not on this list then you should use some alternative solution like:
Create the receiver at runtime by calling Context.registerReceiver(),
instead of declaring the receiver in the manifest.
Use a scheduled job to check for the condition that would have
triggered the implicit broadcast.
For more information
It's not supported in Oreo as manifest tag, you must have to register it at an Service/ Activity with context.registerReceiver(). Or you use the WorkManager to schedule something for specific network conditions.
I have seen a few posts that mention that GCM messages are sent as ordered broadcasts, and that the "android:priority" attribute hence can be used to to control which (out of several) receiver(s) that should handle the broadcast first.
For example: GCM BroadcastReceiver setResultCode use
However, I can't find any doc from Google that confirms this. Regardless of which priority I set on my different GCM-receivers, the broadcast seem to be un-ordered.
Are GCM messages really sent as ordered broadcasts?
I think I've found out why I couldn't control my broadcasts (which led me to believe that GCM broadcasts aren't ordered): I forgot to call abortBroadcast() to prevent the second broadcast receiver from handling the broadcast message:
http://developer.android.com/reference/android/content/BroadcastReceiver.html#abortBroadcast() :
Sets the flag indicating that this receiver should abort the current broadcast; only works with broadcasts sent through Context.sendOrderedBroadcast. This will prevent any other broadcast receivers from receiving the broadcast.
So when I call abortBroadcast() only the first receiver handles the broadcast.
From Google Documentation
A "message with payload" is not simply a "ping" to the mobile application to contact the server to fetch data. In the aforementioned IM application, for example, you would want to deliver every message, because every message has different content. To specify a non-collapsible message, you simply omit the collapse_key parameter. Thus GCM will send each message individually. Note that the order of delivery is not guaranteed.
I am a bit confused about this part of documentations:
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.
What does "no longer active" mean? It means our receiver won't receive any events with the specified type? Or it means the receiver is destroyed and a new one is created when the event occurs?
Is this any difference about this, between registering receiver in manifest file and in code dynamically?
"Is this any difference about this, between registering receiver in manifest file and in code dynamically?"
Yes, there is a difference. Receivers registered in the manifest file will receive all intent-filters it matches, anytime the OS sends them out. This differs from registering a broadcast receiver in code by the broadcast receiver in code will only listen to broadcast intents while you have set it to listen. The reason you would use this method sometimes, as opposed to just registering it in the manifest, is if you wanted to implement ordered broadcast. For example, (you can build your application in such a way that) a broadcast receiver in an activity would have higher priority than the manifest, that way, if you receive an intent that your application handles, you can present a message in the activity because you know that the user much currently be in your app. If the broadcast receiver is not listening in the activity, then you assume the user is not currently using your app so then you may just want to send a notification. I should mention that ordered broadcast have the ability to abort the propagation of a broadcast intent to the next receiver, which is what you would do if you caught the intent in your activity class ,therefore, the manifest file will only get the intent if the receiver in the activity class did not catch it.
The words "no longer active" mean that the broadcast receiver will just stop doing any work for that particular broadcast. It will still listen to any succeeding broadcast intents just fine.
It means that upon returning from onReceive() the system will consider its process to be empty and aggressively kill it so that resources are available for other more important processes.
You will often use a Service in conjunction with a BroadcastReceiver to keep the containing process active for the entire time of your operation.
A fellow developer and I have started to question whether a broadcast announcement is guaranteed to be received by the appropriate broadcast receiver.
We have a broadcast receiver which receives messages that should be put on to the screen. Occasionally we notice that some messages never make it to the screen.
Even with the debugger, it has been hard to tell for certain if the receiver is not getting the broadcast or if it due to our own bugs that the broadcast is never sent.
So I wanted to ask generally if there are any known reasons why the broadcast receiver would not receive an announcement?
There are ordered broadcasts in Android. They are sent to receivers according to the receivers priority. And receiver with a higher priority can abort the broadcast spreading.
See this blog post for details.