extras（附加信息），是其它所有附加信息的集合。使用extras可以为组件提供扩展信息，比如，如果要执行“发送电子邮件”这个动作，可以将电子邮件的标题、正文等保存在extras里，传给电子邮件发送组件。
下面是这些额外属性的几个例子：
ACTION_MAIN with category CATEGORY_HOME //用来 Launch home screen. 以前我也写过一篇于与之有关的文章， 点击这里可以看到。
ACTION_GET_CONTENT with MIME type vnd.android.cursor.item/phone //用来列出列表中的所有人的电话号码
综上可以看出，action、 data/type、category和extras 一起形成了一种语言，这种语言可以是android可以表达出诸如“给张三打电话”之类的短语组合。
三、 intent的解析
应用程序的组件为了告诉Android自己能响应、处理哪些隐式Intent请求，可以声明一个甚至多个Intent Filter。每个Intent Filter描述该组件所能响应Intent请求的能力——组件希望接收什么类型的请求行为，什么类型的请求数据。比如之前请求网页浏览器这个例子中，网页浏览器程序的Intent Filter就应该声明它所希望接收的Intent Action是WEB_SEARCH_ACTION，以及与之相关的请求数据是网页地址URI格式。如何为组件声明自己的Intent Filter? 常见的方法是在AndroidManifest.xml文件中用属性< Intent-Filter>描述组件的Intent Filter。
前面我们提到，隐式Intent(Explicit Intents)和Intent Filter(Implicit Intents)进行比较时的三要素是Intent的动作、数据以及类别。实际上，一个隐式Intent请求要能够传递给目标组件，必要通过这三个方面的检查。如果任何一方面不匹配，Android都不会将该隐式Intent传递给目标组件。接下来我们讲解这三方面检查的具体规则。
1.动作测试
< intent-filter>元素中可以包括子元素< action>，比如：
< intent-filter> < action android:name=”com.example.project.SHOW_CURRENT” /> < action android:name=”com.example.project.SHOW_RECENT” /> < action android:name=”com.example.project.SHOW_PENDING” /> < /intent-filter>
一条< intent-filter>元素至少应该包含一个< action>，否则任何Intent请求都不能和该< intent-filter>匹配。如果Intent请求的Action和< intent-filter>中个某一条< action>匹配，那么该Intent就通过了这条< intent-filter>的动作测试。如果Intent请求或< intent-filter>中没有说明具体的Action类型，那么会出现下面两种情况。
