BroadcastReceiver

facebook.com/apex.tgi

twitter.com/ApextgiNoida
pinterest.com/apextgi

BroadcastReceiver
It belongs to android.content (android.content.BroadcastReceiver)

package and extends Object class have some subclass to implement it

functionality such as AppWidgetProvider , DeviceAdminReceiver ,
RestrictionsReceiver ,WakefulBroadcastReceiver etc.
It is Base class for code that will receive intents sent by sendBroadcast().

BroadcastReceiver
There are two major classes of broadcasts that can be received:
Normal broadcasts:

(sent withContext.sendBroadcast) are completely asynchronous. All receivers of the broadcast

are run in an undefined order, often at the same time.

This is more efficient, but means that receivers cannot use the result or abort APIs included here.

BroadcastReceiver
Ordered broadcasts:

(sent withContext.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 theandroid:priorityattribute of the matching
intent-filter; receivers with the same priority will be run in an arbitrary order.

BroadcastReceiver
Some Important Point :

Even in the case of normal broadcasts, the system may in some situations revert to delivering the
broadcast one receiver at a time. In particular, for receivers that may require the creation of a
process, only one will be run at a time to avoid overloading the system with new processes. In
this situation, however, the non-ordered semantics hold: these receivers still cannot return
results or abort their broadcast.

The BroadcastReceiver class (when launched as a component through a

manifest's<receiver>tag) is an important part of anapplication's overall lifecycle.

BroadcastReceiver

Although the Intent class is used for sending and receiving these broadcasts, the Intent broadcast
mechanism here is completely separate from Intents that are used to start Activities
withContext.startActivity().

There is no way for a BroadcastReceiver to see or capture Intents used with startActivity();
likewise, when we broadcast an Intent, we 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.

Receiver Lifecycle
A BroadcastReceiver object is only valid for the duration of the call

toonReceive(Context, Intent). Once code returns from this function, the system
considers the object to be finished and no longer active.
This has important repercussions to what we can do in anonReceive(Context,

Intent)implementation: anything that requires asynchronous operation is not

available, because we 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.

Receiver Lifecycle
A BroadcastReceiver object is only valid for the duration of the call

toonReceive(Context, Intent). Once code returns from this function, the system
considers the object to be finished and no longer active.
This has important repercussions to what we can do in anonReceive(Context,

Intent)implementation: anything that requires asynchronous operation is not

available, because we will need to return from the function to handle the
asynchronous operation.

Receiver Lifecycle
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.

In particular, we maynotshow a dialog or bind to a service from within a

BroadcastReceiver. For the former, we should instead use theNotificationManager

API. For the latter, we can useContext.startService()to send a command to the
service.

Process Lifecycle
A process that is currently executing a BroadcastReceiver (that is, currently

running the code in itsonReceive(Context, Intent)method) is considered to be a

foreground process and will be kept running by the system except under cases of
extreme memory pressure.
Once control return from onReceive(), the BroadcastReceiver is no longer active,

and its hosting process is only as important as any other application components
that are running in it.

Process Lifecycle
This is especially important because if that process was only hosting the

BroadcastReceiver then 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. It is a common case for applications that the user
has never or not recently interacted with.
This means that for longer-running operations we will often use aServicein

conjunction with a BroadcastReceiver to keep the containing process active for the
entire time of your operation.

Security & Permission

Receivers used with theContextAPIs are by their nature a cross-application

facility, so we must consider how other applications may be able to abuse our use
of them. Some things to consider are:
The Intent namespace is global. Make sure that Intent action names and other

strings are written in a namespace we own, or else we may inadvertently conflict

with other applications.
When we useregisterReceiver(BroadcastReceiver, IntentFilter),anyapplication

may send broadcasts to that registered receiver.

Security & Permission

We can control who can send broadcasts to it through permissions described

below.
When we publish a receiver in

application's manifest and specify intent-filters for

it, any other application can send broadcasts to it regardless of the filters specifed.
To prevent others from sending to it, make it unavailable to them

withandroid:exported="false".
When we usesendBroadcast(Intent)or related methods, normally any other

application can receive these broadcasts.

Security & Permission

We can control who can receive such broadcasts through permissions described

below. Alternatively, starting withICE_CREAM_SANDWICH, We can also safely

restrict the broadcast to a single application withIntent.setPackage
None of these issues exist when usingLocalBroadcastManager, since intents

broadcast it never go outside of the current process.

Access permissions can be enforced by either the sender or receiver of a broadcast.

To enforce a permission when sending, supply a non-nullpermissionargument

tosendBroadcast(Intent, String)orsendOrderedBroadcast(Intent, String, BroadcastReceiver,
android.os.Handler, int, String, Bundle).

Security & Permission

Only receivers who have been granted this permission (by requesting it with the<usespermission>tag in theirAndroidManifest.xml) will be able to receive the broadcast.

To enforce a permission when receiving, supply a non-nullpermissionwhen registering receiver

-- either when callingregisterReceiver(BroadcastReceiver, IntentFilter, String,
android.os.Handler)or in the static<receiver>tag in AndroidManifest.xml.

Only broadcasters who have been granted this permission (by requesting it with the<usespermission>tag in theirAndroidManifest.xml) will be able to send an Intent to the receiver.

Contact

Thank You
Apex TG India
E-20 , Sector 63, Noida
0120
4029000/9024/9025/9027
Stay Connected with us for more PPT on Android

+91-9953584548
Email id:
pratap@apextgi.com

Apex TG India Pvt. Ltd. E-20 Sec-63 Noida