标签: androidtv

上接：如何将Android带入互联网数字家庭? 第二篇      如何将Android带入互联网数字家庭? 第三篇 在第一篇中，我们分享了数字家庭软件平台的发展趋势和特点；在第二篇中，我们归纳了将Android移植到电视、机顶盒平台需要面对的五大技术挑战并重点探讨了 挑战1 ： 符合电视体验的2D/3D图形性能和用户交互模式方面的挑战 。在本篇中，我们将一起来继续分析其他的技术挑战。 挑战 2 ： 适合大屏的丰富多媒体影音体验： Android设计时是以移动手持设备为目标的，因此并没有考虑作为家庭娱乐中心的电视和机顶盒的多媒体影音需求。在下述方面需要改进： 更加优化的多媒体框架； 支持更多的音视频文件格式和容器； 支持更多的音视频编解码标准；          在Android的版本更新进化过程中，Android使用过两套多媒体框架：OpenCore和  Stagefright。 在Gingerbread之前使用的是OpenCore（在Froyo中，OpenCore和Stagefright同时存在），之后Stagefright完全替换了OpenCore。相比较而言，Stagefright架构更加简单，添加新的feature，新的parser更加容易。图一描述了多媒体框架在Android整个软件架构中的位置。                         图一 从Froyo到Gingerbread Android多媒体架构的变化 针对多媒体框架的修改和定制，一般我们有三个选择： 直接在OpenCore或者Stagefright上进行修改或者定制。          这个选择相对简单，只需要在相应的框架上做相关的修改。缺点是由于Stagefright支持的文件格式和编解码标准较少，需要一定的工作量来支持一些家庭娱乐中常见的多媒体格式和编码，同时也不便于重用已有的一些成果。 集成已有的成熟的开源多媒体框架，比如Gstreamer或者FFMPEG。         这样做的好处是可以最大程度的利用已有的资源和成果；如果是选择集成Gstreamer的话，则有大量的Plug in可以利用。图二表述了将Gstreamer集成到Android之后的多媒体架构。                                图二 集成Gstreamer的Android多媒体架构 集成商业或者私有的多媒体框架。 ARM的合作伙伴特别是在多媒体方面有多年积累的伙伴，会希望将自己私有的多媒体架构集成进Android， 一方面，他们对私有架构的性能非常自信；另一方面也可以重用自身很多已有的成果，形成差异化。另外一方面，ARM的软件合作伙伴也提供了一些商业的多媒体框架供选择，比如VisualOn推出的VOME。 在考虑过选择何种方案定制多媒体框架后， 我们来看看作为家庭娱乐中心的电视、机顶盒对所支持的多媒体格式的需求与Android自身支持能力之间的差异。图三到图五分别列出了电视平台在音视频文件格式（容器）和编码解码格式的主流需求与Android 3.0原生能力之间的差异。                    图三 Android TV平台对音视频文件格式的需求与Android 3.0原生能力的差异                    图四 Android TV平台对音频编解码格式的需求与Android 3.0原生能力的差异                     图五 Android TV平台对音频编解码格式的需求与Android 3.0原生能力的差异          从上面三张图的比较，我们可以看出Android 3.0原生支持的格式与电视平台对媒体文件格式和编解码格式的主流需求还有不小的差距，弥补这些差距正是将Android移植到互联数字家庭必须开展的工作。 挑战 3 ： 集成数字电视相关功能： 集成数字电视协议栈，比如DVB-T,DVB-C, ATSC等； 针对数字电视功能扩展API接口；           截至到Android 3.1， Android内没有集成任何数字电视协议相关的协议栈，如DVB-C/T/S 或其他。 因此如何集成DTV/STB 相关协议栈也是Android TV/STB 开发过程中不得不面对的问题。由于各个国家，各个地区的数字电视标准存在较大的差异化，因此对于数字电视相关协议栈的集成需要根据实际需求开展。一般来说，开发Android TV / STB 的合作伙伴具备一定的数字电视/机顶盒开发经验，将软件组件集成进去技术上难度不大，包括对CA的集成。          图六从架构的角度描述了数字电视相关软件组件的集成到Android后的情形。                                                                            图六 集成了数字电视相关组件的Android架构       从上图可以看出，除了需要集成相关的C/C++ 库到Library这一层外；在Application Framework这一层也需要做相应的封装将相关的API暴露给应用层。 关于如何实现和定义Android TV数字电视功能相关的API，目前各家Android TV的厂家都没有标准，这也是Android TV/ STB最大的风险和挑战之一。       目前在Android TV/STB中实现数字电视相关的API大致有两种方式（不限于两种）：       1. Java Application + Customized Application Framework + JNI + DTV/STB Specific Libraries       2. Browser (HTML5 + JavaScript) +  C/C++ DTV/STB Specific Libraries       第一种方式如图六所示，在Application Framework这一层对一系列JNI进行封装，形成数字电视功能相关的Java Level的Class； 第二种方式，通过修改Webkit，让JavaScript去call 相关的C level API从而将数字电视的功能嵌入到浏览器网页之中。        图七和图八给出了第一种方式的一个示例， 包括封装哪些类以及相应的Data Flow的一个示例。                                   图七  示例： 新增的数字电视功能相关的Java Package/Class                                          图八 示例 ：新增的数字电视功能相关的Java Package/Class的数据流 挑战 4 ： 推动应用开发者开发适合于TV的Android应用；           Android TV/STB 能否真正取得商业的成功，极大程度上取决于Android TV Application Store能否成功。目前虽然Google Android Market上已经有了20多万的应用，但是没有一个应用是真正为电视量身定做的。换句话说Android TV需要自己的应用和应用商店！           那么，如何推动应用开发者开发适合TV的Android应用？在2011年6月21号ARM在深圳举办的Android TV/STB 技术交流会上，来自于国内主流的运营商，芯片商，电视系统厂商，软件设计公司的代表就这个问题展开了深入的讨论。其中有几个共识一起分享一下：           第一， 需要形成相对统一的Android TV的API规范； 至少要有标准化的Android TV/STB SDK 或者 NDK, 包括Emulator；           第二， 需要各家电视系统商家，包括运营商能以共享的心态来推动应用市场的建设；各家维护各家的应用市场难以支撑Android TV的商业成功；           第三， 需要形成灵活的商业模式吸引应用开发者开发Android TV的应用；           第四， 针对TV的Android应用要充分考虑TV和用户交互方式的特点， 从最简单的“上下左右确认返回”六个键做起；           第五， 需要推动Android TV相关的便利的开发工具在应用开发者的使用          虽然很多共识还需要进一步的细化，更需要落实；但所有的合作伙伴都已经意识到对于Android TV或者说智能电视来说，应用是王道；而要推动应用的发展和繁荣，必须抱着一种开放和共享的心态！          在下一篇（最后一篇）中， 我们会继续探讨将Android带入互联网数字家庭的挑战5 :“如何部署内容保护"以及Android TV和GoogleTV的一些比较。（第三篇完）

上接： 如何将Android带入互联网数字家庭? 第一篇   如何将Android带入互联网数字家庭? 第二篇   在上一篇中，我们探讨了数字电视/机顶盒软件架构的现状与未来，分享了数字家庭软件平台未来的发展趋势和特点。在本篇中，我们将一起来探讨为什么Android能够成为未来数字家庭软件平台的选择之一；而我们又如何才能将原本为手持设备量身定做的Android移植到电视/机顶盒平台？   首先，我们需要回答的第一个问题就是： Why Android?为什么Android能够成为未来数字家庭软件平台的有力竞争者？         先来看看Android自身的天然的优势： Android 是一套完整的消费电子设备的软件解决方案，它包括： Linux 内核； 完整的中间件，包括2D/3D图形，多媒体框架，WebKit，Dalvik虚拟机等等； 健壮的可以重用的应用程序框架以及便利实用SDK/NDK开发工具。 Android是个开源项目： 可以自由的定制和移植；（有碎片化的风险，本文不做讨论） Android基于Apache2.0 license，方便用于商业用途。 Android的生态系统已经建立： Google Market上已经有了超过20万的Android应用 每天有超过40万个Android设备被激活 Android中集中了大量ARM架构的优化，在ARM上Android可以获得倍增的性能和用户体验。   除了这些优势，Android移植到电视/机顶盒平台，劣势也很明显： 没有TV/STB相关的API，造成Android TV/STB的应用程序框架的非标准化。 Android不是为TV/STB设计的，需要做大量的定制，移植和优化工作。 Google完全控制Android，包括新的性能，架构和应用程序框架的变化，路线图等等。 这对于定制和移植Android的厂商有一定的风险。 Google官方的GoogleTV 对于AndroidTV的影响： － 开发AndroidTV的合作伙伴需要谨慎的考虑GoogleTV对AndroidTV的影响： －－ 如何兼容GoogleTV？ －－ GoogleTV开源后，如何快速高效的merge到GoogleTV？ －－ 是否可以重用GoogleTV的生态系统？            这些都是需要考虑的问题同时也是风险所在。由于成为GoogleTV Leading Partner  有很高门槛，同时GoogleTV开源的时间仍然很难确认，对于希望开发Android TV/STB的合作伙伴，我们建议在软件架构设计和定制时，考虑到未来兼容GoogleTV的可能性；因为有很多定制和移植工作，即便在GoogleTV开源后，仍然是需要的 。   图一描述了Google已经发布的针对的不同的目标设备的Android版本。 图一 Google发布的针对不同设备的Android版本         从图一我们可以看出GoogleTV是以Android为基础的一个分支；根据Google最新的路线图，未来的Android主线会演化成适用于手机，平板和电视三类设备。   那么，如何才能将Android移植到电视或机顶盒平台呢？要说清楚这个问 题， 首先我们必须明确将Android移植到电视或机顶盒平台上需要面对哪些挑战？ 挑战1 ：电视用户对于用户界面，图形的性能以及用户交互模式有完全不同于手机用户的体验。这包括： －－ TV的分辨率要求至少720p/1080p以及大于30fps的帧率； －－ TV的OSD要求32位的色彩深度；而android默认的是16bit； －－ TV的用户界面，包括界面上内容的组织方式不同于手机； －－ TV用户使用遥控器而不是触摸屏； －－ TV因为是大屏设备，对2D/3D图形的性能有更高的要求，需要硬件 加速。 挑战 2 ： 适合于大屏的丰富的多媒体影音体验： －－ 更加优化的多媒体框架； －－ 支持更多的音视频文件格式和容器； －－ 支持更多的音视频编解码标准； 挑战 3 ： 集成DTV/STB功能： －－ 集成数字电视协议栈，比如DVB-T,DVB-C, ATSC等； －－ 针对数字电视功能扩展API接口； 挑战 4 ： 推动应用开发者开发适合于TV的Android应用； 挑战 5 ： 内容保护 －－ 如何部署CA? －－ 如何部署DRM？         接下来我们将来讨论如何应对这五大挑战。由于篇幅关系，本篇将重点讨论挑战1。 在第三篇和第四篇中，我们会依次对其他挑战展开讨论。          首先我们将挑战1中面临的问题分为两类：        第一类：图形图像显示相关的问题： TV的分辨率要求至少720p/1080p以及大于30fps的帧率； TV的OSD要求32位的色彩深度；而android默认的是16bit； TV因为是大屏设备，对2D/3D图形的性能有更高的要求，需要硬件加速。 针对上述问题，需要至少对下列模块进行修改或集成，如图二所示：                                 图二 应对挑战1的第一类问题需要涉及的模块   第二类： 用户交互模式相关的问题： TV的用户界面，包括界面上内容的组织方式不同于手机； TV用户使用遥控器而不是触摸屏；   针对这类问题，需要对Android中的下列模块进行修改，具体请参见图三： 图三 应对挑战1的第二类问题需要涉及的模块   2D和3D图形的性能是Android TV整体性能的关键点；在Android中，我们可以通过优化Skia和SurfaceFlinger来加速2D性能。              如何优化Skia来加速Full HD的2D体验？   重用Skia中大量的Neon优化；或者用Neon进行进一步优化； 利用GPU（OpenGL ES/OpenVG/…）来做Skia的后端 在Image Decoder中嵌入硬件decoder。   图四说明了上述优化可能发生在Skia架构中的哪些模块？                                          图四 Skia优化可能涉及的模块             如何通过优化SurfaceFlinger加速2D？ 在Android1.6（Donut）之前（包含Donut）的版本，需要实现“copybit”的HAL来实现2D硬件加速。 Android1.6以后的版本，将“Copybit”封装进了OpenGL ES；通过硬件实现的OpenGL ES 2D API来实现硬件加速。 Android3.0（Honeycomb）在2D上增加了新的功能，包括： 通过在AndroidManifest.xml中设置 来启动硬件加速2D； =“true” 应用开发者可以控制硬件加速的作用域，是全局的还是某个Activity或者某个View 通过运用GPU可以带来更加流畅的用户体验   在下篇中， 我们将继续探讨如何将Android移植到电视/机顶盒平台； 同时也会重点介绍GoogleTV以及GoogleTV与AndroidTV之间的对比。   （第二篇完） 下接： 如何将Android带入互联网数字家庭? 第三篇

   如何将Android带入互联网数字家庭? 第一篇   Android作为优秀的开源软件解决方案, 它的作用域已经从手机市场,波及到了平板电脑,甚至以数字电视、机顶盒为典型应用的数字家庭领域。Android最初是为手机移动设备量身定做的,它默认支持的分辨率，色彩深度，多媒体播放架构，用户交互方式，2D/3D图形的性能等都无法适应类似于数字电视，机顶盒这样的家庭应用。   因此，将Android移植到数字电视或机顶盒需要对Android进行大量的定制和修改。这些修改和定制涉及到Android软件架构中的各个层面，我将用四篇Blog来依次介绍如何将标准的Android移植到数字电视或机顶盒平台。   在开始我们的讨论之前， 我们先来简单探讨一下目前数字电视和机顶盒软件的现状和未来   数字电视/机顶盒软件的现状   1 软件架构的差异化   目前， 数字电视和机顶盒的软件架构中由于使用了不同的操作系统，不同的中间件平台， 不用的应用程序框架使得软件架构层面出现了极大的差异化。   在操作系统层面, Linux, uCos，VxWorks, WinCE，iTron, ThreadX 等不同的操作系统在不同的产品上都有相应的部署；   在中间件层面， 有公开的标准化的中间件平台，比如MHP，Tru2way, ACAP,ARIB，MHEG5等， 也存在私有的非标准的中间件平台；而不同的中间件软件提供商更会提供各自不同的中间件解决方案，这些解决方案之间大多是无法互相兼容的。   在应用生态系统方面， 缺乏统一的应用软件框架， 造成缺乏共通的应用程序生态系统。   2 设备的网络互联化   网络互联化已经成为数字家庭， 或者更具体的说是数字电视、机顶盒发展的趋势和方向。从图一，我们可以看到预计到2013年全球具备上网功能的电视将超过50%。                               图一 全球互联网电视的发展趋势   而从图二,我们更能清楚地看到国内互联网电视明显的增长趋势  图二 中国互联网电视发展趋势   但是, 尽管数字电视互联化的趋势如此明显, 目前仍然缺乏一个统一的中间件标准应对这股互联化的趋势。   那么， 未来数字电视的软件架构会是什么样子呢？   现状中已经蕴含了对未来架构的需求。   虽然数字电视软件具有明显的差异化， 但是Linux已经成为最通用的软件平台，而由此导致了大量开源软件的使用，使得数字电视软件具备了统一化的基础；   另外，网络互联化的趋势，要求未来的数字电视平台是一个标准化，高兼容性，高性能的平台。因此，未来的数字电视软件架构至少应该具备下面几个特点： 更开放 更统一 更高性能 更加互联   图三是一个虚拟的未来数字电视或机顶盒的软件架构，从中我们可 以清楚的看到一些趋势和关键属性：                   图三  未来的数字电视、机顶盒软件架构 更多开源的或标准化的中间件 更通用的应用程序框架 更加专注于通过UI和应用层的变化来实现差异化   图三只是一个虚拟的架构，并不是未来的数字电视、机顶盒软件架构的硬性标准；但是我相信，未来的数字家庭的软件架构都会或多或少的趋同于这个架构。而Android因其自身的特性，也一定为成为未来数字家庭软件架构的有力竞争者。 （第一篇完）   下接： 如何将Android带入互联网数字家庭? 第二篇