UNIVERSIDADE FEDERAL DE PERNAMBUCO

CENTRO DE INFORMÁTICA
SISTEMAS DE INFORMAÇÃO

DAVID FRANCISCO DO NASCIMENTO BANDEIRA

Ambientes desenvolvimento de software na plataforma Android

TRABALHO DE CONCLUSÃO DE CURSO

Recife
5 de Dezembro de 2019
 DAVID FRANCISCO DO NASCIMENTO BANDEIRA

Ambientes desenvolvimento de software na plataforma Android

Trabalho de Conclusão de Curso apresen-

tado ao Sistemas de Informação, como
parte dos requisitos necessários à obten-
ção do título de Bacharel em Sistemas de
Informação.

Orientador: Vinicius Cardoso Garcia

Recife
5 de Dezembro de 2019
 David Francisco do Nascimento Bandeira

Ambientes desenvolvimento de software na plataforma Android

IMPORTANTE: ESSE É APENAS UM

TEXTO DE EXEMPLO DE FOLHA DE
APROVAÇÃO. VOCÊ DEVERÁ SOLICITAR
UMA FOLHA DE APROVAÇÃO PARA SEU
TRABALHO NA SECRETARIA DO SEU
CURSO (OU DEPARTAMENTO).

Trabalho aprovado. Recife:

Vinicius Cardoso Garcia

Orientador

Professor
Convidado 1

Professor
Convidado 2

Recife
5 de Dezembro de 2019
 “Dedico a Deus por pela vida que me foi dada e às pessoas a que deram parte
das suas próprias para que puder ser quem sou hoje ”
 Agradecimentos

Agradeço primeiramente a Deus por ser o único que me acompanha a todo

momento nesta vida caótica e difícil mas sempre cheias de mistérios e descobertas
que me mostram que sempre vale a pena viver.
Agradeço a minha família que foi capaz de sempre dar suporte para chegar
neste momento único e aos meu poucos e valiosos colegas e amigos que puderam me
iluminar com meus erros e acertos.
Por fim e não menos importante aos meus mestres que na medida da suas
paciências e dedicação me repassaram seu conhecimento e experiência de vida.
 Resumo

Os smartphones se tornaram o meio pelo o qual a maior parte da sociedade

tem acesso a um computador e para as gerações mais novas é o principal meio
de acesso a recursos computacionais, somado isto ao crescente aumento de poder
computacional que os smartphones sendo hoje comparados a computadores e uma
transformação crescente nas formas de trabalhos estarem atreladas ao smartphones
temos um ambiente propício para o uso do android como uma alternativa real de uma
plataforma de desenvolvimento de software, graças às semelhanças do Android com o
sistemas operacionais baseados Linux, temos a capacidade de ter as ferramentas de
software e processos de produção de software moderno no Android e este trabalho
deseja viabilidade do uso do ambiente de smartphone Android como ambiente padrão
de desenvolvimento de software de qualidade.
Palavras-chave: Android. Desenvolvimento. Mobile. Desktop
 Abstract

Smartphones have become the means by which most of society has access
to a computer, and for younger generations it is the primary means of access to
computing resources, added to the increasing computational power that smartphones
today are compared to. computers and a growing transformation in the way work is
linked to smartphones we have a conducive environment for using android as a real
alternative to a software development platform, thanks to the similarities of android with
linux based operating systems we have the ability to have software tools and modern
software production processes on Android and this work wants viability of using Android
smartphone environment as standard quality software development environment.
Keywords: Android. Development. Mobile. Desktop
 Lista de ilustrações

Figura 1 – Dados coletados durante um período de sete dias encerrado em 7

de maio, 2019. As versões com menos de 0,1% de distribuição não
são exibidas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Figura 2 – Interface do Userland . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Figura 3 – Interface Termux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Figura 4 – Pirâmide da solução . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
 Lista de tabelas

Tabela 1 – Ficha tecnica do aparelho . . . . . . . . . . . . . . . . . . . . . . . . 13

Tabela 2 – Relação criterios x aplicação . . . . . . . . . . . . . . . . . . . . . . 16
Tabela 3 – Tamanho do armazenamento usado antes de instalar as distribuicões
e depois, valores medios . . . . . . . . . . . . . . . . . . . . . . . . 23
Tabela 4 – Resultados do uso do Termux . . . . . . . . . . . . . . . . . . . . . 25
 Sumário

1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.1 Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.2 Desafios, limitações . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.3 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2 Desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3 Conclusões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.1 Resultados Obtidos . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2 Discussão sobre o android . . . . . . . . . . . . . . . . . . . . . . . 24
3.3 Trabalhos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Referências . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

ANEXOS 28
 10

1 Introdução

O android é um dos ecossistemas de sistemas operacionais mais bem sucedidos

e diversos do mundo segundo os dados revelados durante o evento do GOOGLE (2019)
I/O que existem no ano de 2019 cerca de 2,5 bilhões de dispositivos ativos e esse
número está dividido entre toda uma gama de aparelhos de smartphone,tablet e
computadores, somado isto ao anúncio do “Desktop Mode” relatado por Rahman (2019)
que em sua versão 10 é visível as intenções da Google que é atual cabeça do android,
o interesse em transformar a plataforma em um ambiente pleno e padrão de desktop.
Existem outros pontos positivos como o parentesco entre os sistemas operacio-
nais baseados em Linux e Android que pesquisas como as de NAMRATA B BOTHE
et al. (2016) que demonstraram a possibilidade de portar ferramentas de sistema
operacionais baseados em Linux para o sistema Android com relativo. Temos desafios
a superar como diferenças arquiteturais entre os sistemas Linux padrão e o Android
relatadas nos trabalhos de CHARAN K.V, S. P SHARMILA e A.S MANJUNATH (2014)
que dificultam a capacidade de execução de aplicações mais complexas e por esse
motivos algumas das ferramentas mais comuns do ambiente Linux padrão não são
possíveis de serem usadas nos aparelhos android clássicos.
Nas seções seguintes, será descrito todo o processo de pesquisa e transporte
do ambiente de desenvolvimento, testes, adaptações e desafios encontrados todos
com o objetivo de responder as seguintes perguntas:

• O android podem ter um ambiente de desenvolvimento?

• Que recursos se tem hoje em dia que possibilite o desenvolvimento?

• Caso haja impedimentos de uso de alguma ferramenta como contornar para

que a mesma seja operacionalizada dentro da plataforma?

• O quanto de linux o Android tem de compatível com seus primos do desktop?

. A seção 2 irá contextualizar este trabalho no sistema operacional Android

e outros conceitos importantes para entender as Soluções aplicadas, explicando as
decisões tomadas, método da pesquisa e limitações encontradas. Na seção 3, será
descrito o processo de desenvolvimento,pesquisa e escolha das aplicações nativas
usadas, como foi implementado os ambientes de desenvolvimento com possíveis
desenvolvimentos e quais resultados encontrados. Por fim, na seção 4, será analisado
os resultados finais obtidos e possíveis melhorias identificadas para trabalhos futuros.
Contexto
Capítulo 1. Introdução 11

1.1 Android

O Android (PROJECT, 2017) se define como um sistema operacional de kernel

Linux e mantido e desenvolvido por um consórcio chamado de Open Handset Alliance
com o interesse em comum para manter um sistema operacional open source, todos
compartilhando uma base comum e criando customizações para seus produtos, sendo
estas customizações seguindo limitações impostas pelo programa de compatibilidade
do Android Open Source Project (AOSP) liderado pelo Google com o objetivo de
melhorar a compatibilidade e minimizar os custos de customização, customizações
podem ser alterações visuais na interface do usuários, adição de recursos de hardware
novos ou aplicações proprietárias que permitem recursos ainda não explorados, porém
tais mudanças precisam respeitar a arquitetura de software do android.
O android em sua documentação oficial (ANDROID DEVELOPERS, 2017)
atualmente tem suporte a duas arquitetura principais: x86 e ARM para as variantes 32
e 64 bits,sendo a última na variação de 64bits sua atual principal arquitetura e por ser
um sistema inicialmente projetado para dispositivos alimentados pelo uso de baterias
o Android faz um agressivo gerenciamento de memória e processamento de forma
a tentar detectar processos inativos ou que nao estao sendo usados no momento e
eliminá-los, isso de deve a que todas as aplicações do android serem desenvolvidas
em cima de uma máquina virtual de processo chamada de Dalvik (ANDROID OPEN
SOURCE PROJECT, 2017), pois toda a aplicação android é compilada para um
bytecode que a Dalvik irá trabalhar do jeito mais otimizado para as limitações do
aparelho, existem formas de contornar o uso da Dalvik rodando código nativo, mas
a maioria das interfaces principais do sistema precisam ser acessada pela Dalvik e
processo nativo são iniciados pela mesma.
NAMRATA B BOTHE et al. (2016) identificaram em sua pesquisa de portabilidade
linux para Android uma serie de diferenças entre as distribuições Linux clássicas para
computadores e o Android como: uma restrição de acesso de recursos do SO para os
aplicativos pela remoção de syscalls do sistema, impossibilidade de usar técnicas de
concorrência como semáforos em código nativo, a impossibilidade de uso de recursos
modernos virtualização dos processadores mesmo que os processadores tenham
acessado a estes, existem exceções caso a vendedora do hardware tenham aberto
implementação durante a customização do sistema, não existe o conceito de super
usuário no sistema, sendo assim não é possível tem acesso ao hardware sem que exista
alguma interface aberta e que a aplicação tenha permitido acesso prévio para usuário.
Apesar de tantos problemas, estes podem ser contornado pois o android é flexível o
suficiente para que haja iniciativas de melhorar a compatibilidade de aplicações Linux
no Android e liberar recursos que normalmente não seriam possíveis em aparelhos
normais, habilitar o super usuário para customização do kernel permite que se tenham
Capítulo 1. Introdução 12

acesso total aos recursos de um sistema operacional Linux convencional.

Existem também iniciativas de open source como a aplicação Termux(TERMUX,
2017) que cria um terminal interativo para o android com uma camada de compa-
tibilidade para tornar a experiência de usuário parecida com as distribuições Linux
clássicas e um gerenciador de pacotes com programas de terminal compilados para
rodar especificamente neste ambiente.

1.2 Desafios, limitações

A implantação de ambientes de desenvolvimento em sistemas móveis possui

muitas variáveis que tornam imprevisível a capacidade reprodução, o maior desafio
está na pluralidade de configurações de hardwares dos aparelhos, tipos de arquiteturas
diferentes, e mesmo desconsiderando os diferentes sistemas operacionais no mercado
ainda há variações do mesmo sistema operacional feitas pelas empresas que vendem
o hardware e versões do operacional divididos como pode se ver na figura 1 .

Figura 1 – Dados coletados durante um período de sete dias encerrado em 7 de maio, 2019.
As versões com menos de 0,1% de distribuição não são exibidas.

https://developer.android.com/about/dashboards?hl=pt-br

Por haver uma fragmentação tão alta e a fim de simplificar os testes será
usado como base o tablet Samsung Galaxy Tab A SPen(SM-P205NZKPZTO) para
os experimentos. Foram feitos teste preliminares de aparelhos mais simples como o
Xiaomi Redmi 2 de 512 megabytes de RAM e um Alcatel A3xl de 2 gigabytes de RAM,
com aplicações simuladoras de terminal, será explicado mais à frente destas aplicações,
e apesar de um resultado satisfatório em caso de pequenas tarefas, ser capaz de rodar
múltiplas ferramentas de desenvolvimento e ainda as aplicações desenvolvidas iria
Capítulo 1. Introdução 13

requerer uma quantidade de memória que os aparelhos com configurações menores

não poderiam fornecer, a versão do sistema operacional android testado em aparelhos
de versão 5.0 Lollipop ou superior, em especial as versão 9(Pie).
Por fim a último desafio de executar um ambiente de desenvolvimento usando
os recursos de hardware do próprio aparelho sem nenhum acesso remoto, no caso
de usar um Android como um terminal burro para um servidor de desenvolvimento
externo teríamos a possibilidade de executar virtualmente em qualquer aparelho pois
já existem aplicativos nativos para cliente dos principais protocolos de acesso remoto
como ssh,vnc,rdp. O objetivo deste trabalho está em forçar os limites da plataforma
para entender se ela pode ter condições mínimas com ferramentas modernas de
desenvolvimento.

Tabela 1 – Ficha tecnica do aparelho

Nome Samsung Galaxy Tab A SPen(SM-P205NZKPZTO)

Sistema operacional Android 9.0 (Pie)

CPU Octa-core (2x1.8 GHz Cortex-A73 & 6x1.6 GHz Cortex-A53)

GPU Mali-G71 MP2

Chipset Exynos 7904 (14 nm)

MEMÓRIA 32 GB, 3 GB RAM

1.3 Metodologia

O processo de pesquisa das soluções primárias de compatibilidade foi feito ma-

nualmente, e foi pautado no resultado de busca de palavras chave da como “ running
linux android port applications” em engines de busca, sites especializados para desen-
volvedores de software e redes sociais onde normalmente se encontram comunidades
de software, o principal objetivo deste tipo de busca era encontrar comunidades de
desenvolvedores ou empresas que teriam o ativo interesse no trabalho de portabilidade
entre linux e android, depois de encontrado as ferramentas elas seriam avaliadas pelos
seguintes critérios:

• Portabilidade, o ambiente do android e fragmentado e a solução precisa suportar

o máximo possível de versões do android.

• Suporte, caso seja uma empresa ou comunidade esta é capaz de dar suporte
para conhecimento, implementação de novas features e correções de bug.

• Flexibilidade, capacidade de se o máximo personalizado possível para se en-

caixe no maior número de usuários possíveis.
Capítulo 1. Introdução 14

• Aplicações, existe um ecosistemas de outras aplicações em cima desta para

expandir esta solução sem muito esforço.

• Ergonômia, evitar o uso de features como super usuário que não é um padrão en-
tregue pelo S.O sem ter que recorrer a recursos não ortodoxos e possivelmente
danosos para o aparelho.
 15

2 Desenvolvimento

Antes de iniciar as tentativas para reproduzir os ambientes de desenvolvimento

foi preciso realizar uma pesquisa de quais ferramentas disponíveis no mercado para
poder adaptar um workflow destes ambientes, neste caso ferramentas nativas e básicas
como editores de texto, compiladores, ides, debuggers não existem no android oficial-
mente em seu principal centro de distribuição de aplicativos a Google Play, algumas
exceções como o aplicativo AIDE que é uma tentativa de se criar um IDE para criação
de aplicativos android existem mas são pouco customizáveis e não apresentam padrões
que a indústria de desenvolvimento de software está usando, logo seria necessário
portar as ferramentas de plataformas mais consolidadas como o Linux desktop para o
Android usando aplicações que fariam essa compatibilidade com algumas alterações
menores se fosse preciso, essa busca foi manual e o ponto de referência dela seria a
loja do Google Play usando termos de busca como “linux on android” e “terminal”, o
resultado desta busca foi:

Aplicativo Descrição

Uma ferramentas para automatizar a instalação de um S.O

linux deploy
Linux dentro do Android

Complete linux Uma ferramentas para automatizar a instalação de um S.O

installer Linux dentro do Android

Um terminal construido com camadas de compatibilidade

Termux para pertir que Apps de terminal linux normais executem
dentro dele

Um aplicativo que gerencia,cria e instala distribuições linux

Userland
dentro do Android por simulação de sistema de arquivos

UbuntuForAndroid Instala o ubuntu e o torna acessivel via ssh

GNURoot Um aplicação de terminal Debian para o Android

Bochs Um port da biblioteca bochs para o Android

Instala uma distribuição Ubuntu completa com interface

Linux on DeX gráfica, disponível apenas na linha samsung galaxy note 8
e9

Observando os critérios e limitações levantados no capítulo de contexto, po-

demos fazer algumas considerações, os aplicativos “linux deploy”, “Complete linux
installer” e “UbuntuForAndroid” precisam ter acesso ao superusuário logo eles não pu-
deram ser escolhidos, o “Linux on Dex” existe apenas para os aparelhos da linha galaxy
note da empresa Samsung e nao foi possivel ter acesso a esses aparelhos para realizar
Capítulo 2. Desenvolvimento 16

testes, o aplicativo “Bochs” está em uma versão rudimentar apresentando problemas

de performance e usabilidade nos testes preliminares que foram feitos nos aparelhos
selecionados para testes e foi descartado, o aplicativo “GNURoot” foi capaz de oferecer
uma camada de Debian rodando em um terminal, funcionando bem o suficiente, mas
oferecia pouca integração com o smartphone como acesso ao armazenamento externo
do aparelho, existem problemas de compatibilidade com as versões mais novas do
Android, em especial ele não estava atualizado para as versão 9, e acabou ficando
como uma versão de para aparelhos mais antigos, a tabela 2 resume os resultados da
pesquisa.

Tabela 2 – Relação criterios x aplicação

Nome Portabilidade Suporte Flexibilidade Aplicações Ergonômia

Sim,
Sim, todas as Não, pois
linux deploy Não existe totalmente Nao
versoes usa root
customizavel

Sim,
Complete linux Sim, todas as Não, pois
Não existe totalmente Não
installer versoes usa root
customizavel

Sim, possui
Sim,
Sim, todas as widgets de
Termux Sim, opensource totalmente Sim
versoes UI do
customizavel
android

Sim, a partir Sim, integra

Userland da 5 em Sim, opensource Não com apps Sim
diante de ssh e vnc

Não, sem
Sim, todas as acesso
UbuntuForAndroid Não existe Não Não
versoes direto ao
android
Capítulo 2. Desenvolvimento 17

Nome Portabilidade Suporte Flexibilidade Aplicações Ergonômia

Não, somente
GNURoot Não existe Não Não Sim
as antigas

Bochs Não Não existe Não Não Sim

Sim,
Não,
Não, somente Funciona
Linux on DeX Não existe Não exclusivo do
as novas seamless
samsung
com o Dex

As opções restantes dos aplicativos que funcionam foram o UserLand(Figura

2) e Termux(Figura 3), ambos são aplicações open source com suporte com uma
comunidade bem estabelecida, UserLand tem recursos que de maneira visual é possível
escolher uma distribuição, que está na lista de suportadas e executá-la tendo acesso
por acesso do protocolo SSH para terminal ou VNC caso deseje usar interface de
usuário padrão, isso se torna possivel com tecnicas de simuação por sistemas de
arquivos e container por chroot sem privilegios de super usuario e assim a distribuição
funciona de maneira meta por esta funcionando em cima de do Kernel do Android,
um dos problemas enfrentados com o UserLand foi a sua baixa integração com as
interfaces do Android pois o sistema operacional hospedeiro não tem acesso aos
recursos como ao armazenamento externo do aparelho, ao usb ou sensores e outros
recursos, por o aplicativo tem pouca customização logo em caso de necessidade do
usuário, não sendo possível rodar outras distro além das oferecidos pelo aplicativo,
porém em questão de uso ele oferece boa performance e usabilidade caso o usuário
não deseje tais recursos e os testes de ambientes de desenvolvimento também servem
nele.
Capítulo 2. Desenvolvimento 18

Figura 2 – Interface do Userland

Capítulo 2. Desenvolvimento 19

Figura 3 – Interface Termux

O Termux se mostrou a ferramenta escolhida por ser capaz de reproduzir com

simplicidade um terminal funcional linux com um gerenciador de pacotes próprios
compilados com compatibilidade o android, porém no caso pode não haver todas as
ferramentas necessárias para trabalhar com desenvolvimento e neste caso foi necessá-
rio uma ferramenta comum em muitas distros chamada de PROOT (2018) que é uma
implementação de user-space de chroot, mount –bind e binfmt_misc, sendo assim pos-
sível simular uma distribuição linux com seu próprio sistema de arquivos e assim rodar
processos que têm dependência em binários próprios no sistema de arquivos hospe-
deiro, essa técnica apenas permite que um sistema operacional hospedeiro opere com
uma performance aceitável já que não há uma simulação completa. O Termux possui
vários scripts de instalação de outras distro feitos pela própria comunidade(TERMUX
WIKI, 2018) que são amplamente usados e no caso deste trabalho de graduação será
usado uma instalação do Alpine Linux que é uma distribuição focada em portabilidade
e requer pouco armazenamento depois de completamente instalado, neste estado
já é possível instalar um ambiente básico de desenvolvimento pelo terminal com as
Capítulo 2. Desenvolvimento 20

linguagens mais comuns como ruby,javascript,python porém deve-se estar ciente das
limitações do kernel, nas dependência das linguagens que usarem recursos bloquea-
dos elas causarão erros, neste momento foi conseguido instalar todo um ambiente de
desenvolvimento no terminal com ferramentas de como VIM,Tmux e git.
Caso uma interface de usuário mais tradicional seja necessária é possível ser
instalada e acessada através do protocolo remoto VNC, podemos instalar um ambiente
de desktop que pode ser acessado pela gerenciador de pacotes que a distribuição tem
disponível, o XFCE foi o escolhido, depois de instalado será preciso de um servidor
de vnc para que se possa criar o ambiente gráfico pois o Termux não possui meios
de representar um ambiente gráfico, no caso foi usado o servidor TightVnc server e
teremos que configurá-lo para responder a rede local do aparelho, uma vez que o
tenhamos configurado o servidor é possível já instalar um aplicativo de cliente de VNC
disponível na loja do android para que abrir o servidor e acessar o ambiente, com
uma aparelho com memória suficiente se consegue ter acesso a qualquer aplicativo
que como ide populares e browsers de desktop, neste ponto tem-se um ambiente
gráfico e um ambiente linux quase funcional com alguns impedimentos, em termos de
usabilidade dependendo do aparelho teremos problemas de delay caso a memória do
aparelho esteja perto de ser completamente ocupada e renderização de openGL em
alguns aplicativos fica comprometida sem que haja adaptações, esses são problemas
comuns de se usar o protocolo VNC e como para o objetivo deste projeto não foram
usados aplicações que usam demasiadamente recursos gráficos não foram encontrados
empecilhos.
Porém considerações precisam ser feitas enquanto os scripts, a mais contras-
tante e que a variante da arquitetura arm 32 bits está caindo em desuso e o suporte
a vários pacotes pode não existir ou esta com versões antigas e ainda falando dos
aparelhos com arquitetura 32 bits temos problemas com relação às especificações dos
aparelhos que normalmente vem neste arquitetura pois elas normalmente são inferiores
ao requisitos mínimos do escopo deste projeto e o melhor aparelho que usado para
teste neste projeto bate com as especificações mínimas sem muita folga e quando lhe
foi requerido mais processamento como no caso de subir servidores de projeto mais
complexos e manter servidores gráficos a performance foi baixa, não seria possível um
aparelho desta especificações ter um servidor gráfico enquanto o usuário trabalha em
um projeto sem o custo de delay e performance ruim, mas o usuário consiga trabalhar
todo seu fluxo de trabalho dentro de aplicações baseadas em texto para serem usadas
no terminal do Termux seria perfeitamente possível ter um fluxo de trabalho natural
com o aparelhos nas especificações mínimas, outra observação fica com os ambientes
gráficos acessados por VNC pois a usabilidade não substitui a manipulacao nativa
de uma interface gráfica, em aparelho melhores ainda existe um pequeno delay de
interação com os elementos da tela, e o acesso a recursos de som nao e simples de
Capítulo 2. Desenvolvimento 21

ser feito mas com um período de adaptação o autor do deste artigos deixou de sentir
estranheza com essas limitações de uso.
Porém ainda existiam limitações que precisavam ser superadas, pois executar
aplicações como Docker ou o Kubernetes seria impossivel containers no Android não
está disponível mesmo pela simulação de distribuições do Proot, mesmo que consiga
baixar as binário pelo gerenciador de pacotes, para esses tipos de necessidades uma
simulação completa.
Antes de trabalhar em uma solução deve-se lembrar que o Android não possui
diretivas de kernel para uma aceleração de virtualização por padrão, logo tem-se em
mente que a performance da simulação pode não ser satisfatória dependendo da
exigência da aplicação rodando pela simulação. Para ter acesso a um virtualizador
será necessário usar uma distribuição simulada pelo Proot, pois o Termux não possui
pacotes estáveis para um virtualizador e para este projeto será usado o Alpine Linux
em Proot e a ferramenta de virtualização será o Qemu na sua variante de arquitetura
compatível com a versão do aparelho, no casos os aparelhos usados para teste foram
da Arm 64 bits que é chamada de aarch64, a iso do sistema usada na simulação
completa continua sendo a do Alpine Linux, porém neste caso todo o sistema ficará
dentro de uma unidade de disco virtual, a figura 2 abaixo demonstra todas as camadas
da pilha de tecnologia:
Capítulo 2. Desenvolvimento 22

Figura 4 – Pirâmide da solução

Mas antes uma ISO especial precisara ser feita pois padrão o alpine linux nao
dispoe para arm um de disco unificado com todas as parte do sistema pronto para
execução do virtualizador, no caso ela divide todas os arquivos do S.O em vários
arquivos separados e deve ser papel do desenvolvedor usuário montar o sistema
operacional e customizá-lo dependendo das usar necessidades, logo na primeira vez e
única vez será necessário construir um setup de virtualização onde irá se iniciar uma
máquina para montar uma máquina final básica em uma unidade virtual vazia criada
para esta finalidade, este processo se torna único pois após a criação bem sucedida
da mesma pode-se guardar esta nova unidade e posteriormente usá-la em novas
simulações caso deseje, foram criados scripts de inicialização da primeira vez, eles
baixam o arquivos do kernel e da árvore de pasta do sistema de arquivos, configurações
menores de processador,memória montagem da unidade vazia destino e variáveis de
inicialização do sistema também são feitas.
Após os scripts serem rodados com sucesso a máquina virtual em modo terminal
estará disponível e a fim de acelerar o processo de instalação e simplificá-lo será
necessário usar as as ferramentas padrões de setup e instalação do sistema que já
Capítulo 2. Desenvolvimento 23

estão dentro do alpine linux, porém existe um problema em especifico com a versão do
alpine linux ARM, pois o bootloader padrão da distribuição é extlinux e neste momento
não há versão suportada para ARM, para contornar esse problema deve-se preparar
primeiro o sistema para depois configurar o instalador do alpine a usar o padrão de
instalação com o bootloader para o tipo EFI diferente do padrão legacy usado para
inicializar a máquina virtual, isso será feito mudando algumas variáveis de instalação.
Depois da instalação ter ocorrido é necessário desligar a máquina virtual e iniciar
alguns scripts de configuração para que permita que o qemu reconheça o bootloader do
tipo EFI, neste momento pode-se criar uma variação do script de inicialização padrão
para configurar o qemu a fim de expor alguma porta de rede da máquina virtual para
uma das portas da máquina hospedeira, essa característica é importante caso se
deseje dentro da máquina virtual rodar aplicações web que precisam ser vistas do lado
de fora do ambiente simulado. Após iniciar os scripts que rodam a máquina virtual final
tem-se acesso a uma máquina funcional e operacional e pode-se instalar e executar
aplicações que seriam impossíveis no ambiente normal, no caso foram testados o
Docker com containers do NGINX, e caso ao ligar na porta correta pode-se neste caso
acessá-lo pelo browser do próprio android na porta local e porta de rede especificado
no script de inicialização.
Por fim o motivo que levou a escolha do alpine Linux foi a sua portabilidade, pois
em aparelhos modestros a quantidade de armazenamento acaba sendo pequena e
economizar torna-se prioridade.

Tabela 3 – Tamanho do armazenamento usado antes de instalar as distribuicões e depois,

valores medios

Tamanho Alpine Archlinux Ubuntu

base antes de instalar 1 MB 400 MB 35 MB

base depois de instalar 80 MB 2000 MB 1200 MB

 24

3 Conclusões

A plataforma mobile tem bastante potencial de crescimento, o Android em

questão vai necessitar muito esforço para que se torne um ambiente funcional e
acessível para desenvolvimento e mesmo sem esse foco hoje já se consegue com
certas adaptações executar as tarefas mais básicas.

3.1 Resultados Obtidos

Um dos objetivos alcançados e mais impressionantes foi a ausência de neces-

sidade de implementação pois por meio da comunidade estão sendo feitos esforços
para tornar o ambiente desktop no Android cada vez mais natural, basicamente todo
conhecimento para realizar esses testes foram buscados de outras fontes da comuni-
dade, a parte de contribuição deste trabalho a comunidade está na simulação completa
por máquina virtual de arm64 no android, porém toda as partes de compatibilidade já
haviam sido criadas e estavam bem documentadas.
Ainda sobre a técnica simulação completa é que ela deve naturalmente ter mais
delay por ter várias camadas de simulação e compatibilidade na pilha android, Termux,
Proot, qemu, sistema operacional simulado e aplicação respectivamente. Também
foram testados simulações de máquinas virtuais de arquiteturas diferentes como x86 64
bits(também conhecida como amd64) porém devida a natureza limitada dos aparelhos
usados, a performance delas foi menor que as versões simuladas na mesma arquitetura
nativa e talvez seriam eficientes em um hardware mais potente para os casos que
não existam uma aplicação portada para ARM. Por fim a memória se tornou um
grande gargalo pois a máquina virtual precisa de bastante memória reservada e talvez
abordagens mistas com um ambiente de desenvolvimento sendo feito localmente e o
ambiente de teste e desenvolvimento ficando externo em servidores também pode ser
uma alternativa

3.2 Discussão sobre o android

Para sucesso do futuro android como plataforma funcional de desenvolvimento

será necessário ver em perspectiva o suporte do android ao compatibilidade com
os padrões Unix pois quase a totalidade de aplicações usadas neste projeto foram
inicialmente criadas para o ambiente Linux desktop padrão, pois durante a implantação
deste projeto foram encontrados vários desafios entre versões do próprios android,
particularmente das versões do Android 8 em diante está-se tendo várias mudanças que
quebra de compatibilidade com a remoção e restrição cada vez maior de acesso aos
recursos do kernel que nao seja pelos métodos escolhido como padrão para o android
que nao sao compativeis com o Linux desktop e isso dificulta ainda mais a trabalho da
Capítulo 3. Conclusões 25

comunidade que trabalha em com a portabilidade das ferramentas de software. Talvez

isso seja questão de tempo até que o Android e a comunidade de desenvolvimento
de software encontrem um balanço pois durante o anúncio da versão 10 do android
houve o lançamento experimental ao modo desktop do android demonstrando que há
iniciativas por parte do organização que gerencia o android uma visão de ver o Android
como uma plataforma unificada.
De ponto de melhoria o android vai precisar de um método de compatibilidade
com as ferramentas de interface visual já existentes no linux desktop e o próprio android
pois a atual solução de acesso por modo de protocolos de acesso remoto como o
VNC apesar de ser funcionar e depende do hardware ser responsiva ainda e causa
estranheza para usuários de interfaces gráficas nativas que são responsivas e com
melhor performance em hardware mais modestos, de preferência focado em hardware
intermediários, pois teria maior público alvo e usuários, esta característica é essencial
pois a linguagem comum de interação com os computadores continuam sendo as
interfaces gráficas e fazer o usuário ter que interagir com um terminal de texto como o
Termux e nao intuito.

Tabela 4 – Resultados do uso do Termux

Sucessos Fracassos

Acesso a pacotes como nodejs e

Break Changes entre versões*
python

Pode rodar X11 e acessá-lo via

Baixa performance nos smartphones antigos
VNC

Simulação de distribuição com o Proot não simula features que o kernel não
“Proot” com scripts da possui, Docker por exemplo nao consegue
comunidade rodar

3.3 Trabalhos futuros

Neste trabalho foi focamos em adaptar aplicações existentes com o mínimo

adaptação para simular um ambiente de desenvolvimento, mas por causa das limi-
tações de performance apenas um grupo seleto de portadores de hardwares mais
potentes poderão se realmente beneficiar do estado atual do desenvolvimento em
plataformas móveis, seria esse ponto para atacar, por dois caminhos: criar abstra-
ções de compatibilidade melhores, como redirecionar simular apenas aos recursos
de kernel não existentes e criar formas de simulação híbrida e modulares, isso seria
um aumento significativo de performance. Outro caminho estaria em criar soluções
nativas para ferramentas e/ou adaptar as soluções consagradas no desktop, criando
versões alternativas de ambientes gráficos XFCE nativos para Android sem VNC ou
Capítulo 3. Conclusões 26

Docker nativo para Android, permitindo assim um futuro onde os desenvolvedores de

ferramentas software também pensem no android para implementar suas ferramentas
em vez depender de iniciativa exclusivas da comunidade.
 27

Referências

ANDROID DEVELOPERS. Android ABIs. 2017. Disponível em: https://

developer.android.com/ndk/guides/abis.html. Acesso em: 25 nov 2019.

ANDROID OPEN SOURCE PROJECT. Android Runtime (ART) and Dalvik. 2017.
Disponível em: https://source.android.com/devices/tech/dalvik. Acesso em: 25 nov
2019.

CHARAN K.V; S. P SHARMILA; A.S MANJUNATH. Customizing AOSP for Different

Embedded Devices. International Conference on Computing for Sustainable
Global Development, IEEE, p. 259 – 264, 2014.

GOOGLE. Google Keynote (Google I/O’19). 2019. Disponível em: https:

//www.youtube.com/watch?v=TQSaPsKHPqs&feature=youtu.be. Acesso em: 12 dez
2019.

NAMRATA B BOTHE et al. Migration of Hadoop To Android Platform Using ‘Chroot’.

International Journal of Innovative Research and Creative Technology, IJIRCT,
2016.

PROJECT, A. O. S. Set up for Android Development. 2017. Disponível em:

https://source.android.com/setup/. Acesso em: 25 nov 2019.

PROOT. PRoot. 2018. Disponível em: https://proot-me.github.io/. Acesso em: 28 nov

2019.

RAHMAN, M. Android Q’s Desktop Mode is real, here’s your first look. 2019.
Disponível em: https://www.xda-developers.com/android-q-desktop-mode/. Acesso
em: 15 out 2019.

TERMUX. The Termux Wiki. 2017. Disponível em: https://wiki.termux.com/wiki/

Main_Page. Acesso em: 25 nov 2019.

TERMUX WIKI. Termux Wiki, proot. 2018. Disponível em: https://wiki.termux.com/

wiki/PRoot.
Anexos
 Referências 29

Anexo A codigo para instalar o Alpine linux e realizar build inicial trabalhar
com o qemu

Código 1 – Initial.sh
pkg update
pkg install curl
curl - LO https :// raw . githubusercontent . com / Hax4us /
TermuxAlpine / master / TermuxAlpine . sh
sh TermuxAlpine . sh
startalpine
apk update
apk add wget
apk add qemu - img
apk add qemu - system - aarch64
apk add qemu - system - arm

Anexo B codigo para executar a maquina de build

Código 2 – Run.sh
1 ARCH = $ ( uname -m )
2 ALPINELINUXARCH = " "
3 if [ " $ARCH " = " armv7l " ]; then
4 echo " armv7 "
5 ALPINELINUXARCH = " armv7 "
6 elif [ " $ARCH " = " aarch64 " ]; then
7 echo " aarch64 "
8 ALPINELINUXARCH = " aarch64 "
9 else
10 echo " armhf "
11 ALPINELINUXARCH = " armhf "
12 fi
13
14 INITRAMFS = http :// dl - cdn . alpinelinux . org / alpine / v3 .10/ releases
/ $ALPINELINUXARCH / netboot -3.10.3/ initramfs - vanilla
15 VMLINUZ = http :// dl - cdn . alpinelinux . org / alpine / v3 .10/ releases /
$ALPINELINUXARCH / netboot -3.10.3/ vmlinuz - vanilla
16 MODLOOP = http :// dl - cdn . alpinelinux . org / alpine / v3 .10/ releases /
$ALPINELINUXARCH / netboot -3.10.3/ modloop - vanilla
17 if [ ! -f initramfs - vanilla ]; then
18 wget " $INITRAMFS "
19 fi
20
21 if [ ! -f vmlinuz - vanilla ]; then
22 wget " $VMLINUZ "
23 fi
24
25 if [ ! -f vm . qcow2 ]; then
26 qemu - img create -f qcow2 vm . qcow2 4 G
27 fi
28
 Referências 30

29 if [ " $ARCH " = " aarch64 " ]; then

30 qemu - system - aarch64 \
31 -M virt \
32 -m 512 M \
33 - cpu cortex - a53 \
34 - kernel vmlinuz - vanilla \
35 - drive if = none , file = vm . qcow2 , id = hd0 \
36 - device virtio - blk - device , drive = hd0 \
37 - netdev user , id = user0 - device virtio - net -
device , netdev = user0 \
38 - initrd initramfs - vanilla \
39 - append " console = ttyAMA0 ip = dhcp alpine _ repo =
http :// dl - cdn . alpinelinux . org / alpine / edge /
main / modloop = $MODLOOP " \
40 - nographic
41 else
42 qemu - system - arm \
43 -M virt \
44 -m 512 M \
45 - cpu cortex - a15 \
46 - kernel vmlinuz - vanilla \
47 - drive if = none , file = vm . qcow2 , id = hd0 \
48 - device virtio - blk - device , drive = hd0 \
49 - netdev user , id = user0 - device virtio - net -
device , netdev = user0 \
50 - initrd initramfs - vanilla \
51 - append " console = ttyAMA0 ip = dhcp alpine _ repo =
http :// dl - cdn . alpinelinux . org / alpine / edge /
main / modloop = $MODLOOP " \
52 - nographic
53 fi

Anexo C fluxo para instalar o Alpine linux dentro da maquina virtual de

build

# ...
Welcome to Alpine Linux 3.11 _ alpha20191114 ( edge )
Kernel 4.19.80 -0 - vanilla on an aarch64 (/ dev / ttyAMA0 )

localhost login : root

Welcome to Alpine !

The Alpine Wiki contains a large amount of how - to guides and

general
information about administrating Alpine systems .
See < http :// wiki . alpinelinux . org / >.

You can setup the system with the command : setup - alpine

You may change this message by editing / etc / motd .

localhost :~ # setup - alpine

Available keyboard layouts :
Referências 31

# ...
Select keyboard layout [ none ]:
Enter system hostname ( short form , e . g . ’ foo ’) [ localhost ]:
Available interfaces are : eth0 .
Enter ’? ’ for help on bridges , bonding and vlans .
Which one do you want to initialize ? ( or ’? ’ or ’ done ’) [ eth0
]
Ip address for eth0 ? ( or ’ dhcp ’ , ’ none ’ , ’? ’) [10.0.2.15]
dhcp
Do you want to do any manual network configuration ? [ no ]
udhcpc : started , v1 .31.1
udhcpc : sending discover
udhcpc : sending select for 10.0.2.15
udhcpc : lease of 10.0.2.15 obtained , lease time 86400
Changing password for root
New password :
Bad password : too weak
Retype password :
passwd : password for root changed by root
Which timezone are you in ? ( ’? ’ for list ) [ UTC ]
* WARNING : clock skew detected !
* WARNING : clock skew detected !
* Starting busybox acpid ...
[ ok ]
* Starting busybox crond ...
[ ok ]
HTTP / FTP proxy URL ? ( e . g . ’ http :// proxy :8080 ’ , or ’ none ’) [
none ]
Which NTP client to run ? ( ’ busybox ’ , ’ openntpd ’ , ’ chrony ’ or
’ none ’) [ chrony ] busybo
x
* service ntpd added to runlevel default
* Starting busybox ntpd ...
[ ok ]

Available mirrors :
# ...
r ) Add random from the above list
f ) Detect and add fastest mirror from above list
e ) Edit / etc / apk / repositories with text editor

Enter mirror number (1 -46) or URL to add ( or r / f / e / done ) [ f ]:

f
Finding fastest mirror ...
Added mirror linorg . usp . br
Updating repository indexes ... done .
Which SSH server ? ( ’ openssh ’ , ’ dropbear ’ or ’ none ’) [ openssh ]
none
Available disks are :
vda (4.3 GB 0 x554d4551 )
Which disk ( s ) would you like to use ? ( or ’? ’ for help or ’
none ’) [ none ]
Enter where to store configs ( ’ floppy ’ , ’ usb ’ or ’ none ’) [
none ]: none
Referências 32

Enter apk cache directory ( or ’? ’ or ’ none ’) [/ var / cache / apk

]: none
localhost :~ # USE _ EFI =1 BOOTLOADER = grub setup - disk -s 0
Available disks are :
vda (4.3 GB 0 x554d4551 )
Which disk ( s ) would you like to use ? ( or ’? ’ for help or ’
none ’) [ vda ]
The following disk is selected :
vda (4.3 GB 0 x554d4551 )
How would you like to use it ? ( ’ sys ’ , ’ data ’ , ’ lvm ’ or ’? ’
for help ) [?] sys
WARNING : The following disk ( s ) will be erased :
vda (4.3 GB 0 x554d4551 )
WARNING : Erase the above disk ( s ) and continue ? [ y / N ]: y
Creating file systems ...
mkfs . fat 4.1 (2017 -01 -24)
Installing system on / dev / vda2 :
Installing for arm64 - efi platform .
Installation finished . No error reported .
100% # ###########################################== >
initramfs : creating / boot / initr
amfs - vanilla
Generating grub configuration file ...
Found linux image : / boot / vmlinuz - vanilla
Found initrd image : / boot / initramfs - vanilla
done

Installation is complete . Please reboot .

localhost :~ # QEMU 4.0.1 monitor - type ’ help ’ for more
information
( qemu ) quit
[ root@localhost vm ] #

Anexo D codigo para executar o Alpine linux dentro da maquina virtual

final

Código 3 – run2.sh
if [ ! -f QEMU _ EFI . fd ]; then
wget https :// releases . linaro . org / components / kernel /
uefi - linaro / latest / release / qemu64 / QEMU _ EFI . fd
fi

if [ ! -f flash0 . img ]; then

dd if =/ dev / zero of = flash0 . img bs =1 M count =64
dd if = QEMU _ EFI . fd of = flash0 . img conv = notrunc
fi

if [ ! -f flash1 . img ]; then

dd if =/ dev / zero of = flash1 . img bs =1 M count =64
fi
# rodando em um device aarch64
Referências 33

qemu - system - aarch64 -m 1024 - cpu cortex - a57 -M virt -

nographic \
- pflash flash0 . img \
- pflash flash1 . img \
- drive if = none , file = vm . qcow2 , id = hd0 \
- device virtio - blk - device , drive = hd0 \
- netdev user , id = user0 - device virtio - net - device , netdev =
user0 \
- redir tcp :2222::22