CN101632300A - 用于多屏幕配置的多屏幕管理的方法和设备 - Google Patents

用于多屏幕配置的多屏幕管理的方法和设备 Download PDF

Info

Publication number
CN101632300A
CN101632300A CN200780051478A CN200780051478A CN101632300A CN 101632300 A CN101632300 A CN 101632300A CN 200780051478 A CN200780051478 A CN 200780051478A CN 200780051478 A CN200780051478 A CN 200780051478A CN 101632300 A CN101632300 A CN 101632300A
Authority
CN
China
Prior art keywords
screen
configuration
hscreen
ocap
org
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN200780051478A
Other languages
English (en)
Other versions
CN101632300B (zh
Inventor
李光基
李钟昊
边成昱
郑云教
格伦·A·亚当斯
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Samsung Electronics Co Ltd
Original Assignee
Samsung Electronics Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Samsung Electronics Co Ltd filed Critical Samsung Electronics Co Ltd
Publication of CN101632300A publication Critical patent/CN101632300A/zh
Application granted granted Critical
Publication of CN101632300B publication Critical patent/CN101632300B/zh
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N5/00—Details of television systems
    • H04N5/44—Receiver circuitry for the reception of television signals according to analogue transmission standards
    • H04N5/445—Receiver circuitry for the reception of television signals according to analogue transmission standards for displaying additional information
    • H04N5/45—Picture in picture, e.g. displaying simultaneously another television channel in a region of the screen
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/431—Generation of visual interfaces for content selection or interaction; Content or additional data rendering
    • H04N21/4312—Generation of visual interfaces for content selection or interaction; Content or additional data rendering involving specific graphical features, e.g. screen layout, special fonts or colors, blinking icons, highlights or animations
    • H04N21/4316—Generation of visual interfaces for content selection or interaction; Content or additional data rendering involving specific graphical features, e.g. screen layout, special fonts or colors, blinking icons, highlights or animations for displaying supplemental content in a region of the screen, e.g. an advertisement in a separate window
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/443—OS processes, e.g. booting an STB, implementing a Java virtual machine in an STB or power management in an STB
    • H04N21/4433—Implementing client middleware, e.g. Multimedia Home Platform [MHP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
    • H04N21/462—Content or additional data management, e.g. creating a master electronic program guide from data received from the Internet and a Head-end, controlling the complexity of a video stream by scaling the resolution or bit-rate based on the client capabilities
    • H04N21/4622—Retrieving content or additional data from different sources, e.g. from a broadcast channel and the Internet
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/436—Interfacing a local distribution network, e.g. communicating with another STB or one or more peripheral devices inside the home
    • H04N21/43615—Interfacing a Home Network, e.g. for connecting the client to a plurality of peripherals

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • Software Systems (AREA)
  • Business, Economics & Management (AREA)
  • Marketing (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Controls And Circuits For Display Device (AREA)
  • Studio Circuits (AREA)
  • User Interface Of Digital Computer (AREA)

Abstract

本发明的目的是为了使用多个屏幕和多种方法来执行多屏幕配置和多屏幕管理，以展示多个服务内容。根据本发明的一个实施例的多屏幕配置方法，通过互相分配一个或更多个广播服务、一个或更多个逻辑屏幕、一个或更多个显示屏幕以及一个或更多个输出端口，最终输出在由输出端口分配的屏幕上执行的服务内容，并设置、改变和报告多屏幕的配置，多屏幕的配置可以被设置或重置，以便使用想要的方法来有效地在多屏幕上输出各种服务内容。

Description

用于多屏幕配置的多屏幕管理的方法和设备
技术领域
本发明涉及用于配置在其上显示多个服务的屏幕的方法和设备，更具体而言，涉及用于配置最终输出屏幕的方法和设备，该最终输出屏幕包括多个在其上展示或显示多个服务的屏幕。
背景技术
总的来说，传统的广播接收系统，如数字电视(TV)或数字机顶盒，在单个的物理显示装置上仅提供一个内容元素或在单个的物理显示装置上同时显示主屏幕和子屏幕。但是，尽管传统的广播接收系统可以在相同的显示屏幕上同时显示主屏幕和子屏幕，它们只能以有限的方式安排主屏幕和子屏幕。而且，能够组合和显示来自如广播、数字通用盘(DVD)和连接到输入端的外部设备等各个源的服务的显示装置的种类是有限的。尽管所有的视频服务、音频服务和数据服务可以在主屏幕上显示时，不能在子屏幕上显示数据服务。
图1示出了由传统的画中画(PiP)方法形成的屏幕配置。传统的PiP方法在物理显示屏幕上显示主屏幕和子屏幕。参考标号100、110、120、130、140和150指示物理显示屏幕，且参考标号105、115、125、135、142、144、145、152和154指示子屏幕。特别地，由于子屏幕105、115、125、135、142、144、145、152和154的位置或尺寸被限制，灵活地实施传统的PiP方法存在限制。
在交互式TV应用程序环境中，如多媒体家庭平台(MHP)、应用配置访问协议(ACAP)和OpenCable应用平台(OCAP)，假设只输出一个屏幕。在交互式TV应用程序环境中，采用家庭音频/视觉交互(HAVi)用户界面。根据HAVi UI，尽管对物理显示装置上显示的屏幕的数量没有限制，通常只显示一个屏幕。而且，应用程序只共享显示的一个屏幕。
因此，传统的用于广播服务的应用程序环境在动态配置的屏幕上显示各种服务内容方面有限制。
附图说明
图1示出了由传统的PiP方法形成的屏幕配置。
图2示出了根据本发明的实施例的逻辑屏幕、显示屏幕和显示映射器之间的关系。
图3是根据本发明的实施例的能够实施多屏幕管理器的数字电视(TV)系统的框图。
图4示出了在根据本发明的实施例的数字TV系统中展示的多个内容。
图5A和5B分别示出了根据本发明的实施例的非抽象服务和抽象服务。
图6示出了屏幕上下文和各种方法之间的关系。
图7A和7B示出了根据逻辑屏幕的z-顺序在显示屏幕上的结果。
图8A和8B示出了服务内容、逻辑屏幕和显示屏幕之间的联系。
图9A和9B示出了根据逻辑屏幕所映射到的显示区域的显示屏幕上的结果。
图10示出了多个服务、多个逻辑屏幕和显示屏幕之间的联系。
图11A示出了根据本发明的实施例、在‘org.ocap.ui.MultiScreenConfigurableContext’中的Java常量的注册。
图11B示出了根据本发明的实施例、在‘org.ocap.ui.MultiScreenConfiguration’中的Java常量的注册。
图11C示出了根据本发明的实施例，在‘org.ocap.ui.MultiScreenContext’中的Java常量的注册。
图11D示出了根据本发明的实施例、在‘org.ocap.ui.event.MultiScreenConfigurationEvent’中的Java常量的注册。
图11E示出了根据本发明的实施例、在‘org.ocap.ui.MultiScreenContextEvent’中的Java常量的注册。
图11F示出了根据本发明的实施例、在‘org.ocap.ui.MultiScreenEvent’中的Java常量的注册。
图11G示出了根据本发明的实施例、在‘org.ocap.ui.MultiScreenResouceEvent’中的Java常量的注册。
图12示出了根据本发明的实施例的Java包‘org.ocap.ui’的接口和类。
图13A示出了根据本发明的实施例的‘org.ocap.ui’包的‘MultiScreenConfigurableContext’接口的定义。
图13B示出了根据本发明的实施例的org.ocap.ui’包的‘MultiScreenConfigurableContext’接口的字段。
图13C示出了‘CONFIGURABLE_SCREEN_PAMAMETER_DEVICE_Z_ORDER’字段的使用例子。
图13D到13F示出了根据本发明的实施例的‘org.ocap.ui’包的‘MultiScreenConfigurableContext’接口的方法。
图14A示出了根据本发明的实施例的‘org.cap.ui’包的‘MultiScreenConfiguration’接口的定义。
图14B示出了根据本发明的实施例的‘org.ocap.ui’包的‘MultiScreenConfiguration’接口的字段。
图14C示出了根据本发明的实施例的‘org.ocap.ui’包的‘MultiScreenConfiguration’接口的方法。
图15A示出了根据本发明的实施例的‘org.ocap.ui’包的‘MultiScreenContext’接口的定义。
图15B示出了根据本发明的实施例的‘org.ocap.ui’包的‘MultiScreenContext’接口的字段。
图15C和15D示出了根据本发明的实施例的‘org.ocap.ui’包的‘MultiScreenContext’接口的方法。
图16A示出了根据本发明的实施例的‘org.ocap.ui’包的‘MultiScreenManager’类的定义。
图16B示出了根据本发明的实施例的‘org.ocap.ui’包的‘MultiScreenManager’类的构造函数。
图16C到16F示出了根据本发明的实施例的‘org.ocap.ui’包的‘MultiScreenManager’类的方法。
图17示出了根据本发明的实施例的Java包‘org.ocap.ui.event’的接口和类。
图18A示出了根据本发明的实施例的‘org.ocap.ui.event’包的‘MultiScreenConfigurationEvent’类的定义。
图18B示出了根据本发明的实施例的‘org.ocap.ui.event’包的‘MultiScreenConfigurationEvent’类的字段。
图18C示出了根据本发明的实施例的‘org.ocap.ui.event’包的‘MultiScreenConfigurationEvent’类的构造函数。
图18D示出了根据本发明的实施例的‘org.ocap.ui.event’包的‘MultiScreenConfigurationEvent’类的方法。
图19A示出了根据本发明的实施例的‘org.ocap.ui.event’包的‘MultiScreenConfigurationListener’接口的定义。
图19B示出了根据本发明的实施例的‘org.ocap.ui.event’包的‘MultiScreenConfigurationListener’接口的方法。
图20A示出了根据本发明的实施例的‘org.ocap.ui.event’包的‘MultiScreenContextEvent’类的定义。
图20B示出了根据本发明的实施例的‘org.ocap.ui.event’包的‘MultiScreenContextEvent’类的字段。
图20C示出了根据本发明的实施例的‘org.ocap.ui.event’包的‘MultiScreenContextEvent’类的构造函数。
图20D示出了根据本发明的实施例的‘org.ocap.ui.event’包的‘MultiScreenContextEvent’类的方法。
图21A示出了根据本发明的实施例的‘org.ocap.ui.event’包的‘MultiScreenContextListener’接口的定义。
图21B示出了根据本发明的实施例的‘org.ocap.ui.event’包的‘MultiScreenContextListener’接口的方法。
图22A示出了根据本发明的实施例的‘org.ocap.ui.event’包的‘MultiScreenEvent’类的定义。
图22B示出了根据本发明的实施例的‘org.ocap.ui.event’包的‘MultiScreenEvent’类的字段。
图22C示出了根据本发明的实施例的‘org.ocap.ui.event’包的‘MultiScreenEvent’类的构造函数。
图22D示出了根据本发明的实施例的‘org.ocap.ui.event’包的‘MultiScreenResourceEvent’类的方法。
图23A示出了根据本发明的实施例的‘org.ocap.ui.event’包的‘MultiScreenResourceEvent’类的定义。
图23B示出了根据本发明的实施例的‘org.ocap.ui.event’包的‘MultiScreenResourceEvent’类的字段。
图23C示出了根据本发明的实施例的‘org.ocap.ui.event’包的‘MultiScreenResourceEvent’类的构造函数。
图23D示出了根据本发明的实施例的‘org.ocap.ui.event’包的‘MultiScreenResourceEvent’类的方法。
图24A到24C示出了根据本发明的实施例的改变多屏幕配置的事先条件。
图24D示出了根据本发明的实施例的改变多屏幕配置的过程。
图25A到25E示出了根据本发明的实施例的改变多屏幕配置的事后条件。
图26A到26D示出了根据本发明的实施例的验证不变量的限制。
图27示出了根据本发明的实施例的‘getNonDefaultScreens()’方法的定义。
图28A和28B示出了根据本发明的实施例的‘getNonDefaultScreenDevices()’方法的定义。
图29示出了根据本发明的实施例的多个方法。
图30A示出了根据开放有线应用平台(OCAP)标准的‘AppID’Java类型的伪代码。
图30B示出了根据本发明的实施例的用于实现OCAP MSM的‘OcapAppID’Java类型的伪代码。
图31示出了根据本发明的实施例的用于支持‘OcapAppID’Java类型的伪代码。
图32A示出了根据OCAP标准的‘HSceneBinding’Java类型的伪代码。
图32B示出了根据本发明的实施例的用于实现OCAP MSM的‘HSceneBinding’Java类型的伪代码。
图33A示出了根据OCAP标准的‘HSceneChangeRequestHandler’Java类型的伪代码。
图33B示出了根据本发明的实施例的用于实现OCAP MSM的‘HSceneChangeRequestHandler’Java类型的伪代码。
图34A示出了根据OCAP标准的‘HSceneManager’Java类型的伪代码。
图34B和34C示出了根据本发明的实施例的用于实现OCAP MSM的‘HSceneManager’Java类型的伪代码。
发明内容
本发明提供了一种用于配置和管理多屏幕的方法和设备，在该多屏幕上多个服务内容可以以期望的位置和期望的尺寸被同时显示。
本发明还提供了接口，其允许支持多屏幕的装置对资源的有效使用，以及用于多屏幕功能性管理的可共同操作的应用。本发明还提供标准接口，用于管理多屏幕功能性和多屏幕状态，如画中画(PiP)或画外画(PoP)屏幕。
根据本发明的用于管理多屏幕的方法和设备，动态地控制资源的使用和用于每个屏幕的应用程序的生命周期，以便在多个独立的逻辑屏幕上展示服务内容。
有益效果
由于一个或更多个服务内容按照多对多方式、而非一对一的方式对应于一个或更多个屏幕，根据本发明的用于配置和管理多屏幕的方法和设备可以动态地配置和输出最终屏幕。而且，由于各种资源管理接口，多屏幕管理功能性允许支持多屏幕的主机装置对资源的有效使用。
根据本发明的实施例的开放有线(OpenCable)应用平台(OCAP)多屏幕管理(MSM)扩展是OCAP特性(profile)的扩展，其包括所有所需的应用程序接口(API)、内容和数据格式以及协议、直到应用层。被开发为OCAPMSM扩展的应用程序可以在OpenCable-compliant Host装置上被执行。该Open MSM扩展允许有线操作者部署能共同使用的应用程序以管理连接到其网络的OpenCable-compliant Host装置上的多屏幕功能。(OCAP)特性允许有线操作者具有用于管理多屏幕功能及其状态的标准接口，如跨越多个主机装置供货商的画中画(PiP)和画外画(PoP)屏幕。
OCAP MSM扩展可以用于多种类型的硬件和操作系统，以便允许消费电子(CE)厂商在实施中的灵活性。定义OCAP MSM扩展的主要目标是使CE厂商能够竞争实施，而同时保持一致和可共同操作的编程接口，以便被有线操作者定义的应用程序以及希望意识到多屏幕功能性的独立于有线网络的应用程序所使用。
最佳模式
根据本发明的一个方面，提供了一种配置和管理多屏幕的方法，该方法包括：接收一个或更多个广播服务；将该一个或更多个广播服务分配给一个屏幕；将该屏幕分配给一个或更多个显示屏幕；以及将该一个或更多个显示屏幕分配给一个或更多个输出端口。
该方法还可以包括将用于逻辑屏幕的服务内容与用于一个或更多个显示屏幕的上下文关联，并改变上下文之间的关联。
该方法还可以包括确定包括逻辑屏幕、一个或更多个显示屏幕、用于服务的上下文和关于一个或更多个输出端口的信息的多屏幕配置，并且改变该多屏幕配置。
该方法还可以包括观察用于改变多屏幕配置的事先条件和事后条件。
该方法还可以包括报告多屏幕配置和上下文的改变。
发明模式
现在将参考附图更全面地描述本发明，附图中示出了本发明的示例性实施例。
将参考图2到图34C解释本发明的多屏幕管理。
将参考图2到图10解释在本发明中所介绍的多屏幕系统和多屏幕管理。
将参考图11A到29解释根据本发明的实施例的各种Java类型的定义和功能。
将参考图30A到34C解释对现有的开放有线应用平台(OCAP)标准的修改或添加以在OCAP环境中实施本发明的实施例。
为了更好地理解本发明，现在将定义各种简写和术语。
“HAVi”是家庭音频视觉接口的缩写。“MSM”是多屏幕管理器的缩写。“PiP”是画中画的缩写。“PoP”是画外画的缩写。“AIT”是应用程序信息表的缩写。“XAIT”是扩展应用程序信息表的缩写。
“音频焦点屏幕”是一个屏幕，其音频源被选择以用于与任意被使能的视频输出端口关联的任意音频展示装置，该屏幕与所述视频输出端口直接(如果它是显示屏幕)或间接关联(如果它是映射的逻辑屏幕)。
“显示映射器”是将逻辑屏幕的标准化坐标空间合成为显示屏幕(或其某部分)的标准化坐标空间的逻辑处理。
“显示多屏幕配置”是仅组成显示屏幕的多屏幕配置。每个每平台多屏幕配置是显示多屏幕配置。显示多屏幕配置的配置类型是SCREEN_CONFIGURATGION_DISPALY，这将在稍后解释。
“显示屏幕”是一种对物理显示装置的最终输出组成进行建模的屏幕。显示屏幕与一个或更多个视频输出端口关联，这些端口本身要么(1)被附着到内部的集成显示器要么(2)被附着到通过一些被很好定义的接口，例如，高清多媒体接口(HDMI)或电气和电子工程师协会(IEEE)1394，连接到外部显示装置的物理输出端口。
“普通屏幕”是被分配了普通屏幕类型的逻辑屏幕，这将在稍后解释。普通屏幕通常典型地能被重新配置，使得其可以服务不同的应用情形。例如，其有时可以被配置为PiP屏幕，但在另外的时候被配置为PoP屏幕。
“逻辑屏幕”是不与物理显示装置直接关联、但可以通过显示映射器被映射到显示屏幕的一类屏幕。逻辑屏幕可以被映射或不被映射。如果被映射，它与显示屏幕关联；如果不被映射，它不与显示屏幕关联。在例外的情况下，逻辑屏幕可以与视频输出端口直接关联，在这种情况下，它可以同时被用作逻辑屏幕和准显示屏幕。
“主屏幕”是被分配了主屏幕分类的显示屏幕或逻辑屏幕，这将在稍后解释。主屏幕总是与显示装置的全屏范围共同扩展(除非被没有MSM知识的显示装置本身进一步映射)。
“多屏幕可配置上下文”是多屏幕上下文的扩展，其提供了配置(变更)涉及多屏幕管理功能的状态信息的能力。多屏幕配置上下文由以下在本发明的实施例中使用的‘MultiScreenConfigurableContext’接口所定义，且说明中的‘MultiScreenConfigurableContext’接口是展示多屏幕可配置上下文的Java类型。
“多屏幕配置”是正在展示或能够展示内容的可识别的屏幕集合，该集合可以(但不必须)是在指定的平台实施上或指定的显示屏幕上所有可访问的屏幕的合适的子集。在任意指定的时间，单个多屏幕配置应用到(1)整个平台，在这种情况下，配置中的屏幕是显示屏幕，以及(2)每个显示屏幕，在这种情况下，配置中的屏幕要么是显示屏幕本身要么是一组被映射到显示屏幕的逻辑屏幕。指定的基本屏幕可以在指定的时间在多个多屏幕配置中展示。
多屏幕配置可以由以下在本发明的实施例中使用的‘MultiScreenConfiguration’接口来定义，且该‘MultiScreenConfiguration’接口是展示多屏幕配置的Java类型。
“多屏幕配置类型”是多屏幕配置的特点，其主要基于其组成屏幕的种类。多屏幕配置类型的集合被进一步分为(1)单例显示多屏幕配置类型，已知为显示多屏幕配置，以及(2)所有其它的多屏幕配置类型，已知为非显示多屏幕配置。
“多屏幕上下文”是一组状态信息，其在HAVi屏幕上扩展，以便允许在实施多个屏幕的平台中的协同工作。基线多屏幕上下文提供功能以发现(但不是改变)该状态信息。
多屏幕上下文由以下在本发明的实施例中使用的‘MultiScreenContext’接口定义，且说明书中的‘MultiScreenContext’接口代表多屏幕上下文。
“多屏幕管理器”是由平台实施提供的单例管理组件，其通过在本说明中定义的属性而使得多个屏幕被有效使用。多屏幕管理器也被称为多个屏幕管理器。
多屏幕管理器由以下在本发明的实施例中使用的‘MultiScreenManager’类定义，且‘MultiScreenManager’类是代表多屏幕管理器的Java类型。
“覆盖屏幕”是被分配到覆盖屏幕类型的逻辑屏幕，这将在稍后解释。覆盖屏幕的z-顺序将相应的覆盖屏幕放置在比所有其它的非覆盖屏幕更前面。
“每显示屏幕配置”是非显示多屏幕配置，其定义或可以用来定义与指定的显示屏幕关联的活动的或可能活动的屏幕集合。在当前活动的每平台多屏幕配置中的每个基本显示屏幕包括可定义其活动每显示多屏幕配置的状态变量。
“每平台多屏幕配置”是显示多屏幕配置，其当前定义或可以用来定义活动的或可能活动的显示屏幕集合。当前活动的每平台多屏幕配置是多屏幕管理器单例实例的状态变量。
“PiP屏幕”是被分配了PiP屏幕类型的逻辑屏幕。PiP屏幕典型地与主屏幕交叉，且比主屏幕显得更靠前(在z-顺序中)。
“PoP屏幕”是被分配了PoP屏幕类型的逻辑屏幕。PoP屏幕典型地沿着一个或更多个其它的PoP屏幕平铺，以便填充显示屏幕的范围。
“屏幕”是一组(逻辑的或可能是物理的)资源，其使背景颜色、背景图像、视频和图形的一些组合能展示。背景颜色、背景图像、视频和图形通过由HAVI提供的HScreenDevice来显示。背景颜色和背景图像可以用HBackgroundDevice显示，视频可以用HVideoDevice显示，且图形可以通过用HGraphicsDevice显示。屏幕可以包括一个HBackgroundDevice、一个HVideoDevice和一个HGraphicsDevice。屏幕被分类为显示屏幕或逻辑屏幕。
“默认屏幕”是多个屏幕中最容易被访问的屏幕。“默认屏幕装置”是多个屏幕装置中最容易被访问的屏幕装置。默认屏幕装置可以是HBackgroundDevice、HVideoDevice和HGraphicsDevice中的一个。
“屏幕分类”是根据其使用或配置特性的屏幕分组。
“屏幕标志符”是基本屏幕及其各个资源的屏幕唯一标记，其允许不同分类的屏幕之间或单个分类中屏幕之间的区分。
“屏幕类型”是将屏幕分为两种类型的最高等级：显示屏幕和逻辑屏幕。
“服务”是包括多个服务组件的多媒体内容。
“服务组件”是包括视频组件、音频组件和数据组件的服务成分。数据组件包括在平台上执行的用于服务和应用的各种信息。
“服务上下文”是包括关于将被执行的服务的资源、装置、状态信息等的对象。
OCAP MSM扩展定义了功能和行为的集合，以允许支持这些属性的平台实施上的多个显示器和多个逻辑屏幕的有效使用。
“多屏幕配置监听器”被用来提供关于下列改变的通知：系统和应用程序所引起的MultiScreenManager实例的全局状态或针对每平台或一些每显示多屏幕配置的改变，或者特定MultiScreenConfiguration实例的改变。多屏幕配置监听器由以下本发明的实施例的‘MultiScreenConfigurationListener’接口定义，说明书中的‘MultiScreenConfigurationListener’接口是代表多屏幕配置监听器的Java类型。
“多屏幕上下文监听器”被用来提供关于系统或应用程序引发的对MultiScreenContext的改变的通知。MultiScreenContext由以下本发明的实施例的‘MultiScreenContextListener’接口定义。说明书中的‘MultiScreenContextListener’接口是代表多屏幕上下文监听器的Java类型。
“多屏幕配置事件”被用来报告多屏幕管理器实例的全局状态或针对每平台或某些每显示多屏幕配置的某些显示HScreen的状态的改变，或者是特定MultiScreenConfiguration实例的变化。多屏幕配置事件是由以下本发明的实施例的‘MultiScreenConfigurationEvent’接口定义的。说明中的‘MultiScreenConfigurationEvent’接口是代表多屏幕配置事件的Java类型。
“多屏幕上下文事件”被用来向感兴趣的监听器报告对MultiScreenContext的改变。多屏幕上下文事件是由以下本发明的实施例的‘MultiScreenContextEvent’接口定义的。在说明书中‘MultiScreenContextEvent’是表示多屏幕上下文事件的Java类型。
“多屏幕事件”用于组织事件标识码的抽象的基类，该标识码是由涉及多个屏幕管理功能的不同类型的事件使用的。多屏幕事件由以下本发明的实施例的‘MultiScreenEvent’接口定义。说明书中的‘MultiScreenEvent’接口是代表多屏幕事件的Java类型。
多屏幕资源事件被用来报告关于涉及资源的多屏幕的资源状态的改变。多屏幕资源事件是由本发明的实施例的‘MultiScreenResourceEvent’接口定义的，这将在稍后解释。说明书中的‘MultiScreenResourceEvent’接口是代表多屏幕资源事件的Java类型。
特定平台实施支持这种扩展的程度是由平台和装置制造商或这种扩展的其它外部特性决定的，且典型地是由硬件的类型和可配置性决定的，包括可用调谐器或独立的输入源的数量、可用的视频解码管线的数量、集成显示器的数量、独立的视频(和音频)输出端口的数量、可用于视频和图形缓冲的存储器的数量和其它非特定的资源。
将参考图2到图10解释本发明中所提出的多屏幕系统和多屏幕管理。
图2示出了根据本发明实施例的逻辑屏幕、显示屏幕和显示映射器之间的关系。
多屏幕管理上的屏幕包括逻辑屏幕集合210和显示屏幕集合230。逻辑屏幕集合210通过显示映射器220与显示屏幕集合230关联。显示映射器220是将逻辑屏幕的标准化坐标空间合成为显示屏幕的标准化坐标空间的逻辑处理。即，通过显示映射器220，一个或更多个逻辑屏幕可以在显示屏幕期望的位置上被显示。
例如，根据本发明的实施例的多屏幕管理系统包括显示映射器220、多个逻辑屏幕212、214和216，以及多个显示屏幕240、250和260。逻辑屏幕212、214和216的至少一个通过显示映射器220在每个显示屏幕240、250和260上被显示。
即，由于显示映射器220，屏幕区域242和244可以在显示屏幕240内被并行排列。逻辑屏幕212被缩小并放置在屏幕区域242中，逻辑屏幕214也被缩放和放置在屏幕区域244中。同样地，逻辑屏幕214被放置在显示屏幕250中最后面的屏幕区域252。逻辑屏幕214被放置在显示屏幕250的屏幕区域254。逻辑屏幕212被放置在显示屏幕260的最后面的屏幕区域262。逻辑屏幕214被缩小并放置在显示屏幕260的屏幕区域264。逻辑屏幕216被缩小并放置在显示屏幕260的屏幕区域266中。
图3是数字电视(TV)系统300的框图，其中多屏幕管理器可以根据本发明的实施例而被实施。
数字电视系统300包括广播信号接收单元310、数字信号处理单元320、多媒体服务处理单元330、输出单元340和显示单元350。
广播信号接收单元310接收有线广播信号。作为替换，广播信号接收单元310可以接收地面广播信号或卫星广播信号。
数字信号处理单元320通过使用由广播信号接收单元310接收的服务组件重新配置服务。
多媒体信号处理单元330生成用于展示由数字信号处理单元320重新配置的服务的逻辑屏幕，并将所产生的逻辑屏幕输出到输出单元340。
输出单元340生成显示屏幕，并将该显示屏幕映射到逻辑屏幕。即，逻辑屏幕与显示屏幕关联，使得逻辑屏幕的服务与显示屏幕关联。尽管在图3中，服务与逻辑屏幕关联然后与显示屏幕关联，本发明不限于此，且服务可以直接与显示屏幕关联。
当输出单元340包括一个或更多个输出端口时，输出端口可以与显示屏幕关联。
为了使数字TV系统300执行多屏幕管理功能，逻辑屏幕、显示屏幕和输出端口之间的联系可以在多媒体信号单元330和输出单元340中被确定。当平台被实施时，多个屏幕可以被生成，且多屏幕管理功能的实施，即多屏幕配置、管理和改变，提供了用于MSM的应用程序接口(API)，这将在稍后解释。
显示单元350包括物理显示屏幕装置，在其上显示显示屏幕。
图4示出了根据本发明的实施例在数字TV系统400中展示的多个内容。
数字TV系统400可以同时展示地面广播内容410、有线广播内容420和个人视频记录器(PVR)数据内容430。即，如果本发明的多屏幕管理可以在数字TV/机顶盒(DTV/STB)模块中被实施，地面广播内容410、有线广播内容420和PRV数据内容430可以分别与逻辑屏幕关联，且每个逻辑屏幕在显示屏幕450上显示。
由于本发明的多屏幕管理定义了一个或更多个逻辑屏幕和一个或更多个显示屏幕之间的关联，一个或更多个逻辑屏幕可以被映射到一个显示屏幕。即，地面广播内容410的逻辑屏幕452被放置在显示屏幕450的屏幕区域452，且有线广播内容420的逻辑屏幕456被放置在显示屏幕450的屏幕区域456。而且，由于DTV/STB模块，PVR内容430的逻辑屏幕454被放置在显示屏幕450的屏幕区域454。
即，逻辑屏幕452、454和466可以被缩小并以预定顺序放置在显示屏幕450的各个位置。
图5A和5B分别示出了根据本发明的实施例的非抽象服务和抽象服务。
在图5A中，服务组510是非抽象服务组。在图5B中，服务组550是抽象服务组。非抽象服务组510包括视频服务520、音频服务530和应用服务540。相反，抽象服务组550包括视频应用560和音频应用570。即，抽象服务组550是仅包括应用服务的服务组，而没有任何视频服务或音频服务，而非抽象服务组510是包括其它服务以及应用服务的服务组。
图6示出了屏幕上下文600和各种方法之间的关系。
参考图6，屏幕上下文600包括z-顺序610、显示区域620、可见性630、关联的显示屏幕640和关联的服务上下文650。
z-顺序610是指用于确定多个逻辑屏幕以什么顺序在显示屏幕上显示的信息。
显示区域620是一个区域，其中逻辑屏幕的标准化屏幕坐标空间被映射到显示屏幕的标准化屏幕坐标空间。
可见性630确定逻辑屏幕是否被可见地或不可见地在显示屏幕上显示。
关联的显示屏幕640是逻辑屏幕与之关联的显示屏幕。关联的服务上下文650是连接到逻辑屏幕或显示屏幕的服务上下文。
屏幕上下文600可以通过‘set/add’方法来设置或添加属性并且通过‘get/remove’方法来获取或移除属性。即，屏幕上下文600可以通过使用‘set/add’和‘get/remove’方法来设置或改变属性。
尽管没有在图6中示出，屏幕上下文600可以不仅仅包括z-顺序、显示区域、可见性、关联的显示屏幕和关联的服务上下文，也可以包括与当前屏幕关联的音频、与当前屏幕关联的音频源、与当前屏幕关联的屏幕装置的z-顺序、与当前屏幕关联的显示区域和与当前屏幕关联的视频输出端口中的至少一个。
图7A和7B示出了根据逻辑屏幕的z-顺序的显示屏幕上的结果。
随着相应元素的z-顺序的增加，相应元素被放置在较高(更靠前)的位置。参考图7A，当放置在显示屏幕700的逻辑屏幕1a 710和逻辑屏幕2a 720的z-顺序分别为1和2时，逻辑屏幕2a 720高于(比)逻辑屏幕1a 710(更靠前)。
类似地，参考图7B，当放置在显示屏幕750的逻辑屏幕1b 760和逻辑屏幕2b 770的z-顺序分别为2和1时，逻辑屏幕1b 760高于(比)逻辑屏幕2b 770(更靠前)。
z-顺序的概念和顺序被应用到屏幕装置以及逻辑屏幕。
图8A和8B示出了服务上下文、逻辑屏幕和显示屏幕之间的关联。
当包括视频内容812、音频内容814和应用上下文816的服务810被接收时，直接/间接地将服务与显示屏幕关联的方法将被解释。
参考图8A，当服务810与空的逻辑屏幕820关联，而与服务810关联的逻辑屏幕830与显示屏幕840关联时，服务810在显示屏幕840上显示850。即，显示屏幕840和服务810通过逻辑屏幕820和830间接地彼此关联。
参考图8B，当服务810与空的显示屏幕840关联时，服务810在显示屏幕840上显示860。即，显示屏幕840和服务810间接地彼此关联。
因此，由于服务810与显示屏幕840直接/间接地关联，服务810可以在显示屏幕840上被显示，且当最终与输出端口关联时，可以被输出。
图9A和9B示出了根据逻辑屏幕所映射到的显示区域的显示屏幕上的结果。
参考图9A，当逻辑屏幕910通过显示映射器220被映射到显示区域920的全部区域930时，逻辑屏幕910在显示屏幕920的整体区域930上被显示940。
相反的，参考图9B，当逻辑屏幕910通过显示映射器220被映射到显示屏幕920的区域950时，逻辑屏幕910在显示屏幕920的区域950被显示960。
即，与传统的PiP方法不同，显示在整体屏幕的一部分上的内容屏幕可以被缩放。
图10示出了多个服务、多个逻辑屏幕和显示屏幕之间的关联。
根据本发明的实施例的多屏幕管理设备可以同时将与第一服务1010关联的第一逻辑屏幕屏幕1030和与第二服务1020关联的第二逻辑屏幕1040映射到显示屏幕1050。当第一和第二逻辑屏幕1030和1040所映射到的显示屏幕1050与输出端口1060关联时，最终输出接口1070可以在显示单元上被展示。
即，多屏幕管理设备可以包括多个服务、多个逻辑屏幕、多个显示屏幕和多个输出端口。因此，多屏幕管理设备可以通过多个输出端口来展示多个服务和多个屏幕。
不仅参考图2到图10所描述的多屏幕配置，还有根据本发明的实施例的多屏幕管理方法和设备，定义了用于多屏幕状态配置、改变和管理的操作。即，多屏幕管理方法和设备具有如下各种能力：获取、改变、设置和发现逻辑屏幕和显示屏幕之间的映射关系，屏幕装置、服务上下文、显示屏幕、视频输出端口、音频焦点分配、每显示多屏幕配置、每平台多屏幕配置之间的关联；保留资源以及释放资源保留；以及监控并通知各种变化，以及用于各种变化的各种事前条件和事后条件的各种能力，因此可以执行顺利的多屏幕配置和多屏幕管理。用于多屏幕配置和多屏幕管理的各种能力稍后将解释。
现在将解释根据本发明的实施例、应用到OCAP系统的多屏幕管理方法和设备。
本发明定义了用于支持如本说明书所定义的多屏幕管理功能的OCAP主机装置的OCAP特性的模块扩展。多屏幕管理功能被定义为标准化软件接口，允许共同操作的OCAP应用程序，以便有效地使用支持多个屏幕的主机装置的资源。
OCAP MSM扩展是包括OCAP特性的扩展，其包括所有所需的API、内容和数据格式和协议、直到应用层。被开发为OCAP MSM扩展的应用程序将用OpenCable-compliant主机装置执行。OCAP MSM扩展允许有线操作者部署可共同操作的应用以便在与其网络连接的OpenCable-compliant主机装置上管理多个屏幕功能。
(OCAP)特性允许有线操作者具有用于管理多屏幕功能及其状态的标准化接口，如跨越多个主机装置供货商的PiP和PoP屏幕。
OCAP MSM扩展可被应用到各种各样的硬件和操作系统以允许消费电子(CE)厂商在实施中的灵活性。定义OCAP MSM扩展的主要目标是使CE厂商能够竞争实施，而同时保持一致和可共同操作的编程接口，以便被有线操作者定义的应用程序以及希望意识到多屏幕功能性的独立于有线网络的应用程序所使用。
多屏幕管理方法和设备是对现有的OCAP标准的扩展。OCAP MSM扩展采用信令机制(描述符)、API、平台行为(语义)和应用使用限制等形式。
在本实施例中，由说明书定义的API采用扩展到现有功能的形式，且API是由org.havi.ui所定义的HAVi用户接口定义的。特别地，这里定义的许多功能采用了由平台所使用的具体类实现的接口的形式，以便支持org.havi.ui.HScreen类。
HScreen实例是以下的一个屏幕。在英语中，Java类型或参数在引号(“)中被引用。Java类是用于相同类型对象的各种参数和方法的集合，而Java接口指定了在类中能共同操作的对象的能力。根据本发明的实施例可以通过由每个类定义的方法来管理和配置多屏幕以及改变配置。一个实例是从类生成的对象。
多屏幕管理的实施例中的各种方法、各种字段和各种Java类型将在图11A到23D中定义。
OCAP MSM扩展定义了用于Xlet应用的单个MSM相关行为的可选描述符。在缺少这样的描述符的情况下，定义了默认的语义。
如下所定义的，OCAP MSM扩展通过多个屏幕使用描述符扩展了OCAP特性。在AIT或在XAIT中用信号通知的OCAP应用程序可以在应用到应用程序的应用程序描述符环中包括一个但不超过一个多屏幕使用描述符。
如果在某些应用程序的应用程序描述符环中没有多屏幕使用描述符，则OCAP主机装置可以考虑其等同于多个屏幕使用描述符的存在，其terminate_on_condition标记被清“0”，其disallow_partial_display_graphics_mapping标记被清“0”，且其allow_default_device_reconfig标记被清“0”。
以上所产生的效果是，默认地，(1)通过中间逻辑屏幕的方式，应用程序默认图像平面可以(与其默认背景和视频平面一起)被缩放到显示屏幕的一部分，(2)应用程序默认屏幕装置不能被任意重新配置或解除资源(unresourced)，以及(3)如果该最后条件必须保持，则应用程序被挂起，或者，如果不可能挂起的话，则终止。在说明书中，当应用程序暂时停止进程而持续使用资源使时，使用术语‘挂起’。并且，当应用程序解除资源并且完全地结束处理时，使用术语“终止”。
多屏幕使用描述符包括descriptor_tag、descriptor_length、terminate_on_condition、disallow_partial_display_graphics_mapping、allow_default_device_reconfig及reserved。
Descriptor_tag是具有0x6E值的8比特无符号整数，其标识该多屏幕使用描述符。
Descriptor_length是8比特无符号整数，其规定了紧接该字段之后的字节数量。对于本说明书来说，确切地说只有一字节应该跟在descriptor_length字段之后。
Terminate_on_condition是1比特的标记，表示在‘disallow_partial_display_graphics_mapping’被设为1或者‘allow_default_device_reconfig’被清‘0’的情况下，该应用生命周期期望的效果，且由该两个单独的标记所指定的条件要求应用挂起或终止。
如果该标记被设为‘1’，则OCAP平台应该在支配(governing)条件开始时终止(销毁)应用程序；否则，如果该标记被清‘0’，则OCAP平台应该试图挂起该应用，并且，如果不能挂起，应该在支配条件开始时终止应用程序。
如果作为该标记为false的结果应用程序被挂起，则当没有获取支配条件时，应用程序应该被恢复，但当不可能恢复时，例如，由于资源可用性不足，应用程序应当被终止(销毁)。
在当前的上下文中，术语‘挂起’将被解释为等同于调用受影响的应用程序初始Xlet实例的‘pauseXlet()’方法。
Disallow_partial_display_graphcis_mapping是1比特的标记，其指示当多屏幕配置改变或服务上下文在屏幕间交换或移动时，应用程序不能继续运行，使得应用程序默认图形平面(屏幕装置)可以被缩放以在逻辑屏幕中操作，其屏幕区域没有被映射到整个显示屏幕范围。
如果disallow_partial_display_graphcis_mapping被设为‘1’，则根据以上‘terminate_on_condition’标记的值，应用应该在该条件开始时被挂起或终止；否则，如果disallow_partial_display_graphcis_mapping被清‘0’，则应用程序在该条件开始时不被挂起或终止。
Allow_default_device_reconfig是1比特的标记，其指示当多屏幕配置改变或服务上下文在屏幕间交换或移动时，应用程序可以继续运行，使得(1)一些默认屏幕装置的一个或多个以下屏幕装置配置(HScreenConfiguration)参数将会改变：屏幕区域、像素分辨率或者像素纵横比；或者(2)在配置改变或服务上下文交换/移动之前的一个或多个默认屏幕装置的基本资源在配置改变或服务上下文交换/移动后不再可用。
如果‘Allow_default_device_reconfig’被清‘0’，则根据以上‘terminate_on_conidtion’标记，应用程序在该条件开始时应该被挂起或终止；否则，如果‘Allow_defaul_device_reconfig’被设为1，则应用程序在该条件开始时不被挂起或终止。
发出设为‘1’状态的‘allow_default_device_config’标记的信号的应用程序，被期望来注册用于并处理org.havi.ui.HScreenConfigurationEvent和org.ocap.ui.MultiScreenEvent的Java类型两者的监听器
Reserved是为未来的标准化所保留的字段，并且应具有所有‘1’组成的值。
现在将解释用于OCAP MSM扩展的应用程序接口。
现在将结合Java类型来解释本发明的实施例。但是，该实施例不限于Java类型，并且本领域普通技术人员理解可以使用各种方法来达到本发明的目的和效果。
OCAP MSM扩展定义了功能和行为的集合以便允许在支持这些属性的平台实施上的多个显示器和多个逻辑屏幕的有效使用。MSM扩展通过以下规定的多屏幕管理功能扩展了OCAP特性。
支持OACP MSM扩展的OCAP主机装置应当实现由以下小节所指定的语法。
现在将解释MSM。
用于OCAP应用程序的默认HScreen屏幕是表示默认基本屏幕装置的当前活动集合及其当前活动的HAVi屏幕配置的HScreen实例。
关于应用程序的默认HScreen的进一步信息将在默认HScreen分配和‘MultiScreenManager.getDefaultHScreen()’方法中描述。
实现MultiScreenManager类的OCAP主机装置将提供用于每个次级和初级观看屏幕的区别的逻辑HScreen实例，该观看屏幕被暴露给OCAP实施，即，PiP和非PiP观看屏幕两者。
现在将解释屏幕。
HAVi用户接口子系统(称为基线HAVi模式)将‘HScreen类’定义为‘装置的最终输出组成’的描述，并指示‘具有两个独立显示器的平台将支持该类的两个实例’。根据MSM扩展的介绍，该定义被扩展以便引入显示屏幕和逻辑屏幕之间的区别。
首先，现在将解释从‘显示屏幕’扩展的‘HScreen’类。
建模‘物理显示装置的最终输出组成’的屏幕被MSM称为‘显示屏幕’。相反地，通过逻辑坐标系统转换处理、或通过硬件或软件映射到显示屏幕的屏幕被称为‘逻辑屏幕’。
显示屏幕关联(或映射到)零个或多个视频输出端口，该视频输出端口可以如VideoOutputPort所定义被单独使能或失效。如果显示屏幕没有与任何视频输出端口关联，则在显示屏幕的上下文中活动的任意展示没有被展示装置所展现。
在MSM的上下文中，音频输出及其为了表现音频内容的目的而关联的显示屏幕，被认为由显示屏幕的视频输出端口关联所隐含。
显示屏幕表示它自己或将其映射到它的‘音频焦点屏幕’的逻辑屏幕中的一个。‘音频焦点屏幕’被用来确定哪个音频源在与显示屏幕所映射到的视频输出端口关联的任何(隐含的)音频输出上展现。在本实施例中，音频输出可以是嵌入的音频输出。这种差别只有在多个逻辑屏幕同时映射到或在显示屏幕上展示时才会需要，例如在PiP或PoP多屏幕配置的情况下。
如果没有逻辑屏幕映射到显示屏幕，或者音频焦点不与这样的逻辑屏幕关联，则音频焦点被分配给显示屏幕自己。在这种情况下，与显示屏幕关联的任何HScreenDevice实例成为潜在的候选音频源。
逻辑屏幕是HScreen的基线HAVi模型的自然扩展，其中人们将“装置的最终输出组合”词组中的“装置”理解为与物理装置相对的“逻辑装置”。该扩展与一般理解的逻辑盘驱动的概念没有什么不同，其中物理盘驱动的一部分被当作是它权限内的独立磁盘驱动。
从OCAP应用程序的角度来看，逻辑屏幕用于和显示屏幕一样的所有意图和目的。它拥有现有(非多屏幕)HScreen实例的所有标准属性和行为：默认屏幕背景、视频和图形屏幕装置的集合，这些相同类型的非默认屏幕装置的可选集合，相关屏幕装置配置的一个或更多个集合，自动修改屏幕装置集合以便为这些装置建立相关屏幕配置集合的能力，以及给定屏幕装置配置模板、用于确定能够指定类型的屏幕装置的最佳配置的机制。
每个逻辑屏幕拥有它自己的独立的标准化的如基线HAVi模型所定义的屏幕坐标空间。逻辑屏幕典型地与显示屏幕及该显示屏幕上的显示区域关联。通过这种关联，逻辑屏幕的标准化屏幕坐标空间映射到显示屏幕的标准化屏幕坐标空间的屏幕矩形。尽管为了方便解释下面用屏幕矩形来展示显示区域，本发明不限于矩形。
该屏幕矩形(以下被称为显示区域)可以和整个显示屏幕重合，在这种情况下映射等价于两个标准化屏幕坐标空间之间的映射。
或者，屏幕矩形可以和显示屏幕的一部分重合。在这种情况下，显示区域可以被完全包含在显示屏幕的可见范围内，或者它可以整个位于显示屏幕的可见区域之外。或者，屏幕矩形可以与显示屏幕的可见和非可见(外部)部分交叉。
如果显示区域的某部分延伸到显示屏幕的可见显示区域以外(即，在显示屏幕的显示矩形[0，0]，[1，1]之外)，则是否将区域在外部修剪(clip)到显示屏幕的(名义上的)可见区域，是实施的可选项。
每个逻辑屏幕拥有一组默认显示装置，每个被表示为特定子类型：HBackgroundDevice、HVideoDevice或HSGraphicsDevice的HScreenDevice实例。此外，类似于基线HAVi模型，每个逻辑屏幕可以拥有每个这种子类型的一组非默认屏幕装置。
与基线HAVi模型一样，逻辑屏幕所使用的每个基本屏幕装置资源通过HScreenDevice类的标准子类来被引用，并且这些屏幕装置中的每个拥有它自己的一组配置参数，该配置参数由基线HAVi模型定义，并且通过HScreenConfiguration类的标准子类型来表示。
例如，这样的一个参数通过模板优先选择HScreenConfigurationTemplate.PIXEL_RESOLUTION来建模，并可以使用帮助函数‘HScreenDevice.getPixelResolution()’来访问。正如HScreenDevice实例是基线HAVi模型的非多屏幕实现的情形，在引用逻辑屏幕的显示装置时该参数也可以通过相同的方法存在和访问。
但是，在这里定义的逻辑屏幕的情况下，像素分辨率是指在逻辑屏幕的标准化坐标空间的上下文中的屏幕装置的分辨率，而不是逻辑屏幕所映射到的显示屏幕的分辨率。最后，逻辑屏幕的屏幕装置的像素分辨率确实通过二阶坐标空间转换而映射到显示屏幕的标准化坐标空间。但是，使用逻辑屏幕的应用程序不需要知道该二阶转换，因为从逻辑处理的角度，逻辑屏幕与最后输出到真实物理显示装置的信号没有区别。
逻辑屏幕的标准化坐标空间与显示屏幕的标准化坐标空间中的关联显示区域的映射(上述二阶坐标空间转换)，以下被称为显示映射，被定义为逻辑映射过程，这就是说MSM实施不需要将特定的硬件组件专门用于该映射过程。
例如，一个实施选择是将映射到特定显示屏幕的所有逻辑屏幕的(分配资源的)显示装置的所有集合的并集(在内部)建模为在该单个显示屏幕中的屏幕装置的单个集合，其中使用了关于该屏幕装置集合中的像素相干性和z-顺序的特定限制。
特别地，如果某个像素相干性规则的集合应用到给定的某个逻辑屏幕的显示装置的(子)集合，则当那些显示装置被认为是显示屏幕中(概念上映射的)屏幕装置的更大集合的一部分时，那些像素相干性规则也被应用。
类似地，显示屏幕中的(概念上映射的)屏幕装置的z-顺序必须考虑(1)每个逻辑屏幕内的显示装置的z-顺序，和(2)逻辑屏幕之间的z-顺序。换句话说，不同逻辑屏幕的(概念上映射的)屏幕装置不是隔行扫描的。
无论(从逻辑到显示屏幕的)显示映射过程通过逻辑或物理(硬件)方式来执行，影响该过程的实体被称为用于给定的<逻辑屏幕，显示屏幕>对的映射器。
现在将解释逻辑屏幕的视频输出端口关联。
在典型的情形下，由于被映射到显示屏幕，逻辑屏幕和视频输出端口间接关联，其中显示屏幕与视频输出端口直接关联。但是，为了允许更多灵活性，MSM允许逻辑屏幕与视频输出端口直接关联。
逻辑屏幕可以在两种情形下与视频输出端口直接关联：(1)当逻辑屏幕是孤立的，即，没有映射到任何显示屏幕，而是被独立操作好像它是显示屏幕(在这种情况下它可以直接和视频输出端口关联)，以及(2)当逻辑屏幕以显示屏幕为父(屏幕)，且由此与显示屏幕的输出端口间接关联，并且同时，被独立操作好像它是显示屏幕，并且额外地直接与另一个视频输出端口相关联。下面将分别描述体现这两种情形的使用情况。
1.孤立的逻辑屏幕被添加到服务上下文，该服务上下文的内容例如通过数字视频录像器(DVR)功能被记录，并且同时希望将该内容输出到辅助视频输出端口，例如，1394或NTSC组合端口。
2.逻辑屏幕作为在PiP多屏幕配置中映射到显示屏幕的PiP屏幕被展示(其中主屏幕也同时被展示)，并且该显示屏幕与主要视频输出端口关联；此外，希望该PiP逻辑屏幕直接输出到辅助视频输出端口，例如，1394或NTSC组合端口。
逻辑屏幕通过下列方式中的一种来间接关联到音频输出端口：(1)通过被映射到显示屏幕，与视频输出端口间接关联，或者(2)类似于视频输出端口关联，与视频输出端口直接关联。
当多个逻辑屏幕映射到显示屏幕，只有一个逻辑屏幕典型地在给定时间对用于展现的音频源有贡献。该一个逻辑屏幕被表示为显示屏幕的音频焦点屏幕，并通过使用‘MultiScreenConfigurableContext.assignAudioFocus()’方法来确定。
由于单个逻辑屏幕可以有多个音频源，如从其默认HScreenDevice实例以及非默认实例导出的那样，希望的是控制这些实例中哪个对逻辑屏幕的组合音频输出有贡献。这些源通过使用‘MultiScreenConfigurableContext.add，removeAudioSources(..)’方法来确定。
现在将解释屏幕分类。
多屏幕配置中的每个屏幕被分配给下列预定义的屏幕分类或依赖于平台的分类中的一个，其字符串表示以‘x-’开始：
‘None(SCREEN_CATEGORY_NONE)’、‘Display(SCREEN_CATEGORY_DISPLAY)’、‘Main(SCREEN_CATEGORY_DISPLAY)’、‘PiP(SCREEN_CATEGORY_PIP)’、‘PoP(SCREEN_CATEGORY_POP)’，‘Overlay(SCREEN_CATEGORY_OVERLAY)’以及‘General(SCREEN_CATEGORY_GENERAL)’。
这些屏幕分类被以上MultiScreenConfiguration指定的字段正式定义为可扩展的字符串(String)枚举。只有当没有特定的分类应用时，屏幕才被分类为SCREEN_CATEGORY_NON。
现在将解释‘屏幕标志符(Screen Identifier)’。
共同地表示显示或逻辑屏幕的每组可标志的屏幕资源，被分配唯一的(字符串)标志符，其中唯一性的范围包括在给定时间可以通过所有活动的多屏幕配置来访问的所有屏幕。MSM的实施可以扩大唯一性的范围为包括在给定时间的所有非活动多屏幕配置，并且进一步地，可以扩大该范围为包括平台(在冷启动周期之间)操作的所有连续的持续时间。
支持动态、实时添加显示屏幕或逻辑屏幕的MSM实施应该在添加的时候准备分配标志符，该标志符保持唯一性最小范围的上述限制。
多屏幕配置包括每平台显示多屏幕配置和每显示多屏幕配置。
在任何给定时间，在下列意义上，显示屏幕的特定(通常，但不是必须合适的)子集合在MSM实施的上下文中是活动的：这些显示屏幕如果被标志为可见，则同时表示内容或可以表示来自一个或更多个逻辑屏幕的内容。这样的显示屏幕的子集被称为每平台显示多屏幕配置，并被MSM用实现MultiScreenConfiguration接口的对象来建模，并且其中该接口的getConfigurationType()方法返回MultiScreenConfiguration.SCREEN_CONFIGURATION_DISPLAY。
当前活动的每平台多屏幕配置可以用‘MultiScreenManager.getMultiScreenConfiguration()’来获取，并用‘MultiScreenManager.setMultiScreenConfiguration()’来建立。
此外，对于参与平台多屏幕配置的每个显示屏幕，存在在显示屏幕的上下文中活动的(现有)逻辑屏幕的特定(通常是合适的)子集，从而如果某个这样的逻辑屏幕被标志为可见，则它同时表示内容或可以表示来自一个或更多个服务上下文或媒体播放器的内容。这样的逻辑屏幕的子集被称为每显示多屏幕配置，并被MSM用实现MultiScreenConfiguration接口的对象来建模。MultiScreenConfiguration接口的getConfigurationType()方法返回不同于MultiScreenConfiguration.SCREEN_CONFIGURATION_DISPLAY的值。
特定显示屏幕的当前活动的每显示多屏幕配置可以用MultiScreenContext.getMultiScreenConfiguration()方法来获取，并用MultiScreenConfigurableContext.setMultiScreenConfiguration()来建立。所有可访问可使用的每显示多屏幕配置的集合(其可以和特定的显示屏幕一起使用)可以用MultiScreenContext.getMultiScreenConfiguration()来获取。
所有可访问的多屏幕配置的集合(无论当前正在使用或没有使用，并且无论是每平台还是每显示多屏幕配置)可以用MultiScreenManager.getMultiScreenConfigurations()来获取。
对于每个非终止的OCAP应用程序，当前活动的每平台多屏幕配置的显示屏幕的某个当前活动的多屏幕配置的恰好一个HScreen实例的基本资源应该和OCAP应用程序的默认屏幕的基本资源相同(或等价)。
每个被建模为多屏幕配置的屏幕集合被分配下列预定义的配置类型之一，或以“x-”开头的字符串所表示的依赖于平台的配置。
多屏幕配置类型包括：
·Display(SCREEN_CONFIGURATION_DISPLAY)，
·Non-PiP(SCREEN_CONFIGURATION_NON_PIP)，
·PiP(SCREEN_CONFIGURATION_PIP)，
·PoP(SCREEN_CONFIGURATION_POP)，以及
·General(SCREEN_CONFIGURATION_GENERAL)。
这些配置类型通过MultiScreenConfiguration接口的上述指定字段作为可扩展的字符串(String)枚举来正式定义。
多屏幕配置指定其可访问屏幕中的一个作为默认的服务上下文关联屏幕。在没有更多的特定关联信息时，该屏幕被用来确定服务上下文和屏幕之间的默认关联。
每个预定义的多屏幕配置类型定义了特定的屏幕作为其初始默认服务上下文关联屏幕。在平台启动时间之后，多屏幕配置的默认服务上下文关联屏幕可以使用MultiScreenConfiguration.setDefualtServiceContextScreen(..)来改变。多屏幕配置的当前默认服务上下文关联屏幕可以通过使用MultiScreenConfiguration.getDefaultServiceContextScreen()来获取。
为了更多的信息，现在将解释MultiScreenManager.setMultiScreenConfiguration(..)，MultiScreenConfigurableContext.setMultiScreenConfiguration(..)，并且特别是这些方法的ServiceContextAssociations参数。
默认的多屏幕配置包括默认的每平台多屏幕配置和默认的每显示多屏幕配置。
在执行MSM扩展的OCAP主机装置(Host Device)的冷启动(或重启)之后，默认的(初始活动的)每平台多屏幕配置应该是冷重启之前活动的同一多屏幕配置。如果没有之前的每平台配置是已知的，则默认的每平台多屏幕配置应该是MultiScreenManager.getMultiScreenConfigurations(SCREEN_CONFIGURATION_DISPLAY)返回的与显示屏幕关联的第一个多屏幕配置，该屏幕反过来与配置类型SCREEN_CONFIGURATION_NON_PIP的每显示多屏幕配置关联。
类似地，默认的每平台多屏幕配置的每个显示屏幕的默认(初始活动的)每显示多屏幕配置应该是冷重启之前活动的同一多屏幕配置。如果对于某个显示屏幕没有之前的每显示多屏幕配置是已知的，则它应该是由该显示屏幕上的MultiScreenContext.getMultiScreenConfigurations(SCREEN_CONFIGURATION_NON_PIP)返回的配置类型是SCREEN_CONFIGURATION_NON_PIP的第一个多屏幕配置。
当对实现MSM扩展的OCAP主机装置或OCAP环境执行任何其它类型的(非冷)重启或重置时，则默认的(初始活动的)多屏幕配置应该是非冷重启或环境重置之前活动的同一多屏幕配置。
现在将解释屏幕装置的定义。
HScreen实例表示来自装置的单个独立视频输出信号。具有多个独立视频输出信号的装置应该支持HScreenDevice类的多个实例。视频输出信号通过将由从HScreenDevice类继承的多个对象表示的装置的作用加在一起而创建。这些对象可以是HGraphicsDevice对象、HVideoDevice对象和HBackgroundDevice对象。给定的HScreen可以支持API所涉及的任意数量的这些对象。但是，某些形式的特性(profiling)可以限制对象的数量。现在实际上，每个实例是所有可以合理地期望作为当前的那些。
HBackgroundDevice类表示屏幕的最终背景，即，背景颜色和背景图像。背景是视频/图像组成栈中的最后面。背景可以潜在地覆盖整个屏幕区域。当装置支持在屏幕上同时有多个应用程序(或甚至是窗口管理器)，背景不受任何特殊应用程序或窗口的限制。控制屏幕背景的权利是稀缺资源，并被这样管理。
HGraphicsDevice类描述了可用于特定HScreen的光栅图形装置。每个HGraphicsDevice具有与该HGraphicsDevice关联的一个或更多个HGraphicsConfiguration对象。
这些对象指定了在HGraphicsDevice中可以被使用的不同配置(设置)。
HVideoDevice类描述了可以对特定屏幕的外观起作用的逻辑视频装置。每个HVideoDevice具有与HVideoDevice关联的一个或更多个HVideoConfiguration对象。这些对象制定了在HVideoDevice中可以被使用的不同配置(设置)。HVideoDevice类只表示视频的展示，而不提供对哪个视频被展示的选择。
HScreenDevice类、HBackgroundDevice类、HGraphicsDevice类和HVideoDevice类在用于HAVi用户接口的‘org.havi.ui’包中定义。
公共类HBackgroundDevice扩展了HScreenDevice。HBackgroundDevice类描述了由从HScreenDevice类继承的对象所表示的背景装置。
公共类HGraphicsDevice扩展了HScreenDevice。HGraphicsDevice类描述了由从HScreenDevice类继承的对象所表示的图形装置。
公共类HVideoDevice扩展了HScreenDevice。HVideoDevice类描述了由从HScreenDevice类继承的对象所表示的视频装置。
现在将解释改变多屏幕配置。
当前的多屏幕配置可以由授权的应用程序(MonitorAppPermission(“multiscreen.configuration”)被授予了该应用程序)，通过MultiScreenManager实例或某个显示屏幕的MultiScreenConfigurableContext接口的setMultiScreenConfiguration(..)或requestMultiScreenConfigurationChange(..)方法来改变。此外，当前的多屏幕配置可以被主机装置自己作为未被本说明书定义的其它事件的结果而改变。例如，制造商可以提供显式的远程控制键，其引起特定的多屏幕配置被激活。
不管是什么引起了当前多屏幕配置被改变，应该使用下列限制：
1.在改变之前，使用下面指定的事先条件；
2.在改变的期间，使用下面指定的改变处理步骤，在该时间阶段，使用下面指定的动态状态不变量；
3.在改变之后，使用下面定义的事后条件。
为了提高共同操作性的目的，多个这样的事前条件和事后条件在图24A到24C及25A到25E中以断言的形式以伪代码的形式来表示。在图24A到24C及25A到25E中表示的限制旨在与在下列子章节中出现的描述性文本一致。为了避免疑问，在被编码形式不连续或部分覆盖的情况下，下列描述性文本将优先于图24A到24C和图25A到25E的编码。尽管有该优先，图24A到24C和图25A到25E应该为了确定MSM扩展的可共同操作的实施的一致性的目的而使用。
现在将解释用于改变多屏幕配置的事前条件。
在作为多屏幕配置改变的结果而产生的MultiScreenConfigurationEvent.MULTI_SCREEN_CONFIGURATION_CHANGING事件之前，下列有序的事前条件应该成立。
1.下面定义的静态不变量(Quiescent State Invariant)必须被满足。现在将说明改变处理步骤。
MSM实施应该执行下列有序的步骤，以影响对当前多屏幕配置的改变。
1.产生MultiScreenConfigurationEvent.MULTI_SCREEN_CONFIGURATION_CHANGING事件，用于应用程序的分派。
2.在这一时刻开始，直到MultiScreenConfigurationEvent.MULTI_SCREEN_CONFIGURATION_CHANGED事件产生的时刻，不允许OCAP应用程序(1)改变当前的多屏幕配置，(2)保留HScreen或HScreenDevice及其基本资源，或者(3)执行屏幕装置配置改变或多屏幕屏幕上下文状态改变。
3.对于被授予MonitorAppPermission(“multiscreen.configuration”)权限的每个OCAP应用程序，调用任何被注册的MultiScreenConfigurationListener的notify()方法，提供作为上面产生的MultiScreenConfigurationEvent.MULTI_SCREEN_CONFIGURATION_CHANGING的参数。
所有这样的被注册的监听器应该在继续到下一步骤之前被调用。但是，MSM实施不需要在继续之前等待任一个或所有监听器从notify()方法返回。
4.对于任何HScreen实例，其MultiScreenContext可访问状态将要或可以作为对当前多屏幕配置的该改变的结果而改变，则如果HScreen实例由不同于调用setMultiScreenConfiguration(..)方法的应用程序的某个OCAP应用程序所保留，或者倘若该改变是主机装置初始改变的结果由任何OCAP应用程序保留(OCAP应用程序没有对该方法的显式调用)，则，对于由保留的HScreen引用的每个HScreenDevice，并且在推迟对任何产生的HScreenDevice ReleasedEvent实例的通知时，调用releaseDevice()方法，并且如果需要，调用拥有该保留的ResourceClient的release()方法。
5.对于任何HScreen实例，其HScreenConfiguration可访问状态将要或可以作为当前多屏幕配置改变的结果而改变，则如果HScreen实例由不同于调用setMultiScreenConfiguration(..)方法的应用程序的某个OCAP应用程序所保留，或者倘若该改变是主机装置初始改变的结果由任何OCAP应用程序保留(OCAP应用程序没有对该方法的显式调用)，则，对于该HScreenDevice，并且在推迟对任何产生的HScreenDeviceReleasedEvent实例的通知时，调用releaseDevice()方法，并且如果需要，调用拥有该保留的ResourceClient的release()方法。
6.对于任何HScreenDevice，其HScreenConfiguration可访问状态将要或可以作为当前多屏幕配置改变的结果而改变，产生但延迟通知相应的HScreenConfigurationEvent实例。
7.对于任何HScreen实例，其MultiScreenContext可访问状态将要或可以作为当前多屏幕配置改变的结果而改变，产生但延迟相应的MultiScreenContextEvent实例。
8.如果任何MultiScreenConfigurationListener其nofity()方法在上面的步骤(3)中被调用还没有返回，则等待直到(1)所有这样的notify()方法已经返回，或者(2)自第一个这样的方法被调用起，已经经过了不少于五秒不多于30秒的时间(实时)。
9.执行所有需要的改变，以满足下面指定的事后条件。
10.对于上面产生且按照产生顺序的每个HScreenDeviceReleasedEvent实例，则对于每个OCAP应用程序，调用任何已注册的ResourceStatusListener的statusChanged()方法，提供作为HScreenDeviceReleasedEvent实例的参数。
11.对于上面产生且按照产生顺序的每个HScreenConfigurationEvent实例，则对于每个OCAP应用程序，调用任何已注册的HScreenConfigurationListener的report()方法，提供作为HScreenConfigurationEvent实例的参数。
12.对于上面产生且按照产生顺序的每个MultiScreenContextEvent实例，则对于每个OCAP应用程序，调用任何已注册的MultiScreenContextListener的notify()方法，提供作为MultiScreenContextEvent实例的参数。
13.产生MultiScreenConfigurationEvent.MULTI_SCREEN_CONFIGURATION_CHANGED事件用于应用程序分派。
14.对于每个OCAP应用程序，调用任何已注册的MultiScreenConfigurationListener的notify()方法，提供作为上面产生的MultiScreenConfigurationEvent.MULTI_SCREEN_CONFIGURATION_CHANGED的参数。
下面将解释多屏幕配置改变的事后条件。
在作为多屏幕配置改变的结果而产生的MultiScreenConfigurationEvent.MULTI_SCREEN_CONFIGURATION_CHANGED事件之后，下面有序的事后条件应该成立。
1.下面定义的静态不变量必须被满足。
2.当前的多屏幕配置是新的配置。
3.新的默认屏幕必须是和旧的默认屏幕一样的(对象)。
4.如果默认的背景屏幕装置在旧的和新的多屏幕配置两者中的默认屏幕中都存在，则除非应用程序发送为‘1’的allow_default_device_reconfig信号，
a.新的默认背景屏幕装置必须是和旧的默认背景屏幕装置相同的实例，并且
b.新的默认背景屏幕装置必须和旧的默认背景屏幕装置具有相同的屏幕区域、像素分辨率和像素纵横比。
如果应用程序发送为‘1’的allow_default_device_reconfig信号，并且默认的背景屏幕装置在旧的多屏幕配置中存在而在新的多屏幕配置中不存在，则对旧的默认背景屏幕配置的任何引用必须被重置为等于空的背景屏幕装置。
5.如果默认的视频屏幕装置在旧的和新的多屏幕配置两者中的默认屏幕中都存在，则除非应用程序发送为‘1’的allow_default_device_reconfig信号，
a.新的默认视频屏幕装置必须是和旧的默认视频背景屏幕装置相同的实例，并且
b.新的默认视频屏幕装置必须和旧的默认视频屏幕装置具有相同的屏幕区域、像素分辨率和像素纵横比。
如果应用程序发送为‘1’的allow_default_device_reconfig信号，并且默认的视频屏幕装置在旧的多屏幕配置中存在而在新的多屏幕配置中不存在，则对旧的默认视频屏幕配置的任何引用必须被重置为等于空的视频屏幕装置。
6.如果默认的图形屏幕装置在旧的和新的多屏幕配置两者中的默认屏幕中都存在，则除非应用程序发送为‘1’的allow_default_device_reconfig信号，
a.新的默认图形屏幕装置必须是和旧的默认图形屏幕装置相同的实例，并且
b.新的默认图形屏幕装置必须和旧的默认图形屏幕装置具有相同的屏幕区域、像素分辨率和像素纵横比。
如果应用程序发送为‘1’的allow_default_device_reconfig信号，并且默认的图形屏幕装置在旧的多屏幕配置中存在而在新的多屏幕配置中不存在，则对旧的默认图形屏幕配置的任何引用必须被重置为等于空的图形屏幕装置。
7.对于在重新配置之前获取的每个非默认屏幕引用，如果非默认屏幕不再存在，则它必须等于空屏幕；否则，它必须不等于空屏幕。
8.对于在重新配置之前获取的每个非默认屏幕装置，如果非默认屏幕装置不再存在，则它必须等于空屏幕装置；否则，它必须不等于空屏幕装置。
下面将定义静态不变量。
在MultiScreenConfigurationEvent.MULTI_SCREEN_CONFIGURATION_CHANGING事件之后并且在对应的MultiScreenConfigurationEvent.MULTI_SCREEN_CONFIGURATION_CHANGED事件之前，下面有序的不变量必须成立：
1.必须存在当前的非改变多屏幕管理器；
2.必须存在当前的非改变每平台多屏幕配置；
3.必须存在用于每个显示屏幕的当前的非改变每显示多屏幕配置；
4.必须存在非空、非改变的可访问多屏幕配置的集合；
5.当前的每平台多屏幕配置必须是(对适当授权的应用程序)可访问的配置；
6.每个当前的每显示多屏幕配置必须是(对适当授权的应用程序)可访问的配置；
7.必须存在当前每平台多屏幕配置中的非空、非改变的屏幕集合；
8.必须存在每个当前每显示多屏幕配置中的非空、非改变的屏幕集合；
9.在当前的每平台多屏幕配置中的屏幕必须不为空；
10.在每个当前的每显示多屏幕配置中的屏幕必须不为空；
11.在当前的多屏幕配置中的任意两个不同的屏幕元素必须不能表示相同的资源；
12.必须存在当前的默认屏幕；
13.当前的默认屏幕必须不等于空屏幕；
14.在某个当前多屏幕配置中正好有一个屏幕元素必须表示和默认屏幕相同的资源；
15.必须存在非空的可访问屏幕的集合；
16.当前的默认屏幕必须是可访问屏幕集合中的不同成员；
17.当前的默认屏幕的任何背景屏幕装置必须不等于空的背景屏幕装置；
18.当前的默认屏幕的任何视频屏幕装置必须不等于空的视频屏幕装置；
19.当前的默认屏幕的任何图形屏幕装置必须不等于空的图形屏幕装置；
现在将解释动态不变量(Dynamic State Invariant)。
在MultiScreenConfigurationEvent.MULTI_SCREEN_CONFIGURATION_CHANGING事件之后并且在MultiScreenConfigurationEvent.MULTI_SCREEN_CONFIGURATION_CHANGED事件之前，下面有序的不变量必须成立：
1.必须存在当前的非改变多屏幕管理器；
2.必须存在当前的但可能改变的多屏幕配置；
3.必须存在非空但可能改变的可访问多屏幕配置的集合；
4.当前的多屏幕配置必须是可访问的配置；
5.必须存在当前多屏幕配置中的非空但可能改变的屏幕集合；
6.当前的多屏幕配置中的屏幕必须不为空；
7.在当前的多屏幕配置中的任意两个不同的屏幕元素必须不能表示相同的资源；
8.必须存在当前的但可能改变的默认屏幕；
9.当前的默认屏幕必须不等于空屏幕；
10.当前的多屏幕配置中正好有一个屏幕元素必须表示和默认屏幕相同的资源；
11.必须存在非空但可能改变的可访问屏幕的集合；
12.当前的默认屏幕必须是可访问屏幕集合中的不同成员；
13.当前的默认屏幕的任何背景屏幕装置必须不等于空的背景屏幕装置；
14.当前的默认屏幕的任何视频屏幕装置必须不等于空的视频屏幕装置；
15.当前的默认屏幕的任何图形屏幕装置必须不等于空的图形屏幕装置。
现在将解释本发明所应用的基线HAVi模型扩展。
多屏幕管理器必须有对基线HAVi模型，特别是下面说明的下列HAVi定义类型的特定行为和用途的扩展。
如上所示，每个HScreen实例被刻画为如多屏幕管理器所定义的显示屏幕或逻辑屏幕。
关于由这样的实例表示的HScreen实例和基本资源，由多屏幕管理器给出区别。特别地，与HScreen实例关联的下列基本状态可以在其时间范围内改变。
即，基本背景屏幕装置、这些基本背景屏幕装置的屏幕装置配置(参数集合)、与默认的HBackgroundDevice实例关联的基本背景屏幕装置的数量，基本视频屏幕装置、这些基本视频屏幕装置的屏幕装置配置(参数集合)、与默认的HVideoDevice实例关联的基本视频屏幕装置的数量，基本图形屏幕装置、与默认的HGraphicsDevice实例关联的基本图形屏幕装置、这些基本图形屏幕装置的屏幕装置配置(参数集合)的数量，可以在其时间范围内改变。
每个HScreen实例应该实现MultiScreenContext接口，或者如果HScreen实例表示根据MultiScreenConfigurableContext所定义的功能可以配置的基本屏幕资源，则HScreen实例应该实现MultiScreenConfigurableContext接口而不是MultiScreenContext(注意MultiScreenConfigurableContext接口是MultiScreenContext接口的子接口)。
HScreen.getHScreens()静态方法应该返回和MultiScreenManager.getInstance().getScreens()相同的值。
HScreen.getDefaultHScreen()静态方法应该返回和MultiScreenManager.getInstance().getDefaultScreen()相同的值。
现在将解释默认HScreen分配。
当应用程序被初始启用时，应用程序应该首先与由HScreen.getHScreens()返回的可访问屏幕的集合关联，并且其次被分配给根据下列规则的默认HScreen，其中，适用的第一规则被使用，而其它的被忽略：
1.如果ServiceContext SC只与一个(基本)屏幕关联，该ServiceContextSC的应用程序所选中的服务被发送信号，则使用该屏幕作为默认屏幕。
2.否则，如果SC与多个(基本)屏幕关联，则如果这些屏幕中的一个被分类为主屏幕，即，getScreenCategory()返回MultiScreenConfiguration.SCREEN_CATEGORY_MAIN，则使用在由HScreen.getHScreens()返回的屏幕排列中出现的第一个这样的主屏幕作为默认屏幕。
3.否则(与多个屏幕关联关联，其中没有一个是主要屏幕)，则使用HScreen.getHScreens()返回的屏幕排列中出现的第一个屏幕作为默认屏幕。
MSM引入了已知为空HScreen的特殊定义的HScreen实例，它是HScreen类的(子类的)唯一、不可变的实例，其用于建立(名义上非空的)HScreen实例中明确定义的已知状态。
下面被称为ES的空HScreen应该满足下列限制：
1.在应用程序引用的范围内，ES是唯一的(对象)实例；
2.ES实现下列接口：MultiScreenContext、MultiScreenConfigurableContext、ResourceProxy和ResourceServer；
3.ES.getDefaultHBackgroundDevice()应该返回HBackgroundDevice，其状态等于下面定义的空HBackgroundDevice；
4.ES.getDefaultHVideoDevice()将返回HVideoDevice，其状态等于下面定义的空HVideoDevice；
5.ES.getDefaultHGraphicsDevice()将返回HGraphicsDevice，其状态等于下面定义的空HScreenDevice；
6.ES.getBestConfiguration(HBabckgroundConfigTemplate hbc)将返回ES.getDefaultBackgroundDevice().getBestConfiguration(hbc)；
7.ES.getBestConfiguration(HVideoConfigTemplate hvc)将返回ES.getDefaultVideoDevice().getBestConfiguration(hvc)；
8.ES.getBestConfiguration(HGraphicsConfigTemplate hgc)将返回ES.getDefaultGraphicsDevice().getBestConfiguration(hgc)；
9.ES.getBackgroundDevices()将返回new HBackgroundDevice[1]{ES.getDefaultHBackgroundDevice()}；
10.ES.getVideoDevices()将返回new HVideoDevice[1]{ES.getDefaultHVideoDevice()}；
11.ES.getGraphicsDevices()将返回new HGraphicsDevice[1]{ES.getDefaultHGraphicsDevice()}；
12.ES.getCoherentScreenConfigurations(..)将返回null；
13.ES.setCoherentScreenConfigurations(..)将抛出HConfigurationException的异常；
14.((MultiScreenContext)ES).getScreenType()将返回MultiScreenContext.SCREEN_TYPE_LOGICAL；
15.((MultiScreenContext)ES).getDisplayScreen()将返回null；
16.((MultiScreenContext)ES).getDisplayArea()将返回null；
17.((MultiScreenContext)ES).getOutputPorts()将返回null；
18.((MultiScreenContext)ES).getServiceContexts()将返回new ServiceContext[0]；
19.((MultiScreenContext)ES).getVisible()将返回false；
20.((MultiScreenContext)ES).getZOrder()将返回-1；
21.((MultiScreenContext)ES).addScreenContextListener()不会产生任何副作用；
22.((MultiScreenConfigurableContext)ES).setDisplayScreen(..)将抛出IllegalStateException的异常，除非使用SecurityException；
23.((MultiScreenConfigurableContext)ES).setDisplayArea(..)将抛出IllegalStateException的异常，除非使用SecurityException；
24.((MultiScreenConfigurableContext)ES).setVisible(..)将抛出IllegalStateException的异常，除非使用SecurityException；
25.((MultiScreenConfigurableContext)ES).setZOrder(..)将抛出IllegalStateException的异常，除非使用SecurityException；
26.((MultiScreenConfigurableContext)ES).addOutputPort(..)将抛出IllegalStateException的异常，除非使用SecurityException；
27.((MultiScreenConfigurableContext)ES).(..)将抛出IllegalStateException的异常，除非使用SecurityException；
28.((ResourceProxy)ES).getClient()将返回null。
如果两个HScreenDevice接口SD1和SD2关于其基本资源是相等的，即如果sameResources(SD1，SD2)返回true，则SD1.getIDString()将返回与SD2.getIDString()一样的值；否则，SD1.getIDString()将返回与SD2.getIDString()一样的值。
OCAP应用程序保留HScreenDevice的尝试将导致HpermissionDeniedException异常的抛出，该HScreenDevice的基本屏幕装置资源不被完全包括在当前活动的多屏幕配置所引用的基本屏幕装置资源集合之内。
上述限制旨在防止应用程序保留屏幕装置资源，其中该资源不被包含在某个当前活动的多屏幕配置所表示的基本资源集合之中。这样的情形可以在活动多屏幕配置和某个非活动多屏幕配置之间划分屏幕装置资源的情况下使用。
下面将解释默认的HScreenDevice分配。
通过如上所述分配默认屏幕，可访问屏幕装置的默认集合被分配给应用程序。在默认分配给HScreen S时，分配给应用程序的默认屏幕装置应该通过S.getDefaultHBackgroundDevice()、S.getDefaultHVideoDevice()和S.getDefaultHGraphicsDevice()来确定。
如果默认屏幕具有多于一个特定类型的屏幕装置，则为该屏幕确定这些屏幕装置中哪个是该特定类型的默认屏幕装置的过程，应该保持依赖于平台，并且这样的分配应该不依赖于共同操作的应用程序。
MSM引入了定义的子类型HBackgroundDevice、HVideoDevice和HGraphicsDevice的空HScreenDevice实例的特殊定义的集合。这些实例，下面被称为ED，应该在后面的副标题下定义的其子类型的特定限制之外满足下列限制：
1.ED.getIDString()将返回空字符串“”；
2.ED.getScreenAspectRatio()将返回new Dimension()；
3.ED.addMultiScreenConfigurationListener(..)不会产生任何副作用；
4.ED.reserveDevice(ResourceClient)将返回false；
5.ED.releaseDevice()不会产生任何副作用；
6.ED.getClient()将返回null。
空HBackgroundDevice，下面称为EBD，应该满足下列限制：
1.在应用程序引用的范围内，EBD是唯一的(对象)实例；
2.EBD应该满足上面对空HScreenDevice指定的限制；
3.EBD.getDefaultConfiguration()将返回如下定义的空HBackgroundConfiguration；
4.EBD.getCurrentConfiguration()将返回与EBD.getDefaultConfiguration()相同的值；
5.EBD.getBestConfiguration(..)将返回与EBD.getDefaultConfiguration()相同的值；
6.EBD.getConfigurations()将返回new HbackgroundConfiguration[1]{getDefaultConfiguration()}；
7.EBD.setBackgroundConfiguration()将抛出HConfigurationException的异常，除非使用SecurityException或HPermissionException的异常。
空HVideoDevice，下面称为EVD，应该满足下列限制：
1.在应用程序引用的范围内，EVD是唯一的(对象)实例；
2.EVD应该满足上面对空HScreenDevice指定的限制；
3.EVD.getDefaultConfiguration()将返回如下定义的空HVideoConfiguration；
4.EVD.getCurrentConfiguration()将返回与EVD.getDefaultConfiguration()相同的值；
5.EVD.getBestConfiguration(..)将返回与EVD.getDefaultConfiguration()相同的值；
6.EVD.getConfigurations()将返回new HVideoConfiguration[1]{getDefaultConfiguration()}；
7.EVD.setVideoConfiguration()将抛出HConfigurationException的异常，除非使用SecurityException或HPermissionException的异常。
空HGraphicsDevice，下面称为EGD，应该满足下列限制：
1.在应用程序引用的范围内，EGD是唯一的(对象)实例；
2.EGD应该满足上面对空HScreenDevice指定的限制；
3.EGD.getDefaultConfiguration()将返回如下定义的空HGraphicsConfiguration；
4.EGD.getCurrentConfiguration()将返回与EGD.getDefaultConfiguration()相同的值；
5.EGD.getBestConfiguration(..)将返回与EGD.getDefaultConfiguration()相同的值；
6.EGD.getConfigurations()将返回new  HGraphicsConfiguration[1]{getDefaultConfiguration()}；
7.EGD.setGraphicsConfiguration()将抛出HConfigurationException的异常，除非使用SecurityException或HPermissionException的异常。
MSM引入了定义的子类型HBackgroundConfiguration、HVideoConfiguration和HGraphicsConfiguration的特殊定义的空HScreenConfiguration实例的集合。
空HScreenConfiguration的实例，下面被称为EC，应该在后面的副标题下定义的其子类型的特定限制之外满足下列限制：
1.EC.convertTo(..)将返回null；
2.EC.getFlickerFilter()将返回false；
3.EC.getInterlaced()将返回false；
4.EC.getOffset(..)将返回new Dimension()；
5.EC.getPixelAspectRatio()将返回new Dimension()；
6.EC.getPixelSolution()将返回new Dimension()；
7.EC.getScreenArea()将返回new HScreenRectangle(0，0，0，0)。
空HBackgroundConfiguration，下面被称为EBC，应该满足下列条件：
1.在应用程序引用的范围内，EBC应该是唯一的(对象)实例；
2.EBC应该满足上面对空HScreenConfiguration指定的限制；
3.EBC.getDevice()将返回上面定义的空HBackgroundDevice实例；
4.EBC.getConfigTemplate()将返回下面定义的空BackgroundConfigTemplate；
5.EBC.getColor()将返回new Color(0，0，0)；
6.EBC.setColor()将抛出HConfigurationException的异常。
空HVideoConfiguration，下面被称为EVC，应该满足下列条件：
1.在应用程序引用的范围内，EVC应该是唯一的(对象)实例；
2.EVC应该满足上面对空HScreenConfiguration指定的限制；
3.EVC.getDevice()将返回上面定义的空HVideoDevice实例；
4.EVC.getConfigTemplate()将返回下面定义的空HVideoConfigTemplate。
空HGraphicsConfiguration，下面被称为EGC，将满足下列条件：
1.在应用程序引用的范围内，EGC应该是唯一的(对象)实例；
2.EGC应该满足上面对空HScreenConfiguration指定的限制；
3.EGC.getDevice()将返回上面定义的空HGraphicsDevice实例；
4.EGC.getConfigTemplate()将返回下面定义的空HGraphicsConfigTemplate；
5.EGC.getAllFonts()将返回Font[0]；
6.EGC.getCompatibleImage(Image input，HImageHints hints)将返回输入；
7.EGC.getComponentHScreenRectangle(..)将返回null；
8.EGC.getPixelCorrdinatesHScrenRectangle(..)将返回new Rectangle()；
9.EGC.getPunchThroughToBackgroundColor(..)将返回null；
10.EGC.dispose(Color)不会产生任何副作用。
MSM引入了定义的子类型HBackgroundConfigTemplate、HVideoConfigTemplate和HGraphicsConfigTemplate的特殊定义的空HScreenConfigTemplate实例的集合。
空HScreenConfigTemplate的实例，下面被称为ET，应该在后面的副标题下定义的其子类型的特定限制之外满足下列限制：
1.ET.getPreferenceObject(int)应该抛出IllegalArgumentException的异常；
2.ET.getPreferencePriority(int)将返回HScreenConfigTemplate.DONT_CARE；
3.ET.setPreference(int，int)将抛出IllegalArgumentException的异常；
4.ET.setPreference(int，Object，int)将抛出IllegalArgumentException的异常。
空HBackgroundConfigTemplate，下面被称为EBT，应该满足下列限制：
1.在应用程序参考的范围内，EBT是唯一的(对象)实例；
2.EBT应该满足上面对空HScreenConfigTemplate指定的限制；
3.EBT.isConfigSupported(HBackgroundConfiguration)将返回false。
空HVideoConfigTemplate，下面被称为EVT，应该满足下列限制：
1.在应用程序参考的范围内，EVT是唯一的(对象)实例；
2.EVT应该满足上面对空HScreenConfigTemplate指定的限制；
3.EVT.isConfigSupported(HVideoConfiguration)将返回false。
空HGraphicsConfigTemplate，下面被称为EGT，应该满足下列限制：
1.在应用程序参考的范围内，EGT是唯一的(对象)实例；
2.EGT应该满足上面对空HScreenConfigTemplate指定的限制；
3.EGT.isConfigSupported(HGraphicsConfiguration)将返回false。
现在将解释HVideoDevice。
如果本说明书定义的某些机制的使用允许多于一个(至少由视频解码器和解码器格式转换组件构成的)视频管线关联(或映射到)由HVideoDevice实例表示的基本视频屏幕装置资源，则这些管线中的一个被指定为有贡献的视频管线，而剩余的被指定为非贡献(non-contributing)的视频管线。非贡献的视频管线不应该向由HVideoDevice实例表示的基本视频屏幕装置资源贡献视频信息或相关的音频信息。
有贡献的视频管线应该根据下列有序的规则，从一组可能是有空闲的视频管线中确定：
1.如果候选的视频管线中只有一个视频管线与某个非抽象服务的活动视频基本流(elementary stream)关联，则该视频管线是有贡献的管线；
2.否则，如果候选的视频管线中有多于一个的视频管线与某个非抽象服务的活动视频基本流关联，则最近选择的非抽象服务的视频管线是有贡献的管线；
3.否则，如果候选的视频管线中只有一个视频管线与由某个非抽象服务控制的媒体播放器关联，则该媒体播放器的视频管线是有贡献的管线；
4.否则，如果候选的视频管线中有多于一个的视频管线与某个非抽象服务控制的媒体播放器关联，则最近启动(或在暂停或停止后恢复)的媒体播放器的视频管线是有贡献的视频管线；
5.否则，如果候选的视频管线中只有一个视频管线与由某个抽象服务控制的媒体播放器关联，则该媒体播放器的视频管线是有贡献的管线；
6.否则，如果候选的视频管线中有多于一个的视频管线与某个抽象服务控制的媒体播放器关联，则最近启动(或在暂停或停止后恢复)的媒体播放器的视频管线是有贡献的视频管线；以及
7.否则，确定哪个视频管线是有贡献的视频管线没有被本说明书定义，并依赖于实现。
当本发明的实施例是基于实施OCAP MSM扩展的OCAP主机装置时，现在将解释Xlet应用程序的安全所需的某些许可。
本说明书定义的特定方法的调用需要应用程序具有MonitorAppPermission(“multiscreen.configuration”)或(和)MonitorAppPermission(“multiscreen.context”)中的一个(或两者)。在实施OCAP MSM扩展的OCAP主机装置中，下列附加的许可被认为应用到MonitorAppPermission。
multiscreen.configuration提供访问和修改平台多屏幕配置状态的能力。具有该许可的应用程序可以修改平台的多屏幕配置并发现和监控其动态状态。
multiscreen.context提供修改屏幕的多屏幕上下文状态的能力。具有该许可的应用程序可以修改可访问的屏幕的多屏幕上下文状态。
此外，由许可请求文件(PRF)定义的文档类型定义(DTD)所定义ocap:monitorapplication元素类型的名字属性的枚举标志值类型应该被认为包含下列值：multiscreen.configuration和multiscreen.context。
由于本发明的实施例基于Java系统，现在将定义系统属性(SystemProperty)。
如果OCAP主机装置实施本实施例中的MSM扩展，则“ocap.api.option.msm”Java系统属性应该用对应于本说明书的实现版本的值来定义，其中本说明书的该版本为“1.0.0”。相反，如果主机装置定义了“ocap.api.option.msm”Java系统属性，则主机装置应该实现本说明书的符合该属性值的版本。
对该属性的读访问应该同时被授予签名和未签名的应用程序。
现在将解释根据本发明的实施例实现基于Java系统的多屏幕管理器的实施例。
现在将参考图11A到11G来解释根据本发明的实施例的Java接口常量的注册。
图11A示出了根据本发明的实施例的org.ocap.ui.MultiScreenConfigurableContext中的Java常量的注册。这些常量在下面参考图13A到13F说明的org.ocap.ui包的MultiScreenConfigurableContext中定义。
图11B示出了根据本发明的实施例的‘org.ocap.ui.MultiScreenConfiguration’中的Java常量的注册。这些常量在下面参考图14A到14C说明的‘org.ocap.ui’包的‘MultiScreenConfiguration’中定义。
图11C示出了根据本发明的实施例的‘org.ocap.ui.MultiScreenContext’中的Java常量的注册。这些常量在下面参考图15A到15D来说明的‘org.ocap.ui’包的‘MultiScreenContext’中定义。
图11D示出了根据本发明的实施例的‘org.ocap.ui.event.MultiScreenConfigurationEvent中的Java常量的注册。这些常量在下面参考图18A到18D说明的‘org.ocap.ui.event’包的‘MultiScreenConfigurationEvent中定义。
图11E示出了根据本发明的实施例的‘org.ocap.ui.event.MultiScreenContextEvent中的Java常量的注册。这些常量在下面参考图20A到20D说明的‘org.ocap.ui.event’包的‘MultiScreenContextEvent中定义。
图11F示出了根据本发明的实施例的‘org.ocap.ui.event.MultiScreenEvent中的Java常量的注册。这些常量在下面参考图22A到22D说明的‘org.ocap.ui.event’包的‘MultiScreenEvent中定义。
图11G示出了根据本发明的实施例的‘org.ocap.ui.event.MultiScreenResourceEvent中的Java常量的注册。这些常量在下面参考图23A到23D说明的‘org.ocap.ui.event’包的‘MultiScreenResourceEvent中定义。
现在将解释根据本发明的实施例的多屏幕管理的平台行为(语义)。
现在将参考图12到16F解释HAVi用户接口的org.ocap.ui包的扩展。
图12示出了根据本发明的实施例的Java包‘org.ocap.ui’的接口和类。
org.ocap.ui包的接口1200包括MultiScreenConfigurableContext接口1210、MultiScreenConfiguration接口1220以及‘MultiScreenContext’接口1230。
将参考图13A到13F解释MultiScreenConfigurableContext接口1210，将参考图14A到14C解释MultiScreenConfiguration接口1220，并将参考图15A到15D解释MultiScreenContext接口1230。
org.ocap.ui包的类1250包括MultiScreenManager类1260。将参考图16A到16F解释MultiScreenManager类1260。
图13A示出了根据本发明的实施例的org.ocap.ui包的MultiScreenConfigurableContext接口的定义。
MultiScreenConfigurableContext接口1210包括MultiScreenContext和org.davic.resources.ResourceProxy作为超接口(superinterface)。public interfaceMultiScreenConfigurableContext扩展了MultiScreenContext，org.davic.resources.ResourceProxy。
MultiScreenConfigurableContext接口1210提供了用于完成下列功能的一组工具：
1.修改逻辑HScreen到显示HScreen的映射，包括逻辑HScreen在显示HScreen上出现的区域(范围)、其可见性及其(在其它HScreen中的)z-顺序；
2.修改HScreen内的HScreenDevice的z-顺序；
3.修改与HScreen关联的ServiceContext集合；
4.修改显示HScreen的关联及相应的VideoOutputPort实例；
5.修改HScreenDevice的集合，其生成的音频组成HScreen的音频源的集合；
6.修改显示HScreen的当前视频焦点分配；
7.保留和释放对基本屏幕和屏幕装置资源的保留；
8.获取对已经保留了屏幕及其基本资源的当前资源客户端的引用；以及
9.建立显示HScreen的当前活动每显示多屏幕配置。
如果HScreen实例可以暴露给OCAP应用程序并且如果该HScreen关于由MultiScreenConfigurableContext接口1210定义的功能可以配置，则MSM实施应该在每个这样的HScreen实例上支持MultiScreenConfigurableContext接口。
MSM实施可以在关于由MultiScreenConfigurableContext接口1210定义的功能不可配置的HScreen实例上支持MultiScreenConfigurableContext接口1210。
不需要MultiScreenConfigurableContext接口1210的给定实现来支持任意或所有定义的配置改变，但由于硬件或其它限制，可以只支持特定的配置改变。
如果MultiScreenConfigurableContext接口1210的实现不支持特定的配置改变，则试图执行该改变将引起IllegalStateException异常被发起，如下面定义的每个方法下所说明的那样。
MultiScreenConfigurableContext接口1210从MSM 101版本起使用。
图13B示出了根据本发明的实施例的org.ocap.ui包的MultiScreenConfigurableContext接口的字段。
MultiScreenConfigurableContext接口的字段1300包括下列值中的至少一个：‘static int CONFIGURABLE_SCREEN_PARAMETER_AUDIO_FOCUS1302’、‘static int CONFIGURABLE_SCREEN_PARAMETER_AUDIO_SOURCE 1304’、‘static int CONFIGURABLE_SCREEN_PARAMETER_DEVICE_Z_ORDER 1306’、‘static int CONFIGURABLE_SCREEN_PARAMETER_DISPLAY_AREA 1308’、‘static int CONFIGURABLE_SCREEN_PARAMETER_DISPLAY_SCREEN 1310’、‘static intCONFIGURABLE_SCREEN_PARAMETER_OUTPUT_PORT 1312’、‘staticint CONFIGURABLE_SCREEN_PARAMETER_SERVICE_CONTEXT1314’、‘static int CONFIGURABLE_SCREEN_PARAMETER_VISIBILITY1316’和‘static int CONFIGURABLE_SCREEN_PARAMETER_Z_ORDER1318’。
从org.ocap.ui.MultiScreenContext接口1230继承的字段1320包括‘SCREEN_TYPE_DISPLAY’和‘SCREEN_TYPE_LOGICAL’中的至少一个。
Static final int CONFIGURABLE_SCREEN_PARAMETER_AUDIO_SOURCE字段1304是确定音频源的可配置性的可配置的参数。
屏幕的音频源的配置通过使用由org.ocap.ui.MultiScreenConfigurableContext接口1210所定义的addAudioSources(..)和removeAudioSources(..)方法来完成。
如果‘org.ocap.ui.MultiScreenConfigurableContext’接口1210所引用的HScreen实例支持其音频源的配置，则isConfigurableParameter(CONFIGURABLE_SCREEN_PARAMETER_AUDIO_SOURCE)将返回true。
如果hasDiscreteParamterSpace(CONFIGURABLE_SCREEN_PARAMETER_AUDIO_SOURCE)返回true，则getDiscreteParameterSpace(CONFIGURABLE_SCREEN_PARAMETER_AUDIO_SOURCE)将返回HScreenDevice[]类型的值，其中该数组值中的每个元素是可以作为该屏幕的音频源的该屏幕的可访问屏幕装置。
CONFIGURABLE_SCREEN_PARAMETER_AUDIO_SOURCE字段1304从MSM 101起使用。
static final int CONFIGURABLE_SCREEN_PARAMETER_AUDIO_FOCUS字段1302是确定屏幕焦点的可配置性的可配置参数。
屏幕的音频焦点的配置通过使用‘org.ocap.ui.MultiScreenConfigurableContext’接口1210所定义的assignAudioFocus(..)方法来实现。
如果该接口引用的HScreen实例支持音频源的配置，则isConfigurableParameter(CONFIGURABLE_SCREEN_PARAMETER_AUDIO_FOCUS)将返回true。
如果hasDiscreteParamterSpace(CONFIGURABLE_SCREEN_PARAMETER_AUDIO_FOCUS)返回true，则getDiscreteParameterSpace(CONFIGURABLE_SCREEN_PARAMETER_AUDIO_FOCUS)将返回HScreen[]类型的值，其中该数组值中的每个元素是可以作为音频焦点屏幕的可访问屏幕。
如果该屏幕是显示屏幕，则返回的元素应该被限制为当前映射到能被分配音频焦点的显示屏幕的那些逻辑屏幕。由于显示屏幕总是可以被直接分配音频焦点(与将音频焦点分配给映射到显示屏幕的某个逻辑屏幕相对)，显示屏幕本身不包括在返回的元素中。
如果该屏幕是逻辑屏幕并且如果该逻辑屏幕映射到显示屏幕并且可以被分配音频焦点，则返回的数组应该只包含该屏幕；否则，返回的数组应该为空。
CONFIGURABLE_SCREEN_PARAMETER_AUDIO_FOCUS字段1302从MSM I01起使用。
static final int CONFIGURABLE_SCREEN_PARAMETER_DEVICE_Z_ORDER域1306是确定屏幕装置z-顺序的可配置性的可配置参数。
对屏幕的装置z-顺序的配置通过使用‘org.ocap.ui.MultiScreenContext’接口1230所定义的setZOrder(HScreenDevice[])方法来完成。
如果该接口引用的HScreen实例支持对其屏幕装置的z-顺序的配置，则isConfigurableParameter(CONFIGURABLE_SCREEN_PARAMETER_DEVICE_Z_ORDER)将返回true。
如果hasDiscreteParameterSpace(CONFIGURABLE_SCREEN_PARAMETER_DEVICE_Z_ORDER)返回true，则getDiscreteParameterSpace(CONFIGURABLE_SCREEN_PARAMETER_DEVICE_Z_ORDER)应该返回HScreenDevice[][]类型的值，其中该数组值中的每个元素是屏幕装置的数组，其顺序匹配这些屏幕装置所支持的z-顺序，其中这样的屏幕装置数组中的第一个元素是在z-顺序的最后面(即，装置z-顺序为0)。
图13C示出了‘CONFIGURABLE_SCREEN_PARAMETER_DEVICE_Z_ORDER’字段的使用情形。
在图13C中，应用下列假设：
1.屏幕具有一个背景装置B1、一个视频装置V1和两个图形装置G1和G2；并且
2.支持图形装置的两种顺序：(1)B1＜V1＜G1＜G2及(2)B1＜V1＜G2＜G1。
通过S1330确定，背景装置B1的z-顺序为0，视频装置V1的z-顺序为1，图形装置G1的z-顺序为2，且图形装置G2的z-顺序为3。
类似地，通过S1340确定，背景装置B1的z-顺序为0，视频装置V1的z-顺序为1，图形装置G2的z-顺序为2，且图形装置G1的z-顺序为3。
‘CONFIGURABLE_SCREEN_PARAMETER_DEVICE_Z_ORDER’字段1306从MSM 101起使用。
static final int CONFIGURABLE_SCREEN_PARAMETER_DISPLAY_AREA字段1308是确定屏幕关联显示区域的可配置性的可配置参数。
对(逻辑)屏幕的显示区域的配置通过使用org.ocap.ui.MultiScreenContext接口1230所定义的setDisplayArea(HScreenRectangle)方法来完成。
如果org.ocap.ui.MultiScreenConfigurableContext接口1210所引用的HScreen实例是显示屏幕，则isConfigurableParameter(CONFIGURABLE_SCREEN_PARAMETER_DISPLAY_AREA)将返回false；否则，如果该逻辑屏幕支持对其显示区域的配置，则isConfigurableParameter(CONFIGURABLE_SCREEN_PARAMETER_DISPLAY_AREA)将返回true。
如果hasDiscreteParameterSpace(CONFIGURABLE_SCREEN_PARAMETER_DISPLAY_AREA)返回true，则getDiscreteParameterSpace(CONFIGURABLE_SCREEN_PARAMETER_DISPLAY_AREA)将返回HScreenRectangle[]类型的值，其中该数组值中的每个元素是支持的显示区域。
CONFIGURABLE_SCREEN_PARAMETER_DISPLAY_AREA字段1308从MSM 101版本起使用。
‘static final int CONFIGURABLE_SCREEN_PARAMETER_DISPLAY_SCREEN’是确定屏幕关联的显示屏幕的可配置性的可配置参数。
对(逻辑)屏幕的显示屏幕的配置通过使用‘org.ocap.ui.MultiScreenContext’接口1230所定义的‘setDisplayScreen(HScreen)’来完成。
如果‘org.ocap.ui.MultiScreenConfigurableContext’接口1210所引用的‘HScreen’实例是显示屏幕，则‘isConfigurableParameter(CONFIGURABLE_SCREEN_PARAMETER_DISPLAY_SCREEN’)将返回‘true’。如果‘hasDiscreteParameterSpace(CONFIGURABLE_SCREEN_PARAMETER_DISPLAY_SCREEN)’方法返回‘true’，则‘getDiscreteParameterSpace(CONFIGURABLE_SCREEN_PARAMETER_DISPLAY_SCREEN)’将返回‘HScreen[]’类型的值，其中该数组值中的每个元素是逻辑屏幕可以映射到的可访问显示屏幕。
‘CONFIGURABLE_SCREEN_PARAMETER_DISPLAY_SCREEN’字段1310从MSM I01版本起被使用。
‘static final int CONFIGURABLE_SCREEN_PARAMETER_OUTPUT_PORT’是确定屏幕关联的输出端口的可配置性的可配置参数。
对屏幕的输出端口的配置通过使用‘org.ocap.ui.MultiScreenConfigurableContext’接口1210所定义的‘addOutputPorts(..)’和‘removeOutputPorts(..)’来完成。
如果‘org.ocap.ui.MultiScreenConfigurableContext’接口1210所引用的‘HScreen’实例支持对其视频输出端口的配置，则‘isConfigurableParameter(CONFIGURABLE_SCREEN_PARAMETER_OUTPUT_PORT’)将返回‘true’。如果‘hasDiscreteParameterSpace(CONFIGURABLE_SCREEN_PARAMETER_OUTPUT_PORT)’返回‘true’，则‘getDiscreteParameterSpace(CONFIGURABLE_SCREEN_PARAMETER_OUTPUT_PORT)’将返回‘VideoOutputPort[]’类型的值，其中该数组值中的每个元素是屏幕可以直接映射到的可访问的视频端口。
‘CONFIGURABLE_SCREEN_PARAMETER_OUTPUT_PORT’字段1312从MSM I01版本起被使用。
‘CONFIGURABLE_SCREEN_PARAMETER_SERVICE_CONTEXT’字段1314被声明为‘static final int CONFIGURABLE_SCREEN_PARAMETER_SERVICE_CONTEXT’，并且是确定屏幕关联的服务上下文的可配置性的可配置参数。
对屏幕的服务上下文的配置通过使用‘org.ocap.ui.MultiScreenConfigurableContext’接口1210所定义的‘addServiceContext(..)’和‘removeServiceContext(..)’、以及使用‘MultiScreenManager’所定义的‘swapServiceContexts(..)’和‘moveServiceContexts(..)’来完成。
如果‘org.ocap.ui.MultiScreenConfigurableContext’接口1210所引用的‘HScreen’实例支持对其服务上下文的配置，则‘isConfigurableParameter(CONFIGURABLE_SCREEN_PARAMETER_SERVICE_CONTEXT’)将返回‘true’。
如果‘hasDiscreteParameterSpace(CONFIGURABLE_SCREEN_PARAMETER_SERVICE_CONTEXT)’返回‘true’，则‘getDiscreteParameterSpace(CONFIGURABLE_SCREEN_PARAMETER_SERVICE_CONTEXT)’将返回‘ServiceContext[]’类型的值，其中该数组值中的每个元素是可以与该屏幕关联的可访问服务上下文。
‘CONFIGURABLE_SCREEN_PARAMETER_SERVICE_CONTEXT’字段1314从MSM I01版本起被使用。
‘CONFIGURABLE_SCREEN_PARAMETER_VISIBILITY’字段1316被声明为‘static final int CONFIGURABLE_SCREEN_PARAMETER_VISIBILITY’，并且是确定屏幕可见性的可配置性的可配置参数。
对屏幕可见性的配置通过使用‘org.ocap.ui.MultiScreenConfigurableContext’接口1210所定义的‘setVisible(boolean)’来完成。
如果‘org.ocap.ui.MultiScreenConfigurableContext’接口1210所引用的‘HScreen’实例支持对其可见性的配置，则‘isConfigurableParameter(CONFIGURABLE_SCREEN_PARAMETER_VISIBILITY’)将返回‘true’，而‘hasDiscreteParameterSpace(CONFIGURABLE_SCREEN_PARAMETER_VISIBILITY)’返回‘false’，表示如果可见性可以配置，则使用连续的参数空间(即，‘true’和‘false’两者)。
‘CONFIGURABLE_SCREEN_PARAMETER_VISIBILITY’字段1316从MSM I01版本起被使用。
‘static final int CONFIGURABLE_SCREEN_PARAMETER_Z_ORDER’是确定屏幕z-顺序的可配置性的可配置参数。
对屏幕z-顺序的配置通过使用‘org.ocap.ui.MultiScreenConfigurableContext’接口1210所定义的‘setZOrder(int)’来完成。
如果‘org.ocap.ui.MultiScreenConfigurableContext’接口1210所引用的‘HScreen’实例支持对其(关于其多屏幕配置中的其它屏幕的)z-顺序的配置，则‘isConfigurableParameter(CONFIGURABLE_SCREEN_PARAMETER_Z_ORDER’)将返回‘true’。
如果‘hasDiscreteParameterSpace(CONFIGURABLE_SCREEN_PARAMETER_Z_ORDER)’返回‘true’，则‘getDiscreteParameterSpace(CONFIGURABLE_SCREEN_PARAMETER_Z_ORDER)’将返回‘interger[]’类型的值，其中该数组值中的每个元素‘v’是这样的：‘v.intValue()’返回在屏幕的多屏幕配置上下文中对该屏幕所支持的‘z-顺序’
‘CONFIGURABLE_SCREEN_PARAMETER_Z_ORDER’字段1318从MSM I01版本起被使用。
从‘org.ocap.ui.MultiScreenContext’继承的‘org.ocap.ui.MultiScreenContext’字段1320继承的字段包括‘SCREEN_TYPE_DISPLAY’、‘SCREEN_TYPE_LOGICAL’。
图13D至13F示出了根据本发明的实施例的‘org.ocap.ui’包的‘MultiScreenConfigurableContext’接口的方法1350。
‘org.ocap.ui.MultiScreenContext’接口的方法1350包括下列中的至少一个：‘void addAudioSources(org.havi.ui.HScreenDevice[]devices，booleanmixWithAudioFocus)’方法1352；‘void addOutputPorts(org.ocap.hardware.videoOutputPort[]ports，boolean removeExisting)’方法1354；‘void addServiceContexts(javax.tv.service.selection.ServiceContext[]contexts，booleanassocateDefaultDevices’方法1356；‘void assignAudioFocus()’方法1358；‘Boolean checkServiceContextCompatibility(javax.tv.serviceselection.ServiceContext context)’方法1360；‘org.davic.resources.ResourceClient getClient()’方法1362；‘java.lang.Object[]getDiscreteParameterSpace(int parameter)’方法1364；‘boolean hasDiscreteParameterSpace(int parameter)’方法1366；‘boolean isConfigurableParameter(int parameter)’方法1368；‘void releaseScreen()’方法1370；‘void removeAudioSources(org.havi.ui.HScreen Device[]devices)’方法1372；‘void removeOutputPorts(org.ocap.hardware.VideoOutputPort[]ports)’方法1374；‘void removeServiceContexts(javax.tv.service.selection.ServiceContext[]contexts)’方法1376；‘void request MultiScreenConfigurationChange(MultiScreenConfiguration configuration，java.util.Dictionary serviceContextAssocations)’方法1378；‘booleanreserveScreen(org.davic.resources.ResourceClient client，java.lang.Object requestData)’方法1380；‘void setDisplayArea(org.havi.ui.HScreenRectangel rect)’方法1382；‘void setDisplayScreen(org.havi.ui.HScreen screen)’方法1384；‘void setSetMultiScreenConfiguration(MultiScreenConfiguration configuration，java.util.Dictionary serviceContextAssociations)’方法1386；‘voidsetVisible(boolean visible)’方法1388，‘void setZOrder(org.havi.ui.HScreenDevice[]devices)’方法1390；以及‘void setZOrder(int order)’方法1392。
从‘org.ocap.ui.MultiScreenContext’接口1230继承的方法1394包括下列中的至少一个：‘addMultiScreenConfigurationListener’、‘addScreenContextListener’、‘getAudioFocus’、‘getAudioSources’、‘getDisplayArea’、‘getDisplayScreen’、‘getID’、‘getMultiScreenConfiguration’、‘getMultiScreenConfigurations’、‘getMultiScreenConfigurations’、‘getOutputPorts’、‘getScreenCategory’、‘getScreenType’、‘getServiceContexts’、‘getVisible’、‘getZOrder’、‘getZOrder’、‘removeMultiScreenConfigurationListener’和‘removeScreenContextListener’。
‘isConfigurableParameter’方法1368被声明为‘booleanisConfigurableParameter(int parameter)’，并确定可配置的参数对于某个屏幕是否被平台实施支持为可配置的(相对于固定的)。
参数‘parameter’是如上定义的可配置的屏幕参数枚举值。如果平台实施支持指定的‘parameter’在该屏幕上的连续或离散的变化，则‘isConfigurableParameter’方法1368返回‘true’，否则返回‘false’。
‘isConfigurableParameter’方法1368从MSM I01版本起被使用。
‘hasDiscreteParameterSpace’方法1366被声明为‘booleanhasDiscreteParameterSpace(int parameter)’，并确定被支持的可配置参数是否具有离散或连续变化的值空间。
在当前的上下文中，‘连续’可配置的参数是指平台支持或可以近似参数值类型的所有值，而‘离散’是指只有‘getDiscreteParameterSpace()’所报告的参数值类型的特定枚举值可以被使用。
参数‘parameter’是如上定义的可配置的屏幕参数枚举值。如果平台实施支持在该屏幕上的指定‘parameter’的值类型空间中的值的离散(子)集合则‘hasDiscreteParameterSpace’方法1366返回‘true’。否则，‘hasDiscreteParameterSpace’方法1366返回‘false’，在这种情况下，值类型空间中的所有值都被支持(或近似)。
如果‘isConfigurableParameter(parameter)’方法1368返回‘false’，则‘hasDiscreteParameterSpace’方法1366产生‘java.lang.IllegalArgumentException’的异常。
‘hasDiscreteParameterSpace’方法1366从MSM I01版本起被使用。
‘getDiscreteParameterSpace’方法1364被声明为‘java.lang.Object[]getDiscreteParameterSpace(int parameter)’，并获取可配置参数的值类型空间中的值的离散(子)集合。
‘getDiscreteParameterSpace’方法1364返回的数组及数组元素的实际运行时类型应该为指定的可配置参数定义，如上通过每个可配置参数的规范给出。
除非由特定的可配置参数的定义所指示，由‘getDiscreteParameterSpace’方法1364返回的数组中的元素的顺序不在本说明书中定义，并且应该被可共同操作的应用程序认为是依赖于实施的。
在屏幕的生命期间，被支持的离散参数的集合可以基于屏幕的基本资源的动态状态而针对给定的屏幕和给定的可配置参数做改变。但是，这样的改变如果发生，不应该在完成分派‘MultiScreenConfigurationEvent.MULTI_SCREEN_CONFIGURATION_CHANGING’事件和完成分派相应的‘MultiScreenConfigurationEvent.MULTI_SCREEN_CONFIGURATION_CHANGED’事件之间的时间间隔以外发生。
参数‘parameter’是如上定义的可配置的屏幕参数枚举值。‘getDiscreteParameterSpace’方法1364返回对象实例的数组，其中每个表示平台所支持(或近似)的指定参数的离散值。
如果‘hasDiscreteParameterSpace(parameter)’方法1366返回‘false’，则‘isConfigurableParameter(parameter)’方法1368或‘getDiscrete ParameterSpace’方法1364将产生‘java.lang.IllegalArgumentException’的异常。
‘getDiscreteParameterSpace’方法1364从MSM I01版本起被使用。
‘setVisible’方法1388被声明为‘void setVisible(boolean visible)’，并设置屏幕可见性。
如果屏幕是逻辑屏幕，则屏幕被标记为可见的(如果之前是隐藏的)或被标记为隐藏的(如果之前是可见的)。如果屏幕是显示屏幕，则映射到显示屏幕的所有逻辑屏幕被标记为可见的(如果之前是隐藏的)或被标记为隐藏的(如果之前是可见的)。
参数‘visible’是Boolean值，表示逻辑‘HScreen’或映射到该显示屏幕的逻辑屏幕应该在其关联的显示‘HScreen’上被设为可见或隐藏(不可见)。
如果调用的线程没有被授予‘MonitorAppPermission(“multiscreen.context”)’的权限，则‘setVisible’方法1388产生‘java.lang.SecurityException’的异常。
如果‘HScreen’的可见性不能被改变，例如，如果平台使用永久可见性设置，则‘setVisible’方法1388产生‘java.lang.IllegalArgumentException’的异常。
‘setVisible’方法1388从MSM I01版本起被使用。
‘setZOrder(int)’方法1392被声明为‘void setZOrder(int order)’，它设置屏幕的‘z-顺序’。
‘setZOrder(int)’方法1392引起逻辑‘HScreen’改变它在映射到相同显示‘HScreen’的其它逻辑‘HScreen’中的‘z-顺序’。
参数‘order’是正整数，表示要分配给该逻辑‘HScreen’的新的‘z-顺序’。
如果调用的线程没有被授予‘MonitorAppPermission(“multiscreen.context”)’的权限，则‘setZOrder(int)’方法1392产生‘java.lang.SecurityException’的异常。如果‘HScreen’的类型不是‘SCREEN_TYPE_LOGICAL’或者如果‘HScreen’的‘z-顺序’不能被改变，例如如果平台使用永久的‘z-顺序’设置，则‘setZOrder(int)’方法1392产生‘java.lang.IllegalArgumentException’的异常。
‘setZOrder(int)’方法1392从MSM I01版本起被使用。
‘setZOrder(HScreenDevice[])’方法1390被声明为‘void setZOrder(org.havi.ui.HScreenDevice[]devices)’，并为屏幕装置的集合为该屏幕内的屏幕装置设置‘z-顺序’。
‘setZOrder(HScreenDevice[])’方法1390自动设置指定的‘HScreenDevice’集合的‘z-顺序’，其中下列限制被使用：
-如果‘HBackgroundDevice’在指定的装置集合中存在，则(i)‘HBackgroundDevice’在该装置集合中包含的任何‘HVideoDevice’之前，并且(ii)它在装置集合包含的任何‘HGraphicsDevice’之前。
-如果‘HVideoDevice’在指定的装置集合中存在，则‘HVideoDevice’在装置集合包含的任何‘HGraphicsDevice’之前。
如果‘setZOrder(HScreenDevice[])’方法没有引起任何异常，则指定的‘HScreen Device’实例的集合将被排序，从而‘MultiScreenContext.getZOrder(HScreenDevice)’在该屏幕上以任何指定装置被调用时，将返回保存指定装置的相对顺序的‘z-顺序’索引。
如果比与该屏幕关联的‘HScreenDevice’实例的整个集合少的(实例)在参数‘device’中被提供，则未指定的装置相对于指定的装置的相对顺序没有被定义，除了由‘MultiScreenContext.getZOrder(HScreenDevice)’定义的限制应该在返回‘getZOrder(HScreenDevice[])’方法1390之后被应用到该屏幕中所有的装置排序。
参数‘devices’是与该屏幕关联的‘HScreenDevices’实例的有序数组。
如果调用的线程没有被授予‘MonitorAppPermission(“multiscreen.context”)’的权限，则‘setZOrder(HScreenDevices[]’方法1390产生‘java.lang.SecurityException’的异常。
如果‘device’装置不是该屏幕的‘HScreenDevice’，则‘setZOrder(HScreenDevices[]’方法1390产生‘java.lang.IllegalArgumentException的异常。
当(i)指定的‘HScreenDevice’的‘z-顺序’不能被改变，例如，平台对该屏幕中的屏幕装置使用永久的‘z-顺序’设置；或者(ii)如果指定装置的顺序不允许分配满足上述限制的‘z-顺序’索引，则‘setZOrder(HScreenDevices[])’方法1390应该产生‘java.lang.IllegalStateException’的异常。
‘setZOrder(HScreenDevices[]’方法1390从MSM I01版本起被使用。
‘addAudioSources’方法1352被声明为‘void‘addAudioSources(org.havi.ui.HScreenDevice[]devices，boolean mixWithAudioFocus)，并为该屏幕添加一个或更多个音频源。‘addAudioSources’方法1352将一个或更多个‘HScreenDevice’实例加到音频源的集合，展示的音频从该集合中选择(和混合)，用于从该屏幕音频展示的目的。
如果指定的音频源已经被指定为该屏幕的音频源，但‘mixWithAudioFocus’不同于在它被加为音频源时所指定的，则新的‘mixWithAudioFocus’值被使用。
参数‘devices’是‘HScreenDevice’实例的非空集合，其中每个‘HScreenDevice’实例对来自该屏幕的混合音频展示有贡献。
如果参数‘mixWithAudioFocus’是‘true’，则指定的屏幕装置贡献与该屏幕(直接或间接)关联的任意视频输出端口关联的任意音频输出的音频或混合音频，无论该屏幕是否被分配了音频焦点。如果参数‘mixWithAudioFocus’是‘false’，则只有在该屏幕被分配了音频焦点时指定的屏幕才贡献音频。
如果调用的线程没有被授予‘MonitorAppPermission(“multiscreen.context”)’的权限，则‘addAudioSources’方法1352产生‘java.lang.SecurityException’的异常。
如果参数‘devices’不是非空数组或者‘devices’中某个元素不是该屏幕的‘HScreenDevice’，则‘addAudioSources’方法1352产生‘java.lang.IllegalArgumentException’的异常。
当(i)用于该‘HScreenDevice’的音频源不能被改变，例如，当平台对该屏幕的屏幕装置使用永久的音频源装置，或者(ii)当多个音频源被指定，而音频混合不被支持，则‘addAudioSources’方法1352将产生‘java.lang.Illegal StateException’的异常。
‘addAudioSources’方法1352从MSM I01版本起被使用。
‘removeAudioSources’方法1372被声明为‘void removeAudioSources(org.havi.ui.HScreenDeviee[]devices)’，并移除一个或更多个音频源。‘removeAudioSources’方法1372从该‘HScreen’的音频源集合中移除特定‘HScreenDevice’实例的所有或某个非空集合。如果‘devices’具有‘null’值，则所有音频源都被移除。
参数‘devices’表示“null”值或‘HScreenDevice’实例的非空集合。
如果调用的线程没有被授予MonitorAppPermission(“multiscreen.context”)’的权限，则‘removeAudioSources’方法1372产生‘java.lang.SecurityException’的异常。
如果‘devices’不是null并且某个‘HScreenDevice’元素不与该‘HScreen’实例关联，则‘removeAudioSources’方法1372产生‘java.lang.IllegalArgumentException’的异常。
如果用作该‘HScreen’的音频源的指定‘HScreenDevice’不能被改变，例如，如果平台使用音频源与指定‘HScreenDevice’的永久关联，则‘removeAudioSources’方法1372应该产生‘java.lang.IllegalStateException’的异常。
‘removeAudioSources’方法1372从MSM I01版本起被使用。
‘assignAudioFocus’方法1358被声明为‘void assignAudioFocus()’，并将音频焦点分配给该屏幕。
在任意给定时间，显示屏幕应该将音频焦点分配给它自己或映射到它(显示屏幕)的正好一个逻辑屏幕。当音频焦点被新分配给显示屏幕的逻辑屏幕，并且逻辑屏幕当前没有音频焦点被分配给它，则音频焦点应该从映射到显示屏幕的任何其它逻辑屏幕上移除，并改为分配给新分配的逻辑屏幕。
如果没有逻辑屏幕映射到给定的显示屏幕，或者没有一个映射到给定显示屏幕的逻辑屏幕被分配了音频焦点，则显示屏幕应该(默认地)将音频焦点分配给自己。音频焦点可以通过显示屏幕实例上的‘assignAudioFocus’方法1358显式地分配给显示屏幕。
显示屏幕的音频焦点屏幕是这样的屏幕，其当前选择的音频源被分配以便在显示屏幕所映射到的所有视频输出端口的所有(隐含的)音频展示装置上呈现。如果音频焦点所分配的屏幕没有音频源，即，如果它具有音频源的空集合，则(如OCAP平台所产生或潜在地产生的)音频不应该在显示屏幕所映射到的所有视频输出端口的任何(隐含的)音频展示装置上呈现。
每个单独的显示屏幕可以具有不同的逻辑屏幕，音频源被分配到该逻辑屏幕，用于在显示屏幕(及其映射的逻辑屏幕的集合)上呈现音频的目的。
如果调用的线程没有被授予‘MonitorAppPermission(“multiscreen.context”)’的权限，则‘assignAudioFocus’方法1358产生‘java.lang.SecurityException’的异常。
如果分配给该‘HScreen’的音频焦点或当前的音频焦点不能被改变，则‘assignAudioFocus’方法1358产生‘java.lang.IllegalStateException’的异常。
‘assignAudioFocus’方法1358从MSM I01版本起被使用。
‘addOutputPorts’方法1354被声明为‘void addOutputPorts(org.ocap.hardware.VideoOutputPort[]ports，boolean removeExisting)’，并添加屏幕所映射的一个或更多个视频输出端口。
如果‘HScreen’是逻辑屏幕而不是显示屏幕，则为了映射到指定的视频输出端口的目的，‘HScreen’应该被认为起到与显示屏幕一样的作用。即，逻辑屏幕好像自然是主显示屏幕一样被对待。
参数‘ports’是‘VideoOutputPort’实例的非空数组。如果参数‘removeExisting’是‘true’值，则与已有的屏幕的关联(如果这样的关联存在)应该在被加到新的屏幕之前被移除。
如果调用的线程没有被授予‘MonitorAppPermission(“multiscreen.context”)’的权限，则‘addOutputPorts’方法1354产生‘java.lang.SecurityException’的异常。
当(i)指定的‘VideoOutputPort’已经和不同的‘HScreen’关联并且‘removeExisting’不是‘true’，(ii)由于平台的特定硬件限制，该‘HScreen’不能被映射到某个指定的‘VideoOutputPort’，以及(iii)当该‘HScreen’所映射到的‘VideoOutputPort’实例的集合不能被改变，例如，当平台使用与特定的‘VideoOutputPort’实例集合的永久关联时，‘addOutputPorts’方法1354产生‘java.lang.IllegalStateException’的异常。
‘addOutputPorts’方法1354从MSM I01版本起被使用。
‘removeOutputPorts’方法1374被声明为‘void removeOutputPorts(org.ocap.hardware.VideoOutputPort[]ports)’，并移除屏幕所映射到的一个或更多个视频输出端口。‘removeOutputPorts’方法1374从‘HScreen’所映射到的视频输出端口集合中移除特定‘VideoOutputPort’实例中的所有或某个非空集合。如果参数‘ports’是‘null’，则所有视频输出端口关联都被移除。
参数‘ports’是‘null’或者‘VideoOutputPort’实例的非空数组。
如果调用的线程没有被授予‘MonitorAppPermission(“multiscreen.context”)’的权限，则‘removeOutputPorts’方法1374产生‘java.lang.SecurityException’的异常。
如果‘ports’不是null，并且某个‘VideoOutputPort’元素不与该‘HScreen’实例关联，则‘removeOutputPorts’方法1374产生‘java.lang.IllegalArgumentException’的异常。
如果用于该‘HScreen’的指定‘VideoOutputPort’不能被改变，例如，如果平台使用与指定‘VideoOutputPort’的永久关联，则‘removeOutputPorts’方法1374应该产生‘java.lang.IllegalStateException’的异常。
‘removeOutputPorts’方法1374从MSM I01版本起被使用。
‘setDisplayScreen’方法1384被声明为‘void setDisplayScreen(org.havi.ui.HScreen screen)’，并将逻辑屏幕与显示屏幕关联。即，‘setDisplayScreen’方法1384将该逻辑‘HScreen’与显示‘HScreen’关联。
参数‘screen’是显示‘HScreen’实例或null。如果参数‘screen’是null，‘setDisplayScreen’方法1384被执行而没有异常，并且参数‘screen’被返回，则逻辑‘HScreen’不再与显示‘HScreen’关联。
如果调用的线程没有被授予‘MonitorAppPermission(“multiscreen.context”)’的权限，则‘setDisplayScreen’方法1384产生‘java.lang.SecurityException’的异常。
当‘HScreen’的类型不是‘SCREEN_TYPE_LOGICAL’，(ii)指定的‘screen’不是‘null’，并且其屏幕类型不是‘SCREEN_TYPE_DISPLAY’，或者(iii)与该逻辑‘HScreen’关联的显示‘HScreen’不能被改变，例如，当平台使用与特定显示‘HScreen’的永久关联时，‘setDisplayScreen’方法1384产生‘java.lang.IllegalStateException’的异常。
‘setDisplayScreen’方法1384从MSM I01版本起被使用。
‘setDisplayArea’方法1382被声明为‘void setDisplayArea(org.havi.ui.HScreenRectangle rect)’，并将显示屏幕的区域设置为逻辑屏幕所映射的区域。即，方法1382将逻辑HScreen与它所关联的显示HScreen的区域(范围)关联。
参数‘rect’是HScreenRectangle实例，表示在显示HScreen上与该逻辑HScreen关联的区域，其应该对应于该逻辑屏幕的范围。
如果调用的线程没有被授予‘MonitorAppPermission(“multiscreen.context”)’的权限，则‘setDisplayArea’方法1382产生‘java.lang.SecurityException’的异常。
如果(1)该HScreen类型不是SCREEN_TYPE_LOGICAL，或者(2)如果与该逻辑HScreen关联的显示HScreen的区域不能被改变，例如，如果平台使用与与所关联的特定区域的永久关联，则‘setDisplayArea’方法1382产生‘java.lang.IllegalStateException’的异常。
‘setDisplayArea’方法1382从MSM I01版本起被使用。
‘checkServiceContextCompatibility’方法1360被声明为‘booleancheckServiceContextCompatibility(javax.tv.service.selection.ServiceContextcontext)’，并且测试服务上下文与屏幕的兼容性。即，‘checkServiceContextCompatibility’方法1360确定应用程序是否可以将ServiceContext分配给该HScreen，以及指定的ServiceContext是否与该HScreen上的展示兼容。
参数‘context’是有效的‘ServiceContext’实例。
‘checkServiceContextCompatibility’方法1360返回布尔值，表示指定的ServiceContext实例是否可以被分配给HScreen。如果指定的ServiceContext可以被分配，则返回‘true’；否则，返回‘false’。
如果调用的线程没有被授予‘MonitorAppPermission(“multiscreen.context”)’的权限，则‘checkServiceContextCompatibility’方法1360产生‘java.lang.SecurityException’的异常。
如果指定的‘ServiceContext’不是有效的，则‘checkServiceContextCompatibility’方法1360产生‘java.lang.IllegalArgumentException’的异常。
‘checkServiceContextCompatibility’方法1360从MSM I01版本起被使用。
‘addServiceContexts’方法1356被声明为‘void‘addServiceContexts(javax.tv.service.selection.ServiceContext[]contexts，boolean associateDefaultDevices)’，并将服务上下文加到该屏幕。即，‘addServiceContexts’方法1356将一个或更多个ServiceContext实例加到与该HScreen关联的服务上下文的集合，以便允许来自这些服务上下文实例的背景、视频和图形内容在HScreen的各个屏幕装置上展示。
如果指定的服务上下文已经与‘org.ocap.ui.MultiScreenContext’接口所表示的基本屏幕关联，则服务上下文不会与该屏幕多次关联，而已有的关联保持不变。即，给定的服务上下文应该与给定的(基本)屏幕关联一次或根本不关联。
如果两个或更多个非抽象服务上下文与给定的屏幕关联，并且来自这些多个非抽象服务上下文的基于背景的播放器的多个视频源与给定屏幕的给定HVideoDevice实例关联，则来自这些多个服务上下文的、其视频内容要被显示的基于背景的播放器根据下列有序的规则被确定：
1.如果关联的非抽象服务上下文中的一个所拥有的应用程序占据对屏幕的给定HVideoDevice的保留，则来自该服务上下文的基于背景的播放器被指定为在该视频装置在展示；以及
2.否则，其应用程序被分配了最高优先级的、关联的非抽象服务上下文的基于背景的播放器被指定为在该视频装置上展示。
如果，在应用上面的规则之后，给定应用程序的多个基于背景的播放器被指定为在视频装置上展示，则最近启动的播放器被给予视频展示的优先级。
参数‘contexts’是‘ServiceContext’实例的非空数组，如果参数‘associateDefaultDevices’是‘true’，则该屏幕的默认屏幕装置与当前与指定ServiceContext实例关联的所有ServiceMediaHandler关联。如果参数‘associateDefaultDevice’是‘false’，则不执行该默认屏幕装置的关联。
如果调用的线程没有被授予‘MonitorAppPermission(“multiscreen.context”)’的权限，则‘addServiceContexts’方法1356产生‘java.lang.SecurityException’的异常。
如果用于该HScreen的指定的ServiceContext不能被改变，例如，如果平台使用与特定ServiceContext的永久关联，则‘addServiceContexts’方法1356产生‘java.lang.IllegalStateException’的异常。
‘addServiceContexts’方法1356从MSM I01版本起被使用。
‘removeContextContexts’方法1376被声明为‘void removeServiceContext(javax.tv.service.selection.ServiceContext[]contexts)’，并从屏幕移除服务上下文。即，‘removeContextContexts’方法1376从与该HScreen关联的服务上下文的集合中移除所有或某个非空集合的特定ServiceContext实例。如果contexts是‘null’，则所有服务上下文都被移除。
参数‘contexts’是‘null’或‘ServiceContext’实例的非空数组。
如果调用的线程没有被授予‘MonitorAppPermission(“multiscreen.context”)’的权限，则‘removeContextContexts’方法1376产生‘java.lang.SecurityException’的异常。
如果contexts不是‘null’，并且某个ServiceContext元素不与该HScreen实例关联，则‘removeContextContexts’方法1376产生‘java.lang.IllegalArgumentException’的异常。
如果ServiceContext不能被改变，例如，如果平台使用与特定ServiceContext的永久关联，则‘removeContextContexts’方法1376产生‘java.lang.IllegalStateException’的异常。
‘removeContextContexts’方法1376从MSM I01版本起被使用。
‘setMultiScreenConfiguration’方法1386被声明为‘void setMultiScreenConfiguration(MultiScreenConfiguration configuration，java.util.DictionaryserviceContextAssociations)’，并为该显示屏幕设置当前活动的多屏幕配置。即，可以与该显示屏幕关联的逻辑屏幕子集的集合中的一个在指定的时间被选择。
如果指定的configuration是用于该显示屏幕的当前配置，则，除非使用SecurityException，则从‘setMultiScreenConfiguration’方法1386返回值而不产生任何副作用。
如果指定的configuration不是用于该显示屏幕的当前配置，并且不使用SecurityException、IllegalStateException和IllegalArgumentException，则本说明书中定义的同步显示多屏幕配置改变过程被执行。
如果参数serviceContextAssocations被指定(即，如果它不是null)，则可以访问调用的应用程序的任何ServiceContext实例应该不与屏幕关联或与指定的(新)多屏幕配置中的可应用屏幕关联。如果没有关联与某个可访问的ServiceContext匹配，如果某个可访问的ServiceContext实例不在指定的关联中存在，或者如果它存在但没有这样的可应用屏幕在新的多屏幕配置中存在，则ServiceContext实例应该与指定的多屏配置的默认服务上下文关联进行关联，即，configuration.getDefaultContextScreen()所返回的屏幕。
为了匹配可访问ServiceContext实例，该实例的引用在指定的serviceContextAssociations字典中作为关键字出现，这些关键字上的虚方法equals(Object)将被使用，在这种情况下，假设‘setMultiScreenConfiguration’方法1386与Object.equals(Object)的默认实现一样地表现。
在给定应用实例的上下文中，MSM主机实施应该在暴露给该应用程序的ServiceContext实例和基本服务上下文资源集合之间保持一对一的关系。如果MSM主机实施不能保持该关系，则当查询serviceContextAssociation字典时，MSM实施将认为两个不同的基本服务上下文资源集合是同一个服务上下文，例如，如果在不同的时间，单个ServiceContext实例引用资源的不同的基本集合。同时，MSM实施可以认为单个基本服务上下文资源集合是两个不同的服务上下文，例如，如果在给定的时间，两个不同的ServiceContext实例引用了资源的相同的基本集合。
视频管线的解码器格式转换(DFC)组件的状态不会受‘setMultiScreenConfiguration’方法1386的执行的影响，该视频管线被用来处理与服务上下文关联的视频，该服务上下文由‘setMultiScreenConfiguration’方法1386在屏幕之间隐式地交换或移动。
参数‘configuration’是要成为该显示屏幕的当前活动每显示多屏幕配置的MultiScreenConfiguration实例。如果参数‘serviceContextAssociation’不是null，它是这样的Dictionary实例，其关键字是ServiceContext实例，并且其值是String实例，其中该字符串值定义如下：(1)如果字符串值是“-”，则没有屏幕被应用(在这种情况下，在配置改变后匹配的服务上下文没有与任何屏幕关联)，(2)否则，如果字符串值是“*”，则新屏幕配置的所有屏幕被应用，(3)否则，如果字符串值是如MultiScreenContext.getID()返回的屏幕标志符，则该屏幕被应用，(4)否则，如果字符串值是如MultiScreenContext.getScreenCategory()返回的屏幕分类，则新配置的任何该分类的屏幕被应用，(5)否则，如果字符串值是用分号分隔的屏幕标志符的列表，则新配置的每个具有匹配标志符的屏幕被应用，(6)否则，如果字符串值是用分号分隔的屏幕分类的列表，则新配置的每个具有匹配分类的屏幕被应用，(7)否则，如果字符串值是用分号分隔的屏幕标志符或屏幕分类的列表，则新配置的每个具有匹配标志符或分类的屏幕被使用，并且(8)否则，新配置的默认服务上下文关联屏幕被应用。
如果调用的线程没有被授予‘MonitorAppPermission(“multiscreen.configuration”)’的权限，则‘setMultiScreenConfiguration’方法1386产生‘java.lang.SecurityException’的异常。
如果参数‘configuration’不是如MultiScreenContext.getMultiScreenConfigurations()所返回的该(显示)屏幕的多屏幕配置中的一个，则‘setMultiScreenConfiguration’方法1386产生‘java.lang.IllegalArgumentException’的异常。
(1)如果MSM实施不允许指定的多屏幕配置的激活，(2)如果‘setMultiScreenConfiguration’方法1386之前被调用了，并且改变处理的步骤还没有完成，或者(3)如果否则在方法调用的时刻激活不被允许，则‘setMultiScreenConfiguration’方法1386产生‘java.lang.IllegalStateException’的异常。
‘setMultiScreenConfiguration’方法1386从MSM I01版本起被使用。
‘requestMultiScreenConfigurationChange’方法1378被声明为‘voidrequestMultiScreenConfigurationChange(MultiScreenConfigurationconfiguration，java.util.Dictionary serviceContextAssociations)’，并请求该显示屏幕的当前活动的多屏幕配置被改变。
如果指定的configuration是该显示屏幕的当前配置，则除非使用SecurityException，从‘requestMultiScreenConfigurationChange’方法1378返回值而不产生任何副作用。
如果指定的configuration不是当前的显示配置，并且如果不使用‘SecurityException’、‘IllegalArgumentException’和‘IllegalStateException’，则对当前多屏幕配置的异步改变被初始化，其中setMultiScreenConfiguration()的语义被使用，除了该方法将在MultiScreenConfiguration.MULTI_SCREEN_CONFIGURATION_CHANGING产生之后(但在被分派之前)立即返回。
参数‘configuration’是要成为当前活动的屏幕配置的‘MultiScreenConfiguration’实例。
参数‘serviceContextAssociation’是‘null’或这样的Dictionary实例，其关键字是ServiceContext实例，并且其值是String实例，基于如上由setMultiScreenConfiguration所定义的语义。
如果调用的线程没有被授予‘MonitorAppPermission(“multiscreen.configuration”)’的权限，则‘requestMultiScreenConfigurationChange’方法1378产生‘java.lang.SecurityException’的异常。
如果参数‘configuration’不是如MultiScreenContext.getMultiScreenConfigurations()所返回的该(显示)屏幕的多屏幕配置中的一个，‘requestMultiScreenConfigurationChange’方法1378产生‘java.lang.IllegalArgumentException’的异常。
如果屏幕不是显示屏幕，或者(1)如果MSM实施不允许激活指定的多屏幕配置，(2)如果‘setMultiScreenConfiguration’方法1378之前被调用，且改变过程的步骤还没有完成，或者(3)如果否则在方法被调用的时刻激活不被允许，则‘setMultiScreenConfiguration’方法1378产生‘java.lang.IllegalStateException’的异常。
‘requestMultiScreenConfigurationChange’方法1378从MSM I01版本起被使用。
‘getClient’方法1362被声明为‘org.davic.resources.ResourceClientgetClient()’，并获取这样的资源客户端，其当前保留了与该HScreen实例关联的基本屏幕和屏幕资源。
‘getClient’方法1362也由‘org.davic.resources.ResourceProxy’接口的‘getClient’指定。
‘getClient’方法1362返回ResourceClient实例或返回‘null’，如果与该HScreen关联的基本屏幕和屏幕资源没有被保留。
‘getClient’方法1362从MSM I01版本起被使用。
‘reserveScreen’方法1380被声明为‘boolean reserveScreen(org.davic.resources.ResourceClient client，java.lang.Object requestData)’，并在原子级保留该屏幕的基本资源。
如果保留屏幕应被认为等价于保留与该屏幕相关的所有HScreenDevice实例，除了当使用‘reserveScreen’方法1380来保留屏幕，在没有首先释放所有HScreenDevice实例和该屏幕的所有基本屏幕资源时，不应该释放单独的HScreenDevice实例。
如果在保留屏幕时，屏幕的某个HScreenDevice已经被另一个应用程序保留，则在将保留授予屏幕前，该保留必须被(MSM实施)成功地释放。如果保留没有或不能被释放，则尝试保留屏幕将失败。即，‘reserveScreen’方法1380将返回‘false’。
如果在保留屏幕时，屏幕的某个HScreenDevice已经被保留的应用程序保留，则该保留将被整个屏幕的成功保留隐式地包含。
如果使用‘reserveScreen’方法1380来保留屏幕的尝试成功，即‘reserveScreen’方法1380返回‘true’，则屏幕的所有HScreenDevice实例的getClient()将返回和‘org.ocap.ui.MultiScreenConfigurableContext’接口1210所定义的getClient()方法1362相同的值(如HScreen的具体实现所实现)。
如果该屏幕之前未保留且‘reserveScreen’方法1380的调用使得该屏幕被保留，则在从‘reserveScreen’方法1380返回之前，将产生MultiScreenResourceEvent.MULTI_SCREEN_RESOURCE_SCREEN_RESERVED事件。
如果调用的应用程序已经拥有对该屏幕的保留，并且如果指定的client和requestData参数和调用的应用程序之前被授予保留时指定的那些参数一样，则‘reserveScreen’方法1380将没有副作用并返回‘true’。但是，如果调用的应用程序已经拥有对该屏幕的保留，但指定的client或requestData参数不同于在调用的应用程序之前被授予保留时指定的那些参数，则(1)指定的client和requestData参数将被之前指定的那些参数替换，(2)调用的应用程序将保持该保留，并且(3)‘reserveScreen’方法1380将返回‘true’。
参数‘client’是‘ResourceClient’实例。参数‘requestData’是‘null’或者实现java.rmi.Remote接口的Object实例。
如果屏幕的基本资源被成功保留，‘reserveScreen’方法1380返回‘true’，否则返回‘false’。
‘reserveScreen’方法1380从MSM I01版本起被使用，并且‘Remote’被涉及。
‘releaseScreen’方法1370被声明为‘void releaseScreen()’，并在原子级上释放屏幕的基本资源。
如果调用的应用程序没有对该屏幕的保留，则‘releaseScreen’方法1370不会有任何副作用。
如果屏幕之前被保留了，且‘releaseScreen’方法1370的调用使得屏幕不再被保留(即，未保留)则在从‘releaseScreen’方法1370返回值之前，将产生MultiScreenResourceEvent.MULTI_SCREEN_RESOURCE_SCREEN_RELEASED事件。
‘releaseScreen’方法1370从MSM I01版本起被使用。
图14A示出了根据本发明的实施例的‘org.ocap.ui’包的‘MultiScreenConfiguration’接口的定义。
‘MultiScreenConfiguration’接口被声明为‘public interface MultiScreenConfiguration’。
由OCAP主机平台实现的MultiScreenConfiguration接口提供关于离散屏幕配置的信息，以及监控屏幕配置改变的机制。
MSM实施应支持配置类型为SCREEN_CONFIGURATION_DISPLAY的至少一个多屏幕配置。
MSM实施应支持配置类型为SCREEN_CONFIGURATION_NON_PIP的至少一个多屏幕配置。
如果MSM实施实现PIP功能，并允许在OCAP操作期间的PIP屏幕展示，则MSM实施应支持多屏幕配置SCREEN_CONFIGURATION_PIP。
如果MSM实施实现POP功能，并允许在OCAP操作期间的POP屏幕展示，则MSM实施应支持多屏幕配置SCREEN_CONFIGURATION_POP。
如果MSM实施在离散配置中实现PIP、POP或OVERLAY功能，该离散配置在下面没有被非一般多屏幕配置显式地指定，则MSM实施应支持表示每个这样的多屏幕配置的SCREEN_CONFIGURATION_GENERAL配置类型的一个或更多个多屏幕配置。
‘org.ocap.ui’包的‘MultiScreenConfiguration’接口1220从MSM I01版本起被使用。
图14B示出了根据本发明的实施例的‘org.ocap.ui’包的‘MultiScreenConfiguration’接口的字段1400。
‘org.ocap.ui’包的‘MultiScreenConfiguration’接口的字段1400包括下列中的至少一个：‘static java.lang.String SCREEN_CATEGORY_DISPLAY’字段1402、‘static java.lang.String SCREEN_CATEGORY_GENERAL’字段1404、‘static java.lang.String SCREEN_CATEGORY_MAIN’字段1406、‘static java.lang.String SCREN_CATEGORY_NONE’字段1408、‘static java.lang.String SCREEN_CATEGORY_OVERLAY’字段1410、‘static java.lang.String SCREEN CATEGORY_PIP’字段1412、‘staticjava.lang.String SCREEN_CATEGORY_POP’字段1414、‘static java.lang.String SCREEN_CONFIGURATION_DISPLAY’字段1416、‘static java.lang.String SCREEN_CONFIGURATION_GENERAL’字段1418、‘static java.lang.String SCREEN_CONFIGURATION_NON_PIP’字段1420、‘static java.lang.String SCREEN_CONFIGURATION_PIP’字段1422，以及‘static java.lang.String SCREEN_CONFIGURATION_POP’字段1424。
‘SCREEN_CONFIGURATION_DISPLAY’字段1416被声明为‘staticjava.lang.String SCREEN_CONFIGURATION_DISPLAY’。如果‘MultiScreenConfiguration’与一个或更多个显示屏幕关联，并且是被用作每平台多屏幕配置的候选者，则该配置类型是SCREEN_CONFIGURATION_DISPLAY字段1416。
SCREEN_CONFIGURATION_DISPLAY字段1416的配置类型的初始默认屏幕应是getScreens(SCREEN_CATEGORY_MAIN)返回的第一个屏幕。如果在配置中没有这样分类的屏幕，则SCREEN_CONFIGURATION_DISPLAY字段1416的配置类型的初始默认屏幕应是getScreens()返回的第一个屏幕。
‘SCREEN_CONFIGURATION_DISPLAY’字段1416从MSM I01版本起被使用。
‘SCREEN_CONFIGURATION_NON_PIP’字段1420被声明为‘staticfinal java.lang.String SCREEN_CONFIGURATION_NON_PIP’。如果MultiScreenConfiguration正好与一个分类为SCREEN_CATEGORY_MAIN的屏幕关联，则其配置类型为SCREEN_CONFIGURATION_NON_PIP。
SCREEN_CONFIGURATION_NON_PIP字段1420的配置类型的初始默认屏幕应是getScreens(SCREEN_CATEGORY_MAIN)返回的第一个屏幕。
被分类为具有SCREEN_CONFIGURATION_NON_PIP字段1420的配置类型的MultiScreenConfiguration实例不应包含多于一个的显示屏幕。
‘SCREEN_CONFIGURATION_NON_PIP’字段1420从MSM I01版本起被使用。
‘SCREEN_CONFIGURATION_PIP’字段1422被声明为‘static finaljava.lang.String SCREEN_CONFIGURATION_PIP’。如果MultiScreenConfiguration(1)与映射到单个显示屏幕的整个区域、具有默认值为0的z-顺序的一个逻辑屏幕关联，并且(2)与映射到同一显示屏幕的具有默认值为1的z-顺序的一个或更多个非交叉逻辑屏幕关联，则其配置类型为SCREEN_CONFIGURATION_PIP字段1422。
SCREEN_CONFIGURATION_PIP字段1422的配置类型的初始默认屏幕应是getScreens(SCREEN_CATEGORY_MAIN)返回的第一个屏幕，或者，如果在配置中没有屏幕被分类作为SCREEN_CATEGORY_MAIN字段1406，则SCREEN_CONFIGURATION_PIP字段1422的配置类型的初始默认屏幕应是getScreens()返回的第一个屏幕。
被分类为具有SCREEN_CONFIGURATION_PIP字段1422的配置类型的MultiScreenConfiguration实例不应包含多于一个的显示屏幕。
‘SCREEN_CONFIGURATION_PIP’字段1422从MSM I01版本起被使用。
‘SCREEN_CONFIGURATION_POP’字段1424被声明为‘static finaljava.lang.String SCREEN_CONFIGURATION_POP’。如果MultiScreenConfiguration与具有默认值为0的z-顺序、其默认显示区字段(一起)平铺(tile)单个显示屏幕的整个区域的两个或更多个非交叉逻辑屏幕关联，则其配置类型为SCREEN_CONFIGURATION_POP字段1424。
SCREEN_CONFIGURATION_POP字段1424的配置类型的初始默认屏幕应是getScreens(SCREEN_CATEGORY_POP)返回的第一个屏幕，或者，如果在配置中没有屏幕被分类作为SCREEN_CATEGORY_POP字段1414，则SCREEN_CONFIGURATION_POP字段1424的配置类型的初始默认屏幕应是getScreens()返回的第一个屏幕。
被分类为具有SCREEN_CONFIGURATION_POP字段1424的配置类型的MultiScreenConfiguration实例不应包含多于一个的显示屏幕。
‘SCREEN_CONFIGURATION_POP’字段1424从MSM I01版本起被使用。
‘SCREEN_CONFIGURATION_GENERAL’字段1418被声明为‘staticfinal java.lang.String SCREEN_CONFIGURATION_GENERAL’。如果MultiScreenConfiguration不能被分类作为其它预定的屏幕配置类型中的一种，则其配置类型为SCREEN_CONFIGURATION_GENERAL字段1418。
SCREEN_CONFIGURATION_GENERAL字段1418的配置类型的初始默认屏幕应是getScreens(SCREEN_CATEGORY_POP)返回的第一个屏幕。如果在配置中没有屏幕被分类作为SCREEN_CATEGORY_GENERAL字段1404，则SCREEN_CONFIGURATION_GENERAL字段1418的配置类型的初始默认屏幕应是getScreens()返回的第一个屏幕。
被分类为具有SCREEN_CONFIGURATION_GENERAL字段1418的配置类型的MultiScreenConfiguration实例不应包含多于一个的显示屏幕。
‘SCREEN_CONFIGURATION_GENERAL’字段1418从MSM I01版本起被使用。
‘SCREEN_CATEGORY_NONE’字段1408被声明为‘static finaljava.lang.String SCREEN_CATEGORY_NONE’。如果HScreen实例不与其它任何更为特定的分类关联，则其分类为SCREEN_CATEGORY_NONE字段1408。
被分类为具有SCREEN_CATEGORY_NONE的配置类型的MultiScreenConfiguration实例不应包含多于一个的屏幕。
‘SCREEN_CATEGORY_NONE’字段1408从MSM I01版本起被使用。
‘SCREEN_CATEGORY_DISPLAY’字段1402被声明为‘static final java.lang.String SCREEN_CATEGORY_DISPLAY’。如果显示HScreen实例被定性为非主屏幕，则其类型为SCREEN_CATEGORY_DISPLAY字段1402。分配了该分类的显示屏幕不应该被HBackgroundDevice或HVideoDevice构成(populated)，但可以被作为覆盖的一个或更多个HGraphicsDevice实例构成。
被分类为SCREEN_CATEGORY_DISPLAY字段1402的显示HScreen实例具有例外的属性：如果存在任何HGraphicsDevice实例，则其应覆盖映射到显示屏幕的所有逻辑屏幕。该属性不应保持，即使MultiScreenContext.getZOrder()对任何显示屏幕都返回‘0’。
上述例外属性旨在支持(1)过时(legacy)装置的情形，其中隐藏字幕覆盖在所有其它内容上出现，以及(2)配置，其中覆盖屏幕被认为是显示屏幕的集成HGraphicsDevice，而不是将覆盖屏幕作为分离的逻辑屏幕。
‘SCREEN_CATEGORY_DISPLAY’字段1402从MSM I01版本起被使用。
‘SCREEN_CATEGORY_MAIN’字段1406被声明为‘static final java.lang.String SCREEN_CATEGORY_MAIN’。如果显示或逻辑HScreen实例被定性为主屏幕，则其分类为SCREEN_CATEGORY_MAIN字段1406。被分配该分类的逻辑屏幕将被映射到某些显示屏幕的全部区域，并且将被分配默认值为0的z-顺序。
‘SCREEN_CATEGORY_MAIN’字段1406从MSM I01版本起被使用。
‘SCREEN_CATEGORY_PIP’字段1412被声明为‘static final java.lang.String SCREEN_CATEGORY_PIP’。如果逻辑HScreen实例被定性为画中画(PIP)屏幕，则其分类为SCREEN_CATEGORY_PIP字段1412。被分配该分类的逻辑屏幕将不会被映射到某些显示屏幕的全部区域，将不会被分配值为0的z-顺序，并且将在某些屏幕被分配了类型SCREEN_CATEGORY_MAIN 1406的配置中共存。
‘SCREEN_CATEGORY_PIP’字段1412从MSM I01版本起被使用。
‘SCREEN_CATEGORY_POP’字段1414被声明为‘static final java.lang.String SCREEN_CATEGORY_POP’。如果逻辑HScreen被定性为画外画(POP)屏幕，则其分类为SCREEN_CATEGORY_POP字段1414。被分配了该分类的逻辑屏幕将不会映射到某些显示屏幕的全部区域，将不会在某些屏幕被分配了分类SCREEN_CATEGORY_MAIN 1406的配置中共存，并且将在其它一些屏幕被分配了分类SCREEN_CATEGORY_POP 1414的配置中共存。
‘SCREEN_CATEGORY_POP’字段1414从MSM I01版本起被使用。
‘SCREEN_CATEGORY_OVERLAY’字段1410被声明为‘static finaljava.lang.String SCREEN_CATEGORY_OVERLAY’。如果逻辑HScreen实例被定性为覆盖屏幕，则其分类为SCREEN_CATEGORY_OVERLAY字段1410。被分配了该分类的逻辑屏幕将映射到某个显示屏幕的全部区域，将被分配默认z-顺序，其值大于与下列分类中的一个关联的任何屏幕：SCREEN_CATEGORY_MAIN字段1406、SCREEN_CATEGORY_PIP字段1412和SCREEN_CATEGORY_POP字段1414，并且不会包含背景或显示的视频平面(HVideoDevice)。
尽管有上面的说明，覆盖屏幕可以使用隐含的视频平面(HVideoDevice)的资源，用于在其图形平面(中的一个)中展示基于组件的视频。
‘SCREEN_CATEGORY_OVERLAY’字段1410从MSM I01版本起被使用。
‘SCREEN_CATEGORY_GENERAL’字段1404被声明为‘static finaljava.lang.String SCREEN_CATEGORY_GENERAL’。如果逻辑HScreen实例能够被配置(例如，在其尺寸、位置或z-顺序等方面)，从而它可以在所建议的分配两个或更多个其它屏幕分类的模式下操作，则其分类可以是SCREEN_CATEGORY_GENERAL字段1404。被分配了该分类的逻辑屏幕将不会在尺寸、位置、z-顺序或其它可配置属性上受限制，除了终端装置将固有的限制置于可配置属性之上。
‘SCREEN_CATEGORY_GENERAL’字段1404从MSM I01版本起被使用。
图14C示出了根据本发明的实施例的‘org.ocap.ui’包的‘MultiScreenConfiguration’接口的方法1450。
‘org.ocap.ui’包的‘MultiScreenConfiguration’接口的方法1450包括以下中的至少一个：‘java.lang.String getConfigurationType()’方法1452、‘org.havi.ui.HScreen getDefaultServiceContextScreen()’方法1454、‘org.havi.ui.HScreen[]getScreens()’方法1456、‘org.havi.ui.HScreen[]getScreens(java.lang.String category)’方法1458、‘boolean hasOverlayScreen()’方法1460、‘boolean isScreenInConfiguration(org.havi.ui.HScreen screen)’方法1462、以及‘void setDefaultServiceContextScreen’方法1464。
‘getConfigurationType’方法1452被声明为‘java.lang.String getConfigurationType()’，并获取该配置的屏幕配置类型。如果可以使用多于一个的非一般配置类型，或者如果配置类型未知或不能被确定，则将返回SCREEN_CONFIGURATION_GENERAL方法1418的值。
‘getConfigurationType’方法1452返回字符串，其是(i)‘SCREEN_CONFIGURATION_DISPLAY’方法1416、‘SCREEN_CONFIGURATION_NON_PIP’方法1420、‘SCREEN_CONFIGURATION_PIP’方法1422、‘SCREEN_CONFIGURATION_POP’方法1424和‘SCREEN_CONFIGURATION_GENERAL’方法1418中的元素，或者是(ii)表示依赖于平台的配置类型并以前缀“x-”开始的字符串。
‘getConfigurationType’方法1452从MSM I01版本起被使用。
‘getScreens()’方法1456被声明为‘org.havi.ui.HScreens[]getScreens()’，并获取与该配置关联的可访问屏幕集合。
由‘getScreens()’方法1456返回的给定HScreen实例的基本资源可以和另一个多屏幕配置中包含的HScreen实例共享。但是，被共享的资源在给定的时间不应在多于一个的多屏幕配置中活动。返回的HScreen实例的数组中元素的顺序依赖于实施。
给定返回数组中任意两个不同元素的值，S1和S2，并且给定MultiScreenManager，MSM的单例实例，则在‘getScreens()’方法1456返回的时刻与MultiScreenConfigurationEvent.MULTI_SCREEN_CONFIGURATION_CHANGING事件产生和分派的时刻之间的间隔期间，下列限制被应用：
·MSM.isEmptyScreen(S1)应是‘false’；
·MSM.isEmptyScreen(S2)应是‘false’；
·MSM.sameResources(S1，S2)应是aflse。
如果被没有MonitorAppPermission(“multiscreen.configuration”)权限的应用程序调用，则不与应用程序可访问的ServiceContext实例关联的该配置的屏幕将不会被返回；否则，该配置的所有可访问屏幕将被返回。
在应用程序的生命周期中，并且除了下面的限制，MSM实施可以将屏幕加到多屏幕配置或从多屏幕配置移除，在这种情况下它将分别产生MultiScreenConfigurationEvent.MULTI_SCREEN_CONFIGURATION_SCREEN_ADDED或者MultiScreenConfigurationEvent.MULTI_SCREEN_CONFIGURATION_SCREEN_REMOVED事件。
屏幕不应被添加到当前活动的每平台多屏幕配置或某个当前活动每显示多屏幕配置，或从其移除。
MSM实施必须等待直到多屏幕配置不再是当前活动的多屏幕配置，以便将屏幕添加到该配置或从该配置移除。
在没有MultiScreenConfigurationEvent.MULTI_SCREEN_CONFIGURATION_SCREEN_ADDED或MultiScreenConfigurationEvent.MULTI_SCREEN_CONFIGURATION_SCREEN_REMOVED事件产生的任何时间间隔中，从给定应用程序角度来看，返回的HScreen实例的集合以及这些返回的实例的顺序不会改变。
MSM实施不会移除或产生MultiScreenConfigurationEvent.MULTI_SCREEN_CONFIGURATION_SCREEN_REMOVED事件，该事件具有从该多屏幕配置移除(或报告移除)HScreen实例的效果，该HScreen实例的基本资源表示和某个未销毁应用程序的默认HScreen实例相同的(基本资源)。
‘getScreens()’方法1456返回‘HScreen’数组。返回的‘HScreen’数组可以是空数组。
‘getScreens()’方法1456从MSM I01版本起被使用。
‘getScreens(String)’方法1458被声明为‘org.havi.ui.HScreen[]getScreens(java.lang.String categort)’，并返回给定分类的所有可访问屏幕。
‘getScreens(String)’方法1458将和getScreens()方法1456起相同的作用，除了以下：
·如果category不是null，则只返回分配了指定分类的那些屏幕，或者，如果不存在这样的屏幕，则返回空HScreen数组；否则，如果categorg不是null，则返回和getScreens()方法1456相同的值。
参数category是下列值中的一个：(1)null，(2)下列枚举中的一个元素：{SCREEN_CATEGORY_NONE 1408，SCREEN_CATEGORY_DISPLAY1402，SCREEN_CATEGORY_MAIN 1406，SCREEN_CATEGORY_PIP 1412，SCREEN_CATEGORY_POP 1414，SCREEN_CATEGORY_OVERLAY 1410和SCREEN_CATEGORY_GENERAL 1404}，或者(3)依赖于平台的字符串，其没有被预定义为屏幕分类，但可以被getScreenCategory(HScreen)返回。
‘getScreens(String)’方法1458返回‘HScreen’数组。由‘getScreens(String)’方法1458返回的‘HScreen’数组可以是空的。
‘getScreens(String)’方法1458从MSM I01版本起被使用。
‘hasOverlayScreen()’方法1460被声明为‘boolean hasOverlayScreen()’，并确定与该配置关联的屏幕集合是否包括覆盖屏幕，即分类为SCREEN_CATEGORY_OVERLAY 1410的屏幕。
如果getScreens(SCREEN_CATEGORY_OVERLAY)返回非空数组，则‘hasOverlayScreen()’方法1460返回‘true’；否则，它返回‘false’。
‘hasOverlayScreen()’方法1460从MSM I01版本起被使用。
‘getDefaultServiceContextScreen()’方法1454被声明为‘org.havi.ui.HScreen‘getDefaultServiceContextScreen()’，并获取与该配置的屏幕关联的默认服务上下文。
多屏幕配置的默认服务上下文关联屏幕是在配置变为活动、假设没有更具体的信息可用来确定怎样将ServiceContext实例与屏幕关联时与ServiceContext实例关联的屏幕。
下列限制被应用：
1.如果该多屏幕配置是每平台显示多屏幕配置，则默认的服务上下文关联屏幕应是与和该多屏幕配置关联的某些显示屏幕的每显示多屏幕配置关联的屏幕；
2.否则，如果该多屏幕配置是每显示多屏幕配置，则默认的服务上下文关联屏幕应是与该多屏幕配置关联的显示屏幕或逻辑屏幕。
‘getDefaultServiceContextScreen()’方法1454返回作为该配置的默认服务上下文屏幕的HScreen实例。
如果调用的线程没有被授予MonitorAppPermission(“multiscreen.configuration”)的权限，则‘getDefault ServiceContextScreen()’方法1454产生‘java.lang.SecurityException’的异常。
‘getDefaultServiceContextScreen()’方法1454从MSM I01版本起被使用。
‘setDefaultServiceContextScreen()’方法1464被声明为‘void setDefaultServiceContextScreen(org.havi.ui.HScreen screen)’，并设置该配置的默认服务上下文关联屏幕。
多屏幕配置的默认服务上下文关联屏幕是在配置变为活动、假设没有更具体的信息可用来确定怎样将ServiceContext实例与屏幕关联时与ServiceContext实例所关联的屏幕。
参数‘screen’是HScreen实例，其被指定为该多屏幕配置的默认服务上下文关联屏幕。
如果调用的线程没有被授予‘MonitorAppPermission(“multiscreen.configuration”)’的权限，则‘setDefaultServiceContextScreen’方法1464产生‘java.lang.SecurityException’的异常。如果在getDefaultServiceContextScreen()方法1454下，上面指定的限制没有被满足，‘setDefaultServiceContextScreen’方法1464则产生‘java.lang.IllegalArgumentExeption’。
‘setDefaultServiceContextScreen’方法1464从MSM I01版本起被使用。
‘isScreenInConfiguration(HScreen)’方法1462被声明为‘boolean isScreenInConfiguration(org.havi.ui.HScreen screen)’。‘isScreenIn Configuration(HScreen)’方法1462确定指定屏幕的基本资源是否由与该配置相关的一组屏幕中包含的HScreen实例来表示。
参数‘screen’是‘HScreen’参数。
如果指定屏幕的基本资源由在该配置中所包含的HScreen实例来表示，则‘isScreenInConfiguration(HScreen)’方法1462返回‘true’；否则它返回‘false’。
‘isScreenInConfiguration(HScreen)’方法1462从MSM I01版本起被使用。
图15A示出了根据本发明的实施例的‘org.ocap.ui’包的‘MultiScreenContext’接口1230的定义。
‘org.ocap.ui’包的‘MultiScreenContext’接口1230的所有已知子接口包括‘MultiScreenConfigurableContext’，并被声明为‘public interface MultiScreenContext’。
‘MultiScreenContext’接口1230提供了一组工具用于完成下列功能：
1.通过逻辑映射过程，区分与VideoOutputPort直接关联的HScreen实例和与VideoOutputPort间接关联的实例；即，发现HScreen是显示屏幕还是逻辑屏幕；
2.发现HScreen实例的基本资源的唯一平台标志符；
3.发现在HScreen所包含的MultiScreenConfiguration之内分配给HScreen的分类；
4.发现逻辑HScreen到显示HScreen的映射，包括在显示HScreen之上逻辑HScreen出现的区域(范围)，其可见性，及其z-顺序；
5.发现HScreen之内HScreenDevice的z-顺序；
6.发现与HScreen关联的ServiceContext集合；
7.发现显示HScreen与相应VideoOutputPort的关联；
8.发现HScreenDevice集合，其生成的音频构成了HScreen的音频资源的集合；
9.发现显示HScreen的当前音频焦点分配；
10.获取该MultiScreenContext状态改变或实现该接口的HScreen实例的特定改变的通知；
11.获取显示屏幕的每显示多屏幕配置的改变的通知；
12.发现可以和显示屏幕一起使用的每显示多屏幕配置的集合；
13.获取显示屏幕当前活动的每显示多屏幕配置。
如果OCAP实施不支持OCAP多屏幕管理器(MSM)扩展，并且除此之外不支持‘MultiScreenContext’接口1230，则OCAP应用程序可以假设HScreen的行为等价于未实现该接口MultiScreenContext的HScreen实例(的行为)，其方法表现如下：
■getScreenType()返回SCREEN_TYPE_DISPLAY；
■getID()返回依赖于平台的字符串(可能为空)；
■getScreenCategory()返回字符串“main”；
■getVisible()返回‘true’；
■getZOrder()返回‘0’；
■getZOrder(HScreenDevice device)返回HScreenDevice实例的数组中device的数组索引，或者在device在该数组中不存在的情况下抛出IllegalArgumentException的异常，其中，通过将在该HScreen实例上调用HScreen.getHBackgroundDevices()方法，接着调用HScreen.getHVideoDevices()方法，接着调用HScreen.getHGraphicsDevices()方法的排序结果进行连接，该HScreenDevice实例被创建；
■getAudioSources()返回HScreenDevice实例的数组，通过将在该HScreen实例上调用HScreen.getHBackgroundDevices()方法，接着调用HScreen.getHVideoDevices()方法，接着调用HScreen.getHGraphicsDevices()方法的排序结果进行连接，该HScreenDevice实例被创建；
■getAudioFocus()返回该HScreen实例；
■getOutputPorts()返回包含该平台上所有可用的VideoOutputPort的数组；
■getDisplayScreen()返回该HScreen实例；
■getDisplayArea()返回new HScreenRectangle(0，0，1，1)；
■getContexts()返回包含当前应用程序可以访问的所有ServiceContext的数组；
MSM实施应该在每个HScreen实例上支持MultiScreenContexts接口1230。
‘org.ocap.ui’包中的‘MultiScreenContext’接口1230从MSM I01版本起被使用。
图15B示出了根据本发明的实施例的‘org.ocap.ui’包中的‘MultiScreenContext’接口1230的字段1500。
‘org.ocap.ui’包中的‘MultiScreenContext’接口1230的字段1500至少包括‘static int SCREEN_TYPE_DISPLAY’字段1502和‘static intSCREEN_TYPE_LOGICAL’字段1504。
‘SCREEN_TYPE_DISPLAY’字段1502被声明为‘static int SCREEN_TYPE_DISPLAY’。如果HScreen与VideoOutputPort直接关联，并且HScreen的范围映射到从VideoOutputPort产生的视频光栅的范围，则HScreen的类型为SCREEN_TYPE_DISPLAY，并且被称为显示HScreen。
‘SCREEN_TYPE_DISPLAY’字段1502从MSM I01版本起被使用。
‘SCREEN_TYPE_LOGICAL’字段1504被声明为‘static int SCREEN_TYPE_LOGICAL’。如果HScreen不与VideoOutputPort直接关联，或者HScreen的范围映射到从某个VideoOutputPort产生的视频光栅的子区域，则HScreen的类型为SCREEN_TYPE_LOGICAL，并且被称为逻辑HScreen。逻辑HScreen可以和显示HScreen关联。如果逻辑HScreen与显示HScreen不关联，则可视或可听的表现形式不应被与逻辑HScreen关联的任何ServiceContext产生。
不与显示HScreen关联的逻辑HScreen可以解码和使用用于除了展示以外的某个目的的内容。例如，逻辑HScreen可以记录来自ServiceContext的内容用于将来展示。
‘SCREEN_TYPE_LOGICAL’字段1504从MSM I01版本起被使用。
图15C和15D示出了根据本发明的实施例的‘org.ocap.ui’包中的‘MultiScreenContext’接口1230的方法1550。
‘org.ocap.ui’包中的‘MultiScreenContext’接口1230的方法1550包括以下方法中的至少一个：‘void addMultiScreenConfigurationListener(MultiScreenConfigurationListener listener)’方法1552，‘void addScreenContextListener(MultiScreenContextListener listener)’方1554，‘org.havi.ui.HScreengetAudioFocus()’方法1556，‘org.havi.ui.HScreenDevice[]getAudioSources()’方法1558，‘org.havi.ui.HScreenRectangle getDisplayArea()’方法1560，‘org.havi.ui.HScreen getDisplayScreen()’方法1562，‘java.lang.StringgetID()’方法1564，‘MultiScreenConfiguration getMultiScreen Configuration()’方法1566，‘MultiScreenConfiguration[]getMultiScreen Configurations()’方法1568，‘MultiScreenConfiguration[]getMultiScreen Configurations(java.lang.String screenConfigurationType)’方法1570，‘org.ocap.hardware.VideoOutput Port[]getOutputPorts()’方法1572，‘java.lang.String getScreenCategory()’方法1574，‘int getScreenType()’方法1576，‘javax.tx.service.selection.ServiceContext[]getServiceContexts()’方法1578，‘boolean getVisible()’方法1580，‘int getZOrder()’方法1582，‘int getZOrder(org.havi.ui.HScreenDevice device)’方法1584，‘void removeMultiScreenConfigurationListener(MultiScreenConfigurationListener listener)’方法1586，‘void removeScreenContextListener(MultiScreenContextListener listener)’方法1588。
‘getScreenType()’方法1576被声明为‘int getScreenType()’，并获取该HScreen的类型。‘getXreenType()’方法1576返回由‘SCREEN_TYPE_DISPLAY’或‘SCREEN_TYPE_LOGICAL’表示的整数值。
‘getScreenType()’方法1576从MSM I01版本起被使用。
‘getID()’方法1564被声明为‘java.lang.String getID()’，并且获得依赖于平台的唯一标志符，用于该屏幕表示的屏幕资源的基本集合，其中，唯一性的范围不小于与当前活动的每平台多屏幕配置和所有活动的每显示多屏幕配置关联的屏幕集合。屏幕标志符的唯一性的范围是否包括其它非活动的多屏幕配置，这依赖于实施方式。
屏幕标志符不应该等于getScreenCategory()返回的任何屏幕分类。
如果S1和S2是在实现的唯一性范围的上下文中的HScreen实例，并且MultiScreenManager.sameResources(S1，S2)返回‘false’，则((MultiScreenContext)S1).getID()和((MultiScreenContext)S2).getID()不应该返回相同(相等)的字符串。相反，如果MultiScreenManager.sameResources(S1，S2)返回‘true’，则((MultiScreenContext)S1).getID()和((MultiScreenContext)S2).getID()应该返回相同(相等)的字符串。
一个字符串值，表示该HScreen实例在实现的唯一性范围内所表示的基本资源的集合。
‘getID()’方法1564从MSM I01版本起被使用。
‘getScreenCategory()’方法1574被声明为‘java.lang.String.getScreenCategory()’，并获取该HScreen实例的屏幕分类。‘getScreenCategory()’方法1574可以是(1)下列由MultiScreenConfiguration所定义的枚举常量中的元素：{‘SCREEN_CATEGORY_DISPLAY’字段1402、‘SCREEN_CATEGORY_MAIN’字段1406、‘SCREEN_CATEGORY_PIP’字段1412、‘SCREEN_CATEGORY_POP’字段1414、‘SCREEN_CATEGORY_OVERLAY’字段1410和‘SCREEN_CATEGORY_GENERAL’字段1404}，或者是(2)表示依赖于平台的屏幕分类并且以前缀“x-”开始的字符串值。
‘getScreenCategory()’方法1574从MSM I01版本起被使用。
‘getVisible()’方法1580被声明为‘boolean getVisible()’，并获取屏幕的可见性。
‘getVisible()’方法1580确定该HScreen是否被标记为可见，用于在某些显示HScreen上展示，其中“可见”被定义为向VideoOutputPort生成光栅信号，无论VideoOutputPort是否是有效的或无效的。显示HScreen应该保持被标记为可见。逻辑HScreen可以是可见的或隐藏的(不可见的)。
‘getVisible()’方法1580返回一个布尔值，表示该HScreen是否在某些HScreen上被标记为可见。
‘getVisible()’方法1580从MSM I01版本起被使用。
‘getZOrder()’方法1582被声明为‘int getZOrder()’，并获取屏幕的z-顺序，即，其确定该HScreen的z-顺序。显示HScreen应该总是返回值为0的z-顺序。逻辑HScreen可以被分配1或更大的z-顺序，除非它不和显示HScreen关联，在这种情况下，其z-顺序为-1。较大的z-顺序表示一组HScreen实例中更前面(上面)的顺序。
‘getZOrder()’方法1582是表示该HScreen的z-顺序的值或‘-1’。如果该HScreen是不与显示HScreen关联的逻辑HScreen，则应该返回‘-1’。
‘getZOrder()’方法1582从MSM I01版本起被使用。
‘getZOrder(HScreenDevice)’方法1584被声明为‘int getZOrder(org.havi.ui.HScreenDevice device)’，并获取在该屏幕内的屏幕装置z-顺序。即，‘get ZOrder(HScreenDevice)’方法1584确定具有HScreen的特定HScreenDevice的z-顺序，其中，下列限制被应用程序：
·如果HbackgroundDevice在该屏幕中存在，则最后面(下面)的HBackgroundDevice的z-顺序为0；
·如果没有HBackgroundDevice在该屏幕中存在，并且如果HVideoDevice在该屏幕中存在，则最后面(下面)的HVedioDevice的z-顺序为0；
·如果HBackgroundDevice和HVideoDevice都不在该屏幕中存在，并且如果HGraphicsDevice在该屏幕中存在，则最后面(下面)的HGraphicsDevice的z-顺序为0；
·HVideoDevice的z-顺序大于该屏幕中任何HBackgroundDevice的z-顺序；
·HGraphicsDevice的z-顺序大于该屏幕中任何HVideoDevice的z-顺序。
较大的z-顺序表示在HScreen实例内的一组HScreenDevice中更前面(上面)的顺序。
被表示为HScreen实例的每组不同的基本屏幕装置组成不同的z-顺序。即，给定表示不同基本屏幕的多个HScreen实例，分配给这些屏幕的基本屏幕装置资源的z-顺序值集合可以再用相同的z-顺序索引。
device参数是与该屏幕关联的HScreenDevice。
‘getZOrder(HScreenDevice)’方法1584返回非负值，表示指定HScreenDevice的z-顺序。
如果device不是该屏幕的HScreenDevice，‘getZOrder(HScreenDevice)’方法1584产生‘java.lang.IllegalArgumentException’异常。
‘getZOrder(HScreenDevice)’方法1584从MSM I01版本起被使用。
‘getAudioSources()’方法1558被声明为‘org.havi.ui.HScreenDevice[]getAudioSources()’，并获取该屏幕的音频源。即，‘getAudioSources()’方法1558获取HScreenDevice的集合，从中选择(并混合)被表示的音频，用于从该屏幕展示音频的目的。
屏幕的默认音频源集合包括与该屏幕关联的所有HScreenDevice。
‘getAudioSources()’方法1558返回的数组中元素的顺序没有被本说明书定义，而应该被考虑为依赖于实施方式。
‘getAudioSources()’方法1558返回对(可能为空的)HScreenDevice实例数组的引用，其中，每个这样的实例对来自该屏幕的混合音频展示有贡献，或者，如果该屏幕不支持混合音频，则至少一个元素在该返回的数组中存在。
‘getAudioSources()’方法1558从MSM I01版本起被使用。
‘getAudioFocus()’方法1556被声明为‘org.havi.ui.HScreengetAudioFocus()’，并获取音频焦点屏幕。
该HScreen的音频焦点屏幕根据下列规则来确定，其中应用的第一条规则被使用，而其它的被忽略：
1.如果该HScreen是逻辑屏幕，则应用下列有序的子规则：
a.如果该逻辑HScreen被映射到显示屏幕，则应用程序下列子规则：
i.如果该逻辑HScreen当前被选定为其显示屏幕的上下文中的音频焦点，则返回该逻辑HScreen。
ii.否则(当前没有被选定为其显示屏幕中的音频焦点)，则返回‘null’。
b.否则(没有映射到显示屏幕)，如果该逻辑HScreen被直接映射到视频输出端口，则返回该HScreen。
c.否则(没有映射到显示屏幕，并且不直接映射到视频输出端口)，则返回‘null’。
2.否则(该HScreen是显示屏幕)，则应用下列子规则：
a.如果映射到该显示屏幕的某些逻辑屏幕被选定为音频焦点，则返回该逻辑HScreen；
b.否则(没有逻辑屏幕映射到该显示屏幕，或者没有映射到该显示屏幕的逻辑屏幕被选定为音频焦点)，则返回该显示HScreen。
显示屏幕的音频焦点屏幕是这样的屏幕，其当前被选择的音频源被选定为在显示屏幕所映射到的所有视频输出端口的所有(暗含的)视频展示装置上展现。
‘getAudioFocus()’方法1556如上所述返回HScreen实例或null。
‘getAudioFocus()’方法1556从MSM I01版本起被使用。
‘getOutputPorts()’方法1572被声明为‘org.ocap.hardware.VideoOutputPort[]getOutputPorts()’，并获取屏幕所映射到的视频端口。即，‘getOutputPorts()’方法1572获取与该HScreen关联的VideoOutputPort的集合。如果HScreen的类型为SCREEN_TYPE_DISPLAY，则应该返回与该显示屏幕关联的VideoOutputPort实例。如果该HScreen的类型为SCREEN_TYPE_LOGICAL，并且该HScreen与显示HScreen关联，则应该返回与该显示HScreen关联的VideoOutputPort实例。如果HScreen的类型为SCREEN_TYPE_LOGICAL，并且该HScreen不与显示HScreen关联，则应该返回空的数组。
‘getOutputPorts()’方法1572返回对VideoOutputPort实例数组的引用。如果返回的数组是空的，则该HScreen不用任何VideoOutputPort关联。
‘getOutputPorts()’方法1572从MSM I01版本起被使用。
‘getDisplayScreen()’方法1562被声明为‘org.havi.ui.HScreen getDisplayScreen()’，并获取与该屏幕关联的显示屏幕。即，‘getDisplayScreen()’方法1562获取与该HScreen关联的显示HScreen。
如果该HScreen的类型为SCREEN_TYPE_DISPLAY，则应该返回对该HScreen的引用。如果该HScreen的类型为SCREEN_TYPE_LOGICAL，并且该HScreen与显示HScreen关联，则应该返回该显示HScreen。如果HScreen的类型为SCREEN_TYPE_LOGICAL，并且该HScreen不与显示HScreen关联，则应该返回null值。
‘getDisplayScreen()’方法1562返回对显示HScreen实例的引用或‘null’。如果返回‘null’，则该HScreen不与显示HScreen关联。
‘getDisplayScreen()’方法1562从MSM I01版本起被使用。
‘getDisplayArea()’方法1560被声明为‘org.havi.ui.HScreenRectanglegetDisplayArea()’，并获取该屏幕所映射到的显示屏幕的区域。‘getDisplayArea()’方法1560获取该HScreen的区域(范围)。如果该HScreen的类型为SCREEN_TYPE_DISPLAY，则应该返回其值等于HScreenRectangle(0，0，1，1)的HScreenRectangle。如果该HScreen的类型为SCREEN_TYPE_LOGICAL，并且该HScreen与显示HScreen关联，则应该返回该逻辑HScreen在其关联的显示HScreen上所占据的区域(范围)。如果该HScreen的类型为SCREEN_TYPE_LOGICAL，并且不与显示HScreen关联，则应该返回‘null’值。
‘getDisplayArea()’方法1560返回HScreenRectangle实例或‘null’。如果返回‘null’，则该HScreen不与显示HScreen关联。
‘getDisplayArea()’方法1560从MSM I01版本起被使用。
‘getServiceContexts()’方法1578被声明为‘javax.tv.service.selection.ServiceContext[]getServiceContexts()’，并且获取与该屏幕关联的服务上下文。即，‘getServiceContexts()’方法1578获取与该HScreen关联的ServiceContext的集合，调用的应用程序被授予对该ServiceContext的访问权限。
‘getServiceContexts()’方法1578返回对ServiceContext实例数组的引用。如果返回的数组为空，则该HScreen不与任何可访问的ServiceContext关联。
‘getServiceContexts()’方法1578从MSM I01版本起被使用。
‘addScreenContextListener(MultiScreenContextListener)’方法1554被声明为‘void addScreenContextListener(MultiScreenContextListener listener)’，并且添加屏幕上下文监听器。即，‘addScreenContextListener(MultiScreenContextListener)’方法1554在屏幕上下文事件发生时添加要通知的监听器。如果该监听器之前已被添加并随后没有被移除，则尝试重新添加不会产生任何副作用。
参数listener是MultiScreenContextListener的实例。
‘addScreenContextListener(MultiScreenContextListener)’方法1554从MSM I01版本起被使用。
‘removeScreenContextListener(MultiScreenContextListener)’方法1588被声明为‘void removeScreenContextListener(MultiScreenContextListenerlistener)’，并且移除屏幕上下文监听器。即，‘removeScreenContextListener(MultiScreenContextListener)’方法1588移除之前在屏幕上下文事件发生时被添加的要通知的监听器。如果指定的监听器当前没有被注册为监听器，则尝试移除它不会产生任何副作用。
参数listener是MultiScreenContextListener的实例。
‘removeScreenContextListener(MultiScreenContextListener)’方法1588从MSM I01版本起被使用。
‘addMultiScreenConfigurationListener(MultiScreenConfigurationListener)’方法1552被声明为‘addMultiScreenConfigurationListener(MultiScreenConfigurationListener listener)’，并在屏幕是显示屏幕的情况下、当应用程序到该屏幕的多屏幕配置事件发生时添加要通知的监听器。如果该监听器之前已被添加并随后没有被移除，则尝试重新添加不会产生任何副作用。
应用到显示屏幕的配置文件应该被限制到这样的事件：影响与显示屏幕关联的逻辑屏幕的补集。
如果产生了MultiScreenConfigurationEvent所定义的事件，则MSM实施应该相应地通知每个已注册的屏幕配置监听器。
参数listener是MultiScreenConfigurationListener的实例。
如果该屏幕的类型不是SCREEN_TYPE_DISPLAY，则‘addMultiScreenConfigurationListener(MultiScreennConfigurationListener)’方法1552产生‘java.lang.IllegalStateException’异常。
‘addMultiScreenConfigurationListener(MultiScreennConfigurationListener)’方法1552从MSM I01版本起被使用。
‘removeMultiScreenConfigurationListener(MultiScreenConfigurationListener )’方法1586被声明为‘removeMultiScreenConfigurationListener(MultiScreenConfigurationListener listener)’，并且移除之前添加的在多屏幕配置事件发生时要通知的监听器。如果指定的监听器当前没有被注册为监听器，则尝试移除它不会产生任何副作用。
参数listener是MultiScreenConfigurationListener的实例。
‘removeMultiScreenConfigurationListener(MultiScreennConfigurationListener)’方法1552从MSM I01版本起被使用。
‘getMultiScreenConfigurations()’方法1568被声明为‘MultiScreenConfiguration[]getMultiScreenConfigurations()’，并获取当前与该显示屏幕关联的所有每显示多屏幕配置的集合，其中任何这样的多屏幕配置的配置类型应该不是‘SCREEN_CONFIGURATION_DISPLAY’字段1416。
‘getMultiScreenConfigurations()’方法1568返回MultiScreenConfiguration实例的非空数组。
如果调用的线程没有被授予MonitorAppPermission(“multiscreen.configuration”)，则‘getMultiScreenConfigurations()’方法1568产生‘java.lang.SecurityException’异常。
‘getMultiScreenConfigurations()’方法1568从MSM I01版本起被使用。
‘getMultiScreenConfigurations(String)’方法1570被声明为‘MultiScreenConfiguration[]getMultiScreenConfigurations(java.lang.String screenConfigurationType)’，并获取与该显示屏幕关联的特定类型的每显示多屏幕配置。
参数screenConfigurationType是(1)由MultiScreenConfiguration接口定义的下列常数枚举中的元素：{SCREEN_CONFIGURATION_NON_PIP字段1420、SCREEN_CONFIGURATION_PIP字段1422、SCREEN_CONFIGURATION_POP字段1424、及SCREEN_CONFIGURATION_GENERAL字段1418}，或者是(2)没有被预定义为多屏幕配置类型的某个其它的依赖于平台的值。
‘getMultiScreenConfigurations(String)’方法1570返回MultiScreenConfiguration实例数组或‘null’，这依赖于特定的配置类型是否被支持。
如果调用的线程没有被授予MonitorAppPermission(“multiscreen.configuration”)的权限，则‘getMultiScreenConfigurations(String)’方法1570产生‘java.lang.SecurityException’的异常。
如果screenConfigurationType是SCREEN_CONFIGURATION_DISPLAY，没有被定义，或者对于平台实现是未知的，则‘getMultiScreenConfigurations(String)’方法1570产生‘java.lang.Illegal ArgumentException’的异常。
‘getMultiScreenConfigurations(String)’方法1570从MSM I01版本起被使用。
‘getMultiScreenConfiguration()’方法1566被声明为‘MultiScreenConfiguration getMultiScreenConfiguration()’，并获取用于该显示屏幕的当前活动的每显示多屏幕配置。
‘getMultiScreenConfiguration()’方法1566返回用于该显示屏幕的当前活动的每显示MultiScreenConfiguration实例。
如果‘HScreen’不是显示屏幕，则‘getMultiScreenConfiguration()’方法1566产生‘java.lang.IllegalStateException’的异常。
‘getMultiScreenConfiguration()’方法1566从MSM I01版本起被使用。
图16A示出了根据本发明的实施例的‘org.ocap.ui’包的‘MultiScreenManager’类1260的定义。
‘org.ocap.ui’包的‘MultiScreenManager’类1260是‘java.lang.Object’的子类(lower class)，并且所有实现的接口包括‘org.davic.resources.ResourceServer’。
‘org.ocap.ui’包的‘MultiScreenManager’类1260被声明为‘publicabstract class MultiScreenManager’，扩展为‘extends java.lang.Object’，并且被实现为‘implements org.davic.resources.ResourceServer’。
‘MultiScreenManager’类1260是抽象的单例的管理类，由提供多屏幕管理服务的OCAP主机平台实现。
其它要应用的语义限制和行为将在本说明书中详细描述。
‘org.ocap.ui’包的‘MultiScreenManager’类1260从MSM I01版本起被应用。
图16B示出了根据本法的实施例的‘org.ocap.ui’包的‘MultiScreenManager’类1260的构造函数1600。
MultiScreenManager类1260的构造函数1600被声明为‘protected MultiScreenManager()’，并且是受保护的默认构造函数。
‘MultiScreenManager()’1602从MSM I01版本起被使用。
图16C到16F示出了根据本发明的实施例的‘org.ocap.ui’包的‘MultiScreenManager’类1260的方法1630。
‘org.ocap.ui’包的‘MultiScreenManager’类1260的方法1630包括以下方法中的至少一个：‘void addMultiScreenConfigurationListener(MultiScreenConfigurationListener listener)’方法1632、‘void addPlayerScreenDevices(javax.media.Player player，org.havi.ui.HScreenDevice[]devices)’方法1634、‘void addResourceStatusListener(org.davic.resources.ResourceStatusListener listener)’方法1636、‘org.havi.ui.HScreen[]findScreens(javax.tv.service.selection.ServiceContext context)’方法1638、‘org.havi.ui.HScreen[]getCompatibleScreens(org.ocap.hardware.VideoOutputPort port)’方法1640、‘org.havi.ui.HScreen getDefaultScreen()’方法1642、‘org.havi.ui.HScreengetEmptyScreen()’方法1644、‘static MultiScreenManager getInstance()’方法1646、‘MultiScreenConfiguration getMultiScreenConfiguration()’方法1648、‘MultiScreenConfiguration getMultiScreenConfiguration(org.havi.ui.HScreen screen)’方法1650、‘MultiScreenConfiguration[]getMultiScreenConfigurations()’方法1652、‘MultiScreenConfiguration[]getMultiScreenConfigurations(java.lang.String screenConfigurationType)’方法1654、‘org.havi.ui.HScreen getOutputPortScreen(org.ocap.hardware.VideoOutputPortport)’方法1656、‘org.havi.ui.HScreenDevice[]getPlayerScreenDevices(javax.media.Player player)’方法1658、‘org.havi.ui.HScreen[]getScreens()’方法1660、‘boolean isEmptyScreen(org.havi.ui.HScreen screen)’方法1662、‘boolean isEmptyScreenDevice(org.havi.ui.HScreenDevice device)’方法1664、‘void moveServiceContexts(org.havi.ui.HScreen src.org.havi.ui.HScreen dst，ajavax.tv.services.selection.ServiceContext[]contexts)’方法1666、‘voidremoveMultiScreenConfigurationListener(MultiScreenConfigurationListenerlistener)’方法1668、‘void removePlayerScreenDevices(javax.media.Playerplaer，org.havi.ui.HScreenDevice[]devices)’方法1670、‘void removeResourceStatusListener(org.davic.resources.ResourceStatusListener listener)’方法1672、‘void requestMultiScrenConfigurationChange(MultiScreenConfigurationconfiguration，java.util.Dictionary serviceContextAssociations)’方法1674、‘boolean sameResources(org.havi.ui.HScreenDevice device1，org.haiv.ui.HScreenDevice device2)’方法1676、‘boolean sameResources(org.havi.ui.HScreen screen1，org.havi.ui.HScreen screen2)’方法1678、‘boolean sameResources(javax.tv.service.selection.ServiceContext sc1，javax.tv.service.selection.ServiceContext sc2)’方法1680、‘void setMultiScreenConfiguration(MultiScreenConfiguration  configuration，java.util.Dictionary serviceContextAssociations)’方法1682、以及‘void swapServiceContexts(org.havi.ui.HScreenscreen1，org.havi.ui.HScreen screen2，javax.tv.service.selection.ServiceContext[]exclusions)’方法1684。
从‘java.lang.Object’类继承的方法1690包括‘clone’、‘equals’、‘finalize’、‘getClass’、‘hashCode’、‘notify’、‘notifyAll’、‘toString’、‘wait’、‘wait’和‘wait’中的至少一个。
从‘org.davic.resources.ResourceServer’接口继承的方法1695包括‘addResourceStatusEventListener’和‘removeResourceStatusEventListener’中的至少一个。
‘getScreens()’方法1660被声明为‘public org.havi.ui.HScreen[]getScreens()’，并获取可以访问的‘HScreen’实例的集合。
返回的HScreen实例的集合应该如下被确定。
当被授予MonitorAppPermission(“multiscreen.configuration”)权限的OCAP应用程序调用时，则应该为在该方法被调用时通过任何可访问的MultiScreenConfiguration实例所暴露的每个显示屏幕和每个逻辑屏幕返回HScreen实例。否则，则应该为可访问的ServiceContext所(直接或间接)关联的每个显示屏幕和逻辑屏幕返回HScreen实例，用于展示或可能展示的目的。
返回的HScreen[]数组中的第一个HScreen实例应该等于由‘MultiScreenManager’类1260的getDefaultScreen()方法1642所返回的值。返回的数组中随后的元素不遵循规定的顺序，并且应用程序不应该依赖于这些随后的元素的顺序。
由‘getScreen()’方法1660返回的HScreen实例的集合可以在应用程序的生命周期过程中改变，例如当屏幕被加到或从可访问的多屏幕配置或者从其移除时。但是，表示应用程序的默认HScreen的HScreen实例引用在应用程序的生命周期中不应该保持不变。即，从给定的应用程序实例的角度来看，MSM实施应该总是返回相同的HScreen实例引用作为返回的HScreen实例数组的第一个元素。
在‘getScreens()’方法1660返回值的时间和生成并分派MultiScreenConfigurationEvent.MULTI_SCREEN_CONFIGURATION_CHANGING事件或MultiScreenContextEvent.MULTI_SCREEN_CONTEXT_SERVICE_CONTEXT_CHANGED事件的时间之间的间隔时段期间，‘getScreens()’方法1660返回的任何HScreen实例不应该等于空HScreen。
由‘getScreens()’方法1660返回的每个HScreen实例可以返回与从应用程序的生命周期过程中的其getHBackgroundDevices()、getHVideoDevices()及getHGraphicsDevices()所返回的HScreenDevice实例不同的HScreenDevice实例集合。但是，如下所述在getDefaultScreen()方法的定义下，通过‘getHBackgroundDevices()’、‘getHVideoDevices()’和‘getHGraphicsDevices()’从默认HScreen实例所返回的默认的HbackgroundDevice、VideoDevice和HgraphicsDevice实例的集合在应用程序的生命周期中应该保持不变，而这些默认HScreenDevice实例的基本装置资源和配置可以改变。
在‘getScreens()’方法1660返回值的时间和生成MultiScreenConfigurationEvent.MULTI_SCREEN_CONFIGURATION_CHANGING事件或MultiScreenContextEvent.MULTI_SCREEN_CONTEXT_SERVICE_CONTEXT_CHANGED事件的时间之间的间隔时段期间，由‘getScreens()’方法1660返回的任何HScreen的任何背景、视频或图形屏幕装置，即，HbackgroundDevice、HVideoDevice或HgraphicsDevice，不应该等于其特定子类型的空HScreenDevice。
从由‘getScreens()’方法1660返回的HScreen实例的getHBackgroundDevices()、getHVideoDevices()和getHGraphicsDevices()所返回的HScreenDevice实例的数量，在HScreen实例的生命周期中可以改变。如果它们改变，则MultiScreenConfigurationEvent.MULTI_SCREEN_CONFIGURATION_CHANGED事件应产生并被分派给所有已注册的MultiScreenContextListener实例。
如果特定类型的HScreenDevice实例的数量增加或保持相同(对于给定的HScreen实例)，则对于之前返回给应用程序的非默认HScreenDevice实例的任何引用应保持可实行，并且在MSM实施的选项下，应该(1)被再用来表示该类型的屏幕装置新的基本装置资源，或者(2)被重置为如上定义的合适子类型的空HScreenDevice。在前一种情况下，被再用的HScreenDevice实例应该根据其屏幕装置类型在从getHBackgroundDevices()、getHVideoDevices()或getHGraphicsDevices()返回的屏幕装置集合中存在。在后一种情况下，状态被重置为空HScreenDevice的HScreenDevice实例不应该在从getHBackgroundDevices()getHVideoDevices()或getHGraphicsDevices()返回的屏幕装置集合中存在。
如果特定类型的HScreenDevice实例的数量减少(对于给定的HScreen实例)，则对于之前返回给应用程序的非默认HScreenDevice实例的任何引用应保持可实行，应被重置为空屏幕装置状态，并且不应在由HScreen实例返回的屏幕装置集合中存在。
上述行为的净效果是，只访问其默认HScreen实例和默认HScreenDevice实例的应用程序可以继续访问和使用那些实例，而不用关于MSM功能的存在性的任何知识。相反，访问非默认HScreen实例或非默认HScreenDevice实例的应用程序需要监控对当前的每平台和每显示多屏幕配置的改变，以及与非默认屏幕关联的屏幕装置集合的改变。
如果之前由应用程序所引用的非默认HScreen实例被重置为空屏幕状态作为多屏幕配置改变的结果，则应用程序可以通过将先于合适的MultiScreenConfigurationEvent获取的HScreen实例引用集合与在该事件之后可获取的HScreen实例引用集合进行比较，来检测该事实。在该事件之后，那些被重置为空状态的HScreen实例将不再在由‘getScreens()’方法1660返回的HScreen实例的数组中存在。此外，可以通过使用‘MultiScreenManager’类1260所定义的isEmptyScreen(HScreen)来查询那些之前被获取的HScreen实例是否被重置了。最后，如果应用程序可以继续使用这样的重置HScreen实例，则其行为被明确定义且不可变。
类似地，如果之前被应用程序引用的非默认HScreenDevice实例被重置为空屏幕装置状态作为多屏幕配置改变的结果，则应用程序可以通过将先于合适的MultiScreenContextEvent事件获取的HScreenDevice实例引用集合与在该事件之后可获取的HScreenDevice实例引用集合进行比较，来检测该事实。在该事件之后，那些被重置为空状态的HScreenDevice实例将不再通过由‘getScreens()’方法1660所返回的可访问HScreen实例集合来访问。此外，可以通过使用‘MultiScreenManager’类1260所定义的isEmptyScreenDevice(HScreenDevice)来查询它们是否被重置了。最后，如果应用程序可以继续使用这样的重置HScreenDevice实例，则其行为被明确定义且不可变。
如果HScreen实例S没有实现MultiScreenConfigurableContext接口(例如，由于它在被创建时不是可配置的，且MSM实施选择性地在特定的HScreen上实现该接口)，并且如果新的基本资源是可配置的(由此该接口将在表示该基本屏幕资源集合的HScreen实例上实现)，则MSM实施在多屏幕配置改变时，不应该再用S来表示新的基本屏幕资源集合，而应该将S重置为空状态。
‘getScreens()’方法1660如上所述返回HScreen实例的非空数组。
‘getScreens()’方法1660从MSM I01版本起被使用。
‘getDefaultScreen()’方法1642被声明为‘public org.havi.ui.HScreen getDefaultScreen()’，并获取默认的HScreen实例。
‘getDefaultScreen()’方法1642返回的HScreen实例应该表示当前活动的默认基本屏幕装置的集合，及其当前活动的HAVi屏幕配置。此外，HScreen实例可以表示当前活动的非默认基本屏幕资源的集合及其配置。
返回的默认HScreen实例旨在从调用的应用程序、或该方法所代表而被调用的应用程序的角度来说是默认的。如果‘getDefaultScreen()’方法1642在不隐含特定应用的上下文中被平台实现所调用，则返回的值不被定义，并且应该依赖于实现，包括，例如返回‘null’。
在应用程序的生命周期过程中，从‘getDefaultScreen()’方法1642返回的引用应该保持不变。此外，该默认HScreen实例的getDefaultHBackgrounDevice()、getDefaultHVideoDevice()和getDefault HGraphicsDevice()所返回的默认HScreenDevice实例集合在应用程序的生命周期中应类似地保持不变。尽管该引用不变，这些装置资源的基本装置资源和基本配置可以在应用程序的生命周期中改变。
‘getDefaultScreen()’方法1642所返回的任何非默认背景、视频或图形屏幕装置，即HBackgroundDevice、HVideoDevice或HGraphicsDevice，在该方法返回的时间与产生MultiScreenConfiguration.MULTI_SCREEN_CONFIGURATION_CHANGING或MultiScreenContextEvent.MULTI_SCREEN_CONTEXT_SERVICE_CONTEXT_CHANGED事件的时间之间的间隔时段期间，不应该等于特定子类型的空HScreenDevice。
如果由‘getDefaultHBackgroundDevice()’、‘getDefaultHVideoDevice()’和‘getDefualtHGraphicsDevice()’返回的任何默认HScreenDevice实例的任何HScreenConfiguration参数(或导出的屏幕装置类型的特定参数)在应用程序生命周期中改变，则合适的HScreenConfigurationEvent应该生成并被分派给所有已注册的HScreenConfigurationListener实例。类似地，如果将由该默认HScreen实例实现的MultiScrenContext接口的任何查询(get*)方法所返回的任何值改变，则合适的MultiScreenContextEvent事件应该生成并被分派给所有已注册的MultiScreenContextListener实例。
如果‘getDefaultScreen()’方法1642所返回的任何HScreen实例实现了MultiScreenConfigurableContext接口，则由该方法返回的任何HScreen实例应该实现MultiScreenConfigurableContext接口，不管由返回的HScreen实例所表示的基本屏幕资源是否是可配置的。
‘getDefaultScreen()’方法1642如上所述返回HScreen实例。
‘getDefaultScreen()’方法1642从MSM I01版本起被使用。
‘findScreens(ServiceContext)’方法1638被声明为‘public org.havi.ui.HScreen[]findScreens(javax.tv.service.selection.ServiceContext context)’，并寻找与特定服务上下文关联的至少一个可访问的屏幕。给定的服务上下文可以与零个、一个或多个HScreen实例关联。即，‘findScreens(ServiceContext)’方法1638寻找与指定的ServiceContext关联的可访问HScreen实例的集合。如果getScreens()方法1660返回(或将返回)HScreen实例(当在该方法被调用的同一时刻被相同的应用程序调用时)，则HScreen实例是可以(被某些应用程序)访问的。
参数‘context’是‘ServiceContext’实例。
‘findScreens(ServiceContext)’方法1638返回HScreen实例的集合或‘null’。如果指定的ServiceContext与某个可访问的HScreen关联，则该HScreen应该在返回的数组中存在，该数组不应为‘null’并且是非空的。否则，返回‘null’，表示ServiceContext不与任何HScreen关联。
‘findScreens(ServiceContext)’方法1638从MSM I01版本起被使用。
‘getOutputPortScreen(VideoOutputPort)’方法1656被声明为‘publicorg.havi.ui.HScreen getOutputPortScreen(org.ocap.hardware.VideoOutputPortport)’，并获取与输出端口关联的屏幕。给定特定的VideoOutputPort实例，‘getOutputPortScreen(VideoOutputPort)’方法1656获取与该端口关联的HScreen实例，用于展示的目的。
参数port是VideoOutputPort实例。
‘getOutputPortScreen(VideoOutputPort)’方法1656返回与指定的端口关联的HScreen实例，或返回‘null’，如果关联不存在。
‘getOutputPortScreen(VideoOutputPort)’方法1656从MSM I01版本起被实现。
getCompatibleScreens(VideoOutputPort)方法1640被声明为getCompatibleScreens(org.ocap.hardware.VideoOutputPort port)，并获取与输出端口相容的可访问的屏幕集合。
给定特定的VideoOutputPort实例，getCompatibleScreens(VideoOutputPort)方法1640获取可以与该端口关联的(由getScreens()方法所返回的更大的集合中的)HScreen实例的子集，用于展示的目的。
参数port是VideoOutputPort实例。
getCompatibleScreens(VideoOutputPort)方法1640返回可以和指定的端口关联的HScreen实例的(可能为空的)数组。
getCompatibleScreens(VideoOutputPort)方法1640从MSM I01版本起被实现。
getMultiScreenConfigurations()方法1652被声明为public MultiScreenConfiguration[]getMultiScreenConfigurations()，并且获取该平台支持的所有当前多屏幕配置的集合，不管它们的配置类型。
由getMultiScreenConfigurations()方法1652返回的多屏幕配置实例的集合应该包括所有每平台多屏幕配置(由显示屏幕单独构成)和所有每显示多屏幕配置(由不多于一个显示屏幕和任意数量的逻辑屏幕构成)。
由getMultiScreenConfigurations()方法1652返回的多屏幕配置的顺序没有被本说明书定义。
getMultiScreenConfigurations()方法1652返回MultiScreenConfiguration实例的数组。
如果调用的线程没有被授予MonitorAppPermission(“multiscreen.configuration)”的权限，则getMultiScreenConfigurations()方法1652将抛出java.lang.SecurityException的异常。
getMultiScreenConfigurations()方法1652从MSM I01版本起被使用。
getMultiScreenConfigurations(String)方法1654被声明为public MultiScreenConfiguration[]getMultiScreenConfigurations(java.lang.String screenConfigurationType)，并获取特定配置类型的多屏幕配置。
参数screenConfigurationType是下列值中的一个：(1)由MultiScreenConfiguration所定义的下列枚举常量中的元素：{SCREEN_CONFIGURATION_DISPLAY 1416、SCREEN_CONFIGURATION_NON_PIP1420、SCREEN_CONFIGURATION_PIP 1422、SCREEN_CONFIGURATION_POP 1424、SCREEN_CONFIGURATION_GENERAL 1418}，或者(2)没有被预定义为多屏幕配置类型的某个其它的依赖于平台的值。
由getMultiScreenConfigurations(String)方法1654返回的多屏幕配置实例的集合应该包括在由getMultiScreenConfigurations()方法1652返回的数组中出现的所有指定类型的多屏幕配置。
由getMultiScreenConfigurations(String)方法1654返回的多屏幕配置的顺序没有被本说明书定义。
getMultiScreenConfigurations(String)方法1654返回MultiScreenConfiguration实例的数组或null，取决于指定的配置类型是否被支持。
如果调用的线程没有被授予MonitorAppPermission(“multiscreen.confguration”)的权限，则getMultiScreenConfigurations(String)方法1654抛出java.lang.SecurityException的异常。
getMultiScreenConfigurations(String)方法1654从MSM I01版本起被使用。
getMultiScreenConfiguration(HScreen)方法1650被声明为public MultiScreenConfiguration getMultiScreenConfiguration(org.havi.ui.HScreen screen)，并获取特定屏幕的多屏幕配置。
给定的HScreen实例应该与零个或正好一个多屏幕配置实例关联；但是，由于单个基本屏幕可以被多个HScreen实例共享(多次引用)，基本屏幕(及其组成资源)可以和多于一个多屏幕配置关联。
参数screen是HScreen实例。
getMultiScreenConfiguration(HScreen)方法1650返回MultiScreenConfguration实例，其指定的HScreen是组成的屏幕，或null，如果该指定的HScreen是孤立的(即，没有被多屏幕配置所拥有，例如，它是空屏幕的情形)。
getMultiScreenConfiguration(HScreen)方法1650从MSM I01版本起被使用。
getMultiScreenConfiguration()方法1648被声明为public MultiScreenConfiguration getMultiScreenConfiguration()，并获取当前活动的每平台显示多屏幕配置。
getMultiScreenConfiguration()方法1648返回当前活动的每平台显示MultiScreenConfiguration实例。
getMultiScreenConfiguration()方法1648从MSM I01版本起被使用。
setMultiScreenConfiguration()方法1682被声明为public voidsetMultiScrenConfiguration(MultiScreenConfiguration configuration，java.util.Dictionary serviceContextAssociations)，并设置当前活动的每平台显示多屏幕配置。
如果指定的configuration是当前的每平台显示多屏幕配置，则，除非SecurityException被应用，setMultiScreenConfiguration()方法1682返回值而不会产生任何副作用。
如果指定的configuration不是当前的每平台显示多屏幕配置，并且如果SecurityException、IllegalArgumentException和IllegalStateException没有被应用，则setMultiScreenConfiguration()方法1682执行由OCAP MultiScreenManager(MSM)扩展规范所定义的同步每平台多屏幕配置改变处理。
如果参数serviceContextAssociation是指定的(即不是null)，则可以访问调用的应用程序的任何ServiceContext实例应该要么不与屏幕关联，要么与在指定的(新)每平台多屏幕配置中(或在其每显示多屏幕配置中)的可应用的屏幕关联。如果没有关联与某个可访问的ServiceContext匹配，如果某个可访问的ServiceContext实例不在指定的关联中存在，或者如果它存在但没有这样的可应用屏幕在新的每平台多屏幕配置中(或在其每显示多屏幕配置中)存在，则ServiceContext实例应该与指定的多屏幕配置的默认服务上下文关联屏幕、即由configuration.getDefaultServiceContextScreen()所返回的屏幕关联。
为了匹配这样的可访问的ServiceContext实例，即，其引用在指定的serviceContextAssociations字典中作为关键字出现，应该使用这些关键字上的虚方法equals(Object)，在这种情况下，假设setMultiScreenConfiguration()方法1682与Object.equals(Object)方法的默认实现一样地表现。
在给定应用程序实例的上下文中，MSM主机实施应该在暴露给该应用程序的ServiceContext实例和基本服务上下文集合之间保持一对一的关系。如果MSM主机实施不能保持这种关系，则在查询ServiceContextAssociations字典时，MSM实施可以将两个不同的基本服务上下文资源的集合考虑为相同的服务上下文，例如，如果在不同的时间，单个ServiceContext实例引用不同的资源基本集合，或者，可以将单个基本服务上下文资源的集合考虑为两个不同的服务上下文，例如，如果在给定的时间，两个不同的ServiceContext实例引用了相同的资源基本集合。
视频管线(pipeline)的解码器格式变换(DFC)组件的状态不应该被setMultiScreenConfiguration()方法1682的执行影响，该视频管线被用来处理与服务上下文关联的视频，该服务上下文被setMultiScreenConfiguration()方法1682在屏幕之间隐式地交换或移动。
参数configuration是MultiScreenConfiguration实例，该实例将成为当前活动的每平台显示多屏幕配置。
参数serviceContextAssociations如果不是null，则是字典实例，其关键字是ServiceContext实例而其值是String实例，其中字符串的值被定义如下：(1)如果字符串值是“-”，则没有屏幕使用(在这种情况下，在配置改变后，匹配的服务上下文不与任何屏幕关联)，(2)否则，如果字符串值是“*”，则使用新屏幕配置的所有屏幕，(3)否则，如果字符串值是如MultiScreenContext.getID()方法所返回的屏幕描述符，则使用该屏幕；(4)否则，如果字符串值是如MultiScreenContext.getScreenCategory()方法所返回的屏幕分类，则使用新配置的该分类的任何屏幕；(5)否则，如果字符串值用分号分隔的屏幕描述符的列表，则使用每个具有匹配的标志符的新配置的屏幕，(6)否则，如果字符串值是用分号分隔的屏幕分类的列表，则使用每个具有匹配分类的新配置的屏幕，(7)否则，如果字符串值是用分号分隔的屏幕标志符或屏幕分类的列表，则使用每个具有匹配标志符或分类的新配置的屏幕，(8)否则，使用新配置的默认服务上下文关联屏幕。
如果调用的线程没有被授予MonitorAppPermission(“multiscreen.configuration”)的权限，则setMultiScreenConfiguration()方法1682抛出java.lang.SecurityException的异常。
如果参数configuration不是要被MultiScreenManager.getMultiScreenConfigurations(SCREEN_CONFIGURATION_DISPLAY)方法返回的每平台多屏幕配置，则setMultiScreenConfiguration()方法1682抛出java.lang.IllegalArgumentException的异常。
如果MSM实施(1)不允许激活指定的多屏幕配置，(2)如果setMultiScreenConfiguration()方法1682之前被调用，且改变处理的步骤还没有完成，或者(3)如果在方法调用的时刻激活不被允许，则setMultiScreenConfiguration()方法1682抛出java.lang.IllegalStateException的异常。
setMultiScreenConfiguration()方法1682从MSM I01版本起被使用。
requestMultiScreenConfigurationChange方法1674被声明为public voidrequestMultiScreenConfigurationChange(MultiScreenConfigurationconfiguration，java.util.Dictionary serviceContextAssociations)，并请求对当前活动的每平台显示多屏幕配置的改变。
如果指定的configuration是当前的配置，则除非应用SecurityException，requestMultiScreenConfigurationChange方法1674返回值，而不产生任何副作用。
如果指定的configuration不是当前的每平台显示多屏幕配置，并且没有应用SecurityException、IllegalArgumentException和IllegalStateException，则requestMultiScreenConfigurationChange方法1674启动对当前的每平台多屏幕配置的异步改变，其中应用setMultiScreenConfiguration()方法1682的语义，除了requestMultiScreenConfigurationChange方法1674应该在MultiScreenConfguration.MULTI_SCREEN_CONFIGURATION_CHANGING事件生成之后(但在它被分派之前)立即返回。
参数configuration是MultiScreenConfiguration实例，该实例将成为当前活动的屏幕配置。serviceContextAssociations参数是null或Dictionary实例，其关键字是ServiceContext实例，而其值是String实例，并具有如上由setMultiScreenConfiguration()所定义的语义。
如果调用的线程没有被授予MonitorAppPermission(“multiscreen.configuration”)的权限，则requestMultiScreenConfigurationChange方法1674抛出java.lang.SecurityException的异常。
(1)如果MSM实施不允许激活指定的多屏幕配置，(2)如果requestMultiScreenConfigurationChange方法1674之前被调用，且改变处理的步骤还没有完成，或者(3)如果在方法调用的时刻激活不被允许，则requestMultiScreenConfigurationChange方法1674抛出java.lang.IllegalStateException的异常。
requestMultiScreenConfigurationChange方法1674从MSM I01版本起被使用。
addMultiScreenConfiguratioinListener方法1632被声明为public void addMultiScreenConfiguratioinListener(MultiScreenConfigurationListener listener)，并在多屏幕配置事件发生时，添加要通知的监听器。如果监听器之前已被添加且随后没有被移除，则尝试重复添加不会产生副作用。
应用到该MultiScreenManager单例实例的配置事件应该被限制为那些影响可用的显示屏幕的补集。
如果MultiScreenConfigurationEvent所定义的事件被产生，则MSM实施应该相应地通知每个已注册的屏幕配置监听器。
参数listener是MultiScreenConfigurationListener实例。
addMultiScreenConfiguratioinListener方法1632从MSM I01版本起被使用。
removeMultiScreenConfiguratioinListener方法1668被声明为public voidremoveMultiScreenConfiguratioinListener(MultiScreenConfigurationListenerlistener)，并在多屏幕配置事件发生时移除之前添加的要通知的监听器。如果指定的监听器当前没有被注册为监听器，则尝试移除它不会产生副作用。
参数listener是MultiScreenConfigurationListener实例。
removeMultiScreenConfiguratioinListener方法1668从MSM I01版本起被使用。
addResourceStatusListener方法1636被声明为public void addResourceStatusListener(org.davic.resources.ResourceStatusListener listener)，并添加资源状态监听器。
参数listener是ResourceStatusListener实例。
addResourceStatusListener方法1636从MSM I01版本起被使用。
removeResourceStatusListener方法1672被声明为public void removeResourceStatusListener(org.davic.resources.ResourceStatusListener listener)，并移除资源状态监听器。
参数listener是ResourceStatusListener实例。
removeResourceStatusListener方法1672从MSM I01版本起被使用。
swapServiceContext方法1684被声明为public void swapServiceContext(org.havi.ui.HScreen screen1，org.havi.ui.HScreen screen2，javax.tv.service.selection.ServiceContext[]exclusions)，并自动地在两个HScreen实例之间交换服务上下文。
swapServiceContext方法1684是方便的方法，用于支持在屏幕之间交换内容展示的一般功能。swapServiceContext方法1684得到的类似结果，也可以通过使用MultiScreenConfigurableContext.addServiceContext(..)和MultiScreenConfigurableContext.removeServiceContext(..)方法，由对特定可访问屏幕移除和添加服务上下文的更一般的机制来完成。但是，由于swapServiceContext方法1684的原子交换语义，使用更一般的方法可能造成比使用swapService Context方法1684更多的展示转换现象。
视频管线的解码器格式变换(DFC)组件的状态不应该被swapServiceContext方法1684的执行影响，该视频管线被用来处理与服务上下文关联的视频，该服务上下文被swapServiceContext方法1684交换。
参数screen1是HScreen实例，其服务上下文要与screen2的交换。
参数screen2是HScreen实例，其服务上下文要与screen1的交换。
参数exclusions如果不是null，则是要从交换操作排除的ServiceContext实例的非空集合，即，其屏幕关联不会被交换影响。
如果调用的线程没有被授予MonitorAppPermission(“multiscreen.configuration”)的权限，则swapServiceContext方法1684抛出java.lang.SecurityException的异常。
如果下列任一个成立，则swapServiceContext方法1684抛出java.lang.IllegalStateException的异常：(1)视频在任一个屏幕中被展示为组件视频而不是背景视频，或者(2)用于指定屏幕的ServiceContext不能被改变，例如，如果平台使用与特定ServiceContext和屏幕的永久关联。
swapServiceContext方法1684从MSM I01版本起被使用。
moveServiceContext方法1666被声明为public void moveServiceContext(org.havi.ui.HScreen src，org.havi.ui.HScreen dst，javax.tv.service.selection.ServiceContext[]contexts)，并自动地将一组特定的服务上下文从一个HScreen移动到另一个HScreen实例。
moveServiceContext方法1666是方便的方法，用于支持在屏幕之间针对一组给定的服务上下文移动内容展示的一般功能。moveServiceContext方法1666得到的类似结果，也可以通过使用MultiScreenConfigurableContext.addServiceContext(..)和MultiScreenConfigurableContext.removeServiceContext(..)方法，由对特定可访问屏幕移除和添加服务上下文的更一般的机制来完成。但是，由于moveServiceContext方法1666的原子移动语义，使用更一般的方法可能造成比使用moveServiceContext方法1666更多的展示转换现象。
视频管线的解码器格式变换(DFC)组件的状态不应该被moveServiceContext方法1666的执行影响，该视频管线被用来处理与服务上下文关联的视频，该服务上下文被moveServiceContext方法1666移动。
参数src是HScreen实例，指定的服务上下文从该实例移出。
参数dst是HScreen实例，指定的服务上下文向该实例移入。
参数contexts是要从输入src屏幕移到dst屏幕的ServiceContext实例的非空数组。
如果调用的线程没有被授予MonitorAppPermission(“multiscreen.configuration”)的权限，则moveServiceContext方法1666抛出java.lang.SecurityException的异常。
如果某个指定的ServiceContext当前没有和源HScreen关联，则moveServiceContext方法1666方法抛出java.lang.IllegalArgumentException的异常。
如果下列任一个成立，则moveServiceContext方法1666抛出java.lang.IllegalStateException的异常：(1)视频在任一个屏幕中被展示为组件视频而不是背景视频；(2)用于指定屏幕的ServiceContext不能被移动，例如，如果平台使用与特定ServiceContext和屏幕的永久关联；或者(3)非抽象的ServiceContext已经和目标屏幕关联，且平台只支持每个屏幕一个非抽象ServiceContext。
moveServiceContext方法1666从MSM I01版本起被使用。
getPlayerScreenDevices方法1658被声明为public org.havi.ui.HScreenDevice[]getPlayerScreenDevice(javax.media.Player player)，并获取当前被分配给Java媒体框架(JMF)媒体播放器使用的屏幕装置的集合。
参数player是JMF Player实例，要查询其屏幕装置的集合。
getPlayerScreenDevices方法1658是HScreenDevice实例的数组，当且仅当没有关联的屏幕装置时，它返回空。
getPlayerScreenDevices方法1658从MSM I01版本起被使用。
addPlayerScreenDevices方法1634被声明为public void addPlayerScreenDevices(javax.media.Player player，org.havi.ui.HScreenDevice[]devices)，将屏幕装置加到媒体播放器。
参数player是JMF Player实例，要查询指定的屏幕装置。参数devices是HScreenDevice实例的非空数组，在该HScreenDevice上展示来自指定媒体播放器的某种类型的呈现的内容。
如果调用的线程没有被授予MonitorAppPermission(“multiscreen.context”)的权限，则addPlayerScreenDevices方法1634抛出java.lang.SecurityException的异常。
如果下列任一个成立，则addPlayerScreenDevices方法1634抛出java.lang.IllegalStateException的异常：(1)指定的player不是处于停止状态；(2)指定的屏幕device和指定的player不兼容；(3)devices的某个基本屏幕装置不能被本应用程序使用，例如，由于被另一个应用程序排他性地保留了；或者(4)devices的某个基本屏幕装置已经和媒体播放器关联，并且该装置不支持与多个媒体播放器的关联。
addPlayerScreenDevices方法1634从MSM I01版本起被使用。
关于addPlayerScreenDevices方法1634的更详细的信息，可以参考Player、HScreenDevice实例来获得。
removePlayerScreenDevices方法1670被声明为public void removePlayerScreenDevices(javax.media.Player player，org.havi.ui.HScreenDevice[]devices)，并从媒体播放器移除屏幕装置。换句话说，所有或一个非空集合的HScreenDevice实例从指定媒体播放器在其上展示(或关联用于展示)的屏幕装置集合中移除。如果devices是null，者移除所有屏幕装置关联。
如果调用的线程没有被授予MonitorAppPermission(“multiscreen.context”)的权限，则removePlayerScreenDevices方法1670抛出java.lang.SecurityException的异常。
如果devices不是null，并且devices中的某个元素不与指定的媒体播放器关联，则removePlayerScreenDevices方法1670抛出java.lang.IllegalArgumentException的异常。
如果指定的player不是处于停止状态，则removePlayerScreenDevices方法1670抛出java.lang.IllegalStateException的异常。
removePlayerScreenDevices方法1670从MSM I01版本起被使用。
getEmptyScreen()方法1644被声明为public org.havi.ui.HScreen getEmptyScreen()，并获取单例的空HScreen实例。
使用该空HScreen，getEmptyScreen()方法1644可以获取对每个可用子类的空HScreenDevice、空HScreenConfiguration和空HScreenConfigTemplate的引用，例如，HBackgroundDevice、HVideoDevice、HGraphicsDevice等。
getEmptyScreen()方法1644的存在主要目的在于支持测试MSM的功能，例如isEmptyScreen()、isEmptyScreenDevice()、sameResources()等的语义。
getEmptyScreen()方法1644返回空HScreen单例。
getEmptyScreen()方法1644从MSM I01版本起被使用。
isEmptyScreen()方法1662被声明为public boolean isEmptyScreen(org.havi.ui.HScreen screen)，并确定HScreen实例在满足限制时是否等于空HScreen。
如果screen没有实现MultiScreenConfigurableContext，则适于MultiScreenConfigurableContext的那些限制应该被认为是相等的。
参数screen是HScreen实例。
如果指定的screen等于空HScreen，则isEmptyScreen()方法1662返回true。
isEmptyScreen()方法1662从MSM I01版本起被使用。
isEmptyScreenDevice()方法1664被声明为public boolean isEmptyScreenDevice(org.havi.ui.HScreenDevice device)，并确定HScreenDevice实例在满足限制时是否等于特定子类型的空HScreenDevice。
参数device是下列子类型中的一个的HScreenDevice实例：HBackgroundDevice、HVideoDevice或HgraphicsDevice。
如果指定的device等于匹配子类型的空HScreenDevice，则isEmptyScreenDevice()方法1664返回true。
isEmptyScreenDevice()方法1664从MSM I01版本起被使用。
sameResources(HScreen，HScreen)方法1678被声明为public booleansameResouces(org.havi.ui.HScreen screen1，org.havi.ui.HScreen screen2)，并确定两个HScreen实例是否表示相同的基本平台资源和基本资源状态，即，关于这些基本资源是相等的。
为了确定相等性的目的，应使用下列条件：
·如果screen1和screen2中正好有一个等于空HScreen，则两个屏幕关于基本资源是不相等的；
·如果对于由screen1.getBackgroundDevices()返回的每个屏幕装置BD1，不存在正好由screen2.getBackgroundDevices()返回的一个屏幕装置BD2，从而sameResources(BD1，BD2)返回true，则两个屏幕关于基本资源是不相等的；
·如果对于由screen1.getVideoDevices()返回的每个屏幕装置VD1，不存在正好由screen2.getVideoDevices()返回的一个屏幕装置VD2，从而sameResources(VD1，VD2)返回true，则两个屏幕关于基本资源是不相等的；
·如果对于由screen1.getGraphicsDevices()返回的每个屏幕装置GD1，不存在正好由screen2.getGraphicsDevices()返回的一个屏幕装置GD2，从而sameResources(GD1，GD2)返回true，则两个屏幕关于基本资源是不相等的；
·如果给定相等的模板参数集合，screen1.getBestConfiguration(..)和screen2.getBestconfiguration(..)不会返回(名义上无序的)相等的HScreenConfguration实例的集合，则两个屏幕关于基本资源是不相等的；
·如果给定相等的屏幕配置参数集合，screen1.setCoherentScreenConfigurations(..)和screen2.setCoherentScreenConfigurations(..)不会返回相同HScreenConfiguration实例的集合，则两个屏幕源于基本资源是不相等；
·如果给定相等的屏幕配置参数集合，screen1.setCoherentScreenConfigurations(..)和screen2.setCoherentScreenConfigurations(..)不会返回相同的值，或者不会修改与指定屏幕配置参数关联的屏幕装置集合，从而这些屏幕装置保持相等，则两个屏幕关于基本资源是不相等的；
·如果上述条件都不成立，则screen1和screen2被认为是关于基本资源相等的。
参数screen1和screen2是HScreen实例。
如果指定的屏幕如上条件所述是相等的，则返回true值。
sameResources(HScreen，HScreen)方法1678从MSM I01版本起被使用。
sameResources(HScreenDevice，HScreenDevice)方法1676被声明为public boolean sameResources(org.havi.ui.HScreenDevice device1，org.havi.ui.HScreenDevice device2)，并确定两个HScreenDevice实例是否表示相同的基本平台资源和基本资源状态，即，关于这些基本资源是相等的。
为了确定相等性的目的，应使用下列条件：
·如果device1和device2不是相同的子类型HBackgroundDevice、HVideoDevice或HgraphicsDevice，则两个屏幕装置关于基本资源是不相等的；
·如果device1和device2中正好有一个等于合适子类型的空HScreenDevice，则两个屏幕装置关于基本资源是不相等的；
·如果device1.getFlickerFilter()和device2.getFlickerFilter()不会返回相同的值，则两个屏幕装置关于基本资源是不相等的；
·如果device1.getInterlaced()和device2.getInterlaced()不会返回相同的值，则两个屏幕装置关于基本资源是不相等的；
·如果device1.getPixelAspectRatio()和device2.getPixelAspectRatio()不会返回相等的值，则两个屏幕装置关于基本资源是不相等的；
·如果device1.getPixelResolution()和device2.getPixelResolution()不会返回相等的值，则两个屏幕装置关于基本资源是不相等的；
·如果device1.getScreenArea()和device2.getScreenArea()不会返回相等的值，则两个屏幕装置关于基本资源是不相等的；
·如果给定相等的HScreenConfiguration实例SC1和SC2作为参数，device1.getOffset(SC1)和device2.getOffset(SC2)不会返回相等的值，则两个屏幕装置关于基本资源是不相等的；
·如果给定相等的HScreenConfiguration实例SC1和SC2及相等的Point实例P1和P2作为参数，device1.convertTo(SC1，P1)和device2.convertTo(SC2，P2)不会返回相等的值，则两个屏幕装置关于基本资源是不相等的；
·如果device1.getConfigurations()和device2.getConfigurations()不会返回(名义上无序的)相等的HScreenConfiguration实例的集合，则两个屏幕关于基本资源是不相等的；
·如果device1.getCurrentConfiguration()和device2.getCurrentConfiguration()不会返回相等的HScreenConfiguration实例的集合，则两个屏幕关于基本资源是不相等的；
·如果device1.getDefaultConfiguration()和device2.getDefaultConfiguration()不会返回相等的HScreenConfiguration实例的集合，则两个屏幕关于基本资源是不相等的；
·如果给定相等的模板参数或模板参数集合，device1.getBestConfguration(...)和device2.getBestConfiguration(...)不会返回相等的HScreenConfiguraion实例的集合，则两个屏幕关于基本资源是不相等的；
·如果device1和device2是HBackgroundDevice的实例，并且在相等的HBackgroundConfiguration实例被指定为参数时，device1.setBackgroundConfiguration(..)和device2.setBackgroundConfiguration(..)不会返回相等的值，则两个屏幕关于基本资源是不相等的；
·如果device1和device2是HVideoDevice的实例，并且如果(1)在相等的HVideoConfiguration实例被指定为参数时，device1.setVideoConfiguration(..)和device2.setVideoConfiguration(..)不会返回相等的值，(2)device1.getVideoSource()和device2.getVideoSource()不会返回名义上相等的视频源，(3)device1.getVideoController()和device2.getVideoController()不会返回名义上相等的视频控制器，则两个屏幕关于基本资源是不相等的；
·如果device1和device2是HGraphicsDevice的实例，并且在相等的HGraphicsConfiguration实例被指定为参数时，device1.setGraphicConfiguration(..)和device2.setGraphicsConfiguration(..)不会返回相等的值，则两个屏幕关于基本资源是不相等的；
·如果上述条件都不成立，则device1和device2被认为是关于基本资源相等的。
参数device1和device2是HScreenDevice实例。
如果指定的屏幕如上条件所述是相等的，sameResources(HScreenDevice，HScreenDevice)方法1676返回true。
sameResources(HScreenDevice，HScreenDevice)方法1676从MSM I01版本起被使用。
sameResources(ServiceContext，ServiceContext)方法1680被声明为publicboolean sameResources(javax.tv.service.selection.ServiceContext scl，javax.tv.service.selection.ServiceContext sc2)，并确定两个ServiceContext实例是否表示相同的基本平台资源和基本资源状态，即，关于这些基本资源是相等的。
参数sc1和sc2是ServiceContext实例。
如果指定的服务上下文相等(即，表示相同的基本资源和资源状态)，则sameResources(ServiceContext，ServiceContext)方法1680返回true。
sameResources(ServiceContext，ServiceContext)方法1680从MSM I01版本起被使用。
getInstance()方法1646被声明为public static MultiScreenManager getInstance()，并得到MultiScreenManager的单例实例。MultiScreenManager实例被返回。
getInstance()方法1646从MSM I01版本起被使用。
图17示出了根据本发明的实施例的org.ocap.ui.event包的接口1700和类1710。
org.ocap.ui.event包具有对HAVi用户接口事件类的扩展，包括OCAP特定远程控制事件和多屏幕管理事件。
org.ocap.ui.event包的接口1700包括MultiScreenConfigurationListener接口1702和MultiScreenContextListener接口1704中的至少一个。
MultiScreenConfigurationListener接口1702被用来提供关于下列变化的通知：系统和应用程序引发的分别对MultiScreenManager实例的全局状态或某个显示HScreen关于每平台或某个每显示多屏幕配置的状态的改变，或者对特定MultiScreenConfiguration实例的改变。
MultiScreenContextListener接口1704被用来提供关于系统和应用程序引发的对MultiScreenContext改变的通知。
org.ocap.ui.event包的类1710包括MultiScreenConfigurationEvent类1712、MultiScreenContextEvent类1714、MultiScreenEvent类1716和MultiScreenResourceEvent类1718中的至少一个。
MultiScreenConfigurationEvent类1712被用来报告分别对MultiScreenManager实例的全局状态或某个显示HScreen关于每平台或某个每显示多屏幕配置的状态的改变，或对特定MultiScreenConfiguration实例的改变。
MultiScreenContextEvent类1714被用来将对MultiScreenContext的改变报告给感兴趣的监听器。
MultiScreenEvent类1716是抽象的基类，被用来组织事件识别码，该识别码被与多屏幕管理功能相关的不同类型的事件使用。
MultiScreenResourceEvent类1718被用来报告关于多屏幕相关资源的资源状态的改变。
图18A示出了根据本发明的实施例的org.ocap.ui.event包的MultiScreenConfigurationEvent类1712的定义。
org.ocap.ui.event包的MultiScreenConfigurationEvent类1712的Java类型被定义为java.lang.Object的子级别java.util.EventObjectd的子级别org.ocap.ui.event.MultiScreenEvent的子级别。
org.ocap.ui.event包的MultiScreenConfigurationEvent类1712包括java.io.Serializable作为全部实现接口(All Implemented Interface)，被定义为publicclass MultiScreenConfigurationEvent，并扩展MultiScreenEvent。
MultiScreenConfigurationEvent类1712被用来报告分别对MultiScreenManager实例的全局状态或某个显示HScreen关于每平台或某个每显示多屏幕配置的状态的改变，或对特定MultiScreenConfiguration实例的改变。
下列类型的改变将引起MultiScreenConfigurationEvent类1712的产生：
·如MultiScreenManager所确定的当前活动的每平台多屏幕配置从一个多屏幕配置改变为另一个多屏幕配置；
·如某个显示HScreen所确定的当前活动的每显示多屏幕配置从一个多屏幕配置改变为另一个多屏幕配置；
·与MultiScreenConfiguration关联的屏幕集合改变(即，屏幕被添加到多屏幕配置或从多屏幕配置移除)；
org.ocap.ui.event包的MultiScreenConfigurationEvent类1712从MSM I01版本起被使用。
图18B示出了根据本发明的实施例的org.ocap.ui.event包的MultiScreenConfigurationEvent类1712的字段1800。
org.ocap.ui.event包的MultiScreenConfigurationEvent类1712的字段1800包括以下中的至少一个：static int MULTI_SCREEN_CONFIGURATION_CHANGED字段1802、static int MULTI_SCREEN_CONFIGURATION_CHANGING字段1804、static int MULTI_SCREEN_CONFIGURATION_LAST字段1806、static int MULTI_SCREEN_CONFIGURATION_ADDED字段1808以及static int MULTI_SCREEN_CONFIGURATION_SCREEN_REMOVED字段1810。
从org.ocap.ui.event包的MultiScreenEvent类1716继承的字段1820包括MULTI_SCREEN_CONFIGURATION_FIRST和MULTI_SCREEN_CONTEXT_FIRST中的至少一个。
从java.util.EventObject类继承的字段1825包括Source。
MULTI_SCREEN_CONFIGURATION_CHANGING字段1804被声明为public static final int MULTI_SCREEN_CONFIGURATION_CHANGING。对当前活动的每平台或MultiScreenManager所确定的某个每显示MultiScreenConfiguration或某个显示HScreen的改变被启动，在该情况下，getSource()返回的值应该是被影响的MultiScreenManager或显示HScreen，并且getRelated()返回的值应该是随后活动的MultiScreenConfiguration。
MULTI_SCREEN_CONFIGURATION_CHANGING字段1804不应被分派给未被授予MonitorAppPermission(“multiscreen.configuration”)的权限的应用程序。
MULTI_SCREEN_CONFIGURATION_CHANGING字段1804从MSMI01版本起被使用。
MULTI_SCREEN_CONFIGURATION_CHANGED字段1802被声明为public static final int MULTI_SCREEN_CONFIGURATION_CHANGED。当前活动的每平台或MultiScreenManager所确定的某个每显示MultiScreenConfiguration或某个显示HScreen已经改变，在该情况下，getSource()返回的值应该是被影响的MultiScreenManager或显示HScreen，并且getRelated()返回的值应该是之前活动的MultiScreenConfiguration。
MULTI_SCREEN_CONFIGURATION_CHANGED字段1802从MSMI01版本起被使用。
MULTI_SCREEN_CONFIGURATION_ADDED字段1808被声明为public static final int MULTI_SCREEN_CONFIGURATION_ADDED。与MultiScreenConfiguration关联的屏幕集合已经改变，且已添加了新的屏幕，在该情况下，getSource()返回的值应该是被影响的MultiScreenConfiguration，且getRelated()返回的值应该是新添加的HScreen。
除了在最后分派MULTI_SCREEN_CONFIGURATION_CHANGING字段1804和生成MULTI_SCREEN_CONFIGURATION_CHANGED字段1802之间的间隔时段期间，屏幕不应该被加到多屏幕配置且不应该对该多屏幕配置产生MULTI_SCREEN_CONFIGURATION_ADDED字段1808，该多屏幕配置是当前的每平台或某个当前每显示多屏幕配置。
MULTI_SCREEN_CONFIGURATION_ADDED字段1808从MSM I01版本起被使用。
MULTI_SCREEN_CONFIGURATION_REMOVED字段1810被声明为public static final int MULTI_SCREEN_CONFIGURATION_REMOVED。与MultiScreenConfiguration关联的屏幕集合已经改变，且已移除了现有的屏幕，在该情况下，getSource()返回的值应该是被影响的MultiScreenConfiguration，且getRelated()返回的值应该是新移除的HScreen。
除了在最后分派MULTI_SCREEN_CONFIGURATION_CHANGING字段1804和生成MULTI_SCREEN_CONFIGURATION_CHANGED字段1802之间的间隔时段期间，屏幕不应该从多屏幕配置移除且不应该对该多屏幕配置产生MULTI_SCREEN_CONFIGURATION_REMOVED字段1810，该多屏幕配置是当前的每平台或某个当前每显示多屏幕配置。
MULTI_SCREEN_CONFIGURATION_REMOVED字段1810从MSMI01版本起被使用。
MULTI_SCREEN_CONFIGURATION_LAST字段1806被声明为publicstatic final int MULTI_SCREEN_CONFIGURATION_LAST，并且是分配给MultiScreenConfigurationEvent事件标志符的最后的事件标志符。
MULTI_SCREEN_CONFIGURATION_LAST字段1806从MSM I01版本起被使用。
图18C示出了根据本发明的实施例的org.ocap.ui.event包的MultiScreenConfigurationEvent类1712的构造函数1830。
构造函数1830包括MultiScreenConfigurationEvent(java.lang.Objectsource，int id，java.lang.Object related)1832。
构造函数1830被声明为public MultiScreenConfigurationEvent(java.lang.Object source，int id，java.lang.Object related)，并构造MultiScreenConfigurationEvent类1712。
根据上面指定的事件，参数source是对MultiScreenManager、显示HScreen实例或MultiScreenConfiguration实例的引用。
参数id是该事件的事件标志符，其值应该是下列中的一个：MULTI_SCREEN_CONFIGURATION_CHANGING、MULTI_SCREEN_CONFIGURATION_CHANGED、MULTI_SCREEN_CONFIGURATION_ADDED、MULTI_SCREEN_CONFIGURATION_REMOVED。
根据上面指定的特定事件，参数related是对MultiScreenConfiguration实例或HScreen实例的引用。
MultiScreenConfigurationEvent类1712的构造函数1830从MSM I01版本起被使用。
图18D示出了根据本发明的实施例的org.ocap.ui.event包的MultiScreenConfigurationEvent类1712的方法1840。
org.ocap.ui.event包的MultiScreenConfigurationEvent类1712的方法1840包括java.lang.Object.getRelated()方法1842，从类org.ocap.ui.event.MultiScreenEvent继承的方法1850包括getId，从类java.util.EventObject继承的方法1852包括getSource、toString中的至少一个，从类java.lang.Object继承的方法1854包括clone、equals、fnalize、getClass、hashCode、notify、notifyAll、wait、wait和wait中的至少一个。
getRelated()方法1842被声明为public java.lang.Object getRelated()，并得到该事件的相关对象。即，getRelated()方法1842返回该事件相关的对象实例，其值应该是由特定事件类型确定的下列之一：对MultiScreenConfiguration实例的引用，或对HScreen实例的引用。
getRelated()方法1842从MSM I01版本起被使用。
图19A示出了根据本发明的实施例的org.ocap.ui.event包的MultiScreenConfigurationListener接口1702的定义。
org.ocap.ui.event包的MultiScreenConfigurationListener接口1702包括java.util.EventListener作为超接口，被声明为public interface MultiScreenConfigurationListener，并扩展java.util.EventListener。
MultiScreenConfigurationListener接口1702被用来提供关于下列变化的通知：系统和应用程序引发的分别对MultiScreenManager实例的全局状态或某个显示HScreen关于每平台或某个每显示多屏幕配置的状态的改变，或者对特定MultiScreenConfiguration实例的改变。
MultiScreenConfigurationListener接口1702从MSM I01版本起被使用。
图19B示出了根据本发明的实施例的org.ocap.ui.event包的MultiScreenConfigurationListener接口1702的方法1900。
org.ocap.ui.event包的MultiScreenConfigurationListener接口1702的方法1900包括void notify(MultiScreenConfigurationEvent evt)方法1910。
void notify方法1910被声明为void notify(MultiScreenConfigurationEventevt)。在生成MultiScreenConfigurationEvent时，该实现应该在所有已注册的监听器上调用void notify方法1910，以向每个监听器报告事件信息，如特定的时间语义所需。
在事件是MultiScreenConfigurationEvent.MULTI_SCREEN_CONFIGURATION_CHANGING时，void notify方法1910不会被调用，直到注册该监听器的应用程序已经被授予MonitorApp Permission(“multiscreen.configuration”)的权限。此外，void notify方法1910的实现应该严格限制可以发生的处理的数量，因为对于所有可用的监听器的集合，绝对时间限制被施加到对void notify方法1910的调用。
参数evt是MultiScreenConfigurationEvent实例。
void notify方法1910从MSM I01版本起被使用。
图20A示出了根据本发明的实施例的org.ocap.ui.event包的MultiScreenContextEvent类1714的定义。
org.ocap.ui.event包的MultiScreenContextEvent类1714被定义为java.lang.Object的子级别java.util.EventObject的子级别org.ocap.ui.event.MultiScreenEvent的子级别。
org.ocap.ui.event包的MultiScreenContextEvent类1714的所有实现的接口包括java.io.Serializable、被声明为public class MultiScreenContextEvent，并扩展MultiScreenEvent。
MultiScreenContextEvent类1714被用来向感兴趣的监听器报告对MultiScreenContext的改变。
下列类型的改变导致MultiScreenContextEvent类1714的产生：
·关联的ServiceContext的改变；
·关联的显示HScreen的改变；
·关联的显示HScreen的区域(范围)分配的改变；
·关联的VideoOutputPort集合的改变；
·显示HScreen的音频焦点的改变；
·屏幕可见性的改变；
·屏幕z-顺序的改变。
·向HScreen贡献音频源的基本HScreenDevice的集合的改变；
·基本HScreenDevice实例的集合的改变，例如，由于从HScreen添加或移除HScreenDevice；
·HScreen的基本HScreenDevice实例的z-顺序的改变。
org.ocap.ui.event包的MultiScreenContextEvent类1714从MSM I01版本起被使用。
图20B示出了根据本发明的实施例的org.ocap.ui.event包的MultiScreenContextEvent类1714的字段2000。
org.ocap.ui.event包的MultiScreenContextEvent类1714的字段2000包括以下的至少一个：static int MULTI_SCREEN_CONTEXT_AUDIO_FOCUS_CHANGED字段2002、static int MULTI_SCREEN_CONTEXT_AUDIO_SOURCE_CHANGED字段2004、static int MULTI_SCREEN_CONTEXT_DEVICES_CHANGED字段2006、static int MULTI_SCREEN_CONTEXT_DEVICES_Z_ORDER_CHANGED字段2008、static int MULTI_SCREEN_CONTEXT_DISPLAY_AREA_CHANGED字段2010、static int MULTI_SCREEN_CONTEXT_DISPLAY_SCREEN_CHANGED字段2012、static intMULTI_SCREEN_CONTEXT_OUTPUT_PORT_CHANGED字段2014、staticint MULTI_SCREEN_CONTEXT_SERVICE_CONTEXT_CHANGED字段2016、static int MULTI_SCREEN_CONTEXT_VISIBILITY_CHANGED字段2018、static int MULTI_SCREEN_CONTEXT_Z_ORDER_CHANGED字段2020和static int MULTI_SCREEN_CONTEXTS_LAST字段2022。
从org.ocap.ui.event.MultiScreenEvent继承的字段2030包括MULTI_SCREEN_CONFIGURATION_FIRST和MULTI_SCREEN_CONTEXT_FIRST中的至少一个。从java.util.EventObject继承的字段2035包括Source。
MULTI_SCREEN_CONTEXT_DEVICES_CHANGED字段2006被声明为public static final int MULTI_SCREEN_CONTEXT_DEVICES_CHANGED，并对应于下列情况：与源MultiScreenContext的基本HScreen关联的HScreenDevice实例集合已经改变。
MULTI_SCREEN_CONTEXT_DEVICES_CHANGED字段2006从MSMI01版本起被使用。
MULTI_SCREEN_CONTEXT_DEVICES_Z_ORDER_CHANGED字段2008被声明为public static final int MULTI_SCREEN_CONTEXT_DEVICES_Z_ORDER_CHANGED，并对应于下列情况：与源MultiScreenContext的基本HScreen关联的HScreenDevice实例集合的z-顺序已经改变。
MULTI_SCREEN_CONTEXT_DEVICES_Z_ORDER_CHANGED字段2008从MSM I01版本起被使用。
MULTI_SCREEN_CONTEXT_SERVICE_CONTEXT_CHANGED字段2016被声明为public static final int MULTI_SCREEN_CONTEXT_SERVICE_CONTEXT_CHANGED，并对应于下列情况：与源MultiScreenContext的基本HScreen关联的ServiceContext已经改变。
MULTI_SCREEN_CONTEXT_SERVICE_CONTEXT_CHANGED字段2016从MSM I01版本起被使用。
MULTI_SCREEN_CONTEXT_DISPLAY_SCREEN_CHANGED字段2012被声明为public static final int MULTI_SCREEN_CONTEXT_DISPLAY_SCREEN_CHANGED，并对应于下列情况：与源代码MultiScreenContext的基本HScreen关联的显示HScreen已经改变。
MULTI_SCREEN_CONTEXT_DISPLAY_SCREEN_CHANGED字段2012从MSM I01版本起被使用。
MULTI_SCREEN_CONTEXT_DISPLAY_AREA_CHANGED字段2010被声明为public static final int MULTI_SCREEN_CONTEXT_DISPLAY_AREA_CHANGED，并对应于下列情况：源MultiScreenContext的基本HScreen所分配的显示HScreen的区字段(范围)已经改变。
MULTI_SCREEN_CONTEXT_DISPLAY_AREA_CHANGED字段2010从MSM I01版本起被使用。
MULTI_SCREEN_CONTEXT_OUTPUT_PORT_CHANGED字段2014被声明为public static final int MULTI_SCREEN_CONTEXT_OUTPUT_PORT_CHANGED，并对应于与源MultiScreenContext的基本HScreen关联的视频输出端口集合已经改变。
MULTI_SCREEN_CONTEXT_OUTPUT_PORT_CHANGED字段2014从MSM I01版本起被使用。
MULTI_SCREEN_CONTEXT_VISIBILITY_CHANGED字段2018被声明为static int final int MULTI_SCREEN_CONTEXT_VISIBILITY_CHANGED，并对应于下列情况：源MultiScreenContext的基本HScreen的可见性已经改变。
MULTI_SCREEN_CONTEXT_VISIBILITY_CHANGED字段2018从MSM I01版本起被使用。
MULTI_SCREEN_CONTEXT_Z_ORDER_CHANGED字段2020被声明为public static final int MULTI_SCREEN_CONTEXT_Z_ORDER_CHANGED，并对应于下列情况：源MultiScreenContext的基本HScreen的z-顺序已经改变。
MULTI_SCREEN_CONTEXT_Z_ORDER_CHANGED字段2020从MSM I01版本起被使用。
MULTI_SCREEN_CONTEXT_AUDIO_SOURCES_CHANGED字段2004被声明为public static final int MULTI_SCREEN_CONTEXT_AUDIO_SOURCES_CHANGED，并对应于下列情况：源MultiScreenContext的基本HScreen的音频源已经改变。
MULTI_SCREEN_CONTEXT_AUDIO_SOURCES_CHANGED字段2004从MSM I01版本起被使用。
MULTI_SCREEN_CONTEXT_AUDIO_FOCUS_CHANGED字段2002被声明为public static final int MULTI_SCREEN_CONTEXT_AUDIO_FOCUS_CHANGED，并对应于下列情况：源MultiScreenContext的基本HScreen的音频焦点已经改变。当显示HScreen的音频焦点屏幕改变时，则该事件(在完成该改变后)将产生两次：第一次是对已经失去音频焦点的逻辑屏幕的MultiScreenContext的改变(如果这样的逻辑屏幕存在)，而第二次是对显示屏幕的MultiScreenContext的改变。在这两种情况下，源MultiScreenContext应该是显示屏幕。
MULTI_SCREEN_CONTEXT_AUDIO_FOCUS_CHANGED字段2002从MSM I01版本起被使用。
MULTI_SCREEN_CONTEXTS_LAST字段2022被声明为public staticfinal int MULTI_SCREEN_CONTEXTS_LAST，并且是分配给MultiScreenContextEvent事件标志符的最后的事件标志符。
MULTI_SCREEN_CONTEXTS_LAST字段2022从MSM I01版本起被使用。
图20C示出了根据本发明的实施例的org.ocap.ui.event包的MultiScreenContextEvent类1714的构造函数2040。
构造函数2040包括MultiScreenContextEvent(java.lang.Object source，intid)(2042)。
构造函数2040被声明为public MultiScreenContextEvent(java.lang.Object source，int id)，并构造MultiScreenContextEvent类1714。
参数source是对MultiScreenContext接口的引用。
参数id是该事件的事件标志符，其值应该等于下列中的一个：MULTI_SCREEN_CONTEXT_DEVICES_CHANGED字段2006、MULTI_SCREEN_CONTEXT_DEVICES_Z_ORDER_CHANGED字段2008、MULTI_SCREEN_CONTEXT_SERVICE_CONTEXT_CHANGED字段2016、MULTI_SCREEN_CONTEXT_DISPLAY_SCREEN_CHANGED字段2012、MULTI_SCREEN_CONTEXT_DISPLAY_AREA_CHANGED字段2010、MULTI_SCREEN_CONTEXT_OUTPUT_PORT_CHANGED  字段2014、MULTI_SCREEN_CONTEXT_VISIBILITY_CHANGED字段2018、MULTI_SCREEN_CONTEXT_Z_ORDER_CHANGED字段2020、MULTI_SCREEN_CONTEXT_AUDIO_SOURCES_CHANGED字段2004和MULTI_SCREEN_CONTEXT_AUDIO_FOCUS_CHANGED字段2002。
MultiScreenContextEvent类1714的构造函数2040从MSM I01版本起被使用。
图20D示出了根据本发明的实施例的org.ocap.ui.event包的MultiScreenContextEvent类1714的方法2050。
org.ocap.ui.event包的MultiScreenContextEvent类1714的方法2050包括getId，而从类java.util.eventObject继承的方法2054包括getSource和toString中的至少一个。从类java.lang.Object继承的方法2056包括clone、equals、finalize、getClass、hashCode、notify、notifyAll、wait、wait和wait中的至少一个。
图21A示出了根据本发明的实施例的org.ocap.ui.event包的MultiScreenConfigurationListener接口1702的定义。
org.ocap.ui.event包的MultiScreenConfigurationListener接口1702包括java.util.eventListener作为超接口，被声明为public interface MultiScreenContextListerner，并扩展java.util.EventListener。
MultiScreenConfigurationListener接口1702被用来提供关于系统和应用程序引发的对MultiScreenContext的改变的通知。
MultiScreenConfigurationListener接口1702从MSM I01版本起被使用。
图21B示出了根据本发明的实施例的org.ocap.ui.event包的MultiScreenConfigurationListener的方法2100。
org.ocap.ui.event包的MultiSereenConfigurationListener的方法2100包括void notify(MultiScreenContextEvent evt)方法2102。
void notify(MultiScreenContextEvent)方法2102被声明为void notify(MultiScreenContextEvent evt)。当OCAP实施对MultiScreenContext做出任何改变，该改变导致MultiScreenContextEvent的产生，则该实施应该在所有已注册的监听器上调用void notify(MultiScreenContextEvent)方法2102，以将改变信息报告给监听器。
如果注册该监听器的应用程序没有被授予MonitorAppPermission(“multiscreen.context”)的权限，且与指定MultiScreenContextEvent关联的源MultiScreenContext没有和ServiceContext关联，或者和该应用程序不能访问的ServiceContext关联，则void notify(MultiScreenContextEvent)方法2102不应该在该监听器上被调用；否则，它应该在该监听器上被调用。
如果ServiceContext是从ServiceContextFactory.getServiceContexts()方法返回的，则它可以被应用程序访问。
参数evt是MultiScreenContextEvent实例。
void notify(MultiScreenContextEvent)方法2102从MSM I01版本起被使用。
图22A示出了根据本发明的实施例的org.ocap.ui.event包的MultiScreenEvent类1716的定义。
org.ocap.ui.event包的MultiScreenEvent类1716被定义为java.lang.Object的子级别的java.util.eventObject的子级别。
org.ocap.ui.event包的MultiScreenEvent类1716包括java.io.Serializable作为所有实现的接口(All Implemented Interfaces)，并包括MultiScreenConfigurationEvent和MultiScreenContextEvent中的至少一个作为直属已知子类(Direct Known Subclass)。
org.ocap.ui.event包的MultiScreenEvent类1716被声明为public abstractclass MultiScreenEvent，并扩展java.util.EventObject。
MultiScreenEvent是抽象的基类，被用来组织被与多屏幕管理功能相关的不同类型事件使用的事件标志符代码。
org.ocap.ui.event包的MultiScreenEvent类1716从MSM I01版本起被使用。
图22B示出了根据本发明的实施例的org.ocap.ui.event包的MultiScreenEvent类1716的字段2200。
org.ocap.ui.event包的MultiScreenEvent类1716的字段2200包括static intMULTI_SCREEN_CONFIGURATION_FIRST字段2202和static int MULTI_SCREEN_CONTEXT_FIRST字段2204中的至少一个。从类java.util.EventObject继承的字段2210包括source。
SCREEN_CONFIGURATION_FIRST字段2202被声明为public staticfinal int SCREEN_CONFIGURATION_FIRST，并且是分配给MultiScreenConfigurationEvent事件标志符的第一个事件标志符。
SCREEN_CONFIGURATION_FIRST字段2202从MSM I01版本起被使用。
MULTI_SCREEN_CONTEXT_FIRST字段2204被声明为public staticfinal int MULTI_SCREEN_CONTEXT_FIRST，并且是分配给MultiScreenContextEvent事件标志符的第一个事件标志符。
MULTI_SCREEN_CONTEXT_FIRST字段2204从MSM I01版本起被使用。
图22C示出了根据本发明的实施例的org.ocap.ui.event包的MultiScreenEvent类1716的构造函数2220。
org.ocap.ui.event包的MultiScreenEvent类1716的构造函数2220包括protected MultiScreenEvent(java.lang.Object source，int id)(2222)中的至少一个。
org.ocap.ui.event包的MultiScreenEvent类1716的构造函数2220被声明为protected MultiScreenEvent(java.lang.Object source，int id)，并且是MultiScreenEvent的受保护的构造函数。
参数source是对事件源的引用，该事件源由MultiScreenEvent类1716的具体子类来定义。
参数id是MultiScreenEvent类1716的事件标志符。
MultiScreenEvent类1716的构造函数2220从MSM I01版本起被使用。
图22D示出了根据本发明的实施例的org.ocap.ui.event包的MultiScreenEvent类1716的方法2230。
org.ocap.ui.event包的MultiScreenEvent类1716的方法2230包括intgetId()方法2232。从类java.util.EventObject继承的方法2240包括getSource和getString中的至少一个。从类java.lang.Object继承的方法2245包括clone、equals、finalize、getClass、hashCode、notify、notifyAll、wait、wait和wait中的至少一个。
int getId()方法2232被声明为public int getId()，并获取与MultiScreenEvent类关联的事件标志符。
MultiScreenEvent的事件标志符被返回，见MultiScreenEvent的子类：MultiScreenConfigurationEvent和MultiScreenContextEvent。
int getId()方法2232从MSM I01版本起被使用。
图23A示出了根据本发明的实施例的org.ocap.ui.event包的MultiScreenResourceEvent类1718的定义。
org.ocap.ui.event包的MultiScreenResourceEvent类1718被定义为java.lang.Object的子级别java.util.EventObject的子级别org.davic.resources.ResourceStatusEvent的子级别。
org.ocap.ui.event包的MultiScreenResourceEvent类1718包括java.io.Seriazable作为所有实现的接口(All Implemented Interfaces)。org.ocap.ui.event包的MultiScreenResourceEvent类1718被声明为public class MultiScreenResourceEvent，并扩展org.davic.resources.ResourceStatusEvent。
MultiScreenResourceEvent类1718被用来报告关于多屏幕相关资源的资源状态的改变。
org.ocap.ui.event包的MultiScreenResourceEvent类1718从MSM I01版本起被使用。
图23B示出了根据本发明的实施例的org.ocap.ui.event包的MultiScreenResourceEvent类1718的字段2300。
org.ocap.ui.event包的MultiScreenResourceEvent类1718包括static intMULTI_SCREEN_RESOURCE_SCREEN_RELEASED字段2302和static intMULTI_SCREEN_RESOURCE_SCREEN_REVERSED字段2304中的至少一个。从java.util.EventObject类继承的字段2310包括Source。
MULTI_SCREEN_RESOURCE_SCREEN_RELEASED字段2302被声明为public static final int MULTI_SCREEN_RESOURCE_SCREEN_RELEASED。对屏幕的保留(reservation)刚被释放，表示该屏幕(或组成它的屏幕装置)现在可以被保留(即，现在它们是未保留的)。
MULTI_SCREEN_RESOURCE_SCREEN_RELEASED字段2302从MSM I01版本起被使用。
MULTI_SCREEN_RESOURCE_SCREEN_REVERSED字段2304被声明为public static final int MULTI_SCREEN_RESOURCE_SCREEN_REVERSED。对屏幕的保留刚被授权给应用程序，表示该屏幕(包括组成它的屏幕装置)不再是未保留的。
MULTI_SCREEN_RESOURCE_SCREEN_REVERSED字段2304从MSM I01版本起被使用。
图23C示出了根据本发明的实施例的org.ocap.ui.event包的MultiScreenResourceEvent类1718的构造函数2320。
MultiScreenResourceEvent类1718的构造函数2320包括MultiScreenResourceEvent(java.lang.Object source，int id)2322。
MultiScreenResourceEvent类1718的构造函数2320被声明为publicMultiScreenResourceEvent(java.lang.Object source，int id)，并且是MultiScreenResourceEvent的构造函数。
参数source是对HScreen实例的引用，该HScreen实例的资源状态已经改变。
参数id是MultiScreenResourceEvent类1718的事件标志符。
MultiScreenResourceEvent类1718的构造函数2320从MSM I01版本起被使用。
图23D示出了根据本发明的实施例的org.ocap.ui.event包的MultiScreenResourceEvent类1718的方法2330。
org.ocap.ui.event包的MultiScreenResourceEvent类1718的方法2330包括int getId()方法2332和java.lang.Object getSource()方法2334中的至少一个。从类java.util.EventObject继承的方法2340包括toString，从类java.lang.Object继承的方法2345包括clone、equals、finalize、getClass、hashCode、notify、notifyAll、wait、wait和wait中的至少一个。
getSource()方法2334被声明为public java.lang.Object getSource()，并获取生成该事件的源目标。
getSource()方法2334重载了类org.davic.resources.ResourceStatusEvent中的getSource。getSource()方法2334返回对HScreen实例或它的子类的引用。
getSource()方法2334从MSM I01版本起被使用。
getId()方法2332被声明为public int getId()，并获取与MultiScreenResourceEvent类1718关联的资源事件标志符。
MultiScreenResourceEvent类的事件标志符被返回，其中该标志符是下列中的一个：{MULTI_SCREEN_RESOURCE_SCREEN_RELEASED字段2302、MULTI_SCREEN_RESOURCE_SCREEN_REVERSED字段2304}。
getId()方法2332从MSM I01版本起被使用。
下面，将参考图24A到24D、25A到25E、26A到26D、27、28A和28B及29，说明根据本发明的实施例的对多屏幕配置的应用程序使用限制。
根据当前的实施例，用于多屏幕配置改变处理、即多屏幕重配置的事前条件(图24A到24C)及事后条件(图25A到25B)必须被满足。在这种情况下，事前条件和事后条件必须在下列假设下被满足：
1.平台如定义那样地实现MSM；
2.多于一个的不同多屏幕配置存在并且可以访问；
3.调用程序具有MonitorAppPermission(“multiscreen.configuration”)的权限；
4.在verifyContraints()方法执行期间，没有MultiScreenConfigurationEvent.MULTI_SCREEN_CONFIGURATION_CHANGING或者MultiScreenConfigurationEvent.MULTI_SCREEN_CONFIGURATION_CHANGED事件产生，而不是作为通过verifyConstraints()方法调用setMultiScreenConfiguration()的直接结果；
5.在verifyContraints()方法执行期间，没有MultiScreenConfigurationEvent.MULTI_SCREEN_CONFIGURATION_SCREEN_ADDED或者MultiScreenConfigurationEvent.MULTI_SCREEN_CONFIGURATION_SCREEN_REMOVED事件产生；
6.应用程序在多屏幕使用描述符中发送作为1的allow_default_device_reconfig信号；
7.平台保存了关键的默认屏幕装置配置参数，明确地是在配置改变时的屏幕区域、像素分辨率和像素的纵横比；即，它没有利用下列事实：应用程序已发出为1的allow_default_device_reconfig的信号，以重新配置默认屏幕装置参数(注意：验证过程可以被扩展到覆盖平台不保存这些参数的情形，即，合适的HScreenConfigurationEvent或MultiScreenContextEvent可以被监听，并被用来注解平台没有保存这些参数)。
图24A到24C示出了根据本发明的实施例的改变多屏幕配置的事前条件。
在图24A的S2410中，不变量被验证。根据本发明的实施例，静态不变量作为事前条件被验证。在这种情况下，后面将参考图26A到26D来描述验证不变量的verifyInvariantConstraints()方法。
在图24A的S2420中，默认屏幕被记录。
在图24A的S2430中，默认背景屏幕装置和关键配置参数被记录。
在图24B的S2240中，默认视频屏幕装置和关键配置参数被记录。
在图24B的S2450中，默认图形显示装置和关键配置参数被记录。
在图24C的S2460中，非默认屏幕被记录。
在图24C的S2470中，非默认屏幕装置被记录。
在图24C的S2480中，找到与当前配置不同的配置。
图24D示出了根据本发明的实施例的改变多屏幕配置的过程。
在S2490中，多屏幕配置被改变。即，多屏幕配置通过MSM.setMultiScreenCondition(MSC2，null)被改变，并且MULTI_SCREEN_CONFIGURATION_CHANGING和MULTI_SCREEN_CONFIGURATION_CHANGED事件的产生通过waitForMultiScreenConfigurationChangingEvent()方法和waitForMultiScreenConfigurationChangedEvent()方法来等待。
图25A到25E示出了根据本发明的实施例的改变多屏幕配置的事后条件。
在图25A的S2500中，不变量被验证。根据本发明的实施例，静态不变量作为事后条件被验证。在这种情况下，后面将参考图26A到26D来说明验证不变量的verifyInvariantConstraints()方法。
在图25A的S2505中，当前多屏幕配置是新的配置。
在图25A的S2510中，新的默认屏幕必须和旧的默认屏幕是相同的实例。
在图25A的S2515中，新的默认背景屏幕装置(如果其存在)必须和旧的默认背景屏幕装置(如果其存在)是相同的实例，除非应用程序发送为1的allow_default_device_reconfig信号，在这种情况下允许在重新配置之后没有默认背景装置可用，在这种情况下，前一个默认背景装置必须被重置为空的背景屏幕装置状态。
在图25B的S2520中，新的默认背景屏幕装置(如果其存在)必须具有与之前的默认背景屏幕装置具有相同的屏幕区域、像素分辨率、像素的纵横比。
在图25C的S2525中，新的默认视频屏幕装置(如果其存在)必须和旧的默认视频屏幕装置(如果其存在)是相同的实例，除非应用程序发送为1的allow_default_device_reconfig信号，在这种情况下允许在重新配置之后没有默认视频装置可用，在这种情况下，前一个默认视频装置必须被重置为空的视频屏幕装置状态。
在图25C的S2530中，新的默认视频屏幕装置(如果其存在)必须具有与之前的默认视频屏幕装置具有相同的屏幕区域、像素分辨率、像素的纵横比。
在图25D的S2535中，新的默认图形屏幕装置(如果其存在)必须和旧的默认图形屏幕装置(如果其存在)是相同的实例，除非应用程序发送(值)为1的allow_default_device_reconfig信号，在这种情况下允许在重新配置之后没有默认图形装置可用，在这种情况下，前一个默认图形装置必须被重置为空的图形屏幕装置状态。
在图25D的S2540中，新的默认图形屏幕装置(如果其存在)必须具有与之前的默认图形屏幕装置具有相同的屏幕区域、像素分辨率、像素的纵横比。
在图25E的S2545中，对于每一个在重新配置之前得到的非默认屏幕，如果不再是非默认屏幕，则它必须等于空屏幕；否则，它必须不等于空屏幕。
在图25A的S2500中，对于每一个在重新配置之前得到的非默认屏幕装置，如果不再是非默认屏幕装置，则它必须等于空屏幕装置；否则，它必须不等于空屏幕装置。
图26A到26D示出了根据本发明的实施例的用于验证不变量的限制。
在图26A的S2605中，必须存在多屏幕管理器。
在图26A的S2610中，必须存在当前的多屏幕配置。
在图26A的S2615中，必须存在可访问的多屏幕配置的非空集合。
在图26A的S2620中，当前的多屏幕配置必须是可以访问的配置。
在图26B的S2625中，在当前的多屏幕配置中必须存在屏幕的非空集合。
在图26B的S2630中，在当前的多屏幕配置中的屏幕必须不是空的。
在图26B的S2635中，在当前的多屏幕配置中任意两个不同的屏幕项必须不能表示相同的资源。
在图26C的S2640中，必须存在当前的默认屏幕。
在图26C的S2645中，当前的默认屏幕必须不等于空屏幕。
在图26C的S2650中，在当前的多屏幕配置中正好有一个屏幕项必须表示和默认屏幕相同的资源。
在图26C的S2655中，必须存在可以访问的屏幕的非空集合。
在图26C的S2660中，当前的默认屏幕必须可以访问的屏幕集合的不同成员。
在图26D的S2665中，当前的默认屏幕中的任何背景屏幕装置必须不等于空的背景屏幕装置。
在图26D的S2670中，当前的默认屏幕中的任何视频屏幕装置必须不等于空的视频屏幕装置。
在图26D的S2675中，当前的默认屏幕中的任何图形屏幕装置必须不等于空的图形屏幕装置。
图27示出了根据本发明的实施例的getNonDefaultScreens()方法的定义。
getNonDefaultScreens()方法通过在MultiScreen Manager(MSM)上返回非默认屏幕(SX1ND)来获取非默认屏幕(SX1ND)。
图28A和28B示出了根据本发明的实施例的getNonDefaultScreenDevices()方法的定义。
在图28A的S2810中，背景屏幕装置、视频屏幕装置和图形屏幕装置的非默认屏幕装置的数量被分别检查。
在图28B的S2820中，背景屏幕装置、视频屏幕装置和图形屏幕装置的非默认屏幕装置被分别获取和返回。
图29示出了根据本发明的实施例的多个方法。
在S2910中，等待状态被保持，直到MultiScreenConfigurationEvent.MULTI_SCREEN_CONFIGURATION_CHANGING事件产生。
在S2920中，等待状态被保持，直到MultiScreenConfigurationEvent.MULTI_SCREEN_CONFIGURATION_CHANGED事件产生。
在S2930中，断言失败被检查和报告。
下面，将参考图30A、30B、31、32A、32B、33A、33B和34A到34C，描述根据OCAP标准来改变和添加的主体，以便在OCAP环境中实施本发明的实施例。
OCAP应用不支持或不是非常严格地支持对HAVi HScreen类定义的多个显示屏幕或多个逻辑屏幕的屏幕管理，并且，特别地，对画中画(PIP)和画外画(POP)功能的屏幕管理。因此，为了根据本发明来实施OCAP MSM，OCAP应用必须验证“ocap.api.option.msm”Java系统属性的存在。如果“ocap.api.option.msm”Java系统属性被验证，则OCAP可以发现、配置、使用或否则操作下列装置能力：PIP功能、POP功能、多显示(Multiple Displays)、以及从Main、PIP、POP屏幕映射到输出端口(Output Port)。
下面，将参考图30A和30B来描述用于标志应用程序的AppID，它将被改变以实现OCAP MSM。
图30A示出了根据OCAP标准的AppID的伪代码。图30B示出了根据本发明的实施例的用于实现OCAP MSM的OcapAppID的伪代码。
如果OCAP平台实施支持多个服务上下文(javax.tv.selection.ServiceContext)的同时展示，则不能区分使用相同的组织和由MHP定义的类org.dvb.application.AppID所表示的应用程序标志符的两个应用程序实例，其中，这些单独的实例在不同的服务上下文中运行。
结果，应用程序数据库和使用AppID的相关类的功能没有被很好地定义，即，在这种使用情况下存在二义性。
根据本发明的实施例，通过将图30A的S3010改为图30B的S3050，应用程序标志符被定义为新引入的类OcapAppID而不是类AppID。
类似地，应用程序标志符被定义为图30B的S3055、S3060、S3065和S3070中的类OcapAppID，而不是图30A中的S3015、S3020、S3025和S3030中的AppID。
现在将参考图31来描述类OcapAppID的定义。
图31示出了根据本发明的实施例的OcapAppID的伪代码。
在S3110中，OcapAppID允许在相同应用程序的多个实例之间进行区分，其中，这些多个实例与不同的ServiceContext实例关联。
这里，相同的应用程序是指应用程序使用相同的组织和应用程序标志符。支持多个同时展示的ServiceContext实例的OCAP实施可以允许同一应用程序的多个并发实例。
除了org.dvb.application.AppId由OCAP应用通过构造函数AppID(int，int)的显式调用来构造的情形，AppID的每个应用可见实例应该也是OcapAppID的实例。
如果OCAP实施或OCAP应用遇到AppID的实例，调用该id，其不是OcapAppID的实例，则该实例应该从语义上被当作与以下构造的OcapAppID相等：
在S3120中，定义当默认该OcapAppID的ServiceContext字段时要使用的公开构造函数。特别地，调用该构造函数应该等于调用OcapAppID(oid，aid，null)方法。
参数oid是与超类构造函数AppID(int oid，int aid)中相同名称的参数一致的组织标志符。
参数aid是与超类构造函数AppID(int oid，int aid)中相同名称的参数一致的组织标志符。
在S3130中，定义了指定该OcapAppID的ServiceContext字段时要使用的公开构造函数。
参数oid是与超类构造函数AppID(int oid，int aid)中相同名称的参数一致的组织标志符。
参数aid是与超类构造函数AppID(int oid，int aid)中相同名称的参数一致的组织标志符。
参数context是ServiceContext实例或null。如果是null，则当前应用程序的当前默认ServiceContext实例应该在初始化ServiceContext实例时被替代为null。
在S3140中，与OcapAppID实例关联的ServiceContext被获取。非空的ServiceContext实例由于getServiceContext()方法而被返回。
下面，将参考图32A、32B、33A、33B和34A到34C来描述根据OCAP标准的HScene Manager，其被修改以支持OCAP MSM扩展。
由org.ocap.ui.HSceneManager及相关类型定义的场景管理器(SceneManager)功能没有充分支持下列使用情形：
·单个应用程序使用多个HScene实例，其中这些不同的实例与不同的HGraphicsDevice实例关联；
·监控应用程序或其它授权的应用程序，以将焦点独立于所属程序地从一个HScene传递到另一个HScene的能力；
·监控应用程序或其它授权的应用程序，以监控和/或授权/拒绝HScene焦点的应用程序或平台初始化改变的能力；
·监控应用程序或其它授权的应用程序，以确定不同的HSceneBinding实例是否涉及独立于所属程序的相同或不同的基本场景的能力；
·监控应用程序或其它授权的应用程序，以保持所有可见场景的准确状态模型、其z-索引及其屏幕位置的能力；
·监控应用程序或其它授权的应用程序，以响应于重新排序的请求而指定要使用的场景的可替代z-索引顺序的能力；
·改变HSceneManager.getSceneOrder()的返回值类型。
此外，发现下列功能通过合并以重构而被更好地表达：
·通过指定oldOrder为-1，将HSceneChangeRequestHandler.testShow(..)合并为testOrder(..)；
该工程改变(Engineering Change)如下解决这些问题：
·增加HSceneBinding.getGraphicsDevice()；
·增加HSceneChangeRequestHandler.testMoveFocus(HSceneBinding，HSceneBinding)；
·增加HSceneChangeRequestHandler.focusChanged(HSceneBinding，HSceneBinding)；
·移除HSceneChangeRequestHandler.testShow(..)；
·改变HSceneChangeRequestHandler.testOrder(..)签名、返回值类型和声明的异常；
·改变HSceneChangeRequestHandler.testMove(..)签名和声明的异常；
·增加HSceneManager.getAppDefaultHScene(AppID)；
·增加HSceneManager.getAppHScenes(AppId)；
·增加HSceneManager.getAppHSceneLocation(HScene)；
·增加HSceneManager.getHSceneFocus()；
·增加HSceneManager.getHSceneOrder(HGraphicsDevice)；
·增加HSceneManager.transferHSceneFocus(HSceneBinding)；
·增加HSceneManager.sameScene(HSceneBinding，HSceneBinding)；
·改变HSceneManager.getHSceneOrder()返回值类型。
此外，为了清楚和更好理解，对HSceneManager、HSceneBinding和HSceneChangeRequestHandler及其之前存在的成员的原文描述被编辑性地增强了。
在javax.tv.graphics.TVContainer中，如果getRootContainer(Xletcontextctx)由(或代表)OCAP应用程序调用，ctx是调用的应用程序的初始XletContext，并且返回了实例，则该实例应该等于在同一时间由org.havi.ui.HScreenFactory.getDefaultHScene()返回的实例。
通过增加下面指定的特定场景管理(Scene Managemenent)功能，OCAP扩展了DVB-GEM 1.0.2。特别地，如下参考图32B、33B、34B和34C所指定，OCAP实现应该实现org.ocap.ui.HSceneBinding、org.ocap.ui.HSceneChangeRequestHandler、org.ocap.ui.HSceneManager及其相关语义。
此外，在org.havi.ui.HSceneFactory中，在获得另一个HScene S2之前，不需要OCAP应用程序在前面获取的HScene S1上使用dispose(HScene)方法，假设前一个和后一个HScene实例S1和S2与不同的HGraphicsDevice实例关联。
在焦点处理规则(Focus Handling Rules)中，实施应该保持可聚焦的HScene实例的全局有序列表。可聚焦的HScene是可见且活动的HScene，其中，如果HScene.isVisible()方法返回true，则HScene被认为是可见的，而(1)如果HScene.setActive(boolean)方法从没有被应用程序调用过，或者(2)如果HScene.setActive(boolean focus)方法在上一次调用时focus等于false之后至少被调用过一次focus等于true，则HScene被认为是活动的。
聚焦的HScene是被分配输入焦点的可聚焦HScene。无论多少HGraphicsDevice实例或HScreen实例是活动的，在给定的时间只有一个聚焦的HScene。
当HScene变为可聚焦时，它被加到可聚焦HScene列表的末尾。
当可聚焦的被分配焦点时，它被移到可聚焦HScene列表的开头。
当HScene不再可聚焦时，它从可聚焦HScene列表中被移除。
当聚焦的HScene不再可聚焦时，实现应该将焦点从聚焦的HScene收回，并将焦点分配给可聚焦HScene列表中的第一个可聚焦HScene。
当第一个可聚焦HScene被插入到可聚焦HScene列表时，应用程序应该自动将输入焦点分配给它。
图32A示出了根据OCAP标准的HSceneBinding的伪代码。图32B示出了根据本发明的实施例的用于实现OCAP MSM的HSceneBinding的伪代码。
在图32B的S3250中，在图32A的OCAP标准中不存在的HGraphicsDevice接口被额外地声明。
在图32B的S3260中，该HSceneBinding被平台定义的类实现，以提供表示HScene的特定属性的方法，其中HScene典型地由另一个应用程序拥有，并且因此，对HScene引用的直接访问不被允许。
在图32B的S3270中，由该HSceneBinding表示的HScene的屏幕矩形在getGraphicsDevice()方法所映射的HScreen的标准化坐标空间内被得到(返回)。
在图32B的S3280中，该HSceneBinding所表示的HScene所关联的应用程序属性被得到(返回)。
在图32B的S3290中，该HSceneBinding所表示的HScene所关联的图形装置被得到(返回)。
图33A示出了根据OCAP标准的HSceneChangeRequestHandler的伪代码。图33B示出了根据本发明的实施例的用于实现OCAP MSM的HSceneChangeRequestHandler的伪代码。
图33A的S3310被移除。
在图33B的S3330中，HSceneChangeRequestHandler被授权的应用程序实现，以便处理请求(1)以添加当前未显示的HScene，(2)移除当前显示的HScene，(3)改变屏幕上的HScene的位置，(4)在HGraphicsDevice的HScene z-顺序中移动HScene，(5)在HScene的包含层次结构之间移动AWT，并且(6)生成对AWT焦点分配给HScene包含层次结构的改变的通知。
在图33B的S3340中，测试HScene移动(或大小改变)请求是否被允许。当HScene要在HScreen内移动或要被改变大小时，即，如果展示的HScene的HScreenRectangle将被改变位置或大小，testMove(HSceneBinding move，HSceneBinding currentScenes[])方法被调用。
参数move是表示受影响的HScene的屏幕矩形的HSceneBinding，并且它应该是currentScenes中的元素。参数currentScenes是对应于包括受影响的HScene在内的现有可见HScene(及其当前屏幕矩形)的HSceneBinding。在该上下文中，如果HScene.isVisible()方法返回true，则HScene被认为是可见的。
如果可以进行移动，则testMove方法返回true，否则返回false。
在图33B的S3350中，测试是否可以做出HScene的z-顺序改变请求。当HScene要在z-顺序中移动，或者引起在z-顺序中添加或从z-顺序中移除，则testOrder(HSceneBinding reorder，HSceneBinding currentScenes[]，intcurrentOrder，int newOrder)被调用。在HScene从z-顺序中移除的情况下，testOrder方法的结果值可以被实现忽略(例如，因为应用程序结束了应用程序的HScene被移除)。
在调用testOrder方法时，下列限制将被使用：
·currentOrder或(和)newOrder中的一个(或两者)是非负的；
·如果currentOrder是非负的，则它是被currentScenes引用的数组的有效索引；
·如果currentOrder是currentScenes的有效索引，并且如果newOrder是非负的，则它是被currentScenes引用的数组的有效参数。
参数reorder是表示受影响的HScene的HSceneBinding。如果该HScene已经在z-顺序中存在，则它应该作为currentScenes的元素出现；否则，它不应该在currentScenes中出现。参数recorder不在图33A的S3320的testOrder方法中考虑，并且考虑到受图33B的testOrder方法影响的HScene，z-顺序可以被参数reorder验证。
参数currentScenes是对应于z-顺序中现有的可见HScene的HSceneBinding，其第一个元素(0)是最前面的HScene。在该上下文中，如果HScene.isVisible()方法返回true，则HScene被认为是可见的。
如果由于调用HScene.show()方法或HScene.setVisible(true)方法从而HScene将被显示，则参数currentOrder值为-1，或者，如果HScene已经被显示，则参数currentOrder的值是表示要移动的HScene在currentScenes中的现有位置的非负整数。
参数newOrder是表示受影响的HScene要移动到的新位置的非负整数，或者是-1，如果受影响的HScene将(完全)从HScene z-顺序中移除。如果受影响的HScene被加到HScene z-顺序，则newOrder表示它出现的位置，而其它当前HScene都被下移一个位置。如果currentOrder是-1并且newOrder的值大于currentScenes的最后一个有效索引的索引，则要添加的HScene被请求放置在HScene z-顺序的最后面。
如果reorder(添加/移除)请求如参数所指定而被允许，则testOrder方法返回null。如果请求必须不能如指定地执行，则返回参数currentScenes的值。
HSceneBinding实例的新的数组被返回，该新的数组是由下列元素组成的集合的重排列：(a)currentScenes减去reorder，如果currentOrder是非负的，且newOrder是负的，(b)currentScenes加上reorder，如果currentOrder是负的，且newOrder是非负的，或者(c)currentScenes，如果currentOrder和newOrder是非负的。
在图33B的S3360中，测试向(从)HScene重新分配(或移除)AWT焦点是否被允许。如果HSceneChangeRequestHandler被注册，则每当AWT焦点被初始分配给HScene容器层次关系、在HScene容器层次关系之间移动或者从HScene容器层次关系移除时，OCAP平台实施应该调用testFocusChange()方法。如果testFocusChange()对某个焦点状态改变返回false，则OCAP平台实现不应该完成该改变，并必须保持AWT焦点不变。
在HScene实例内部在子容器或组件之间移动焦点时，OCAP平台实施不应该调用testFocusChange()方法。
在源于平台的AWT HScene焦点重新分配的情况下，OCAP平台实施可以，但不是必须调用testFocusChange()方法(或使用其返回值)；但是，在这样的情况下，平台应该在所有情况下调用focusChanged(..)方法来提供对源于平台的HScene焦点改变的通知。
在调用testFocusChange方法时，newScene或(和)oldScene中的一个(或两者)作为限制不应该为null。
参数newScene是表示要分配焦点的HScene的HSceneBinding，或者，在焦点没有被分配给任何HScene，即没有被分配的情况下，该参数是null。
参数oldScene是表示焦点要被移除的HScene的HSceneBinding，或者，在焦点没有被分配给任何HScene的情况下(紧靠在调用testFocusChange方法之前)，该参数是null。
如果焦点转移(或移除)可以进行，则testFocusChange方法返回true，否则返回false。
在图33B的S3370中，改变的处理函数(handler)在当前的AWT焦点分配中被通知。focusChanged方法向某个HScene提供对当前的AWT焦点分配的改变的通知。为了指定这样的HScene，使用了HSceneBinding，其通过组合来自HSceneBinding.getAttributes()方法的被标志的应用程序和来自HSceneBinding.getGraphicsDevice()方法的图形屏幕装置，来唯一地标志一个场景。
在HScene实例内部在子容器或组件之间移动焦点时，OCAP平台实施不应该调用focusChanged方法。
上面提到的唯一标志是基于给定的应用程序每个HGraphicsDevice具有不多于一个HScene的限制的。
参数newScene是(1)直接表示被分配焦点的新HScene的HSceneBinding，或者(2)null，表示没有HScene现在被分配了焦点(在该应用程序环境中)。
参数oldScene是(1)直接表示要被移除焦点的旧的(先前的)HScene的HSceneBinding，或者(2)null，如果没有HScene在之前被分配了焦点(在该应用程序环境中)。
图34A示出了根据OCAP标准的HSceneManager的伪代码。图34B和34C示出了根据本发明的实施例的用于实现OCAP MSM的HSceneManager的伪代码。
在图34B的S3420中，HSceneManager表示平台管理器组件，其允许有授权的应用程序注册处理函数，来处理在(该HGraphicsDevice的)所有HScenes组成的HGraphicsDevice之内请求的HScene改变。此外，HScene z-顺序、默认的场景和默认的焦点分配可以使用HSceneManager来查询。
在图34B的S3430中，生成了受保护的默认构造函数。
在图34B的S3435中，得到HSceneManager的单例实例，其中，该实例(从可访问状态的角度来看)表现为平台的作用域(而不是调用的程序的)。HSceneManager被返回。
在图34B的S3440中，setHSceneChangeRequestHandler(HSceneChangeRequestHandler handler)方法允许应用程序将自己建立为HScene改变请求处理函数。如果在setHSceneChangeRequestHandler被调用时已经注册了处理函数，则HScene改变请求处理函数被替换为指定的处理函数。
参数handler是(1)关于HScene z-顺序的改变以及关于默认焦点分配的改变、要查询的HSceneChangeRequestHandler，或者(2)null，在此情况下当前的处理函数被移除。
如果调用程序没有MonitorAppPermission(“handler.resource”)的权限，则抛出SecurityException的异常。
在图34B的S3445中，对应于调用的应用程序的默认HGraphicsDevice的可见HScene的场景绑定的集合被获得。当与图34A的S3410中的publicstatic OcapAppAttributes[]getHSceneOrder()比较，通过被声明为HSceneBinding[]类型而不是static OcapAppAttributes[]类型，场景绑定被返回。
如果调用的应用程序被分配了默认的图形屏幕，则getHSceneOrder()方法应该返回与getHSceneOrder(HScreen.getDefualtHScreen().getDefaultHGraphicsDevice())方法相同的值；否则，它应该返回空的数组。
对应于调用的应用程序的默认HGraphicsDevice的可见HScene实例的HSceneBinding实例的数组以z-顺序返回，其中可见是指scene.isVisible()返回true。
如果调用程序没有MonitorAppPermission(“handler.resource”)的权限，则抛出SecurityException的异常。
对应于指定HGraphicsDevice的可见HScene的场景绑定的集合被获得。
返回的场景绑定的数组是有序的，从而第一个元素(0)对应于在用于指定的HGraphicsDevice的HScene z-顺序中最前面的可见HScene，而最后一个元素对应于最后面的可见HScene。
如果指定的图形装置与未与显示屏幕或输出端口关联或没有在输出端口上启用显示的屏幕关联，则应该返回空的数组。
参数device是HGraphicsDevice。
对应于指定的HGraphicsDevice的可见HScene实例的HSceneBinding实例的数组以z-顺序返回，其中可见是指scene.isVisible()返回true。
如果调用程序没有MonitorAppPermission(“handler.resource”)的权限，则抛出SecurityException的异常。
在图34C的S3455中，用于调用的应用程序的默认HScene的HScene z-顺序位置被得到。应用程序可以调用getAppHSceneLocation()方法来确定其默认HScene在HGraphicsDevice实例的z-顺序中位于何处。
如果应用程序从未获取对其默认HScene的引用(意味着该应用程序没有用户界面)，则getAppHSceneLocation()方法返回返回-1；否则，返回与getAppHSceneLocation(HSceneFactory.getDefaultHScene())相同的值。
在图34C的S3460中，用于指定的HScene的HScene z-顺序被得到。应用程序可以调用getAppHSceneLocation(HScene scene)方法来确定指定的HScene在HGraphicsDevice的z-顺序中位于何处。
参数scene是HScene实例，对该实例获取HScene所关联的HGraphicsDevice内的z-顺序位置。
getAppHSceneLocation(HScene scene)方法返回表示指定的HScene的HScene z-顺序位置的整数。该值在z-顺序中有序增长，其中0是最前面的HScene，并且顺序增长的所有其它值在最前面的HScene下面。如果HScene没有被排序或如果它不可见，则返回-1值，其中可见被定义为scene.isVisible()返回true。
在图34C的S3465中，getAppDefaultHScene(AppID id)方法得到HSceneBinding，其允许确定被标志的应用程序的默认HScene，如果该应用程序拥有默认的HScene。
对getAppDefaultHScene(AppID id)的调用不应该引起默认HScene的创建或默认HScene与应用程序的关联。
参数id是表示OCAP应用程序的AppID实例。
getAppDefaultHScene(AppID id)方法返回(1)HSceneBinding，(间接)表示分配给被标志的应用程序的默认HScene，或者(2)null，表示该应用程不再在应用程序数据库中存在、已经终止、或者(当前)没有被分配默认HScene。
如果调用程序没有MonitorAppPermission(“handler.resource”)的权限，则抛出SecurityException的异常。
在图34C的S3470中，表示被标志的应用程序的当前HScene实例的HSceneBinding实例的数组被getAppHScenes(AppID id)方法获取。
对getAppHScenes(AppID id)方法的调用不应该引起默认HScene的创建或默认HScene与应用程序的关联。
参数id是表示OCAP应用程序的AppID实例。
getAppHScenes(AppID id)方法应该返回(1)HSceneBinding的非空数组，(间接)表示分配给指定的应用程序的HScene实例，或者(2)null，表示该应用程不再在应用程序数据库中存在、已经终止、或者(当前)没有被分配任何HScene。
如果调用程序没有MonitorAppPermission(“handler.resource”)的权限，则抛出SecurityException的异常。
在图34C的S3475中，HSceneBinding被getHSceneFocus()方法获取，该HSceneBinding允许确定(该应用程序环境中)被分配AWT焦点的HScene。
如果调用的程序没有被授予MonitorAppPermission(“handler.resource”)的权限，则getHSceneFocus()方法应该返回null，如果AWT焦点被分配给了不是调用的应用程序所拥有的HScene。
getHSceneFocus()方法应该返回(1)HSceneBinding，(间接)表示AWT焦点被分配的HScene，或者(2)null，表示AWT焦点(在该应用程序的环境中)没有被分配给任何HScene，或者调用的应用程序在上述环境中没有MonitorAppPermission(“handler.resource”)的权限。
在图34C的S3480中，AWT焦点的转移(或移除)通过transferHSceneFocus(HSceneBinding binding)方法来向(从)(该应用程序的环境中的)指定HScene请求。
如果该转移(或移除)请求完成了，则该完成关于transferHScreenFocus()方法的调用可以是异步的；此外，如果平台状态或某个其它条件否则阻止AWT焦点改变，则该完成可能不会发生。
将AWT焦点分配给不处于运行状态的应用程序或不可聚焦的HScene的请求不会被完成。
在通过transferHSceneFocus方法或通过(独立于transferHSceneFocus方法的)平台来成功地将焦点转移到某个HScene(或从某个HScene移除)，则focusChanged()方法不会在注册的HSceneChangeRequestHandler实例上被调用。
参数binding是(1)HSceneBinding，其唯一地标志AWT焦点被请求要分配的HScene，或者(2)null，表示AWT焦点分配被请求从(该应用程环境中的)所有HScene实例移除。
如果调用程序没有MonitorAppPermission(“handler.resource”)的权限，则抛出SecurityException的异常。
在图34C的S3485中，(HSceneBinding sb1，HSceneBinding sb2)方法确定两个HSceneBinding实例是否是指相同的基本场景。
参数sb1和sb2是HSceneBinding实例。
如果sb1和sb2表示相同的基本场景，则(HSceneBinding sb1，HSceneBinding sb2)方法返回true；否则，返回false。
本发明的实施例可以被写为计算机程序，并且可以在执行使用计算机可读记录介质的程序的通用数字计算机上实现。计算机可读记录介质的例子包括磁存储介质(例如ROM、软盘、硬盘等)、光存储介质(例如，CD-ROM或DVD)、以及例如载波的存储介质(例如，通过因特网传输)。
虽然本发明被特殊地示出，并参考其示例性实施例来描述，本领域普通技术人员应该理解，可以对形式和细节进行各种修改，而不偏离所附权利要求书所定义的本发明的精神和范围。示例性实施例应该被认为仅是描述性的，而不是为了限制的目的。因此，本发明的范围不是由本发明的详细说明书而是由所附权利要求书来定义的，并且在该范围内的所有差别都将被认为是包含在本发明之内的。

Claims (1)

1、一种配置和管理多屏幕的方法，该方法包括：
接收一个或更多个广播服务；
将该一个或更多个广播服务分配给一个屏幕；
将该屏幕分配给一个或更多个显示屏幕；以及
将该一个或更多个显示屏幕分配给一个或更多个输出端口。
CN2007800514785A 2006-12-18 2007-12-18 用于多屏幕配置的多屏幕管理的方法和设备 Expired - Fee Related CN101632300B (zh)

Applications Claiming Priority (11)

Application Number Priority Date Filing Date Title
US87047106P 2006-12-18 2006-12-18
US60/870,471 2006-12-18
US91889407P 2007-03-20 2007-03-20
US60/918,894 2007-03-20
US94803807P 2007-07-05 2007-07-05
US60/948,038 2007-07-05
US97284607P 2007-09-17 2007-09-17
US60/972,846 2007-09-17
US97590607P 2007-09-28 2007-09-28
US60/975,906 2007-09-28
PCT/KR2007/006637 WO2008075880A1 (en) 2006-12-18 2007-12-18 Method and apparatus for multiscreen management for multiple screen configuration

Publications (2)

Publication Number Publication Date
CN101632300A true CN101632300A (zh) 2010-01-20
CN101632300B CN101632300B (zh) 2012-07-04

Family

ID=39536460

Family Applications (1)

Application Number Title Priority Date Filing Date
CN2007800514785A Expired - Fee Related CN101632300B (zh) 2006-12-18 2007-12-18 用于多屏幕配置的多屏幕管理的方法和设备

Country Status (8)

Country Link
US (1) US8054319B2 (zh)
EP (1) EP2095633A4 (zh)
KR (1) KR101476140B1 (zh)
CN (1) CN101632300B (zh)
BR (1) BRPI0720474A8 (zh)
CA (1) CA2672450A1 (zh)
MX (1) MX2009006596A (zh)
WO (1) WO2008075880A1 (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106227594A (zh) * 2016-07-11 2016-12-14 中国人民解放军国防科学技术大学 一种基于分屏的多核cpu帧缓存显示优化方法
CN114071199A (zh) * 2020-08-07 2022-02-18 惠州视维新技术有限公司 一种屏幕控制方法、终端设备以及存储介质

Families Citing this family (37)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9182937B2 (en) 2010-10-01 2015-11-10 Z124 Desktop reveal by moving a logical display stack with gestures
KR101204795B1 (ko) * 2007-10-23 2012-11-26 삼성전자주식회사 이종의 그래픽 시스템 기반 어플리케이션들의 화면 공유방법 및 그 장치
KR101463567B1 (ko) * 2008-07-02 2014-11-20 엘지이노텍 주식회사 디지털 텔레비전의 단일 튜너를 이용한 피아이피기능구현장치
US20100064251A1 (en) * 2008-09-05 2010-03-11 International Business Machines Corporation Toggling window display state by screen in a multi-screened desktop environment
EP2270658A1 (en) * 2009-06-22 2011-01-05 Clayster Asia Ltd. Method and computer system for introducing client devices into a client-server network
KR101700811B1 (ko) 2010-09-02 2017-02-01 주식회사 케이티 이동형 사용자 단말 위치에 기반한 콘텐츠 연속 이용 제공 방법 및 서버
US9372618B2 (en) 2010-10-01 2016-06-21 Z124 Gesture based application management
US9733665B2 (en) * 2010-10-01 2017-08-15 Z124 Windows position control for phone applications
US20120218202A1 (en) 2010-10-01 2012-08-30 Sanjiv Sirpal Windows position control for phone applications
US20120225694A1 (en) 2010-10-01 2012-09-06 Sanjiv Sirpal Windows position control for phone applications
JP6010036B2 (ja) 2010-10-01 2016-10-19 ゼット１２４Ｚ１２４ タッチセンサ式ディスプレイに画像を表示する方法及び通信デバイスならびにコンピュータ可読媒体
US9430122B2 (en) 2010-10-01 2016-08-30 Z124 Secondary single screen mode activation through off-screen gesture area activation
US20120225693A1 (en) 2010-10-01 2012-09-06 Sanjiv Sirpal Windows position control for phone applications
US9436217B2 (en) 2010-10-01 2016-09-06 Z124 Windows position control for phone applications
US9189018B2 (en) 2010-10-01 2015-11-17 Z124 Windows position control for phone applications
US9588545B2 (en) 2010-10-01 2017-03-07 Z124 Windows position control for phone applications
US20120220340A1 (en) * 2010-10-01 2012-08-30 Sanjiv Sirpal Windows position control for phone applications
US20120102403A1 (en) * 2010-10-22 2012-04-26 Robert Sanford Havoc Pennington Video integration
US11265510B2 (en) * 2010-10-22 2022-03-01 Litl Llc Video integration
US9582239B2 (en) * 2011-01-21 2017-02-28 Qualcomm Incorporated User input back channel for wireless displays
US10135900B2 (en) 2011-01-21 2018-11-20 Qualcomm Incorporated User input back channel for wireless displays
US9787725B2 (en) 2011-01-21 2017-10-10 Qualcomm Incorporated User input back channel for wireless displays
US9495012B2 (en) 2011-09-27 2016-11-15 Z124 Secondary single screen mode activation through user interface activation
CN103229511A (zh) 2011-10-26 2013-07-31 松下电器产业株式会社 广播接收装置、广播接收方法以及程序
US8799974B2 (en) * 2011-12-12 2014-08-05 Infosys Limited System and method for multi-standard browser for digital devices
US9395869B2 (en) 2012-02-02 2016-07-19 Apple Inc. Global z-order for windows
US9407961B2 (en) * 2012-09-14 2016-08-02 Intel Corporation Media stream selective decode based on window visibility state
KR102069547B1 (ko) 2013-04-19 2020-01-28 삼성전자주식회사 방송 통신 시스템에서 부가 정보를 송수신하는 방법 및 장치
KR20150004156A (ko) * 2013-07-02 2015-01-12 삼성전자주식회사 디스플레이 장치 및 그 방법
KR102099594B1 (ko) * 2013-10-23 2020-04-10 엘지전자 주식회사 Tv 및 그 동작 방법
US10275139B2 (en) * 2014-09-18 2019-04-30 Sony Interactive Entertainment LLC System and method for integrated user interface for electronic devices
KR101594105B1 (ko) 2015-03-06 2016-02-16 주식회사 와이젯 사용자 장치 간에 여러 화면을 분배하고 입력 인터페이스를 공유하는 멀티 스크린 구현 방법 및 장치
US10585869B2 (en) * 2015-05-22 2020-03-10 Open Text Holdings, Inc. System and method for generating, maintaining, and querying a database for computer investigations
KR101916728B1 (ko) * 2016-03-07 2018-11-08 엘지전자 주식회사 차량에 구비된 차량 제어 장치 및 그의 제어방법
WO2017155219A1 (en) 2016-03-07 2017-09-14 Lg Electronics Inc. Vehicle control device mounted in vehicle and control method thereof
US10795630B2 (en) 2018-10-10 2020-10-06 International Business Machines Corporation Configuring computing device to utilize a multiple display arrangement by tracking eye movement
US11301456B2 (en) * 2020-05-07 2022-04-12 Sap Se Processing consistency validations of conditional foreign-key relations

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5347624A (en) * 1987-03-05 1994-09-13 Hitachi, Ltd. Method and apparatus for display control
US5289574A (en) * 1990-09-17 1994-02-22 Hewlett-Packard Company Multiple virtual screens on an "X windows" terminal
JPH06268908A (ja) * 1993-03-10 1994-09-22 Toshiba Corp マルチ画面用枠信号発生回路
US6088005A (en) * 1996-01-11 2000-07-11 Hewlett-Packard Company Design and method for a large, virtual workspace
JP4541476B2 (ja) 1999-02-19 2010-09-08 キヤノン株式会社 マルチ画像表示システムおよびマルチ画像表示方法
JP2002335444A (ja) * 2001-05-08 2002-11-22 Canon Inc マルチ画面表示装置、マルチ画面表示方法、記録媒体、及びプログラム
EP1538929A4 (en) * 2002-03-20 2009-03-11 Eugene Science Inc POWDER MIXTURE OF VEGETABLE STEROL AND EMULSIFIANT, AND PROCESS FOR PREPARING THE SAME
JP2003309780A (ja) * 2002-04-18 2003-10-31 Matsushita Electric Ind Co Ltd 画像表示装置
JP2006049935A (ja) * 2003-04-17 2006-02-16 Fujitsu Ltd 映像制御機能を備える制御装置及びプログラム
CN1627765B (zh) 2003-12-10 2010-09-01 松下电器产业株式会社 便携式信息终端装置
KR100710301B1 (ko) * 2005-01-14 2007-04-23 엘지전자 주식회사 멀티-스크린 시스템 및 그 구현방법

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106227594A (zh) * 2016-07-11 2016-12-14 中国人民解放军国防科学技术大学 一种基于分屏的多核cpu帧缓存显示优化方法
CN114071199A (zh) * 2020-08-07 2022-02-18 惠州视维新技术有限公司 一种屏幕控制方法、终端设备以及存储介质
CN114071199B (zh) * 2020-08-07 2024-03-12 惠州视维新技术有限公司 一种屏幕控制方法、终端设备以及存储介质

Also Published As

Publication number Publication date
BRPI0720474A8 (pt) 2017-09-12
CA2672450A1 (en) 2008-06-26
CN101632300B (zh) 2012-07-04
US20090322714A1 (en) 2009-12-31
BRPI0720474A2 (pt) 2014-01-14
EP2095633A1 (en) 2009-09-02
WO2008075880A1 (en) 2008-06-26
US8054319B2 (en) 2011-11-08
KR20080057187A (ko) 2008-06-24
MX2009006596A (es) 2009-07-02
EP2095633A4 (en) 2014-04-16
KR101476140B1 (ko) 2014-12-24

Similar Documents

Publication Publication Date Title
CN101632300B (zh) 用于多屏幕配置的多屏幕管理的方法和设备
JP4895424B2 (ja) 複数ユーザ用マルチメディア・ターミナル
US20070030390A1 (en) Apparatus for providing multiple screens and method of dynamically configuring screens
US20030035007A1 (en) Architecture for convergence systems
JP4567115B2 (ja) 条件付きアクセスモジュールへの直接アクセスによってデジタルビデオ放送共通インタフェース機能を拡張する方法及び装置
CN1430838A (zh) 用于改进的设备互用性的装置和方法
CN101014101B (zh) 管理数据广播的应用的方法、类/接口结构及广播接收机
JP4849756B2 (ja) 位置とスケーリングファクタを決定するパラメータを伴うビデオウィンドウを生成する方法および装置
US9681178B2 (en) Distributed presentation software for multiple instantiations in home network
CA2648597A1 (en) Apparatus and method for managing resource in multiple screens environment
TW200849990A (en) Method and apparatus for multiscreen management for multiple screen configuration
KR100725421B1 (ko) 다중 스크린을 제공하는 장치 및 상기 다중 스크린의 동적구성 방법
KR100791302B1 (ko) 다중 스크린을 제공하는 장치 및 상기 다중 스크린의 동적구성 방법
KR100791301B1 (ko) 다중 스크린을 제공하는 장치 및 상기 다중 스크린의 동적구성 방법
KR100746041B1 (ko) 다중 스크린을 제공하는 장치 및 상기 다중 스크린의 동적구성 방법
US20080094508A1 (en) Apparatus for providing mutliple screens and method of dynamically configuring
WO2007114643A1 (en) Apparatus and method for managing resource in multiple screens environment
KR20070100110A (ko) 다중 스크린을 제공하는 장치 및 상기 다중 스크린의 동적구성 방법
CA2615881A1 (en) Apparatus for providing multiple screens and method of dynamically configuring multiple screens
US20040168166A1 (en) Network adapted for flexible media integration
JP2001027955A (ja) 複数の端末と、すべての端末に配布されるソフトウェアシステムとを有するネットワーク
WO2007018374A1 (en) Apparatus for providing multiple screens and method of dynamically configuring multiple screens

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
C14 Grant of patent or utility model
GR01 Patent grant
CF01 Termination of patent right due to non-payment of annual fee
CF01 Termination of patent right due to non-payment of annual fee

Granted publication date: 20120704

Termination date: 20181218