Android：BroadcastReceiver

android.content.BroadcastReceier.

 

 

public abstract class

BroadcastReceiver

extends Object

Class Overview

Base class for code that will receive intents sent by sendBroadcast(). You can either dynamically register an instance of this class with Context.registerReceiver() or statically publish an implementation through the <receiver> tag in your AndroidManifest.xml. Note:    If registering a receiver in your Activity.onResume() implementation, you should unregister it in Activity.onPause(). (You won't receive intents when paused, and this will cut down on unnecessary system overhead). Do not unregister in Activity.onSaveInstanceState(), because this won't be called if the user moves back in the history stack.

 

作用：接收由sendBroadcast()發送的Intent。

 

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

• Normal broadcasts (sent with Context.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.
• 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.

這裡：Normal broadcasts是不按順序發送廣播訊息的。而Ordered broadcasts是一次只發送一個廣播訊息給一個接收者。

 

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.

 

Note that, 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 with Context.startActivity(). 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.

 

注意：通過Context.startActivity啟動Intent和使用BroadcastReceiver廣播Intent在運行方式中是不同的，前者是處於前台的，而後者處於背景。

 

The BroadcastReceiver class (when launched as a component through a manifest's <receiver> tag) is an important part of an application's overall lifecycle.

 

Topics covered here:

1. Receiver Lifecycle
2. Permissions
3. Process Lifecycle

Receiver Lifecycle

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.

This has important repercussions不良後果 to what you can do in an onReceive(Context, Intent) implementation: anything that requires asynchronous operation is not available, because you 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.

In particular, you may not show a dialog or bind to a service from within a BroadcastReceiver. For the former, you should instead use the NotificationManager API. For the latter, you can use Context.startService() to send a command to the service.

 

BroadcastReceiver的生命期只處於調用onReceive期間，所以在onReceive函數執行過程中，不能調用非同步作業。也不能顯示對話方塊或和某個服務進行綁定。

Permissions

Access permissions can be enforced by either the sender or receiver of an Intent.

To enforce a permission when sending, you supply a non-null permission argument to sendBroadcast(Intent, String) or sendOrderedBroadcast(Intent, String, BroadcastReceiver, android.os.Handler, int, String, Bundle). Only receivers who have been granted this permission (by requesting it with the <uses-permission> tag in their AndroidManifest.xml) will be able to receive the broadcast.

To enforce a permission when receiving, you supply a non-null permission when registering your receiver -- either when calling registerReceiver(BroadcastReceiver, IntentFilter, String, android.os.Handler) or in the static <receiver> tag in your AndroidManifest.xml. Only broadcasters who have been granted this permission (by requesting it with the <uses-permission> tag in their AndroidManifest.xml) will be able to send an Intent to the receiver.

See the Security and Permissions document for more information on permissions and security in general.

Process Lifecycle

A process that is currently executing a BroadcastReceiver (that is, currently running the code in its onReceive(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 you 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. This is especially important because if that process was only hosting the BroadcastReceiver (a common case for applications that the user has never or not recently interacted with), 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.

This means that for longer-running operations you will often use a Service in conjunction with a BroadcastReceiver to keep the containing process active for the entire time of your operation.

 

需要特別注意的是：如果hosting process中只有Broadcast Receiver的話，一旦Broadcast Receiver的onReceive()函數執行完後，就會被系統認為是空進程，而被殺掉。所以一般要使Broadcast Receiver長期在操作過程中有效話，就和Service一起綁定使用。

 

 

下面是一些常用的成員函數：

 

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~·

public final String getResultData () Since: API Level 1

Retrieve the current result data, as set by the previous receiver. Often this is null.

Returns

• String The current result data; may be null.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~·

public abstract void onReceive (Context context, Intent intent) Since: API Level 1

This method is called when the BroadcastReceiver is receiving an Intent broadcast. During this time you can use the other methods on BroadcastReceiver to view/modify the current result values. The function is normally called within the main thread of its process, so you should never perform long-running operations in it (there is a timeout of 10 seconds that the system allows before considering the receiver to be blocked and a candidate to be killed). You cannot launch a popup dialog in your implementation of onReceive().

If this BroadcastReceiver was launched through a <receiver> tag, then the object is no longer alive after returning from this function. This means you should not perform any operations that return a result to you asynchronously -- in particular, for interacting with services, you should use startService(Intent) instead of bindService(Intent, ServiceConnection, int). If you wish to interact with a service that is already running, you can use peekService(Context, Intent).

 

The Intent filters used in registerReceiver(BroadcastReceiver, IntentFilter) and in application manifests are not guaranteed to be exclusive. They are hints to the operating system about how to find suitable recipients. It is possible for senders to force delivery to specific recipients, bypassing filter resolution. For this reason, onReceive() implementations should respond only to known actions, ignoring any unexpected Intents that they may receive.

Parameters

context	The Context in which the receiver is running.
intent	The Intent being received.

onReceive()函數當BroadcastReceiver收到新的Intent時才會執行。

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

public final void setResult (int code, String data, Bundle extras) Since: API Level 1

Change all of the result data returned from this broadcasts; only works with broadcasts sent through Context.sendOrderedBroadcast. All current result data is replaced by the value given to this method.

This method does not work with non-ordered broadcasts such as those sent with Context.sendBroadcast

 

Parameters

code	The new result code. Often uses the Activity RESULT_CANCELED and RESULT_OK constants, though the actual meaning of this value is ultimately up to the broadcaster.
data	The new result data. This is an arbitrary string whose interpretation is up to the broadcaster; may be null.
extras	The new extra data map. This is a Bundle holding arbitrary data, whose interpretation is up to the broadcaster. Can be set to null. This completely replaces the current map (if any).

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~深入理解一下：（轉載。。。。）在Android中，Broadcast是一種廣泛運用的在應用程式之間傳輸資訊的機制。而BroadcastReceiver是對發送出來

的Broadcast進行過濾接受並響應的一類組件。下面將詳細的闡述如何發送Broadcast和使用BroadcastReceiver過

濾接收的過程：

首先在需要發送資訊的地方，把要發送的資訊和用於過濾的資訊（如Action、Category)裝入一個Intent對象，

然後通過調用Context.sendBroadcast(),sendOrderBroadcast()或sendStickyBroadcast()方法，把Intent對象以廣

播方式發送出去。當Intent發送以後，所有已經註冊的BroadcastReceiver會檢查註冊時的IntentFilter是否與發

送的Intent相匹配，若匹配則就會調用BroadcastReceiver的onReceive()方法。所以當我們定義一個

BroadcastReceiver的時候，都需要實現onReceive（）方法。

註冊BroadcastReceiver有兩種方式。一種方式是，靜態在AndroidManifest.xml中用<receiver>標籤生命注

冊，並在標籤內用<intent-filter>標籤設定過濾器。另一種方式是，動態在代碼中先定義並設定好一個

IntentFilter對象，然後在需要註冊的地方調用Context.registerReceiver()方法，如果取消時就調用

Context.unregisterReceiver()方法。如果用動態方式註冊的BroadcastReceiver的Context對象被銷毀

時，BroadcastReceiver也就自動取消註冊了。

另外，若在使用sendBroadcast()的方法是指定了接收許可權，則只有在AndroidManifest.xml中用<uses-

permission>標籤聲明了擁有此許可權的BroascastReceiver才會有可能接收到發送來的Broadcast。同樣若在註冊

BroadcastReceiver時指定了可接收的Broadcast的許可權，則只有在包內的AndroidManifest.xml中用<uses-

permission>標籤聲明了，擁有此許可權的Context對象所發送的Broadcast才能被這個BroadcastReceiver所接

收。