Android vs MeeGo by Joao Silva

Instituto Superior de CiĂŞncias do Trabalho e da Empresa

Dinis Monteiro // JoĂŁo Silva

Mestrado Open Source Software - ISCTE 2010/11

Janeiro de 2011

Indíce 1. Contextualização 1.1 Android 1.2 MeeGo 2. Arquitectura de Hardware 3. Kernel Linux nos mobile OS 4. Arquitectura de Software 4.1 Android 4.1.1 Linux Kernel 4.1.2 Middleware - Bibliotecas 4.1.3 Middleware - Android Runtime 4.1.4 Framework de Aplicações (API) 4.1.5 Aplicações 4.2 Meego 4.2.1 Linux Kernel, drivers, OHM 4.2.2 Midlleware 4.2.3 MeeGo API 4.2.4 User Interface/ User Experience 4.2.4 MeeGo Security Architecture 5. Comparações 5.1 Kernel 5.2 Middleware 5.3 Distribuição 5.4 Aplication Framework - API 5.5 UI/UX 5.6 IDE 5.7 Platform usage 5.8 Openess / Governance / Maintenance 5.9 Tabela resumo de comparações 6. Considerações finais 7. Anexos

8. Bibliografia

1. Contextualização Estima-se que o número de telefones móveis vendidos em todo o mundo totalize cerca de 417 milhões de unidades no terceiro quarto de 2010, correspondendo a um aumento de 35% quando comparado com o período análogo do ano transacto. De acordo com a Gartner, Inc. (ver gráfico 1) as vendas de smartphones cresceram 96% no mesmo período, representando 19.3% do total de vendas de dispositivos móveis. As previsões apontam para que em 2013 cerca de 70% dos telefones móveis sejam smartphones e que o negócio das lojas de aplicações representem um negócio de 215 biliões de Euros. Ainda de acordo com o mesmo gráfico 1 o Android roubou cota de mercado a todos os sistemas operativos exceptuando o IOS. Diversas empresas, ou em alguns casos alianças, têm vindo a posicionar-se face à grande expectativa que está criada em torno deste fenómeno, apostando

fortemente no

desenvolvimento e promoção de plataformas, que são na realidade eco-sistemas baseados num sistema operativo e complementado por um vasto conjunto de serviços.As estratégias que serão adoptadas terão um factor determinante para o sucesso das vendas. Qualquer plataforma que falhe a inovar ou na consolidação dos seus serviços e sistemas vai perder developers, fabricantes, parceiros e o mais importante, utilizadores. Neste momento existem cinco grandes players no mercado: Symbian, Android, IOS, RIM e Windows Mobile. Há ainda outras que por serem extremamente recentes não conseguiram expressão de mercado, como são os casos do Meego ou bada.

Esquema 1: Smartphone OS shares 3Q de 2009 vs 3Q de 2010. Fonte: Garter

Neste trabalho vamos aprofundar a arquitectura de dois dos sistemas operativos anteriormente mencionados, o Google Android e o Meego. Ambos são baseados em Kernel Linux, concorrem pelos mesmos developers e ambos pretendem atingir os mesmos mercados.

1.1 Android Foi em 2005 que a Google se interessou por uma empresa chamada Android, Inc, uma startup Californiana que tinha como principal core o desenvolvimento de aplicações/software para dispositivos moveis. Rapidamente o interesse se materializou em aquisição. A Google pretendia desenvolver um aparelho que oferecesse serviços baseados em localização, sendo que para tal precisava de um sistema, procurando por isso importar know - how e tecnologia para o mesmo. Dois anos e meio depois, a 5 de Novembro de 2007, a Google anuncia o seu novo sistema operativo para dispositivos móveis baseado em Linux. Foi também referenciado que seria open source. No mesmo ano e mês foi formada a Open Handset Alliance, que incluía empresas tão diversas como a Google, HTC, Motorola, Intel, Qualcomm, Sprint Nextel, T-Mobile, e NVIDIA. Era pretendido com a aliança o desenvolvimento de padrões abertos para dispositivos móveis. Em 2008 o Android passa a ser disponibilizado à comunidade como full open source. O primeiro dispositivo data de Setembro de 2008 e chamava-se de G1 tendo sido lançado pela TMobile. O Android é baseado na licença Apache, que é uma licença BSD (sem necessidade de após modificação ter de a redistribuir).

Histórico de versões:

● ● ● ● ● ● ● ●

Android 1.1 (Fevereiro de 2009) - Kernel 2.6.25 Android 1.5 "Cupcake"(Maio de 2009) - Kernel 2.6.27 Android 1.6 "Donut (Setembro de 2009) - Kernel 2.6.29 Android 2.0/2.1 "Eclair" (OUT-2009) Kernel 2.6.29 Android SDK 2.0.1(Janeiro de 2010) Android 2.2 "Froyo"(20 de Maio de 2010) Kernel 2.6.32 Android 2.3

“Gingerbread” 2.6.33 ou 34

Android 3.0 (Honeycomb)

1.2 MeeGo O projecto MeeGo resulta da junção do Moblin (lançado em 2007), sistema operacional da Intel e do Maemo (iniciado em 2005), SO da Nokia. O Maemo e o Moblin partiram de distribuições Linux para desktop: o primeiro baseado no Debian, e o segundo no Fedora, ainda assim, ambos incorporaram tecnologias de outras distribuições. Tanto o Maemo como o Moblin tinham bastantes semelhanças tecnológicas, desde subsistemas como o D-Bus, Pango, Cairo, GStreamer, Evolution Data Server, PulseAudio, até à plataforma de renderização Gecko da Mozilla. Quanto a diferenças o Moblin usava a nível de ferramentas de desenvolvimento o GTK+ e o Clutter, sendo que o Maemo na versão mais recente estava em processo de transição para o Qt1, a qual é mantida actualmente no MeeGo2. O mesmo, é totalmente open source, e tem como principais premissas suportar múltiplas arquitecturas de hardware, para deste modo ter uma ampla gama de distribuição desde smartphones, notbooks, tablets, televisores até a sistemas de informação e entretenimento de bordo (IVI). O MeeGo tem ainda como particularidade estar hospedado e ser mantido pela Linux Foundation3, sendo o único de entre os vários So’s mobile baseados em Linux, caso do Android ou bada. É ainda o SO que mais de perto segue o modelo do desktop Linux sendo que por isso esteja desde já a facilitar o aparecimento de comunidades activas e produtos potencialmente robustos, como é o caso da adopção pela Genivi Alliance do MeeGo como plataforma para a próxima geração de IVIs (In-Vehicle Infotainment). Relembre-se que nesse grupo fazem parte empresas como a BMW, GM ou Hyundai. Até no campo da domática o MeeGo começa a marcar presença. Há portanto todo um vasto leque de novas oportunidades pelas quais essa nova plataforma procura concorrer, tendo para já imposto algumas derrotas à Google e ao seu Android. O smartphone N900 da Nokia foi o primeiro a suportar Maemo, sendo que actualmente já suporta MeeGo com uma actualização oficial, sendo que até poderá correr em dual boot. O

1Framework multiplataforma que tem como principal função permitir o desenvolvimento de aplicações que possam

correr em diversos dispositivos sem ter de rescrever o código fonte. A Nokia pretende assim facilitar a programação de aplicações destinadas fundamentalmente a MeeGo e Symbian. 2O Meego, assemelha-se bastante ao Moblin, mas com o Qt como kit de ferramentas de desenvolvimento.

Analisaremos adiante este aspecto. 3A AMD, um dos membros da Linux Foundation, anunciou recentemente que pretende apoiar o MeeGo, sendo que

tem como objectivo integrar a sua tecnologia de APUs (Accelerated Processing Units)

próximo a sair com este sistema operativo é o N9, o qual incorporará MeeGo sucedendo ao N8, aposta da Nokia para revitalizar o Symbian. Constata-se também que o MeeGo está mais maduro no que diz respeito as versões para notbooks.

Histórico de versões: ● ● ● ● ● ● ●

MeeGo 1.00 (26 de Maio de 2010) - Kernel 2.6.33 MeeGo 1.01 (12 de Julho de 2010) - Kernel 2.6.33.5 MeeGo 1.02 (9 de Agosto de 2010) - Kernel 2.6.33.5 MeeGo 1.03 (10 de Stembro de 2010) - Kernel 2.6.33.5 MeeGo 1.04 (12 de outubro de 2010) - Kernel 2.6.33.5 MeeGo 1.1

(28 de Outubro de 2010) - Kernel

MeeGo 1.2

(2011)

2.6.35

2. Arquitectura de Hardware A arquitectura de ambas as plataformas depende da escolha do fabricante, assim, apresentamos um esquema que poderá exemplificar a arquitectura de hardware possível de ser utilizado nas duas. Decidimos por isso fazer uma breve análise desta arquitectura, visto ser a única que já foi efectivamente utilizada por dispositivos moveis Android e Maemo (N900). O N9 (primeiro dispositivo MeeGo) deverá correr em OMAP4.

Esquema 2 : Architecture 3430 Fonte: MeeGo Architecture por Hiroshi Doyo, Nokia

Este modelo, Texas Instruments OMAP 34304, está presente tanto em plataformas Maemo/MeeGo, caso do N900 como no Motorola Droid dispositivo Android ou no Samsung I8910, dispositivo Symbian s60 v5. Procuramos com isto frisar que a mesma arquitectura

4Omap 3 é dividido em 3 grupos distintos, o OMAP 34x, o OMAP 35x e o OMAP 36x.

de hardware pode usar diferentes sistemas operacionais, se bem que há sempre limitações técnicas, nomeadamente a nível do processador e suas caracteristicas e da exigência do SO5. São algumas particularidades desta plataforma o suporte de XGA (800×600), ou até WXGA (1280x800) 16M de cor (24 bits), o USB 2.0, saída por componentes ou S-video out, suporte OpenGL ES 1.1, integração de ISP, para mais rápida e alta qualidade de imagem com poucos gastos ao nível da bateria entre outras caracteristicas como o suporte até 12 megapixeis com ISP onboard. A nível de CPU o que é utilizado é o ARM Cortex A8 com clock de 600 mhz (possível de ser estendido mediante OC nesta mesma plataforma até valores na casa dos 950mhz). Actualmente a plataforma Spapdragon SoC está a assumir uma posição de destaque no que diz respeito à adopção de arquitecturas, com CPU’s com valores de 1 GHz. Mas atenção esta relação de de MHz não é proporcional ao nível de desempenho em aplicações, estamos a falar do factor scaling. Não há portanto o dobro de performance, entre um CPU 550 MHz, como é o caso do Motorola Droid e um Snapdragon de 1 GHz (Nexus One). A diferença de performance situa-se em valores a rondar os 40%.

3. Kernel Linux nos mobile OS De uma forma generalizada todos os sistemas operativos tem um Kernel. Este núcleo funciona como um elo de ligação entre o hardware e o middleware. O uso do kernel Linux em sistemas operativos mobile já data de há longos anos. A primeira empresa a apresentar um SO com base em Kernel Linux foi a Nokia com o Maemo, ano de 2005 (Internet tablet Nokia 770). Foram necessários mais quatro anos até ser lançado o primeiro smarphone Maemo, no caso a versão 5 (N900). Em 2010, a junção do Maemo, que nunca se impôs, com a plataforma Moblin (a qual a Intel pretendia usar para equipar netbooks com processadores Atom) e que em parte tinha o mesmo problema do Maemo, falta de adopção por parte da comunidade mainstream de utilizadores. O MeeGo é até considerado pela Linux Foundation a versão oficial de Linux para dispositivos moveis. Em 2006 houve outra empresa que pretendeu impor o sistema open source baseado em Kernel Linux, no caso a FIC e o seu OpenMoko. Pretendia ser livre a nível de software

5A titulo de exemplo o I8910 que usa por defeito a arquitectura OMAP 3430, numa versão prototipo equipado com

o processador Qualcomm Snapdragon corre Windows Phone 7, algo que é impossível na arquitectura referida anteriormente. - Fonte: http://www.mobiletechworld.com/2010/05/26/windows-phone-7-hands-on-with-the-samsungprototype/

assim como de hardware, contudo, o seu projecto não captou muito interesse por parte dos fabricantes e em 2009 o projecto foi cancelado. Em 2007 um grupo de empresas, incluindo a Motorola, Vodafone entre outras criam a LiMo, plataforma também ela open source. Não teve grande projecção no mercado, sendo que actualmente é mais conhecida no Oriente. Em 2009 mais um caso de altos e baixos, o WebOs da Palm. Não correu como planeado, de tal forma que a Palm foi adquirida este ano pela HP. Este SO tinha como missão reabilitar a Palm e ser o SO de Kernel Linux de referência. O Palm Pre 1 é o caso tipico de um smartphone de excelentes reviews por parte de toda a imprensa especializada e que no entanto não teve sucesso que se poderia julgar que poderia ter. O Palm Pre 2 foi lançado recentemente (fim de 2010) sobre comando da HP mas segundo a imprensa especializada continua a ter os mesmos defeitos e virtudes da versão anterior. Também em 2009 a Samsung anuncia o bada, sistema que pode correr em Kernel Linux ou em real time OS kernel, dependendo do propósito. Esta plataforma é ainda uma incógnita, sendo que há poucos modelos no mercado. É Closed Source. Em 2010 a Motorola, decide adquirir a Azingo, mais uma versão baseada em Kernel Linux. A Motorola pretende como a maioria dos grandes fabricantes, à exepção da HTC e SonyEricsson ter a sua própria plataforma. Este SO é closed Source. Por último, em 2007, e como único caso de sucesso temos claro o Android, o qual anteriormente já analisamos.

4. Arquitectura de Software Qualquer sistema operativo tem por norma três grandes blocos, o Core ou base do SO, no caso o Kernel Linux, middleware e por último a parte visivel - UI (user interface) / UX (user experience). A suportar toda esta camada de software está a arquitectura de hardware. A hardware abstration layer (HAL), no MeeGo tem o nome de OHM (derivação do HAL). É uma camada de abstracção implementada de forma a mediar a interacção do hardware com software. A sua função é esconder as diferenças de hardware do Kernel, possibilitando assim que independentemente das variações de hardware o sistema possa correr sobre o mesmo. Há obviamente limitações técnicas como no caso dos sistemas operativos 64 bits, x64, e arquitecturas de hardware a 32 bits (x86).

4.1 Android O esquema 3 mostra os principais componentes do sistema operativo Android. Cada uma dessas secções é detalhada nos pontos seguintes.

Esquema 3 : MeeGo Top Level Architecture Fonte: MeeGo Architecture por Hiroshi Doyo, Nokia

4.1.1 Linux Kernel A arquitectura do Android está baseada na versão 2.6 do Kernel Linux, que funciona como uma camada de ligação entre o hardware e as restantes. Este Kernel inclui drivers de hardware, faz a gestão de memória, gestão de processos, gestão de rede, e muito importante, é uma peça de software que atingiu um elevado nível de maturidade. Inicialmente, a Google contribuíu com algum código para o Kernel Linux numa tentativa de suprimir algumas necessidades encontradas. Um desentendimento relacionado com novas

funcionalidades que a Google achava que deveriam fazer parte do Kernel, originou a decisão de fazer uma fork para uma nova versão que pode ser entendida como “Kernel do Android”. A contribuição inicial da Google para o Kernel do Linux acabou por ser removida, uma vez que o código deixou de ser utilizado e mantido. No entanto, a Google já anunciou que tem intenção de alocar uma equipa de desenvolvimento para apoiar a comunidade que desenvolve o Kernel Linux.

4.1.2 Middleware - Bibliotecas O middleware inclui um conjunto de bibliotecas C/C++ que são utilizadas na implementação dos vários dos componentes do sistema. Estes são por sua vez utilizados através de um conjunto de funcionalidades que estão à disposição dos developers na ”Android application framework”. Seguem algumas das principais bibliotecas:

● Bibliotecas C - uma implementação baseada em BSD das bibliotecas de C standard (libc), pensada para dispositivos embebidos. ●

Media Libraries - Suporte de imagem, audio e vídeo para a maioria dos formatos, como por exemplo: MPEG4, H.264, OGG, MP3, AAC, AMR, JPG, and PNG.

●

Surface Manager - Faz a gestão de acessos ao display, por parte das várias aplicações

● LibWebCore - um motor de web browser responsável pelo browser do sistema operativo e embebido nas WebViews. ●

SGL - motor gráfico 2D.

● 3D libraries - baseada em OpenGL ES 1.0 APIs, utiliza aceleração por hardware quando disponível. ●

Freetype – renderização de fonts bitmap e vectoriais

●

SQLite - um motor de base de dados robusto e leve destinado a aplicações móveis.

O sistema inclui um conjunto de bibliotecas C/C++ usadas por diversos componentes do Android. Essas bibliotecas permitem trabalhar com arquivos de mídia comuns como MPEG4, H.264, MP3, AAC, AMR, JPG e PNG. Componentes como o Surface Manager permitem a exibição de conteúdo em 2D. Há inclusive, uma biblioteca 3D cuja implementação foi baseada no OpenGL (Open Graphics Library). Basicamente é um conjunto de várias funções que fornecem acesso a praticamente todos os recursos do hardware de vídeo. Para completar, foi disponibilizado também o SQLite, um poderoso e leve banco de dados relacional.

4.1.3 Middleware - Android Runtime O Android Runtime inclui uma série de bibliotecas fundamentais que equivalem às bibliotecas “core” do Java. Cada aplicação corre no seu processo, com a sua própria instância da máquina virtual (VM) Dalvik. A Dalvik foi desenvolvida de forma a suportar diversas VM’s em simultâneo de forma eficiente. Ele executa um formato de ficheiro específico (.dex) que foi optimizado para consumir pouca memória. A VM é “register-based” e corre classes compiladas pelo compilador da linguagem Java, as quais foram transformadas em ficheiros .dex através da ferramenta "dx". A VM do Dalvik comunica com o Kernel, tarefas como “threading” e gestão de memória (a baixo nível).

4.1.4 Framework de Aplicações (API) O Android fornece uma plataforma de desenvolvimento, escrita maioritariamente em Java, que possibilita aos “developers” a criação de aplicações. Tirando partido do hardware, utilizando as suas funcionalidades nativas, os “developers” podem aceder e gerir informação gravada localmente, consultar a geolocalização, correr serviços em background, fazer chamadas, requisitar serviços de rede, entre outros. Os “developers” tem acesso completo às API’s da framework utilizadas pelas aplicações de origem (core apps). A arquitectura dessas aplicações foi desenhada para simplificar a reutilização de componentes. As aplicações podem publicar as suas características, que poderão, mais tarde, vir a ser ser utilizadas por outros aplicações. Este mecanismo permite que esses componentes sejam subtituidos pelo utilizador.

4.1.5 Aplicações O Android vem com um conjunto de aplicações “default” que incluem um cliente de email, um programa de SMS, o calendário, a aplicação dos mapas, o browser, a listagem de contactos, uma aplicação de chamadas, a ligação ao Marketplace, que permite o download e a a respectiva instalação de novos aplicativos. Todo este software está escrito em Java e corre na VM Dalvik. Apesar de o Android ser quase na totalidade open source ha certos módulos que são fechados.

São exemplos o Android Market, Google Talk, E-mail client, Maps application, YouTube client, Calendar application ou a framework responsável pela sincronização.

4.2 Meego 4.2.1 Linux Kernel, drivers, OHM O Linux Kernel é toda a base do MeeGo. A este nível do core OS inclui-se o Kernel e as drivers de dispositivos como a câmera fotográfica e uma série de bibliotecas e subsistemas. A versão do Kernel é a 2.6.35 na versão 1.1 ou abaixo consoante a versão do SO. O facto de o MeeGo estar sobre controlo da Linux Foundation faz com que haja atenção em assegurar um Kernel mainstream (não ha forks no que diz respeito ao Kernel), ou seja, há preocupações que outras distros (com este mesmo Kernel) estejam aptas a correr num mesmo hardware com o mínimo de complicações possível. O MeeGo usa praticamente os mesmos componentes que uma versão standard desktop de Linux, sendo que promete não criar fragmentações, a qual já afecta outras plataformas. O Qt pode vir até mudar a forma de actualização da substituibilidade para o incremento (algo já disponível nas versões Linux Desktop). O MeeGo promove uma forte full stack based compatibility, focando-se então na interoperabilidade entre aparelhos MeeGo. Assim, todos os pacotes deverão ser baseados no MeeGo Source sendo que a UI/UX pode ser costumizada mediante algumas condições. Há até uma “directiva” chamada de MeeGo compatibility. Ainda relativamente ao core do sistema, a Hardware Adaptation API é a chamada camada de abstracção para o Meego suportar arquitecturas de hardware diferentes. Relativamente à Hardware Adaptation Software é onde se inclui todo o software especifico da plataforma, como é o caso especifico de drivers ou codecs. O MeeGo por padrão utiliza também o Btrfs(B-tree file system) para armazenamento de arquivos e RPM ao nível de pacotes. Ainda ao nível do núcleo do sistema operativo em questão, iremos fazer 4 distinções nos subsistemas, as quais aparecem sugeridas no esquema 4, são elas o settings database (GConf), as System Libraries (Glibc, Glib), message bus (D-Bus) e a plataform Info (libudev) .

GConf O GConf é um subsistema onde são guardadas as preferências das aplicações definidas pelo utilizador ou até as que são pré-definidas no momento de instalação do SO. Como particularidade, quando múltiplas aplicações tentam aceder aos mesmos dados

armazenados, o GConf tem como medidada de segurança bloquear os dados de modo a que os mesmos não sejam corrompidos. O GConf usa um tipo de estrutura baseado em directórios e em arquivos XML, onde cada preferencia é armazenada num key value.

Glibc/Glib O Glibc é uma bliblioteca standardizada em C que é usada por múltiplos programas no sistema. A fim de economizar espaço e memória, bem como para fazer a actualização mais fácil, o código comum é mantido e partilhado entre programas. O glib disponibiliza uma biblioteca que tem como função a cross plataform software.

D-Bus O D-Bus é um inter-process communication (IPC), portanto, um sistema de comunicação de mensagens, entre processos, num mesmo aparelho. É uma forma de as aplicações “falarem” entre si. O D-bus ajuda também a coordenar o ciclo de vida dos processos

Libudev É um simples sistema de serviços que consegue enumerar os dispositivos, controlá-los e enviar notificações quando algum hardware for removido ou adicionado ao aparelho.

Hardware Adaptation Software Há múltiplos componentes de software que os vendedores de hardware deverão providenciar ao MeeGo para correr na sua arquitectura, porque são específicos da mesma. Inclui-se nesta secção os drivers do Kernel para a plataforma, a sua configuração, core architecture patches (patches para activar algumas funcionalidades da arquitectura - exemplo, updates do firmware), bootloader6, suporte para o modem e outras especificações a nível de hardware. Estes componentes específicos são chamados de Hardware Adaptation Software e são divididos de uma forma geral pelos seguintes subsistemas:

●

Platform Kernel Drivers

trabalho do bootloader é executar as inicializações necessárias para preparar o hardware para o sistema operacional. Contem código especifico de processador e faz a mediação e ligação entre firmware e kernel. Uma vez corrompido o bootloader, só com recurso a ferramentas do género Jtag se consegue recuperar, de outra forma o smartphone está aquilo a que se chama “bricked”.

●

Kernel Core Architecture Patches

●

Kernel Configuration

●

X Software Core Architecture Patches

●

X Software Configuration

●

Modem Support

●

Hardware Specific Media Codecs

Assim, o Meego Core OS define interfaces dependendo da plataforma de hardware. É da responsabilidade de um chipset hardware adaptation software a implementação das mesmas.

4.2.2 Midlleware Ao nível do midleware, o MeeGo divide-se por diversas sub-áreas, vamos analisar cada uma delas detalhadamente.

Comms Services Os Comms Services fornecem serviços para gerir a “voz e dados” da plataforma.

●

Connection Management Este sistema é encarregue da gestão de ligações de dados, caso do WiFi, WiMAX, 3G entre outras.

●

Telephony APIs A este nível a plataforma open source oFono providencia APIS internas para as bandas GSM/UMTS. Para comunicações sobre IP O MeeGo utiliza a framework Telepathy, também ela Open Source. A Telepathy é uma framework baseada no D-Bus.

●

IP (VoIP, IM, Presence) O IP comms inclui plugins especificos da Telepathy para comunicações sobre IP, seja voz ou vídeo.

●

Bluetooth Wireless Technology – O BlueZ, Official Linux Bluetooth protocol stack, oferece suporte a essa tecnologia.

Internet Services Os serviços de Internet incluem sistemas com capacidade para renderizar conteúdo web, fazer troca de dados user-server, localização, etc

●

Layout Engine O layout engine disponibiliza a renderização de conteúdos web . A layout engine pode

ainda variar de acordo com o dispositivo, WebKit/Chromium em netbook, Gecko/Fennec, por exemplo, num smartphone.

●

Web Run Time O Web Run Time oferece um ambiente para a criação de aplicativos que recorram a

tecnologias web, como Javascript , HTML e CSS. O Web Run Time do MeeGo é baseado em WebKit e só começou a existir desde a versão 1.1 (daí o tracejado no esquema 4).

●

Location As aplicações podem aceder aos serviços de localização recorrendo às bibliotecas Qt.

No Meego, as Qt location Apis donominam-se de GeoClube, o qual, utiliza o sistema D-Bus.

Visual Services Os Visual Services fornecem o núcleo 2D e recursos gráficos 3D, incluindo aceleração gráfica por hardware, a qual varia de hardware para hardware.

●

3D Graphics O OpenGL/ES7 permitem a renderização de gráficos 3d.

●

2D Graphics A layer gráfica 2D oferece capacidades de desenho 2D com suporte para aceleração de

hardware.

●

Clutter/GTK O Clutter é uma toolkit leve, que foi feita para trabalhar em cima de OpenGL/ES. Poderá

7OpenGL ES (OpenGL for Embedded Systems) é uma subsecção da API da biblioteca de gráficos 3D OpenGL .

ser usado juntamente com o GTK (toolkit multi-plataforma para a criação de interfaces gráficas) ou bibliotecas Qt. ●

X A fundação x.org possibilita o emprego de uma interface gráfica recorrendo ao conceito

de janelas (X Window System).

Media Services Os Media Services possibilitam a reprodução de audio/vídeo, streaming e imagem.

●

Gstreamer O Gstreamer é uma framework multimedia que permite a reprodução de diversos tipos

de media.

●

Gupnp O framework GUPnP é baseado em código aberto e oferece uma API escrita em C (GObject) para a construção de dispositivos e pontos de controle UPnP.

Data Management O subsistema de gestão de dados presta serviços para a extração e gestão de arquivos de metadata, recuperação de dados sobre o dispositivo (como a sua posição, o estado do cabo USB), e gestão do conjunto de pacotes instalados no dispositivo.

●

Content framework O content framework possibilita a indexação, extracção de metadata e possibilidades de

pesquisa para diversos tipos de data.

●

Context Framework Este sistema oferece mecanismo de informação sobre o dispositivo, tais como o nível de

bateria, posição do smartphone, etc

●

Package Manager Foi decidida a mudança de deb (dpkg) para RPM (RedHat/Fedora...). Assim, foi esse o

package manager escolhido para ser utilizado no MeeGo. O sistema de pacotes funciona de forma praticamente igual a sistemas desktop ao nível de dependências. No desenvolvimento pode-se recorrer ao plug-in para o Qt creator, RPM Spec Creator ou ao openSUSE Build Service (OBS), um sistema automatizado para construção de software packages, colaboração entre developers, manutenção, etc.

Device Services O subsistema Device Services contem uma série de serviços para gerir o estado do dispositivo, incluindo tudo o que é necessário para tornar o dispositivo seguro para o utilizador, informações sobre o sensor data extraction, sincronização e ainda backup e restauro do sistema.

●

Device health O DSME (Device State Management Entity) possibilita o

controlo do estado do

dispositivo, vigilância dos processos (“meaning constant pinging over socket”), níveis de temperatura, etc

●

Energy Management Possibilita o controlo de gastos de energia, assim como nivéis de carga da mesma.

●

Sensor Framework O sensor framework relaciona-se com os sensores, como é o caso do acelarometro,

intensidade de liluminação, etc.

●

System Profiles Subsistema encarregue de gerir os perfis do dispositivo, tais como o os de chamada,

vibração, entre outros.

●

Backup and Restore Aqui atribui-se a responsabilidade às opções de backup do sistema e restauro do

mesmo.

Personal Services Gerir dados do utilizador no dispositivo, calendário, contactos, tarefas e gestão de

contas. ● PIM Services O PIM Services fornece uma interface para aceder e armazenar as informações do PIM, Personal Information Manage, (livro de endereços, calendário, tarefas e notas).

●

Accounts & Single Sign-on – O Accounts & Single Sign-on é responsavel por guardar informações sobre contas de

utilizador.

4.2.3 MeeGo API A MeeGo API é baseada no Qt 4.x. Esta framework de desenvolvimento em C++ é multi-plataforma, assim, pode-se compilar para diversas plataformas sem ter de alterar o código fonte. O Qt Mobility estende as bibliotecas Qt para assim fornecer recursos adicionais para casos de uso especiais não disponíveis na distribuição padrão de Qt. A nível de desenvolvimento, a Qt Creator é uma ferramenta nativa. Faz ainda parte da MeeGo API a Web runtime (WRT) para aplicações web (HTML, JS, CSS, etc.), e a MeeGo Touch Framework, que possibilita features para desenvolvimento de aplicações touch.

4.2.4 User Interface/ User Experience A user experience layer possibilita a Application Framework para cada perfil de dispositivo. A Netbook UX usa o Clutter e bibliotecas MX. O Handset UX recorre ao MeeGo Touch Framework. A interface do MeeGo é baseada nas bibliotecas Qt e QML. Esta última é uma tecnologia baseada em JavaScript para desenhar e definir as interfaces para o utilizador final. O QML é particularmente adequado para a criação de interfaces dinâmicas para aplicações móveis em Meego.

4.2.4 MeeGo Security Architecture O Meego usa uma estrutura de segurança escalável que possibilita protecção através do controlo de acesso, desde subsistemas totalmente abertos a subsistemas que precisam ser parcialmente bloqueados. Ainda com medidas de segurança:

○ ○

Identificação se o software é confiável. Encriptação SHA1 / verificação de todos os pacotes nos updates ou execuções.

Esquema 4 : MeeGo Top Level Architecture Fonte: MeeGo Architecture por Hiroshi Doyo, Nokia

5. Comparações

Esquema 5. A look at Android vs MeeGo Architecture comparison Fonte: http://www.svholla.net/

5.1 Kernel 23

Um olhar sobre a primeira camada da ambos os sistemas observamos um Kernel Linux e um conjunto de drivers de dispositivo, os quais indicam os drivers proprietários dos fornecedores da plataforma. O MeeGo adoptou a versão 2.6 (na sua total essência) do Kernel Linux, já o Android, como consequência de algumas divergências entre os responsáveis pela “MainTree” e a Google, resolveram fazer uma fork da versão 2.6. Adicionaram algumas drivers que interagem com aplicações dos dispositivos, optimizando também o consumo de energia/bateria e implementando o IPC “Binder” para suportar aparelhos com recursos de memória e processamento mais limitados. Tanto o sistema Android como MeeGo podem executar processos separados, mas muitas vezes precisam comunicar entre si e partilhar informações. No caso do Android é utilizado a já referida Binder driver e no MeeGo o D-Bus. O MeeGo também não usa máquina virtual, cada aplicação é um processo, já no Android é usada a Dalvik Virtual Machine. Cada aplicação é executada na sua própria instãncia de VM. Enquanto MeeGo é um sistema Linux embebido, o Android na realidade está totalmente dependente de uma máquina virtual Java. O Kernel no caso do Android é apenas uma “ferramenta” para para carregar esta VM. Pode-se até especular que num futuro não muito distante, o Android poderá funcionar com um “native Java hardware”. Ainda como diferenças, Android suporta a Bionic C library, em vez de glibc ou newlib. Embora não seja compatível com glibc, os binários ligados estaticamente serão executados de forma correcta. O Android tem ainda um suporte muito limitado para a biblioteca pthread.

5.2 Middleware Olhando para o middleware das duas software stacks há muita semelhança funcional entre os componentes de Android e MeeGo. Alguns são exactamente os mesmos, como o WebKit, o Bluetooth connectivity manager, suporte OpenGL, entre outros. O Android utiliza a sua máquina virtual Dalvik, com o código da aplicação compilado em Java. A Native Development Kit (NDK) também é oferecido para aplicações de alto desempenho (como jogos) que devem usar C++. O sistema operacional Meego é principalmente baseado na plataforma da Nokia Qt, com aplicações a serem escritas em C++.

5.3 Distribuição Com o aparecimento da distribuição de Linux “Debian” foi introduzido o conceito de “gestor de pacotes” (package”), um mecanismo que instala determinado software a partir do

seu código fonte (tar.gz) resolvendo inclusivamente as suas dependências. Mais tarde a Red Hat criou o seu próprio gestor de pacotes denominado RPM. Para fazer a distribuição de aplicações, o Meego utiliza o sistema de pacotes RPM, já o Android utiliza os pacotes de instalação APK (Android Package), uma variante do “.jar”. Verificamos assim que no primeiro caso há uma utilização idêntica á dos sistemas desktop nomeadamente ao nível de depêndencias, enquanto no Android cada APK é independente no conteudo em relação aos outros instalados no sistema.

5.4 Aplication Framework - API A API do MeeGo é baseado em Qt, um projecto com uma longa história na comunidade de software livre, que abriu o seu processo de desenvolvimento e modelo de contribuição nos últimos anos. A maioria dos componentes desenvolvidos em Qt estão disponíveis para uma grande variedade de plataformas, como Windows, Symbian, MeeGo entre outras. Já a estrutura da VM Dalvik é baseada num fork do Java, optimizada para dispositivos móveis. As componentes do Android são utilizadas apenas pelo próprio sistema operativo. Embora o Java seja uma linguagem em franca utilização, esse isolamento impede a portabilidade de aplicações Linux, exigindo competências específicas para desenvolvimento em Android.

5.5 UI/UX Ao nível de UI ambos os sistemas podem ser personalizados, incluir aplicações e interfaces de vários fabricantes como a HTC Sense. O MeeGo destaca-se ainda por ter uma netbook / handset UI e respectivas frameworks.

5.6 IDE O desenvolvimento do Android poderá ser feito numa ferramenta livre de custos, como por exempo Eclipse IDE. Já o Qt creator requer uma licença (3.695$) de “developer” comercial para aplicações que não seja partilhado o código-fonte (Ver anexo 2). Quanto às aplicações Java do Android não é exactamente o mesmo que J2ME, no entanto, a grande maioria das aplicações J2ME existentes podem ser transpostas para Android com pequenas modificações.

5.7 Platform usage O Android expandiu-se rapidamente para várias tipos de dispositivos. Nesta plataforma todas as aplicações default podem ser substituídas. O Android sofre ainda do problema da fragmentação de versões, o que causa conflitos nomeadamente ao nível de compatibilidade de aplicações. O facto de serem as fabricantes dos dispositivos a comandarem o rumo dos updates para os seus aparelhos faz com que muitas vezes não existam updates oficiais por questão comerciais (de custos para o fabricante) e de venda de novos dispositivos da marca. Ainda há a questão de os próprios aparelhos não poderem suportar os updates por questões de hardware. A versão 2.3 do Android exige pelo menos 1GHz de processamento ao CPU. No Meego, é proibido substituir aplicações “embutidas”, permite apenas que o UX possa ser personalizado, mas com as seguintes restrições:

1. A MeeGo stack tem de ser fornecida na sua totalidade. 2. Todos os pacotes têm de ter base em fontes MeeGo. 3. Os componentes só podem ser adicionados no topo da MeeGo stack. 4. Utilizar a “UI framework” e um modelo de interacção por utilizador

O Meego é feito de forma a tentar impedir a fragmentação da plataforma e assegurar a compatibilidade de aplicações para qualquer dispositivo baseado em Meego. O uso da marca Meego será baseado no cumprimento das especificações do programa de compatibilidade da plataforma. O MeeGo pode até mesmo mudar a forma como se faz as actualizações de sistemas devido ao uso da plataforma Qt, em que da versão MeeGo 1.x poder-se-á passar a ter a versão MeeGo e as actualizações incrementáveis sem necessidade de formatar ou fazer o update de todo o sistema, algo que já se passa em ambientes Linux desktop e que se virá a passar em ambientes Symbian (Qt). O Meego foi projectado de início para plataformas de sistemas embedded, que vão além de smartphones. Exemplo: netbooks, portáteis, computador de bordo (IVI), TV-Box entre outros.

Esquema 6: MeeGo Usage. Fonte: www.meego.com

5.8 Openess / Governance / Maintenance Tanto Android como Meego têm as suas origens em "free sources". Enquanto os participantes da OHA contribuem para o Android, o cronograma de lançamento e conteúdo é totalmente controlado pelo Google. O MeeGo tem uma maior "abertura", visto que opera sobre coordenação da Fundação Linux e tem mais formas de desenvolvimento do que unicamente pela via Java (e agora NDK também). A estrutura do MeeGo é aberta a todos os contribuintes, enquanto o Android e a Open Handset Alliance são claramente regidos pelo Google. Desde o primeiro dia o MeeGo tem pelo menos duas empresas diferentes (neste momento 3 com a AMD) como principais interessadas, o que requer uma estrutura totalmente diferente. Intel e Nokia estão dispostos a receber a participações externas para desenvolvimento no MeeGo.

5.9 Tabela resumo de comparações Android

Meego

Controlo da plataforma

Google

Linux Foundation

Kernel

Fork do Kernel Linux

Kernel Linux

Tipo de Kernel

Monolítico

Dalvik

Open Source

Quase na totalidade

Sim

Open API

Sim

Sim (Qt framework)

Licença

Apache 2.0 (some code are GNU GPL v2 under the GPL v2)

IDE

Eclipse

Qt Creator

MonoDroid

...

App Inventor Linguagem

Java

Qt (C++), Java, Python, ruby.

devenvolvimento

Web Technologies

bash, mono (.net framework),

NDK (C++)

Web Technologies

apk (installer)

rpm (compilador e gestor de

Distribuição (packages)

dependências) Linux Apps

Não

Algumas (“standalone”) "Portable XChat,

Linux

Apps"

FBReader,

=> VLC

Player and Liferea

* "Portable Linux Apps" it's a project where popular Linux software gets packaged into standalone AppImage executables.

6. Considerações finais Como referido o Android não é o Linux como estamos habituados. É apenas um Kernel Linux altamente modificado com uma VM Davlik que trabalha em cima do mesmo. O MeeGo é diferente, basicamente, uma distro com a maioria das ferramentas e bibliotecas do Linux, às

quais os utilizadores e developers já estão habituados. Ao contrário do Android, isto significa que o MeeGo terá todas as capacidades que uma distro Linux dispõe. Este é um dos factos que está a fazer com que alguma da parte da comunidade Linux esteja a colocar de lado a plataforma Android e se esteja a interessar por esta. Quem se sente hà vontade com a linha de comandos e terminal verá no MeeGo algo que os restantes não proporcionam, pelo menos de forma tão explicita, ou não fosse possível efectuar desde já, um Dual Boot entre Maemo e MeeGo ou até Linux Mer e como o total apoio da Nokia (N900). É ainda possível programar para esta plataforma recorrendo a Windows, Mac ou Linux, sendo neste possível ir além do SDK e mergulhar no Kernel podendo então fazer-se adaptações ou modificações ao nível de drivers da câmara fotográfica ou gravação de vídeo por exemplo. Outro aspecto que pode facilitar a migração de developers é o uso de Bibliotecas Qt e por isso um maior leque de plataformas sem para isso haver um custo maior de desenvolvimento, como já referimos anteriormente. A nível de desenvolvimento há no MeeGo um ponto bastante forte. Nesta plataforma existe um conjunto diversificado de ferramentas de desenvolvimento, em que se tem como principal vantagem não estar limitado a uma linguagem como o Java no Android ou o Objective C no IOS. Devido ao facto de ele ser um sistema verdadeiramente Linux, o developer não está vinculado a uma linguagem específica, mas sim a qualquer uma que esteja disponível para Linux. É aqui que pode residir a grande força do MeeGo. Quem desenvolve para Linux é um possível developer para MeeGo, sendo por isso relativamente fácil fazer essa migração de plataformas, visto usarem exactamente a mesmas armas de desenvolvimento. Adicionando a biblioteca Qt e assim se pode constatar um manancial tremendo de potenciais programadores para esta plataforma. Resta à Nokia, Intel, Amd e Linux Foundation, promoverem adequadamente este sistema e assim cativar a comunidade. Note-se que o facto de o MeeGo não estar apenas associado a uma única marca, como o bada (Samsung), WebOs (Palm Pre), ou Android (Google) tem a mais valia de não ter o rumo ditado pelas necessidades exclusivas de uma grande marca. A juntar a isto, há pela primeira vez nos sistemas operativos mobile uma integração multi-plataforma por parte do utilizador que tanto poderá instalar aplicações no seu Symbian, como no Linux ou MeeGo e o developer que pode desenvolver como nunca pode, para tanta plataforma, sem ter de fazer grandes alterações no seu código. Uma vantagem para a plataforma Meego, e provavelmente a mais importante é que o mesmo foi projectado para funcionar em múltiplas plataformas. Handhelds, netbooks, IVI, tv’s, e porque usa um verdadeiro Kernel Linux, cada sistema operacional da mesma familia.

Assim o MeeGo parece-nos que dispõe de muito potencial, bastante capacidade técnica de desenvolvimento, seria dificil arranjar melhores parceiros do que os dois líderes mundiais de CPU’s, caso da Amd e Intel, e uma empresa expert em relações operacionais e inovação aberta como a Nokia. Parece ter tudo para dar certo, veremos se mais uma vez não é descurada a parte mais importante, a usabilidade proporcionada ao utilizador comum. Se o MeeGo falhar a Nokia poderá agravar irremediávelmente o seu futuro.

7. Anexos

Anexo 1 Comparativo entre os vรกrios sistemas operacionais Mobile. Fonte: http://beta.battleit.eu/

Anexo 2 Licenรงas Qt.

Fonte: http://qt.nokia.com/products/licensing/

8. Bibliografia (12/12/2010) Gartner Says Worldwide Mobile Phone Sales Grew 35 Percent in Third Quarter 2010; Smartphone Sales Increased 96 Percent, http://www.gartner.com/it/page.jsp?id=1466313 (27/12/2010) Android vs. MeeGo: two approaches to competitively leveraging "open source", http://the-world-is-analog.blogspot.com/2010/05/android-vs-meego-two-approaches-to.html

(14/12/2010) What is Android?, http://www.embetek.com/index.php?option=com_content&view= article&id=49:android. (15/12/2010) MeeGo Architecture, http://meego.org/meego-architecture/ (15/12/2010) Introduction to Android, http://www.youtube.com/watch?v=x1ZZ-R3p_w8 (16/12/2010) Android 2.0 Review: Almost Human, http://gizmodo.com/5395801/ android-20review-almost-human (16/12/2010) Google's Android code deleted from Linux kernel, http://www.theregister.co.uk/ 2010/02/03/android_driver_code_deleted_from_linux_kernel/ (17/12/2010) MeeGo Build Infrastructure, http://wiki.meego.com/Build_Infrastructure (16/12/2010) Projeto MeeGo Escolhe Btrfs como Sistema de Arquivos Padr達o, http://under-linux.org/projeto-meego-escolhe-btrfs-como-sistema-de-arquivos-padrao-953/ (20/12/2010) How open is the open-source Android truly?, http://www.helloandroid.com/content/ how-open-open-source-android-truly Saxena, Sunil (2010) MeeGo Architecture and Compliance, http://meegozone.com/wp-content/ uploads/2010/09/MeeGoDeveloperDays-IDF-Fall2010.pdf Yanes, Adrian (2010) Packages on Maemo/MeeGo, University Cooperation in Telecommunications, http://fruct.org/conf7/Yanes_Packages_on_Maemo_MeeGo.pdf Chi, Zhang (2010) Leveraging Qt in the MeeGo Ecosystem, http://coscup.org/2010/slides/ 14_0_1300_QtandMeeGo_COSCUP.pdf Saxena,Sunil (2010) MeeGo Architecture and Compliance (ESC Chicago: Android Vs. MeeGo), http://video.eetimes.com/video/esc-chicago-android-vs-meego-for-linux/95697559001 Kost, Stefan, The MeeGo Multimedia Stack - CELF Embedded Linux Conference Europe, http:// elinux.org/images/d/d1/MeeGoMultimedia.pdf van de Ven, Arjan (2010) MeeGo Technical Overview, Linux Foundation Collaboration Summit, http://events.linuxfoundation.org/slides/lfcs2010_ven.pdf (15/12/2010) A fus達o entre Maemo e Moblin, http://www.guiadohardware.net/artigos/meego DOYU. Hiroshi (2010) MeeGo Architecture, http://www.linuxfoundation.jp/jp_uploads/

MeeGo201007/slide/E-4.pdf (17/12/2010) Developing Applications for Android, White Paper http://developer.att.com/home/develop/referencesandtutorials/whitepapers/ Developing_Apps_Android.pdf Jaaksi, Ari (2010) MeeGo Free & Standard Linux OS for the Mobile Industry, http:// events.linuxfoundation.org/slides/lfcs2010_jaaksi.pdf Xuguang, Huang (2009) An Introduction to Android, http://androidgroup.googlecode.com/files/ Introduction%20to%20Android%28Huang%20Xuguang%2020091130%29.pdf Zhang, Danny & Li, Horace (2010), MeeGo* Based Operating. System Technical Overview, http://meegozone.com/wp-content/uploads/2010/07/BJ10_SFTS010_100_English.pdf