I'm coming up to speed on Android development and the distinction between an implicit intent and a broadcast receiver is unclear. I was hoping for help in distinguishing these concepts and when to use the two.
Both receive intents, both react to system messages, so why is a broadcast receiver even needed and when is it used as opposed to an implicit intent and intent filter to accept the implicit intent?
Broadcasts are just that -- messages broadcast to anyone listening. They are inherently insecure, and delivery to the intended recipient isn't guaranteed, because there really isn't an intended recipient. For example, the CONNECTIVITY_CHANGE broadcast makes this quite clear: When connectivity changes in an Android device, many apps might be interested. Rather than the ConnectivityManager having to notify each app via specific Intent, it sends a broadcast. Any app that has registered interest in this event will be notified. Any app that isn't running or doesn't care... won't.
An Intent is "sent" when one app or Activity wants to launch another to do something very specific. For example, a file-manager might want to launch an image viewer or video player. Your app might want to launch a very specific Activity within another one of your apps, etc. The communication by specific intents (i.e. including package name and component name) can not easily be intercepted, so it's somewhat more secure. Most importantly, there's only and exactly one "receiver" -- if none can be found, the Intent will fail.
Further, a BroacastReceiver will be active within an Activity or Service and received broadcasts will generally only change state and/or do minor UI updates... for example, you might disable a few actions if your internet connectivity is dropped. By comparison, a specific Intent will usually launch a new Activity or bring an existing one to the foreground.
I am going to compile a list here of all the differences between Implicit Intents (sent via startActivity()) and Broadcasts (sent via sendBroadcast())
Broadcasts, by default, can affect multiple applications at once (Ordered Broadcasts have the potential to be disrupted). In contrast, Implicit Intents will only affect one application. Please note that there may be multiple possibilities of applications that could be affected, but eventually only one will be.
Implicit Intents are handled via Intent-Filters, and Broadcasts are handled via Broadcast Receivers (albeit the intent-filters play a role here too). I have seen in many instances over the web that Broadcasts are compared to Intent-filters and that does not make sense to me.
An Implicit Intent launches an Activity, or a Service. By contrast, a Broadcast launches a Broadcast Receiver. (This, if you think about it, is the core difference between Intents and Broadcasts. It is because of this reason that Broadcasts aren't meant to do too much heavy work, and especially not UI work!)
From the Developers Website:
There is no way for a BroadcastReceiver to see or capture Intents used
with startActivity(); likewise, when you broadcast an Intent, you will
never find or start an Activity. These two operations are semantically
very different: starting an Activity with an Intent is a foreground
operation that modifies what the user is currently interacting with;
broadcasting an Intent is a background operation that the user is not
normally aware of.
I'll add more if I find anything else.
Related
Before android O, I was able to trigger the functionality of a second sister-app based on the action of a first app. I did this by sending the second app an intent that was defined as a broadcast receiver in the second app. All as well.
But apparently as of api 26, any broadcast receivers defined in the manifest that aren't particular system ones (ie, app specific ones like mine) get ignored. I get errors in the logcat to that effect, I forget the details.
The only way I can think to get this to work is to have the second app start on boot (that broadcast receiver still seems to work) and have it start a service that installs a broadcast receiver programatically, and the service keeps enough of the app alive to receive those messages.
I haven't tried that yet because that seems like overkill and very resource intensive just to receive an intent to do something.
Is there any other mechanism to make this work?
Thanks.
But apparently as of api 26, any broadcast receivers defined in the manifest that aren't particular system ones (ie, app specific ones like mine) get ignored
Not true. You're misunderstanding the restriction.
As of API 26, you can no longer receive implicit broadcasts with a Manifest-declared receiver. However, explicit broadcasts are exempt.
Target the receiver explicitly in your Intent:
Intent intent = new Intent("my_action");
intent.setComponent(new ComponentName("com.sister.packagename", "com.sister.packagename.Receiver");
sendBroadcast(intent);
You'll obviously need to use your own action and the proper package/class name, but that will allow you to keep your Manifest-defined receiver.
Make sure you're checking the action in that receiver's onReceive() method, though. By sending an explicit broadcast, Android ignores your intent filter and sends the intent anyway.
I have an App which is a BroadcastReceiver and which processes NEW_OUTGOING_CALL intents. There are also other apps on my phone that are registered as receivers for these intents, but mine is registered with a higher priority intent filter, so my BroadcastReceiver gets to see the intents first.
I would like to programmatically be able to prevent any other registered BroadcastReceiver for NEW_OUTGOING_CALL from processing these intents, but I would like to allow the phone call to proceed. Is this possible?
I don't think you can actually do what you want to do. The documentation for this action describes pretty clearly how the system expects this broadcast to be handled:
For consistency, any receiver whose purpose is to prohibit phone calls should have a priority of 0, to ensure it will see the final phone number to be dialed. Any receiver whose purpose is to rewrite phone numbers to be called should have a positive priority. Negative priorities are reserved for the system for this broadcast; using them may cause problems.
If you want to see the number first, you can do that (with a higher priority), but then you have to live with other receivers seeing it after you do. Alternatively, you can see the number last (by lowering your priority to 0), but then you have to live with other receivers seeing the number before you do.
Note that another person suggested aborting the broadcast. Not only does this not make sense since the system needs the result of the broadcast, it also is stated explicitly in the documentation not to abort this broadcast.
Any BroadcastReceiver receiving this Intent must not abort the broadcast.
I need to check the vulnerability of my app. I am trying to intercept a broadcast message in android such that no other app is able to use that broadcast, is there any way for this?
No.
The closest you can come is if it is an ordered broadcast, if your receiver is higher priority than any other, you can abort the broadcast when you receive it. However, there is nothing preventing some other app from specifying an even higher priority, and where there is a tie (Integer.MAX_VALUE), there's a tiebreaker. I think the tiebreaker is first-one-installed wins, as that tiebreaker is used elsewhere.
If the broadcast is not ordered -- IOW, most broadcasts -- then you cannot abort it, and all registered receivers will receive it.
FWIW, I fail to see how preventing broadcasts being delivered to other apps helps "check the vulnerability of [your] app".
I want to know the difference between services and broadcast receivers, can anyone point out an example that can be observed on android mobile devices.
Thanks
Service: If you want to do something in background , this will be running always in background even if the application closed. You can create this in separate process and also you can give your service to other app if you want. Downloading any content or Music is good example
Broadcast Reciever: Usually system will send some info which can be recieved by your app if you would wish to ,by registering. And you can do something what you want when that thing happens by using onReceive method.
Example is the system will send BroadcastReceiver when new sms arrives or Booting done
Here is good article : Service and BroadcastReceiver
Service is used when you want to do something in background, any long running process can be done using Service in Background. For example, you want to play music when your application gets close. In that case service will be running in background with music.
Example of Service
BroadcastReceiver is used when you want to fire some stuff or code during some event. For example, event can be on Boot of Device. If you want to perform something when device Boots, date and time changed etc...
Example of BroadcastReceiver
I think of it possibly a different way. A Service receives intents that were sent specifically to your application, just like an Activity. A Broadcast Receiver receives intents that were broadcast system-wide to all apps installed on the device.
(The reason I say a Service is a bit like an Activity is that: You wouldn't broadcast a message saying "start Activity MyActivity" across all apps installed on the device. It is only for your specific app.)
Of course, as others mentioned, a Service can continue running in the background, whereas a Broadcast Receiver should finish quickly (e.g. if it is running for more than 5 seconds it may be killed by the OS). The Broadcast Receiver can still run in the background (when app is closed) under certain circumstances. For this, it's worth mentioning that there are actually two types of Broadcast Receivers - Manifest-declared, and Context-registered. They have different lifespans and restrictions - the former can receive broadcasts in the background with certain restrictions, while the latter cannot receive broadcasts in the background (app must be running and active) but has no restrictions on the types of intents that can be received.
Both services and broadcast receivers must be specifically invoked (via an intent), but for services this is usually a specific call (e.g. when your app is started or when the user clicks some button) whereas for broadcast receivers they don't need to be explicitly started as they will start anyway when a relevant broadcast is made.
Here's how I would think of it:
Type
Displays UI?
Can continue running for a long time when app is closed?
Can receive intents when app is closed?
Intents must specifically target your app?
Restricted list of intents that can be specified?
Activity
Yes
No
Yes
Yes
No
Service
No
Yes
Yes
Yes
No
Manifest-declared Broadcast Receiver
No
No
Yes
No
Yes1
Context-registered Broadcast Receiver
No
No
No
No
No
1: Only if you target Android 8.0 or above. The restrictions are not applied if the intent specifically targets your app. The restricted list of intents can be found here.
What is a BroadcastReceiver? What are its uses and how can I use it?
Start by reading the documentation. Also, copying from Application Fundamentals:
Broadcast receivers
A broadcast receiver is a component that responds to system-wide
broadcast announcements. Many
broadcasts originate from the
system—for example, a broadcast
announcing that the screen has turned
off, the battery is low, or a picture
was captured. Applications can also
initiate broadcasts—for example, to
let other applications know that some
data has been downloaded to the device
and is available for them to use.
Although broadcast receivers don't
display a user interface, they may
create a status bar notification to
alert the user when a broadcast event
occurs. More commonly, though, a
broadcast receiver is just a "gateway"
to other components and is intended to
do a very minimal amount of work. For
instance, it might initiate a service
to perform some work based on the
event.
A broadcast receiver is implemented as a subclass of
BroadcastReceiver and each broadcast
is delivered as an Intent object. For
more information, see the
BroadcastReceiver class.
Finally, read in Common Tasks how you can utilize BroadcastReceivers to listen for messages and set alarms.
A broadcast is generated by android on occurrence of some action , BroadcastReceiver class enables the developer to handle the situation on occurence of the event/action . Action can be arrival of msg or call , download complete , boot completed , etc.
Broadcast Receivers simply respond to broadcast messages from other applications or from the system itself. These messages are sometime called events or intents. For example, applications can also initiate broadcasts to let other applications know that some data has been downloaded to the device and is available for them to use, so this is broadcast receiver who will intercept this communication and will initiate appropriate action.
I like this slide, because it focuses on Broadcast Receiver and offers simple description. The minor problem is that the updated date was a little bit old ( in 2011 ).
Link
Android Application Component: BroadcastReceiver Tutorial
(retrieved from the slide)
Broadcast Receiver
Receives and Reacts to broadcast Intents
No UI but can start an Activity
Extends the BroadcastReceiver Base Class
BroadCastReciever is an Android Component that helps you to know handle registered System Events or Application Events.
For Example:
System Events Such us : the screen has turned off, the battery is low, or a picture was captured.
Applications can also initiate broadcasts—for example, to let other applications know that some data has been downloaded to the device and is available for them to use... etc
In simple terms
A broadcast receiver is basically an interface that you can implement so that your app can subscribe to system changes like when the system has finished booting, or a charger is connected/disconnected or airplane mode is switched on/off etc.