Control API是Smart Extension APIs中的一部分。前面一篇讲到了Sony Extension API。Sony某些智能配件支持Control API。Control API让Extension可以完全控制配件，包括控制屏幕、LED、振动、输入。正是由于是完全控制设备，所以同一时刻只能有一个Extension运行。
Control API包括以下内容：
注册
Control Extension可以使用配件之前，需要使用注册API中的Content Provider插入一条记录到Extension表中(原文：it must use the registration API content provider to insert a record in the extension table)。此外还应在注册表中添加信息。每个可与Extension交互的主应用(Host Application)均应完成上述过程。
为了知道有哪些主应用可用以及主应用支持哪些功能，Extension需要使用Capability API
Extension的生命周期
Extension成功注册后即可与主应用通信。再次强调，由于Extension是完全控制配件，所以同一时刻只有一个Extension运行
Extension并不能任意执行，它应先确认没有其他Extension在运行，这种情况下当前Extension才能使用CONTROL_ START_ REQUEST_ INTENT来请求运行自己。 当主应用准备好将控制权交给 Extension后它将发出一个CONTROL_ START_ INTENT响应。见下图
当Extension请求控制配件时，主应用可以接受请求并交出控制权；或者由于某些情况，拒绝该请求并发出一个CONTROL_ ERROR_ INTENT响应。主应用可以发出的错误码请参考EXTRA_ ERROR_ CODE
当Extension在配件上可见主应用时将发出CONTROL_ RESUME_ INTENT。可以认为这里Extension控制一切了，而主应用不过是在配件和Extension之间传递信息。
当一个高优先级的Extension临时需要运行时或者主应用负责管理屏幕状态而屏幕 关闭时，也可以暂停Extension。这种情况下主应用给Extension发送CONTROL_ PAUSE_ INTENT。也就是，当前Extension已关闭或者其他Extension开始控制配件，所以当前Extension再也不能更新屏幕了。当Extension强行更新屏幕时，主应用会忽略这些违反规定的调用。
当Extension处于暂停状态时，它不能控制屏幕/LED/振动器/按键事件。一个例子是通话Extension，它具有高优先级。比如，当某个Extension正在运行，这时用户接到一个电话。我们希望能够暂停正在运行的Extension，让通话Extension在屏幕上显示来电号码。当通话结束后，结束通话Extension并重新运行原来的Extension，原来的Extension会接收到CONTROL_ RESUME_ INTENT。
主应用发出CONTROL_ RESUME_ INTENT后，原来的Extension将重新控制一切了。
用户退出Extension时主应用会发送一个CONTROL_ PAUSE_ INTENT和一个CONTROL_ STOP_ INTENT。这时主应用重新获得控制权。
当正在运行的Extension想结束自己，比如通话Extension，可以向主应用发送CONTROL_ STOP_ REQUEST_ INTENT。主应用将停止它并发送一个CONTROL_ STOP_ INTENT。如果这个Extension还未停止，主应用发送CONTROL_ STOP_ INTENT之前将先发送CONTROL_ PAUSE_ INTENT。相应地，其他被暂停的Extension将重新运行。
控制屏幕
实现了Control API的Extension可以控制配件的屏幕状态。使用CONTROL_ SET_ SCREEN_ STATE_ INTENT控制屏幕。
无论在手机端还是配件端，编程时应注意尽可能消耗更少的电量，这点非常重要。配件的电池比手机小得多，所以使用各种功能时应小心。尽可能让主应用控制屏幕状态。这样的话，你就不心担心配件上的电量消耗问题。仅需将屏幕状态设置为"自动"即可。
其实缺省情况下，Extension启动时屏幕状态会被设置为"自动"，所以主应用会控制屏幕开/关/暗等行为。如果Extension想要控制屏幕状态，它必须明确进行修改。
Extension停止时，主应用会自动接管屏幕控制。
注意：当处理"自动"状态时，屏幕关时Extension将收到一个CONTROL_ PAUSE_ INTENT；屏幕开时会收到一个CONTROL_ RESUME_ INTENT。
活动节能模式
某些配件可能支持这样一种模式：信息可以展示给用户但同时保持电量消耗最少。 这种活动节能模式仅能以黑白色显示内容。支持该模式的配件通过SUPPORTS_ LOW_ POWER_ MODE来标识将启动活动节能模式。如果Extension想使用这种模式，它必须在注册到主应用时将LOW_ POWER_ SUPPORT设置为TRUE。
如果Extension和配件都支持活动节能模式，屏幕关时将激活这一模式。即，如果屏幕状态是SCREEN_ STATE_ AUTO，配件将判断何时进入活动节能模式。如果屏幕状态是SCREEN_ STATE _ON或SCREEN_ STATE _DIM，Extension可以通过设置屏幕状态为SCREEN_ STATE _OFF来激活活动节能模式。无论是Extension还是配件激活活动节能模式， Extension都会收到一个CONTROL_ ACTIVE _POWER _SAVE _MODE _STATUS _CHANGED _INTENT。另外，在活动节能模式下，Extension仍然可以使用正常显式模块下的方法来更新屏幕。
如果屏幕状态是SCREEN_ STATE _AUTO，并且是由配件主动进入活动节能模式，配件也可以决定什么时候退出这种模式。注意，活动节能模式中Extension不会收到来自配件的任何输入事件，因为这将导致退出活动节能模式。如果是由Extension主动进入活动节能模式，则仍然需要Extension决定什么时候退出该模式，退出时需要设置屏幕状态为SCREEN_ STATE _ON。如果Extension想在屏幕处于活动节能模式时仍然收到输入事件，则只能由它自己主动进入该模式(而不是由配件主动进入)。当屏幕退出活动节能模式时，Extension都会收到CONTROL_ ACTIVE _POWER _SAVE _MODE _STATUS _CHANGED _INTENT，并且Extension应用更新屏幕内容。
控制LED
配件上可能有一个或多个LED，可用于提醒用户有新的事件发生。Extension可以通过注册API和Capability API来获取配件上LED相关的信息。
如果配件上有LED，则Extension可以使用Control API来控制LED。使用CONTROL_ LED_ INTENT进行控制。 注意主应用可能在任何时候控制LED以提示用户。而Extension不知道这种情况，如果这时它尝试控制LED，则主应用会忽略它的请求。
控制振动器
配件上可能有振动器。使用注册API和Capability API来检查是有振动器。如果有，则可以使用CONTROL_ VIBRATE_ INTENT
按键事件
配件上可能有若干物理键。当按下物理键时Extension会接收到CONTROL_ KEY_ EVENT_ INTENT表示的按键事件。
该Intent包含几个参数，比如事件的时间戳，事件类型(按下，松开还是重复)，以及按键代码。每个按键有唯一的按键代码。
触摸事件
某些配件具有触屏。Extension通过注册API和Capability API获取相关信息。当用户触摸配件屏幕时Extension将收到CONTROL_ TOUCH_ EVENT_ INTENT
如果CONTROL_ DISPLAY_ DATA_ INTENT用于发送图片，那么触摸事件则有带有屏幕坐标信息的CONTROL_ TOUCH_ EVENT_ INTENT发送。如果有滑动手势，则会向Extension发送CONTROL_ SWIPE_ EVENT_ INTENT
如果CONTROL_ PROCESS_ LAYOUT_ INTENT用于发送布局，则布局中的某些View将处理触摸事件。触摸事件会被android:clickable设置为true的View处理。对于这些View，Extension会收到CONTROL_ OBJECT_ CLICK_ EVENT_ INTENT。而ListView将触摸事件处理为CONTROL_ LIST_ ITEM_ CLICK_ INTENT。未被布局中View处理的触摸事件和滑动事件会发送给Extension自己来处理。
在配件上显示内容
Extension不仅控制配件本身，还能控制屏幕上显示什么内容。用户可见的内容来自于Extension。基本上Extension是发送图片以显示在配件的屏幕上。为获取支持的屏幕大小和颜色深度，Extension需要使用注册API和Capability API。Extension通过发送CONTROL_ DISPLAY_ DATA_ INTENT更新屏幕内容。
Extension可以发送图片的原始数据或仅仅发送URI。注意，我们是使用蓝牙来传输数据所以无法达到较高的帧率。屏幕刷新率请见注册API和Capability API。
布局
Control API v2版本开始可以发送布局而不仅仅是图片了。由EXTRA_ DATA_ XML_ LAYOUT来指定布局(仅支持标准Android布局中的某些)。使用CONTROL_ PROCESS_ LAYOUT_ INTENT发送布局。而布局中View的内容则使用CONTROL_ SEND_ IMAGE_ INTENT和CONTROL_ SEND_ TEXT_ INTENT来更新。使用布局时，点击事件由CONTROL_ OBJECT_ CLICK_ EVENT_ INTENT发送。
列表
布局中可以包含列表。列表由CONTROL_ LIST_ COUNT_ INTENT初始化。这个Intent可以在EXTRA_ LIST_ CONTENT中包含列表数据。如果没有提供EXTRA_ LIST_ CONTENT，则主应用会要求必要时使用CONTROL_ LIST_ REQUEST_ ITEM_ INTENT来逐一请求列表项数据。Extension可以在任意时候发送一个CONTROL_ LIST_ COUNT_ INTENT来更新列表内容，如需要添加新的列表项或者已存在的列表项需要刷新。
ListView和其子元素必须占满屏幕的整个宽度。而列表项的高度小于或等于ListView的高度。
有些列表可以支持用户发起的更新。当用户发起更新时，会向Extension发送一个[CONTROL_ LIST_ REFRESH_ REQUEST_ INTENT][CONTROL_LIST_REFRESH_REQUEST_INTENT]。Extension需要检查数据源(比如向服务器拉数据)并更新列表内容。如果列表项数目发生变化，则会发送一个新的CONTROL_ LIST_ COUNT_ INTENT。如果只是内容发生变化，则会发送几个CONTROL_ LIST_ ITEM_ INTENT。
Gallery
与List非常类似。
总结
Control包含两个内部接口，分别是
1.Control.Intents
Intents sent between Control Extensions and Accessory Host Applications.
2.Control.KeyCodes
Interface used to define constants for keycodes (??? 不明白，为什么这个也要重新定义)
来源：oschina
链接：https://my.oschina.net/u/578279/blog/183076