- /**
- * How to understand Broadcastreceiver (radio)?
- * In fact, you can think of this, first we have to send a broadcast of the "media", in this case, we use the activity component as the media, of course, later
- * Use service, or random start to send the broadcast, this depends on the business needs to decide.
- * In this example, when the button is clicked, a broadcast is sent out, and the intent object intent is also used.
- * As with activation activity and service, we need to set "tag" and "parcel" for the intended object, which is like a base station, sending a signal to the world.
- * And for the broadcast itself, he is like a listener, a system-level listener, and of course he has the content he listens to, not everything is listening,
- * So how do you determine what the broadcast is listening to?
- * As mentioned above, it is intended that the base station is activated and sent out to send a signal, the signal is marked with "action", for example, the base station sent a mark as
- * Setaction ("Wuchen.broadcastReceiver.MY_RECEIVER") signal,
- * And in the world listen to the broadcast, if you want to hear this signal, you need to let the world know that their existence, and tell the world of their own signals to listen to the mark is what,
- * all must be recorded. This needs to be registered in the manifest manifest file:
- * <receiver android:name= ". Mybroadcastreceiver ">
- <intent-filter>
- <action android:name= "Wuchen.broadcastReceiver.MY_RECEIVER"/>
- </intent-filter>
- </receiver>
- * Once the registration has been successful, the broadcast June will launch and intercept the message whenever a signal from the base station is matched with the broadcast June to the world registration mark.
- * In fact, the broadcast to listen to this process, the above metaphor needs to be adjusted, more rigorous is that the broadcast is not always kept in a state of listening, but in
- * It will only be triggered if the broadcast received by intent is matched with the information of its own registration, and it is different from the system level listening and program level monitoring:
- * Program level monitoring does not have a listening function after the program terminates, while the system level listener will have its own process when it is activated, for example, when a program opens and activates a system
- * System level monitoring, when the program is closed, the level of monitoring does not follow the activation of his program shutdown to stop processing the role of the business, will continue to run,
- * The end of the life cycle unless he himself has completed the business requirements. Strictly speaking, the system level monitoring broadcastreceiver can only run for up to 10 seconds after activation.
- * If the business is not finished within 10 seconds, Android will consider the program unresponsive and eject the ANR (Application no Response) dialog box.
- * for this "restriction", the way we handle this restriction is also the most common method used in the project: Start the service.
- * The most reliable way is to start a service in the broadcast, let the service in the background to process the data, so even if the end of the broadcast life cycle, the service will not be destroyed,
- * Because a service that starts with StartService this way, even if the visitor (broadcast) destroys himself, it will not be destroyed,
- * and the time-consuming operation of data processing in the broadcast, to the service to do, while avoiding the emergence of the ANR problem.
- * the way to start a new thread is also unreliable,
- * The life cycle of the broadcast is the cycle of the internal onreceive method, and when the Onreceiver method ends, it means the end of the broadcast. Although we can be in Onreceiver
- * Internal execution starts a new thread to execute time-consuming business, because the Onreceiver method cycle is very short, it may occur that the child thread has not ended
- * The broadcast is off, and once the broadcast is off, the sub-thread can run, but the system will assume that the broadcast is in a state of component-free activity, and that the process is prioritized when memory is tight, so
- * May cause the child thread to not finish the task. So the best way is to start the service.
- *
- * It is important to note that the world receives the same signal in the broadcast, you can only exist one, maybe broadcast June A and broadcast June B is the same signal
- * This is never in conflict. But whether the broadcast June a first received the signal or broadcast June B first received, which involves the orderly broadcast, and orderly broadcast corresponding to the ordinary broadcast.
- * General Broadcast:
- * Ordinary broadcast can let all the broadcast June to receive the signal (logically), if there are 10 broadcast June, then is a can receive, unable to stop the transmission of the signal.
- * Orderly Broadcast:
- * Orderly broadcast propagation is like passing, for example, there are 10 broadcast June, a to B,b to C, and so on, if D, D want to stop the transmission of the signal, then D
- * The broadcast June will not receive the signal. Although all 10 broadcasters are waiting to receive the same signal, in D here, there is a right to terminate the transmission of the signal.
- * Orderly broadcasting also has a feature, broadcast June can pass his content to the next
- * The only thing to be sure is whether the broadcast June a first received or broadcast June B first received, this need in the broadcast when the king in the registration, taking into account the "priority" problem.
- * Add an attribute android:priority= "100" to the intent-filter tag in each receiver of the configuration file, the higher the number
- * The greater the priority.
- * <receiver android:name= ". Mybroadcastreceiver ">
- <intent-filter android:priority= "One" >
- <action android:name= "Wuchen.broadcastReceiver.MY_RECEIVER"/>
- </intent-filter>
- </receiver>
- <receiver android:name= ". Mybroadcastreceiver_b ">
- <intent-filter android:priority= "Ten" >
- <action android:name= "Wuchen.broadcastReceiver.MY_RECEIVER"/>
- </intent-filter>
- </receiver>
- * @author Administrator
- *
- */
There are a lot of basic concepts about broadcasting, so broadcastreceiver in the actual application will play a role in the end?
Because broadcast is a system-level listener, it can be a "tie" between different interprocess communications. As a simple example, we know that when we start the service, if we start with StartService this way, visitors and service are not able to interact with the data, but with broadcastreceiver, you can interact. Method I roughly say, create a broadcast on the activity side, also create a broadcast on the service side, listen to each other's actions, so that you can achieve the purpose of inter-process communication.
SMS Blocker
Broadcastreceiver can also monitor system processes, such as Android SMS, low power, battery change, system startup, etc... As long as broadcastreceiver listen to these processes, you can achieve a lot of interesting features, such as receiving the text message of this broadcast is an orderly broadcast, so we can listen to this signal, when passed to the real receiver, we will be the custom broadcast receiver program priority is greater than it, and cancel the broadcast transmission, so that can achieve the ability to intercept SMS.
We only need a broadcastreceiver class, we can implement this function, do not need activity, and do not need layout file. Of course, if more commercialization is needed, there are areas for improvement
There's a lot more. For example, we can make an interface that allows users to specify a number from a contact to intercept text messages or to customize them.
Package wuchen.broadcastreceiver;
Import Android.content.BroadcastReceiver;
Import Android.content.Context;
Import android.content.Intent;
Import Android.os.Bundle;
Import Android.telephony.SmsMessage;
Import Android.widget.Toast;
public class Smsreceiver extends Broadcastreceiver
{
triggered when a text message is received
@Override
public void OnReceive (context context, Intent Intent)
{
If you are receiving a text message
if (Intent.getaction (). Equals (
"Android.provider.Telephony.SMS_RECEIVED"))
{
Cancel the broadcast (this line of code will keep the system from receiving text messages)
Abortbroadcast ();
StringBuilder sb = new StringBuilder ();
Receive data sent by SMS
Bundle bundle = Intent.getextras ();
Determine if there is data
if (bundle! = null)
{
Receive all SMS messages via PDUs
Object[] PDUs = (object[]) bundle.get ("PDUs");
Build the SMS Object array and create the size of the array based on the length of the object received
smsmessage[] messages = new Smsmessage[pdus.length];
for (int i = 0; i < pdus.length; i++)
{
Messages[i] = Smsmessage
. CREATEFROMPDU ((byte[]) pdus[i]);
}
Send SMS Merge custom information in StringBuilder
for (Smsmessage message:messages)
{
Sb.append ("SMS Source:");
Get the phone number to receive the SMS
Sb.append (Message.getdisplayoriginatingaddress ());
Sb.append ("\ n------SMS content------\ n");
Get the message content
Sb.append (Message.getdisplaymessagebody ());
}
}
Toast.maketext (Context, sb.tostring ()
, (). Show ();
}
}
}
<?xml version= "1.0" encoding= "Utf-8"?>
2 <manifest xmlns:android= "Http://schemas.android.com/apk/res/android"
3 package= "Wuchen.broadcastreceiver"
4 android:versioncode= "1"
5 Android:versionname= "1.0" >
6 <application android:icon= "@drawable/icon" android:label= "@string/app_name" >
7 <receiver android:name= ". Smsreceiver ">
8 <intent-filter android:priority= ">"
9 <action android:name= "Android.provider.Telephony.SMS_RECEIVED"/>
Ten </intent-filter>
</receiver>
</application>
<!--grant the program permission to receive text messages--
<uses-permission android:name= "Android.permission.RECEIVE_SMS"/>
</manifest>
Android--broadcastreceiver Broadcast SMS Interception