1+ /*
2+ * Copyright (C) 2006 The Android Open Source Project
3+ *
4+ * Licensed under the Apache License, Version 2.0 (the "License");
5+ * you may not use this file except in compliance with the License.
6+ * You may obtain a copy of the License at
7+ *
8+ * http://www.apache.org/licenses/LICENSE-2.0
9+ *
10+ * Unless required by applicable law or agreed to in writing, software
11+ * distributed under the License is distributed on an "AS IS" BASIS,
12+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
13+ * See the License for the specific language governing permissions and
14+ * limitations under the License.
15+ */
16+ package android .content ;
17+
18+ import android .os .Bundle ;
19+ /**
20+ * Base class for code that will receive intents sent by sendBroadcast().
21+ *
22+ * <p>If you don't need to send broadcasts across applications, consider using
23+ * this class with {@link android.support.v4.content.LocalBroadcastManager} instead
24+ * of the more general facilities described below. This will give you a much
25+ * more efficient implementation (no cross-process communication needed) and allow
26+ * you to avoid thinking about any security issues related to other applications
27+ * being able to receive or send your broadcasts.
28+ *
29+ * <p>You can either dynamically register an instance of this class with
30+ * {@link Context#registerReceiver Context.registerReceiver()}
31+ * or statically publish an implementation through the
32+ * {@link android.R.styleable#AndroidManifestReceiver <receiver>}
33+ * tag in your <code>AndroidManifest.xml</code>.
34+ *
35+ * <p><em><strong>Note:</strong></em>
36+ * If registering a receiver in your
37+ * {@link android.app.Activity#onResume() Activity.onResume()}
38+ * implementation, you should unregister it in
39+ * {@link android.app.Activity#onPause() Activity.onPause()}.
40+ * (You won't receive intents when paused,
41+ * and this will cut down on unnecessary system overhead). Do not unregister in
42+ * {@link android.app.Activity#onSaveInstanceState(android.os.Bundle) Activity.onSaveInstanceState()},
43+ * because this won't be called if the user moves back in the history
44+ * stack.
45+ *
46+ * <p>There are two major classes of broadcasts that can be received:</p>
47+ * <ul>
48+ * <li> <b>Normal broadcasts</b> (sent with {@link Context#sendBroadcast(Intent)
49+ * Context.sendBroadcast}) are completely asynchronous. All receivers of the
50+ * broadcast are run in an undefined order, often at the same time. This is
51+ * more efficient, but means that receivers cannot use the result or abort
52+ * APIs included here.
53+ * <li> <b>Ordered broadcasts</b> (sent with {@link Context#sendOrderedBroadcast(Intent, String)
54+ * Context.sendOrderedBroadcast}) are delivered to one receiver at a time.
55+ * As each receiver executes in turn, it can propagate a result to the next
56+ * receiver, or it can completely abort the broadcast so that it won't be passed
57+ * to other receivers. The order receivers run in can be controlled with the
58+ * {@link android.R.styleable#AndroidManifestIntentFilter_priority
59+ * android:priority} attribute of the matching intent-filter; receivers with
60+ * the same priority will be run in an arbitrary order.
61+ * </ul>
62+ *
63+ * <p>Even in the case of normal broadcasts, the system may in some
64+ * situations revert to delivering the broadcast one receiver at a time. In
65+ * particular, for receivers that may require the creation of a process, only
66+ * one will be run at a time to avoid overloading the system with new processes.
67+ * In this situation, however, the non-ordered semantics hold: these receivers still
68+ * cannot return results or abort their broadcast.</p>
69+ *
70+ * <p>Note that, although the Intent class is used for sending and receiving
71+ * these broadcasts, the Intent broadcast mechanism here is completely separate
72+ * from Intents that are used to start Activities with
73+ * {@link Context#startActivity Context.startActivity()}.
74+ * There is no way for a BroadcastReceiver
75+ * to see or capture Intents used with startActivity(); likewise, when
76+ * you broadcast an Intent, you will never find or start an Activity.
77+ * These two operations are semantically very different: starting an
78+ * Activity with an Intent is a foreground operation that modifies what the
79+ * user is currently interacting with; broadcasting an Intent is a background
80+ * operation that the user is not normally aware of.
81+ *
82+ * <p>The BroadcastReceiver class (when launched as a component through
83+ * a manifest's {@link android.R.styleable#AndroidManifestReceiver <receiver>}
84+ * tag) is an important part of an
85+ * <a href="{@docRoot}guide/topics/fundamentals.html#lcycles">application's overall lifecycle</a>.</p>
86+ *
87+ * <p>Topics covered here:
88+ * <ol>
89+ * <li><a href="#Security">Security</a>
90+ * <li><a href="#ReceiverLifecycle">Receiver Lifecycle</a>
91+ * <li><a href="#ProcessLifecycle">Process Lifecycle</a>
92+ * </ol>
93+ *
94+ * <div class="special reference">
95+ * <h3>Developer Guides</h3>
96+ * <p>For information about how to use this class to receive and resolve intents, read the
97+ * <a href="{@docRoot}guide/topics/intents/intents-filters.html">Intents and Intent Filters</a>
98+ * developer guide.</p>
99+ * </div>
100+ *
101+ * <a name="Security"></a>
102+ * <h3>Security</h3>
103+ *
104+ * <p>Receivers used with the {@link Context} APIs are by their nature a
105+ * cross-application facility, so you must consider how other applications
106+ * may be able to abuse your use of them. Some things to consider are:
107+ *
108+ * <ul>
109+ * <li><p>The Intent namespace is global. Make sure that Intent action names and
110+ * other strings are written in a namespace you own, or else you may inadvertantly
111+ * conflict with other applications.
112+ * <li><p>When you use {@link Context#registerReceiver(BroadcastReceiver, IntentFilter)},
113+ * <em>any</em> application may send broadcasts to that registered receiver. You can
114+ * control who can send broadcasts to it through permissions described below.
115+ * <li><p>When you publish a receiver in your application's manifest and specify
116+ * intent-filters for it, any other application can send broadcasts to it regardless
117+ * of the filters you specify. To prevent others from sending to it, make it
118+ * unavailable to them with <code>android:exported="false"</code>.
119+ * <li><p>When you use {@link Context#sendBroadcast(Intent)} or related methods,
120+ * normally any other application can receive these broadcasts. You can control who
121+ * can receive such broadcasts through permissions described below. Alternatively,
122+ * starting with {@link android.os.Build.VERSION_CODES#ICE_CREAM_SANDWICH}, you
123+ * can also safely restrict the broadcast to a single application with
124+ * {@link Intent#setPackage(String) Intent.setPackage}
125+ * </ul>
126+ *
127+ * <p>None of these issues exist when using
128+ * {@link android.support.v4.content.LocalBroadcastManager}, since intents
129+ * broadcast it never go outside of the current process.
130+ *
131+ * <p>Access permissions can be enforced by either the sender or receiver
132+ * of a broadcast.
133+ *
134+ * <p>To enforce a permission when sending, you supply a non-null
135+ * <var>permission</var> argument to
136+ * {@link Context#sendBroadcast(Intent, String)} or
137+ * {@link Context#sendOrderedBroadcast(Intent, String, BroadcastReceiver, android.os.Handler, int, String, Bundle)}.
138+ * Only receivers who have been granted this permission
139+ * (by requesting it with the
140+ * {@link android.R.styleable#AndroidManifestUsesPermission <uses-permission>}
141+ * tag in their <code>AndroidManifest.xml</code>) will be able to receive
142+ * the broadcast.
143+ *
144+ * <p>To enforce a permission when receiving, you supply a non-null
145+ * <var>permission</var> when registering your receiver -- either when calling
146+ * {@link Context#registerReceiver(BroadcastReceiver, IntentFilter, String, android.os.Handler)}
147+ * or in the static
148+ * {@link android.R.styleable#AndroidManifestReceiver <receiver>}
149+ * tag in your <code>AndroidManifest.xml</code>. Only broadcasters who have
150+ * been granted this permission (by requesting it with the
151+ * {@link android.R.styleable#AndroidManifestUsesPermission <uses-permission>}
152+ * tag in their <code>AndroidManifest.xml</code>) will be able to send an
153+ * Intent to the receiver.
154+ *
155+ * <p>See the <a href="{@docRoot}guide/topics/security/security.html">Security and Permissions</a>
156+ * document for more information on permissions and security in general.
157+ *
158+ * <a name="ReceiverLifecycle"></a>
159+ * <h3>Receiver Lifecycle</h3>
160+ *
161+ * <p>A BroadcastReceiver object is only valid for the duration of the call
162+ * to {@link #onReceive}. Once your code returns from this function,
163+ * the system considers the object to be finished and no longer active.
164+ *
165+ * <p>This has important repercussions to what you can do in an
166+ * {@link #onReceive} implementation: anything that requires asynchronous
167+ * operation is not available, because you will need to return from the
168+ * function to handle the asynchronous operation, but at that point the
169+ * BroadcastReceiver is no longer active and thus the system is free to kill
170+ * its process before the asynchronous operation completes.
171+ *
172+ * <p>In particular, you may <i>not</i> show a dialog or bind to a service from
173+ * within a BroadcastReceiver. For the former, you should instead use the
174+ * {@link android.app.NotificationManager} API. For the latter, you can
175+ * use {@link android.content.Context#startService Context.startService()} to
176+ * send a command to the service.
177+ *
178+ * <a name="ProcessLifecycle"></a>
179+ * <h3>Process Lifecycle</h3>
180+ *
181+ * <p>A process that is currently executing a BroadcastReceiver (that is,
182+ * currently running the code in its {@link #onReceive} method) is
183+ * considered to be a foreground process and will be kept running by the
184+ * system except under cases of extreme memory pressure.
185+ *
186+ * <p>Once you return from onReceive(), the BroadcastReceiver is no longer
187+ * active, and its hosting process is only as important as any other application
188+ * components that are running in it. This is especially important because if
189+ * that process was only hosting the BroadcastReceiver (a common case for
190+ * applications that the user has never or not recently interacted with), then
191+ * upon returning from onReceive() the system will consider its process
192+ * to be empty and aggressively kill it so that resources are available for other
193+ * more important processes.
194+ *
195+ * <p>This means that for longer-running operations you will often use
196+ * a {@link android.app.Service} in conjunction with a BroadcastReceiver to keep
197+ * the containing process active for the entire time of your operation.
198+ */
199+ public abstract class BroadcastReceiver {
200+
201+ /**
202+ * State for a result that is pending for a broadcast receiver. Returned
203+ * by {@link BroadcastReceiver#goAsync() goAsync()}
204+ * while in {@link BroadcastReceiver#onReceive BroadcastReceiver.onReceive()}.
205+ * This allows you to return from onReceive() without having the broadcast
206+ * terminate; you must call {@link #finish()} once you are done with the
207+ * broadcast. This allows you to process the broadcast off of the main
208+ * thread of your app.
209+ *
210+ * <p>Note on threading: the state inside of this class is not itself
211+ * thread-safe, however you can use it from any thread if you properly
212+ * sure that you do not have races. Typically this means you will hand
213+ * the entire object to another thread, which will be solely responsible
214+ * for setting any results and finally calling {@link #finish()}.
215+ */
216+
217+ public BroadcastReceiver () {
218+ }
219+ /**
220+ * This method is called when the BroadcastReceiver is receiving an Intent
221+ * broadcast. During this time you can use the other methods on
222+ * BroadcastReceiver to view/modify the current result values. This method
223+ * is always called within the main thread of its process, unless you
224+ * explicitly asked for it to be scheduled on a different thread using
225+ * {@link android.content.Context#registerReceiver(BroadcastReceiver,
226+ * IntentFilter, String, android.os.Handler)}. When it runs on the main
227+ * thread you should
228+ * never perform long-running operations in it (there is a timeout of
229+ * 10 seconds that the system allows before considering the receiver to
230+ * be blocked and a candidate to be killed). You cannot launch a popup dialog
231+ * in your implementation of onReceive().
232+ *
233+ * <p><b>If this BroadcastReceiver was launched through a <receiver> tag,
234+ * then the object is no longer alive after returning from this
235+ * function.</b> This means you should not perform any operations that
236+ * return a result to you asynchronously -- in particular, for interacting
237+ * with services, you should use
238+ * {@link Context#startService(Intent)} instead of
239+ * {@link Context#bindService(Intent, ServiceConnection, int)}. If you wish
240+ * to interact with a service that is already running, you can use
241+ * {@link #peekService}.
242+ *
243+ * <p>The Intent filters used in {@link android.content.Context#registerReceiver}
244+ * and in application manifests are <em>not</em> guaranteed to be exclusive. They
245+ * are hints to the operating system about how to find suitable recipients. It is
246+ * possible for senders to force delivery to specific recipients, bypassing filter
247+ * resolution. For this reason, {@link #onReceive(Context, Intent) onReceive()}
248+ * implementations should respond only to known actions, ignoring any unexpected
249+ * Intents that they may receive.
250+ *
251+ * @param context The Context in which the receiver is running.
252+ * @param intent The Intent being received.
253+ */
254+ public abstract void onReceive (Context context , Intent intent );
255+ }
0 commit comments