Intent

  brief introduction ： Intent（ Intention ）, Be responsible for the completion of Android application 、 Interaction and communication between components .
common Activity Call to 、Receiver Sending of 、Service You can't start without Intent.
Intent Usually contains information ：

1. Categpry： species 、 classified .
2. Action： Indicate what to do ？ It usually represents the capability of a component .
3. Data/Extras： Communication data .
4. Flags： Specifies how the system starts a Activity.

---

Activity（ Activities ）

  Usually, a display interface in an application is a Activity,Activity Responsible for displaying the elements of the interface and interaction with users .

Activity Use ：

 Activity The first thing you need to do is AndroidManifest.xml Register in , The way to register is as follows ：

<activity android:name="com.test.TestActivity"></activity>
// So that's one Activity The most basic way to register , stay activity Specify the component name of the component under the tag 

How to use Intent To start a Activity？

  start-up Activity Need to pass through Context Class startActivity() To achieve ,Android in Activity、Service All are Context Subclasses of ,
So in Activity You can call startActivity(). Here's a Activity Start another Activity Example ：

Intent intent = new Intent(this, TestActivity.class);
startActivity(intent);
/* Code above , When TestActivity As mentioned earlier Manifest After registration in , Through this code, you can TestActivity open .  Created a Intent,Intent One... Was passed in respectively Context object （ The above incoming this Because in Activity Constructing the object is ,Activity Is itself a Context, So we introduce a this that will do ）,  And a Activity class （ To be started Activity） */

 Activity There are usually two ways to start , The above description is one of the startup methods , Directly specify the to be started Activity Specific classes of , This startup Activity The method is called display startup . Another way to start Activity The method is called implicit startup .
  What kind of hermit start ？
  The so-called implicit startup is Intent There are no more specific... That need to be started Activity class , But through Intent Provide some information , The system retrieves the information that meets the startup intention Activity. Here we need to insert a concept , Intention filter . stay Manifest Register in Activity etc. Android When the component , You can also add some corresponding attribute tags under the component tag .
  for example :

<intent-filter>
// The filter information of the component can be specified in the tag , The most common designation is Action
<action android:name="com.test.testActivity.action.TEST" />
</intent-filter>

  Start... With implicit intent Activity The way ：

        Intent intent = new Intent();
        intent.setAction("com.test.testActivity.action.TEST");
        startActivity(intent);
        /* In this way , You can start matching to the corresponding Action Of Activity, If   Match to multiple Activity Have the right to Action, At present Android The system processing method is , Let users choose by themselves through the dialog box . */

---

Activity Component safety

  Usually, each component , for example Activity stay Manifest Registration in China , Under the corresponding component label, there is a label as （android:exported）, It indicates whether the component allows external applications to call the component . Usually, this attribute defaults to false Of , That is, external applications are not allowed to call components . however , When the component adds intention filtering , This attribute defaults to true, That is, external applications can also start the corresponding components through implicit intention . This situation is temporarily called component exposure , And exposure means that there are likely to be safety problems .
Let's analyze the possible problems through a scenario ：

/* First, in the test1 A... Is registered in the application WebActivity  At the same time Activity add to Action Filter action android:name="com.test1.action.VIEW_URL  function ： The Activity Need to receive a url Address , Then visit the address . */
<activity android:name="com.test1.WebActivity">
    <intent-filter>
        <action android:name="com.test1.action.VIEW_URL"/>
        <category android:name="android.intent.category.DEFAULT"/>
    </intent-filter>
</activity>

/* stay test2 Register a... In the application TestActivity, The Activity Will invoke... Through implicit intention test1 Medium WebActivity*/
<activity android:name="com.test2.TestActivity"/>

/* The following for TestActivity Start implicitly WebActivity Code for */
Intent intent = new Intent();
intent.setAction("com.test1.action.VIEW_URL");
startActivity(intent);

/* The following for WebActivity In order to get url Value and load the code */
String url = getIntent().getStringExtra("url");
Log.d("WebActivity", "url: " + url.toString());
webView.setWebViewClient(new WebViewClient());
webView.loadUrl(url);

  analysis , What will happen to the above code ？

1. First , from Manifest As can be seen from the registration documents , Declared a WebActivity Of Activity, The Activity Added intent filter , Can pass action To match the activity Turn it on . here , As mentioned above, this WebActivity Due to the addition of intention filter （intent-filter）, So the activity Of exported The property value becomes true, That is the activity Become an exposed component , At this time, all external applications can use this action To start this activity.
2. Look again. WebActivity The code in , adopt Intent To get a key by "url" String . That is to say, any application passes action（com.test1.action.VIEW_URL）, Can evoke WebActivity, also Intent Can carry one Key by url The string provided to the activity Use .
3. This is a normal start with parameters Activity The way , So what's the problem ？ Suppose I have an evil should , I think we should WebActivity You should do something bad , The simplest , Through the following startup methods, I started WebActivity, But at this time, I didn't bring in any url Parameters , The worst thing you can imagine happened , It should have WebActivity Our application crashed completely , Out of the most common NullPointerException.

Intent intent = new Intent();
intent.setAction("com.test1.action.VIEW_URL");
startActivity(intent);

  Here we are. , Many people should know the problem , Some people say , I can be there. Activity First check the obtained url Is it effective , Judge whether it is empty before use . In fact, as a rigorous procedure , For parameters from any untrusted source, the validity of the parameters should be checked , Judge whether the parameters meet the expected needs of the program . So simple ？ This is component security ？NO, This is at most a parameter verification ！

---

  See above , Someone will say , This Activity I use it myself , I can ensure that I have legal parameters when coding , But the problem is when Activity Of exported by true, Indicates that the activity Has been completely exposed , You can get this in a very simple way activity Of action, Then some malicious applications will start it maliciously , When one day the app became famous , With a lot of users , You can guarantee that no malicious application will destroy it ？ It is only a simple parameter validity test that can judge that it may prevent the program from crashing , But will there be some not very elegant url Into our app ？

that , For exposed components , How to ensure the safety of components ？

  This component is unsafe , In the final analysis, it is because it is exposed to other applications , And if we can control its exposure range , Expose it only to applications we trust , Is it not easy to have some of the above malicious attacks ？ Here's how to expose it to trusted applications .
Android Provides Permission Check mechanism to control which execution rights an application has , For example, only when an application has read-write storage permission can it have the right to read and write files stored by the device , Then, can you control whether an application starts the application through permissions activity What about your rights ？ The answer is obvious , Otherwise I wouldn't mention it .
Android Provides the ability to customize permissions , Applications can define their own permissions , The following shows how to Manifest Customize a Permission：

<permission
        android:name="com.myself.permission.WEB"
        android:protectionLevel="signature"
        android:label="permission for opening Web activity"
        />
/** *  Here are three permission Attribute configuration under the tab ： * name: The name of the permission , When using this permission, specify the permission to use by name  * protectionLevel： The level at which this permission is protected , Very important , It mainly introduces three  * ————signature： Signature level permissions , That is, the authority defining party and the registering party must have the same signature to be valid  * ————system： System level permissions , That is, the authority defining party and the registering party must be the system application  * ————signatureOrSystem ： Same as signature or system application , One of the above two is enough  * label： Generally, it is the description of permission  */

  Then the definition of permission is completed , How to use it to protect exposed components , As shown below ：

<permission android:name="com.myself.permission.WEB"
			android:protectionLevel="signature"/>
<activity
    android:permission="com.myself.permission.WEB"
    android:name="com.test1.WebActivity">
    <intent-filter>
        <action android:name="com.test1.action.VIEW_URL"/>
        <category android:name="android.intent.category.DEFAULT"/>
    </intent-filter>
</activity>

/** *  Above , stay activity When making a statement ,activity There's one under the label permission, adopt permission Of name You can specify to protect the activity Authority , such , Only those with this permission activity To start it , Note that both the definer and the user must define and declare custom permissions  */

---

  With the above constraints , Is it right? activity The range of exposure is controllable , such as , When there are mutual component calls between two applications of the same company , You can use the permission of the same signature to restrict , Generally, external applications are not easy to get an application's signature , If properly protected , Then, whether the component is controlled in the trusted calling area .
Here are just examples activity Example , and Android also BroadcastReceiver、Service And so on , The safety control of exposure of other components can also be achieved through permission To control , Specific analysis and follow-up .

---

---

BroadcastReceiver Component safety

  Broadcast as a way of cross process communication , You can receive messages sent by other processes , Therefore, broadcasting is completely an exposed component in its life cycle , Accordingly, there will be the problem of component security .BroadcastReceiver There are two ways to register （ That is, static registration and dynamic registration , Static registration – stay Manifest Declare in the registration , Dynamic registration – Rely on other components in the code , adopt registerReceiver register ）.
 BroadcastReceiver There are mainly the sender and receiver of broadcasting , So when used permission To verify communication, two-way verification is generally required , That is, both the sender and receiver of the broadcast need to add permission verification , Ensure that the sender only sends the broadcast to the trusted receiver , Similarly, the receiver only accepts broadcasts from the trusted party .

Broadcast sender permission

 Android Can be in Context Implementation class through sendBroadcast() Method send broadcast , Mainly through Intent To carry broadcast information , How to add permission verification when sending a broadcast ？

<permission
        android:name="com.myself.permission.BROADCAST_SEND"
        android:protectionLevel="signature"
        android:label="permission for broadcast send"
        />

<uses-permission android:name="com.myself.permission.BROADCAST_SEND"/>
  /** First of all, the same Activity It's the same as in , Before using permissions, you need to define a custom permission */

  /** * sendBroadcast(Intent intent, String receiverPermission) * sendBroadcast There is a method of transmitting a broadcast as described above  * receiverPermission That is, you need the permission of the receiver  */
  Intent intent = new Intent();
  intent.setAction("com.practice.broadcast.action.SEND");
  sendBroadcast(intent, "com.myself.permission.BROADCAST_SEND");

  If above , The broadcast sender has added permissions (“com.myself.permission.BROADCAST_SEND”) The check , That is, if the receiver of a broadcast wants to receive the broadcast , Must be in Manifest You can successfully receive the permission only by adding the corresponding permission in the . The receiver Manifest Add permissions ：

<uses-permission android:name="com.myself.permission.BROADCAST_SEND"/>

Sender authority verification completed .

Broadcast receiver permission

  The broadcast receiver shall be divided into static registration and dynamic registration , Therefore, the verification of permissions is also described in these two cases .

1. The first is to complete a BroadcastReceiver Implementation class of , This class is used to process received broadcast messages .

public class Receiver extends BroadcastReceiver {
    

    // Callback after receiving broadcast information 
    @Override
    public void onReceive(Context context, Intent intent) {
    
      // Remember Activity What did you say , You should do some legal checks on external parameters 
        String action = intent.getAction();
        if (TextUtils.isEmpty(action)) {
    
            return;
        }
        //TODO: deal with something
    }
}

2. Then there is the registration of the broadcast , First, static registration , namely Manifest Register in , as follows ：

<permission
        android:name="com.myself.permission.BROADCAST_RECEIVER"
        android:protectionLevel="signature"
        android:label="permission for broadcast receiver"
        />

<uses-permission android:name="com.myself.permission.BROADCAST_RECEIVER"/>

<receiver
    android:name="com.practice.Receiver"
    android:permission="com.myself.permission.BROADCAST_RECEIVER">
    <intent-filter>
        <action android:name="com.practice.broadcast.action.SEND"/>
    </intent-filter>
</receiver>
/** *  alike receiver There are also attributes under the tag android:permission, *  So it's the same here activity In general , Just define one permission , Add permissions to permission label  *  You can add permission verification for the permission receiver  */

  When the static broadcast receiver adds the above permission verification , signify , It will only accept information from people with （“com.myself.permission.BROADCAST_RECEIVER”） Sent by the sender of the permission （action：“com.practice.broadcast.action.SEND”） radio broadcast , Other broadcasts that do not have this permission even if the corresponding message is sent action Broadcast of , The recipient will not receive , The sender needs to add the following permissions ：

<permission
        android:name="com.myself.permission.BROADCAST_RECEIVER"
        android:protectionLevel="signature"
        android:label="permission for broadcast receiver"
        />

<uses-permission android:name="com.myself.permission.BROADCAST_RECEIVER"/>

  After that, static registration , Let's look at dynamic registration . as follows ：

Receiver receiver = new Receiver();
IntentFilter intentFilter = new IntentFilter();
intentFilter.addAction("com.practice.broadcast.action.SEND");
registerReceiver(receiver, intentFilter);
/** *  Usually you can complete a receiver Dynamic registration of , But this is a broadcast recipient without permission to check , * registerReceiver Is the way to register for broadcasting , You might as well make a bold guess , Is there a registerReceiver Overload method of , with permission What about parameters? , The answer is obvious , *  Therefore, the dynamic registration broadcast with permission is as follows  */
registerReceiver(receiver, intentFilter, "com.myself.permission.BROADCAST_RECEIVER", null);
// The third parameter is permission 

  Come here , The security of broadcast components is also finished , You might as well try your BroadcastReceiver Can you filter out irrelevant broadcasts through permissions ？

---

  This article talks about BroadcastReceiver, Here's a little extra ,
Android O For App Performance and power considerations , The broadcasting of static registration is greatly limited , Except for a few exempted system broadcasts , System broadcasting and customized broadcasting outside the exemption list , Statically registered broadcasts will no longer be received , For example, the broadcast of installation package uninstallation and installation cannot be accepted , For details, please refer to the official website of Google developers Android O Change of conduct . Background execution restrictions
  So how to deal with the previously statically registered broadcast ？

1. Google officially recommends JobScheduler Instead of , But there is no guarantee of effectiveness .
2. Using dynamic registration broadcasting is not affected .
3. For customized broadcast , The sender specifies the package name of the receiver , The broadcast acceptance of static registration is also not affected , Or add permission verification at the same signature level to the broadcast .