I was going through the docs on Broadcasts and found the following in the best practices:
When you register a receiver, any app can send potentially malicious broadcasts to your app's receiver. There are three ways to limit the
broadcasts that your app receives:
But receiving a broadcast entails receiving an Intent, carrying some data optionally. I was wondering how it can be malicious after all?
if you have listeners waiting for a specific signal, from that broadcast, so they can, for example, show a notification, someone can do a malicious app that can call that listener and star showing n number of notifications and start annoying your user.
Related
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'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.
I want to watch for a particular SMS, and handle it in a Receiver when it arrives. I then want to "eat it" so that it doesn't bubble upwards and display to the user (it should be handled "silently"). Is this possible? If so, how?
Is this possible? If so, how?
Since the SMS broadcast happens to be an ordered broadcast, your BroadcastReceiver can call abortBroadcast() to stop it from being handled by lower-priority receivers.
Here is a blog post from a while back discussing ordered broadcasts. Here is a sample project based upon that blog post. Here is a sample SMS BroadcastReceiver that conditionally executes abortBroadcast().
You are looking for the Service construct in Android. It is designed to run something, without requiring a UI (like an Activity).
BroadcastReceiver is additional functionality you should research to catch the SMS event.
I then want to "eat it" so that it doesn't bubble upwards and display to the user (it should be handled "silently")
Huh? Intents that you register to receive are handled silently unless you choose to handle it "loudly".
EDIT
Also, there is no way to prevent other apps from responding to SMS messages. Think about the security implications of allowing one app to control whether other apps can listen for system events...
Yes, it can be aborted by abortBroadcast() method and if you set priority of IntentFilter to 1000(highest priority) then this receiver will receive broadcast before the system.
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.
Can anybody tell what is the use of a BroadcastReceiver and give an example in Android?
Can someone give a time zone change example using a BroadcastReceiver?
I think the android developers documentation explains it pretty good:
A broadcast receiver is a component that does nothing but receive and react to broadcast announcements. Many broadcasts originate in system code — for example, announcements that the timezone has changed, that the battery is low, that a picture has been taken, or that the user changed a language preference. 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.
(see developer.android.com)
On your android system broadcasts are used as an instrument of notifications. As the name suggests, they are broadcastet through your whole system. With a broadcast receiver you can catch these broadcast notifications.
Think about the broadcast receiver as a normal listener. If you listening for free beer and someone yells "free beer here", than you will react on that :) Thats your real life broadcast receiver example :D
A broadcast receiver is a component which allows us to register for system or application events. All registered receivers for an event will be notified by Android once this event happens.
Android system periodically broadcast messages about things that are happening, such as the battery status changed, the Wi-Fi came on, or the phone’s orientation changed. You can pick up these state changes and perform actions after intercepting them and all this is done using broadcast receivers. Broadcast receivers receive and react to broadcasts generated by system or apps .