Broadcasts Receiver
.
Broadcasts overview
Android apps can send or receive broadcast messages
from the Android system and other Android apps, similar to
the publish-subscribe design pattern. These broadcasts are
sent when an event of interest occurs. Generally speaking,
broadcasts can be used as a messaging system across
apps and outside of the normal user flow. However, you
must be careful not to abuse the opportunity to respond to
broadcasts and run jobs in the background that can
contribute to a slow system performance.
About system broadcasts
The system automatically sends broadcasts when various system
events occur, such as when the system switches in and out of
airplane mode. System broadcasts are sent to all apps that are
subscribed to receive the event.
Changes to system broadcasts
As the Android platform evolves, it periodically changes how
system broadcasts behave. Keep the following changes in mind if
your app targets Android 7.0 (API level 24) or higher, or if it's
installed on devices running Android 7.0 or higher.
Receiving broadcasts
Apps can receive broadcasts in two ways:
1. manifest-declared receivers and
2. context-registered receivers.
Manifest-declared receivers
If you declare a broadcast receiver in your manifest, the system
launches your app (if the app is not already running) when the
broadcast is sent.
Context-registered receivers
Context-registered receivers receive broadcasts as long as their
registering context is valid. For an example, if you register within
an Activity context, you receive broadcasts as long as the activity
is not destroyed. If you register with the Application context, you
receive broadcasts as long as the app is running.
Effects on process state
Whether your BroadcastReceiver is operating or not affects its
contained process, which can alter its system-killing likelihood. A
foreground process executes a receiver's onReceive() method.
The system runs the process except under extreme memory
pressure.
The BroadcastReceiver is deactivated after onReceive(). The receiver's
host process is only as significant as its app components. If that process
hosts only a manifest-declared receiver (a frequent occurrence for apps
the user has never or not recently interacted with), the system may kill it
after onReceive() to make resources available for other more critical
processes.
Sending Broadcasts
Android provides ways for apps to send broadcast:
The sendOrderedBroadcast(Intent, String) method sends broadcasts 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
The sendBroadcast(Intent) method sends broadcasts to all receivers in an
undefined order. This is called a Normal Broadcast. This is more efficient, but
means that receivers cannot read results from other receivers, propagate data
received from the broadcast, or abort the broadcast.
Restricting broadcasts with permissions
Permissions allow you to restrict broadcasts to the set of apps that
hold certain permissions. You can enforce restrictions on either
the sender or receiver of a broadcast.
Sending with permissions
When you call sendBroadcast(Intent, String) or
sendOrderedBroadcast(Intent, String, BroadcastReceiver,
Handler, int, String, Bundle), you can specify a permission
parameter. Only receivers who have requested that permission
with the tag in their manifest (and subsequently been granted
the permission if it is dangerous) can receive the broadcast.
Receiving with permissions
If you specify a permission parameter when registering a
broadcast receiver (either with registerReceiver
(BroadcastReceiver, IntentFilter, String, Handler) or in
<receiver> tag in your manifest), ), then only broadcasters who
have requested the permission with the <uses-permission> tag in
their manifest (and subsequently been granted the permission if it
is dangerous) can send an Intent to the receiver
.
Thank you!!!
