Programando Androids – Parte 3

Continuando com meus posts sobre programação Android, mesmo desanimado pelo fato de não conseguir colocar minha(s) app(s) no Android Market.

Mas já que comecei, e o assunto é interessante, melhor continuar. Neste post, dando uma olhada por alto em como o Android OS é organizado e como ele gerencia a memória.

Arquitetura e Memória

O Android OS tem uma arquitetura em camadas (stacks). Os níveis mais baixos dessas camadas são por sua vez expostos para os níveis mais altos através de interfaces até a camada mais alta, onde se programa em Java.

A imagem abaixo (cortesia do google) demonstra uma visão aumentada de como estas camadas são organizadas:

Arquitetura do Android OS

Como se pode ver, o nível mais baixo do Android é o Kernel. Atualmente (versão 1.5 “cupcake”) o kernel utilizado é o Linux 2.6.27. No kernel estão também os drivers e controles básicos de hardware. A segunda camada é onde ficam as bibliotecas (libraries) e o próprio runtime do Android, incluindo aí a Dalvik Virtual Machine, encarregada de efetivamente executar o código das aplicações. A terceira camada consiste já das capacidades expostas aos desenvolvedores  para suas aplicações (gerenciador de janelas, sistema de notificação e etc). Finalmente a última camada é composta pelas aplicações propriamente ditas.

A camada de kernel é responsável também pelo controle mais fino da memória. Cada aplicação no Android roda em um processo separado, com sua própria VM, PID (número de processo) e usuário. Isso garante que caso uma aplicação dê problema, ela possa ser isolada e removida da memória sem comprometer o resto do sistema.

A Dalvik VM é a virtual machine que roda código java, mas com várias alterações para fazer isso usando menos ciclos de CPU (portanto gastando menos energia) e com otimizações de espaço/tamanho de dados. A Dalvik usa bytecode diferente da JVM tradicional e as aplicações usam um formato diferente do tradicional JAR (.jar), chamado .dex, também otimizado para menor uso de espaço.

Uma das diferenças da Dalvik é como ela mapeia a memória. Isso é feito usando um mapa memória-disco que permite que aplicações sejam rapidamente removidas da memória e depois restauradas. O G1 da T-Mobile limita cada aplicação a 16M de heap, e ainda estou tentando descobrir exatamente quanto de RAM ele tem. Algumas fontes dizem 192M, outras 64M. O fato é que a maioria das aplicações é bem menor que 16M. Quando o sistema começa a ter problemas de falta de memória o OS vai fechar aplicações que não estejam sendo exibidas, e estas aplicações podem ser retomadas depois com seus estados intactos (desde que bem programadas).

No próximo post eu vou falar um pouco sobre esses cuidados com as informações e o ciclo de vida das aplicações.

Lanterna: mais uma lanterna para telefones Android!

English version below.

Como eu disse neste post eu comecei a fazer algum progresso em programação para o sistema operacional móvel Android. Como eu precisava fazer alguma coisa para aprender/praticar, resolvi fazer uma lanterna, afinal de contas parece ser uma coisa comum para telefones fazerem o papel de iluminadores, ainda mais com seus grandes e brilhantes LCDs.

Eu me baseei em algumas aplicações já disponíveis no Android | Market, mas também em uma led flashlight da marca INOVA, a INOVA Inforce LED Military Flashlight. Por isso as diversas cores de luz e os modos strobe.

Eu não consigo colocar essa aplicação no Android | Market, por isso vou deixar ela disponível aqui e em outros sites que eu for achando (vou atualizando o post quando necessário).

Funcionalidades:

• Modo lanterna com luzes branca, amarela, verde e vermelha.
• Modo strobe com os padrões preto/branco, azul/vermelho (luzes de polícia), multi-cor, sinal luminoso de SOS (em morse), sinal luminoso beacon.
• Três velocidades de strobe, se mantendo dentro da faixa recomendada pela OMS para evitar o efeito pokemon (epilepsia foto-sensível). Alguns estilos de strobe não são afetados pela configuração de velocidade.

Licença e código fonte:

Lanterna é software livre sob os termos da GPL v3. Eu aceito doações (PayPal) se você gostar o bastante do software! =)

O código fonte, projeto Eclipse e todo o resto podem ser encontrados no repositório hospedado no GitHub.

Download:

Lantena.apk

Bugs e novas idéias:

Lighthouse Bug Tracking

Lanterna, yet another flashlight for Android phones!

As I said on this post (in portuguese), I started making some progress on programming Android apps. As I needed something to learn/practice I decided to create another flashlight, after all it seems like a common app on current phones, even more with their big LCD screens.

I based my work on some flashlights already available on the Android | Market, but also on a led flashlight from the INOVA brand, the INOVA Inforce LED Military Flashlight. Thats why it got multiple colors and strobe mode.

I can’t post apps on the Android | Market, so I will make it avaiable here and in other sites (I will update this post when necessary).

Features:

• Flashlight mode with white, yellow, green and red lights.
• Strobe mode with the following patterns: black/white, red/blue (police lights), multi-color, SOS light signal (morse code), beacon light signal.
• Three strobe speeds, respecting the limits suggested by the WHO to avoid the “pokemon effect” (photosensitive epilepsy). Some strobe styles are not affected by the speed settings.

License and source code:

Lanterna is free software under the terms of GPL v3. I accept donations (PayPal) if you liked the software enough!  =)

The source code, Eclipse project and all the rest can be found at the GitHub hosted repository.

Download:

Lantena.apk

Bugs and ideas:

Lighthouse Bug Tracking

Programando Androids – Parte 2

Ferramentas do SDK:

Uma das coisas que eu realmente gostei no SDK do Android é o fato dele ter uma integração muito boa com o Eclipse. Essa integração é tão boa que se me pedirem para criar um projeto Android na munheca é bem provável que eu ABEND e tenha de RTFM. Eu realmente gosto da praticidade de escolher “New -> Android Project” no Eclipse. Além das ferramentas para o Eclipse, existe um bom número de ferramentas para rodar e debugar aplicações, incluindo um emulador muito simpático e funcional.

Estrutura de um projeto Android:

Uma das coisas mais importantes do projeto Android é o arquivo AndroidManifest.xml, que contém a descrição e as configurações básicas da aplicação. Por exemplo, o arquivo descreve todas as Activities/Intents/etc… incluídas na aplicação, além de configurações sobre segurança e acesso a recursos.

O diretório bin/ é onde o binário da aplicação é armazenado depois de compilado, o diretório src/ contém as fontes do programa, os diretórios res/ e assets/ guardam arquivos (recursos) que sua aplicação utiliza, sendo o assets/ utilizado para arquivos estáticos e o res/ para arquivos que são alterados ou usados dinamicamente e finalmente o diretório libs/ onde são colocados qualquer JAR externo que seja utilizado pela aplicação.

O diretório res/ é bem interessante. Existe uma classe automaticamente gerada pelo build do Android que se chama R.java. Esse R.java mapeia o conteúdo do diretório res/ e seus subdiretórios para variáveis acessíveis no código java. Por exemplo, um ícone que está salvo em res/drawable/icon.png pode ser acessado por:

R.drawable.icon

O diretório res/ tem alguns subdiretórios definidos: res/drawable para imagens, res/layout para os XML definindo o layout das Activities, res/menu guardando os XML definindo os Menus, res/raw para arquivos gerais (um TXT a ser incluído, por exemplo), res/values para strings e outros valores a serem referenciados no código e res/xml para arquivos XML em geral.

Produto compilado:

O produto final da estrutura acima é um arquivo .apk, sem assinatura, que pode ser usado em telefones em modo debug e no emulador, um arquivo com seus recursos (do diretório res/) compactados e o AndroidManifest.xml ali no meio também.
Aplicativos Android tem de ser assinados digitalmente para serem distribuídos, isso é feito com o jarsigner mesmo. A versão de debug é assinada com uma chave especial de debug.

Em tempo: os posts seguem a mesma estrutura do livro “The Busy Coder’s Guide to Android Development“. Ótimo livro para iniciantes. O serviço de assinatura dele é legal, você paga 35 dólares e por um ano tem acesso aos PDF’s de todos os livros e atualizações.

Programando Androids – Parte 1

Nos últimos dias eu vendi meu HTC Tytn II e troquei por um T-Mobile G1 rodando Android. Tenho de dizer que de todos os sistemas operacionais para telefones que eu já usei, o Android é o que mais me deixou satisfeito. Ainda faltam uns cantos para serem lapidados, mas de saída ele já é bem melhor que Symbian e Windows Mobile.

De quebra, eu resolvi baixar o SDK do Android para dar uma olhada e acabei programando um bocadinho e pegando gosto pela coisa. Mesmo sendo Java. Eu tenho (tinha?) uma certa ojeriza de Java mas como a unica opção para o Android era essa, fazer o quê né. Resolvi escrever esses posts porque a medida que eu for entendendo e descobrindo novas coisas eu acabo revisando o conhecimento.

Tipos de aplicações Android:

Quando você faz uma aplicação Android, ela pode ser formada de Activities, Content Providers, Intents ou Services. Se não me engano, você pode inclusive ter vários destes em uma única aplicação.

Activities (Atividades) são basicamente janelas ou coisas visíveis do seu programa. Um diálogo, uma janela mostrando dados ou widgets para entrada de dados, etc.. Tudo isso são Activities.

Content Providers (Provedores de Conteúdo) são ‘ganchos’ que você cria em seu programa para disponibilizar informações para outros programas. O Android tem um conceito bem compartimentado, cada aplicação tem seu próprio processo, espaço em disco e memória, os Content Providers fornecem uma forma de disponibilizar informações de seus programas para outros.

Intents (Intento ou Intenção) são a versão Android de mensagens entre processos e eventos. Basicamente um Intent é um ‘sinal’ que é enviado DA sua aplicação ou PARA a sua aplicação. Por exemplo, quando uma mensagem SMS chega, um Intent é disparado para avisar a todas aplicações dessa mensagem, sua aplicação por exemplo pode observar esse Intent e fazer algo para responder ao mesmo. Da mesma forma, você pode criar um Intent na sua aplicação que será enviado ao sistema (e a alguma aplicação que esteja esperando por ele).

Services (Serviços) são os programas que ficam ‘na memória’ e não tem uma janela ou diálogo. Como os daemons do linux/unix. Serve para repetir aquelas tarefas que tem de acontecer mesmo com o programa não estando ativo, como checar emails, continuar tocando música depois de fechar a tela do player propriamente dida.

Para todos estes tipos de aplicações, estão disponíveis todos os recursos do Android: Armazenamento (na memória interna ou no cartão SD), Rede, Multimídia (câmeras, decodificadores de vídeo e áudio via hardware), GPS e serviços telefônicos como envio de SMS e chamadas.

Em tempo: os posts seguem a mesma estrutura do livro “The Busy Coder’s Guide to Android Development“. Ótimo livro para iniciantes. O serviço de assinatura dele é legal, você paga 35 dólares e por um ano tem acesso aos PDF’s de todos os livros e atualizações.

Desenvolvimento seguro e software livre

Acabei a poucos dias atrás de escrever o trabalho final da faculdade. Para o trabalho eu conversei com o kov sobre segurança no Gnome e Debian, com o Mark que coordena um grupo de segurança do Apache e com alguns desenvolvedores do WordPress. Eu também tentei incluir o OpenBSD mas aparentemente a paranóia deles é meio grande demais (não consegui informações além das que estão no site).

O que eu conclui foi que os projetos de software livre tem sérios problemas quando se fala de desenvolvimento seguro. Claro que a amostragem que eu tenho não representa nada quantitativamente, mas qualitativamente estamos falando de uma grande distrubuição, um web server que serve metade da WWW, um ambiente gráfico que é padrão em várias distribuições e uma plataforma de blogs que é a mais utilizada. Então eu me sinto confortável em generalizar a situação.

Uma parte do meu trabalho era também sugerir algumas práticas para melhorar essa situação e colocar um mínimo de desenvolvimento seguro nos projetos que existam ou ainda vão existir. Eu sei que isso também é um bocado ambicioso, mas no mundo livre todo mundo pode contribuir com algo que pode vir a ser uma boa idéia

Eu vou fazer posts nos próximos dias descrevendo as 4 práticas que eu descrevi como melhores práticas, baseado nos Touchpoints de Gary McGraw, o SDL da Microsoft e o CLASP do OWASP.

Stay tuned.

intel