|
28 | 28 |
|
29 | 29 | /** |
30 | 30 | * Base class for code that will receive intents sent by sendBroadcast(). |
31 | | - * You can either dynamically register an instance of this class with |
| 31 | + * |
| 32 | + * <p>If you don't need to send broadcasts across applications, consider using |
| 33 | + * this class with {@link android.support.v4.content.LocalBroadcastManager} instead |
| 34 | + * of the more general facilities described below. This will give you a much |
| 35 | + * more efficient implementation (no cross-process communication needed) and allow |
| 36 | + * you to avoid thinking about any security issues related to other applications |
| 37 | + * being able to receive or send your broadcasts. |
| 38 | + * |
| 39 | + * <p>You can either dynamically register an instance of this class with |
32 | 40 | * {@link Context#registerReceiver Context.registerReceiver()} |
33 | 41 | * or statically publish an implementation through the |
34 | 42 | * {@link android.R.styleable#AndroidManifestReceiver <receiver>} |
35 | | - * tag in your <code>AndroidManifest.xml</code>. <em><strong>Note:</strong></em> |
| 43 | + * tag in your <code>AndroidManifest.xml</code>. |
| 44 | + * |
| 45 | + * <p><em><strong>Note:</strong></em> |
36 | 46 | * If registering a receiver in your |
37 | 47 | * {@link android.app.Activity#onResume() Activity.onResume()} |
38 | 48 | * implementation, you should unregister it in |
|
86 | 96 | * |
87 | 97 | * <p>Topics covered here: |
88 | 98 | * <ol> |
| 99 | + * <li><a href="#Security">Security</a> |
89 | 100 | * <li><a href="#ReceiverLifecycle">Receiver Lifecycle</a> |
90 | | - * <li><a href="#Permissions">Permissions</a> |
91 | 101 | * <li><a href="#ProcessLifecycle">Process Lifecycle</a> |
92 | 102 | * </ol> |
93 | 103 | * |
|
98 | 108 | * developer guide.</p> |
99 | 109 | * </div> |
100 | 110 | * |
101 | | - * <a name="ReceiverLifecycle"></a> |
102 | | - * <h3>Receiver Lifecycle</h3> |
103 | | - * |
104 | | - * <p>A BroadcastReceiver object is only valid for the duration of the call |
105 | | - * to {@link #onReceive}. Once your code returns from this function, |
106 | | - * the system considers the object to be finished and no longer active. |
107 | | - * |
108 | | - * <p>This has important repercussions to what you can do in an |
109 | | - * {@link #onReceive} implementation: anything that requires asynchronous |
110 | | - * operation is not available, because you will need to return from the |
111 | | - * function to handle the asynchronous operation, but at that point the |
112 | | - * BroadcastReceiver is no longer active and thus the system is free to kill |
113 | | - * its process before the asynchronous operation completes. |
114 | | - * |
115 | | - * <p>In particular, you may <i>not</i> show a dialog or bind to a service from |
116 | | - * within a BroadcastReceiver. For the former, you should instead use the |
117 | | - * {@link android.app.NotificationManager} API. For the latter, you can |
118 | | - * use {@link android.content.Context#startService Context.startService()} to |
119 | | - * send a command to the service. |
120 | | - * |
121 | | - * <a name="Permissions"></a> |
122 | | - * <h3>Permissions</h3> |
123 | | - * |
| 111 | + * <a name="Security"></a> |
| 112 | + * <h3>Security</h3> |
| 113 | + * |
| 114 | + * <p>Receivers used with the {@link Context} APIs are by their nature a |
| 115 | + * cross-application facility, so you must consider how other applications |
| 116 | + * may be able to abuse your use of them. Some things to consider are: |
| 117 | + * |
| 118 | + * <ul> |
| 119 | + * <li><p>The Intent namespace is global. Make sure that Intent action names and |
| 120 | + * other strings are written in a namespace you own, or else you may inadvertantly |
| 121 | + * conflict with other applications. |
| 122 | + * <li><p>When you use {@link Context#registerReceiver(BroadcastReceiver, IntentFilter)}, |
| 123 | + * <em>any</em> application may send broadcasts to that registered receiver. You can |
| 124 | + * control who can send broadcasts to it through permissions described below. |
| 125 | + * <li><p>When you publish a receiver in your application's manifest and specify |
| 126 | + * intent-filters for it, any other application can send broadcasts to it regardless |
| 127 | + * of the filters you specify. To prevent others from sending to it, make it |
| 128 | + * unavailable to them with <code>android:exported="false"</code>. |
| 129 | + * <li><p>When you use {@link Context#sendBroadcast(Intent)} or related methods, |
| 130 | + * normally any other application can receive these broadcasts. You can control who |
| 131 | + * can receive such broadcasts through permissions described below. Alternatively, |
| 132 | + * starting with {@link android.os.Build.VERSION_CODES#ICE_CREAM_SANDWICH}, you |
| 133 | + * can also safely restrict the broadcast to a single application with |
| 134 | + * {@link Intent#setPackage(String) Intent.setPackage} |
| 135 | + * </ul> |
| 136 | + * |
| 137 | + * <p>None of these issues exist when using |
| 138 | + * {@link android.support.v4.content.LocalBroadcastManager}, since intents |
| 139 | + * broadcast it never go outside of the current process. |
| 140 | + * |
124 | 141 | * <p>Access permissions can be enforced by either the sender or receiver |
125 | | - * of an Intent. |
126 | | - * |
| 142 | + * of a broadcast. |
| 143 | + * |
127 | 144 | * <p>To enforce a permission when sending, you supply a non-null |
128 | 145 | * <var>permission</var> argument to |
129 | 146 | * {@link Context#sendBroadcast(Intent, String)} or |
|
133 | 150 | * {@link android.R.styleable#AndroidManifestUsesPermission <uses-permission>} |
134 | 151 | * tag in their <code>AndroidManifest.xml</code>) will be able to receive |
135 | 152 | * the broadcast. |
136 | | - * |
| 153 | + * |
137 | 154 | * <p>To enforce a permission when receiving, you supply a non-null |
138 | 155 | * <var>permission</var> when registering your receiver -- either when calling |
139 | 156 | * {@link Context#registerReceiver(BroadcastReceiver, IntentFilter, String, android.os.Handler)} |
|
144 | 161 | * {@link android.R.styleable#AndroidManifestUsesPermission <uses-permission>} |
145 | 162 | * tag in their <code>AndroidManifest.xml</code>) will be able to send an |
146 | 163 | * Intent to the receiver. |
147 | | - * |
| 164 | + * |
148 | 165 | * <p>See the <a href="{@docRoot}guide/topics/security/security.html">Security and Permissions</a> |
149 | 166 | * document for more information on permissions and security in general. |
| 167 | + * |
| 168 | + * <a name="ReceiverLifecycle"></a> |
| 169 | + * <h3>Receiver Lifecycle</h3> |
| 170 | + * |
| 171 | + * <p>A BroadcastReceiver object is only valid for the duration of the call |
| 172 | + * to {@link #onReceive}. Once your code returns from this function, |
| 173 | + * the system considers the object to be finished and no longer active. |
| 174 | + * |
| 175 | + * <p>This has important repercussions to what you can do in an |
| 176 | + * {@link #onReceive} implementation: anything that requires asynchronous |
| 177 | + * operation is not available, because you will need to return from the |
| 178 | + * function to handle the asynchronous operation, but at that point the |
| 179 | + * BroadcastReceiver is no longer active and thus the system is free to kill |
| 180 | + * its process before the asynchronous operation completes. |
150 | 181 | * |
| 182 | + * <p>In particular, you may <i>not</i> show a dialog or bind to a service from |
| 183 | + * within a BroadcastReceiver. For the former, you should instead use the |
| 184 | + * {@link android.app.NotificationManager} API. For the latter, you can |
| 185 | + * use {@link android.content.Context#startService Context.startService()} to |
| 186 | + * send a command to the service. |
| 187 | + * |
151 | 188 | * <a name="ProcessLifecycle"></a> |
152 | 189 | * <h3>Process Lifecycle</h3> |
153 | 190 | * |
|
0 commit comments