Pontifícia Universidade Católica de Minas Gerais Curso de Ciência da Computação. Android, Arquitetura e Desenvolvimento. Thiago de Souza Passos

Transcrição

1 Pontifícia Universidade Católica de Minas Gerais Curso de Ciência da Computação Android, Arquitetura e Desenvolvimento Thiago de Souza Passos Poços de Caldas Novembro de 2009

2 Thiago de Souza Passos Android, Arquitetura e Desenvolvimento Monografia - 2s/2009 Monografia apresentada ao Curso de Ciência da Computação da Pontifícia Universidade Católica de Minas Gerais (Campus Poços de Caldas) como pré-requisito para a obtenção do título de bacharelado sob a orientação do professor Dr. Udo Fritzke Jr. Poços de Caldas Novembro de 2009

3 FICHA CATALOGRÁFICA ELABORADA PELA BIBLIOTECA DA PUC Minas (Campus Poços de Caldas) c

4 Trabalho apresentado à disciplina de Trabalho de Diplomação da Pontifícia Universidade Católica de Minas Gerais, Poços de Caldas, Prof. Dr. Udo Fritzke Jr (Orientador) PUC Minas Prof. MSc. Fabiano Costa Teixeira PUC Minas Prof. MSc. Paulo Muniz de Ávila PUC Minas

5 Agradecimentos Primeiramente agradeço a Deus. Ele tem me ajudado a superar as dificuldades e tem me abençoado à cada dia. Agradeço também à minha família, que contribuiu de uma maneira especial na minha formação pessoal e me deu a oportunidade de estudar. Nunca faltou nada que eu realmente precisasse. Agradeço aos amigos, com carinho especial pelo Fabrício. Ele me ensinou algunas coisas sobre a vida como por exemplo não reclamar dela. Por fim, gostaria de agradecer o professor Dr. Udo Fritzke Jr. pela confiança e orientação de altíssimo nível. Obrigado a todo o corpo docente pelo ensino e pela amizade. e

6 Epígrafe A maravilhosa disposição e harmonia do universo só pode ter tido origem segundo o plano de um Ser que tudo sabe e tudo pode. Isto fica sendo a minha última e mais elevada descoberta. Isaac Newton f

7 Resumo Este trabalho apresenta a arquitetura da plataforma Android, um sistema operacional aberto e livre para celulares e dispositivos móveis. A necessidade de se ter um sistema operacional aberto e livre é crescente conforme aumenta o número de usuários de celulares pelo mundo. Com o aumento desse numero crescem também as iniciativas no sentido de melhorar o processo de desenvolvimento e, assim, ter um ambiente cada vez mais próximo dos sistemas para desktops. Os programas estão cada vez mais robustos e complexos e é necessário que haja bom entendimento das técnicas e ferramentas disponíveis para tal fim. Esta monografia visa elucidar algumas questões nesse sentido. Apresentadas as características principais da arquitetura será proposta uma aplicação baseada em localização (LBA - Location Based Application) que irá utilizar os conceitos estudados e demonstrar o uso das APIs do Google Maps na plataforma Android.

8 Abstract This technical report presents the architecture of the Android Platform, an opensource and free operational system projected by Google for handsets. The need for a free and open operational system is growing as the number of handsets s users around the world increases. With this increase, grows also the initiatives to improve the development process and in order to an environment ever closer to desktops systems. The softwares are increasingly more robust and complex and it is important the understanding of the techniques and tools available for this purpose. This work aims to clarify some issues in this context. After this, we ll propose an Android Location-based Application witch is gonna use the explicated concepts and show the Maps API s use in the Android platform.

9 Sumário I Introdução ao Android 1 1 Introdução Objetivos Android 4 3 Arquitetura do Sistema Kernel Linux Linux no Android Bibliotecas Bionic Libc Bibliotecas de funções Servidores nativos Bibliotecas de abstração do hardware Android Runtime (Ambiente de execução) Máquina Virtual Dalvik Core Libraries Framework de aplicação Activity Manager Package Manager Telephony Manager i

10 SUMÁRIO ii Content Providers Aplicações Componentes da aplicação Conclusões sobre a arquitetura II Desenvolvimento 24 4 Fundamentos de programação no Android Linguagem e paradigma Distribuição das aplicações Independência e estabilidade Activities Serviços Baseados em Localização Aplicações GPS Mapas Google Maps LBS no Android O pacote Location Aplicação Onde Estou OndeEstou Considerações sobre a aplicação Considerações finais 45 Apêndices 46

11 SUMÁRIO iii A Códigos-fonte 46 A.1 OndeEstou.java A.2 Setup.java A.3 MyProximityAlert.java A.4 AndroidManifest.xml A.5 main.xml B Interface da Aplicação 59 Bibliografia 61

12 Lista de Figuras 3.1 Arquitetura do Sistema (fonte: Application Fundamentals) Kernel Linux Bibliotecas Camada de abstração de hardware Android Runtime Framework de aplicação Applicações Ciclo de vida de uma activity (fonte: Activity Android Developers) Super classes de Activity B.1 Interface da Aplicação Onde estou iv

13 Códigos-fonte 4.1 Principais métodos da classe Activity A.1 Classe OndeEstou A.2 Classe Setup A.3 Classe MyProximityAlert A.4 Arquivo de configuração da aplicação AndroidManifest.xml A.5 Arquivo de layout main.xml v

14 Lista de Abreviaturas ANATEL - Agência Nacional de Telecomunicações API - Application Programming Interface BSD - Berkeley Software Distribution DVM - Dalvik Virtual Machine FAQ - Frequently Asked Questions GPL - General Public License GPS - Global Positioning System GUI - Graphical User Interface JVM - Java Virtual Machine KML - Keyhole Markup Language LCD - Liquid Crystal Display mp3 - MPEG Layer 3 MPGE - Moving Picture Experts Group PDA - Personal Digital Assitent SDK - Software Development Kit XML - extensible Markup Language

15 Parte I Introdução ao Android 1

16 1 INTRODUÇÃO Os celulares já se consolidaram no meio comercial. Segundo os últimos dados da ANATEL (Agência Nacional de Telocomunicações) há, atualmente, cerca de 166 milhões de celulares habilitados no Brasil todo. Esse crescimento, não só no Brasil mas no mundo inteiro, vem abrindo espaço para pesquisas na área de desenvolvimento para dispositivos móveis. O hardware presente nos celulares e dispositivos móveis em geral teve uma melhora muito significativa nos últimos anos. Além disso, as tecnologias de redes sem fio e internet banda larga tem crescido muito pelo mundo todo e tem proporcionado uma gama de recursos aos dispositivos móveis, recursos estes antes presentes apenas nos desktops. Essa aproximação dos dispositivos móveis em relação aos desktops, não só em termos de hardware, mas também nas tecnologias de banda larga, tem trazido à tona diversas linhas de pesquisa na área de desenvolvimento de software. No desenvolvimento para celulares e dispositivos embarcados em geral é muito importante considerarmos algumas características como por exemplo a capacidade de: a) processamento, b) memória, c) disco (armazenamento), d) bateria, etc. Embora os celulares hoje em dia tenham um alto desempenho no quesito hardware, ainda assim poderíamos dizer que o hardware é muito limitado se comparado aos desktops. Embora essa afirmação seja verdadeira, os softwares cada vez mais tem migrado, ou melhor, tem estado presente também nos dispositivos móveis. Em outras palavras, os softwares que estão rodando atualmente nos desktops (muito mais potentes de que os dispositivos móveis) estão rodando nos celulares também. Assim, nesse contexto, cabe aos produtores de hardware melhorar o hardware dos dispositivos, buscando aproximar (na medida do possível) os celulares dos desktops. Aos desenvolvedores, cada vez mais eles precisam ser capazes de fazer softwares mais compactos e otimizados, contribuindo assim para o crescimento da plataforma móvel. 2

17 CAPÍTULO 1. INTRODUÇÃO 3 Os ambientes atuais de programação para dispositivos móveis são crianças ainda em termos de padrões e metodologias de desenvolvimento. O que temos atualmente é uma série de plataformas onde há desenvolvimento em paralelo, cada aplicação é desenvolvida para uma linha de celulares ou, as vezes, para um único celular. Essa falta de padrões é prejudicial para os desenvolvedores. Nesse contexto, foi criado um sistema operacional para celulares chamado Android. O Android é um sistema de código aberto que oferece aos fabricantes de dispositivos móveis um sistema completo que gerencie o hardware. Em outras palavras, o Android é uma solução em software criada para provêr aos dispositivos móveis a) gerenciamento de hardware (função de um sistema operacional), b) suporte à drivers plugáveis, c) suporte para desenvolvimento em linguagem nativa C e linguagens de alto-nível como Java e XML, d) frameworks e APIs de desenvolvimento, entre outros. Aos desenvolvedores, o Android oferece suporte completo à programação. Mais adiante, no decorrer deste trabalho, serão mostradas em detalhes as características de programação para a plataforma. 1.1 Objetivos Hoje em dia, torna-se indispensável aos desenvolvedores e especialistas da área de computação conhecer as plataformas, técnicas de programação e APIs disponíveis para desenvolvimento de aplicações em ambientes móveis. Este projeto tem como objetivo apresentar o Android, detalhando pontos importantes da sua arquitetura e o ciclo de vida das aplicações. Além disso pretende-se mostrar como iniciar a construção de um programa básico para o Android. Pretende-se, ao final deste trabalho, desenvolver uma aplicação baseada em localização que irá utilizar o serviço GPS e mostrar a localização do dispositivo através de mapas utilizando a API do Google Maps. Através da aplicação pretende-se mostrar os recursos que a plataforma Android oferece às aplicações baseadas em localização.

18 2 ANDROID Android é uma pilha de softwares para dispositivos móveis que inclui sistema operacional, middleware e aplicações. Entende-se por pilha de software um conjunto de aplicações que trabalham em conjunto para atingir determinado objetivo. Um Sistema Operacional, por exemplo, é uma pilha de softwares. Ele contém diversas aplicações trabalhando em conjunto para atingir seu objetivo, que é gerenciar o hardware. O termo pilha é usado porque numa pilha um elemento depende de outro. Essa idéia de dependência é o que se quer deixar claro no termo Pilha de Softwares (em inglês Software Stack). No Android, além do Sistema Operacional ainda é oferecida uma gama de recursos para programação e desenvolvimento. Esses recursos incluem ferramentas de desenvolvimento (compiladores, emuladores, etc), classes re-escritas, bibliotecas, APIs e Frameworks para tornar possível a confecção de softwares para o Android. Todos esses recursos são fornecidos utilizando a linguagem de programação Java. Vamos falar um pouco sobre os recursos mais importantes a seguir. O próximo capítulo deste documento irá descrever mais detalhadamente a arquitetura do Android. 4

19 3 ARQUITETURA DO SISTEMA É fundamental conhecer bem a arquitetura do Android e fazer uso desses conhecimentos na hora da programação. O bom entendimento de todas as camadas da arquitetura permitirá que o desenvolvedor tire proveito das vantagens que o sistema oferece nativamente, podendo assim criar aplicações mais robustas e de alto-nível. A figura 3.1 mostra a arquitetura do sistema Android. Figura 3.1: Arquitetura do Sistema (fonte: Application Fundamentals) A seguir veremos em detalhes cada camada da arquitetura. A abordagem começará pela parte de baixo da pilha, no Kernel do Android. 5

20 CAPÍTULO 3. ARQUITETURA DO SISTEMA Kernel Linux O Android utiliza o Kernel Linux como camada de abstração de hardware. Em outras palavras, o Kernel Linux constitui o núcleo do Android, realizando todas as funções cabíveis à um sistema operacional. A versão utilizada no Android é a 2.6 do Linux (a mesma utilizada pelos atuais sistemas operacionais Linux) para todos os serviços do núcleo do sistema, como segurança, gerenciamento de memória, gerenciamento de processos, rede, drivers, entre outros. Além disso, foram feitas melhorias no Kernel para que ele tenha um melhor desempenho em dispositivos móveis. Um pouco de história O Kernel Linux foi criado em 1991 por Linus Torvalds. Ele queria desenvolver um sistema Unix-like que rodasse em processadores Intel Antes de desenvovler o Linux, Linus chegou a estudar o Minix, o sistema de Andrew Tanenbaum, mas não ficou satisfeito com a arquitetura deste e resolveu (por hobby, como ele mesmo disse) criar o seu próprio sistema. O sistema operacional Linux que utilizamos em nossos computadores é uma junção do Kernel (criado por Linus) mais uma grande quantidade de outros utilitários e aplicativos abertos e fechados criados por diversas empresas e programadores espalhados pelo mundo todo. Assim, aliado à esses parceiros o Kernel escrito por Linus se tornou o poderoso sistema operacional Linux como conhecemos hoje, um ambiente completo, seguro e estável para desktops, servidores e sistemas embarcados. O Kernel do Linux não foi criado com o intuito de ser portável, mas as coisas evoluíram nesse sentido. Hoje o kernel Linux é um dos Kernels mais portáveis que se conhece. Ele tem sido utilizado em: Computadores - PDAs, netbooks, notebooks, desktops, servidores e mainframes Pequenos dispositivos eletrônicos - Relógios, eletrodomésticos,

21 CAPÍTULO 3. ARQUITETURA DO SISTEMA 7 Celulares, vídeo-games, entre outros Arquiteturas compatíveis com o Linux O site oficial da Debian GNU/Linux (atualmente umas das mais importantes distribuições Linux) possui uma FAQ 1 na qual são explicados, entre outros, alguns pontos sobre compatibilidade do sistema Linux. Em resposta à questão sobre quais arquiteturas de hardware rodam Linux, o site disponibiliza a seguinte resposta: O Debian GNU/Linux inclui os códigos-fonte completos para todos os programas inclusos, portanto, eles devem rodar em qualquer sistema que seja suportado pelo kernel Linux; veja a FAQ do Linux para detalhes. A versão atual do Debian GNU/Linux, a 5.0, contém uma completa distribuição binária para as seguintes arquiteturas: i386: essa cobre os PCs baseados em Intel e processadores compatíveis, incluindo Intel 386, 486, Pentium, Pentium Pro, Pentium II (tanto Klamath quanto Celeron), e Pentium III, e os processadores compatíveis da AMD, Cyrix e outros, compatíveis com estes. m68k: essa cobre as máquinas Amiga e Atari que possuem processadores Motorola 680x0 (para x >= 2); com MMU. alpha: sistemas Alpha da Compaq/Digital. sparc: essa cobre os sistemas SPARC da Sun e a maioria dos sistemas UltraSPARC. powerpc: essa cobre algumas máquinas IBM/Motorola PowerPC, incluindo máquinas CHRP, PowerMac e PReP. arm: máquinas ARM e StrongARM. Trecho retirado do site da Debian GNU/Linux 1 Disponível em

22 CAPÍTULO 3. ARQUITETURA DO SISTEMA Linux no Android O Linux tem se mostrado um sistema operacional bastante robusto e estável, inclusive sendo usado em servidores e, cada vez mais, em empresas. Se, no seu surgimento, o Linux era usado praticamente só em universidades e apenas por especialistas na área (geralmente, no meio acadêmico), cada vez mais o Linux tem ocupado um lugar de destaque em outras áreas, seja em ambientes comerciais ou para uso pessoal. Além do mais o sistema tem sido constantemente melhorado. Normalmente, a cada seis meses sai uma atualização com melhorias e correções de problemas encontrados por usuários no mundo todo. Assim, as falhas (até os melhores sistemas tem falhas) são encontradas e corrigidas mais rapidamente que em qualquer outro sistema operacional que se conheça. Essas e outras razões contribuíram para que o Linux fosse usado no Kernel da plataforma Android. O Kernel atua como uma camada entre o hardware e o restante dos softwares. A figura 3.2 apresenta o Kernel Linux e seus componentes. Figura 3.2: Kernel Linux Android não é Linux Embora o Kernel Android seja baseado no Kernel do Linux, ele não é um sistema Linux, pois: Não possui sistema nativo de janelas Não possui suporte à biblioteca glibc Não inclui o mesmo conjunto de utilitários dos sistemas Linux (e.g., dbm do RedHat ou Ubuntu)

23 CAPÍTULO 3. ARQUITETURA DO SISTEMA 9 Por que utilizar o Kernel do Linux? Se o Android não é um sistema Linux, porque então utilizar o Kernel do Linux? Qualquer conhecedor de sistemas operacionais poderia responder essa pergunta. O Linux oferece recursos que o tornam o mais indicado para ser utilizado no Android. Excelente gerenciamento de processos e memória - Segundo [Brady, 2008], O Linux possui gerenciamento de processos e memória, como nenhum outro sistema possui Modelo de segurança baseado em permissões - Controle rígido de permissões na qual cada usuário tem determinados privilégios sobre cada arquivo Drivers - O Linux tem um modelo de drivers que permitiu aos desenvolvedores da plataforma criar uma abstração entre os dispositivos de hardware (e.g. LCDs, TouchScreen, Keyboard, etc) e os software que eles utilizam Suporte para bibliotecas compartilhdas - É o que se costuma chamar de pluggable architecture (arquitetura plugável), quando um sistema permite plugar diversos componentes com muita facilidade, etc... Open-Source Talvez a mais forte característica do Linux é que ele é um sistema Open-source (i.e., de código aberto). A comunidade que mantém o Linux é bastante numerosa e tem acrescentado inúmeras qualidades que tornaram o Linux uma potência em termos de sistema operacional. Melhorias do Kernel Alguns programas foram acrescentados ao Kernel para que ele pudesse se adequar aos dispositivos móveis. Dentre os principais programas, podemos destacar os seguintes: Alarm - Driver para prover temporizadores e funções básicas de alarmes (e.g., ligar ou desligar o aparelho) Ashmem (Android shared memory) - Permite que as aplicações compartilhem memória

24 CAPÍTULO 3. ARQUITETURA DO SISTEMA 10 Binder - Gerencia a intercomunicação entre processos. No Android todas as aplicações rodam em processos diferentes e as vezes é necessário que haja comunicação entre processos para compartilhar dados. Tipicamente, qualquer comunicação entre processos (IPC) pode causar um overhead significativo e ainda, falhas de segurança. O Binder foi criado para resolver estes problemas Power Management - Gerenciador de energia - Baseado no projeto OpenBinder 2, entre outros Mais informações Informações sobre o Kernel Linux podem ser obtidas na página oficial dos desenvolvedores do Kernel Linux 3. O código-fonte do Kernel Android está disponível para análise, estudos e colaboração no seguinte repositório: Bibliotecas A próxima camada da arquitetura é a camada das bibliotecas. Todas elas foram escritas em C e C++. Segundo [Cleron, 2007c], deste nível é que vem todo o poder, ou melhor, a robustez da plataforma. Como todas as classes foram escritas em C / C++ iremos começar falando Figura 3.3: Bibliotecas da biblioteca Libc ou melhor, Bionic Libc. Assim iremos entender melhor como funcionam as bibliotecas de código C da plataforma Android. [Brady, 2008] divide as bibliotecas em quatro partes. São elas:

25 CAPÍTULO 3. ARQUITETURA DO SISTEMA Bionic Libc Bionic Libc é uma implementação específica da biblioteca Libc, otimizada para uso embarcado. Novamente, que fique claro que esta biblioteca é diferente dos ambientes de programação em C encontrados em sistemas Linux, como Ubuntu ou Fedora. Por que criar uma nova Libc? Com certeza é um grande trabalho manter uma nova implementação de uma biblioteca própria da linguagem C. Foram três fatores fundamentais que contribuiram para a decisão de criar uma nova biblioteca. 1. Licença - Libc utiliza licença GPL. A licença GPL é uma licensa de software livre. Dentre as especificações da licença GPL, podemos destacar uma delas como a mais importante: todos os trabalhos derivados de projetos com licença GPL tem que ser licenciados sob a mesma licença (i.e. se 1% da sua aplicação utilizar algum projeto sob a licença GPL, então a sua aplicação inteira terá de ser GPL também). Segundo a Free Software Foundation, essa medida é necessária para proteger os autores e desenvolvedores. A biblioteca criada no projeto Android, a BionicC é distribuída sob a licença BSD. Os códigos sob a licença BSD podem ser utilizados em softwares livres ou softwares proprietários 4. Embora o Android seja um projeto de software livre é importante para algumas empresas ter a liberdade de ter seus softwares bem guardados, ou seja, estas empresas terão a possibilidade de possuir código-fechado mesmo junto com um projeto de código aberto. É o caso por exemplo da empresa Apple e da Microsoft, que utilizam protocolos de rede abertos (nas suas aplicações de rede e servidores) em seus sistemas operacionais. Não faria sentido estes dois sistemas operacionais serem obrigados a utilizar a licença GPL apenas porque eles utilizam uma pequena parte do software sob esta licença. Por final, foi utilizada no Android a licensa BSD para não haver problemas de código proprietário. 2. Tamanho - Para um desktop com GBs de memória RAM pouco importa o tamanho 4 Apenas com o conhecimento dos autores e pequenas restrições

26 CAPÍTULO 3. ARQUITETURA DO SISTEMA 12 de aplicativos em C, mas para um dispositivo móvel é diferente. A biblioteca Bionic Libc é realmente muito pequena, tem 200K, aproximadamente metade do tamanho da biblioteca GLibc. Isso representa um grande impacto se pensarmos em múltiplos processos rodando ao mesmo tempo num dispositivo móvel. E isso realmente irá acontecer pois no Android cada aplicação irá rodar sobre uma instância da biblioteca Bionic libc. 3. Rapidez - Toda biblioteca deve ser rápida, principalmente nos dispositivos móveis. Além do tamanho é necessário que as bibliotecas sejam rápidas e eficientes mesmo quando várias instâncias forem criadas. Mesmo para um dispositivo móvel é comum que uma aplicação (inclusive o próprio sistema operacional) se utilize de centenas de threads para realizar as mais diversas funções. Para aumentar a velocidade das aplicações que utilizam threads (praticamente todas hoje em dia) foi feita a re-implementação da biblioteca pthread. Enquanto a biblioteca pthread convencional tem tamanho de cerca 12 KB a biblioteca re-escrita tem apenas 4 KB. Além das vantagens acima citadas, também foram integrados à biblioteca funções para a utilização de serviços específicos do Android: Propriedades do sistema - através das funções getprop e setprop é possível obter e modificar propriedades do sistema operacional ou trocar informações entre processos. Há propriedades que são visíveis no sistema inteiro (algumas propriedades não podem ser modificadas, elas começam com as letras ro., de read-only). A seguir os protótipos das funções: int property_get(const char *key, char *value, const char *default_value); int property_set(const char *key, const char *value); Onde: a) key = identificação da propriedade, geralmente algo como my.system.property b) const = buffer que irá guardar as informações e c) default value = valor padrão da propriedade

27 CAPÍTULO 3. ARQUITETURA DO SISTEMA 13 Capacidades de Log realizar o debbug das aplicações nativas. - algumas funções para criar arquivos de log e tornar possível LOGI( Logging a message with priority Info ); Bibliotecas de funções O Android possui várias bibliotecas, então não iremos falar de todas (até porque a maioria já é conhecida dos usuários). [Cleron, 2007c] define como sendo as mais importantes bibliotecas: WebKit O WebKit é um engine (i.e., motor) de browsers. Ele é o responsável por analisar o código das páginas Web e criar a visualização que os navegadores exibem (processo conhecido por renderização). Em outras palavras o WebKit é o motor que faz um browser funcionar. Atualmente, os seguintes browsers utilizam o WebKit: Safari, da Apple Chrome, da Google Epiphany, navegador padrão do Gnome Midori Arora OmniWeb icab Shiira ABrowse Desta lista, merecem destaque os navegadores da Google e da Apple, grandes empresas hoje no ramo de software.

28 CAPÍTULO 3. ARQUITETURA DO SISTEMA 14 Media Framework Esta biblioteca é responsável por fornecer suporte a todo tipo de arquivos de mídia. Ela é baseada no pacote de vídeos OpenCore. As bibliotecas oferecem suporte para visualizar e gravar em diversos formatos de audio, vídeo e também imagens. Entre esses formatos podemos destacar alguns mais populares: MPEG4 H.264 MP3 AAC AMR JPG PNG Com esses codecs é possível ter uma rica experiência com audio e vídeo. Os desenvolvedores não precisam se preocupar em desenvolver ou importar codecs para estes tipos de arquivo, pois o sistema operacional lhes oferece, nativamente, esse suporte. SQLite O SQLite é um banco de dados otimizado para dispositivos móveis. Como sugere o nome, é um banco de dados mais leve, apropriado para ambientes com menos recursos. Com um banco dados relacional as aplicações tem mais recursos para armazenar suas informações de forma estruturada e assim, criar aplicações mais robustas, rodando com um banco de dados local Servidores nativos São processos rodando em background para realizar tarefas para controlar os dispositivos de entrada e saída do dispositivo.

29 CAPÍTULO 3. ARQUITETURA DO SISTEMA 15 Gerenciador de superfícies Biblioteca é responsável por desenhar na tela, ou melhor, apresentar todas as interfaces gráficas das aplicações e do próprio sistema operacional. A troca de janelas e gerenciamento de tudo que for GUI (interface gráfica com o Usuário) cabe à esta biblioteca. OpenGL ES e SGL Bibliotecas para gráficos 2D e 3D, que podem ser combinados numa mesma aplicação. O núclo (core) dos gráficos é formado por essas duas bibliotecas, ambas livres. Gerenciador de áudio Enquanto o gerenciador de superfícies é responsável pelos dispositivos de display, o gerenciador de áudio é o responsável pelo gerenciamento de todos os dispositivos de saída de áudio. O gerenciador de áudio se encarrega de todas as formas de saída de áudio do dispositivo Bibliotecas de abstração do hardware Entre o hardware e o níveis superiores da arquitetura do Android se encontra a camada de abstração de hardware. Acima da camada do Kernel linux há vários fabricantes de hardware que irão fazer drivers para se comunicar com o software rodando no Android. Para mostrar melhor o papel desta camada, a figura 3.4 mostra onde a camada de abstração de harware se encaixa dentro da figura 3.1 (Arquitetura do Android, página 5). A camada de abstração tem como objetivo definir as interfaces que o Android requer que os drivers de hardware implementem para que se encaixar (plugar) ao sistema. Essa camada separa a lógica da plataforma do Android das interfaces de hardware. [Brady, 2008] explica que a equipe tentou criar um padrão, um conjunto de APIs para definir como um hardware irá se comunicar com o dispositivo. Da mesma forma que o Android SDK fornece aos desenvolvedores classes e interfaces que possibilitam que ele

30 CAPÍTULO 3. ARQUITETURA DO SISTEMA 16 faça seu próprio código e rode dentro da arquitetura, com o hardware vai acontecer de maneira parecida. 3.3 Android Runtime (Ambiente de execução) Este componente foi escrito exclusivamente para o Android, permitindo-lhe rodar programas complexos em ambientes com memória limitada, bateria limitada, processamento limitado, entre outros. O ambiente de execução do Figura 3.4: Camada de abstração de hardware Android é composto pela Máquina Virtual Dalvik, criada especialmente para o sistema Android. Também temos as bibliotecas para se programar especificamente para essa máquina virtual. A seguir iremos falar sobre estes dois itens, a máquina virtual e as suas bibliotecas Máquina Virtual Dalvik A máquina virtual Dalvik roda aplicações no formato.dex (do acrônimo em inglês Dalvik Executable). As aplicações do Android irão rodar no ambiente virtual Dalvik sempre. Isso significa que qualquer que Figura 3.5: Android Runtime seja o dispositivo, o ambiente em que o programa roda será sempre o mesmo (mesmo sendo celulares completamente diferentes ou, ainda, mesmo não sendo celulares), dando portabilidade às aplicações escritas para o Android. A máquina virtual Dalvik não roda bytecodes Java, ela roda apenas arquivos to tipo.dex. Se o Android precisar executar um pacote.jar ele irá primeiro converter as classes para o formato.dex, que é menor e depois irá rodar essas classes.

31 CAPÍTULO 3. ARQUITETURA DO SISTEMA 17 Cada aplicação no Android roda no seu próprio processo, com a sua própria instância da Máquina Virtual Dalvik. Em outras palavras um dispositivo rodando Android pode rodar múltiplas máquinas virtuais de maneira eficiente, e cada processo roda em cima da sua própria máquina virtual. A máquina virtual Dalvik depende do Kernel Linux para fornecer funcionalidades como threading and gerenciamento de memória de baixo-nível, isso melhora significantemente o desempenho das aplicações [Brady, 2008] Core Libraries O Android conta com uma série de bibliotecas para prover as mesmas funcionalidades básicas disponíveis na linguagem Java. Observe na figura 3.1 (Arquitetura do Sistema, página 5) que tudo o que está em azul foi escrito em Java. Por isso as bibliotecas do core estão em azul. É importante ressaltar que todas as classes em Java foram reescritas para uso específico pela Máquina Virtual Dalvik. Apesar de algumas classes serem bem parecidas (ou idênticas) com as classes Java, elas foram reescritas. Portanto, o Android não usa as mesmas classes Java. Para se ter uma noção das classes Java re-implementadas segue uma pequena lista com as classes mais comuns, todas reescritas para o Android: Classes Java java.io java.math java.net java.security java.sql java.util Outras junit.framework

32 CAPÍTULO 3. ARQUITETURA DO SISTEMA 18 org.apache.http org.json org.w3c.dom org.xml, entre outras O objetivo aqui não é falar das classes especificamente. Quem já está familiarizado com as classes Java não terá problemas para entender o funcionamento das classes do Android. 3.4 Framework de aplicação Um nível acima do ambiente de execução temos o Framework de aplicação, totalmente escrito em linguagem Java. Um Framework é um conjunto de módulos integrados que visam o reaproveitamento de código, aumentando a produtividade na hora do desenvolvimento. A idéia principal de um framework é proporcionar à uma determinada linguagem uma série de recursos para elevar o nível de abstração dessa linguagem. No Android, esses frameworks são uma caixa de ferramentas (comumente chamados de toolkit) que todas as aplicações utilizam. Estas aplicações incluem implementações do celular (como por exemplo as aplicações Home e Phone), aplicações escritas pela equipe do Android (Google) e aplicações escritas por nós, programadores. Todas as aplicações usam o mesmo framework e as mesmas APIs. Figura 3.6: Framework de aplicação Entre os frameworks, podemos destacar os frameworks de serviço, aqueles cuja existência é fundamental para a plataforma inteira. Alguns desses frameworks trabalham em background de maneira transparente para o programador. A seguir serão descritos alguns dos mais importantes componentes desta camada:

33 CAPÍTULO 3. ARQUITETURA DO SISTEMA Activity Manager Estas atividades são serviços rodando em background que irão gerenciar todo o ciclo de vida de uma aplicação Android Todas as tarefas relativas a troca de contexto e gerenciamento de processos são realizadas por esse componente Package Manager Este componente é responsável por gerenciar a instalação e atualização das aplicações no Android. O package manager (gerenciador de pacotes) funciona de maneira parecida com outros gerenciadores de pacotes de sistemas Linux como por exemplo: Yum (Fedora) Synaptics (Debian e Ubuntu) Software Update (Mac OS) Telephony Manager Contém as APIs utilizadas na Aplicação Phone. Todas as aplicações relativas à um celular (conceito básico de um celular: fazer ligação) são fornecidas por este componente. Assim, a aplicação Phone do Android (padrão do sistema) utiliza estas APIs e todos os programadores que desejarem usar algum recurso ligado à telefonia poderão utilizar também esta classe Content Providers Os provedores de conteúdo são uma exclusividade do Android. Este framework provê recursos para que as aplicações compartilhem dados entre si. Os dados podem ser armazenados no dispositivo através de arquivos ou do banco de dados SQLite. Pode ser que, em determinado momento, uma aplicação crie dados e queira disponibilizar estes para uma aplicação de terceiros. O contrário também pode ser verdade,

34 CAPÍTULO 3. ARQUITETURA DO SISTEMA 20 em determinado momento podemos precisar de dados gerados por uma outra aplicação. Repare que este recurso enfatiza bem o significado de framework, no sentido de que as aplicações são mais integradas, visando escrever menos código, com transparência para o programador. Todos os contatos do Android são gerenciados e armazenados pela aplicação Contacts. Esta classe é um ótimo exemplo de uma aplicação provedora de conteúdo. Todos os objetos da classe (i.e., todos os contatos) são disponibilizados através dos provedores de conteúdo para qualquer aplicação que queira utilizar esses contatos. 3.5 Aplicações O Android vai rodar com várias aplicações em seu núcleo (core) incluindo cliente de e- mail, programas de SMS, calendário, mapas, navegador, contatos, entre outros. Todas aplicações são escritas em Java. Figura 3.7: Applicações As aplicações de terceiros também rodarão nesta camada, a camada mais alta da plataforma. Nesta camada é que vão estar todas as aplicações de alto-nível. Pode ser necessário implementar em qualquer uma das outras camadas, mas isso só para casos mais específicos (e.g., numa aplicação CPU-Bound pode ser necessária a utilização da linguagem C para se obter melhor desempenho) Componentes da aplicação Uma característica central nas aplicações do Android é o fato de elas poderem fazer uso de elementos de outras aplicações (claro que apenas se as outras aplicações permitirem e disponibilizarem estes recursos). Para isso, sua aplicação não precisa incorporar nem linkar código de outras aplicações. Basta referenciar a activity da outra aplicação que você necessita.

35 CAPÍTULO 3. ARQUITETURA DO SISTEMA 21 Para que isso funcione, o sistema deve ser capaz de iniciar uma aplicação quando qualquer parte dela for requerida e instanciar os objetos Java para aquela parte. Diferentemente das aplicações de outros sistemas, as aplicações do Android não possuem apenas uma função de entrada do programa (entry point) que sempre será chamada quando a aplicação rodar (e.g., a função main()). No Android as aplicações possuem componentes essenciais que o sistema pode instanciar e rodar quando for preciso. Há quantro tipos de componentes: Activities (Atividades) Uma atividade consiste num serviço visual oferecido ao usuário, que pode ser uma lista de contatos, um vizualizador de fotos, um player mp3. Poderíamos por exemplo ter uma atividade para mostrar as músicas do celular, uma outra atividade para tocar uma música selecionada, e ainda uma outra atividade para enviar a música por bluetooth para outro aparelho. Embora todas estas atividades estejam fortemente relacionadas e componham uma só aplicação, elas são independentes umas das outras. Isso significa que em determinado momento poderíamos usar apenas o player de músicas por exemplo. Services Um serviço não possui interface gráfica, ao invés disso roda em background, por um período de tempo indefinido. Um bom exemplo de um serviço é um player que utiliza um serviço para tocar as músicas. O player em si pode estar ativo ou não. O usuário pode estar fazendo outras coisas e mesmo assim a música deve continuar tocando. Broadcast Receivers Um receptor por broadcast é um componente que apenas recebe anúncios tanto do sistema quanto de outras aplicações. O sistema pode querer avisar por exemplo que a hora mudou ou ainda que a bateria esteja acabando. Uma aplicação poderia avisar que acabou o download de um arquivo no servidor e o arquivo está disponível.

36 CAPÍTULO 3. ARQUITETURA DO SISTEMA 22 Uma aplicação pode ter vários receptores esperando por informações que achar relevante para a aplicação. Estes receptores não exibem nenhuma interface. Eles apenas avisam o sistema que algo está acontecendo. Cabe ao sistema saber se avisa o usuário ou apenas toma alguma decisão baseada na mensagem recebida. Na maioria das vezes que um sistema precisa avisar o usuário de algo, ele irá utilizar o NotificationManager. Content Providers Um provedor de conteúdo é o componente responsável por tornar um determinado conjunto de dados de uma aplicação disponível para outras aplicações. Isso é feito através de permissões de usuários. Como cada processo é como se fosse um usuário, então cada processo vai enxergar apenas os seus arquivos.

37 CAPÍTULO 3. ARQUITETURA DO SISTEMA 23 Conclusões sobre a arquitetura Observando a arquitetura do Android (capítulo 3.1, página 5), pode-se observar que todas as camadas da arquitetura utilizam, ou melhor, reutilizam componentes já existentes e de código aberto, possibilitando a realização de melhorias, quando preciso (como foi o caso das bibliotecas libc, WebKit e outras citadas anteriormente). Aí está a importância de uma plataforma totalmente aberta e talvez daí tenha surgido a necessidade da criação da plataforma Android. Poderíamos comparar o Android com o Linux em alguns pontos, como código livre e portabilidade. Um dos objetivos de Linus Torvalds (criador do Linux) era mostrar o código a quem quisesse ver para que os outros usuários pudessem contribuir com o seu projeto. E ele acertou nisso. A comunidade científica abraçou esta idéia e contribuiu (contribui até hoje) de maneira imensurável para o desenvolvimento do Sistema Operacional. O Android está seguindo os passos do Linux.

38 Parte II Desenvolvimento 24

39 4 FUNDAMENTOS DE PROGRAMAÇÃO NO ANDROID Nos capítulos anteriores abordamos diversos conteúdos relacionados ao Android, mas sempre de uma forma bastante teórica. Este capítulo visa abordar de uma forma mais prática os principais conceitos à respeito de uma aplicação para o Android. Nesta seção, todos os trechos de código e palavras comuns nas classes e nos componentes do Android não serão traduzidos. Essa medida foi tomada exatamente para não confundir os leitores, já que a documentação oficial encontra-se em inglês. 4.1 Linguagem e paradigma Para desenvolver uma aplicação básica (custom application) no Android é preciso conhecer Java, XML e Programação Orientada à Objetos. Segue uma breve descrição de cada uma: A linguagem Java é uma linguagem de programação orientada à objetos criada na década de 90 por uma equipe de programadores da Sun Microsystems. As características mais marcantes da linguagem Java são as seguintes: orientação à objetos e portabilidade, independência de plataforma ( write once, run anywhere ), A Programação Orientada à Objetos (POO) é um paradigma de programação que surgiu ainda na década de 60. Nessa época, a complexidade do hardware e software estavam crescendo e em contra-partida a qualidade dos softwares começava a diminuir. Nesse contexto, a orientação à objetos surgiu trazendo melhorias na forma de se modelar um sistema. Não iremos entrar em detalhes ou explicar melhor como funciona o paradigma de orientação à objetos, pois iríamos estar nos distanciando muito do foco. Espera-se que 25

40 CAPÍTULO 4. FUNDAMENTOS DE PROGRAMAÇÃO NO ANDROID 26 o leitor tenha algum conhecimento prévio de POO, não só para o bom entendimento desta seção, mas também pra se desenvolver qualquer software no Android. A linguagem de marcação XML (do acrônimo em inglês extensible Markup Language), trata-se de uma linguagem de marcação para representar qualquer tipo de dado e trocar esses dados entre qualquer tipo de aplicação. O objetivo principal do XML é ser portável, não só quanto à plataforma como também quanto à aplicação. Em outras palavras, um documento XML deve poder ser lido em qualquer plataforma computacional e por qualquer aplicação capaz de ler e processar texto. Existem muitos derivados de XML como, por exemplo: a) XHTML, b) MathML, c) MusicXML, d) SVG (para criação de gráficos), e) Atom, f) RSS, entre outros. Cada formato precisa ter uma estrutura conhecida para poder trocar informações com outras plataformas/aplicações. No Android as aplicações são escritas utilizando a linguagem de programação Java e XML. Conforme vimos nos parágrafos anteriores, estas duas linguagens proporcionam algumas características importantes que fizeram delas linguagens conhecidas e utilizadas no mundo inteiro para os mais diversos fins. 4.2 Distribuição das aplicações Tanto os arquivos Java quanto os demais (arquivos de recursos, imagens, etc) são empacotados, através de um programa chamado aapt tool, para um formato de pacotes do Android, cuja extensão é.apk (de Android Package). Estes arquivos (pacotes na verdade) são o meio de se distribuir e instalar programas em dispositivos móveis com o sistema Android. 4.3 Independência e estabilidade Cada aplicação rodando no Android é totalmente independente das outras aplicações. Isso proporciona estabilidade para as aplicações.

41 CAPÍTULO 4. FUNDAMENTOS DE PROGRAMAÇÃO NO ANDROID 27 Entre as principais características das aplicações do Android, destacam-se as seguintes: Por padrão cada aplicação roda no seu próprio processo Linux Cada processo roda na sua própria máquina virtual java (VM) A segurança é garantida através de um id de usuário Linux (i.e., cada aplicação recebe um id de usuário Linux), assim, as permissões são configuradas de modo que os arquivos de uma aplicação serão visíveis apenas para aquele usuário, ou seja, apenas para a própria aplicação Conforme citado na seção 3.5 (página 20), há quantro tipos de componentes principais nas aplicações do Android. A seguir será dada uma descrição mais detalhada do componente Activity. 4.4 Activities Todo componente do sistema que interagir de alguma forma com o usuário deverá ter pelo menos uma activity, um processo gerenciado pelo sistema operacional. Como todo processo, as activities possuem um ciclo de vida. A figura 4.1 (Ciclo de vida de uma activity) mostra o ciclo de vida completo de uma activity. Na linguagem Java utilizamos o método estático main() para representar o ponto de partida da aplicação (i.e., o primeiro método que será chamada quando o programa for iniciado). No Android não é diferente, precisamos de uma referência para dizer ao sistema qual classe queremos chamar quando o programa for iniciado. O Android ainda possui a característica de poder ter uma ou n activities. Isso lhe dá a possibilidade de definir várias classes-chave do sistema, classes estas que podem ser instanciadas independente umas das outras. Em outras palavras, o Android não tem apenas um ponto de entrada para suas aplicação, ao invés disso ele possui várias activities, como se fosse um programa convencional com vários métodos main(). Isso é pertinente porque no Android uma aplicação tem a possibilidade de chamar uma activity de outra aplicação.

42 CAPÍTULO 4. FUNDAMENTOS DE PROGRAMAÇÃO NO ANDROID 28 Um exemplo prático poderia ser uma aplicação de música que em determinado momento queira mostrar a capa do album da música que está tocando. Se alguma outra aplicação (especializada em fotografias) fornecer uma activity, o programa de música podera invocar essa activity como se fizesse parte do próprio programa. Ciclo de vida de uma Activity A figura 4.1 mostra o ciclo de vida de uma activity do ponto de vista do sistema operacional. Figura 4.1: Ciclo de vida de uma activity (fonte: Activity Android Developers)