gerenciamento de byod.pdf

UNIVERSIDADE FEDERAL DO RIO GRANDE DO SULINSTITUTO DE INFORMTICA

CINCIA DA COMPUTAO

PAULO VITOR SILVESTRIN

Sistema para gerenciamento de DispositivosMveis baseado em Android

Trabalho de Graduao.

Prof. Dr. Alexandre CarissimiOrientador

Porto Alegre, Novembro de 2013

CIP CATALOGAO NA PUBLICAO

Silvestrin, Paulo Vitor

Sistema para gerenciamento de Dispositivos Mveis baseadoem Android / Paulo Vitor Silvestrin. Porto Alegre: Graduaoem Cincia da Computao da UFRGS, 2013.

67 f.: il.

Trabalho de Concluso (bacharelado) Universidade Federaldo Rio Grande do Sul. Cincia da Computao, Porto Alegre,BRRS, 2013. Orientador: Alexandre Carissimi.

1. MDM. 2. Mobile Device Management. 3. Android. 4. AppEngine. 5. Google Cloud Message. 6. Gerenciamento. 7. Dispo-sitivos Mveis. I. Carissimi, Alexandre. II. Ttulo.

UNIVERSIDADE FEDERAL DO RIO GRANDE DO SULReitor: Prof. Carlos Alexandre NettoVice-Reitor: Prof. Rui Vicente OppermannPr-Reitora de Graduao: Profa. Valquiria Link BassaniDiretor do Instituto de Informtica: Prof. Lus da Cunha LambCoordenador do curso: Prof. Raul Fernando WeberBibliotecria-chefe do Instituto de Informtica: Beatriz Regina Bastos Haro

AGRADECIMENTOS

Agradeo ao professores e funcionrios do Instituto de Informtica da UFRGS porproporcionarem este curso de Cincia da Computao de alta qualidade. Agradeo prin-cipalmente ao professores Alexandre Carissimi, por todo acompanhamento durante estetrabalho de concluso, e ao Valter Roesler, pela oportunidade de trabalhar no seu grupode pesquisa por mais de 2 anos.

Agradeo a minha famlia, principalmente meu pai e minha me, por terem disponi-bilizado toda a estrutura necessria para que eu pudesse me dedicar inteiramente gradu-ao.

Aos colegas de faculdade e aos amigos pelos os momentos de diverso deixando estajornada muito mais fcil.

A minha querida namorada pela compreenso nos finais de semana e noites onde osestudos e trabalho tiveram que ser prioridade.

SUMRIO

LISTA DE ABREVIATURAS E SIGLAS . . . . . . . . . . . . . . . . . . . . 6

LISTA DE FIGURAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

LISTA DE TABELAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

RESUMO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

RESUMO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1 INTRODUO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131.1 Objetivos do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131.2 Organizao do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2 MOBILE DEVICE MANAGEMENT - MDM . . . . . . . . . . . . . . . . 152.1 Introduo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.2 Arquitetura bsica de um MDM . . . . . . . . . . . . . . . . . . . . . . 162.3 Open Mobile Alliance (OMA) . . . . . . . . . . . . . . . . . . . . . . . . 162.4 Funcionalidades de um MDM . . . . . . . . . . . . . . . . . . . . . . . . 172.4.1 Inventrio de Dispositivos . . . . . . . . . . . . . . . . . . . . . . . . . . 172.4.2 Provisonamento de Dispositivos . . . . . . . . . . . . . . . . . . . . . . 182.4.3 Gerenciamento de Aplicativos . . . . . . . . . . . . . . . . . . . . . . . 182.4.4 Monitoramento e Suporte . . . . . . . . . . . . . . . . . . . . . . . . . . 182.4.5 Segurana e Proteo de Dados . . . . . . . . . . . . . . . . . . . . . . . 182.4.6 Suporte s diferentes plataformas . . . . . . . . . . . . . . . . . . . . . . 182.5 Sistemas MDM Existentes . . . . . . . . . . . . . . . . . . . . . . . . . . 192.5.1 AirWatch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.5.2 Finberlink Maas360 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.5.3 MobileIron . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.6 Comparao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.7 Consideraes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3 DEVICES MANAGER - ESPECIFICAO . . . . . . . . . . . . . . . . 273.1 Arquitetura do Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.2 Servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.2.1 Comunicao entre servidor e Aplicao Mvel . . . . . . . . . . . . . . 293.2.2 Comunicao entre servidor e Aplicao Web . . . . . . . . . . . . . . . 293.2.3 Mensagens Push . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.3 Aplicao Mvel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.3.1 Servios para Usurio Final . . . . . . . . . . . . . . . . . . . . . . . . . 303.3.2 Servios de Controle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.4 Aplicao Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.4.1 Autenticao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.4.2 Registro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.4.3 Inventrio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.4.4 Gerncia de Aplicativos . . . . . . . . . . . . . . . . . . . . . . . . . . . 353.4.5 Configurao de Dispositivo . . . . . . . . . . . . . . . . . . . . . . . . 353.4.6 Chat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363.4.7 Localizao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363.4.8 Fluxo das Telas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363.5 Consideraes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4 IMPLEMENTAO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384.1 Arquitetura geral do Sistema . . . . . . . . . . . . . . . . . . . . . . . . 384.2 Google Cloud Messaging (GCM) . . . . . . . . . . . . . . . . . . . . . . 384.2.1 Arquitetura do GCM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.3 Servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.3.1 Google App Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.3.2 Web Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.3.3 Banco de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.3.4 Uso do GCM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444.4 Aplicao Mvel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.4.1 Servios para Usurio Final . . . . . . . . . . . . . . . . . . . . . . . . . 454.4.2 Servios de Controle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484.5 Aplicao Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504.5.1 Autenticao do Administrador e Registro de Empresa . . . . . . . . . . 514.5.2 Tela Inicial - Inventrio de Dispositivos . . . . . . . . . . . . . . . . . . 524.5.3 Tela Cadastro e Upload de Aplicaes . . . . . . . . . . . . . . . . . . . 534.5.4 Tela de Configurao do Dispositivo . . . . . . . . . . . . . . . . . . . . 534.5.5 Tela de Configuraes da Empresa . . . . . . . . . . . . . . . . . . . . . 544.6 Consideraes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

5 AVALIAO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 565.1 Avaliao de Funcionalidades . . . . . . . . . . . . . . . . . . . . . . . . 565.1.1 Provisionamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 565.1.2 Atualizao de Software . . . . . . . . . . . . . . . . . . . . . . . . . . 575.1.3 Gerenciamento de Falhas . . . . . . . . . . . . . . . . . . . . . . . . . . 585.2 Avaliao do Consumo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 605.3 Consideraes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

6 CONCLUSO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

REFERNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

LISTA DE ABREVIATURAS E SIGLAS

API Application Programming Interface

APK Android application package file

BYOD Bring Your Own Device

CDMA Code division multiple access

CPU Central process unit

ESN Electronic serial number

GCM Google Cloud Message

GPS Global Positioning System

GSM Global System for Mobile Communications

HTML HyperText Markup Language

HTTP HyperText Transfer Protocol

HTTPS HyperText Transfer Protocol Secure

IMEI International Mobile Station Equipment Identity

JSON JavaScript Object Notation

MAM Mobile Application Management

MDM Mobile Device Management

MEID Mobile equipment identifier

MEM Mobile Email Management

NoSQL Not Only Structured Query Language

RAM Random Access Memory

REST Representational State Transfer

ROM Read-only Memory

SaaS Software as a Service

SDK Software Development Kit

TI Tecnologia da Informao

TTL Time To Live

URL Uniform Resource Locator

XML Extensible Markup Language

LISTA DE FIGURAS

Figura 2.1: Console de Gerenciamento de Dispositivos do AirWatch . . . . . . . 19Figura 2.2: Tela de gerenciamento de aplicativos do AirWatch. . . . . . . . . . . 20Figura 2.3: Tela inicial do aplicativo MaaS360 para iOS. . . . . . . . . . . . . . 21Figura 2.4: Tela de detalhes do dispositivo do MaaS360. . . . . . . . . . . . . . 22Figura 2.5: Tela inicial do aplicativo MaaS360 para Android. . . . . . . . . . . . 22Figura 2.6: Tela do console de gerenciamento do MobileIron para visualizao

dos Dispositivos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23Figura 2.7: Dashboard do MobileIron para visualizao dos dispositivos. . . . . 24Figura 2.8: Tela do aplicativo iOS MobileIron de gerenciamento de aplicativos. . 24

Figura 3.1: Arquitetura do sistema Devices Manager. . . . . . . . . . . . . . . . 28Figura 3.2: Diagrama do fluxo de troca de mensagens do Sistema. . . . . . . . . 29Figura 3.3: Fluxo das telas da aplicao mvel. . . . . . . . . . . . . . . . . . . 32Figura 3.4: Fluxo das telas da aplicao web. . . . . . . . . . . . . . . . . . . . 37

Figura 4.1: Arquitetura da implementao do sistema Devices Manager . . . . . 39Figura 4.2: Arquitetura do Google Cloud Messaging (GCM, 2013). . . . . . . . 39Figura 4.3: Comunicao entre aparelhos Android e servidor atravs das funes

de Web Service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42Figura 4.4: Requisies feitas a partir da aplicao web ao servidor. . . . . . . . 42Figura 4.5: Funes do web service por onde a aplicao web busca as informa-

es que sero exibidas. . . . . . . . . . . . . . . . . . . . . . . . . 43Figura 4.6: Arquitetura do banco de dados NoSQL do sistema. . . . . . . . . . . 44Figura 4.7: Mensagens enviadas aos Dispositivos Android atravs do Google Cloud

Messaging. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45Figura 4.8: Tela para registro do dispositivo. . . . . . . . . . . . . . . . . . . . . 46Figura 4.9: Tela de Chat do aplicativo Device Manager . . . . . . . . . . . . . . 47Figura 4.10: Tabela do banco de dados onde armazenado as mensagens de chat. . 47Figura 4.11: Exemplo de como so mostradas as notificaes de chat no disposi-

tivo Android. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48Figura 4.12: Tela que mostra todos os servios que so executados pelo aplicativo

Device Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49Figura 4.13: Alertas exibidos ao usurio quando um aplicativo instalado ou re-

movido remotamente. . . . . . . . . . . . . . . . . . . . . . . . . . 50Figura 4.14: Tela de Login do Sistema Devices Manager. . . . . . . . . . . . . . 51Figura 4.15: Tela de registro de uma nova empresa no sistema Devices Manager. . 51Figura 4.16: Tela inicial do sistema. Mostra o inventrio de dispositivos. . . . . . 52Figura 4.17: Tela de gerenciamento dos aplicativos da Empresa. . . . . . . . . . . 53

Figura 4.18: Tela de detalhes de um dispositivo. . . . . . . . . . . . . . . . . . . . 54Figura 4.19: Tela com os detalhes da empresa. . . . . . . . . . . . . . . . . . . . 55

Figura 5.1: Tela de download do arquivo de instalao do aplicativo cliente. . . . 56Figura 5.2: Registro do dispositivo. . . . . . . . . . . . . . . . . . . . . . . . . . 57Figura 5.3: Instalao de aplicativo remotamente. . . . . . . . . . . . . . . . . . 57Figura 5.4: Remoo de aplicativo Remotamente. . . . . . . . . . . . . . . . . . 58Figura 5.5: Validao dos dados do status do Dispositivo. . . . . . . . . . . . . . 59Figura 5.6: Notificao de mensagem de chat, tela de chat no aplicativo Android

e Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59Figura 5.7: Consumo de memria interna e memria RAM do aplicativo Device

Manager. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60Figura 5.8: Consumo de dados do Device Manager durante 1 ms de uso. . . . . 61

LISTA DE TABELAS

Tabela 2.1: Comparao entre Desktops e Dispositivos Mveis . . . . . . . . . . 15Tabela 2.2: Grupos de Trabalho e Comits da OMA . . . . . . . . . . . . . . . . 17Tabela 2.3: Comparao entre Sistemas MDM . . . . . . . . . . . . . . . . . . . 25

Tabela 5.1: Resultados do consumo de bateria e dados do aplicativo. . . . . . . . 60

RESUMO

O uso de dispositivos mveis dentro de empresas em ambientes de trabalho vem au-mentando a cada ano. Com o aumento do poder computacional desses dispositivos, em-presas esto migrando aplicaes que antes eram apenas utilizadas em computadores demesa para aplicaes mveis. Ento, a cada dia novos smartphones e tablets chegam sempresas onde os departamentos de TI tem a necessidade de gerenciar e monitorar o usodestes aparelhos. Este trabalho consiste na especificao e implementao de um sistemapara gerenciamento de dispositivos Android. O sistema tem o objetivo de oferecer asfuncionalidades bsicas de controle do inventrio, monitoramento, instalao remota deaplicativos e chat com os dispositivos atravs de uma interface web unificada.

Palavras-chave: MDM, Mobile Device Management, Android, App Engine, GoogleCloud Message, Gerenciamento, Dispositivos Mveis.

RESUMO

A Mobile Device Management System based on Android

The use of mobile devices inside companies or work environments has growing withthe past of years. With the increase of mobile devices processing power, companies aremigrating applications that were used before only in desktops to mobile applications.Then, every day companies buy new smartphones and tablets, the IT department has thetask of manage and monitor the usage of these devices. Therefore, this paper shows thespecification and implementation of an Android device management system. This systemhas the aim of provide the basic features of inventory asset control, monitoring, installapps remotely and chat with devices through an unified web interface.

Palavras-chave: MDM, Mobile, Device, Management, Android, Google, Cloud, Mes-sage, App, Engine.

13

1 INTRODUO

Nos ltimos anos cada vez mais empresas esto adotando smartphones e tablets comodispositivos essenciais para muitas tarefas. Hoje a maior parte do uso desses dispositivos para acessar a Internet ou ler email, mas muitas empresas j esto utilizando para executarprogramas mais complexos como gesto de negcios, clientes e finanas. Ento, essesdispositivos, sendo eles da empresa ou pertencentes ao prprio funcionrio, esto muitasvezes conectados na rede interna e acessando dados importantes. Portanto, eles passarama ser um problema para os departamentos de tecnologia da informao (TI) que devem tero controle e dar segurana aos dados e equipamentos usados na empresa.

Fazer o controle, segurana e dar suporte tcnico aos dispositivos mveis um desafioque os departamentos de TI das empresas esto tendo. Os dispositivos mveis, diferentedos computadores convencionais, possuem uma grande variedade de plataformas, notem localizao fixa, o departamento de TI pode nunca ter acesso ao dispositivo fsico e,alm disso, podem facilmente ser perdidos, ou roubados, contendo dados da empresa.

Para auxiliar departamentos de TI no monitoramento e controle desses dispositivosmveis foram desenvolvidas ferramentas conhecidas como MDM (Mobile Device Mana-gement). MDMs so ferramentas que oferecem controle do inventrio dos dispositivos,monitoramento, configurao remota, entre outras funcionalidades. Por exemplo, paraa segurana dos dados disponibilizam servios de criptografia para transmisso e arma-zenamento de arquivos e emails da empresa, remoo de todos os dados da empresa deforma remota para caso de furto do dispositivo. Para a distribuio e monitoramento deaplicativos da empresa essas ferramentas oferecem servios semelhantes a Apple Store eGoogle Play, onde os aplicativos internos da empresa podem ser instalados, removidos econfigurados remotamente de forma segura e transparente.

No mercado existem vrios sistemas que oferecem recursos necessrios para o geren-ciamento dos dispositivos mveis e muitos outros servios para controle e gerenciamentodos dispositivos e aplicativos. A grande desvantagem dessas solues o seu custo ele-vado.

1.1 Objetivos do Trabalho

As empresas de pequeno e mdio porte possuem uma quantidade menor de disposi-tivos e, normalmente, nem tem a necessidade de todas as funcionalidades que os MDMstradicionais oferecem. Alm disso, o custo dessas ferramentas elevado para esse perfilde empresa.

O objetivo deste trabalho implementar uma soluo MDM orientada a solues decdigo aberto visando um sistema de baixo custo e de fcil configurao.

Para atingir o objetivo proposto, inicialmente, ser feito um estudo das funcionalida-

14

des bsicas de um sistema MDM em especial aquelas voltadas a empresas de pequenoporte. Com base nesse estudo, propor e implementar uma arquitetura MDM que atendaas necessidades da equipe de TI dessas empresas para o monitoramento e controle de suesdispositivos mveis.

1.2 Organizao do Trabalho

Este trabalho est dividido em 6 captulos, incluindo esta introduo. O capitulo 2apresenta um estudo sobre MDM, descrevendo as funcionalidades que devem estar pre-sente nesse tipo de sistema, os desafios encontrados para o desenvolvimento de um MDMe uma viso geral de algumas ferramentas disponveis no mercado. O captulo 3 apresentaa especificao de um sistema MDM chamado Devices Manager com funcionalidades b-sicas que atendem as necessidades de uma empresa de pequeno porte. Na sequencia, Ocaptulo 4 descreve como o sistema MDM proposto foi implementado, incluindo tcni-cas, frameworks e a plataforma mvel utilizada. No captulo 5 feita a avaliao dosistema implementado quanto as funcionalidades e consumo de bateria e dados. Por fim,no captulo 6, feita a concluso do trabalho e idias para trabalhos futuros.

15

2 MOBILE DEVICE MANAGEMENT - MDM

O gerenciamento de dispositivos mveis (Mobile Device Management - MDM) uma rea administrativa que vem crescendo nos ltimos anos com o aumento do uso desmartphones e tablets dentro de empresas. Esses dispositivos mveis oferecem acesso a e-mail, documentos compartilhados e aplicaes da empresa de qualquer lugar aumentandoa agilidade na realizao de tarefas. Portanto, importante o controle desses dispositivospara que no acontea perda, roubo ou mal uso causando prejuzos empresa.

Antigamente, celulares e PDAs, por serem limitados eram muitas vezes desprezadospelos departamentos de TI. Hoje em dia, os dispositivos mveis possuem um grande po-der computacional e as empresas esto vendo cada vez mais seus funcionrios acessandodados importantes atravs deles. Em vez de insistirem que seus funcionrios no utilizemseus prprios dispositivos para trabalho muitas empresas esto adotando o modelo BYOD"bring your own device". Esse modelo habilita funcionrios a usarem seu prprio dispo-sitivo tanto para fins de trabalho quanto pessoais, mas esse modelo exige gerenciamentoeficiente para garantir segurana dos dados da empresa. Portanto, as equipes de TI estosentindo a necessidade de utilizar sistemas para gerenciamento de dispositivos mveispara oferecer segurana e controle a esse patrimnio da empresa.

Os desafios encontrados no gerenciamento do dispositivos mveis so diferentes dosnormalmente encontrados pelas equipes de TI. Como mostrado na tabela 2.1 (MIKE OLI-VER, 2008), os dispositivos mveis possuem algumas limitaes comparados com apa-relhos desktop. Essas limitaes tem que ser levadas em conta na hora de planejar o usoe gerenciamento desses aparelhos.

Este captulo faz uma introduo ao ecossistema MDM descrevendo sua arquitetura,o padro open mobile alliance, funcionalidades bsicas e a anlise de trs sistemas co-merciais com uma breve comparao entre eles.

Tabela 2.1: Comparao entre Desktops e Dispositivos MveisDesktops Dispositivos Mveis

Internet Ilimitada LimitadaConectividade Garantida e confivel InstvelSuporte Tcnico Suporte Local aos Usurio Sem suporte localAcesso ao Dispositivo pelo TI fcil e assegurado no asseguradoPlataforma Usam a mesma plataforma Variedade de plataformasSegurana Segurana de um estabelecimento Perdido ou Roubado facilmente

16

2.1 Introduo

Os MDMs so softwares ou servios que lidam com a segurana, monitoramento,integrao e gerenciamento de dispositivos mveis que inclui smartphones, tablets e lap-tops, de um ambiente de trabalho. O objetivo do MDM otimizar as funcionalidades esegurana dentro da empresa e ao mesmo tempo proteger a rede corporativa. Controlandoe protegendo os dados e configuraes de todos os dispositivos mveis, os MDMs podemreduzir os custos de suporte e reduzir riscos dentro de uma empresa.

Outra rea de gerenciamento que est associada ao MDM MAM (Mobile Applica-tion Management). Os MAMs so sistemas responsveis pela autorizao e controle deacesso aplicativos desenvolvidos internamente, ou disponveis comercialmente, utiliza-dos por empresas em seus dispositivos ou em dispositivos dos funcionrios (BYOD). Ossistemas de Mobile Application Management possibilitam o departamento de TI instalaos aplicativos necessrios, controlar o acesso aos dados da empresa, remover dados im-portantes armazenados no dispositivo em caso de perda ou do funcionrio no trabalharmais na empresa (IT, 2010).

Existem ainda outras especializaes relacionadas a MDM como: Mobile ContentManagement - MCM para distribuio de documentos da empresa dentro de um ambienteseguro; Mobile e-mail Management - MEM para controlar que dispositivos podem acessaro e-mail da empresa e prevenir perda e roubo de e-mails e anexos com dados importantes.

2.2 Arquitetura bsica de um MDM

A arquitetura tipica de um MDM inclui um mdulo servidor, um cliente e um cen-tro para configurao remota. O servidor quem envia comandos de gerenciamento aodispositivo. O cliente executado no dispositivo, ele recebe e implementa os comandosenviados pelo servidor. O centro para gerenciamento remoto um console administrativoutilizado para atualizar ou configurar qualquer dispositivo. Um dos principais recursos desoftwares MDM so recursos Over-the-air (OVERAIR, 2013), que a habilidade de con-figurar remotamente um dispositivo mvel ou um grupo de dispositivos mveis; enviaraplicativos e atualizaes; bloquear ou limpar os dados do dispositivos.

Existem solues MDM nos modelos Software as a service - SaaS e on-premise.Como as tecnologias mveis esto em constante evoluo, sistemas SaaS (baseados emnuvem) so mais fceis, baratos e rpidos para a realizao de atualizaes, enquantosolues on-premise requer que a empresa tenha hardware prprio e preocupao comatualizaes e manuteno.

2.3 Open Mobile Alliance (OMA)

A Open Mobile Alliance (OMA) (OMA, 2013) uma organizao que visa regulamen-tar padres abertos para a indstria de dispositivos mveis. A OMA normatiza protocolosaplicados em qualquer tecnologia de rede celular utilizada para promover comunicaoe transferncia de dados. A aderncia as normas completamente voluntria, a OMAno tem papel mandatrio. Entre os vrios comits tcnicos da OMA est a OMA DM -(OMA Device Management) que especifica funcionalidades de gerenciamento para dis-positivos mveis. A tabela 2.2 mostra a lista dos diferentes grupos de trabalho e comitsque pertencem a OMA junto com uma breve descrio.

17

Tabela 2.2: Grupos de Trabalho e Comits da OMAComit ResponsabilidadeArchitecture Define a arquitetura geral da OMA, fiscaliza e auxilia os outros

grupos de trabalho.Communications (COM) Define os conjuntos de funcionalidades e mtodos que sero uti-

lizados como meio de comunicao entre diferentes aplicaesmveis.

Content Delivery Escreve e mantm especificaes relacionadas a tecnologiaPush.

Device Management Define protocolos de gerenciamento e mecanismos para propor-cionar um gerenciamento robusto do ciclo de vida de um dispo-sitivo.

Interoperability Identifica, especifica e mantem os processos, polticas e progra-mas de teste para garantir a interoperabilidade das especificaesda OMA.

Location Desenvolve especificaes para garantir a interoperabilidade deservios de localizao mvel.

Release and Planning Management Planeja e gerencia os releases da OMA.Requirements Identifica e especifica os casos de uso, interoperabilidade e re-

quisitos de usabilidade de servios de todos os grupos de traba-lho da OMA.

O OMA-DM, na especificao Device Management Requirements verso 1.2 (ALLI-ANCE, 2007), define um MDM como um framework que oferece as seguintes funciona-lidades:

Provisionamento: Registro e configurao do dispositivo de maneira automticano primeiro uso.

Configurao do Dispositivo: Permite a alterao de configuraes e parmetrosdo dispositivo.

Atualizao de software: Oferece um meio para atualizao e instalao de apli-cativos ou softwares do sistema.

Gerenciamento de Falhas: Reporta erros e oferece dados do status do dispositivo.

2.4 Funcionalidades de um MDM

Citar todas as funcionalidades que um sistema de MDM pode ter uma tarefa quaseimpossvel dada a gama de possibilidades existentes (MATHIAS, 2013). Nesta seoso descritas as funcionalidades bsicas que esses sistemas devem ter, segundo (PHIFER,2013), para permitir que o departamento de TI tenha a capacidade de gerenciar os dispo-sitivos.

Note que as necessidades de cada empresa no gerenciamento de seus dispositivosso diferentes. Portanto, nem todas as funcionalidades listadas aqui so essenciais paratodas empresas e nem todas so implementadas por todos os sistemas de MDM. Logo,o departamento de TI de cada empresa deve analisar as funcionalidades que precisam eento escolher o MDM que se adapte as suas necessidades.

2.4.1 Inventrio de Dispositivos

Claramente, um MDM deve manter a lista dos aparelhos a serem gerenciados. Essalista de aparelhos deve incluir alguns dados fsicos como identificao do dispositivos,

18

modelo do hardware, verso do firmware, etc. O inventrio deve permitir algum tipo declassificao, ou forma de agrupar os dispositivos. Por exemplo, um MDM pode auto-classificar os dispositivos por verso de sistema operacional, ou por modelo. O MDMdeve oferecer uma maneira de atualizao do inventrio com adio e remoo de apare-lhos. Hoje em dia muitos smartphones oferecem servios de localizao, ento o invent-rio tambm pode ter a localizao fsica dos dispositivos.

2.4.2 Provisonamento de Dispositivos

O gerenciamento de dispositivos inicia com a incluso ou autorizao do dispositivodentro do MDM. Para isso importante saber que plataformas o MDM suporta incluindosistema operacional, fabricante, modelo e verso. Por exemplo, Apple iOS, Google An-droid (e suas diferentes verses), BlackBerry OS, Microsoft Windows Phone.

Existem diferentes maneiras de instalar o agente MDM no dispositivos. Alguns dispo-sitivos j vem com sistema MDM nativo instalado (Apple iOS, BlackBerry OS). Outroso usurio do dispositivo deve visitar alguma app store ou portal do sistema MDM parafazer download do agente MDM. Outra possibilidade enviar por e-mail ou mensagemde texto instrues de download e instalao do sistema MDM no dispostivo.

2.4.3 Gerenciamento de Aplicativos

Muitos sistemas de MDM vo alm da configurao e inventrio de dispositivos. Ofe-recem ferramentas para distribuio e atualizao de aplicativos utilizados pela empresa.Existem tambm os sistemas MAM que lidam especificamente com o gerenciamento deaplicativos dentro de empresas.

2.4.4 Monitoramento e Suporte

Um sistema MDM tem um grande papel no diagnstico de problemas nos dispositivosmostrando status em tempo real de memria, bateria, processador, conexo com Internet.Alm deste monitoramento, oferece tambm a possibilidade de controle e configuraoremota do dispositivo facilitando o suporte tcnico aos usurios. O monitoramento dodispositivo tambm pode ser salvo na forma de histrico, com isso, MDMs podem ajudarna auditoria e fiscalizao do uso dos dispositivos.

2.4.5 Segurana e Proteo de Dados

Segurana um premissa muito importante em um MDM. Dispositivos mveis podemser perdidos, ou roubados, facilmente, ento o MDM deve ter recursos para proteger osdados da empresa nesses casos. Para isso, oferecem polticas de autenticao para acessoa dados e aplicativos contendo informaes sensveis da empresa e meios para removerremotamente todos os dados importantes em caso de roubo do dispositivo. Outra formade segurana bloquear aplicativos, ou recursos do aparelho, considerados inseguros pelaempresa.

Para a proteo dos dados, alguns MDM oferecem backup/restore automticos, almde tracking de dados, ou seja, manter o histrico de transferncia e modificao de ar-quivo, em caso de auditorias.

2.4.6 Suporte s diferentes plataformas

importante tambm que o sistema de MDM tenha suporte para as diversas plata-formas mveis que esto disponveis hoje no mercado como: iOS, Android, BlackBerry,

19

Windows Mobile, etc. Para empresas que adotam a cultura BYOD importante que oMDM suporte as mais variadas plataformas mveis.

2.5 Sistemas MDM Existentes

Nesta seo sero descritos alguns dos sistemas de MDM existentes no mercado. Oobjetivo fornecer uma viso das funcionalidades disponveis e o funcionamento dos si-temas MDM mais utilizados do mercado. De acordo com o Instituto Gartner, um grupo decinco empresas controla aproximadamente 60% do mercado de MDM mundial (GART-NER, 2013). Essas empresas so Good Technology, SAP, AirWatch, MobileIron e Fiber-link. Todos os sistemas encontrados so proprietrio e pagos, no foi encontrado nenhumsistema livre ou gratuito.

Desses cinco sistemas de MDM foram escolhidos o AirWatch, Fiberlink e MobileIronque so descritos nas prximas sees.

2.5.1 AirWatch

AirWatch (AIRWATCH, 2013) a empresa lder no mercado em MDM segundo aGartner (GARTNER, 2013), possui mais de 1000 funcionrios. O AirWatch Oferece todoo tipo de solues para gerenciamento envolvendo mobilidade para as plataformas An-droid, Apple iOS, BlackBerry, Mac OS, Symbian, Windows 8/RT/32, Windows Mobilee Windows Phone. A soluo de MDM inclui tambm MAM e MEM(Mobile e-mailManagement) e os valores partem de quatro dlares por dispositivo.

A soluo da AirWatch tem como argumento resolver os desafios associados a mobi-lidade oferecendo um meio simples e eficiente de visualizar e gerenciar todos os disposi-tivos a partir de um administrador central. O sistema possui um console web baseado emHTML5, que pode ser acessado a qualquer momento e lugar, onde, pode ser visualizadotodos os dispositivos registrados sendo eles da empresa, do funcionrio ou compartilhado,no importando a plataforma ou tipo do dispositivo. A figura 2.1 uma imagem do con-sole de gerenciamento. O cadastro de dispositivos simples para todas as plataformas. Ousurio deve apenas navegar para uma URL fornecida pelo administrador e, se o agenteAirWatch no estiver instalado no dispositivo, ele ser redirecionado para a respectivaloja onde pode ser realizado o download. Assim que o usurio autenticado as restriesapropriadas, aplicativos e contedo so automaticamente instalados no o dispositivo.

AirWatch tambm permite a criao de perfis de configurao que podem ser apli-cados aos dispositivos automaticamente. Os perfis podem ser associados a dispositivosconforme sua propriedade, sistema operacional, um grupo dentro da organizao, ou umusurio individual.

A ferramenta oferece gerenciamento de aplicativos, ou seja, o administrador pode vertodas as aplicaes instaladas, tanto as pblicas, quanto os aplicativos de uso interno. OAirWatch tambm permite a distribuio e controle de instalao de aplicativos internos.O administrador pode criar listas de aplicativos proibidos e lista de aplicativos obrigat-rios. A ferramenta ainda oferece um SDK para empresas que desenvolvem aplicativosprprios utilizando as funcionalidades de segurana do AirWatch. A figura 2.2 mostraa tela de gerenciamento de aplicativos. A ferramenta de MDM AirWatch sem dvidamuito completa e de fcil usabilidade. sempre a ferramenta citada em qualquer buscana Internet por MDM.

20

Figura 2.1: Console de Gerenciamento de Dispositivos do AirWatch

Figura 2.2: Tela de gerenciamento de aplicativos do AirWatch.

21

Figura 2.3: Tela inicial do aplicativo MaaS360 para iOS.

2.5.2 Finberlink Maas360

O Maas360 (FIBERLINK, 2013) tem como principal propaganda ser uma plataformana nuvem, de rpido e fcil desenvolvimento, que oferece uma viso e controle dos dispo-sitivos, aplicativos e documentos da empresa. A sua documentao diz que suporta todosos tipos e plataformas de dispositivos incluindo Kindle Fire e Symbian.

Para cadastro de dispositivo o procedimento parecido com o AirWatch, porm, almdo compartilhamento da URL, ele oferece a possibilidade de enviar um SMS com asinstrues de provisionamento.

O Maas360 tambm oferece o suporte para uma App Store da empresa que permiteo gerenciamento dos aplicativos. Ainda, disponibiliza recursos para gerenciamento decontedo(MCM). Porm este sistema no oferece uma soluo on-premise, o que podeser um problema para empresas que no esto confortvel com o modelo de coputaoem nuvem.

A figura 2.4 apresenta o controle unificado a partir do qual o administrador tem acessoa todos os detalhes do dispositivo, incluindo sua configurao. As figuras 2.3 e 2.5 mos-tram o aplicativo cliente do Maas360 para iOS e Android, respectivamente.

22

Figura 2.4: Tela de detalhes do dispositivo do MaaS360.

Figura 2.5: Tela inicial do aplicativo MaaS360 para Android.

23

Figura 2.6: Tela do console de gerenciamento do MobileIron para visualizao dos Dis-positivos.

2.5.3 MobileIron

O MobileIron (MOBILEIRON, 2013a) uma plataforma que oferece recursos paragerenciamento e segurana de dispositivos, aplicativos e documentos para empresas detodos os tamanhos. Esta soluo oferece como diferencial uma configurao fcil e rpidatanto no modelo on-premise quanto no modelo software as a service - SaaS. A soluoon-premise uma aplicao fcil de instalar que pode ser inserida na rede corporativa epronta para usar em poucas horas de trabalho(MOBILEIRON, 2013b).

Essa ferramenta oferece o gerenciamento de dispositivos como parte da plataformade gerenciamento disponibilizando servio de e-mail, compartilhamento de contedo, ge-renciamento de certificados de segurana e de identidade, e suporta todos os sistemasoperacionais modernos. O MobileIron tambm tem facilidades para empresas que ado-tam o modelo BYOD, como a disponibilidade de um portal, onde o prprio funcionriopode acessar para fazer o provisionamento do seu aparelho.

A figura 2.6 mostra a tela do console de gerenciamento onde possvel ter uma visogeral de todos os dispositivos cadastrados da empresa, permitindo tambm buscar por umusurio, bloquear ou limpar o aparelho, e outras funes. A figura 2.7 mostra grficos edados sobre os dispositivos cadastrados e sobre atividades de provisionamento. A figura2.8 um screenshot de uma tela do aplicativo iOS mostrando a interface cliente do gerentede aplicativos, nessa tela o usurio pode instalar aplicativos das empresa ou aplicativos daApp Store.

24

Figura 2.7: Dashboard do MobileIron para visualizao dos dispositivos.

Figura 2.8: Tela do aplicativo iOS MobileIron de gerenciamento de aplicativos.

25

2.6 Comparao

Os sistemas MDMs do mercado esto se tornando verdadeiros canivetes suos como suporte para inmeras funcionalidades. A tabela 2.3 fornece uma comparao entre ossistemas AirWatch, Maas360 e MobileIron quanto as funcionalidades oferecidas, plata-formas suportadas e algumas caractersticas gerais. Esta tabela foi elaborada baseada notrabalho observado em (WORLD, 2013).

Tabela 2.3: Comparao entre Sistemas MDM````````````Arquitetura

Sistema AirWatch MobileIron Maas360

On-Premisse Sim Sim NoSaaS Sim Sim Sim

hhhhhhhhhhhhhhhhhPlataformas SuportadasSistema

AirWatch MobileIron Maas360

iOS Sim Sim SimAndroid Sim Sim SimExtenses de Android Knox, Safe Knox, Safe Knox, Safe, 3LM,

HTC, LGBlackBerry Sim Sim SimAndroid Sim Sim SimWondows Phone, 7, 8 Sim Sim SimSymbian Sim Sim SimOutros Mac OS X 10.7 Amazon Kindle Fire,

e superiores Mac OS X Mac OS X, Linux

hhhhhhhhhhhhhhhhhFuncionalidades MDMSistema

AirWatch MobileIron Maas360

Proteo de Senhas Sim Sim SimRestaurar Senha Sim Sim SimLimpeza Remota Sim Sim SimLimpeza Seletiva Sim Sim SimBloqueio Remoto Sim Sim SimSymbian Sim Sim SimSetar VPN, Wi-Fi, APN,proxy-gateway settings Sim Sim SimDesabilitar WIFI Sim Sim SimDesabilitar Rede de Dados Sim Sim SimProvisionamento e RegistroAutomtico Sim Sim SimDesabilitar Cmera Sim Sim SimDesabilitar Bluetooth Sim Sim SimGerenciar Dispositivos Anexos(impressoras e scanners) Sim No No

26

2.7 Consideraes Finais

Como foi visto neste captulo, sistemas MDM so utilizados pelo departamento deTI de empresas para controle e gerenciamento dos dispositivos mveis. Esses sistemasmuitas vezes so de alto custo porm, esse custo amortizado pela reduo nos gastos daempresa com manuteno e suporte aos dispositivos e aplicativos.

Os sistemas encontrados no mercado so bastante parecidos oferecendo uma interfaceweb para o departamento de TI visualizar monitorar e configurar remotamente os dispo-sitivos, alm de muitos recursos para o gerenciamento de aplicativos. As diferenas entreeles est na forma de disponibilizar as informaes e controles aos usurio, ou seja, asinterfaces. Todos tendo bastante nfase na preocupao com a segurana dos dados daempresa.

Na pesquisa feita por sistemas MDM no foi encontrado nenhuma soluo para pe-quenas e mdias empresas, que no possuem muitos aparelhos, e portanto no necessitamde sistemas to completos. Tambm no foi encontrado nenhum sistema MDM livre, oude cdigo aberto, que pode ser um requisito para empresas que querem saber exatamenteo que o sistema est executando, como ele funciona e que tenha baixo custo. Esses fatoresmotivaram o desenvolvimento deste trabalho.

27

3 DEVICES MANAGER - ESPECIFICAO

Devices Manager um sistema que tem o objetivo de auxiliar os administradores deTI ou equipes responsveis pela tarefa de controle e manuteno e gerenciamento dos dis-positivos mveis de uma empresa. O administrador deve saber onde est o aparelho, queme como est sendo utilizado, manter os aplicativos da empresa instalados e atualizados.Essa uma tarefa bastante desgastante visto que, a cada dia, as empresas adotam maistablets e smartphones, e os usurios dos dispositivos muitas vezes no so capacitadospara deix-los pronto para serem usados.

Portanto, o sistema proposto tem como objetivo principal facilitar o gerenciamentodesses dispositivos. Esse objetivo alcanado atravs de uma interface que permite aconfigurao e monitoramento dos aparelhos de uma forma totalmente remota.

Este captulo descreve a arquitetura do sistema proposto neste trabalho e especifica ofuncionamento de cada mdulo.

3.1 Arquitetura do Sistema

O sistema de gerenciamento de dispositivo mveis, como mostrado na figura 3.1, composto por trs mdulos: servidor, aplicao mvel e aplicao web.

O servidor do sistema quem faz a comunicao com os dispositivos e a aplicaoweb. Ele recebe dados atualizados vindos dos dispositivos e envia mensagens a eles atra-vs da tecnologia Push (PUSH, 2013). A aplicao web faz uso peridico do servidor,pois requisita dados em intervalos determinados de tempo para que o usurio sempre te-nha informaes atualizadas sem precisar recarregar a pgina web. O servidor acessa umabase de dados onde ficam armazenadas as informaes atuais e histricos dos dispositivos.

A aplicao mvel quem coleta as informaes de uso do aparelho e as envia parao servidor. O objetivo dessa aplicao , sem comprometer a autonomia da bateria dodispositivo, fazer com que o servidor sempre tenha o status mais atualizado possvel dodispositivo. Alm disso, oferece um servio de chat para comunicao com os respon-sveis pela gerncia do aparelho e disponibiliza uma lista com os aplicativos da empresadando a possibilidade do usurio de instal-los quando necessrio.

A aplicao web por onde o responsvel pelo gerenciamento do dispositivos temacesso a informaes de como e onde o aparelho est sendo utilizado. Essa interface webpode ser acessada de qualquer computador com acesso a Internet. Assim, o administradorpode monitorar os dispositivo mesmo longe de seu local de trabalho.

O sistema possui dois tipos diferentes de usurios: administrador e usurio final. Oadministrador quem tem acesso a interface web e todas as suas funcionalidades de con-figurao dos dispositivos mveis sob gerncia. O administrador aquele que tem co-nhecimento sobre os aplicativos da empresa; quem deve utilizar os aparelhos e como eles

28

Figura 3.1: Arquitetura do sistema Devices Manager.

devem ser utilizados. Alm disso, o administrador deve ser capaz de responder dvidasdos usurios dos dispositivos, muitas vezes resolvendo problemas remotamente atravsdo prprio sistema de gerenciamento.

O usurio final aquele que emprega o dispositivo mvel como equipamento com-putacional para realizar suas tarefas dos dia a dia. O usurio final utiliza o sistema degerenciamento atravs de um aplicativo especfico instalado no dispositivo mvel. Ousurio final pode se comunicar com o administrador do sistema atravs do chat. Almdisso, o usurio final pode instalar ou atualizar aplicativos da empresa.

O Device Manager tambm auxilia o usurio final que est procurando um smartphoneou tablet para uso, permitindo que ele acesse o sistema como um visualizador. Como vi-sualizador o usurio final no precisa e no deve ter acesso aos recursos do administrador,ele apenas deve ter acesso ao status atual dos aparelhos para escolher algum para realizara sua tarefa.

O sistema permite o cadastro de empresa, dispositivo e administradores. O cadastro deempresa feito na primeira vez que um administrador entra no sistema. Ele deve informaro nome da empresa e criar um cdigo de registro. Feito isso a empresa est cadastrada eeste administrador est automaticamente cadastrado para esta empresa.

Os dispositivos de uma determinada empresa so cadastrados no sistema utilizandoo cdigo de registro mencionado anteriormente. O sistema tambm permite que umaempresa tenha vrios administradores que so cadastrados atravs do seu e-mail.

3.2 Servidor

O servidor por onde todas as mensagens do sistema passam. Ele tem a misso dereceber os dados e as requisies e trat-los adequadamente. A figura 3.2 mostra comoacontece o fluxo de mensagens entre o servidor e seus clientes. As prximas seesexplicam como se d a comunicao entre o servidor, a aplicao web e os dispositivosmveis.

29

Figura 3.2: Diagrama do fluxo de troca de mensagens do Sistema.

3.2.1 Comunicao entre servidor e Aplicao Mvel

A comunicao entre os dispositivos mveis e o servidor se d atravs do aplicativoespecfico instalado no aparelho, que tem a funo de tando enviar quanto receber dadosdo servidor. O aplicativo envia dados de uso atualizados ao servidor sempre que necess-rio. Nesse caso o servidor deve tratar os dados e armazen-los no banco de dados.

O dispositivo mvel recebe as mensagens sempre que o administrador, atravs daaplicao web, requisitar. As possveis mensagens so as listadas na seo 3.2.2. Essa co-municao poderia ser implementada atravs de Polling como acontece na aplicao web.Porm, como os dispositivos mveis normalmente possuem uma limitao de Internet ebateria, isso no vivel. Portanto, essa comunicao se d pela tecnologia Push, onde oservidor envia a mensagem ao cliente.

3.2.2 Comunicao entre servidor e Aplicao Web

Como ser visto na seo 3.4, o cliente web faz um uso frequente do servidor. Almde buscar a pgina web renderizada, ele faz acessos peridicos (conhecido como Pol-ling(POLLING, 2013)) para estar sempre exibindo os dados mais recentes enviados pelosdispositivos mvel sem o usurio ter que atualizar a pgina. Por exemplo, quando umdispositivo mvel liga o GPS, essa informao enviada ao servidor, e o administra-dor, estando com a aplicao web aberta, aps alguns segundos, ter essa atualizaoautomaticamente. Com isso, o administrador tem uma experincia em tempo real de mo-nitoramento de seus dispositivos. Em contrapartida, o Polling tem um grande consumode processamento do servidor e de Internet.

Para atender do modo eficiente as requisies peridicas que a aplicao web faz, oservidor deve implementar algum sistema de cache das buscas no banco de dados. Muitasdassas requisies peridicas vo retornar dados que no foram modificados, e acessar obanco de dados para atend-las seria muito ineficiente e custoso. A partir da aplicaoweb tambm so mandadas mensagens para o servidor que por sua vez deve envi-las aosdispositivos. Essas mensagens podem ser: mensagem de Chat; requisio para instalar oudesinstalar algum aplicativo; pedido por dados atualizados; habilitar ou desabilitar GPS,bluetooth, wireless.

30

3.2.3 Mensagens Push

Mensagens Push o nome dado ao tipo de comunicao via Internet onde a requisiopara uma dada transao iniciada pelo servidor e no pelo cliente como normalmenteacontece. O objetivo desta tecnologia fazer com que o cliente receba dados que sodestinados a ele sem ele ter que consultar o servidor. Mensagens, ou notificaes push, somuito utilizadas em aplicaes de e-mail, notcias, resultados de esportes, monitoramentode rede de sensores, entre outros.

Para a implementao de mensagens push em aplicaes para dispositivos mveis osfabricantes do sistema operacional, normalmente, oferecem frameworks. Por exemplo:Google Cloud Messaging para aplicaes Android, Apple Push Notification Service paraaplicaes iOS, Windows Azure para aplicaes Windows.

3.3 Aplicao Mvel

Essa a parte do sistema instalada nos dispositivos mveis como smartphones e ta-blets. A aplicao mvel tem por objetivo ser intuitiva e de fcil utilizao, onde a maioriadas suas funcionalidades so transparentes ao usurio final, ou seja, devem acontecer semque ele perceba.

A aplicao mvel pode ser divida em duas partes: uma oferece servios que permitea interao com usurio final e outra que permite interao com o servidor atravs de umasrie de servios em background.

3.3.1 Servios para Usurio Final

A parte do aplicativo mvel que permite interao com usurio oferece os seguintesservios: registro do dispositivo, chat onde o usurio final pode se comunicar diretamentecom o administrador, e uma rea que permite instalao e atualizao dos aplicativos deuso da empresa.

3.3.1.1 Registro de Dispositivo

O registro do dispositivo quando acontece o cadastro do aparelho para uma deter-minada empresa. O registro do dispositivo pode ser feito tanto pelo usurio final quantopelo administrador. O nico pr requisito para o registro ter em mos o cdigo de regis-tro. Esse cdigo aquele escolhido pelo administrador quando faz o cadastro da empresa(seo 3.4.1). um cdigo nico que deve ser utilizado para registrar todos os disposi-tivos mveis daquela empresa. Para registrar o dispositivo deve-se colocar um nome aoaparelho e o cdigo de registro de dispositivos.

A tela de registro s apresentada ao usurio final na primeira vez que executa oaplicativo, ou quando cancelado o registro do aparelho. O cancelamento do registro dodispositivo s pode ser feito pelo administrador via interface web. Dessa forma, mesmodesinstalando o aplicativo do aparelho, ele continuar registrado no sistema e ao reinstalaro aplicativo e execut-lo a tela de registro no ser apresentada. Isso se deve ao fato de ocdigo de identificao do dispositivo ficar registrado como pertencente a aquela empresa,ento ao executar o aplicativo pela primeira vez ele ir verificar se est registrado enviandoo cdigo ao servidor.

31

O cdigo nico de identificao de dispositivo pode ser o IMEI(GSMA, 2013) paradispositivos GSM e MEID(TIA, 2013a) ou ESN(TIA, 2013b) para dispositivos CDMA.Para dispositivos sem mdulo telefnico utiliza-se um cdigo de identificao fornecidopelo sistema operacional.

3.3.1.2 Chat

O servio de chat um canal de comunicao direta com a equipe de TI responsvelpelos aparelhos. Logo, quando o usurio do dispositivo estiver com algum problema como aparelho, ou dvida na utilizao de algum aplicativo, ele pode utilizar esse recurso parase comunicar com pessoal de TI da empresa.

Esse canal de comunicao pode ser visto como uma forma de registro de problemase dificuldades que os funcionrios da empresa esto tendo com o uso dos aplicativos edispositivos. As mensagens ficam salvas no sistema se tornando um histrico de proble-mas reportados. Ento, o histrico pode ser utilizados na hora de planejar o treinamentodos funcionrios dando mais nfase para as dificuldades reportadas por este sistema.

3.3.1.3 Gerenciamento de Aplicativos

O gerenciamento de aplicativos o servio que permite realizar o download e a ins-talao dos aplicativos de uso especfico da empresa, assim como list-los. Essa funcio-nalidade importante para o caso de algum funcionrio estar em campo e perceber quealguma aplicao que ele necessita no momento no est instalada no dispositivo, ou estdesatualizada. Isso pode acontecer por falha da equipe de gerncia ou por esse disposi-tivo no ser o designado para essa tarefa. Mas, com essa funcionalidade, se o dispositivoestiver com acesso a Internet, ele pode instalar a aplicao e realizar a sua tarefa.

Nesse exemplo citado, o usurio tambm poderia comunicar a equipe responsvel pelodispositivo para realizar a instalao remotamente. Porm, importante permitir que ousurio possa instalar o aplicativo, se isso for necessrio e ele for capacitado.

Esse servio deve possuir uma lista onde cada linha contm o cone, nome e tamanhodas aplicaes disponveis pela empresa, alm de um boto informando se a aplicaoest instalada ou precisa ser instalada ou atualizada. Portanto, estando o usurio comInternet disponvel, com apenas um toque na tela ele ter a sua disposio o aplicativoque ele precisa.

3.3.1.4 Fluxo das Telas

A figura 3.3 mostra o fluxo das telas que fazem parte do aplicativo mvel. O aplicativoinicia com a tela de registro, se o dispositivo ainda no estiver registrado no sistema degerenciamento. Caso contrrio o sistema inicia na tela de servios. A tela de serviosnada mais do que uma forma de navegar para a tela de chat (seo 3.3.1.2) ou tela deaplicativos (seo 3.3.1.3).

3.3.2 Servios de Controle

Os servios executados em background so o centro deste aplicativo. Esses servios,devem responder as requisies por dados atualizados (sincronizao) mesmo com o dis-positivos estando em modo idle. So esses servios que permitem o controle, localizaoe configurao remota do dispositivo.

A sincronizao significa montar um pacote com todos os dados de uso do dispositivo,de cada servio, e enviar ao servidor esse pacote. Dessa maneira, evita-se fazer vrias

32

Figura 3.3: Fluxo das telas da aplicao mvel.

conexes com o servidor para enviar pequenas quantidades de dados, minimizando ogasto de bateria e trfego de rede.

3.3.2.1 Controle

Como controle do dispositivo entende-se o administrador saber como o dispositivoest sendo utilizado. Para isso, ele deve ter acesso a dados como:

Status de GPS, rede wireless, bluetooth e Internet mvel: Esses status devemser gravados no momento que so ativados ou desativados. O status deve ser salvojunto com a data que aconteceu a mudana.

Utilizao de dados de rede: Nos dispositivos podem ter uma interface de Internetmvel, ou seja, a rede 3G ou 4G, e outras interfaces de rede como wireless. Para oadministrador do aparelho importante ter o controle desses dados de uma maneiradiferente, pois muitas vezes a quantidade de trfego permitida pela interface de In-ternet mvel limitada. A quantidade de dados enviados e recebidos pela interfacede Internet mvel e total (por todas as interfaces de rede) sero registradas e envia-das ao servidor. Os valores especficos de uso de rede de cada aplicativo, tambmser registrado, porm, ficar armazenada no dispositivo e ser enviada ao servidorapenas quando uma solicitao especifica por esses dados for recebida. O servioresponsvel pelo monitoramento do uso da rede deve fazer a leitura dos dados.

Nvel da Bateria: O nvel da bateria deve ser registrado sempre que o mesmoapresentar alguma alterao. O valor armazenado mandado para o servidor. No necessrio guardar o histrico dos dados, quando o nvel da bateria sofre algumaalterao o valor antigo pode ser descartado mesmo sem ter sido enviado. Esse dado importante para um usurio poder escolher um aparelho com bateria suficientepara realizar a sua tarefa; ou para o responsvel colocar o dispositivo para carregarquando o nvel de bateria est baixo.

Ociosidade do Dispositivo: Para detectar se o aparelho est sendo utilizado, ouocioso, deve-se checar se a tela est ligada ou desligada e se o aparelho est emmovimento atravs do sensor acelermetro. Esses so alguns dos fatores indicativosde que o aparelho est, ou no, em uso. Esse servio deve ter uma informaoprecisa e atualizada quando for solicitada uma sincronizao.

Status de CPU e memrias RAM, ROM e SD card: Informar o status atual decada um desses recursos de hardware no momento da sincronizao com o servidor.

33

Ou seja, qual a porcentagem da CPU est sendo utilizada e a quantidade de memriaocupada.

3.3.2.2 Localizao

A capacidade de facilmente detectar e oferecer dados de localizao para os aplica-tivos se tornou uma das maiores funcionalidades das plataformas mveis de hoje. Osdispositivos mveis, em sua maioria, oferecem recursos que disponibilizam a posio doaparelho e um indicativo da preciso dessa posio, tambm conhecida como qualidadeda posio.

A localizao dos aparelhos uma informao importante que o administrador deveter para o registro dos locais onde os dispositivos estiveram. Hoje, a maioria dos tabletse smarthphones vem equipados com servios de localizao utilizando GPS, antenas detelefonia e rede wireless. Para maiores detalhes sobre como funciona os servios de lo-calizao em dispositivos mveis o leitor pode buscar no trabalho de Millet & Stoud(MILETTE; STROUD, 2012).

O aplicativo mvel deve ter um servio eficiente que possibilite a localizao e rastre-amento do dispositivo. O hardware de GPS tem um grande consumo de energia, pormesse servio no poder comprometer a durabilidade da bateria. As posies coletadas,junto com data e a sua qualidade, devem ser salvas em um banco de dados local e enviadasao servidor sempre que acontecer uma sincronizao.

Em um ambiente onde encontram-se vrios dispositivos semelhantes, ou no caso deextravio de aparelho, a funo encontre-me pode facilitar o administrador a encontrar umaparelho especifico. Portanto, a aplicao tambm deve suportar essa funcionalidade que a seguinte: quando chega uma requisio encontre-me, imediatamente o dispositivodeve emitir um alerta sonoro para facilitar sua localizao.

3.3.2.3 Configurao Remota

A configurao remota dos dispositivos uma das mais importantes funcionalidadesdo sistema. Isso possibilita que o administrador d manuteno ao dispositivo sem ne-cessitar que tenha acesso fsico ao mesmo. Essa facilidade permite que, atravs de umainterface web, o administrador possa:

Instalar, atualizar e desinstalar aplicativos: Para instalar, ou atualizar um apli-cativo, o servio ir receber uma requisio contendo o URL onde possvel fazero download desse aplicativo para ento instal-lo. Isso deve acontecer em back-ground, sem o conhecimento do usurio. Para remover uma aplicao o serviorecebe uma requisio com o nome do aplicativo que o administrador deseja remo-ver.

Rede wireless: O servio deve permitir ligar e desligar a interface de rede wireless.Alm disso, quando solicitado, deve prover a lista de redes wireless disponveis efazer a conexo na rede escolhida pelo administrador.

GPS e rede mvel: Habilitar e desabilitar esses recursos quando solicitado.

34

3.4 Aplicao Web

A interface web o ambiente que permite visualizar, analisar e gerenciar todos osdispositivos registrados. atravs dela que o administrador pode monitorar e realizara configurao remota dos aparelhos. Para descrever melhor a aplicao web pode-sedividi-la nas seguintes funcionalidades: autenticao, registro, inventrio, gerncia deaplicativos, configurao, chat e localizao.

3.4.1 Autenticao

Os servios de autenticao propostos neste sistema so simples. A tela de autentica-o apresenta duas formas para o usurio entrar no sistema: para o administrador atravsde um provedor OpenId e para o usurio final atravs do cdigo de registro.

O administrador autentica-se no sistema atravs de sua conta OpenId. OpenId umpadro aberto de autenticao que permite usurio se autenticarem atravs de provedoresde identidade, alguns exemplos de provedores so Google, Yahoo e Facebook. Portanto,ao entrar na aplicao web como administrador, ele ser transferido para a pgina deautenticao do seu provedor onde ele deve permitir que o sistema Devices Managertenha acesso a alguns dados de sua conta, como nome e e-mail.

O usurio final se autentica na aplicao web atravs do cdigo de registro obtidocom o administrador. Ao se autenticas com o cdigo de registro, o usurio pode somentevisualizar o inventrio de dispositivos cadastrados no sistema. Isso atende aqueles funci-onrios que desejam localizar um aparelha para uso, ou, apenas tem uma viso geral dascondies dos dispositivos cadastrados no sistema. Nessa opo, o usurio final assumeo papel de visualizador.

3.4.2 Registro

No primeiro acesso do administrador ele deve registrar a sua empresa. Para isso, deveinformar os dados da empresa e criar o cdigo de registro que ser utilizado para registardispositivos que deseja gerenciar. Depois de informado os dados o sistema verifica se ocdigo de registro escolhido est disponvel. Em caso afirmativo, o registro da empresa confirmado, se no o administrador dever escolher outro cdigo.

O administrador tambm pode registrar outras pessoas para serem administradores.Para isso, ele deve informar o e-mail do administrador que ser convidado.

3.4.3 Inventrio

Informar o inventrio dos dispositivos cadastrados uma das funcionalidades bsicasde um sistema MDM. No sistema Devices Manager informaes sobre o inventrio soencontradas na lista de dispositivos, lista de dispositivos em espera e informaes dodispositivo.

3.4.3.1 Lista de Dispositivos

A lista de dispositivos tem por objetivo ser um dashboard para monitorao dos apa-relhos. Nela no permitido alterar configuraes do dispositivos, apenas uma forma devisualizao rpida do status atual. Os dados de cada dispositivo exibidos na lista so:

Nome do Aparelho,

Nome do responsvel,

35

Modelo do dispositivo, Nvel da bateria, Status da rede wireless, Internet mvel e GPS, Mostrar se o aparelho est em uso ou ocioso.

Alm desses dados, a interface da lista de dispositivos deve apresentar um boto encontre-me, que ao ser ativado o dispositivo, se estiver online, deve emitir algum sinal sonoro parafacilitar a localizao.

3.4.3.2 Lista de Dispositivos em Espera

A lista de dispositivos em espera importante para que o administrador tenha controledos dispositivos que esto sendo registrados. Um aparelho entra para a lista de esperano momento em que ele inserido a primeira vez no sistema. A lista exibe o nomedo usurio, modelo do aparelho e verso do sistema operacional e uma para opo paraaceitar e outra para rejeitar esse dispositivo. Com isso o administrador pode aceitar umdispositivo, assim ele passa para a lista de registrados, ou, o administrador pode rejeitar,nesse caso o dispositivo sai da lista de espera e uma notificao enviada ao aparelho.

3.4.3.3 Informaes do Dispositivo

As informaes do dispositivo disponibilizadas so: modelo e fabricante do apare-lho; modelo, fabricante e velocidade da CPU; quantidade de memria RAM e memriainterna; resoluo da tela; verso do Sistema operacional; e verso do Ncleo.

Alm disso, o nome e e-mail de quem o dispositivo est registrado tambm so infor-mados. O administrador tambm pode atribuir um nome a esse dispositivo ou ao usuriodo dispositivo.

3.4.4 Gerncia de Aplicativos

Para o gerenciamento de aplicativos o sistema oferece um cadastro e a possibilidadede instalar e remover aplicativos remotamente de um determinado dispositivo. , O cadas-tro de aplicativos da empresa possibilita adicionar e remover os arquivos de instalaodos aplicativos. Por exemplo, aquivos APK no caso de aplicativos Android. Apenas oadministrador tem permisso para isso. Esta funcionalidade importante, pois apenas osaplicativos que foram previamente adicionados podem ser instalados remotamente peloadministrador nos dispositivos. Logo, todos os aplicativos de uso da empresa devem sercadastrados e mantidos atualizados.

O sistema tambm deve disponibilizar a lista de todos os aplicativos instalados emum determinado dispositivos e um boto possibilitando que o administrador remova umdeterminado aplicativo.

3.4.5 Configurao de Dispositivo

Esse servio permite o administrador ter acesso aos detalhes de configurao e de usodo aparelho. As informaes podem ser estticas ou dinmicas. As esticas so aquelasque uma vez definidas no se alteram diante do uso do equipamento como, por exemplo,modelo e verso do sistema operacional. J as informaes dinmicas so modificadas deacordo com a utilizao do equipamento. As principais informaes fornecidas por esseservio so:

36

Status do hardware: Entre os status de hardware incluem: informao do uso ins-tantneo do processador (incluindo o nmero de processos em execuo) e memriaRAM; o nvel da bateria e se ela est ou no carregando; quantidade de espao utili-zado da memria ROM e SD card. Tambm possvel checar o status de ligado oudesligado do bluetooth, GPS, wireless e rede mvel. O sistema tambm deve per-mitir habilitar e desabilitar essas funcionalidades remotamente. Essas informaesso bastante dinmicas, portanto, a interface deve disponibilizar um boto para soli-citar informaes mais recentes. Para receber a solicitao e responder o dispositivoprecisa estar conectado Internet.

Uso de dados: A quantidade de dados enviados e recebidos pelas interfaces derede do aparelho um dos principais indicativos da forma que o dispositivo estsendo utilizado. Portanto sistema fornecer a quantidade total de bytes trafegadose a quantidade de bytes trafegados pela interface de rede mvel (pois muitas vezestem limite de trfego pago pela companhia).

3.4.6 Chat

O chat o local para a troca de mensagens entre o administrador e o usurio final.As mensagens so enviadas ao aparelho e recebidas atravs da Internet, ou seja, umamensagem enviada ser recebida no dispositivo to logo ele ficar online.

O chat pode ser utilizado pelo usurio para reportar alguma dificuldade no uso doaparelho, ou para o administrador enviar algum alerta ou dicas de uso. As mensagensenviadas e recebidas devem ser armazenadas na forma de histrico.

3.4.7 Localizao

A localizao dos aparelhos uma das principais funcionalidades do sistema, poissaber onde o dispositivo se encontra auxilia na segurana do patrimnio da empresa.

Por exemplo, com o auxilio de um mapa e um pino possvel mostras a posiomais atualizada disponvel de cada dispositivo. Ao clicar nesse pino, abre um balo comnome do usurio e modelo deste aparelho. Se o administrador clicar no balo ele irnavegar para as configuraes do dispositivo. Na rea de configuraes do dispositivo oadministrador pode ver o histrico de localizao escolhendo o intervalo de tempo. Entotodas as posies registradas dentro desse perodo so plotadas no mapa.

3.4.8 Fluxo das Telas

A figura 3.4 mostra o fluxo de telas da aplicao web do sistema Devices Manager. Aaplicao inicia com a tela de autenticao que por onde o administrador ou usurio finalentram no sistema. O administrador, ao entrar no sistema, se no possuir uma empresacadastrada, redirecionado para a tela de registro onde ele registra a sua empresa e cria ocdigo de registro para essa empresa.

A tela inicial onde se tem uma viso geral dos dispositivos. Deve mostrar a listade dispositivos, lista de dispositivos em espera e um mapa mostrando a localizao dosdispositivos. Essa tela tambm deve permitir a navegao para a tela de configurao dodispositivo, tela de cadastro de aplicativos e tela de administrao da conta.

37

Figura 3.4: Fluxo das telas da aplicao web.

A tela de configurao do dispositivo mostra o detalhes do aparelho, status de hard-ware, lista de aplicativos instalados, chat, ativar e desativar recursos remotamente e ins-talar e remover aplicativos remotamente. A tela de cadastro de aplicativos onde soadicionados e removidos os arquivos de instalao dos aplicativos da empresa. Por fim,na tela de administrao da conta possvel visualizar os dados da conta e registrar novosadministradores.

3.5 Consideraes Finais

O sistema Devices Manager especificado neste captulo tem como objetivo ser um sis-tema MDM (Mobile Device Management) que possui funcionalidades que permite moni-torar e configurar remotamente dispositivos mveis de uma empresa de pequeno e mdioporte. Alm disso, ele oferece um servio de chat muitas vezes no previsto em sistemasdesse tipo.

Os principais pontos levados em considerao na hora de especificar o sistema foi oconsumo de bateria do dispositivo e oferecer ao administrador informaes em tempo realde uso do dispositivo. Porm, para o administrador ter essas informaes em tempo realo aplicativo precisa coletar dados de uso e envi-los com frequncia e isso pode gerar umalto consumo de bateria, principalmente informaes de localizao providas pelo GPS.Portanto a implementao desse sistema, que apresentada no prximo captulo, tem odesafio de conciliar esses dois parmetros.

38

4 IMPLEMENTAO

Este capitulo apresenta a implementao do sistema Devices Manager conforme aespecificao fornecida no captulo anterior. Para sua implementao foi escolhida a pla-taforma Android, por se tratar de um sistema de cdigo aberto, com boa ferramentas edocumentao, alm de disponibilizar de maneira fcil os dados necessrio para o geren-ciamendo do dispositivo mvel.

As prximas sees explicam, em detalhes, como cada mdulo foi implementado, astecnologias utilizadas e o porqu de sua escolha. A seo 4.1 descreve da arquitetura dosistema implementado. A base da comunicao entre os mdulos que comes o sistema o Google Cloud Messaging (GCM), o qual descrito na seo 4.2. O servidor do sistema descrito na seo 4.3 onde justifica a escolha do framework App Engine do Google. Aseo 4.4 explica como foi implementado o aplicativo Android e as tcnicas utilizadaspara capturar e enviar as informaes sem um consumo excessivo de bateria. A seo 4.5mostra as tecnologias utilizadas na aplicao web para oferecer ao usurio dados dosdispositivos em tempo real. E, por fim, consideraes gerais sobre a implementao dosistema.

4.1 Arquitetura geral do Sistema

A figura 4.1 retoma a arquitetura do sistema mostrada na figura 3.1 indicando a tecno-logia utilizada em cada mdulo. A arquitetura do Devices Manager possui um servidor,um cliente e um centro de configurao remota, ou seja, a arquitetura bsica de um sistemaMDM como descrita no captulo 2.

Na implementao do sistema foi escolhido utilizar um modelo SaaS onde toda a partede servidor e banco de dados ficam hospedados nos servidores do Google permitindo sempresas clientes apenas o acesso aos servios. O cliente um aplicativo Android que im-plementa as aes enviadas pelo centro de configurao remota. O centro de configuraoremota uma interface web acessvel de qualquer navegador de Internet.

4.2 Google Cloud Messaging (GCM)

Enviar mensagens a partir de um servidor para dispositivos mveis no uma tarefafcil. Smartphones e Tablets esto sujeitos a conexes com Internet instveis, falta debateria, entre outros problemas que tornam difcil essa comunicao. Uma soluo fazercom que o aparelho, quando estiver online, envie mensagens peridicas ao servidor parachecar se possui alguma mensagem para ele. No entanto, essa soluo muito onerosaem termos de consumo de bateria e de envio de dados pela Internet para que o dispositivotenha, em tempo real, as mensagens destinadas a ele.

39

Figura 4.1: Arquitetura da implementao do sistema Devices Manager

Figura 4.2: Arquitetura do Google Cloud Messaging (GCM, 2013).

Para resolver esse problema dos desenvolvedores de aplicativos Android, o Googledisponibiliza o Cloud Messaging (GCM). Anteriormente, esse servio era provido peloCloud to Device Messaging Framework (C2DM) que foi oficialmente descontinuado emJunho de 2012.

4.2.1 Arquitetura do GCM

O GCM o servio do Google responsvel pelo envio de dados aos dispositivos An-droid. Sua documentao pode ser encontrada na pgina para desenvolvedores do An-droid (GCM, 2013). A figura 4.2, retirada da documentao oficial da ferramenta, mostraa arquitetura do sistema. Esse servio est disponvel para qualquer aparelho com sis-tema operacional Android 2.2, ou mais recente, que tenha o pacote de servios do Googleinstalado.

O Cloud Message funciona baseado em uma conexo TCP entre o servidor do GCMe o dispositivo. O servidor GCM mantm um socket TCP na porta 5228 a espera de

40

solicitaes de abertura de conexo (estado de listen). Quando o dispositivo est comacesso a Internet ele abre essa conexo TCP com o servidor. Essa conexo mantidamesmo quando o aparelho est em modo idle. O CGM possui um protocolo para enviode mensagens de maneira eficiente e altamente confivel.

Para acontecer essa comunicao so necessrias algumas credenciais de autenticaopara que o GCM reconhea o servidor, o aparelho e o aplicativo:

ID do Servidor: obtido no console da API do Google no momento em que aaplicao registrada. utilizado no processo de registro para identificar o servidorque est autorizado a enviar mensagens aos dispositivos.

ID da Aplicao: a identificao da aplicao mvel que vai receber a mensagem,ou seja, o nome do pacote da aplicao.

ID de Registro: a identificao do aparelho junto aplicao. fornecido pelosservidores do GCM. Deve ser enviado ao servidor do sistema que por sua vez vaiutilizar para enviar mensagens ao dispositivo.

A mensagem enviada ao GCM composta pelos seguintes parmetros que indicamcomo a mensagem ser tratada pelo servidor GCM:

registration id: esse parmetro o identificador do dispositivo que ir receber amensagem. Pode ser informado uma lista de dispositivos.

delay while idle: um valor booleano que quando true indica que a mensagem deveser enviada ao dispositivo apenas quando ele estiver no estado ativo.

collapse key: um identificador da mensagem. utilizado no caso em que h maisde uma mensagem a ser enviada para o mesmo dispositivo. As mensagens com omesmo valor de identificao, na fila de envio, sero colapsadas em uma s.

time to live: indica o tempo de vida da mensagem na fila de espera para envio aodestino final (dispositivo). Aceita valores de 0 segundos a 4 semanas.

data: a rea onde so inseridos os dados a serem enviados na mensagem. Podeter no mximo 4KB de tamanho.

O GCM entrega a mensagem ao dispositivo assim que ele ficar online. Caso o dispo-sitivo no fique online dentro do tempo de vida da mensagem, ela descartada.

O cliente GCM implementa a tarefa de receber mensagens do servidor GCM e asdistribui para os aplicativos instalados no dispositivo. Essa distribuio feita na formade broadcast de mensagens, no Android chamadas de Intents (DEVELOPERS, 2013a),onde o destinatrio final(aplicao) verifica se a mensagem de seu interesse atravs dacategoria do Intent. Ento, cada aplicao implementa um Broadcast Receiver (DEVE-LOPERS, 2013b) para receber as mensagens e encaminhar para mdulo do aplicativo queir trat-la.

41

4.3 Servidor

O servidor o centro do sistema. Ele deve estar sempre disponvel para receber e en-viar informaes. O servidor normalmente algo essencial para qualquer sistema, mas nocaso do Devices Manager, ele acaba ganhando uma importncia maior, pois os dispositi-vos mveis nem sempre esto online e com uma boa disponibilidade de Internet. Ento,quando esto aptos a mandar dados ao servidor ele no pode falhar.

Por isso, foi feita a escolha pelo Google App Engine que um servio de cloud ofe-recido pelo Google. Esse servio oferece uma disponibilidade de 99.95%, segundo suadocumentao (GOOGLE, 2013). Alm disso, j registrou 0% de indisponibilidade du-rante um ano(BLOG, 2013). O Google App Engine um framework fcil de usar paradesenvolvimento e publicao de servios web, que disponibiliza uma cota grtis do ser-vio que suficiente para os testes deste sistema.

Nesse servidor foi desenvolvido um web service que por onde os dispositivos mveise clientes web enviam e recebem dados. O web service, banco de dados e framework decache utilizados so descritos a seguir.

4.3.1 Google App Engine

O Google App Engine uma ferramenta que permite executar aplicaes web na in-fraestrutura do Google. uma soluo fcil de manter e escalvel deixando o programa-dor livre para focar apenas no desenvolvimento da aplicao em si. Suporta aplicaesescritas em vrias linguagens como JAVA, PYTHON, PHP, GO. Para este trabalho foiescolhido utilizar a linguagem JAVA, pois o autor esta mais familiarizado com essa lin-guagem.

A aplicao web no Google executada em um ambiente seguro com acesso limitadoao sistema operacional. Isso isola a aplicao em um ambiente que independente dehardware, sistema operacional e localizao fsica do servidor. Isso permite distribuir asrequisies web entre mltiplos servidores, alocando e desalocando servidores para seadaptar as demandas de trfego. Essa adaptao dos recursos conforme a sua utilizao o que se denomina de elasticidade na rea de computao em nuvem.

Aplicaes executando no App Engine apenas podem ser acessadas por requisiesHTTP ou HTTPS em suas portas padres. No permitido escrever no sistema de ar-quivos em tempo de execuo, ou seja, apenas se tem acesso aos arquivos carregados nodeploy da aplicao. O cdigo da aplicao s pode ser executado em resposta a algumarequisio, ou tarefa agendada, e precisa responder em at 60 segundos caso contrrioo processo terminado. A aplicao interage com o ambiente por meio de Java Servlet(ORACLE, 2013a), e tambm foi utilizado neste trabalho a tecnologia JavaServer Pages(ORACLE, 2013b) para a renderizao de pginas web dinmicas.

O App Engine tambm oferece um banco de dados NoSQL e Memcache(MEMCACHE,2013) para acesso a dados em alta velocidade. Alm disso, suporta integrao do aplica-tivo com o Google Accounts que facilita a autenticao de usurios.

4.3.2 Web Service

Utilizando a ferramenta App Engine foi implementado um Web Service para a comu-nicao com os dispositivos que compem o sistema. Para implementao foi utilizadoo modelo RESTful de Web Service(RICHARDSON; RUBY, 2007), que implementadoutilizando HTTP e os princpios REST.

Foi escolhido JSON(JavaScript Object Notation) como formato de dados que ser tro-

42

cado entre o web service e seus clientes. O JSON derivado da forma como a linguagemJavaScript representa suas estruturas de dados e arrays, embora JSON seja independentede linguagem e possui parser disponvel para muitas linguagens. Esse formato de dadosvem sendo bastante utilizado hoje em dia por ser uma alternativa, que apresenta um sobre-custo de dados e processamento menor que o XML. Assim, em aplicaes mveis, onde oconsumo de dados algo bastante sensvel, JSON muito utilizado na comunicao comservidores.

Figura 4.3: Comunicao entre aparelhos Android e servidor atravs das funes de WebService.

Foram implementadas funes no webservice para atender as necessidades do aplica-tivo mvel e web. A figura 4.3 mostra as funes de webservice que o aplicativo Androidfaz uso. A figura 4.4 mostra como a aplicao web usa o webservice para enviar dadosao servidor. E por fim, a figura 4.5 mostra como a aplicao web usa o webservice parabuscar dados necessrios para montar a pgina web.

Figura 4.4: Requisies feitas a partir da aplicao web ao servidor.

A seguir so listadas algumas dessas funes dando mais detalhes do funcionamentoe implementao.

Criao e autenticao do administrador: a autenticao acontece atravs do serviode autenticao do Google App Engine utilizando a conta do Google do adminis-trador;

Upload, download e remoo de arquivos APK (pacote de instalao de aplicativoAndroid);

43

Figura 4.5: Funes do web service por onde a aplicao web busca as informaes quesero exibidas.

Lista dos aplicativos da empresa; Requisitar ao aparelho que remova ou instale algum aplicativo; Receber mensagens de chat vindas da aplicao ou do dispositivo, encaminhar men-

sagens ao dispositivo e fornecer o histrico de mensagens a partir de uma data;

Receber a lista de aplicativos instalados em um aparelho e fornecer essa lista quandosolicitado;

Lista de todos os aparelhos de uma empresa com seu status. Essa lista pode ser emformato JSON ou HTML pronto para ser exibido na pgina web;

Recebe dados de uso de um dispositivo; Registro de aparelho; Registra uma empresa com seu nome e cdigo de registro; Solicita dados atualizados aos dispositivos de uma empresa;

As sees 4.4 e 4.5 descrevem de que maneira e com que frequncia essas funes doweb service so utilizadas.

4.3.3 Banco de Dados

Como visto anteriormente, o App Engine tem nativamente suporte para banco de da-dos NoSQL. Diferente de banco de dados relacionais, a natureza do NoSQL, conhecidacomo schema-less, permite que as classes sejam armazenadas assim como elas so. Por-tanto, muitas das tcnicas utilizadas em banco de dados relacionais no se aplicam a umbanco de dados NoSQL. Por exemplo, a classe Company, que tem como um de seus atri-butos uma lista de objetos Device, pode ser armazenada como uma lista dos IDs dessesobjetos.

Para facilitar a implementao da persistncia dos dados do sistema foi utilizado aAPI Objectify, cuja documentao pode ser encontrada em seu site oficial (OBJECTFY,2013). Essa ferramenta, alm de permitir persistir os modelos de maneira fcil, tambmj faz uso da cache, oferecido pela App Engine, de maneira automtica.

44

Figura 4.6: Arquitetura do banco de dados NoSQL do sistema.

A figura 4.6 mostra o diagrama do banco de dados resultante do sistema que com-posto pelas seguintes tabelas:

Company: onde so armazenadas as empresas registradas no sistema. Possui comochave primria o cdigo de registro escolhido pelo administrador. A tabela Com-pany tambm possui o conjunto chamado Applications que so os URLs para osaplicativos cadastrados da empresa. Essa tabela tambm possui o conjunto cha-mado Devices que guarda as referncias para todos os aparelhos registrados para arespectiva empresa.

User: armazena todos os usurios administradores registrados no sistema. Device: os dados dos aparelhos da empresa so armazenados nessa tabela. Tem

como chave primria o IMEI do aparelho. Essa tabela tambm possui um conjuntocom as referncias para as mensagens de chat (chatMessageList) e um conjuntocom todos os aplicativos instalados do aparelho (appsKeyList).

ChatMessage: guarda todas as mensagens de chat do sistema. A coluna timestampque utilizada para ordenar as mensagens por data que foram geradas.

AppEntry: nessa tabela so armazenados os aplicativos instalados nos dispositivos.Tem como chave primria o nome do pacote do aplicativo concatenado com a ver-so. Dessa maneira evita-se que um aplicativo instalado em muitos aparelhos fiquearmazenado repetidamente na tabela.

4.3.4 Uso do GCM

A figura 4.7 mostra as mensagens onde o GCM utilizado para notificar o dispositivo.Todas essas mensagens so enviadas com o TTL mximo de 4 semanas, pois importante

45

Figura 4.7: Mensagens enviadas aos Dispositivos Android atravs do Google Cloud Mes-saging.

que todas cheguem ao aparelho. As mensagens que fazem requisio por dados, indica-das na figura como Solicitar dados atualizados e requisitar aplicativos instalados, soenviadas com o mesmo collapse key. Ou seja, se o aparelho ficar offline por um longoperodo, e mais de uma dessas mensagens forem enviadas, apenas a ultima ser conside-rada, as outras sero descartadas. As mensagens Remover Aplicativo, Instalar Aplicativoe Mensagem de Chat tem importncia isolada, por exemplo, cada mensagem de chat importante que chegue ao dispositivo. Logo, elas so enviadas com collapse key diferen-tes.

4.4 Aplicao Mvel

Esta seo descreve as funcionalidades e servios implementados no aplicativo An-droid, descrevendo as tcnicas e ferramentas utilizadas para extrair e enviar os dados deuso do aparelho sem um consumo excessivo de bateria e rede.

O aplicativo Android foi desenvolvido utilizando o SDK nativo do Android, e com-pilado utilizando a API 17. O aplicativo suporta dispositivos com sistema operacionalAndroid verso 2.3 ou mais recentes.

As prximas sees retomam os servios para usurio final e servios de controle,especificados no captulo 3, adicionando detalhes de como foram implementados.

4.4.1 Servios para Usurio Final

Os servios para o usurio final so aqueles que ele tem acesso atravs de uma inter-face para interagir com o sistema. O aplicativo do sistema Devices Manager implemen-tado possui duas telas principais, no Android chamadas de atividades: a tela para registrodo dispositivo, pode ser vista na figura 4.8, e a tela de chat, pode ser vista na figura 4.9.A seguir so explicados os detalhes de implementao de cada uma delas.

46

Figura 4.8: Tela para registro do dispositivo.

4.4.1.1 Registro do Dispositivo

A primeira vez que o aplicativo iniciado em um dispositivo mvel apresentada atela de registro. A tela implementada pode ser vista na figura 4.8. Aqui, o usurio forneceum nome ao dispositivo e o cdigo de registro da sua empresa e clica em registrar paradar incio ao processo de registro.

Primeiramente, o aparelho se registra no GCM. Para isso ele utiliza o ID do servidore ID da aplicao, que so valores estticos no sistema, com esses dados ele se registra noGCM recebendo o cdigo de registro do dispositivo. Feito isso, chama a funo do Web-service para registro do dispositivo no servidor do Device Manager passando os seguintesdados:

Cdigo de registro do GCM. Cdigo de identificao do dispositivo (IMEI). Esse cdigo obtido atravs dos

procedimentos descritos no artigo (DEVELOPERS, 2013c). O IMEI um identifi-cador nico que permite que o mesmo dispositivo nunca seja registrado duas vezesno sistema. Ou seja, mesmo removendo o aplicativo do aparelho ele continuarregistrado no Devices Manager e quando o aplicativo for reinstalado ele voltar eenviar dados deste mesmo aparelho.

Cdigo de registro da Empresa que associa o dispositivo mvel empresa a qualele pertence.

Nome dado ao dispositivo mvel. Modelo do dispositivo mvel. E-mail do usurio registrado no dispositivo mvel.

47

Feito isso o dispositivo mvel est registrado no sistema e o administrador, pela aplicaoweb, j pode monitor-lo.

4.4.1.2 Chat

A funcionalidade de chat implementada, exibida na figura 4.9, oferece ao usurioos recursos bsicos de enviar e receber mensagens. No caso do aparelho estar offline amensagem fica armazenada e ser enviada assim que o aparelho tiver acesso Internet.

Figura 4.9: Tela de Chat do aplicativo Device Manager

Para armazenar as mensagens de chat recebidas pelo dispositivo mvel foi implemen-tado um banco de dados SQL com a tabela mostrada na figura 4.10. O Android dispo-nibiliza uma API com os recursos necessrios para implementao de banco de dadosSQLite(DEVELOPERS, 2013d).

O aplicativo implementado possui um servio chamado ChatMessagesService que tema misso de gerenciar o envio e recebimento de mensagens. Quando uma mensagem

Figura 4.10: Tabela do banco de dados onde armazenado as mensagens de chat.

48

Figura 4.11: Exemplo de como so mostradas as notificaes de chat no dispositivo An-droid.

chega via GCM ela enviada para esse servio. Ento, ele se encarrega de colocar amensagem no banco de dados e notificar o usurio. Essa notificao pode acontecerde duas maneiras: se o usurio estiver com a tela de chat do aplicativo aberta ela sernotificada e a lista de mensagens ser atualizada; caso contrrio uma notificao, comona figura 4.11, exibida e o usurio pode clicar nela para abrir a tela de chat.sec:controle

Inicialmente, para enviar uma mensagem, ela adicionada ao banco de dados com ocampo sent marcado como falso. Ento enviado uma notificao ao servio que devetentar enviar as mensagens de chat pendentes, se o aparelho estiver online. Sempre queo dispositivo ficar online o servio tambm recebe uma notificao para tentar enviarmensagens pendentes.

4.4.2 Servios de Controle

Essa seo descreve a implementao dos servios de controle especificados na seo3.3.2. Esses servios implementados, que o aplicativo executa em background, so oslistados na figura 4.12 que apresenta um screenshot da tela dos servios do aplicativoDevice Manager.

4.4.2.1 Monitoramento

O servio chamado HandleFreshDataRequest o responsvel pelo monitoramentodos recursos mais dinmicos do dispositivo: GPS, bateria, rede wireless, Internet mvel,localizao e reconhecimento de atividade. Alm disso, responsvel por enviar dadosatualizados ao servidor quando requisitado por mensagens vindas atravs do GCM.

O GPS monitorado apenas quanto ao status, ligado ou desligado. Ento, se o usurioativar ou desativar o GPS, na mesmo momento, o servio recebe uma notificao e tentaenviar ao servidor o status atualizado.

O servio recebe notificao quando o aparelho colocado para carregar a bateria, ouse a bateria entra em um nvel muito baixo. Quando um desses eventos acontece enviadopara o servidor o status atualizado do bateria.

Sempre que a rede wireless ativada, desativada, ou conectada a uma rede o serviotenta enviar ao servidor o status atual.

Dentro do Google Play Services h disponvel um servio que oferece a localizao

49

Figura 4.12: Tela que mostra todos os servios que so executados pelo aplicativo DeviceManager

e a deteco de atividade do aparelho. O servio de localizao do Google disponibilizadiferentes perfis de consumo de bateria. Neste trabalho, foi configurado para um consumomoderado e uma frequncia entre de 1 min e 1 hora. Ento a aplicao ir receber aslocalizaes da seguinte maneira:

1. Se o aparelho estiver sendo utilizado apenas dentro da empresa, ou sem muita mo-vimentao, ele ir receber posies atravs da rede wireless, ou 3G, com poucafrequncia provavelmente chegando ao intervalo mximo de 1 hora.

2. Se o usurio estiver em campo, o servio ir detectar nova localizao aproximadapelas antenas de telefonia celular, ou redes wireless encontradas. Aumentando afrequncia de novas posies.

3. Caso o usurio esteja utilizando algum aplicativo de localizao, como o GoogleMaps, com o GPS ativo, ele ter posies de qualidade atualizadas a todo o instante.Nesse caso, a aplicao ir receber posies a cada 1 minuto que a frequnciamxima configurada.

O reconhecimento de atividade do dispositivo feito com a leitura de sensores debaixo consumo. O servio tem a capacidade de detectar as seguintes atividades: cami-nhando, andando de bicicleta, em um veculo, parado, e outras (desconhecidas). Essaleitura acontece dentro de intervalos de 5 minutos. Cada leitura dos sensores retornauma provvel atividade com um valor de probabilidade de acerto. Ento, sempre que aatividade detectada tiver probabilidade superior a 50%, e for diferente da anterior, essainformao enviada ao servidor.

Mais informaes sobre o funcionamento do Google Play Services pode ser encon-trada na documentao oficial sobre localizao (LOCATION, 2013) e sobre o re

gerenciamento de byod.pdf

Documents