Mobilidade de Código Rápida em Android

Transcrição

1 Mobilidade de Código Rápida em Android CISTER Centro de Investigação em Sistemas Confiáveis de Tempo-Real 2011 / Bruno Filipe Ferreira Soares José Miguel Ribeiro Jesus Teixeira

2 Mobilidade de Código Rápida em Android CISTER Centro de Investigação em Sistemas Confiáveis de Tempo-Real 2011 / Bruno Filipe Ferreira Soares José Miguel Ribeiro Jesus Teixeira Licenciatura em Engenharia Informática Outubro de 2012 Orientadores ISEP: Dr. Luís Lino Ferreira e Mestre Paulo Baltarejo de Sousa Supervisor Externo: Mestre Cláudio Maia ii

3 Agradecimentos Os nossos agradecimentos vão, primeiramente, para o Dr. Luís Lino Ferreira pela constante atenção e supervisão dadas ao nosso projeto. Os constantes conselhos dados, tanto no projeto como na elaboração deste relatório, foram, para nós, de uma mais-valia imensurável. Agradecemos também ao Mestre Cláudio Maia por se ter disponibilizado, sempre que podia (e mesmo quando não podia), a auxiliar em todos os problemas que foram surgindo durante o projeto. Foi, para nós, um enorme privilégio poder ter como orientador uma pessoa com o seu nível de conhecimento. Por último, mas não menos importante, queremos expressar os nossos maiores agradecimentos aos nossos respetivos familiares, amigos e ente-queridos, porque, sem o apoio destes, nunca chegaríamos onde estamos agora. A todos os referidos: Muito Obrigado! iii

4 Resumo Este relatório tem como objetivo apresentar e descrever o projeto desenvolvido para a unidade curricular de Projeto/Estágio do ano letivo 2011/2012, do 2º semestre da Licenciatura em Engenharia Informática do Instituto Superior de Engenharia do Porto. Este projeto teve como objetivo estudar e melhorar bibliotecas de mobilidade de código desenvolvidas em Android, bem como, desenvolver uma aplicação que demonstrasse as potencialidades das referidas bibliotecas. O projeto dividiu-se em quatro fases principais: (1) Estudo e melhoria das bibliotecas de mobilidade de código existentes, onde para além da correção de erros e adição de funcionalidades, foi desenvolvido um mecanismo de Dynamic Class Loading numa das bibliotecas de modo a melhorar o seu desempenho; (2) Desenvolvimento de uma aplicação que servisse como prova de conceito às funcionalidades fornecidas pelas referidas bibliotecas. A aplicação desenvolvida foi um jogo, usando, para isso, uma biblioteca gráfica para Android denominada AndEngine; (3) Implementação, no jogo desenvolvido, das funcionalidades das bibliotecas de mobilidade de código e Offloading, de forma a testar a viabilidade da utilização das tecnologias referidas no problema escolhido. (4) Realização de testes para análise dos resultados às implementações realizadas nas três fases anteriormente referidas. Pretendeu-se com este projeto demonstrar as potencialidades da mobilidade de código em dispositivos que, sendo cada vez mais usados, nem sempre possuem os recursos necessários às necessidades de utilização dos seus utilizadores. Palavras-Chave (Tema): Mobilidade de Código, Computação Móvel, Computação Gráfica, Computação Distribuída Palavras-Chave (Tecnologias): Android, Java, AndEngine iv

5 Abstract This report aims to present and discuss the project developed for the course of Projeto/Estágio for the academic year of 2011/2012, of the second semester of the Degree in Computer Engineering from the Instituto Superior de Engenharia do Porto. This project aimed at studying and improving the offloading libraries developed in Android as well as developing an application that would demonstrate the potential of the features provided by the referred libraries. The project was divided into four main components: (1) Study and improvement of the existent code mobility libraries, where in addition to error fixing and the addition of new functionalities, it was developed a mechanism of Dynamic Class Loading in one of the libraries in order to improve its performance; (2) Development of an application with the purpose of serving as a proof of concept to the functionalities of the referred libraries. The developed application was a videogame in which it was used, during its development, a graphic library for Android called AndEngine; (3) Implementation, in the developed videogame, of the features provided by the code mobility libraries, so it would be possible to test the feasibility of the use of the referenced technologies in the chosen problem; (4) Performance of tests to evaluate the results of the implementations made in the project s components previously mentioned. This project intended to demonstrate the potential of code mobility in devices that, being used by an increasing number of users, sometimes lack the necessary resources to fulfill the needs of its users. Key-Words (Theme): Code Mobility, Mobile Computing, Graphical Computing, Distributed Computing Key-Words (Technologies): Java, Android, AndEngine v

6 Índice 1 Introdução Enquadramento Objetivos do Projeto Planeamento do Projeto ª Fase Estudo, documentação e melhoria das bibliotecas existentes ª Fase Estudo de novas formas de mobilidade e implementação do método escolhido ª Fase Discutir e Planear a Aplicação Multimédia ª Fase Desenvolvimento da Aplicação Multimédia ª Fase Aplicação da biblioteca de mobilidade de código à aplicação desenvolvida ª Fase Desenvolvimento do relatório final Reuniões de Acompanhamento Relatórios Semanais Tecnologias Utilizadas Apresentação da Organização Organização do Relatório Android Pilha de Software Android Desenvolvimento em Android Android Manifest Componentes de uma Aplicação Android Mobilidade de Código vi

7 3.1 Mobility Framework (MobFr) Arquitetura Discovery Manager Package Manager Execution Manager Testes à mobilidade de código com a MobFr Aplicação de Demonstração da MobFR Implementação de Dynamic Class Loading (DCL) na MobFr Dynamic Class Loading Aplicação de Prova de Conceito Implementação na MobFr Real Time Code Offloading Visão geral da Framework Descrição da Framework Previsão do limite Implementação Regressão linear Tempo de mobilidade de código Tempos de execução Aplicação de Demonstração de Mobilidade de Código Bibliotecas gráficas para Android AndEngine Desenvolvimento Conceito Geral do Videojogo vii

8 5.3.2 Pormenores de implementação Integração das bibliotecas de mobilidade o offloading de código Testes Dispositivos Usados Testes à funcionalidade de DCL na MobFR Testes Efetuados ao Jogo Teste 1 Tempos de ciclo em função do número de inimigos Testes aos tempos de processamento locais com offloading de código Conclusões Objetivos Realizados Limitações e Trabalhos Futuros Bibliografia Anexos Relatórios Semanais viii

9 Índice de Figuras Figura 1- Duração das diferentes fases do projeto... 3 Figura 2 Pilha de Software Android [1] Figura 3 Ciclo de vida de uma Activity [3] Figura 4 Representação Abstrata da Arquitetura da MobFr Figura 5 Diagrama de classes DiscoveryManagerService Figura 6- Classes AdvertiseMessage e CooperativeDevice Figura 7 DiscoveryFrameworkMessage_Request Figura 8- DiscoveryFrameworkMessage_Answer Figura 9 Diagrama de Sequência Envio de Broadcast Figura 10 Fluxograma demonstrativo do processo de receção e tratamento de pacotes na classe DiscoveryServer Figura 11 Diagrama de Sequência Processamento de pedidos internos ao módulo Discovery Manager Figura 12 Multicast Figura 13 Obtenção do nível de bateria do dispositivo Figura 14 Diagrama de classes Package Manager Service e respetivas Threads Figura 15 Diagrama de Classes TransferSession Figura 16 Diagrama de Classes DeploySession Figura 17 Diagrama de Sequência Transferência de pacote APK Figura 18 Diagrama de Sequência Instalação remota de pacotes APK Figura 19 Diagrama de Classes Execution Manager Figura 20 Classe InternalExecutionMessage_Request Figura 21 Classe InternalExecutionMessage_Answer ix

10 Figura 22 - Diagrama de Sequência Pedido de execução de Aplicação num dispositivo remoto Figura 23 Confirmação de instalação em Android [5] Figura 24 Aspeto gráfico da aplicação de demonstração Figura 25 Diagrama de classes da MainApp Figura 26 Diagrama de Classes MobileClass Figura 27 Classe PackageMessage_RequestTransfer Figura 28 Classe JarTransferSession Figura 29 Mensagens de Pedidos para Execução Remota Figura 30 Mensagens de resposta a pedidos de execução remota Figura 31 Classes de Mensagens de Execução Remota (Execution Manager) Figura 32 Sequência de eventos para a execução remota de uma classe Figura 33 Relação das classes da Offloading Framework com a das MobFr Figura 34 Classe OffloadableServiceAbstraction Figura 35 Diagrama Sequência do método update da classe OffloadableServiceAbstraction.. 68 Figura 36 Classe CommunicationManager Figura 37 Classe OffloadingManager Figura 38 Classe DeviceManager Figura 39 Gráfico demonstrativo do tempo em milissegundos que demora a renderizar um objeto para um determinado número de objetos já renderizados [8] Figura 40 Tiled Map Editor Figura 41 Representação gráfica da personagem controlada pelo jogador (Atirador) Figura 42 Mira do Atirador Figura 43 Torres de Dano Figura 44 - Torres de Desaceleração x

11 Figura 45 Espaço para construção de torres Figura 46 Inimigo Figura 47 - Nexus Figura 48 Diagrama de Casos de Uso Figura 49 Diagrama de Classes- Entity e respectivas subclasses [10] Figura 50 Diferentes fases da animação do atirador Figura 51 Diferentes fases da animação do inimigo Figura 52 Funcionamento das Pool s Figura 53 Diagrama de Classe Classes representativas das balas de torre Figura 54 SplashScene Figura 55 - MenuScene Figura 56 - PauseScene Figura 57 - GameOverScene Figura 58 Classe MainActivity Figura 59 Diagrama de classes Engine e Respectivas Subclasses Figura 60 Diagrama de Classes Classes MapWorld e Coordinate Figura 61 Exemplo de transposição de obstáculo por excesso de granularidade Figura 62 Opções de movimento para o inimigo Figura 63 Gráfico demonstrativo do tempo médio que cada ciclo demora a ser processado em função do número de inimigos em cena Figura 64 Diagrama de classe Implementação da classe abstracta OffloadableServiceAbstraction Figura 65 Gráfico demonstrativo do tempo de execução de cada ciclo da GameScene Figura 66 - Gráfico demonstrativo do tempo médio de execução de cada dez ciclos da GameScene xi

12 Figura 67 Gráfico demonstrativo da reta de regressão linear calculada a partir do valor das últimas 20 médias obtidas Figura 68 Processo de aparecimento de inimigos, a serem processados localmente, na cena de jogo Figura 69 Classes a ser encapsuladas dentro do ficheiro JAR a ser enviado Figura 70 Classe InfoMessage Figura 71 Envio de InfoMessage para dispositivo remoto Figura 72 Obtenção da próxima coordenada através do Buffer do Socket Figura 73 Gráfico representativo do tempo em milissegundos que cada iteração demorou Figura 74 Gráfico representativo do tempo em milissegundos que cada iteração demorou Figura 75 Resultados Experiência Figura 76 - Resultados Experiência Figura 77 - Experiências 1 e 2 combinadas Figura 78 - Resultados Experiência Figura 79 - Resultados Experiência Figura 80- Experiências 1 e 2 combinadas Figura 81 Tempos de ciclo expectáveis Figura 82 Tempos de Processamento Local Antes e Após Início do processo de Oflloading 124 xii

13 Índice de Excertos de Código Excerto de Código 1 Exemplo de um Android Manifest Excerto de Código 2 Iniciação de uma Activity usando um Intent Excerto de Código 3 Registo de um BroadcastReceiver no Android Manifest Excerto de Código 4 Método Construtor da classe PublishDevice Excerto de Código 5 Método run() da classe PublishDevice Excerto de Código 6 Método createadvertisemessage() da classe AdvertiseMessage Excerto de Código 7 Método cleanmap() da classe DiscoveryServer Excerto de Código 8 - Criação de Socket para Receção de Multicasts Excerto de Código 9 Obtenção do nível de bateria do dispositivo Excerto de Código 10 Método getneighbors() Excerto de Código 11 Instalação/Desinstalação de pacotes APK através de Intent Excerto de Código 12 Criação dos separadores e atribuição das respetivas Atividades Excerto de Código 13 Carregamento Dinâmico de uma Classe Excerto de Código 14 Método Execute Excerto de Código 15 Script Ant para isolamento de uma classe num ficheiro JAR Excerto de Código 16 Processamento de um pedido remoto de execução de uma classe Excerto de Código 17 Código a executar remotamente Excerto de Código 18 Classe a exportar Excerto de Código 19 Script Ant para isolamento das classes a exportar Excerto de Código 20 Código para transferir um ficheiro JAR e executar uma classe dentro deste Excerto de Código 21 Criação e Carregamento de Textura para uma AnimatedSprite xiii

14 Excerto de Código 22 Métodos redefinidos na classe BulletPool Excerto de Código 23 Obtenção de um objeto do tipo Bullet da BulletPool Excerto de Código 24 Reciclagem de um objeto do tipo Bullet Excerto de Código 25 Métodos redefinidos da classe TowerBulletPool Excerto de Código 26 Obtenção de um objeto TowerBullet da TowerBulletPool Excerto de Código 27 Método onupdate da classe Engine Excerto de Código 28 Método onupdate redefinido pela classe LimitedFPSEngine Excerto de Código 29 - Método onupdate redefinido pela classe LimitedFPSEngine Excerto de Código 30 Método update da classe OffloadbleServiceAbstraction Excerto de Código 31 Método execute da classe RemotePathChoosing Excerto de Código 32 Método run da classe interior WorkerThread xiv

15 Índice de Tabelas Tabela 1 Vantagens e Desvantagens das diferentes bibliotecas Tabela 2 Custo, dano e tempo de intervalo entre disparos de uma torre de dano Tabela 3 - Custo, taxa de desaceleração e tempo de intervalo entre disparos de uma torre de desaceleração Tabela 4 Caso de Uso Dispara Tabela 5 Caso de Uso Constrói Torre Tabela 6 Caso de Uso Evolui Torre Tabela 7 Caso de Uso Inicia Jogo Tabela 8 Caso de Uso Interrompe Jogo Tabela 9 Caso de Uso Retoma Jogo Tabela 10 Caso de Uso Sai do jogo Tabela 11- Caso de Uso Move o atirador Tabela 12 Especificações dos dispositivos usados nos testes Tabela 13 Tempos para o teste de execução-apenas Tabela 14 - Tempos para o teste de transferência e execução xv

16 Notação e Glossário Termo Definição APK Ficheiro de arquivo Android API Biblioteca (Interface de Programação de Aplicações) É o conjunto de funções fornecidas por um dado software ou bibliotecas para que outras aplicações possam fazer uso das mesmas. Conjunto de recursos ou funções previamente desenvolvidos, usados por programadores para desenvolver software. Broadcast Modo de transmissão de pacotes em que estes são enviados para todos os dispositivos da rede. Buffer Zona de memória temporária utilizada para escrita e leitura de dados. Classe É, em linguagens de programação orientadas a objetos, uma especificação de como construir uma instância de um determinado objeto. Compilação Função de um compilador. Transforma código fonte, numa dada linguagem de programação, numa outra linguagem, como por exemplo, linguagem objeto. CPU Unidade de processamento central. xvi

17 Datagram Packet São usados, em Java, para implementar um serviço de envio de pacotes não orientado à conexão Emulador Software ou Hardware que emula um determinado sistema informático num outro de tipo diferente. Endereço IP Número de 32 (IPv4) ou de 128 (IPv6) bits que identifica um dispositivo numa rede. Ficheiros DEX São ficheiros que contêm código compilado de aplicações Android. Fila Estrutura de informação do tipo 'Primeiro a entrar, Primeiro a Sair' GPU Unidade de Processamento Gráfico Hardware Componentes físicos de um sistema computacional. IDE (Ambiente de desenvolvimento integrado) Software que providencia ao utilizador ferramentas que facilitam as tarefas de programação. Instância Uma ocorrência de uma classe previamente definida. Interface Em linguagens orientadas a objetos, o termo interface é usado para definir um tipo de objeto abstrato que, não tendo informação, define métodos a serem implementados por outras classes. xvii

18 Javadoc Memória RAM Memória de acesso aleatório. Métodos Estáticos Em linguagens orientadas a objetos, os métodos estáticos são métodos que não necessitam de uma instância da sua classe. Camada de aplicações que providencia às aplicações de software serviços para além daqueles fornecidos pelo sistema operativo. Multicast Modo de transmissão de pacotes em que estes são enviados para um conjunto, previamente definido, de dispositivos numa rede. Ferramenta que gera documentação de uma forma automática, a partir do códigofonte. Middleware Open- Source Método de distribuição de software gratuita, que possibilita o acesso ao código fonte do mesmo. Pilha Estrutura de informação do tipo 'Primeiro a entrar, ultimo a sair' Rendering Processo de gerar uma imagem a partir de um determinado modelo. Semáforo Sistema que limita o número de acessos a um determinado recurso de um programa ou sistema. Serialização Processo de conversão de um objeto ou estrutura de dados num formato que possa ser armazenado e mais tarde convertido de volta ao seu estado de origem. xviii

19 Singleton Padrão de software que restringe a instanciação de uma determinada classe a apenas um objeto. Sistema Operativo Programa que tem como função gerir o Hardware de um sistema e servir como intermediário entre este e o seu utilizador Smartphone Socket Dispositivo que funciona como telemóvel mas cujo software é implementado num sistema operativo móvel que oferece funções mais avançadas que um telemóvel tradicional. Um terminal de conexão numa comunicação em rede. Software Coleção de programas informáticos (e os seus dados) que providencia ao sistema as instruções sobre como fazer determinada tarefa. Thread Conjunto de instruções que são executadas concorrentemente ou paralelamente. URI (Identificador de Recursos Uniforme) É um conjunto de caracteres usados para identificar um determinado recurso. Vetor Estrutura de dados que contém vários dados do mesmo tipo. XML (extensible Markup Language) É uma linguagem de notação que define regras de codificação de documentos. xix

20

21 1 Introdução Neste capítulo é feita uma introdução e enquadramento do projeto, descrevendo os objetivos, fases do projeto, descrição da organização e descrição da organização do relatório. 1.1 Enquadramento Este relatório foi elaborado no âmbito da unidade curricular de Projeto/Estágio (PESTI), da Licenciatura em Engenharia Informática do Instituto Superior de Engenharia do Porto. O projeto foi realizado na unidade de investigação CISTER Centro de Investigação em Sistemas Confiáveis de Tempo Real pertencente ao Instituto Superior de Engenharia do Porto, e tinha como objetivos estudar, aperfeiçoar e documentar frameworks de mobilidade de código previamente desenvolvidas, bem como, desenvolver uma aplicação multimédia que demonstrasse as potencialidades dessas frameworks. A motivação deste projeto prende-se com o uso cada vez mais frequente de dispositivos móveis no dia-a-dia. As aplicações desenvolvidas para este tipo de dispositivos são cada vez mais complexas e exigentes a nível de recursos, sendo assim importante investigar e desenvolver formas que permitam a esses dispositivos executar aplicações com grandes necessidades de recursos, através da distribuição de parte das necessidades de computação pelos nós de um sistema distribuído. 1.2 Objetivos do Projeto No âmbito deste projeto foram delineados os seguintes objetivos: 1. Estudar as bibliotecas de mobilidade e offloading de código previamente desenvolvidas; 2. Corrigir e melhorar funcionalidades dessas bibliotecas; 3. Estudar um método de mobilidade de código mais eficiente que o previamente existente; 4. Implementar o método escolhido; 5. Desenvolver uma aplicação para prova de conceito das capacidades das bibliotecas estudadas; 6. Implementar as funcionalidades das bibliotecas à aplicação desenvolvida; 1

22 7. Escrever um relatório de modo a apresentar e descrever as tarefas desenvolvidas durante o projecto. 1.3 Planeamento do Projeto O planeamento do projeto começou a ser elaborado ainda antes do início oficial do mesmo. Isto porque, antes da data escolhida para o início dos trabalhos, houve breves reuniões com os orientadores do projeto de modo a introduzir a problemática do mesmo, bem como para delinear o plano inicial. Ficou decidido nessas reuniões que a 1ª fase, que iria corresponder ao 1º mês do projeto, serviria unicamente para estudo e documentação das bibliotecas existentes. No fim desse período foi elaborado, em conjunto com o Dr. Luís Lino Ferreira e com o Mestre Cláudio Maia, o planeamento para as restantes tarefas do projeto. As fases propostas foram as seguintes: 2ª Fase: Estudo de novas formas de efetuar mobilidade de código. Implementar a opção escolhida e efetuar testes; 3ª Fase: Discutir e planear o desenvolvimento da aplicação multimédia; 4ª Fase: Desenvolvimento da aplicação multimédia e respetivos testes; 5ª Fase: Integração da aplicação com a biblioteca de mobilidade de código e respetivos testes; 6ª Fase: Desenvolvimento do relatório final; Na Figura 1 é possível observar o diagrama de Gantt relativo à duração efetiva de cada fase. 2

23 Março Abril Maio Junho Julho Agosto Setembro Outubro 1ª Fase 2ª Fase 3ª Fase 4ª Fase 5ª Fase 6ª Fase Figura 1- Duração das diferentes fases do projeto ª Fase Estudo, documentação e melhoria das bibliotecas existentes Nesta fase foram estudadas as bibliotecas desenvolvidas para mobilidade de código em Android. A documentação das mesmas era bastante escassa (praticamente inexistente), o que exigiu que fosse atribuída a esta fase o período de 1 mês. Tendo duas bibliotecas diferentes para analisar, e sendo este projeto realizado por duas pessoas, decidiu-se que cada um ficaria responsável por uma delas: Bruno Soares Mobility Framework (MobFR); José Teixeira Offloading Framework. A documentação realizada nesta fase foi efetuada no formato Javadoc e foram escritos dois relatórios técnicos (um para cada biblioteca). As melhorias pretendidas nesta fase passavam pela resolução de bugs, adição de novas funcionalidades que se revelassem úteis à finalidade da biblioteca e limpeza de código ª Fase Estudo de novas formas de mobilidade e implementação do método escolhido. Nesta fase foi necessário estudar uma forma de melhorar a performance da biblioteca MobFr por aplicação de um novo método de mobilidade de código. Depois de decidido qual o método, foi necessário apresentar uma proposta de aplicação do mesmo aos orientadores do projeto. Para isso 3

24 foi necessário elaborar um documento que sustentasse essa escolha. Depois de implementado, foram efetuados os respetivos testes ª Fase Discutir e Planear a Aplicação Multimédia Nesta fase foi discutida a aplicação multimédia. Para isso seria necessário efetuar um estudo acerca de bibliotecas gráficas existentes para Android de modo a escolher qual seria a mais adequada à aplicação a desenvolver. Foi delegado tempo para a elaboração de várias hipóteses para o tipo de aplicação a desenvolver, de forma a serem apresentadas aos orientadores para assim ser discutida a viabilidade de cada uma ª Fase Desenvolvimento da Aplicação Multimédia Depois de delineados os detalhes da aplicação a desenvolver e de escolher qual a biblioteca gráfica a usar, iniciar-se-ia a fase de desenvolvimento. Após terminado o desenvolvimento seria necessário proceder aos respetivos testes ª Fase Aplicação da biblioteca de mobilidade de código à aplicação desenvolvida A quinta fase do projeto consistiu na integração da biblioteca de mobilidade (com as alterações efetuadas na primeira e na segunda fase do projeto) de código à aplicação desenvolvida ª Fase Desenvolvimento do relatório final Por último, foi escrito o relatório final do projeto de modo a documentar, apresentar e descrever todos os aspetos relevantes do projeto. 1.4 Reuniões de Acompanhamento Legenda: LLF: Dr. Luís Lino Ferreira CM: Mestre Cláudio Maia BS: Bruno Soares JT: José Teixeira 4

25 Data Local Intervenientes Temas Abordados // 10h30 ISEP - Edifício F Sala 115 LLF; BS; JT; Apresentação do Projeto. Delineamento das tarefas iniciais // ISEP - Edifício F LLF; CM; Discussão do estado do estudo à 18h00 Sala 115 BS; JT; MobFr e à Offload Library // ISEP - Edifício F LLF; CM; Discussão do estado do estudo à 18h20 Sala 115 BS; JT; MobFr e à Offload Library. Demonstração da aplicação de teste da MobFr ISEP - Edifício F LLF; CM; Discussão do estado do estudo à // 18h20 Sala 115 BS; JT; MobFr e à Offload Library. Discussão de alternativas às funcionalidades atuais da MobFr ISEP - Edifício F LLF; CM; Discussão de alternativas às // 18h20 Sala 115 BS; JT; funcionalidades atuais da MobFr // ISEP - Edifício F LLF; CM; Demonstração da prova de 15h00 Sala 115 BS; JT; conceito de Dynamic Class Loading // Edifício do CISTER LLF; CM; Apresentação de proposta de 17h00 Anfiteatro BS; JT; aplicação de Dynamic Class Loading na MobFr // 18h30 ISEP - Edifício F Sala 115 LLF; BS; JT; Discussão do tipo de aplicação a desenvolver para demonstração das bibliotecas de mobilidade de código e offloading Edifício do CISTER LLF; CM; Apresentação de proposta de 5

26 // 14h00 Sala de Reuniões do Primeiro Piso BS; JT; integração da MobFr com Dynamic Class Loading na aplicação desenvolvida // 14h30 Edifício do CISTER - Laboratório LLF; BS; JT; Discussão do relatório 1.5 Relatórios Semanais No âmbito deste projeto foram produzidos relatórios que, de uma forma muito simples e resumida, enumeravam as tarefas efetuadas na semana anterior e as tarefas que seriam realizadas nessa semana. Os relatórios escritos no âmbito deste projeto podem ser consultados na secção 9.1 dos anexos. 1.6 Tecnologias Utilizadas Visto que as aplicações para Android são desenvolvidas utilizando a linguagem de programação orientada a objetos Java, grande parte do trabalho envolveu a programação de código nessa linguagem. Para o desenvolvimento de aplicações Android, foi usado o Android Software Development Kit (SDK) em conjunto com o plug-in de Android para o ambiente de desenvolvimento integrado Eclipse denominado de Android Development Tools (ADT). A versão do Eclipse usada correspondeu à 3.7 (Nome de código Indigo). Foi também utilizada uma ferramenta Java denominada Ant para automatizar o processo de compilação de Software (desenvolvido em Java). Todas as outras tecnologias utilizadas serão apresentadas posteriormente neste documento, sendo que para cada uma delas será descrito a razão por detrás do uso dessa mesma tecnologia. 1.7 Apresentação da Organização O CISTER (Centro de Investigação em Sistemas Confiáveis de Tempo Real) é uma unidade de investigação sedeada no Instituto Superior de Engenharia do Porto pertencente ao Instituto Politécnico do Porto. 6

27 O CISTER foi, no processo de avaliação de 2004, a única unidade de investigação em Portugal, nas áreas da Engenharia Eletrotécnica e de Engenharia Informática, a ser premiada com o nível de Excelente. Esta classificação foi confirmada no último processo de avaliação (2007), onde apenas outra unidade de investigação da mesma área teve a mesma classificação. Desde que foi criado esta unidade cresceu para se tornar uma das Unidades de Investigação líderes no panorama Europeu, contribuindo com trabalhos de investigação em seminários, num conjunto de áreas, tais como: Redes de comunicação em tempo real e protocolos. Redes de sensores wireless. Paradigmas de programação em tempo-real e sistemas operativos. Sistemas de tempo real embutidos distribuídos. Computação cooperativa e aplicações QoS-Aware. Escalonamento e análise de escalonabilidade. Sistemas Ciber-Fisícos (CPS). Atualmente, a unidade de investigação CISTER é um membro ativo em vários projetos de redes internacionais de excelência, estando também envolvida em vários projetos, internacionais e nacionais, de investigação e desenvolvimento. 1.8 Organização do Relatório O relatório divide-se, para além do capítulo introdutório, em cinco capítulos. No capítulo 2 é contextualizado o projeto introduzindo o leitor à tecnologia Android. No capítulo 3 é descrito o resultado do estudo à MobFr bem como as adições de funcionalidades feitas à mesma. O capítulo 4 é descrito o resultado do estudo à Offload Library. No capítulo 5 é descrito o desenvolvimento do jogo, integração do mesmo com as bibliotecas de mobilidade de código e o resultado final. No capítulo 6 estão expostas as conclusões do projeto. 7

28

29 2 Android O Android é um sistema operativo de código aberto que inclui uma camada middleware e um conjunto de aplicações móveis fundamentais juntamente com um conjunto de bibliotecas e interfaces para o desenvolvimento de aplicações móveis [1]. 2.1 Pilha de Software Android A pilha de software Android é composta pelos elementos presentes na Figura 2. As cinco camadas constituintes são [1]: Linux Kernel - Os serviços principais (incluindo controladores de Hardware, gestão de memória, processos, energia, rede e segurança) são controlados por um kernel Linux 2.6. Libraries O Android possui várias bibliotecas em C e C++ tais como: o Uma biblioteca multimédia para a reprodução de áudio e vídeo; o Librarias Gráficas; o SQLite para suporte de uma base de dados. Android Run-time Inclui bibliotecas e a Dalvik VM (Virtual Machine). É o motor que suporta as aplicações e, juntamente com as bibliotecas, suporta a Application Framework. Application Framework A Application Framework providencia as classes usadas para criar aplicações Android. Providencia também uma abstração genérica para acesso ao Hardware e gere a interface gráfica e os recursos das aplicações. Application Layer Todas as aplicações, na Application Layer, são compiladas usando as mesmas bibliotecas. A camada de aplicações é executada dentro do Android Run-time, usando classes e serviços quer das restantes aplicações, quer das camadas abaixo. 9

30 Figura 2 Pilha de Software Android [1] 2.2 Desenvolvimento em Android O Android SDK (Software Development Kit) possui todas as ferramentas e todas as API s necessárias para desenvolver aplicações para Android [1]. O plug-in para Eclipse denominado ADT (Android Development Tools) permite a integração de várias ferramentas de desenvolvimento Android no referido IDE. Essas ferramentas incluem, por exemplo, um emulador de dispositivo Android, um sistema de registo de eventos denominado logcat, entre outros. 10

31 O logcat é o sistema de registo de eventos das aplicações Android, providenciando um mecanismo de recolha e visualização do output da depuração das mesmas. [2] Android Manifest Qualquer projeto de aplicação Android inclui um ficheiro XML denominado AndroidManifest.xml, armazenado na raíz do projeto. Este ficheiro permite definir a estrutura, os componentes e as permissões das aplicações e inclui todos os componentes da aplicação. No Excerto de Código 1 é possível observar em exemplo de um ficheiro Android Manifest. <?xml version="1.0" encoding="utf-8"?> <manifest xmlns:android=" package="pt.ipp.isep.cister.scenestest" android:versioncode="1" android:versionname="1.0" > <uses-sdk android:minsdkversion="8" android:targetsdkversion="8" /> <application android:icon="@drawable/ic_launcher" android:label="@string/app_name" > <activity android:name=".mainactivity" android:label="@string/app_name" android:theme="@style/theme.nobackground" > <intent-filter> <action android:name="android.intent.action.main" /> <category android:name="android.intent.category.launcher" /> </intent-filter> </activity> </application> </manifest> Excerto de Código 1 Exemplo de um Android Manifest Componentes de uma Aplicação Android Activity Uma Activity é um dos componentes mais importantes de uma aplicação Android. É uma classe que define o que irá ser mostrado ao utilizador e trata da interação entre este e a aplicação. É necessário haver sempre uma Activity principal, declarada no ficheiro Android Manifest, que será iniciada e apresentada juntamente com o início da aplicação. Uma Activity possui um ciclo de vida composto pelos vários estados da aplicação, cuja representação gráfica pode ser observada 11

32 na Figura 3. O programador pode definir as ações que devem ser executadas pela aplicação no início de cada um dos estados, usando os métodos da classe Activity. Figura 3 Ciclo de vida de uma Activity [3] Service: Um Service é utilizado para realizar operações de longa duração em segundo plano sem mostrar nenhuma interface ao utilizador. Uma aplicação pode iniciar um Service e este fica a executar mesmo que o utilizador não esteja a interagir com a aplicação. Intent: Um Intent é utilizado na comunicação entre Activities, Services e Broadcast Receivers. É uma mensagem enviada para o sistema operativo para realizar alguma acção, como por exemplo, 12

33 iniciar uma Activity. Os Intents facilitam a comunicação entre os vários elementos da aplicação, ou até entre aplicações distintas. É possível enviar e receber dados através de um Intent, como tipos primitivos ou objetos serializados. No Excerto de Código 2 é exemplificada a criação de um Intent para inicializar uma Activity e, através do método putextra, colocado no mesmo duas variáveis do tipo boolean e inteiro que estarão, assim, disponíveis na Activity criada. boolean b = true; int i = 12; Intent it = new Intent(this, SomeClass.class); it.putextra("somebool", b); it.putextra("someint", i); startactivity(it); Excerto de Código 2 Iniciação de uma Activity usando um Intent BroadcastReceiver: Um BroadcastReceiver é usado para permitir que a aplicação fique à escuta de Intents iniciados por qualquer aplicação ou pelo próprio sistema operativo Android. Para isso é necessário que estes sejam registados no Android Manifest da aplicação, como pode ser observado no Excerto de Código 3, que regista um BroadcastReceiver com o nome.init e com um filtro de Intent de nome pt.ipp.isep.cister.package_service e categoria android.intent.category.home. Um filtro de Intent tem como objetivo filtrar o tipo de intents que o BroadcastReceiver irá estar à escuta. <receiver android:name=".init" > <intent-filter> <action android:name="pt.ipp.isep.cister.package_service" /> <category android:name="android.intent.category.home" /> </intent-filter> </receiver> Excerto de Código 3 Registo de um BroadcastReceiver no Android Manifest 13

34

35 3 Mobilidade de Código A mobilidade de código é a capacidade de mover partes de código de uma máquina para outra fazendo com que essas partes possam ser instaladas em tempo de execução. 3.1 Mobility Framework (MobFr) A Mobility Framework (MobFr) é uma biblioteca desenvolvida pelo CISTER, que tem como objetivo fornecer aos programadores as funções necessárias para o suporte de sistemas distribuídos em ambiente Android, fazendo uso do elevado dinamismo que a mobilidade de código oferece. Em Android, as aplicações estão contidas em ficheiros APK que por sua vez são instalados num dado dispositivo. No entanto, as funcionalidades providenciadas por essas aplicações apenas estão disponíveis nesse dispositivo. Com a MobFr este conceito é estendido para um ambiente distribuído, onde as aplicações podem usar Activities e Services de APKs independentemente se estes estão instalados no dispositivo local ou num remoto [4]. Visto que um dos objetivos deste projeto era o aperfeiçoamento e aplicação das bibliotecas existentes, impunha-se que fosse, inicialmente, efetuado um estudo das mesmas. Como a documentação era bastante escassa, esse estudo baseou-se quase unicamente na análise de código. Nesta secção são descritos os resultados do estudo efetuado à MobFr, explicando primeiramente a sua arquitetura e os detalhes de implementação. De seguida, para cada módulo, é feita uma avaliação ao tipo de implementação indicando quais os pontos onde esses módulos poderiam ser melhorados. Por último, serão apresentadas os melhoramentos efetuados pelos autores deste relatório aos módulos descritos Arquitetura De acordo com a Figura 4, a MobFr é implementada na camada de aplicações. Esta camada é a mais apropriada no que se refere à implementação de novos componentes de software, já que não implica nenhuma alteração ao sistema operativo Android. Como tal, a instalação da MobFr 15

36 equivale à instalação de uma aplicação normal e, como é implementada como um Service, as suas funcionalidades são acessíveis a todas as aplicações instaladas no dispositivo [4]. Na Figura 4 é também possível observar que o núcleo (core) da MobFr é constituído por três módulos: o Discovery Manager, o Package Manager e o Execution Manager. Figura 4 Representação Abstrata da Arquitetura da MobFr Em adição aos três módulos existentes no núcleo, existe também um módulo denominado Mobile Library que serve como módulo intermédio entre o programador e as funcionalidades da MobFr, abstraindo assim do programador os pormenores de implementação da MobFr Discovery Manager O módulo Discovery Manager serve para procurar dispositivos remotos na rede e para propagar pela rede informações sobre os recursos disponíveis no dispositivo local. Para isso cada dispositivo na rede, periodicamente, em broadcast, propaga informações sobre o seu estado (recursos disponíveis) e serviços instalados (pacotes APK instalados e os Intents a eles associados) [4]. 16

37 Para isso o módulo Discovery Manager Framework divide-se em três tarefas principais: Anunciar o dispositivo local aos demais dispositivos da rede; Receber anúncios de dispositivos remotos, mantendo um registo dos dispositivos ativos; Receber pedidos internos do dispositivo, solicitando a lista de dispositivos activos Classes O Discovery Manager é executado como um service que possui três threads (contidas, cada uma, em classes diferentes). São estas que são responsáveis pelas tarefas enumeradas na Secção Na Figura 5 é representado um diagrama de classes contendo esse serviço (DiscoveryManagerService) bem como as 3 classes que contêm as referidas threads. Figura 5 Diagrama de classes DiscoveryManagerService As três classes que representam as threads contidas no service DiscoveryManagerService são: PublishDevice Esta classe possui uma thread que, em períodos pré-definidos de tempo, transmite em broadcast informações sobre o dispositivo local. Essas informações vão encapsuladas numa instância da classe denominada CooperativeDevice. Esta classe representa informação relativa a um dispositivo e contém informações tais como o seu 17

38 nome, o estado da bateria, os pacotes APK instalados e o seu endereço IP. Toda essa informação é depois encapsulada numa instância da classe denominada AdvertiseMessage, que contém um número de identificação único que serve para a distinguir das demais mensagens. Na Figura 6, é possível observar uma representação das classes CooperativeDevice e AdverstiseMessage. Figura 6- Classes AdvertiseMessage e CooperativeDevice DiscoveryServer - Esta classe possui uma thread que é responsável por receber as mensagens sob forma de AdvertiseMessage transmitidas pela classe PublishDevice de dispositivos remotos. Para além disso, mantém um registo dos dispositivos que estão ativos na rede 1, possuindo um mecanismo que remove os dispositivos que deixem de enviar mensagens de Advertising. RequestServer - Esta classe possui uma thread que é responsável por responder a pedidos internos do dispositivo que são enviados quando a aplicação que está a fazer uso da Discovery Framework, necessita da lista de dispositivos mantida pela classe DiscoveryServer. 1 Entende-se como dispositivos que estejam activos, os dispositivos Android com o módulo Discovery Manager instalado e que estejam a comunicar com os demais dispositivos na rede. 18

39 O service responsável pela execução do Discovery Framework é iniciado usando um broadcast de Android. Para que uma determinada aplicação faça uso da Discovery Framework, esta necessita de enviar um DatagramPacket, contendo uma instância da classe DiscoveryFrameworkMessage_Request, para o porto definido como sendo o porto de receção de pedidos internos da Discovery Framework. Na Figura 7, pode-se ver uma representação da classe DiscoveryFrameworkMessage_Request. Figura 7 DiscoveryFrameworkMessage_Request Como pode ser visto na Figura 7, a classe DiscoveryFrameworkMessage_Request tem como única variável um número inteiro que indica qual o porto para a qual o pedido deve ser respondido. Depois de enviado, o pedido vai ser recebido e processado pela thread associada à classe RequestServer. Caso o pedido seja recebido e processado com êxito, a thread enviará de volta, para o porto especificado na instância de DiscoveryFrameworkMessage_Request, uma instância de DiscoveryFrameworkManager_Answer. Figura 8- DiscoveryFrameworkMessage_Answer Como pode ser visto na Figura 8, a classe DiscoveryFrameworkManager_Answer contem uma variável, denominada answer, que é um vetor composto por instâncias de CooperativeDevice serializadas. Essas instâncias representam todos os dispositivos atualmente ativos na rede. 19

40 Implementação Envio de broadcasts Como explicado anteriormente, o envio de broadcasts é da responsabilidade da classe PublishDevice. O período no qual é enviado o broadcast com as informações de dispositivo é definido aquando da instanciação da classe PublishDevice, como pode ser visto no Excerto de Código 4. Caso o número de segundos definidos como sendo o período entre broadcasts não seja positivo, é atribuído um valor por defeito de 15000ms. public PublishDevice(int period) { if (period < 0) _period = 15 * 1000; // 15 seconds else _period = period; } Excerto de Código 4 Método Construtor da classe PublishDevice No Excerto de Código 5 é representada uma abstração do método run() da classe PublishDevice. Dentro desse método está contido um ciclo infinito que, em cada iteração, começará por parar a thread por um tempo igual ao definido no construtor da classe (ver Excerto de Código 4). De seguida, para além da criação do socket para o envio da mensagem de anúncio de dispositivo, procede à instanciação de uma classe AdvertiseMessage invocando o método estático createadvertisemessage da mesma classe (Excerto de Código 6). Por último, é enviada através do socket aberto anteriormente a instância de AdvertiseMessage acabada de criar. Na Figura 9 é possível observar um diagrama de sequência que demonstra como decorre o processo de envio de broadcasts para os demais dispositivos da rede. 20

41 public void run() { while (true) { try { sleep(_period); } catch (InterruptedException e) { } try { // Cria o socket para envio de broadcast DatagramSocket socket = new DatagramSocket(0); socket.setbroadcast(true); // Obtém um número aleatório que servirá como número de identificação da mensagem a enviar Random rand = new Random(System.currentTimeMillis()); long sid = rand.nextlong(); sid = (sid > 0)? sid : sid * -1; // Obtém uma instância de AdvertiseMessage byte[] message_in_bytes = AdvertiseMessage.createAdvertiseMessage(sid) // Cria e envia um DatagramPacket contendo a AdvertiseMessage criada anteriormente if (message_in_bytes!= null) { // Envio de DatagramPacket } } // Tratamento de Excepções } } Excerto de Código 5 Método run() da classe PublishDevice. public static byte[] createadvertisemessage(long sessionid) { byte[] result = null; byte[] content = null; //Obtenção de dados do dispositivo local try { content = CooperativeDevice.getSelf(getComponentsList()); //getcomponentslist() obtém todos os pacotes apk instalados no dispositivo local } catch (IOException e) { } //Converte os diferentes valores em byte e agrega no array result if (content!= null) { result = new byte[13 + content.length]; result[0] = 1; ByteUtils.longToBytes(sessionID, result, OFFSET_SID); ByteUtils.intToBytes(content.length, result, OFFSET_CONTENT_LEN); ByteUtils.copyBytesToArray(content, 0, content.length, result, OFFSET_CONTENT_DATA); } return result; } Excerto de Código 6 Método createadvertisemessage() da classe AdvertiseMessage. 21

42 Figura 9 Diagrama de Sequência Envio de Broadcast 22

43 Receção e Processamento de Broadcasts É responsabilidade da classe DiscoveryServer receber todas as mensagens de anúncio de dispositivo enviadas em broadcast pela classe PublishDevice dos dispositivos remotos. Para isso o método run() da classe DiscoveryServer está constantemente à escuta de pacotes enviados para um objeto do tipo ServerSocket criado no seu método construtor. Figura 10 Fluxograma demonstrativo do processo de receção e tratamento de pacotes na classe DiscoveryServer 23

44 A Figura 10 representa um fluxograma demonstrativo do processo de receção e tratamento de pacotes recebidos no ServerSocket referido. Ao receber um novo pacote é chamado o método castbytestoadvertisemessage(byte[] receivedmessage) 2 da classe AdvertiseMessage de forma a extrair a instância de AdvertiseMessage contida no pacote. Após a extração é analisada a instância de CooperativeDevice contida na instância de AdvertiseMessage recebida e, caso esta seja válida inicia-se o processo de adição do dispositivo remoto (representado pela instância de CooperativeDevice) ao mapa de dispositivos remotos (representado pelo objeto do tipo Map ENVIRONMENT_DEVICES). Antes de se iniciar a adição do dispositivo ao mapa é, primeiramente, chamado o método acquire() do objeto do tipo Semaphore associado à classe DiscoveryServer. No caso de o semáforo estar livre, é de seguida avaliado o valor da variável do tipo long denominada NEXT_TIME_OUT. Esta variável guarda o valor em milissegundos em que se tornará necessário proceder a uma atualização dos valores do mapa de dispositivos. Caso esta tenha o valor de -1, valor que lhe é atribuída aquando da sua criação, é de imediato adicionado o dispositivo associado ao pacote recebido à variável ENVIRONMENT_DEVICES. No entanto, caso esta tenha um valor diferente de -1, significa que não é a primeira vez que está a ser processado um pacote. Sendo esse o caso, é feita uma nova avaliação para testar se o valor do tempo atual do sistema é maior do que o valor da variável NEXT_TIME_OUT. Se for o caso, significa que é necessário proceder a uma renovação do mapa que contém os dispositivos remotos. Para isso, é chamado o método local cleanmap(), o qual pode ser observado no Excerto de Código 7. Este método é chamado de forma a apagar do mapa de dispositivos remotos, aqueles cujo anúncio foi recebido há mais de x milissegundos, sendo que o x é o valor definido pela variável TIME_OUT_DELAY. 2 Este método recebe como parâmetro um vector de bytes e tenta extrair e devolver deste uma instância de AdvertiseMessage. 24

45 private static void cleanmap() { long nexttimeout = -1; Set<Long> set = ENVIRONMENT_DEVICES.keySet(); Iterator<Long> it = set.iterator(); // Lista de chaves correspondentes aos valores a descartar do mapa. List<Long> cleankeys = new ArrayList<Long>(); while (it.hasnext()) { long currenttime = System.currentTimeMillis(); try { long currentkey = it.next(); //Caso o valor de tempo no qual este dispositivo foi adicionado a somar com o que foi definido como o TIME_OUT_DELAY seja menor que o tempo actual, significa que a informação já está desactualizada, pelo que adicionamos a chave em questão à lista de valores a descartar. if (currentkey + TIME_OUT_DELAY <= currenttime) { cleankeys.add(currentkey); } else { // Apenas entra aqui uma vez: na primeira vez que for avaliado uma entrada de ENVIRONMENT_DEVICES que não esteja desactualizado. Aqui é definido pela primeira vez o valor de nexttimeout. if (nexttimeout == -1) nexttimeout = currentkey + TIME_OUT_DELAY; // Caso seja encontrado um valor mais baixo para o nexttimeout, atribui-se... else { nexttimeout = currentkey + TIME_OUT_DELAY <= nexttimeout? currentkey + TIME_OUT_DELAY : nexttimeout; } } } catch (Exception e) { } } //Novo valor para NEXT_TIME_OUT... NEXT_TIME_OUT = nexttimeout; //Elimina valores desactualizados for (Long key : cleankeys) { ENVIRONMENT_DEVICES.remove(key); } } Excerto de Código 7 Método cleanmap() da classe DiscoveryServer Depois de executado o método cleanmap() é adicionado à variável ENVIRONMENT_DEVICES o dispositivo associado ao pacote recebido. Em qualquer dos casos, sempre que é adicionado um novo dispositivo é atualizado o valor da variável 25

46 NEXT_TIME_OUT para o resultado da soma do tempo atual do sistema (em ms) com o valor da variável constante denominada TIME_OUT_DELAY Processamento de pedidos internos Sempre que uma aplicação necessite de ter acesso à lista de dispositivos atualmente na rede é necessário que esta envie um pedido interno ao módulo Discovery Manager, sendo que, é responsabilidade da classe RequestServer receber e processar esses mesmos pedidos. Para isso, a classe RequestServer está constantemente à escuta de novos pedidos do dispositivo local. Ao receber um novo pedido, ela cria uma nova thread responsável por aceder ao mesmo. É depois evocado o método estático getneighbors() da classe DiscoveryServer que devolve um vetor de instâncias de CooperativeDevice, representando os dispositivos atualmente ativos na rede. Na Figura 11 é possível observar o diagrama de sequência que mostra a troca de mensagens entre as diferentes classes, aquando de um pedido interno ao módulo Discovery Manager. Figura 11 Diagrama de Sequência Processamento de pedidos internos ao módulo Discovery Manager 26