Guilherme Daher Ferreira Um Middleware Declarativo na Plataforma AndroidTMpara o Sistema Brasileiro de Televisão Digital (SBTVD) Vitória - ES, Brasil 28 de agosto de 2010 Guilherme Daher Ferreira Um Middleware Declarativo na Plataforma AndroidTMpara o Sistema Brasileiro de Televisão Digital (SBTVD) Dissertação apresentada para obtenção do Grau de Mestre em Informática pela Univer- sidade Federal do Esṕırito Santo. Orientador: Dr. Magnos Martinello Co-orientador: Dra. Roberta Lima Gomes Departamento de Informática Centro Tecnolóogico Universidade Federal do Esṕırito Santo Vitória - ES, Brasil 28 de agosto de 2010 Dissertação de Projeto Final de Mestrado sob o t́ıtulo “Um Middleware Declarativo na Plataforma AndroidTMpara o Sistema Brasileiro de Televisão Digital (SBTVD)”, de- fendida por Guilherme Daher Ferreira e aprovada em 28 de agosto de 2010, em Vitória, Estado do Esṕırito Santo, pela banca examinadora constitúıda pelos professores: Prof. Dr. Magnos Martinello Orientador Profa. Dra. Roberta Gomes Lima Co-orientador Prof. Dr. Luiz Fernando Gomes Soares Pontif́ıcia Universidade Católica do Rio de Janeiro Prof. Dr. José Gonçalves Pereira Universidade Federal do Esṕırito Santo Resumo Assim como em todos os principais sistemas de TV digital terrestre, o middleware brasileiro Ginga suporta tanto aplicações declarativas (através da sua apresentação via ambiente declarativo Ginga-NCL) quanto aplicações procedurais (através da sua execução, via ambiente procedural Ginga-J). Diferentemente dos dispositivos fixos, a normatização brasileira estabelece que para os dispositivos portáteis, somente o ambiente Ginga-NCL é obrigatório. Hoje existem no Brasil alguns dispositivos portáteis que permitem a recepção do si- nal de TV digital. No entanto, uma minoria destes aparelhos estão equipados com o middleware adotado pelo Sistema Brasileiro de Televisão Digital - SBTVD. Sabidamente, ainda não existe nenhum dispositivo capaz de executar aplicações para televisão digital utilizando a plataforma AndroidTMcomo sistema operacional. Não existe também ne- nhuma implementação aberta dispońıvel para a comunidade cient́ıfica, de um middleware capaz de reproduzir aplicações, no padrão brasileiro, para televisão digital em dispositivos portáteis. Este trabalho descreve o processo utilizado para implementação do Ginga-NCL, bem como detalhes da codificação, para dispositivos portáteis baseados no sistema operacional AndroidTM. Como meio de validar a implementação, foram conduzidos experimentos para analisar a execução de aplicações NCL, bem como o uso de recursos do dispositivo portátil. Abstract As with all major digital terrestrial TV systems, the Brazilian middleware called Ginga, supports both declarative applications (through its presentation declarative en- vironment Ginga-NCL) and procedural applications (through its execution procedural environment Ginga-J). Unlike the fixtures, the Brazilian standardization provides that for the portable devices, only the environment Ginga-NCL is required. Today in Brazil there are some portable devices that allow the reception of digital TV signal. However, a minority of these devices are equipped with the middleware adopted by the Brazilian System of Digital Television - SBTVD. Known, although there is no device capable of running applications to digital television, using the AndroidTMplatform operating system, like, there is also no open-source middleware implementation, available to the scientific community, capable of playing, in Brazilian standard, digital TV on portable devices. This paper describes the process used for implementation of Ginga-NCL, as well as details of the encoding for portable devices based on AndroidTMoperating system. As a means to validate the implementation, experiments were conducted to analyze the per- formance of applications NCL and resource usage of the handheld device. Dedicatória Dedico este trabalho aos meus pais, à minha irmã, à minha namorada, e aos meus amigos. Agradecimentos Primeiramente ao meu orientador, professor Dr. Magnos Martinello, pela dedicação ao me orientar, pela paciência e pelo esforço em fazer com que eu superasse meus próprios limites. Aos meus queridos pais Nazira e Raymundo, pela vida e por tanta dedicação sempre, e à minha irmã Cristina, por tudo. Agradeço também à minha namorada, Larissa, pelo companheirismo e compreensão nas horas mais dif́ıceis. Ao Fábio e ao Guilherme, companheiros no desenvolvimento ao longo das muitas noites em que estivemos juntos estudando e programando. Aos membros da banca, pelos comentários e sugestões. À escola São Domingos por ter me ensinado a superar os meus desafios com inteligência e sabedoria. A todo o time de colegas e colaboradores da UFES e da PUC-RJ pelas dicas e suges- tões. Por fim, agradeço aos colaboradores da TOTVS e da RR, assim como da RNP através do Centro de Pesquisa e Desenvolvimento em Tecnologias Digitais para Informação e Comunicação (CTIC), e todos aqueles que não foram referenciados acima, mas que de alguma forma foram envolvidos no projeto ou dele participaram. Sumário Lista de Figuras Lista de Tabelas 1 Introdução p. 12 1.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 13 1.2 Motivação e Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 14 1.3 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 15 1.4 Estrutura da dissertação . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 15 2 Revisão da Literatura p. 16 2.1 Televisão Digital . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 17 2.1.1 Histórico e Evolução da TV Digital no Brasil . . . . . . . . . . . . p. 18 2.2 Padrões para Dispositivos Portáteis . . . . . . . . . . . . . . . . . . . . . p. 20 2.2.1 DVB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 20 2.2.2 ARIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 20 2.2.3 ATSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 21 2.2.4 SBTVD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 22 2.2.5 3GPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 22 2.2.6 DMB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 23 2.3 Sistemas Operacionais para Dispositivos Portáteis . . . . . . . . . . . . . p. 23 2.3.1 iPhone OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 24 2.3.2 Symbian . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 24 2.3.3 Windows Mobile . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 25 2.3.4 BlackBerry OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 26 2.3.5 AndroidTM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 27 2.3.6 PalmOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 28 2.4 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 29 3 Plataforma AndroidTM p. 30 3.1 O que é AndroidTM? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 31 3.2 Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 31 3.2.1 Conceitos básicos para desenvolvimento em AndroidTM . . . . . . p. 33 3.2.2 Interface com usuário . . . . . . . . . . . . . . . . . . . . . . . . . p. 35 3.2.3 Recursos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 36 3.2.4 Elementos Gráficos . . . . . . . . . . . . . . . . . . . . . . . . . . p. 37 3.2.5 Audio, Vı́deo e Imagens . . . . . . . . . . . . . . . . . . . . . . . p. 38 3.2.6 Segurança e Permissões . . . . . . . . . . . . . . . . . . . . . . . . p. 39 3.3 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 40 4 Implementação Ginga-NCL para AndroidTM p. 41 4.1 Análise e Modelagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 42 4.2 Implementação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 45 4.2.1 Codificação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 45 4.2.2 Testes Preliminares . . . . . . . . . . . . . . . . . . . . . . . . . . p. 56 4.3 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 60 5 Experimentações e Avaliação dos Resultados p. 61 5.1 Análise do tempo de preparo de mı́dias simultâneas . . . . . . . . . . . . p. 62 5.2 Análise do uso de memória e CPU durante a execução de aplicações NCL p. 65 5.2.1 Fórmula 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 65 5.2.2 Mosáico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 67 5.3 Apresentação de Mı́dias Remotas para Teste do Canal de Retorno . . . . p. 69 5.4 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 70 6 Conclusões e trabalhos futuros p. 71 Referências Bibliográficas p. 74 Lista de Figuras 3.1 Componentes do AndroidTM . . . . . . . . . . . . . . . . . . . . . . . . . p. 32 3.2 Estrutura em árvore da interface Activity retirada de [1] . . . . . . . . . p. 36 4.1 Modelagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 43 4.2 Conversor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 47 4.3 Bases Privadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 49 4.4 Diferença de abordagem para Gerenciador Gráfico . . . . . . . . . . . . . p. 51 4.5 Gerenciador de Exibidores . . . . . . . . . . . . . . . . . . . . . . . . . . p. 52 4.6 Exibidores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 53 4.7 Adaptadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 54 4.8 Escalonador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 55 4.9 Bloco de código responsável pela sincronização de mı́dias . . . . . . . . . p. 57 4.10 Imagens na tela sem sincronismo e com sincronismo . . . . . . . . . . . . p. 57 4.11 Bloco de código responsável pela reutilização de área . . . . . . . . . . . . p. 58 4.12 Imagens na tela com sincronismo e reutilização . . . . . . . . . . . . . . . p. 58 5.1 Aplicação NCL para 2 mı́dias simultâneas . . . . . . . . . . . . . . . . . p. 63 5.2 Tempo de preparo para aplicações NCL . . . . . . . . . . . . . . . . . . . p. 64 5.3 Fómula 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 66 5.4 Análise de CPU e Memória . . . . . . . . . . . . . . . . . . . . . . . . . p. 67 5.5 Mosáicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 68 5.6 Análise de CPU e Memória . . . . . . . . . . . . . . . . . . . . . . . . . p. 68 5.7 Mı́dias Remotas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 69 Lista de Tabelas 3.1 Padrões de áudio suportados . . . . . . . . . . . . . . . . . . . . . . . . . p. 39 3.2 Padrões de v́ıdeo suportados . . . . . . . . . . . . . . . . . . . . . . . . . p. 39 3.3 Padrões de imagens suportados . . . . . . . . . . . . . . . . . . . . . . . p. 39 12 1 Introdução “ Hómines Sunt Voluntates - Os Homens são seus atos de vontade.” Santo Agostinho 1.1 Introdução 13 1.1 Introdução O acesso ao conteúdo televisivo interativo a partir de dispositivos portáteis multifun- cionais, como celulares e smartphones, é uma das grandes apostas para o crescimento da TV digital aberta no Brasil. Hoje já existem no páıs alguns fabricantes de dispositivos portáteis, cujos aparelhos permitem a recepção do sinal de TV digital. No entanto, pou- cos destes dispositivos já estão equipados com o Ginga, software nacional adotado como padrão de middleware pelo Sistema Brasileiro de Televisão Digital - SBTVD. O Ginga, em suas duas modalidades, uma declarativa, o Ginga-NCL [2], e outra imperativa, o Ginga-J [3], fornece uma série de facilidades para a construção e a execução de aplicações interativas em ambiente de TV digital aberta. Desta forma, dos dispositivos portáteis dispońıveis no mercado brasileiro, embora se aproveitem da qualidade superior de áudio e v́ıdeo inerente às tecnologias digitais, poucos ainda suportam a interatividade. Logo, existe uma demanda natural por implementações do middleware Ginga voltadas para terminais portáteis. No cenário de mobilidade, a escolha do sistema operacional embarcado no dispositivo portátil, assim como de suas plataformas de desenvolvimento associadas, tornam-se ques- tões proeminentes no processo de desenvolvimento de novas implementações Ginga. Uma primeira iniciativa acadêmica de implementação do Ginga-NCL para dispositivos móveis, foi realizada na PUC-RJ [4], tendo como plataforma base o sistema operacional Symbian. A plataforma AndroidTMfoi lançada em 2008 pelo Google, através do consórcio Open Handset Alliance. Trata-se de uma plataforma de código aberto e que não está vinculada a apenas um fabricante. Esta caracteŕıstica tem permitido a abertura da restrita área de sistemas operacionais para telefonia móvel. O AndroidTMconsiste em um sistema operaci- onal baseado no kernel Linux 2.6 e provê uma Application Programming Interface (API) na linguagem Java cujas aplicações desenvolvidas são compiladas para a máquina virtual Dalvik. Esta máquina virtual foi projetada especialmente para a plataforma AndroidTM, sendo otimizada para rodar em dispositivos portáteis. Para os desenvolvedores, há um Software Development Kit (SDK) dispońıvel gratuitamente e já existe uma ampla gama de aparelhos com AndroidTMembarcado. Este trabalho apresenta uma implementação do middleware Ginga- NCL para dis- positivos portáteis, tendo como sistema operacional embarcado o Google AndroidTM[5]. Um estudo experimental foi realizado para avaliar a sensibilidade de aplicações NCL [6] e o desempenho do middleware desenvolvido, incluindo o atraso decorrente da preparação 1.2 Motivação e Objetivos 14 inicial dos players em aplicações que contém um número alto de mı́dias simultâneas e a utilização de CPU e memória durante aplicações NCL com caracteŕısticas distintas. 1.2 Motivação e Objetivos A constituição da cadeia de valor da televisão aberta integra diversos agentes que visam produzir um produto final que é sempre voltado ao telespectador, que em sua totalidade é formado por cidadãos de diferentes classes [7]. Com o advento da Tecnologia Digital, agentes como dispositivos portáteis, até então ausentes nesta cadeia, passam a ter papel importante neste processo, trazendo principalmente, novas oportunidades de estudos e negócios. Conforme dados da Agência Nacional de Telecomunicações (Anatel), em fevereiro de 2010, o Brasil possúıa uma densidade de 91,33 aparelhos celulares para cada 100 habitantes, totalizando 175 milhões de celulares habilitados. Em se tratando de televisão digital portátil no Brasil, somente em 2010 os primeiros dispositivos homologados pela Anatel começaram a ser comercializados. Porém, até o momento nenhum dispositivo capaz de executar aplicações para tele- visão digital, possui a plataforma AndroidTMcomo sistema operacional, assim como não existe nenhuma implementação aberta, dispońıvel para a comunidade cient́ıfica, de um middleware capaz de reproduzir aplicações, no padrão brasileiro, para televisão digital em dispositivos portáteis. Além disso, até a presente data nenhum estudo havia sido publi- cado, que tenha sido validado em ambiente real, de análise de desempenho do middleware Ginga em dispositivos portáteis. Os fatores acima, unidos à vontade de contribuir com a evolução e difusão do padrão brasileiro de televisão digital, fizeram o autor decidir por elaborar um estudo que fosse capaz de apresentar uma implementação de um middleware declarativo na plataforma AndroidTMpara o Sistema Brasileiro de Televisão Digital (SBTVD) e também apresentar experimentações nesta plataforma de forma que fosse posśıvel analisar detalhadamente aspectos importantes de funcionamento de um middleware, tais como: i) o tempo de preparo de mı́dias simultâneas ii) uso de memória e CPU durante a execução de aplicações NCL e iii) e viabilidade da utilização do canal de retorno. 1.3 Metodologia 15 1.3 Metodologia A fim de se realizar a implementação do middleware foi necessário elaborar um pla- nejamento detalhado das etapas, de forma que o trabalho fosse conduzido da forma mais controlada posśıvel, evitando desvios que pudessem afetar de alguma forma o desenvolvi- mento das atividades. Foi estabelecido que seria necessário realizar um estudo dos padrões atualmente existentes, bem como dos sistemas operacionais e de suas plataformas de de- senvolvimento. Após isso, foi escolhida a plataforma que mais atendia aos requisitos quanto ao suporte às aplicações multimı́dia, à licença do código, ao ambiente de progra- mação dispońıvel e ao custo para o desenvolvedor. Posteriormente, iniciou-se a etapa de codificação com base nos levantamentos realizados nas etapas anteriores. Para tanto, partiu-se da implementação pública dispońıvel para dispositivos fixos, sendo que foram necessárias várias alterações e novas implementações que serão apresentadas no decorrer do trabalho. Por fim, foram desenvolvidos testes e avaliações de desempenho de forma a buscar a validação funcional da implementação proposta. 1.4 Estrutura da dissertação Os demais caṕıtulos do trabalho estão organizados da seguinte forma: Caṕıtulo 2 discute os trabalhos relacionados à esta dissertação. O Caṕıtulo 3 descreve a plataforma AndroidTMutilizada para a implementação do middleware. Caṕıtulo 4 detalha o projeto de desenvolvimento com foco na implementação. O Caṕıtulo 5 apresenta os testes e avaliações de desempenho desenvolvidas. Por fim, o Cáṕıtulo 6 conclui o trabalho apresentando as considerações finais e as perspectivas de trabalhos futuros. 16 2 Revisão da Literatura “A Matemática pura é, a sua maneira, a poesia das ideias lógicas.” Albert Einstein 2.1 Televisão Digital 17 Este caṕıtulo descreve o Estado da Arte em transmissão e recepção de Televisão Digital (TVD) para dispositivos portáteis. Na seção 2.1, uma introdução à TV Digi- tal e um histórico dos principais trabalhos relacionados são apresentados. Na seção 2.2 foram demonstradas as principais organizações responsáveis por estabelecer padrões e normatizações para televisão digital portátil. Por fim, na seção 2.3 os principais sistemas operacionais para dispositivos portáteis são discutidos. 2.1 Televisão Digital A televisão digital pode ser provida de duas maneiras. Através do primeiro formato, levam-se as tecnologias até então somente utilizadas em computadores para o cenário da televisão. Neste caso, enquadram-se as transmissões de televisão digital por radiodifusão terrestre, via cabo ou satélite. Através do segundo, levam-se as tecnologias, até então somente utilizadas na televisão, para um ambiente computacional. Esta convergência digital deve ser apoiada não só em camadas de baixo ńıvel, mas também na camada de aplicação [8]. No primeiro modelo é posśıvel disponibilizar nos televisores conteúdo de alta defi- nição incluindo iteratividade, personalização de conteúdo, oferecimento de serviços sob demanda, dentre outras funcionalidades. O segundo modelo normalmente é realizado em redes fechadas, como TV’s por assinatura e se encontra mais próximo do modelo da internet convencional. Assim como o primeiro modelo, através da IPTV, também é posśıvel se disponibi- lizar iteratividade, personalização de conteúdo e oferecimento de serviços sob demanda, entretanto, é necessária a utilização de técnicas de multcasting, a fim de viabilizar este mecanismo. Em contrapartida, a viabilização da transmissão pode ser prejudicada devido à complexidade da rede envolvida [9]. Um outro problema da IPTV é o consumo de banda nos serviços sob demanda, como o Video on Demand (VoD)1. Para tal, mecanismos devem ser criados para que esse consumo seja reduzido e o serviço se torne viável. Nos EUA a realidade da IPTV está mais próxima, dado que a difusão da televisão já foi concebida através do uso de cabos. Sendo assim, o fator banda é minimizado consi- deravelmente. No Brasil a TV Digital é oferecida em âmbito nacional por radiodifusão; 1Neste serviço o consumidor tem acesso a um acervo de v́ıdeos que podem ser escolhidos e apresentados sob sua demanda, na hora em que lhe for mais conveniente. 2.1 Televisão Digital 18 sendo assim, a IPTV ficará mais atrativa a medida que mais recursos estiverem dispońı- veis por um custo mais baixo. Dessa forma, acredita-se que em um futuro próximo, a TV também estará prontamente dispońıvel pela Internet [10]. 2.1.1 Histórico e Evolução da TV Digital no Brasil A década de 90 foi marcada por esforços de Norte-Americanos, Japoneses, Europeus e Asiáticos em pesquisas e padronizações que procuravam sempre um melhor modelo para conceber uma tecnologia de transmissão de televisão em alta resolução. No Brasil, assim como nos demais páıses, as pesquisas em grande escala em Televisão Digital também iniciaram-se na década de 90. Em 1994, através da união da Sociedade Brasileira de Engenharia de Televisão (SET) [11] e a Associação Brasileira de Emissoras de Rádio e Televisão (ABERT) [12], foi criado o grupo SET/ABERT [13] que naquele momento foi responsável pelo estudo dos modelos internacionais existentes até então e a sua viabilidade para o Brasil. Nesta mesma época, diversas pesquisas tais como: [14], [15], [16] e [17] também vinham sendo conduzidas por pesquisadores brasileiros e que posteriormente viriam a contribuir consideravelmente na definição do padrão Brasileiro de Televisão Digital. Após alguns anos de análise dos padrões internacionais, e em face à restrições diversas em cada um deles, os modelos já existentes (alguns deles serão apresentados na próxima seção) se mostraram inadequados às necessidades brasileiras. Por fim, através do Decreto No 4.901, de 26 de novembro de 2003, foi oficializado o Sistema Brasileiro de Televisão Digital Terrestre (SBTVD-T). A partir daquele momento diversas pesquisas foram conduzidas, no Brasil, por uni- versidades e por empresas privadas. Posteriormente, com a criação do Fórum do Sistema Brasileiro de TV Digital Terrestre em 2006, padrões foram definidos, os quais vieram a ser aprovados pela Associação Brasileira de Normas Técnicas (ABNT) [18]. As normas estão inseridas em 13 documentos, os quais são responsáveis por forma- lizar os aspectos relacionados aos sistemas de transmissão, codificação de v́ıdeo e áudio, codificação de dados e interatividade. Nesses documentos é prevista a criação de um mediador entre o hardware e as aplica- ções, denominada middleware. Conforme [19], middleware ou mediador é um ”componente que faz a mediação entre softwares, o qual é utilizado para compartilhar informações en- tre programas ocultando do usuário diferenças de protocolos de comunicação, plataformas 2.1 Televisão Digital 19 e dependências do sistema operacional. É geralmente constitúıdo por módulos dotados de APIs de alto ńıvel que proporcionam a sua integração com aplicações desenvolvidas em diversas linguagens de programação e interfaces de baixo ńıvel. Seu objetivo é mas- carar a heterogeneidade e fornecer um modelo de programação mais produtivo para os programadores de aplicativos”. A padrão SBTVD define o Ginga como middleware, que tem como objetivo garantir a interoperabilidade das aplicações em diferentes implementações de plataformas que o suportam [20]. O middleware Ginga contém dois módulos responsáveis pela interatividade na Televisão Digital: o Ginga-J [3] e o Ginga-NCL [2]. O primeiro é responsável pelo processamento de aplicações procedurais e o segundo pelo processamento de aplicações declarativas. Os dois módulos são obrigatórios para receptores fixos, entretanto, [21] define Ginga-NCL como ambiente obrigatório e Ginga-J como ambiente opcional para receptores portáteis. Os esforços no sentido de se desenvolver middlewares para dispositivos portáteis iniciaram-se há pouco tempo e ainda não são muito numerosos. Um exemplo é o caso do Japão, páıs avançado em termos de TV Digital, que começou a migração desse serviço para os dispositivos portáteis apenas em meados de 2006. No Brasil, o primeiro trabalho cient́ıfico neste sentido foi apresentado em [4], sendo proposta a implementação de um middleware Ginga para dispositivos portáteis baseados no sistema operacional Symbian. Trata-se da primeira implementação do Ginga-NCL para dispositivos portáteis e, como tal, possui uma descrição estendida sobre o padrão e trabalhos relacionados. O trabalho tem seu foco na descrição da arquitetura do Ginga-NCL para dispositivos portáteis e na apresentação de decisões tomadas durante a implementação do middleware. Porém, não apresenta o detalhamento dos módulos desenvolvidos, bem como não faz avaliações experimentais detalhadas sobre a plataforma. Vale dizer que, o código fonte também não foi disponibilizado para domı́nio público. Na época de desenvolvimento do trabalho não existiam plataformas abertas amplamente dispońıveis, como é o caso do sistema AndroidTM(que será discutido no próximo caṕıtulo), motivo pelo qual, apesar de ressaltar a vantagem de se utilizar uma plataforma aberta e livre, escolheu-se na época o sistema fechado Symbian para desenvolvimento. O presente trabalho distingue-se dos anteriores ao apresentar não apenas os módu- los do Ginga-NCL desenvolvidos em sistema AndroidTM, mas também por realizar um conjunto de experimentos realizados sobre a plataforma, complementando as discussões 2.2 Padrões para Dispositivos Portáteis 20 iniciadas em [4], particularmente por meio de uma análise aprofundada da execução de aplicações NCL em dispositivos portáteis. 2.2 Padrões para Dispositivos Portáteis Esta seção tem por objetivo realizar uma apresentação das principais organizações, hoje existentes, responsáveis por estabelecer padrões e normatizações para televisão digital portátil. Diferentemente da abordagem utilizada por [10], esta seção irá apresentar de forma resumida as principais organizações e seus respectivos padrões. 2.2.1 DVB O Digital Video Broadcasting Project (DVB) é um consórcio formado por indústrias, operadoras, desenvolvedores de sistemas e organizações reguladoras que atua em 35 páıses com objetivo de desenvolver um padrão aberto para televisão e serviços digitais. Oficialmente em 2004 foi adotado como padrão do grupo o Digital Video Broadcasting Home (DVB-H), a fim permitir a transmissão da TV Digital para os dispositivos por- táteis. O desenvolvimento deste padrão objetivou atender aos requisitos dos handhelds 2, entretanto, ele também pode ser utilizado em outros dispositivos com caracteŕısticas semelhantes, como os smartphones 3. O Multimedia Home Platform (MHP) é o middleware de televisão digital do DVB, sendo que o principal objetivo desta especificação é permitir a utilização de serviços criados para TV Digital, independente da plataforma para a qual tenha sido desenvolvido. O MHP define o Digital Video Broadcast HyperText Markup Language (DVB-HTML) e o Digital Video Broadcast Java (DVB-J) como seus ambientes declarativos e procedurais, respectivamente. A implementação do primeiro é opcional, dado que ele está embutido no segundo [22]. 2.2.2 ARIB A Association of Radio Industries and Businesses (ARIB) foi designada como cen- tro para a promoção do uso eficiente do espectro de rádio pelo Ministério dos Assuntos 2Personal digital assistants (PDAs ou Handhelds), ou Assistente Pessoal Digital, pode ser classificado como um computador de dimensões reduzidas. 3Smartphone é um telefone celular com funcionalidades avançadas que podem ser estendidas por meio de programas executados no seu Sistema Operacional. 2.2 Padrões para Dispositivos Portáteis 21 Internos e Comunicações do Japão (MIC), sendo responsável pela realização de estudos de rádio difusão, estabelecimento de normas, fornecimento de serviços de consultoria, cooperação com outras organizações no exterior e fornecimento de serviços de apoio a assuntos relacionados à televisão digital. Todas estas atividades são realizadas em colabo- ração e com a participação de operadores de telecomunicações, radiodifusão, fabricantes de equipamentos de rádio e organizações relacionadas. O Integrated Services Digital Broadcasting Terrestrial (ISDB-T) é o padrão para TV Digital Terrestre definido por essa organização. Este padrão já dispõe dos requisitos ne- cessários para implementação de middlewares para ambientes portáteis, como é observado em [23]. Já existem alguns dispositivos portáteis, chamados de One Seg Devices, que oferecem suporte ao ISDB-T. Exemplos são: D903iTV, P903iTV, e o SH903iTV. O middleware de TV Digital do ISDB-T é baseado na linguagem Broadcast Markup Language (BML), que é de natureza declarativa e baseada em XHTML1.0 [24]. 2.2.3 ATSC O Advanced Television Systems Committee (ATSC) definiu o Advanced Common Ap- plication Platform (ACAP) como padrão norte-americano de difusão de serviços de tele- visão digital [25]. Uma aplicação ACAP pode ser entendida como uma coleção de informações que são processadas por um ambiente de execução, a fim de interagir com um usuário final ou alterar o estado do ambiente do aplicativo. Aplicações ACAP são classificadas de acordo com a forma que o conteúdo é processado, sendo estas categorias divididas em procedurais (ACAP-J) e declarativas (ACAP-X). Este padrão - Advanced Television Systems Committee Mobile/Handheld (ATSC M/H) - não é considerado, a prinćıpio, adequado ao ambiente portátil, de acordo com [23], tendo em vista a utilização do 8-VSB [26] como técnica de modulação. Entretanto, o comitê está em vias de aprovar uma extensão desse padrão para suportar dispositivos móveis. Em dezembro de 2008, o status dele era de ’padrão candidato’ e em julho de 2009, após algumas modificações, foi elevado para ’padrão recomendado’, estando em vias de aprovação. 2.2 Padrões para Dispositivos Portáteis 22 2.2.4 SBTVD O Sistema Brasileiro de Televisão Digital (SBTVD) é também chamado de ISDB- Tb (padrão japonês ISDB-T, versão brasileira) e difere do ISDB-T, principalmente, pelo emprego da compressão de v́ıdeo [27] (MPEG-4) enquanto o ISDB-T utiliza [28] (MPEG- 2), e também pelo suporte para interatividade utilizando o middleware Ginga. As instituições Pontif́ıcia Universidade Católica do Rio de Janeiro (PUC-RJ) e a Universidade Federal da Paráıba (UFPB) foram duas das principais responsáveis pela especificação do middleware Ginga para o Sistema Brasileiro de TV Digital, sendo a primeira responsável pela especificação do ambiente Declarativo (Ginga-NCL) [20] e a segunda propós a primeira proposta para o ambiente Procedural (Ginga-J) [29]. A utilização de ambos os ambientes é obrigatória nos terminais fixos; porém, apenas o ambiente declarativo Ginga-NCL é obrigatório para dispositivos portáteis. A fim de se permitir o desenvolvimento de aplicações h́ıbridas em terminais portáteis, o padrão determina os meios pelos quais entidades declarativas e procedurais podem se comunicar através de uma ponte entre os dois ambientes. Já existem implementações comerciais do middleware Ginga para dispositivos portá- teis do Sistema Brasileiro de Televisão Digital. A normatização atualmente em vigor, [21], especifica os requisitos necessários para implementação do ambiente declarativo neste tipo de dispositivo. O Ginga-NCL determina profiles que contêm subconjuntos dos módulos da linguagem, usados para atender a diferentes requisitos, sendo o Basic DTV, perfil mı́nimo para dispositivos portáteis, especificado em [21]. 2.2.5 3GPP A 3rd Generation Partnership Project (3GPP), é uma organização resultante de um acordo de colaboração firmado entre empresas de padronização em telecomunicações. Fun- dada em 1998 pela união entre European Telecommunications Standards Institute (ETSI), Association of Radio Industries and Businesses (ARIB), China Communications Stan- dards Association (CCSA), Alliance for Telecommunications Industry Solutions (ATIS) e Telecommunications Technology Association (TTA), foi responsável pelo padrão Mo- bile Broadcast/Multicast Service (MBMS) de transmissão de TV Digital para dispositivos portáteis. MBMS é uma tecnologia para distribuição de TV portátil por redes celulares para 2.3 Sistemas Operacionais para Dispositivos Portáteis 23 pequenos terminais (aparelhos de mão). MBMS usa os recursos de rede mais eficiente- mente, através de conexão ponto a multiponto, comparada com difusão única, no qual cada sessão tem uma conexão separada do servidor de TV portátil para o terminal. Segundo [23] o MBMS é adequado para transmissão de conteúdos básicos, possibili- tando alguns serviços de streaming em tempo real. Segundo o mesmo documento, para streamings 4 pesados em redes complexas e densas, outras soluções se mostram mais adequadas. 2.2.6 DMB Digital Multimedia Broadcasting (DMB) é uma tecnologia de transmissão rádio-digital desenvolvida pela Coréia do Sul como parte do projeto nacional de tecnologia de infor- mação para transmissões tais como: TV, rádio e dados para dispositivos portáteis. Foi com o DMB que o primeiro serviço de televisão portátil digital no mundo deu-se na Coréia do Sul em Maio de 2005, embora testes já estivessem dispońıveis muito mais cedo. Este sistema oferece suporte para operação via satélite (S-DMB) ou terrestre (T-DMB). O DMB também possui algumas semelhanças com os principais concorrentes da tele- visão portátil como o DVB-H. Basicamente sua arquitetura é composta de três camadas: compressão, sincronização e transporte. A linguagem utilizada como descritora de cenas e a sincronização são feitas com o uso do MPEG4 BIFS e MPEG4 SL [30], respectivamente, e o transporte foi implementado com o uso do MPEG2 TS [31]. 2.3 Sistemas Operacionais para Dispositivos Portá- teis Nesta seção é realizada uma apresentação dos principais sistemas operacionais encon- trados atualmente nos dispositivos portáteis comercializados. Suas caracteŕısticas quanto às licenças de uso, possibilidade de desenvolvimento, adequação ao SBTVD e posiciona- mento no cenário mundial também serão discutidas. 4Streaming (fluxo, ou fluxo de mı́dia em português) é uma forma de distribuir informação multimı́dia numa rede através de pacotes. 2.3 Sistemas Operacionais para Dispositivos Portáteis 24 2.3.1 iPhone OS O iPhone OS é um sistema operacional (SO) desenvolvido pela empresa Apple utili- zado exclusivamente nos dispositivos iPhone e iPod, produzidos também por essa empresa. A base do sistema deriva do sistema operacional Mac OS e a arquitetura é composta de quatro camadas: núcleo do sistema operacional, a camada de serviços, a camada de mı́dia e a camada ’Cocoa touch’5. Sua licença de distribuição é General Public License versão 3 (GPLv3) [32] que determina que qualquer aplicação desenvolvida precisa ser submetida à Apple Store6 que efetuará uma avaliação para distribúı-la, sendo que a distribuição ocorrerá somente após aprovação assinada com chaves de propriedade da Companhia. Para o seu desenvolvimento é utilizada a linguagem Objective-C que é um pacote derivado do ANSI C [33] que provê orientação a objetos. Um Kit de Desenvolvimento (SDK) contendo um emulador é disponibilizado; porém, é necessário o pagamento de uma taxa de desenvolvedor para testar as novas aplicações no dispositivo real. Estes fatores tornam o desenvolvimento para o iPhone relativamente mais caro e complexo que outras plataformas. No que se refere ao SBTVD, o iPhone não possui suporte nativo; porém, uma empresa japonesa que distribui o iPhone 3G, a Softbank, desenvolveu um receptor do sistema japonês. Este transmissor recebe o sinal e o repassa ao aparelho através de uma interface sem fio embutida. Em fevereiro de 2010, o sistema da Apple dominava o mercado global de tráfego de informações via smartphones. Durante o peŕıodo de Fevereiro de 2009 a Fevereiro de 2010, o iPhone aumentou a sua quota de 33% para 50% [34]. Na América latina essa quantidade é ainda maior, atingindo um total de 56% em dezembro de 2009 [35]. 2.3.2 Symbian Symbian é um sistema operacional aberto, cuja maior parte dos seus recursos está sob a licença Eclipse Public Licence (EPL) [36] e alguns demais componentes estão disponi- bilizados sob outras licenças. Assim como todo sistema portátil, ele também possui alguns recursos para gerenciar e reduzir a utilização de bateria e de memória. Um ponto forte desta plataforma é a ver- 5Cocoa Touch é uma API para a criação de programas de software para funcionar no iPhone, iPod Touch e do IPAD da Apple Inc. 6A Apple Store é uma cadeia de lojas de varejo de propriedade e operação pela Apple Inc., que vendem e tratam de computadores e equipamentos eletrônicos da Apple. 2.3 Sistemas Operacionais para Dispositivos Portáteis 25 satilidade no desenvolvimento de aplicações. Atualmente, ele fornece suporte à Symbian C/C++, JavaME, FlashLite, Perl, Python, Ruby e Lua . No que tange a SBTV Digital, Symbian possui uma versão, a 9.5, que oferece suporte a esse tipo de aplicação, aceitando, atualmente, dois padrões de modulação/transmissão, o DVB-H e o ISDB-T. No último ano, a plataforma Symbiam perdeu uma fatia considerável de mercado glo- bal de transmissão de dados em smartphones, saindo de 43% em Fevereiro de 2009 para 18% em Fevereiro de 2010 conforme [34] e [37]. Entretanto, a plataforma Symbiam ainda aparece com quotas de mercado consideráveis (77%) a medida que regiões espećıficas são analisadas, tais como: Índia, Indonésia, Austrália, Filipinas, Tailândia, Malásia, Singa- pura e Hong Kong [38]. Na América Latina, por exemplo ao final do ano de 2009, esta plataforma detinha 28% do mercado [35]. 2.3.3 Windows Mobile O Windows Mobile é um sistema operacional, desenvolvido para ser executado em dispositivos portáteis em geral. Devido à semelhança com o sistema operacional Windows amplamente utilizado em PC’s este sistema operacional é em geral muito bem aceito pelos usuários. Além disso, as ferramentas utilizadas para o desenvolvimento de aplicações são as mesmas da sua versão desktop, como o Visual Studio ou o .NET. Recentemente, foi disponibilizada a ferramenta gratuita Microsoft eMbedded Visual C++, concebida especificamente para o desenvolvimento de programas visando disposi- tivos embarcados. Porém, o pacote ainda recomendado pela Microsoft para o Windows Mobile é o recente Windows Mobile 6.5 Developer Resource Kit. Este pacote contém o Visual Studio, ferramenta não gratuita de desenvolvimento da Microsoft. Podemos destacar como principais diferenciais desta plataforma, o Microsoft Office que acompanha o Windows Mobile e que inclui o Pocket Word, o Pocket Excel, e o Pocket PowerPoint. Nestas versões há vários recursos das versões desktop, entretanto, ainda com algumas limitações. O programa de conexão ActiveSync, que acompanha os dispositivos, tem recursos que permitem converter os arquivos da versão desktop para a versão Poc- ket PC. O Windows Media Player 9 para o Windows Mobile suporta grande parte dos formatos de multimı́dia existentes, tais como .WMA, .WMV, .MP3, e .AVI. Em algumas versões é posśıvel reproduzir arquivos MPEG4 Audio (.M4A). Como ponto negativo, o custo de uma licença do Visual Studio é um fator determi- 2.3 Sistemas Operacionais para Dispositivos Portáteis 26 nante na utilização desta plataforma. O custo da licença do Windows Móbile varia de $8,00 a $15,00 por dispositivo, de acordo com a Strategy Analytics7. No cenário global, o sistema operacional da Microsoft tem mantido a estabilidade variando de 2% a 4% nos anos de 2009 a 2010 conforme [34] e [37]. Na América Latina este cenário se mantém, considerando que em dezembro de 2009 este SO possuia 6% do mercado [35]. 2.3.4 BlackBerry OS BlackBerry é o produto vendido pela empresa Research In Motion (RIM). A solução BlackBerry é composta por smartphones com um software integrado que possibilita acesso a uma série de serviços de dados e comunicação. O seu sistema operacional é proprietário e é feito dedicadamente para os handhelds e outros dispositivos portáteis produzidos por esta empresa. A RIM não disponibiliza o seu SO para que outras empresas utilizem, sendo assim, apenas os hardwares fabricados pela própria RIM o possuem. O desenvolvimento de aplicativos para esta plataforma pode ser realizado em Java através de uma plataforma disponibilizada pelo fabricante ou através de BlackBerry Mobile Data System (BMDS). O BlackBerry Mobile Data System v4.1 é um pacote de desenvolvimento de aplica- tivos para a BlackBerry. A sua arquitetura pode ser subdividida em três componentes principais: • BlackBerry MDS Services - Como parte do BlackBerry Enterprise Server, é respon- sável pelo gerenciamento de interações e solicitações entre smartphones BlackBerry e aplicativos empresariais protegidos por firewall. • BlackBerry MDS Developer Tools - Ferramentas para desenvolvedores possibilitando a criação de aplicativos sem fio para smartphones BlackBerry. • BlackBerry MDS Device Software - O BlackBerry MDS Device Software permite que aplicativos criados com Blackberry MDS Developer Tools sejam executados em smartphones BlackBerry. 7Strategy Analytics, Inc., é uma empresa global de pesquisa e consultoria que concentra-se em opor- tunidades de mercado e nos desafios das áreas da Eletrônica Automotiva, Consumidor Digital, Mundos Virtuais, Estratégias Wireless, Tarifas e em Tecnologias Embarcadas. 2.3 Sistemas Operacionais para Dispositivos Portáteis 27 As aplicações de desenvolvimento em ambas as linguagens citadas anteriormente são gratuitas. Os aparelhos da BlackBerry não possuem boa interação com outros tipos de dispositivos. Algumas aplicações, como e-mail, por exemplo, funcionam apenas com um conjunto espećıfico de dispositivos de outras marcas. Até o momento da publicação deste trabalho não existia nenhuma implementação na plataforma BlackBerry adequada ao SBTVD. Assim como o Symbian, o sistema operacional da RIM, tem perdido mercado nos últimos anos. De agosto de 2009 à Fevereiro de 2010 a fatia de mercado da plataforma passou de 8% para 4% conforme [34] e [37]. 2.3.5 AndroidTM Uma das mais recentes e talvez a mais promissora das plataformas é a plataforma AndroidTM. O AndroidTMé um sistema aberto constitúıdo em uma pilha de software para dispositivos portáteis incluindo o sistema operacional Linux 2.6 e algumas aplicações já incorporadas chamadas de ’aplicações cŕıticas’. Qualquer aplicação escrita para este SO deve utilizar a linguagem de programação Java, e posteriormente ser compilada para execução em uma máquina virtual Dalvik (Dal- vik Virtual Machine) projetada especificamente para utilização em ambientes embarcados. O Kit de Desenvolvimento para AndroidTM(Android SDK) fornece as ferramentas e bi- bliotecas necessárias para desenvolvimento de aplicações na plataforma AndroidTMusando a linguagem de programação Java, sendo que os desenvolvedores possuem acesso irrestrito à maior parte da codificação destas bibliotecas, o que de fato facilita em muito o desen- volvimento de aplicativos para esta plataforma. O AndroidTMinclui um conjunto de bibliotecas C/C++ utilizadas por diversos com- ponentes do sistema. Estas funcionalidades são expostas para os desenvolvedores através do framework AndroidTM. Algumas das principais bibliotecas estão listadas abaixo: • System C library • Media Libraries • Surface Manager • LibWebCore 2.3 Sistemas Operacionais para Dispositivos Portáteis 28 • SGL • 3D libraries • FreeType • SQLite. Até o momento da publicação deste trabalho não existia nenhuma implementação na plataforma AndroidTMadequada ao SBTVD. No que se refere ao mercado de tráfego global, AndroidTMé o sistema operacional que mais rapidamente cresce ano após ano. Avaliações indicam que a plataforma Android aumentou fatia de mercado de 2% em fevereiro de 2009 para 24% em fevereiro de 2010. Os cinco dispositivos AndroidTM, que mais se destacam em todo o mundo são os Motorola Droid, HTC Dream, HTC Hero, HTC Magic e o Motorola CLIQ [34]. Na América Latina estes dispositivos começaram a ser comercializados recentemente o que justifica o fato de a plataforma AndroidTMsomente possuir 1% do mercado na região [35]. 2.3.6 PalmOS PalmOs é um sistema operacional inicialmente desenvolvido pela empresa U.S Robotics subsidiária da Palm Computing, Inc. para personal digital assistants (PDAs) em 1996. O seu desenvolvimento é baseado na utilização de tela senśıvel ao toque incluindo interfaces gráficas simplificadas. Ele é fornecido em conjunto a um pacote de aplicações básicas para utilização nos PDA’s. As últimas versões desse sistema foram a PalmOS Garnet e a PalmOS Cobalt, sendo que a última nem chegou a ser lançada comercialmente. Em 2009, a detentora comercial do PalmOS, a Palm Inc, informou a descontinuação do Palm OS para focar o desenvolvimento do WebOS para os próximos dispositivos. De fato, o PalmOS tem tentado se manter no mercado, muito embora não tenha conseguido se sobressair em relação aos seus concorrentes. Certamente, devido a isto a detentora dos direitos do PalmOS esteja focando o desenvolvimento de uma nova plata- forma. Ainda para ilustrar a realidade da Palm, Inc até mesmo alguns aparelhos desta empresa não utilizam a variante do seu sistema operacional, utilizando a variante do Windows anteriormente citado, como é o caso do Treo 700w e do Treo 750. 2.4 Considerações Finais 29 Até o momento da publicação deste trabalho não existia nenhuma implementação na plataforma PalmOS adequada ao SBTVD. O sistema PalmOs tem sido desconsiderado nos últimos levantamentos mercadológicos, tendo em vista a sua mı́nima participação no mercado. Em contrapartida o sistema WebOs se mostrou com um pequeno crescimento na América do Norte, passando de 3% naquela região em dezembro de 2009 [35]. 2.4 Considerações Finais Neste caṕıtulo foi posśıvel contextualizar o trabalho no cenário da televisão digital em dispositivos portáteis apresentando um histórico da televisão digital no Brasil, bem como referenciando organizações assim como sistemas operacionais cujo foco é em dispositivos portáteis. Pela análise da literatura existente e pela percepção do mercado de televisão digital no Brasil, pode-se observar a existência de uma lacuna para desenvolvimento de middeware para dispositivos portáteis no padrão SBTVD e de novas tecnologias de televisão digital no padrão SBTVD. As referências para pesquisas ainda são poucas, e também nota-se a existência de poucos produtos no mercado cujo foco seja este. Sem dúvida, deve haver um maior incentivo governamental tanto para as indústrias quanto para os pesquisadores, de forma a fomentar as pesquisas, bem como o desenvolvimento de novas linhas de produtos voltados a este mercado. Nos próximos caṕıtulos serão enfatizados o SBTVD e a plataforma Android apresen- tadas neste caṕıtulo, de forma que no caṕıtulo 3 detalhes da plataforma AndroidTMserão discutidos e no caṕıtulo 4 uma implementação do Ginga-NCL no padrão SBTVD na plataforma AndroidTMserá proposta. 30 3 Plataforma AndroidTM “O imperador do futuro será um imperador de ideias.” Wiston Churchill 3.1 O que é AndroidTM? 31 Este caṕıtulo tem como objetivo posicionar o leitor na plataforma que foi utilizada para implementação do middleware para dispositivos portáteis. Será apresentado um resumo das principais funcionalidades da plataforma AndroidTM, bem como uma breve descrição e algumas referências que podem ser utilizadas no aprofundamento do estudo do respectivo sistema. 3.1 O que é AndroidTM? A plataforma AndroidTMfoi lançada em 2008 pelo Google, por meio do consórcio Open Handset Alliance [39]. Trata-se de uma plataforma de código aberto, não vinculada apenas a um fabricante, fato este que tem permitido a ampliação da restrita área de telefonia móvel. O AndroidTMconsiste em um sistema operacional baseado no kernel Linux 2.6 e provê uma Application Programming Interface (API) na linguagem Java cujas aplicações desen- volvidas são compiladas para a máquina virtual Dalvik. Esta máquina virtual foi projetada especialmente para a plataforma AndroidTM, sendo otimizada para rodar em dispositivos portáteis. Para os desenvolvedores, há um Software Development Kit (SDK) dispońıvel em licença GPLv2 e já existe uma ampla gama de aparelhos com AndroidTMembarcado. Apesar de ter sido constrúıdo com base no Linux, a plataforma não possui todas as funções de uma plataforma Linux padrão, por exemplo, não possui windowing system nativo (componente GUI) e não suporta glibc. 3.2 Arquitetura A arquitetura do sistema operacional AndroidTM, recomendada pela Open Handset Alliance, possui um bom grau de liberdade para o desenvolvimento de aplicações no ambiente de telefonia móvel [40]. Grande parte das aplicações são escritas usando a linguagem de programação Java e compiladas em byte-code espećıfico para uma máquina virtual projetada especialmente para uso em ambiente embarcados. Essa máquina virtual, chamada de Dalvik VM, tem um modelo no qual cada aplicação é executada sob uma instância da máquina virtual (VM). Dessa forma, cada aplicação associada a uma VM tem o seu espaço de endereçamento separado. 3.2 Arquitetura 32 Apesar de a maioria das aplicações AndroidTMserem escritas na linguagem Java, a Dalvik não é uma máquina virtual Java, já que não executa bytecode JVM. Além disso, todo o gerenciamento da memória dos processos (instâncias Dalvik) e o controle de dispo- sitivos, como câmera e GPS, é feito pelo Linux compilado em processador arm, mips, ppc ou x86 e sua imagem binária pode rodar tanto nos celulares como no emulador provido com o kit de desenvolvimento. O diagrama abaixo apresenta os principais componentes do AndroidTM. Figura 3.1: Componentes do AndroidTM Na parte mais acima da Figura 3.1 estão inclúıdas todas as Aplicações que o cliente pode executar. Logo em seguida no diagrama aparece o Framework das Aplicações, que é o conjunto de classes que permite o desenvolvimento destas aplicações. As principais classes deste conjunto serão detalhadas na Seção 3.2.1. Na camada inferior ao Framework das Aplicações tem-se as bibliotecas escritas em C/C++ usadas para prover acesso ao hardware aos vários componentes do AndroidTM. Estas bibliotecas foram desenvolvidas e otimizadas de uma forma que a execução de suas funções não é dependente da máquina virtual Dalvik e por essa razão possuem acesso privilegiado ao hardware, comparável com device drivers [41] em sistemas operacionais. A plataforma provê para isso o Android NDK, que é um conjunto de ferramentas que acom- panha o SDK nativo que permite o desenvolvimento de aplicações, utilizando a linguagem 3.2 Arquitetura 33 C/C++, cuja execução é independente da máquina virtual Dalvik. Entre essas bibliotecas tem-se toda a parte de multimı́dia usando vários codificadores como MPEG4, H.264, MP3, AAC, AMR, JPG, e PNG, uma biblioteca especifica para renderização de 3D em caso de acelerador gráfico no smartphone e um banco de dados relacional. Por fim, no ńıvel de sistema operacional, a versão 2.6 do Linux foi escolhida para prover os serviços cŕıticos como gerencia da memória e processos, além de prover a camada de abstração entre o dispositivos de hardware e o resto da pilha de software. 3.2.1 Conceitos básicos para desenvolvimento em AndroidTM A maior parte dos aplicativos para AndroidTMdevem ser escritos na linguagem de pro- gramação Java, apesar de também ser posśıvel o desenvolvimento usando c/c++, ainda assim qualquer desenvolvedor que pretenda escrever aplicações nesta plataforma deverá necessariamente conhecer os fundamentos desta linguagem de programação [42]. O código Java implementado pelo desenvolvedor deve ser compilado juntamente com todos os arqui- vos e recursos necessários para o aplicativo, e posteriormente através de uma ferramenta disponibilizada é gerado um arquivo com sufixo .apk, a fim de possibilitar a distribuição da aplicação em dispositivos portáteis. Por padrão, cada aplicação é executada em seu próprio processo e cada processo possui sua própria Máquina Virtual (VM). A cada aplicação é atribúıdo um ID de usuário Linux exclusivo e as permissões são definidas para que os arquivos do aplicativo sejam viśıveis apenas para o usuário e apenas para a aplicação em si. Deve ser destacado que também existem formas de tornar uma aplicação viśıvel para as demais [43]. Também é posśıvel estruturar uma aplicação de forma que duas aplicações compartilhem o mesmo ID. Neste caso, para conservar os recursos do sistema, as aplicações com a mesma identificação podem ser executadas em um mesmo processo Linux, neste caso compartilhando a mesma VM. Activities O bloco de construção das interfaces de usuário no AndroidTMé uma Activity. Pode-se fazer uma analogia entre uma Activity no AndroidTMe uma Window ou um Dialog em uma aplicação para um desktop. Certamente esta é uma das classes mais importantes da plataforma. Cada Activity é responsável por controlar os eventos da tela e definir qual 3.2 Arquitetura 34 View será responsável por desenhar a interface gráfica do usuário [44]. Content Providers O AndroidTMpermite armazenar informações de diversas formas diferentes utilizando banco de dados, arquivos e o sistema de preferências. Contudo, geralmente essas informa- ções ficam salvas dentro do pacote da aplicação, e somente a aplicação que criou o banco de dados ou o arquivo pode ter acesso às informações. Os Content Providers provém um ńıvel de abstração para que qualquer dado guardado no dispositivo seja acesśıvel por mais de uma aplicação. O desenvolvimento na plataforma AndroidTMfavorece os recursos de uma aplicação, de modo que sejam acesśıveis por outras aplicações. Content Providers possibilita que se faça isso, e que se mantenha total controle de como esses recursos são utilizados. Intents Intents são mensagens de sistema que são executadas sempre que um evento ocorre a fim de notificar as aplicações embarcadas de sua existência, por exemplo, na inserção de um cartão SD ou o recebimento de uma mensagem SMS. Os desenvolvedores não só podem responder aos Intents como podem executar suas aplicações quando um destes eventos ocorre. Services A classe Services é utilizada para executar um serviço em segundo plano, geralmente vinculado a algum processo que deve ser executado por tempo indeterminado e possui um alto consumo de recursos, memória e CPU. Intents, Activities e Content Providers são temporárias e podem desaparecer a qual- quer momento. Services, por outro lado, devem ser desenvolvidos para se manterem em execução a qualquer momento, de preferência, independentes de qualquer Activity. Handler Um Handler possibilita o envio de mensagens (android.os.Message) e o processamento de objetos do tipo Runnable associados a threads, ou seja, cada handler é associado a uma única thread e a sua fila de mensagens respectivamente. Quando se cria um Handler, ele 3.2 Arquitetura 35 se vincula a thread que o criou, e a partir daquele momento ele irá enviar mensagens e executar objetos do tipo Runnable na seqüência em que eles são enviados a sua fila. 3.2.2 Interface com usuário Em uma aplicação desenvolvida para o sistema AndroidTM, a interface com o usuário é feita através de objetos do tipo View e View Group, que são as unidades básicas de interface nesta plataforma. A classe View serve como base para as subclasses widgets, que são implementações completas de objetos comuns, tais quais campos de texto e botões. Já a classe ViewGroup serve como base para as subclasses layout, que definem diferentes tipos de arquitetura visual para a aplicação, como linear, tabular e relativa. Um objeto do tipo View é uma estrutura de dados cujas propriedades guardam os parâmetros de leiaute e conteúdo para uma área retangular espećıfica na tela. Ele gerencia as medidas, leiaute, desenhos, mudança de foco, rolagem e interações por tecla e toque da área retangular em que reside. Como um objeto na interface com usuário, a View é um ponto de interação e um receptor dos eventos de interação. A partir destes elementos é posśıvel construir a interface de uma Activity, agrupando os em uma árvore n-ária (Figura 3.2) cuja raiz é um nó do tipo ViewGroup, que define o leiaute mais abrangente desta Activity. Esta árvore pode ser tão complexa quanto o necessário, podendo utilizar apenas os objetos definidos pela API ou objetos criados pelo usuário, que estendem a classe View. Para a renderização desta árvore na tela, uma referência ao nó raiz é passada a um método da API que irá validar, medir e desenhar a árvore. O processamento da ár- vore de leiaute é feito de uma forma top-to-bottom, de modo que vai instanciando Views e adicionando-as aos seus elementos pais, fazendo com que, caso haja sobreposição de elementos, o último a ser desenhado seja colocado na frente. A maneira mais comum de definir a árvore de Interface com Usuário é por meio de um arquivo XML de leiaute, em que cada elemento do XML é um objeto View ou ViewGroup. Esta maneira é a mais indicada para construir aplicações cujo leiaute é estático, ou seja, apenas o conteúdo apresentado será modificado em tempo de execução, permanecendo inalterada a disposição dos elementos da interface. Para aplicações que precisem modificar a estrutura do leiaute em tempo de execução, é posśıvel construir a árvore em código Java, utilizando métodos da API. 3.2 Arquitetura 36 Figura 3.2: Estrutura em árvore da interface Activity retirada de [1] Um widget é um objeto View que serve como uma interface de interação com o usuário. A API AndroidTMoferece um conjunto de elementos widget totalmente implementados que de fato ajudam muito no desenvolvimento de uma aplicação. Uma vez adicionadas algumas widgets para interfacear com usuário, o próximo passo é controlar a interação do usuário com eles, para que se possam realizar ações. Para uma aplicação ser informada de eventos interface do usuário, existem duas formas: A primeira é definir um listener de evento e registrá-lo como uma View. A outra, é implementar um método Callback para a View. A primeira é a forma mais conhecida e usual da linguagem JAVA. A classe de View contém uma coleção de interfaces aninhadas de nomes OnListener, e sempre que for necessário capturar o evento estas classes devem ser implementadas. A segunda forma é o que se deve fazer quando se implementa uma classe View própria e é necessário escutar eventos espećıficos que ocorrem dentro dela. 3.2.3 Recursos Resources e Assets são uma parte integral de uma aplicação para a plataforma AndroidTM. Em geral, são elementos externos inclúıdos e/ou referenciados na aplicação, tais como imagens, áudio, v́ıdeo, strings, leiautes, temas, etc. Toda aplicação AndroidTM, portanto, contém um diretório para resources (res/) e um para assets (assets/). 3.2 Arquitetura 37 A diferença entre resources e assets está na forma com que são acessados pela apli- cação. O conteúdo do tipo resource é acesśıvel via a classe R, que é compilada pelo AndroidTM. Já o conteúdo do tipo asset é acesśıvel apenas através do AssetManager, que lê o arquivo como um byte stream. Existem diferentes tipos de elementos que podem ser adicionados aos resources de uma aplicação, tais como simples valores de elementos comumente usados e imagens necessárias para a interface. Uma descrição destes diferentes tipos será feita a seguir. Valores de elementos podem ser expressos como strings, utilizando formatos não am- b́ıguos para indicar os diferentes tipos de valores. Valores de cor sempre começam com #, seguido pelo valor da cor no formato A-RGB (alpha red green blue). Valores de texto são strings não começadas por # e podem conter tags html para formatação. Drawables, ou desenháveis, são elementos utilizados para a interface com usuário. Documentos bitmap suportados são png, o tipo prefeŕıvel, jpg e gif. Os bitmaps são compilados e disponibilizados à aplicação sem a extensão, através da classe R, como, por exemplo, res/drawable/imagem1.png é acesśıvel por R.drawable.imagem1. Color drawa- bles são retângulos preenchidos com uma cor RGB. Por fim, imagens Nine-Patch são um tipo de imagem expanśıvel, em que um conjunto de 9 seções da imagem é utilizado para desenhá-la, sendo 4 bordas em quina, 4 bordas retas e 1 imagem de centro. Esta imagem deve ser do tipo png e sua extensão deve ser de 9.png sempre. Por fim, elementos important́ıssimos, como os leiautes, Menus e Animações utilizados em mais de uma activity da aplicação podem ser resources comuns a aplicações, para melhor reuso. Estes elementos são definidos através de um arquivo XML que segue uma formatação definida pela plataforma AndroidTMe são acesśıveis através da classe R. 3.2.4 Elementos Gráficos Os elementos gráficos da plataforma AndroidTMsão gerenciados por uma biblioteca própria para gráficos em duas dimensões (2D) e OpenGL ES 1.0 com alta performance para elementos em três dimensões (3D). Os recursos mais comuns para gráficos em 2D podem ser encontrados no pacote drawable. As APIs OpenGL estão dispońıveis a partir do pacote Khronos ES OpenGL [45]. Basicamente existem duas maneiras de se utilizar gráficos 2D em uma aplicação, que são: 3.2 Arquitetura 38 1. Utilizando um método da classe Draw() 2. Utilizando um objeto de uma View Na primeira forma, desenham-se os gráficos diretamente na tela por linha de códigos. Esta é a melhor opção quando a performance da manipulação de gráficos de uma aplicação é algo essencial, como em animações procedurais. Na outra forma, utilizando um objeto da classe View, o gráfico é subordinado à hierarquia desta View no sistema, sendo assim, o programador simplesmente define qual gráfico irá aparecer. Esta é a melhor opção quando há necessidade da utilização de gráficos estáticos e animações pré-definidas [46]. O desenvolvimento de aplicações em 3D é através do OpenGL ES que é uma especi- ficação do OpenGL destinada a dispositivos embarcados. AndroidTMatualmente suporta OpenGL ES 1.0, que corresponde ao OpenGL 1.3. Assim, um aplicativo desenvolvido com OpenGL 1.3 em um sistema desktop, deverá ser portável em AndroidTM. A API espećıfica fornecida pelo AndroidTMé similar ao OpenGL ES JSR239 J2ME API. 3.2.5 Audio, Vı́deo e Imagens Segundo informações do fórum de desenvolvedores bem como informações contidas na página oficial [47], as tabelas abaixo descrevem os formatos de mı́dia de áudio (Tabela 3.1), v́ıdeo (Tabela 3.2) e imagem (Tabela 3.3) suportados pela plataforma AndroidTM. É importante destacar, porém, que qualquer fabricante de dispositivo móvel também pode fornecer suporte para formatos adicionais ou tipos de arquivo não constantes na tabela abaixo. Como não é o objetivo deste trabalho discutir formatos de mı́dia, destacaram-se na coluna ’Referência’ os locais onde se podem obter maiores informações referentes a cada formato. Nas colunas ’Codifica’ e ’Decodifica’, têm-se a informação se a plataforma realiza tais operações e na última coluna são apresentados os tipos de arquivo de mı́dia suportados para cada padrão. 3.2 Arquitetura 39 Tipo Formato Codifica Decodifica Referência Tipo do arquivo suportado AAC LC/LTP Não Sim ISO/IEC 13818-7:2006 3GPP (.3gp) e MPEG-4 (.mp4, .m4a). HE-AACv1 (AAC+) Não Sim ISO/IEC 14496-3:2009 Sem suporte para AAC (.aac) HE-AACv2 (reforçada AAC+) Não Sim ISO/IEC 14496-3:2009 AMR-NB Sim Sim [48] 3GPP (.3gp) AMR-WB Não Sim [48] 3GPP (.3gp) Audio MP3 Não Sim ISO/IEC 11172-3:1993 MP3 (.mp3) Tipo 0 e 1 (.mid, .xmf, .mxmf). MIDI Não Sim [49] Também RTTTL/RTX (.rtttl, .rtx), OTA (.ota), e iMelody (.imy) Ogg Vorbis Não Sim [50] Ogg (.ogg) PCM/WAVE Não Sim [51] WAVE (.wav) Tabela 3.1: Padrões de áudio suportados Tipo Formato Codifica Decodifica Referência Tipo do arquivo suportado H.263 Sim Sim [52] 3GPP (.3gp) e MPEG-4 (.mp4) Vı́deo H.264 AVC Não Sim [53] 3GPP (.3gp) e MPEG-4 (.mp4) MPEG-4 SP Não Sim ISO/IEC 14496-2:2004 3GPP (.3gp) Tabela 3.2: Padrões de v́ıdeo suportados Tipo Formato Codifica Decodifica Referência Tipo do arquivo suportado JPEG Sim Sim [54] JPEG (.jpg) Imagem GIF Não Sim [55] GIF (.gif) PNG Não Sim [56] PNG (.png) BMP Não Sim [57] BMP (.bmp) Tabela 3.3: Padrões de imagens suportados 3.2.6 Segurança e Permissões A plataforma AndroidTMconsiste de um sistema multi-processos em que cada apli- cação, e partes do sistema rodam em seu próprio processo. Com isso, grande parte da segurança entre diferentes aplicações é feita por meio do ńıvel de processo no sistema Linux, utilizando User ID e Group ID para cada aplicação e diretivas de segurança mais robustas são realizadas através de restrições a operações espećıficas que um processo possa realizar. Um ponto central da plataforma é que nenhuma aplicação, por padrão, tem permissão de realizar operações que irão impactar outras aplicações, o sistema, ou o usuário. Isto inclui escrever ou ler dados privados do usuário (contatos, e-mail, etc.), escrever ou ler dados de outra aplicação, acessar a rede, controlar o hardware, etc. Caso uma aplicação necessite realizar tais operações, deve declará-las estaticamente, de modo que é posśıvel saber quais operações uma aplicação fará antes de instalá-la. 3.3 Considerações Finais 40 Além disso, cada desenvolvedor deve criar um par de chaves criptográficas e utilizá- las para estabelecer uma relação de segurança entre ele e o repositório de aplicações AndroidTM. Desta maneira, é posśıvel controlar quem terá acesso às aplicações no servidor e quais aplicações poderão compartilhar dados através de um mesmo ID de usuário. 3.3 Considerações Finais Logo que a primeira versão do AndroidTMfoi lançada, houve uma nova perspectiva tanto no meio corporativo quanto no acadêmico, pelo fato de estar nascendo uma plata- forma aberta para desenvolvimento de aplicações em dispositivos portáteis. Esta estra- tégia de construir um sistema operacional livre e de código aberto teve seus impactos, visto que levou a plataforma hoje dominante, Symbian, a anunciar no primeiro semestre de 2010 que os fontes também estariam dispońıveis para desenvolvedores como uma pla- taforma de código aberto em sua totalidade como uma maneira de não perder espaço de seus concorrentes. Alguns fatores importantes favoreceram o rápido crescimento da plataforma Android tais como: o suporte a mı́dias distintas; o suporte à multi camadas gráficas; a utilização de conceitos como processos a ńıvel de kernel com suporte de comunicação entre processos (IPC); a máquina virtual Dalvik que permite rodar o código compilado .apk de modo transparente em diferentes aparelhos e processadores e também o custo do licenciamento. Alguns requisitos, como Sintonizador (Tuner) e Filtro de Seção (Section Filter), con- tidos na normatização não foram avaliados dado que o hardware utilizado não oferece suporte a estes recursos, que são responsáveis por: i) fornecer uma interface que per- mite selecionar uma determinada freqüência ou realizar uma varredura em uma faixa de freqüência espećıfica e ii) oferecer uma interface para a filtragem de seções MPEG-2 TS, respectivamente. Entretanto, a partir da análise dos demais requisitos, não foi posśıvel observar um ponto cŕıtico que impedisse o desenvolvimento do middleware no padrão SBTVD que será apresentado no próximo caṕıtulo. 41 4 Implementação Ginga-NCL para AndroidTM “Quem pensa pouco erra muito.” Leonardo da Vinci 4.1 Análise e Modelagem 42 O projeto de desenvolvimento de um software é muito abrangente e envolve diversas etapas. Não está no escopo desta dissertação discutir cada uma das etapas do projeto para desenvolvimento do middleware Ginga para AndroidTM. Neste caṕıtulo serão apre- sentadas as principais fases de todo o projeto. Inicialmente serão listados os aspectos que foram considerados para a escolha da plataforma, assim como as etapas seguintes até a fase de codificação e testes, incluindo detalhes da codificação, bem como os diagramas de classes desenvolvidos. 4.1 Análise e Modelagem No projeto de desenvolvimento do middleware Ginga para a plataforma AndroidTM, [5], pode-se destacar a etapa em que foi realizada uma análise preliminar das plataformas existentes. Através dela foi realizada uma verificação das plataformas móveis quanto ao suporte à aplicações multimı́dia, à licença do código, ao ambiente de programação dispońıvel (SDK), à API proposta e ao custo para desenvolvedor. Foram avaliadas as plataformas Symbian, Windows, Apple, RIM e AndroidTM. A primeira delas é bem robusta e sem dúvida possui um excelente ambiente para desenvolvimento de aplicações, entretanto, no ińıcio dos trabalhos a plataforma ainda não estava totalmente aberta, fator este que foi determinante para a sua não utilização no projeto. As plataformas Apple, Windows e RIM assim como a primeira, são bem robustas, entretanto, o ambiente de desenvolvimento é proprietário e ainda existem algu- mas dificuldades em se obter suporte a algumas funcionalidades dessas plataformas. A questão do licenciamento também foi relevante dado que estas plataformas não possuem licenciamento gratuito. Após essa análise, foi escolhida a plataforma AndroidTMdevido ao sistema operacional ser de código aberto constrúıdo sobre o Kernel Linux 2.6, possuir disponibilidade de SDK sem custos, possuir API relativamente simples baseada em Java, oferecer suporte a diferentes mı́dias, oferecer um desenvolvimento cont́ınuo do sistema e devido à experiência dos executores que já haviam trabalhado nesta plataforma. Após a escolha definida, nosso foco voltou-se para uma análise detalhada na pla- taforma AndroidTMcom objetivo de elaborar o projeto conceitual da arquitetura Ginga especificamente sobre tal plataforma. Foi realizado também um levantamento das bibli- otecas que posteriormente deveriam ser estudadas com mais profundidade e que serão discutidas ao longo do caṕıtulo. 4.1 Análise e Modelagem 43 Para orientar o projeto conceitual, partiu-se de um estudo detalhado da normatização Ginga [58, 20, 59, 29, 21] a fim de entender os componentes essenciais da arquitetura. Com base neste estudo, foram elaborados os diagramas representados na Figura 4.1 e posteriormente os diagramas de classes que representam a estrutura base na qual o projeto está ancorado. Figura 4.1: Modelagem Quanto à arquitetura do middleware, a Figura 4.1 ilustra sua componentização, na qual se pode observar a divisão em dois subsistemas [4]: a máquina de apresentação NCL e o núcleo Ginga. Considerando o Ginga-NCL para o sistema AndroidTM, conforme demonstrado na mesma figura, a máquina de apresentação do middleware encontra-se inserido entre a camada de aplicações e o framework de desenvolvimento e, desta maneira, apoia-se na API do sistema para realizar operações espećıficas como a manipulação do ambiente gráfico. O núcleo encontra-se inserido no Core Libraries utilizando recursos providos pela plataforma, como Media Framework, WebKit, dentre outros. O núcleo Ginga é responsável por prover recursos necessários à máquina de apresenta- ção NCL. Seu componente Sintonizador tem o papel de receber conteúdo de TVD para dispositivos portáteis (1-seg) transmitido por provedores de conteúdo. As aplicações inte- rativas podem chegar ao dispositivo de dois modos, i) multiplexadas no conteúdo recebido 4.1 Análise e Modelagem 44 pelo Sintonizador, ou ii) por outra interface de rede (por exemplo, canal de dados oferecido pela operadora, conexão bluetooth, wifi, etc). Quando a aplicação estiver multiplexada, ela é obtida através de um processamento efetuado pelo módulo Processador de Dados sobre o conteúdo recebido. No caso em que a aplicação for recebida por uma interface de rede, o componente Transporte foi definido para gerenciar protocolos e interfaces de rede. Após o recebimento destas aplicações e o conteúdo referenciado por elas, o módulo Persistência atua para gerenciar seu armazenamento. O componente Exibidores é responsável pelos decodificadores espećıficos para cada tipo de mı́dia. Apoiando-se na API AndroidTM, foi utilizada para o desenvolvimento a biblioteca Media Libraries, a qual provê suporte à reprodução e gravação de áudio (MP3) e a alguns formatos de v́ıdeo baseados em MPEG-4, bem como arquivos de imagem estática BMP, GIF, JPG e PNG. Fortemente ligado a este, o componente Adaptadores é responsável pela padronização da comunicação entre a Máquina de Apresentação e a API de decodificação de conteúdo dos exibidores. Ainda como os Exibidores, os Adaptadores seguem uma padronização de interface. O componente Gerenciador Gráfico foi definido para realizar o controle espacial da renderização de objetos de acordo com o especificado pelas aplicações de TV. A biblioteca Surface Manager do AndroidTMfoi utilizada no gerenciamento do subsistema de exibição e camadas gráficas. No subsistema da máquina de apresentação, o principal componente é o Formatador e seu papel consiste em direcionar todas as ações a serem executadas por ela. Inicialmente, o Formatador solicita ao Conversor que processe a aplicação NCL, previamente rece- bida e processada por uma estrutura denominada Base Privada. A gerência de todas as bases presentes no middleware é feita pelo componente Gerenciador de Bases Privadas. Após receber esta estrutura de dados, o Formatador dispara a execução do Esca- lonador, cuja responsabilidade é gerir a execução e temporização das mı́dias presentes na aplicação NCL. O Escalonador atribui ao Gerenciador de Exibidores o proces- samento dos recursos necessários para exibição de cada mı́dia, e ao componente Ge- renciador de layout a responsabilidade de definir os parâmetros de exibição NCL no dispositivo. 4.2 Implementação 45 4.2 Implementação Como ponto de partida para a implementação, foi necessário realizar uma profunda análise das implementações públicas do middleware Ginga para dispositivos fixos, visto que era evidentemente sensato partir de alguma implementação base para que esta fosse adequada à realidade de um dispositivo móvel. As implementações públicas Ginga estudadas foram a versão em C++1 e uma versão em JAVA2. Ao contrário da versão em C++, a versão pública em JAVA havia sido des- continuada; apesar disso, a decisão foi partir da versão em JAVA devido essencialmente a reutilização de código dos componentes que já estavam desenvolvidos. Pode-se afirmar que esta escolha trouxe alguns entraves que tiveram que ser soluciona- dos durante a etapa de implementação. A versão JAVA do código não era modularizada, sendo assim, as classes não estavam dispostas de acordo com a arquitetura mostrada no diagrama 4.1. Existiam algumas falhas de programação que impediam a execução de aplicações NCL simples, principalmente no Gerenciador Gráfico e Escalonador. A ver- são JAVA, foi desenvolvida utilizando bibliotecas gráficas que não estão dispońıveis na plataforma AndroidTM, como por exemplo a java.awt. Devido a todos estes fatores, os módulos Exibidores, Adaptadores, Gerenciador Gráfico, Conversor, Formatador, Escalonador, Gerenciador de Bases Privadas, Gerenciador de Exibidores e Transporte, tiveram que ser alterados ou totalmente reescritos. Na próxima seção serão apresentados os módulos implementados, destacados na Fi- gura 4.1, bem como os primeiros testes realizados na plataforma. 4.2.1 Codificação Formatador A classe Formatter atua como um gerenciador em alto ńıvel, sendo responsável pelo controle das aplicações NCL presentes no middleware. A instanciação inicial da classe ocorre na Intent principal do Middleware, a classe GingaMobile. A classe mantém uma referência ao Formatador e ao receber uma aplicação NCL realiza as chamadas para adicionar a aplicação ao gerenciador e para iniciar a exibi- 1http://svn.softwarepublico.gov.br/trac/ginga/wiki/Building-Wiki-GingaNCL 2http://svn.softwarepublico.gov.br/svn/ginga/ncl30-java/trunk 4.2 Implementação 46 ção. Os botões de controle para pausar e parar a aplicação possuem eventos que realizam as chamadas ao gerenciador para a ação escolhida. O processo de adição de uma aplicação ao gerenciador, é feito através da classe Ncl- DocumentManager. Para iniciar a exibição de uma aplicação NCL, o Formatador realiza uma navegação pela Base Privada da aplicação para criar uma lista de eventos de entrada, ou seja, os eventos iniciais da aplicação. Esta lista é enviada ao Escalonador, que a partir destes eventos iniciais poderá iniciar a execução da aplicação. A estrutura de classes do Formatador foi mantida em relação à implementação utili- zada como referência. Foram necessários alguns ajustes no momento do recebimento do identificador de documento (Document ID) e de interface (Interface ID) e na sua posterior compilação, assim como na criação do evento de entrada. Conversor O módulo conversor é responsável pelo recebimento de uma estrutura NCL qualquer e posterior manipulação desta. A DocumentParser, apresentada na Figura 4.2, faz parte de um parser genérico para qualquer linguagem baseada no padrão XML. Essa classe é responsável pelo geren- ciamento do parser, e pode ser representada como ponto de entrada de compiladores de documentos baseados em linguagem XML. Todas as sub-classes executam o construtor dessa classe para garantir que as variáveis e referências sejam propriamente tratadas. A classe ModuleParser basicamente é responsável por armazenar objetos definidos na classe anterior. As demais classes deste módulo são responsáveis por executar funções espećıficas no processamento da estrutura hierárquica de um documento NCL. 4.2 Implementação 47 Figura 4.2: Conversor Embora a biblioteca de parser Document Object Model (DOM) possua um menor desempenho em relação à Simple API for XML (SAX) [60, 61], foram utilizadas as classes DOM para implementação do módulo Conversor no middleware devido a maior experi- ência dos desenvolvedores com esta biblioteca, mas também pelo fato de que a versão da implementação pública escolhida já estava baseada em DOM. Gerenciador de Bases Privadas O módulo Bases Privadas tem como principal função armazenar a estrutura processada pelo Formatador NCL, responsável por tratar as aplicações recebidas pelo núcleo. É este gerenciador o responsável por receber uma aplicação NCL e armazenar a estrutura denominada Base Privada. A Figura 4.3 apresenta o diagrama de classes que define o módulo Bases Privadas. A principal classe deste módulo Entity estende a interface IEntity. Todas as classes deste módulo (nós, links, descritores, etc) devem implementar essa interface, considerando que 4.2 Implementação 48 cada entidade NCL/NCM tem como atributo um único Identificador (ID). A área funcional Layout especifica elementos e atributos que definem como os objetos serão inicialmente apresentados dentro de regiões de dispositivos de sáıda. Components define os tipos básicos de objetos de mı́dia, e também é responsável pela definição de nós de contexto através de elementos . A área funcional Interfaces permite a definição de interfaces de nós (objetos de mı́dia ou nós de composição) que serão utilizados em relacionamentos com outras interfaces de nós, por sua vez, Linking é responsável por definir os elos, que utilizam conectores. Além dos módulos básicos, a área funcional Connectors também define módulos que agrupam conjuntos de módulos básicos, para facilitar a definição do perfil de linguagem.O NCL permite uma grande reutilização de seus elementos, para tal, a área funcional Reuse também foi implementada. Animation é, na verdade, uma combinação de fatores de suporte ao desenho do objeto e de suporte ao movimento do objeto ou, mais propriamente, suporte para a alteração do objeto em função do tempo. Por fim, Metainformation contém informações sobre o conteúdo utilizado ou exibido. Para implementação dessas classes foram seguidos os padrões definidos em [20]. 4.2 Implementação 49 Figura 4.3: Bases Privadas 4.2 Implementação 50 Gerenciador Gráfico Para realizar o papel do Gerenciador Gráfico do middleware Ginga, a classe Inter- faceUpdater foi implementada. Sua função básica é gerenciar a exibição e remoção de superf́ıcies (AndroidSurface) na tela e, portanto, necessita-se alterar o leiaute principal do middleware. Entretanto, por uma questão de segurança, a plataforma AndroidTMnão permite que todas as classes pertencentes a uma aplicação alterem o leiaute principal; apenas a Intent inicial pode fazê-lo. De modo a contornar esta limitação da plataforma, a classe foi implementada utili- zando um Handler, apresentado na seção 3.2.1. Duas classes internas que implementam a interface Runnable, updateUI e changeImage, também devem ser destacadas. A classe changeImage é utilizada para a troca de uma imagem exibida na tela e, como a exibição é feita através da classe ImageView, o método changeView da classe InterfaceUpda- ter é utilizado. Neste método, um vetor contendo a View a ser removida e a View a ser exibida é adicionado a uma lista de vetores a ser lida pela thread changeImage quando esta é executada. Analogamente, a classe updateUI é utilizada para alterar o leiaute principal, adici- onando e removendo elementos do tipo AndroidWindow adicionados à listas internas através dos métodos addRemoveTask, addDisplayTask, addLayout e addClearTask. É importante destacar que a solução apresentada para contornar uma limitação da plataforma, acrescentou um novo componente não existente até então, ou seja, na ver- são JAVA, cada thread disparada possuia autonomia para manipular o leiaute principal, mas no formato proposto todas as threads necessariamente devem passar por uma nova entidade para que esta realize a ação. Esta diferenciação pode ser observada no esquema proposto na Figura 4.4. Sem dúvidas, a criação deste novo componente acrescentou um novo custo (princi- palmente de tempo) no gerenciamento dos recursos do middleware e na seção 5.1 será apresentado um estudo, no qual, um dos fatores de atraso no tempo de preparação das mı́dias é o tempo gasto pelo handler do Gerenciador Gráfico. Gerenciador de Exibidores O módulo Gerenciador de Exibidores compreende as classes necessárias para gerenci- amento da execução dos exibidores de mı́dias e de interação com usuário. No diagrama de classes indicado pela Figura 4.5, é apresentada a estrutura implementada no middleware 4.2 Implementação 51 (a) Abordagem inicial (b) Abordagem do middleware para Android Figura 4.4: Diferença de abordagem para Gerenciador Gráfico a fim de realizar esse trabalho. Neste diagrama pode-se destacar a interface AndroidSurface que é responsável por definir uma superf́ıcie de exibição de mı́dia. É importante ressaltar que cada mı́dia exe- cutada numa aplicação NCL tem uma superf́ıcie de exibição a ela associada. Vê-se, pelo diagrama, que cada tipo de mı́dia, requer superf́ıcies com caracteŕısticas diferentes; para tal, a API AndroidTMprovê classes distintas, são elas: ImageView, SurfaceView e WebView. Estas classes são utilizadas como base para as superf́ıcies de apresentação do middleware. Com a finalidade de realizar a interface entre o middleware e as bibliotecas nativas da API, foram implementadas a AndroidAudioSurface, AndroidHTMLSur- face, AndroidVideoSurface e a AndroidImageSurface. Uma outra classe importante é a AndroidWindow, a sua função é prover uma abstração da janela de trabalho do middleware, para tal, foi utilizada como base, a classe de leiaute de exibição da API LinearLayout e a interface NCL IWindow. Em suma, todos os elementos exibidos pelo middleware estão contidos numa AndroidWindow. Por fim, tem-se a classe GingaKeyListener, responsável pela recepção dos dados de interação do usuário via teclado. Esta recebe os eventos e repassa-os para as classes 4.2 Implementação 52 necessárias para realizar a ação pretendida. Esta classe implementa a interface OnKey- Listener, provida pela API AndroidTM, que é responsável por ser chamada sempre que um evento é enviado para uma respectiva View. Figura 4.5: Gerenciador de Exibidores Exibidores No módulo exibidores há os apresentadores de mı́dia definidos para cada tipo supor- tado pelo middleware. Eles são utilizados pelos adaptadores para inserir as mı́dias numa apresentação e definem as funções básicas de apresentação necessárias, como: start, pause, abort, resume e stop. O comportamento destas funções é definido por norma, sendo que se buscou, na implementação deste middleware, seguir exatamente as instruções contidas no caṕıtulo 8.2 em [20]. O módulo foi implementado de forma que há uma classe correspondente ao exibidor para cada adaptador, por exemplo, AndroidAudioPlayer e AndroidAudioPlayerA- dapter, estão relacionados. 4.2 Implementação 53 Figura 4.6: Exibidores É importante destacar que na plataforma utilizada como referência, existiam algumas falhas no momento da exibição das mı́dias, que eram oriundas de defeitos nos exibidores. Grande parte destas falhas foram corrigidas dada a robustez das bibliotecas de mı́dia da plataforma AndroidTM. Adaptadores Os adaptadores atuam como intermediários entre o formatador e os exibidores respec- tivos a cada tipo de mı́dia, de forma que existe uma relação um para um entre eles. Cabe ressaltar, que tanto os adaptadores de mı́dia quanto os de código procedural implementam as interfaces de adaptador e listener de eventos, como pode ser visto na Figura 4.7. Desta forma, o adaptador recebe uma chamada de execução de uma mı́dia e carrega o exibidor necessário e, ao captar um evento, repassa-o a este exibidor, para que este realize uma ação baseada neste evento. Para implementação do módulo Adaptadores foi necessário estender as interfaces NCL IFormaterPlayerAdapter e IProceduralPlayerAdapter além da interface Inpu- tEventListener. Para cada tipo de mı́dia a ser executada existe um adaptador dis- tinto, são eles: AndroidImagePlayerAdapter; AndroidVideoPlayerAdapter; An- droidHTMLPlayerAdapter; AndroidAudioPlayerAdapter e AndroidLuaPlaye- rAdapter. 4.2 Implementação 54 A implementação dos quatro primeiros foi elaborada de forma que cada um deles es- tenda a classe AndroidMediaPlayerAdapter. Esta classe é responsável por agrupar caracteŕısticas comuns àquelas que a estendem. Por fim a classe FormatterPlayerA- dapter é responsável por executar comandos a fim de gerenciamento das mı́dias de Áudio, Vı́deo, Imagem e HTML. Figura 4.7: Adaptadores As mı́dias procedurais possuem um tratamento especial, de modo que a classe mais espećıfica responsável pelo tratamento destas mı́dias é a AndroidLuaPlayerAdapter. Esta classe estende ProceduralPlayerAdapter responsável por definir estruturas de da- dos espećıficas para tratamento de mı́dias procedurais, que por sua vez, estende Default- FormatterPlayerAdapter responsável por definir funções especificas para tratamento deste tipo mı́dia. Escalonador O escalonador de documentos NCL é um importante módulo da arquitetura do mid- dleware implementado, sendo ele o responsável por orquestrar a exibição de todos os elementos presentes em um documento NCL. A implementação do Escalonador tem como base o recebimento via parâmetro de um evento NCL, que pode ser instantâneo ou ter duração mensurável, e uma ação a ser 4.2 Implementação 55 realizada sobre este evento. Um evento NCL pode ser do tipo ”Seleção”, em que uma área ou nó do documento é selecionada; ”Atribuição”, que é definido pela atribuição de um valor a uma propriedade de um nó (representado por um elemento , , ou ); ”Composição”, que é definido pela apresentação da estrutura de um nó de composição (representado por um elemento , ou ) ou ”Apresentação”, em que a mı́dia contida em um nó NCL é exibida. Ações sobre os três primeiros tipos são mais simples e de execução rápida, porém ações em eventos do tipo Apresentação necessitam de um tratamento diferente, pois são, sobre uma mı́dia pertencente ao documento. Esse tipo de evento tem a si associado um Exibidor que executará em uma thread separada a mı́dia em questão e sobre o qual serão executadas as ações. É importante destacar, no Escalonador, a ação de start para um evento do tipo Apre- sentação. Ao ser feita esta chamada, o player da mı́dia em questão deve ser instanciado e preparado para exibição. Esta preparação consiste em criar uma superf́ıcie de exibição para a mı́dia e enviá-la ao Gerenciador de Leiaute para que esta possa ser adicionada ao conjunto de superf́ıcies em exibição. Após realizar estas preparações, o escalonador é adicionado como listener do evento e é chamado o método start do exibidor. Este processo pode ser visualizado na Figura 4.8. Figura 4.8: Escalonador 4.2 Implementação 56 Para manter a sincronia dos eventos, o Escalonador provê uma função deCallback e registra-se como listener dos eventos não-instantâneos. Através deste Callback o Escalo- nador recebe atualizações sobre o estado de cada evento iniciado e consegue manter uma estrutura interna para gerência de eventos condicionais. Desta maneira, o escalonador gerencia a instanciação de novas threads e a construção das superf́ıcies de exibição associadas. As ações de controle sobre as mı́dias são recebi- das pelo Escalonador e repassadas aos Exibidores espećıficos, e os eventos gerados pelos players, como o término de uma exibição, são passadas ao Escalonador através de um Callback, permitindo a correta exibição de eventos consecutivos. Transporte O módulo de transporte foi definido de forma a gerenciar protocolos e interfaces de rede. Nesta primeira implementação somente foi tratado o protocolo HTTP, para tal foi utilizada a biblioteca fornecida pela API AndroidTMHttpURLConnection. 4.2.2 Testes Preliminares A fim de realizar os testes preliminares na plataforma, foi desenvolvida uma série de documentos NCL, com base em [62] para construção de programas audivisuais interativos. Tais aplicativos validam componentes básicos do middleware. Somente após estas vali- dações o middleware foi embarcado para que as avaliações de desempenho mais robustas fossem realizadas. Apresentar imagens na tela sem sincronismo e com sincronismo Este teste tem por objetivo validar a exibição de mı́dias de imagens. O primeiro 4.10(a) exibe imagens na tela do dispositivo com base na definição realizada no arquivo NCL. O segundo teste exibe as imagens 4.10(b) e 4.10(c), utilizando critérios de sincronismo entre as exibições. O sincronismo entre as mı́dias foi definido através da utilização de link, port e media, conforme apresentado na Figura 4.9. No arquivo onde não há sincronismo foram definidos 4 ports, sendo que cada mı́dia é apresentada através de uma destas 4 ports. 4.2 Implementação 57 Figura 4.9: Bloco de código responsável pela sincronização de mı́dias Este validador explora principalmente a utilização dos componentes Gerenciador de Exibidores e Exibidores, no que tange a exibição de mı́dias de imagem. Também ex- plora recursos do Conversor, Escalonador, Gerenciador de Bases Privadas, Formatador e Adaptadores. (a) Imagens sem sin- cronismo (b) Imagens com sincronismo (c) Imagens com sincronismo Figura 4.10: Imagens na tela sem sincronismo e com sincronismo Através destes testes foi posśıvel detectar a restrição da plataforma em que apenas uma thread pode modificar o layout da aplicação. Para tal foi necessário desenvolver o controlador apresentado em 4.2.1. Os demais resultados destes testes foram satisfatórios dado que o dispositivo respondeu bem a esta bateria de testes. Apresentar imagens na tela com sincronismo e reutilização de área Este teste tem por objetivo validar a exibição de mı́dias de imagens com sincronismo, entretanto, reutilizando a mesma área de exibição. A reutilização de áreas, conforme imagens 4.12(a), 4.12(b) e 4.12(c), é uma limitação em muitos dispositivos portáteis, sendo assim, este teste visa verificar esta limitação. A reutilização de área foi definida através da utilização de link, port e media, condorme Figura 4.11. 4.2 Implementação 58 Figura 4.11: Bloco de código responsável pela reutilização de área Assim como o primeiro, este validador explora principalmente a utilização dos com- ponentes Gerenciador de Exibidores e Exibidores, no que tange a exibição de mı́dias de imagem. Também explora recursos do Conversor, Escalonador, Gerenciador de Bases Privadas, Formatador e Adaptadores. (a) Imagens com sincronismo (b) Imagens com sincronismo (c) Imagens com sincronismo Figura 4.12: Imagens na tela com sincronismo e reutilização Após a realização dos testes foi posśıvel perceber que o middleware se comportou bem, e neste momento também foi posśıvel identificar algumas falhas de programação que foram corrigidas, bem como pontos de gargalo que foram otimizados para redução do tempo de resposta à exibição das mı́dias. Apresentar áudios no dispositivo sem sincronismo e com sincronismo Assim como o primeiro teste, este tem por objetivo validar a apresentação de mı́dias de áudio com e sem sincronismo. Para esta validação foram desenvolvidas situações bá- sicas, como a simples apresentação do áudio, bem como situações mais avançadas com a 4.2 Implementação 59 utilização de recursos como conectores e links de componentes para definição da sincroni- zação entre os áudios. A estrutura utilizada foi semelhante àquela apresentada na Figura 4.9. É importante destacar que neste teste foi percebido que em determinadas situações uma mı́dia de áudio não era apresentada, embora estivesse definida no arquivo NCL. Com os avanços dos testes foi percebido que se tratava do tempo de preparo de mı́dias simultâneas, que será apresentado no próximo caṕıtulo. Apresentar v́ıdeos no dispositivo sem sincronismo e com sincronismo A avaliação de mı́dias de v́ıdeo, incluiu situações de i) simples exibição de v́ıdeo, ii) apresentação de v́ıdeos e interrupção em um determinado instante, iii) apresentação de v́ıdeos com interrupção em um determinado instante e exibição de outro em seguida mantendo o primeiro pausado, iv) apresentação de v́ıdeos com interrupção em um deter- minado instante e exibição de outro em seguida com destruição do primeiro, e por fim, v) apresentação de v́ıdeos com interrupção em um determinado instante e a exibição de outro em seguida mantendo o primeiro pausado combinando também a exibição de imagens e apresentação de áudios aleatórios. Para todos os testes, foram utilizados recursos apresentados em [62], no caṕıtulo ”Sin- cronizando nós de mı́dia através de elos e conectores”e no caṕıtulo ”Sincronizando diversos nós de mı́dia estática a um nó de mı́dia cont́ınua”. Em todos eles o middleware se com- portou bem. Validar eventos de interação com o telespectador A fim de se validar eventos de interação com o telespectador foram desenvolvidos arquivos de testes para i) validar eventos simples, como dar play ao se pressionar uma tecla ou se pressionar a tela do dispositivo, ii) exibir um v́ıdeo em loop permitindo o usuário prosseguir para um segundo v́ıdeo, pressionando a tecla 1, iii) alternar a exibição de v́ıdeos com base no toque das teclas 1 e 2 e por fim, iv) exibir um v́ıdeo em loop, apresentando duas opções de idioma, ao selecionar uma das opções é exibido um v́ıdeo de abertura, e em seguida um v́ıdeo sem som e um áudio de acordo com o idioma selecionado. Para todos os testes, foram utilizados recursos apresentados em [62], no caṕıtulo ”In- teração com Usuário”. Em todos eles o middleware se comportou bem, sendo necessário apenas alguns ajustes pontuais na codificação dos exibidores. 4.3 Considerações Finais 60 4.3 Considerações Finais Este caṕıtulo apresentou as principais etapas e dificuldades encontradas para a cons- trução do middleware. Foram apresentados os módulos desenvolvidos, bem como detalhes de sua implementação. É importante destacar porém, que um fator causador das maiores dificuldades foi partir de uma implementação pública do middleware já existente, mas que tinha sido concebida para ser executada em um dispositivo fixo. Em contrapartida, teria havido um esforço ainda maior de desenvolvimento, se a codificação do Ginga-NCL tivesse sido todo refeita sem usar uma implementação pública como ponto de partida. Por outro lado, outra dificuldade encontrada no desenvolvimento foi a necessidade de um mapeamento conceitual, por exemplo, da parte gráfica, que originalmente foi de- senvolvida usando bibliotecas .awt do Java, e que na sua origem não são suportadas na