sob a Licença Creative Commons BY-SA 3.0. http://creativecommons.org/licenses/by-sa/3.0/legalcode ✗ Os fontes deste documento estão disponíveis em: http://e-labworks.com/treinamentos/android/source
de 17 anos de experiência em desenvolvimento de software para sistemas embarcados, em diversas arquiteturas de CPU (ARM, PPC, MIPS, x86, 68K), atuando em projetos com Linux embarcado e sistemas operacionais de tempo real. ✗ É sócio da Embedded Labworks, onde atua com consultoria, treinamento e desenvolvimento de software para sistemas embarcados: http://e-labworks.com ✗ Mantém um blog pessoal sobre Linux e sistemas embarcados em: http://sergioprado.org
sistema de build, embarcando o Android, camada nativa, processo de inicialização. ✗ DIA 2: Customizando o Android, produtos, módulos, framework Android, JNI. ✗ DIA 3: Aplicações Android, HAL, debugging.
Android Inc. em Palo Alto/CA, focada no desenvolvimento de um sistema operacional aberto para smartphones. ✗ 2005: Android Inc. comprada pelo Google. ✗ 2007: Criada a Open Handset Alliance, um consórcio de empresas com interesse na área mobile (Google, Intel, TI, Qualcomm, Nvidia, Motorola, HTC, Samsung, etc). ✗ 2008: Sai a versão 1.0 do Android.
de duas novas versões são lançadas. ✗ Cada versão tem o nome de uma sobremesa, liberada em ordem alfabética! ✗ 2.2 (Frozen Yogurt) ✗ 2.3 (Gingerbread) ✗ 3.0/3.1/3.2 (Honeycomb) ✗ 4.0 (Ice Cream Sandwich) ✗ 4.1/4.2/4.3 (Jelly Bean) ✗ Este treinamento é baseado no Jelly Bean 4.2.
com uma experiência familiar. ✗ Ecossistema de aplicações disponíveis (aproximadamente 850.000 aplicações em set/2013). ✗ Framework para desenvolvimento de aplicações. ✗ Ambiente de desenvolvimento completo (SDK) incluindo IDE, emulador e ferramentas de debugging.
basicamente baseado em dois grandes projetos: ✗ Kernel Linux (modificado). ✗ Plataforma Android (AOSP). ✗ A cada versão, o Google libera o código-fonte do projeto através do Android Open Source Project (AOSP). http://source.android.com/ ✗ Apenas alguns dispositivos são suportados pelo AOSP, incluindo os últimos smartphones e tablets de referência do Google.
projeto, mas a comunidade é bem fechada em torno do Google. https://android-review.googlesource.com ✗ O processo de colaboração é realizado através da ferramenta de revisão de código Gerrit, também criada pelo Google. http://en.wikipedia.org/wiki/Gerrit_(software)
sob as licenças permissivas ASL (Apache) e BSD, dando liberdade aos fabricantes de decidirem se desejam liberar o código-fonte alterado (licenças permissivas exigem apenas atribuição de autoria). ✗ Alguns pacotes ainda estão sob as licenças GPL/LGPL (vide diretório external/ no AOSP). ✗ Algumas aplicações do Google são fechadas (Google Play, Gmail, Google Maps, Youtube, etc) e para tê-las você precisa se certificar (ACP).
a marca Android e possa usar as aplicações do Google, é necessário certificá-lo através do Android Compatibility Program (ACP): ✗ Compliance Definition Document (CDD): descreve os requisitos necessários (software e hardware) para que um dispositivo possa ser considerado compatível com Android. ✗ Compliance Test Suite (CTS): ferramenta para testes unitários do framework do Android (APIs, Dalvik, permissões, etc), que deve ser realizado no dispositivo. ✗ Cada versão do Android tem os seus documentos! Mais informações no link abaixo: http://source.android.com/compatibility/
do hardware (U-Boot é comum em plataformas abertas). ✗ Kernel Linux é alterado para suprir as necessidades do Android (IPC, shared memory, power management, etc). ✗ Já o espaço de usuário é totalmente diferente de uma distribuição Linux convencional como o Ubuntu ou o Fedora! ✗ Muitas bibliotecas e aplicações foram reimplementadas por questões de licença (uclibc x bionic, busybox x toolbox, etc). ✗ Todo o framework de desenvolvimento de aplicações é baseado em Java.
com os requisitos do Android. 2. Portar o bootloader para a plataforma de desenvolvimento. 3. Portar o kernel Linux para a plataforma de desenvolvimento (com os patches do Android aplicados). 4. Preparar o sistema de build do Android para compilar e gerar uma versão customizada da plataforma Android para o seu hardware. 5. Implementar a camada HAL do Android para os dispositivos de hardware presentes no sistema.
de uma máquina de 64 bits com o Ubuntu 12.04, já que esta é a configuração usada e testada pelo Google, mas o sistema de build deve funcionar em outras máquinas Linux ou MacOS (instalação nativa ou máquina virtual). ✗ É necessário uma máquina com boa capacidade de processamento (ex: Core i7) e com bastante espaço em disco (os fontes do Android 4.2 ocupam 6G de disco, passando de 25G depois de compilado!). ✗ Pré-requisitos de software: git 1.7+, python 2.6/2.7, make 3.81/3.82, JDK 6. ✗ Consulte o link abaixo para instruções mais completas: http://source.android.com/source/initializing.html
do AOSP em: http://source.android.com/source/index.html ✗ Neste link você vai encontrar detalhes sobre como: ✗ Baixar o código-fonte. ✗ Configurar o sistema de build. ✗ Compilar o Android para um dispositivo padrão do Google (últimos smartphones e tablets do mercado). ✗ Testar a imagem gerada no emulador.
versionado pelo Google através do git. ✗ Porém, o projeto é dividido em vários repositórios git (se o projeto fosse gerenciado por apenas um repositório git, seria lento para baixar e difícil de gerenciar!). ✗ Os repositórios git do Android podem ser acessados em: http://android.googlesource.com
repositórios git existentes no AOSP, o Google então criou uma ferramenta chamada repo. ✗ Esta ferramenta pode ser baixada do site do Google conforme abaixo: wget https://dlssl.google.com/dl/googlesource/gitrepo/repo ✗ Com o repo é possível baixar e gerenciar uma versão específica do Android, composta por diversos repositórios git, descritos em um arquivo XML (manifest.xml).
init u https://android.googlesource.com/platform/manifest $ repo sync [...] Aqui ele vai clonar cada um dos repositórios git! $ ls abi dalvik frameworks Makefile prebuilts bionic development gdk ndk sdk bootable device hardware out system build docs libcore packages cts external libnativehelper pdk
diff em todos os repositórios git). ✗ repo status (verifica o status de todos os repositórios git). ✗ repo start (cria um novo branch em um projeto para desenvolvimento). ✗ repo branches (visualizar branches existentes). ✗ repo forall (executa um comando em todos os repositórios git). ✗ repo help (exibe menu completo de opções).
ferramenta chamada Gerrit para facilitar o processo de revisão de código e colaboração. https://android-review.googlesource.com ✗ Através das ferramentas git e repo qualquer pessoa pode contribuir com o desenvolvimento do Android: ✗ Crie um novo branch: $ repo start <nome_do_branch> ✗ Faça os commits com o git. ✗ Suba o código para revisão no Gerrit: $ repo upload
o repositório principal mas oferece suporte limitado à dispositivos de hardware. ✗ BSP do fabricante pode fornecer bom suporte mas normalmente é mais desatualizado. ✗ A Linaro fornece uma árvore alternativa e atualizada com suporte à um conjunto maior de dispositivos de hardware (ARM): https://wiki.linaro.org/Platform/Android
possui versões customizadas focada em dispositivos de mercado (smartphones e tablets): http://cyanogenmod.org/ ✗ A comunidade de uma determinada plataforma de hardware pode manter uma árvore separada do Android (Rowboat para os chips Sitara da TI, Wandboard, etc).
git://www.wandboard.org/android/manifest.git m default.xml $ repo sync j4 [...] $ ls abi dalvik frameworks libnativehelper prebuilts bionic development gdk Makefile sdk bootable device hardware ndk system build docs kernel_imx packages cts external libcore pdk ✗ Instruções para baixar o código-fonte do Android para a Wandboard no link abaixo: http://www.wandboard.org/index.php/downloads
de referência e imagem de recovery. ✗ kernel_imx/: kernel para a Wandboard (i.MX6), não existe no AOSP! ✗ hardware/: implementação padrão e interface HAL. ✗ device/: configurações e componentes específicos do dispositivos suportados (produtos).
do Android. ✗ system/: aplicações e bibliotecas da camada nativa. ✗ external/: projetos externos usados no Android (openssl, webkit, libusb, etc). ✗ abi/: suporte à RTTI (Run-Time Type Identification) para código escrito em C++. ✗ libnativehelper/: biblioteca para interface JNI.
Development Kit), que possibilita o desenvolvimento de aplicações nativas para o Android. ✗ sdk/: ferrramentas do SDK (Software Development Kit). ✗ pdk/: ferramentas do PDK (Platform Development Kit). ✗ development/: outras ferramentas de desenvolvimento e aplicações de debugging. ✗ cts/: ferramentas do CTS (Compatibility Test Suite).
e outros componentes do sistema de build. ✗ prebuilts/: binários pré-compilados, incluindo os toolchains. ✗ docs/: conteúdo do site http://source.android.com.
dois principais objetivos: ✗ Integrar todos os componentes de software de um sistema Linux (toolchain, bootloader, kernel, filesystem). ✗ Tornar o processo de build reproduzível. ✗ O Linux possui vários sistemas de build disponíveis, como por exemplo o Buildroot, OpenEmbedded e Yocto. ✗ Já o Android tem sua própria solução de sistema de build!
de build do Android é baseado na conhecida ferramenta make do projeto GNU, onde diversos Makefiles (Android.mk) estão espalhados pelos diretórios do código-fonte. ✗ Mas não existe nenhum sistema de configuração para definir o que vai ser compilado, como o menuconfig do Buildroot (kconfig). ✗ A configuração do que será compilado (produto) depende basicamente de variáveis de ambiente do shell.
sistema de build é executar o script de configuração do ambiente build/envsetup.sh: $ source build/envsetup.sh ✗ Este script irá alterar o ambiente corrente do shell, definindo alguns comandos, variáveis de ambiente e macros que serão usadas durante a compilação. ✗ O comando source é necessário para que as alterações aconteçam no ambiente corrente do shell.
no ambiente corrente do shell: ✗ lunch: selecionar o combo (produto e variante) para compilar. ✗ croot: voltar para o diretório principal dos fontes. ✗ godir: ir para o diretório contendo o arquivo especificado. ✗ cgrep: executar um grep em todos os arquivos .c, .cpp e .h. ✗ jgrep: executar um grep em todos os arquivos .java. ✗ resgrep: executar um grep em todos os arquivos .res. ✗ hmm: exibe a lista completa de comandos.
o próximo passo é configurar o produto que desejamos compilar. ✗ Um produto no Android esta associado à um conjunto de características específicas, incluindo: ✗ Arquitetura do dispositivo de hardware. ✗ Configurações do sistema. ✗ Conjunto de módulos habilitados (aplicações nativas, bibliotecas nativas, aplicações Android, binários pré-compilados, etc).
é baseada em algumas variáveis de ambiente que precisam ser definidas, dentre elas: ✗ TARGET_PRODUCT: nome do produto. ✗ TARGET_BUILD_VARIANT: variante do produto (eng, user, userdebug). Dentre todos os módulos habilitados para o produto, apenas aqueles correspondentes à variante selecionada serão incluídos na imagem final. ✗ Você pode definir as variáveis de configuração do produto em um arquivo chamado buildspec.mk e salvá-lo no diretório principal dos fontes (vide build/buildspec.mk.default). ✗ Mas a forma mais comum é carregar a configuração do produto através do comando lunch.
uma lista de produtos no formato <produto><variante>, também chamado de combo, e o usuário deverá selecionar um destes combos. ✗ É possível também executar o comando lunch passando diretamente o nome do combo: $ lunch fulleng ✗ Ao selecionar o combo, o comando lunch irá criar as variáveis de ambiente necessárias para a compilação: $ env | grep "ANDROID\|TARGET"
comando make: $ make ✗ O processo de compilação pode levar algumas horas, dependendo da máquina de build. ✗ Use o parâmetro j se necessário para paralelizar o processo de compilação. $ make j4
componentes do Android (aplicações, bibliotecas, etc) são divididos em módulos, e cada módulo possui um arquivo Android.mk, contendo suas regras de processamento. ✗ Ao iniciar o processo de compilação, o sistema de build do Android faz uma busca recursiva por todos os arquivos Android.mk. ✗ Caso o módulo correspondente ao Android.mk encontrado esteja habilitado para o produto selecionado, seu conteúdo é adicionado à um arquivo de Makefile integrado.
montar este arquivo de Makefile integrado, o sistema de build inicia a compilação através do processamento deste Makefile. ✗ Assim que terminar de compilar todos os módulos descritos neste Makefile, as imagens finais são geradas (ramdisk, system, data).
compilação, as imagens estarão disponíveis no diretório out/, com os subdiretórios host/ e target/. ✗ No diretório out/host/ temos ferramentas, binários e bibliotecas compiladas para o host (ex: emulator, mke2fs, etc). ✗ No diretório out/target/ temos os binários compilados para o target. ✗ As imagens finais estarão disponíveis no diretório out/target/product/<nome_do_produto>/.
produto selecionado: $ make clean ✗ Limpar a compilação de todos os produtos: $ make clobber ✗ Limpar apenas o necessário em uma troca de configuração (produto): $ make installclean
executados durante a compilação: $ make showcommands ✗ Compilar apenas um pacote: $ make <pacote> ✗ Limpar a compilação de um pacote: $ make clean<pacote>
de qualquer diretório $ m ✗ Compilar todos os módulos no diretório corrente: $ mm ✗ Compilar todos os módulos de um diretório específico: $ mmm <diretório>
dispositivos móveis, capaz de rodar na máquina host e emular o sistema gerado. ✗ Este emulador pode ser compilado através dos produtos full, full_x86 e full_mips. ✗ É capaz de emular a interface com o usuário via monitor, teclado e mouse. ✗ Diversos outros dispositivos de hardware e eventos como coordenadas GPS, recebimento de SMS ou mudança de status da bateria podem ser emulados através de uma conexão telnet.
ARM, x86 e MIPS. ✗ O mais comum é encontrar o Android rodando em plataformas ARM, em específico ARMv7 (Cortex-A8) com um ou mais núcleos rodando acima de 1GHz. ✗ Arquiteturas como x86 e MIPS também são suportadas por outras empresas ou pela comunidade: http://www.android-x86.org/ http://developer.mips.com/android/ ✗ A partir do Android 4.0, é necessário também uma GPU com suporte à OpenGL ES 2.0.
necessário no mínimo 340MB de RAM, mas é bem típico um sistema com 1GB. ✗ Para o armazenamento, são necessários 300MB para o sistema, mais 300M para armazenar dados e 1G de armazenamento compartilhado (normalmente no cartão SD) para armazenar dados das aplicações (imagens, vídeos, documentos, etc). ✗ Atualmente, é comum o uso de dispositivos de armazenamento de bloco ao invés de memória flash. O mais comum é utilizar chips eMMC.
por: ✗ Inicialização básica do hardware. ✗ Carregar outro binário (normalmente um sistema operacional) da memória flash, da rede ou de outro dispositivo de armazenamento não volátil para a RAM. ✗ Passar o controle da CPU para este binário. ✗ Além destas funcionalidades básicas, a maioria dos bootloaders possui uma linha de comandos para a execução de diferentes operações, como verificação de memória, formatação da flash e rotinas de diagnóstico.
trabalho em especial no bootloader para o Android, apenas que ele seja capaz de carregar a imagem do Linux e do ramdisk, e passar o controle da CPU para o kernel. ✗ Normalmente cada fabricante de hardware disponibiliza um bootloader (o U-Boot é padrão em plataformas abertas). ✗ Uma funcionalidade normalmente presente em bootloaders para o Android é o fastboot, um protocolo de comunicação com bootloaders via USB. http://goo.gl/WYyd5
Possui as seguintes funcionalidades: ✗ Transmissão de dados para o bootloader. ✗ Gravação de imagens na flash. ✗ Leitura de variáveis de configuração do bootloader. ✗ Controle da sequência de boot.
] <command> commands: update <filename> reflash device from update.zip flashall flash boot + recovery + system flash <partition> [ <filename> ] write a file to a flash partition erase <partition> erase a flash partition format <partition> format a flash partition getvar <variable> display a bootloader variable boot <kernel> [ <ramdisk> ] download and boot kernel flash:raw boot <kernel> [ <ramdisk> ] create bootimage and flash it devices list all connected devices continue continue with autoboot reboot reboot device normally rebootbootloader reboot device into bootloader help show this help message
parte da plataforma Android, e portanto, não será encontrado no AOSP. ✗ Mas o fabricante do hardware normalmente integra a compilação do bootloader ao sistema de build do Android. ✗ O arquivo build/core/Makefile é alterado para compilar o bootloader. ✗ O código-fonte do bootloader é normalmente disponibilizado em bootable/bootloader.
Biblioteca Aplicação User space Kernel Aplicação Aplicação Chamadas de sistema Notificação de eventos Exportação de informações Gerenciamento do hardware Notificação de eventos
fazem as distribuições, o kernel Linux usado no Android é alterado para suprir as necessidades do projeto. ✗ Porém, as mudanças no kernel são tão significativas (centenas de patches) que os componentes de espaço de usuário do Android não funcionarão com um kernel Linux padrão. ✗ No momento, boa parte das alterações já estão integradas à versão oficial do kernel (a maioria em drivers/staging/android), sendo possível subir um sistema Android com uma versão vanilla do kernel.
ao kernel a capacidade de invocação remota de objetos. ✗ Toda a comunicação entre os serviços do sistema, ou mesmo entre componentes de uma aplicação, acontecem via Binder. Sem ele, o Android não funciona! ✗ O serviço do Binder é exposto para o usuário via /dev/binder, que pode ser acessado através de chamadas ioctl().
mecanismo de compartilhamento de memória entre processos. ✗ Algumas deficiências no mecanismo de compartilhamento de memória padrão do Linux (POSIX SHM), como o vazamento de recursos, levaram a criação deste novo mecanismo pelo Google. ndk/docs/system/libc/SYSVIPC.html ✗ Por exemplo, esta implementação usa um contador de referência para destruir regiões de memória que não estão mais sendo usadas. ✗ Via interface /dev/ashmem uma aplicação requisita uma região de memória e compartilha com outros processos via Binder.
de consumo de energia, que podem ser usados pelo Linux para reduzir o consumo durante a execução do sistema. ✗ Quando você fecha um notebook por exemplo, o kernel coloca o sistema automaticamente no modo suspenso, onde apenas a memória RAM fica alimentada, economizando energia. ✗ Em smartphones não é possível usar a mesma técnica, já que, mesmo desligado, o smartphone pode estar executando outra função (tocando uma música, instalando uma aplicação, etc).
este problema são os wakelocks, onde o usuário (aplicação, driver) utiliza uma API para definir quando o sistema pode entrar no modo de baixo consumo. ✗ O sistema entra em modo de baixo consumo sempre que possível (quando nenhum processo estiver segurando um wakelock).
um mecanismo de timer capaz de acordar o sistema quando o mesmo encontra-se em modo suspenso. ✗ Timers ou HRT (High Resolution Timers) são capazes de acordar um processo, mas não um sistema em modo suspenso. ✗ Um RTC é capaz de acordar um sistema em modo suspenso, mas não um processo.
um driver do kernel que integra as funcionalidades de RTC e Timer do Linux, sendo capaz de acordar um processo, mesmo com o sistema em modo suspenso. ✗ O acesso é exportado para o usuário através do arquivo /dev/alarm, possibilitando sua configuração através de chamadas ioctl().
sem memória, o Linux executa o OOM (Out-of- Memory) Killer, que pode matar alguns processos para liberar memória. ✗ Esse processo não é previsível, e pode matar um processo importante do sistema Android. ✗ O Low Memory Killer é uma implementação que é executada antes do OOM Killer: ✗ Leva em consideração a prioridade e a ociosidade do processo antes de matá-lo. ✗ Notifica a aplicação, possibilitando-a salvar seu estado antes de ser encerrada.
depurar um sistema, seja durante a execução ou depois que o problema aconteceu. ✗ Em uma distribuição Linux, normalmente dois componentes estão envolvidos no sistema de log: ✗ Logs do kernel emitidos via printk() e exibidos via comando dmesg. ✗ Daemon de log do sistema, que gerencia os logs das aplicações via função syslog() e normalmente armazena os logs em /var/log/. ✗ Estes mecanismos podem impactar a performance do sistema: ✗ O log via syslog() é realizado através de sockets, gerando trocas de contexto que pode ser custosas para o sistema. ✗ O log é normalmente salvo em uma unidade de armazenamento de baixa velocidade (disco) ou com limites de escrita (flash).
do kernel que cria 4 buffers circulares em uma região de memória do kernel. ✗ main: buffer principal usado pelas aplicações. ✗ system: buffer de uso interno do sistema. ✗ events: buffer de eventos usado internamente pelo framework do Android. ✗ radio: buffer específico do módulo de radio. ✗ Os logs são expostos para o usuário via /dev/log/, e são acessados normalmente pelas aplicações nativas via liblog. ✗ É possível visualizar os logs com a ferramenta logcat.
camada de input do kernel um clock monotônico. ✗ Interactive cpufreq governor: gerencia a velocidade da CPU, mantendo-a em um estado de baixo consumo o máximo possível, e aumentando a velocidade da CPU quando o usuário interage com o dispositivo. ✗ Android Gadget Driver: driver para a conexão ADB. ✗ RAM console: mantém o último buffer de log do kernel em /proc/last_kmsg ao reiniciar o sistema.
controle de acesso à rede por aplicação (GID). ✗ Goldfish emulator: suporte ao emulador Goldfish no kernel. ✗ Netfilter: Alterações para permitir contabilização do uso da rede pelas aplicações. ✗ Timed GPIOs: suporte à GPIOs temporizados.
o fabricante do SoC disponibiliza um porte do kernel Linux com as alterações do Android. ✗ Verifique se existe suporte na comunidade para o seu SoC (Linaro, CyanogenMod, etc). ✗ Contrate ou adquira de uma empresa o BSP Android para a sua plataforma. ✗ Aplique você mesmo os patches do Android no kernel (pode ser necessário algum tipo de adaptação dependendo da versão do kernel). https://android.googlesource.com/kernel/common.git
parte da plataforma Android, e portanto, não será encontrado no AOSP. ✗ Mas o fabricante do hardware normalmente integra a compilação do kernel ao sistema de build do Android. ✗ O arquivo build/core/Makefile é alterado para compilar o kernel. ✗ O código-fonte do kernel é normalmente disponibilizado no diretório principal do código-fonte do Android.
driver para uma plataforma que irá rodar o Android, teste e depure em um sistema GNU/Linux comum. ✗ Depois que o driver estiver rodando e funcionando, comece a trabalhar na camada Android.
usados para organizar dados, de forma hierárquica, em diretórios e arquivos disponíveis em dispositivos de armazenamento (locais ou remotos). ✗ Em sistemas Unix, aplicações e usuários enxergam apenas uma hierarquia única e global de arquivos e diretórios, que podem ser compostos por diferentes sistemas de arquivo. ✗ Um ou mais sistemas de arquivo são montados em locais específicos nesta hierarquia de diretórios. ✗ Quando montamos um sistema de arquivo em um diretório, chamados este diretório de ponto de montagem.
arquivo específico é montado na raiz principal da hierarquia, identificado pelo /. ✗ Este sistema de arquivo é chamado de root ou rootfs. ✗ É responsabilidade do kernel montar o rootfs, de acordo com a opção root passada na linha de comandos do kernel.
em sistemas Linux é padronizada pela Filesystem Hierarcy Standard. http://www.pathname.com/fhs/ ✗ A maioria dos sistemas Linux estão de acordo com este padrão: ✗ As aplicações esperam este formato. ✗ Facilita o trabalho de usuários e desenvolvedores quando precisam trabalhar com diferentes sistemas Linux. ✗ Mas o Android foge à regra!
do Android é composto por 3 principais componentes: ✗ Camada nativa: bibliotecas e aplicações que rodam fora da máquina virtual Java. ✗ Framework Android: serviços do sistema, classes java e API para o desenvolvimento de aplicações. ✗ Aplicações Android. ✗ Estes componentes estão distribuídos em três imagens diferentes (initrd, system e data), montados respectivamente nos diretórios /, /system e /data.
a imagem do RAM disk (rootfs) e executa o processo init. ✗ O init processa os arquivos de configuração, inicializando o sistema e montando os outros sistemas de arquivo: ✗ system: binários e bibliotecas nativas, bibliotecas Java, arquivos de configuração e aplicações padrão (normalmente montado como somente leitura). ✗ data: aplicações instaladas pelo usuário, dados do usário, etc. ✗ cache: arquivos temporários, downloads em andamento, etc. ✗ sdcard: arquivos e documentos do usuário (vídeos, sons, imagens, etc), normalmente montado com vfat. Não é essencial para o funcionamento do sistema.
arquivo virtual proc. /sys Montado com o sistema de arquivo virtual sysfs. /acct Montado com o sistema de arquivo virtual cgroupfs. /config Montado com o sistema de arquivo virtual configfs. /dev Montado com tmpfs e gerenciado pelo ueventd. /d Link para o diretório /sys/kernel/debug, onde normalmente fica montado o sistema de arquivo virtual debugfs.
arquivos de configuração. /sbin Contém as aplicações ueventd e adbd. /mnt Ponto de montagem temporária. /root Home do usuário root, normalmente vazio no Android. /vendor Link para /system/vendor, contendo arquivos específicos do fabricante do hardware (opcional).
a partição system, onde é montada a imagem system.img. /data Ponto de montagem para a partição data, onde é montada a imagem userdata.img. /storage Ponto de montagem para o cartão SD (antigamente montado em /sdcard). /cache Ponto de montagem para a partição cache, usada para armazenar arquivos temporários, downloads em andamento, etc.
Binários externos (não essenciais ao funcionamento do sistema). /lib Bibliotecas do sistema. /framework Arquivos jar do framework Java. /modules Módulos do kernel.
/appprivate Diretório de instalação das aplicações com proteção de cópia habilitada. /appasec Aplicações encriptadas. /data Contém um diretório para cada aplicação instalada (home das aplicações).
Java. /local Diretório com permissão de escrita para qualquer usuário. /property Armazena as propriedades persistentes do sistema. /system Banco de dados do sistema (contas, lista de aplicações instaladas, etc).
é fortemente baseado em credenciais (UID/GUI) e permissões de arquivos e diretórios. ✗ Para incluir um novo usuário/grupo ou alterar a permissão de um arquivo ou diretório, é necessário alterar um arquivo de cabeçalho do sistema: system/core/include/private/android_filesystem_config.h ✗ Este arquivo é processado durante a compilação do Android.
colocar um sistema GNU/Linux lado-a-lado com um sistema Android, porque: ✗ A maioria dos diretórios do rootfs são pontos de montagem de um sistema de arquivo virtual ou links para outros diretórios do sistema. ✗ Quase todo o sistema Android esta localizado nos diretórios /system e /data.
uma ferramenta de debugging desenvolvida pelo Google que possibilita o acesso via USB ou TCP/IP à qualquer dispositivo Android. ✗ Com o ADB, dentre outras opções, é possível: ✗ Iniciar uma seção do shell. ✗ Ler e copiar arquivos do dispositivo. ✗ Exibir o log do sistema. ✗ Debbuging com GDB ou JDB. ✗ Estudaremos o ADB com mais detalhes na seção de Debugging.
Android é composta por todos os componentes do espaço de usuário que rodam fora da máquina virtual Java: ✗ Bibliotecas, incluindo a biblioteca C do sistema (Bionic). ✗ Ferramentas de linha de comando. ✗ Daemons responsáveis por prover determinada funcionalidade ou acesso à determinado recurso do sistema. ✗ Por questões de licença de software, a camada nativa do Android foi praticamente escrita do zero. Em alguns casos, é bastante diferente do que vemos em um sistema Linux tradicional!
bibliotecas que podem ser usadas pelas aplicações, todas disponíveis no rootfs em /system/lib: ✗ Algumas bibliotecas são populares em sistemas Linux, como por exemplo libssl, libexpat, libjpeg, libsqlite e libwebcore. ✗ Outras foram reimplementadas com o objetivo de deixar a biblioteca mais leve e simples de usar, como por exemplo a libtinyalsa. ✗ Outras são específicas do Android, como por exemplo libbinder, libutils e liblog. ✗ O código-fonte das bibliotecas esta disponível nos diretórios bionic/, system/core/, external/ e frameworks/base/. ✗ Uma das bibliotecas mais importantes é a biblioteca C do sistema.
um sistema Linux é a biblioteca C. ✗ A biblioteca C implementa a API do sistema operacional, provendo uma interface para as aplicações acessarem os serviços do kernel (system calls). ✗ Diversas bibliotecas C estão disponíveis para sistemas Linux, incluindo glibc, eglibc e uClibc. ✗ O Android possui a sua própria biblioteca C, a Bionic!
decidiu não usar as bibliotecas C comuns em sistemas Linux, implementando a Bionic, baseando-se na biblioteca C usada no BSD. ✗ A implementação é simples e leve, e liberada sob a licença BSD (código-fonte em bionic/). ✗ Não possui suporte total à API do padrão POSIX, o que pode dificultar o porte de aplicações Linux nativas para o Android. ✗ Mais informações sobre a Bionic em: http://androidxref.com/4.0.4/xref/ndk/docs/system/libc/OVERVIEW.html
básicas como uma aplicação init, um shell e diversas ferramentas para manipular e configurar o sistema. ✗ Normalmente estas aplicações são providas separadamente por diversos pacotes open source (coreutils, bash, grep, sed, tar, wget, modutils, etc), porém: ✗ Estes pacotes não foram desenvolvidos com o conceito de sistemas embarcados em mente. ✗ Seria trabalhoso se fosse necessário compilar separadamente cada um destes pacotes para construir um sistema Linux embarcado. ✗ Em sistemas Linux, o Busybox é uma solução para este problema, integrando diversas ferramentas e aplicações em um único pacote, com foco em sistemas com poucos recursos.
implementou uma ferramenta equivalente ao Busybox chamada Toolbox, liberando-a sob a licença BSD. ✗ O código-fonte esta disponível em system/core/toolbox/. ✗ O Toolbox é mais limitado quando comparado ao Busybox, mas inclui comandos específicos do Android (alarm, getprop, log, etc). cat chmod chown cmp date dd df dmesg hd id ifconfig iftop insmod ionice ln kill ls lsmod lsof mkdir mount mv netstat printenv ps reboot renice rm rmdir rmmod route sleep sync top umount uptime vmstat cp du grep md5 touch
kernel logo após montar o sistema de arquivos, sendo responsável pela inicialização do sistema. ✗ Sistemas Linux possuem diversas implementações do processo init, dentre elas sysvinit, systemd e upstart. ✗ O Android possui a sua própria aplicação init! ✗ Estudaremos em detalhes o processo de inicialização do Android mais adiante no treinamento.
no MirBSD Korn Shell. https://www.mirbsd.org/mksh.htm ✗ Bem mais limitado que o shell que você esta acostumado a usar no desktop! ✗ Documentação pode ser acessada no código-fonte do Android com o comando abaixo: $ man external/mksh/src/mksh.1
alguma funcionalidade do sistema: ✗ São executados na inicialização pelo processo init. ✗ Rodam em background durante todo o tempo em que o sistema esta funcional. ✗ São capazes de controlar e centralizar o acesso à um recurso do sistema. ✗ No Android, alguns daemons servem de interface entre os serviços do Android (System Services) e os recursos do sistema (gerenciamento da rede, pontos de montagem, instalação de aplicações, etc), provendo segurança no acesso à determinado recurso.
da conexão de dispositivos de hardware (device hotplugging). ✗ É o equivalente ao udev ou mdev em um sistema Linux comum. ✗ Princípio básico de funcionamento do ueventd: ✗ Recebe eventos de hotplug do kernel. ✗ Processa eventos de acordo com um conjunto de regras em /ueventd.rc e /ueventd.<device_name>.rc. ✗ Cria os arquivos de dispositivo no /dev.
de dispositivos de armazenamento. ✗ É responsável por: ✗ Montar automaticamente dispositivos de armazenamento. ✗ Formatar partições em dispositivos de armazenamento. ✗ Arquivo de configuração em /system/etc/vold.fstab (mesmo propósito do /etc/fstab em sistemas Linux).
gerencia a comunicação com o chip do modem (voz e dados). ✗ É responsável por: ✗ Discar e receber ligações. ✗ Enviar e receber SMS, MMS, etc. ✗ Estabelecer comunicação de dados com a rede GSM, GPRS, etc.
é o daemon responsável pelo gerenciamento de conexões de rede (Bluetooth, Wi-Fi, USB, etc). ✗ É responsável por: ✗ Gerenciar a configuração de interfaces de rede. ✗ Detectar e estabelecer novas conexões. ✗ Configurar tethering. ✗ Fazer uma conexão PPP.
pela instalação e desinstalação de aplicações Android (*.apk). ✗ Também é capaz de verificar integridade dos pacotes, instalar bibliotecas nativas, etc.
debugging, abrindo e esperando conexões em um UNIX socket. ✗ É invocado pelo linker da Bionic para fazer análise postmortem de um processo que finalizou de forma inesperada. ✗ Gera um arquivo de debugging em /data/tombstones e possibilita o debug via gdbserver.
conexão ADB. ✗ system_server: daemon que contém a maioria dos serviços do Android. ✗ servicemanager: responsável pelo gerenciamento da comunicação com o Binder, funcionando como um índice para todos os serviços que usam o Binder no sistema. ✗ mediaserver: responsável pelos serviços de media (audio, video, etc). ✗ keystore: gerencia o armazenamento e acesso à chaves criptográficas, como por exemplo certificados SSL.
pela codificação e decodificação de arquivos multimedia (equivalente ao gstreamer). ✗ bluedroid: stack Bluetooth, que serve de interface entre os serviços do Android e a camada HAL de acesso ao hardware. ✗ dalvik: máquina virtual Java, portável e leve, responsável por executar aplicações Android. ✗ app_process: ferramenta capaz de instanciar a Dalvik e executar uma aplicação Java.
✗ getprop: listar as propriedades do sistema. ✗ setprop: mudar uma propriedade do sistema. ✗ watchprops: monitorar em tempo-real as propriedades do sistema ✗ getevent: monitorar os eventos de dispositivos de entrada (teclado, touchscreen, mouse, botão, etc). ✗ sendevent: gerar um evento para o sistema.
log: logar uma mensagem no sistema de log do Android. ✗ logcat: exibir o log do sistema. ✗ wipe: apagar a partição system ou data. ✗ logwrapper: permite executar um comando e redirecionar as saídas padrão e de erro para o log do Android. ✗ netcfg: exibir informações e configurar as interfaces de rede.
acesso à um dispositivo de hardware normalmente é exposto para as aplicações através de entradas no /dev ou /sys. ✗ O Android se baseia em uma camada adicional chamada HAL (Hardware Abstraction Layer) para abstrair o acesso ao hardware pelo seu framework. ✗ Boa parte dos dispositivos suportados pelo Android possuem uma camada HAL, que pode variar em comportamento e interface. ✗ Estudaremos em detalhes a camada HAL mais adiante no treinamento.
para a RAM e inicia init Inicia outros serviços e aplicações Kernel Monta o rootfs indicado por ”root=” Inicia a aplicação ”init” Shell Outras aplicações Rootfs
kernel irá tentar executar uma aplicação de inicialização, também chamada de processo init. ✗ Para isso, o kernel tenta executar os binários /sbin/init, /bin/init, /etc/init e /bin/sh. ✗ Você pode passar também o nome do programa de inicialização através do parâmetro init da linha de comandos do kernel. ✗ Normalmente sistemas Android passam para o kernel a aplicação init via parâmetro, conforme abaixo: init=/init
processo init é o responsável pela inicialização do restante do sistema. ✗ Existem diferentes mecanismos de inicialização em sistemas Linux, como systemd, upstart, openrc e sysvinit (System V Init). ✗ O Android possui seu próprio mecanismo de inicialização!
Android, através de alguns arquivos de configuração, é capaz de: ✗ Configurar o sistema (montar sistemas de arquivo, exportar variáveis de ambiente, criar e definir permissões de arquivos, etc). ✗ Iniciar os daemons e gerenciar sua execução. ✗ Gerenciar eventos de hotplug de dispositivos de hardware. ✗ Monitorar as propriedades do sistema e executar ações específicas quando uma propriedade for modificada.
de configuração são utilizados para flexibilizar o funcionamento da aplicação init do Android: ✗ init.rc: arquivo de configuração principal. ✗ init.<platform_name>.rc: customizações da inicialização para a plataforma de hardware. O valor de <platform_name> é obtido do arquivo /proc/cpuinfo ou do parâmetro de boot do kernel androidboot.hardware. ✗ Outros arquivos de configuração podem ser incluídos com a diretiva import.
configuração possuem basicamente dois tipos de declaração: ✗ Ações que podem ser tomadas de acordo com algum evento do sistema: on <trigger> <command> <command> ✗ Serviços que são gerenciados pelo init: service <name> <pathname> [ <argument> ]* <option> <option>
ações resultam na execução de comandos pelo processo init. ✗ A declaração de serviços servem apenas para descrever os serviços, que normalmente são iniciados com os comandos start ou class_start, através de alguma ação disparada por um evento. ✗ São basicamente duas as fontes de eventos que podem disparar uma ação: ✗ Triggers pré-definidos de boot (earlyinit, init, earlyfs, fs, postfs, earlyboot, boot). ✗ Mudança em alguma propriedade do sistema.
são eventos gerados automaticamente pelo init no boot do sistema. ✗ Esta é a lista completa de triggers de boot, por ordem de execução: ✗ early-init ✗ init ✗ early-fs ✗ fs ✗ post-fs ✗ early-boot ✗ boot
por um evento (trigger) irá causar a execução de um ou mais comandos: on earlyinit write /proc/1/oom_adj 16 setcon u:r:init:s0 start ueventd ✗ São vários os comandos disponíveis, dentre eles chdir, chmod, chown, class_start, class_stop, copy, export, ifup, insmod, loglevel, mkdir, mount, start, stop e restart. ✗ Uma descrição (desatualizada) dos comandos esta disponível nos fontes em system/core/init/readme.txt.
gerenciados pelo processo init, declarados conforme abaixo: service <name> <pathname> [ <argument> ]* <option> <option> ✗ Esta declaração apenas descreve o serviço, mas não o inicia. ✗ Um serviço é iniciado no disparo de uma ação, através de alguns comandos como o start ou o class_start.
o serviço com a sua classe, e sim apenas pelo seu nome. critical Se o serviço reiniciar 5 vezes, reinicia o sistema em modo recovery. onrestart Executar determinado comando ao reiniciar o serviço. oneshot Executar apenas uma vez.
é executado no boot do sistema, sendo o responsável pelo gerenciamento dos eventos de hotplug gerados pelo kernel. on earlyinit start ueventd service ueventd /sbin/ueventd class core critical seclabel u:r:ueventd:s0
de hotplug e cria ou remove os arquivos de dispositivo no /dev. ✗ Os arquivos de configuração /ueventd.rc e /ueventd.<platform>.rc podem ser usados para definir as permissões dos arquivos de dispositivos criados. Exemplos: <path> <permission> <user> <group> /dev/null 0666 root root /dev/zero 0666 root root /dev/full 0666 root root /dev/graphics/* 0660 root graphics /dev/snd/dsp 0660 system audio /dev/snd/dsp1 0660 system audio /dev/snd/mixer 0660 system audio
todo sistema Android. ✗ As propriedades são armazenadas em arquivos texto e carregadas para a memória RAM no boot do Android: ✗ /system/build.prop: propriedades padrão geradas durante a compilação da imagem. ✗ /default.prop: propriedades padrão adicionais.
da plataforma (opcional). ✗ /data/property: diretório com propriedades criadas ou alteradas em tempo de execução. ✗ O processo init é o responsável pelo gerenciamento das propriedades, através de um UNIX domain socket em /dev/socket/property_service.
em tempo de compilação de diversas formas diferentes: ✗ Através da variável PRODUCT_PROPERTY_OVERRIDES na definição do produto ou no Makefile da aplicação. ✗ Criando o arquivo system.prop no diretório do produto criado. ✗ Alterando o init.rc ou outro arquivo de configuração do init. ✗ Em tempo de execução, as propriedades do sistema podem ser alteradas através da ferramenta setprop. ✗ As propriedades podem também ser monitoradas com o comando watchprops.
ler as propriedades. ✗ A permissão para alteração de propriedades é definida no código- fonte em system/core/init/property_service.c. /* White list of permissions for setting property services. */ struct { const char *prefix; unsigned int uid; unsigned int gid; } property_perms[] = { { "net.rmnet0.", AID_RADIO, 0 }, { "net.gprs.", AID_RADIO, 0 }, { "net.ppp", AID_RADIO, 0 }, { "ril.", AID_RADIO, 0 }
podem ser alteradas na compilação. persist.* Propriedades armazenadas em /data/property/, cujo valor é mantido no reboot. ctl.start Propriedade especial usada para iniciar um serviço. ctl.stop Propriedade especial usada para terminar um serviço.
capaz de gerenciar as propriedades do sistema e tomar ações baseadas nas mudanças destas propriedades. on property:ro.debuggable=1 start console service console /system/bin/sh class core console disabled user shell group log
Android, um dos principais daemons executados pelo init é o zygote, configurado no init.rc conforme abaixo: service zygote /system/bin/app_process Xzygote /system/bin zygote startsystemserver class main socket zygote stream 660 root system onrestart write /sys/android_power/request_state wake onrestart write /sys/power/state on onrestart restart media onrestart restart netd ✗ O Zygote é iniciado através do app_process, um comando capaz de iniciar a máquina virtual Java (Dalvik) e instanciar uma aplicação Java (neste caso o zygote).
Java, portável e leve, responsável por executar as aplicações Android. ✗ Projetada para executar várias instancias ao mesmo tempo, consumindo pouca memória. ✗ Duas formas de execução: ✗ portable: toda escrita em C, um pouco lenta, mas funciona em todas as plataformas. ✗ fast: otimizada para a arquitetura, mas não portável. ✗ Usa o framework de bibliotecas Java do projeto Apache Harmony.
daemons do Android, responsável por: ✗ Configurar a máquina virtual Dalvik. ✗ Pré-carregar todas as classes Java em memória. ✗ Iniciar o system server (serviços do sistema Android). ✗ Esperar conexões em um UNIX domain socket (/dev/socket/zygote) para iniciar novas aplicações. ✗ Ao receber a requisição de uma nova aplicação, cria um fork de si mesmo para executá-la.
processo separado executado pelo Zygote durante sua inicialização. ✗ Este processo é responsável por registrar todos os serviços Java do sistema, que podem ser usados pelas aplicações através da API do Android. ✗ Um dos serviços registrados, o Activity Manager, termina sua inicialização enviando um Intent do tipo Intent.CATEGORY_HOME, que faz com que a aplicação Launcher seja executada.
necessárias para a compilação de um sistema Android (plataforma de hardware, conjunto de aplicações, customizações, etc). ✗ Por padrão, o AOSP já vem com alguns produtos definidos. Por exemplo, na versão 4.2.2 do Android, são definidos vários produtos para a linha Nexus, além de um produto para a Pandaboard. ✗ Adicionar um produto é normalmente uma das primeiras tarefas ao portar o Android para uma plataforma embarcada. ✗ Os produtos disponíveis podem ser exibidos e selecionados com o comando lunch.
comando lunch, é necessário selecionar também uma variante. ✗ A variante define quais aplicações serão compiladas e incluídas na imagem final: ✗ user: build de produção, inclui módulos com a tag user ou sem definição de tags. ✗ userdebug: mesmo que a variante user, mas inclui também módulos com a tag debug, e habilita o ADB por padrão. ✗ eng: mesmo que a variante userdebug, mas inclui também módulos com as tags eng e development. ✗ Cada aplicação deve definir sua variante no arquivo de compilação Android.mk através da definição da variável LOCAL_MODULE_TAGS.
é necessário criar um diretório em device/<company>/<device>, onde estarão todos os arquivos de definição do produto. $ mkdir p device/labworks/superdroid/ ✗ E depois implementar um arquivo chamado AndroidProducts.mk, que deve incluir o Makefile do seu produto através da variável PRODUCT_MAKEFILES: PRODUCT_MAKEFILES := \ $(LOCAL_DIR)/full_superdroid.mk
implementar o makefile do produto (no nosso exemplo full_superdroid.mk). ✗ Essa é uma definição mínima do makefile: $(call inheritproduct, $(SRC_TARGET_DIR)/product/full.mk) PRODUCT_NAME := full_superdroid PRODUCT_DEVICE := superdroid PRODUCT_MODEL := Super Android robot PRODUCT_BRAND := Android
todas as aplicações que estarão presentes no produto. ✗ Normalmente isso é feito incluindo outro makefile que contém um conjunto de aplicações já pré-definidas, conforme exemplo anterior: $(call inheritproduct, $(SRC_TARGET_DIR)/product/full.mk) ✗ Estes arquivos de makefile pré-configurados estão disponíveis em no código-fonte do sistema de build em build/target/product.
específico para o seu produto, seja uma aplicação Android, biblioteca ou aplicação nativa, coloque-a dentro do diretório do produto criado. ✗ Por exemplo, uma necessidade comum é a implementação de uma aplicação Launcher específica para o seu produto. O código-fonte desta aplicação deve ir dentro do diretório do produto criado. ✗ Isso facilita a manutenção, como por exemplo ao fazer upgrade de versão do Android, já que todas as alterações do seu produto ficam centralizadas em um único diretório. ✗ Veremos como fazer isso mais adiante no treinamento.
é comum a necessidade de copiar algum arquivo diretamente para a imagem final, como por exemplo: ✗ Customização de arquivos de configuração (init.rc, vold.fstab, ueventd.rc). ✗ Inclusão de arquivos binários (firmware, shell scripts, imagem de boot, etc).
sobrescrever recursos definidos por uma aplicação sem precisar alterar o código-fonte original. ✗ Os recursos que podem ser sobrescritos incluem: ✗ Arquivos de imagens. ✗ Mensagens e strings. ✗ Arquivos de configuração das aplicações. ✗ O overlay somente é possível em arquivos de recursos (*.png, *.xml, etc). Não é possível realizar o overlay de código-fonte! ✗ Veja por exemplo uma implementação de overlay no código-fonte do Android em device/samsung/manta/overlay/.
primeiro passo é criar o diretório overlay com a mesma estrutura de diretórios do código-fonte do Android: $ tree device/samsung/manta/overlay/ ── ├ frameworks │ ── └ base │ ── ├ core │ │ ── └ res │ │ ── └ res │ │ ── ├ values │ │ │ ── └ config.xml │ │ ── └ xml │ │ ── ├ power_profile.xml │ │ ── └ storage_list.xml
no Makefile do produto usando DEVICE_PACKAGE_OVERLAYS ou PRODUCT_PACKAGE_OVERLAY: DEVICE_PACKAGE_OVERLAYS := \ device/labworks/superdroid/overlay ✗ Uma lista completa das opções que podem ser usadas no Makefile do produto estão disponíveis no código-fonte do sistema de build em build/core/product.mk.
mudar alguma propriedade padrão do sistema de duas formas: ✗ Através da variável PRODUCT_PROPERTY_OVERRIDES no makefile do produto: PRODUCT_PROPERTY_OVERRIDES := \ net.dns1=8.8.8.8 \ net.dns2=8.8.4.4 ✗ Definindo as propriedades em um arquivo chamado system.prop e salvá-lo no diretório do produto. ✗ As propriedades definidas ou alteradas serão adicionadas ao arquivo /system/build.prop e carregadas no boot do sistema.
do produto é necessário implementar também o arquivo de definição da placa BoardConfig.mk. ✗ Este arquivo contém informações específicas sobre o hardware (arquitetura da CPU, bootloader, kernel, características do hardware). ✗ Não existe uma documentação completa sobre as variáveis que podem ser definidas, e na maioria das vezes é necessário estudar o código-fonte do sistema de build para entender seu funcionamento (build/core/Makefile). ✗ Veja um exemplo completo no código-fonte do Android em device/samsung/manta/BoardConfig.mk.
passadas para o compilador C durante o processo de build. ✗ TARGET_USERIMAGES_USE_EXT4: As imagens geradas serão do tipo EXT4. ✗ TARGET_USERIMAGES_USE_UBIFS: As imagens geradas serão do tipo UBIFS. ✗ TARGET_NO_RECOVERY: Indica se a imagem de recovery deve ser gerada. ✗ BOARD_KERNEL_CMDLINE: Linha de comandos do kernel.
device/<company>/<device>, e implemente os seguintes arquivos: ✗ AndroidProducts.mk: inclua o Makefile do seu produto. ✗ <product_name>.mk: defina informações gerais sobre o produto (nome, dispositivo, módulos, overlays, etc). ✗ BoardConfig.mk: defina a configuração da plataforma de hardware (arquitetura, bootloader, kernel, etc). ✗ vendorsetup.sh: adicione o produto ao menu do comando lunch.
do Android (aplicação nativa, aplicação Android, biblioteca, etc) é chamado de módulo. ✗ As instruções sobre como compilar cada um dos módulos são definidas em arquivos de make nomeados por padrão Android.mk. ✗ O sistema de build do Android possui templates que facilitam o desenvolvimento dos arquivos Android.mk, independente do tipo do módulo.
com LOCAL_*. ✗ LOCAL_PATH indica ao sistema de build a localização do módulo. ✗ include $(CLEAR_VARS) limpa as variáveis que podem ter sido definidas por outros módulos. A lista de variáveis que são limpas podem ser visualizadas em build/core/clear_vars.mk. ✗ LOCAL_SRC_FILES contém a lista de arquivos-fonte que serão compilados.
módulo. ✗ LOCAL_MODULE_TAGS classifica o módulo através de uma tag (user, debug, eng, development, optional). ✗ include $(BUILD_EXECUTABLE) indica ao sistema de build que este módulo deve compilado como um binário.
executável no formato ELF. ✗ BUILD_SHARED_LIBRARY compila e gera uma biblioteca de forma dinâmica. ✗ BUILD_STATIC_LIBRARY compila e gera uma biblioteca de forma estática. ✗ BUILD_JAVA_LIBRARY compila e gera uma biblioteca Java (*.jar). ✗ BUILD_STATIC_JAVA_LIBRARY compila e gera uma biblioteca Java de forma estática.
um binário bare-metal (ex: bootloader). ✗ BUILD_RAW_STATIC_LIBRARY compila e gera uma biblioteca bare-metal. ✗ BUILD_PACKAGE compila e gera uma aplicação Android. ✗ BUILD_PREBUILT instala arquivos pré-compilados no target. ✗ BUILD_MULTI_PREBUILT instala múltiplos arquivos pré- compilados no target.
um executável para o host. ✗ BUILD_HOST_SHARED_LIBRARY compila e gera uma biblioteca de forma dinâmica para o host. ✗ BUILD_HOST_STATIC_LIBRARY compila e gera uma biblioteca de forma estática para o host. ✗ BUILD_HOST_JAVA_LIBRARY compila e gera uma biblioteca Java para o host. ✗ BUILD_HOST_PREBUILT instala arquivos pré-compilados no host.
build, a instalação do módulo é realizada em um determinado diretório: ✗ Executáveis em /system/bin. ✗ Bibliotecas em /system/lib. ✗ Bibliotecas java em /system/framework. ✗ Aplicações Android em /system/app. ✗ É possível mudar o local padrão de instalação do módulo com a variável LOCAL_MODULE_PATH.
para o compilador C. ✗ LOCAL_SHARED_LIBRARIES definem a lista de bibliotecas dinâmicas que o módulo depende. ✗ LOCAL_PACKAGE_NAME define o nome de aplicações Android (*.apk). ✗ LOCAL_C_INCLUDES define caminhos adicionais de arquivos de cabeçalho usados pelo módulo. ✗ Uma lista completa de variáveis pode ser obtida em build/core/clear_vars.mk. ✗ Uma documentação (desatualizada) esta disponível no código-fonte em build/core/buildsystem.html.
macro mydir para retornar o diretório corrente da aplicação: LOCAL_PATH := $(call mydir) ✗ Várias outras macros estão disponíveis para uso, como por exemplo: ✗ alljavafilesunder: retorna todos os arquivos java recursivamente, a partir do diretório passado como parâmetro. ✗ allsubdircfiles: retorna todos os arquivos C recursivamente, a partir do diretório corrente. ✗ A maioria das macros estão definidas em build/core/definitions.mk.
(do diretório principal do Android): $ make <module_name> ✗ Para limpar a compilação de um módulo: $ make clean<module_name> ✗ Para listar todos os módulos que serão compilados: $ make modules
módulo, os arquivos gerados serão salvos em out/target/product/<product_name>/obj/<module_type>/ <module_name>_intermediate. ✗ Porém, a instalação do módulo na imagem final depende da definição de sua tag e do conteúdo da variável PRODUCT_PACKAGES definida na configuração do produto.
estão diretamente ligadas à variante escolhida no comando lunch: ✗ user: build de produção, inclui módulos com a tag user ou sem definição de tags. ✗ userdebug: mesmo que a variante user, mas inclui também módulos com a tag debug, e habilita o ADB por padrão. ✗ eng: mesmo que a variante userdebug, mas inclui também módulos com as tags eng e development.
(*.apk) são ignoradas. As aplicações Android precisam ser incluídas na variável PRODUCT_PACKAGES do produto para serem instaladas. ✗ Módulos com a tag optional precisam ser incluídos na variável PRODUCT_PACKAGES do produto para serem instalados.
produto em device/<company>/<device>. ✗ Use como padrão em novos módulos a tag optional, não esquecendo de incluir o nome do módulo na variável PRODUCT_PACKAGES do produto. ✗ Na dúvida sobre a implementação de um Android.mk, consulte os diversos exemplos disponíveis no código-fonte do Android.
camada responsável por prover serviços para as aplicações Android. ✗ A maioria dos componentes é baseada em Java. ✗ O framework Android se comunica com a camada nativa via JNI (Java Native Interface).
Runtime, Dalvik e Zygote. ✗ System Services. ✗ Classes Java do projeto Apache Harmony. ✗ Android API. ✗ Código-fonte em frameworks/, dalvik/ e libcore/.
Runtime, Dalvik e Zygote quando estudamos o processo de inicialização do Android. ✗ Falaremos sobre as classes Java e a API do Android quando estudarmos a camada de aplicações do sistema. ✗ Nosso foco nesta seção são os System Services, núcleo do framework Android.
do Android responsáveis por prover funcionalidades para as aplicações. Exemplos: ✗ Power Manager para gerenciamento de energia. ✗ Activity Manager para gerenciamento da execução dos componentes Android. ✗ Package Manager para gerenciamento de pacotes Android (APK). ✗ Location Manager para gerenciamento de localização (ex: GPS). ✗ O Android 4.2 possui em torno de 70 serviços!
serviços fazem parte do processo System Server, executado pelo Zygote no boot do sistema. ✗ Alguns serviços são processos que rodam nativamente e são executados pelo processo init no boot (Surface Flinger, DRM Server, Media Server).
do System Server, contém boa parte dos serviços do sistema. ✗ mediaserver: processo do Media Server, composto por serviços nativos relacionados ao framework multimídia do Android (Audio Flinger, Media Player Service, Camera Service, etc). ✗ surfaceflinger: processo do Surface Flinger, responsável por desenhar as superfícies das janelas das aplicações que serão exibidas no display. ✗ drmserver: processo do DRM Server, responsável pelo gerenciamento de conteúdos protegidos por direitos autorais.
cada processo possui seu espaço de endereçamento, provendo segurança e isolamento no acesso aos dados de outros processos. ✗ Por este motivo, para que um processo possa se comunicar com outro processo, é necessário um mecanismo de comunicação entre processos (IPC). ✗ Em sistemas Linux, temos disponíveis vários mecanismos de IPC como pipes, message queues e shared memory. ✗ No Android, o principal mecanismo de comunicação entre processos utilizado é o Binder.
inicialização do sistema, o init executa o processo servicemanager (Service Manager). ✗ O Service Manager se registra no Binder (/dev/binder) como seu gerenciador de contexto. ✗ O gerenciador de contexto do Binder serve como um índice para todos os serviços do sistema. ✗ Durante o restante do processo de inicialização, os serviços se registram no Service Manager via Binder.
(Binder driver) 1 2 Service Manager se registra no Binder como o gerenciador de contexto. 1 2 Os serviços do sistema se registram no gerenciador de contexto.
precisa usar um serviço do sistema (ex: wakelock), ela requisita para o Service Manager um ponteiro (handle) para se comunicar com o serviço (ex: Power Manager Service). ✗ Com o ponteiro, a aplicação pode invocar as operações do serviço. ✗ Este mecanismo de comunicação entre processos usando o Binder é totalmente transparente para o desenvolvedor de aplicações, que precisa conhecer apenas a API do Android.
Service /dev/binder (Binder driver) Aplicação requisita ponteiro (handle) do serviço para o Service Manager. 1 2 Aplicação 1 2 Aplicação usa o ponteiro para acessar as funções providas pelo serviço.
não são muito bem documentados, então para entender seu funcionamento na maioria dos casos você precisa ler o código-fonte! ✗ O código-fonte principal do System Server esta disponível em frameworks/base/services/java/com/android/server/Sys temServer.java, e pode ser um começo para você se aventurar nas milhares de linhas de código de cada um dos serviços do Android.
sistema iniciam algumas aplicações automaticamente no boot: ✗ O serviço Input Method Manager inicia todas as aplicações que possuem o filtro de Intent android.view.InputMethod. ✗ Aplicações com o atributo android:persistent="true" são iniciadas automaticamente pelo Activity Manager. ✗ O Activity Manager envia um Intent do tipo Intent.CATEGORY_HOME, onde a aplicação Launcher é executada.
Dalvik para rodar uma aplicação Java. service permite interagir com os serviços registrados no sistema. stagefright permite interagir com o serviço de Media Player. input permite injetar eventos de input no sistema (teclado, touchscreen, etc).
diretamente com o Activity Manager. pm permite se comunicar diretamente com o Package Manager. ime permite se comunicar diretamente com o serviço Input Method. scv permite se comunicar com vários outros serviços (Power Manager, Wifi Manager, conectividade de dados e porta USB).
entrada para as aplicações. dumpsys realiza o dump de um serviço do sistema. dumpstate realiza um dump de todo o sistema. rawbu faz e restaura backups da partição data/.
Android é bastante monolítica. ✗ Não existe uma forma fácil, via arquivo de configuração ou menu de configuração, de desabilitar um serviço do sistema. ✗ Neste caso, é necessário alterar ou adaptar o código-fonte, o que pode ser bastante trabalhoso. ✗ Mas pode ser um trabalho necessário. Por este motivo, estudaremos como fazer isso mais adiante no treinamento.
o Android sem o framework com o comando abaixo: $ BUILD_TINY_ANDROID=true make j16 ✗ Serão compilados o init, bionic, adbd, logcat, sh e outros componentes da camada nativa. ✗ Pode ser interessante para realizar testes de drivers ou aplicações compiladas nativamente para o Android.
para possibilitar que um código Java possa acessar (e ser acessado) por um código escrito em outras linguagens, como C, C++ e assembly. ✗ No Android, serve de ligação entre o framework Android (Java) e a camada nativa (C/C++). ✗ Implementada na biblioteca libnativehelper.so.
seguinte modelo: JNIEXPORT jstring JNICALL Java_ClassName_MethodName (JNIEnv*, jobject); ✗ JNIEnv é um ponteiro que possibilita manipular objetos Java usando métodos nativos. ✗ jobject contém um ponteiro para o objeto que chamou a função, muito similar ao ponteiro this em C++.
qualquer código Java (serviço do sistema, aplicação Android, etc) acesse diretamente a camada nativa do Android. ✗ Mas mesmo usando JNI para acessar uma aplicação ou biblioteca nativa, todos os mecanismos de segurança do Android são mantidos. ✗ Se você quiser prover para uma aplicação Android o acesso privilegiado à um recurso do sistema, será necessário estender o framework do Android. ✗ Além disso, você precisará estender o framework se quiser adicionar funcionalidades à API do Android.
quebrar a API e adicionar algum bug. ✗ Impossibilita a certificação do dispositivo pelo Google. ✗ É trabalhoso manter e portar as alterações para outras versões do Android.
até aqui tem como principal objetivo prover uma infraestrutura completa para o desenvolvimento de aplicações. ✗ Aplicações Android são escritas basicamente em Java, usando o SDK do Google. ✗ São empacotadas em arquivos com extensão apk, contendo o código compilado, dados e recursos usados pela aplicação. ✗ Podem ser instaladas através do Google Play ou manualmente via ADB ou gerenciador de arquivo.
é baseado na API provida pelo Google. ✗ Esta API contém dois principais componentes: ✗ Bibliotecas Java: subconjunto de classes Java padrão implementadas pelo projeto Apache Harmony. ✗ Android API: classes Java do Android. ✗ Toda a documentação da API do Android esta disponível em: http://developer.android.com/reference/packages.html
com o usuário (é o mesmo que janelas em sistemas desktop). ✗ Uma aplicação Android normalmente possui diversas Activities, e uma das activities é definida como a principal (main), que é apresentada ao usuário ao executar a aplicação pela primeira vez. ✗ Uma aplicação pode requisitar o uso de uma Activity de outra aplicação. Ex: a aplicação de navegação na Internet pode requisitar o uso da Activity da aplicação de envio de e-mail para compartilhar um link por e-mail. ✗ É o desenvolvedor da aplicação que decide quais activities estarão disponíveis para o sistema.
em background e não tem interface com o usuário. ✗ São usados para executar operações demoradas em background ou prover serviços para outras aplicações. ✗ Cuidado para não confundir com os serviços do framework Android!
com um serviço de duas formas: ✗ De forma assíncrona, através da função startService(). Desta forma, o serviço não estará ligado ao componente que o criou, e ficará em execução até que ele ou outro componente pare sua execução. ✗ De forma síncrona, através da função bindService(). Desta forma, o serviço estará ligado ao componente que o criou, e será destruído automaticamente quando o componente não existir mais. Esta forma de execução oferece uma interface do tipo cliente/servidor.
permitem o registro para receber um evento do sistema ou de uma aplicação. ✗ Possuem o mesmo conceito de uma rotina de tratamento de interrupção. ✗ Por exemplo, você pode desenvolver um broadcast receiver para ser notificado quando: ✗ O nível de bateria ficar baixo. ✗ O modo avião for habilitado. ✗ O processo de boot do sistema completar.
prover acesso aos dados de forma organizada, similar à um banco de dados relacional. ✗ Um aplicação deve implementar um content provider quando deseja compartilhar dados com outras aplicações. ✗ A maioria das aplicações usam o SQlite para armazenar os dados, mas o desenvolvedor pode usar outros tipos de armazenamento se desejar (memória, disco, rede, etc).
persistentes de diversas formas: ✗ Shared preferences: permite armazenar dados no formato chave- valor, em um arquivo xml no diretório de dados da aplicação. ✗ Internal Storage: permite armazenar qualquer arquivo no diretório de dados da aplicação. ✗ External Storage: permite armazenar qualquer arquivo em um diretório público do sistema (normalmente o sdcard). ✗ SQLite Databases: permite armazenar dados no banco de dados do sistema.
arquivo de manifesto no formato XML (AndroidManifest.xml), cujo objetivo é declarar informações sobre a aplicação, dentre elas: ✗ Componentes disponíveis. ✗ Permissões necessárias para executar a aplicação. ✗ Revisão da API. ✗ Características do hardware. ✗ Bibliotecas necessárias.
um ou mais componentes. ✗ Um aplicação pode iniciar qualquer componente, incluindo componentes de outras aplicações. ✗ Os componentes se comunicam entre si através de um mecanismo de troca de mensagens chamado intent.
comunicação entre os componentes do Android. ✗ Um intent descreve basicamente a intenção de realizar alguma ação. ✗ Por exemplo, a activity de uma aplicação pode enviar um intent para ver um arquivo PDF, implementado por uma activity de outra aplicação.
são iniciados através de intents. ✗ Internamente, os intents são implementados via Binder. ✗ Os componentes declaram quais intents são capazes de manipular através do atributo intentfilter do arquivo de manifesto.
conter imagens, vídeos, sons, etc. ✗ E tudo que faz parte do visual da aplicação é mantido separado do código-fonte, como layout das activities, animações, menus, strings, etc. ✗ Estes recursos são armazenados no diretório res/ das aplicações. ✗ Durante a compilação da aplicação, a ferramenta de compilação do Android cria a classe R, possibilitando referenciar cada um dos recursos disponíveis.
cada componente de uma mesma aplicação roda em um mesmo processo. ✗ Quando o sistema quiser executar um novo componente: ✗ Se o processo correspondente ao componente ainda não estiver em execução, um novo processo será criado. ✗ Caso contrário, o componente será iniciado dentro do processo em execução. ✗ Se necessário, é possível iniciar um componente de uma aplicação em um novo processo com o atributo android:process no arquivo de manifesto.
por padrão possui apenas uma thread de execução, todos os componentes e interações com o usuário são realizadas de forma sequencial. ✗ Por este motivo, uma operação de I/O ou processamento mais longo pode travar a interface com o usuário. ✗ Se a aplicação bloquear por mais de 5 segundos, o sistema irá exibir a mensagem “Application Not Responding” (ANR). ✗ Por este motivo, é aconselhável nestes casos executar operações mais longas em uma thread separada.
threads no Android: ✗ Usar a implementação de thread padrão do Java, extendendo a classe Runnable. ✗ Usar a classe AsyncTask do Android (mais fácil de implementar a comunicação com a thread principal da aplicação).
central do Android é que o usuário não deve se preocupar com o gerenciamento e troca de tarefas. ✗ O usuário pode iniciar quantas aplicações quiser e mudar entre elas clicando no botão Home e chaveando entre as tarefas. ✗ Mas após um certo uso, vários processos podem estar em execução, consumindo muitos recursos do sistema.
este motivo, o Android gerencia o ciclo de vida de cada um dos componentes da aplicação, matando processos e liberando recursos conforme necessário. ✗ Mas para este processo funcionar corretamente, o desenvolvedor deve implementar uma série de callbacks para cada componente da aplicação. ✗ Estas callbacks são chamadas de acordo com o evento do ciclo de vida do componente. ✗ Por exemplo, na mudança de foreground para background, a callback Pause() do componente é chamada.
memória estiver alto, o sistema pode decidir matar um processo para liberar memória. ✗ Esta decisão é tomada baseada na importância (prioridade) do processo. ✗ Quando um processo é encerrado, todos seus componentes também são.
prioridade de cada processo de acordo com seu status: ✗ Processos rodando em foreground possuem a maior prioridade (activity, service ou broadcast receiver ativo). ✗ Processos visíveis, como uma activity que não esta mais em foreground mas ainda é visível no display. ✗ Serviço iniciado por um processo em background. ✗ Processos em background que não são mais visíveis aos usuários. ✗ Processos vazios (sem componentes).
em um ambiente separado de outras aplicações: ✗ Cada aplicação roda em uma instância da máquina virtual, isolada de outras aplicações. ✗ O sistema atribui um usuário (UID) e grupo (GID) para cada aplicação. ✗ Estas credenciais são usadas para permitir que as aplicações possam acessar apenas os arquivos que tenham direito.
acessar um recurso que não tem permissão diretamente, o desenvolvedor deve declarar as permissões necessárias no arquivo de manifesto da aplicação. ✗ Ao instalar a aplicação, uma mensagem é exibida com as permissões necessárias pela aplicação, e o usuário deve aprovar estas permissões.
determinado recurso do sistema: ✗ O acesso é realizado através de uma API do sistema. ✗ Esta API se comunica via Binder com o Package Manager para verificar se aquela aplicação tem acesso ao recurso desejado. ✗ Caso afirmativo, a API se comunica com o serviço correspondente via Binder. ✗ Alguns serviços ainda se comunicam com um serviço nativo via UNIX domain socket.
um conjunto de ferramentas para o desenvolvimento de aplicações Android em C/C++. ✗ É normalmente utilizado nas seguintes situações: ✗ Quando é necessário mais performance (ex: cálculos matemáticos, jogos, etc). ✗ Para portar rapidamente um código existente (ex: navegador Firefox). ✗ Permite acesso direto à GPU via OpenGL! ✗ Pode ser combinado com o SDK, permitindo ter uma aplicação que usa parte do código em Java e parte em C/C++!
uma aplicação (APK), incluindo o arquivo de manifesto. ✗ Apesar do código não ser executado pela Dalvik, todos os mecanismos de segurança são mantidos. ✗ Principais deficiências: ✗ Perde portabilidade. ✗ Acesso apenas à uma parte da API do Android. ✗ Não possui a funcionalidade de recursos.
manualmente, mas normalmente são distribuídas para os usuários através de um repositório de aplicações. ✗ O repositório padrão do Google é o Google Play. ✗ Existem outros repositórios disponíveis como o Amazon App Store. ✗ Nada te impede de criar seu próprio repositório de aplicações!
aplicações Android é realizado no Eclipse com o plugin ADT instalado e diversas outras ferramentas como o emulador, ADB, etc. ✗ A forma mais fácil de preparar o ambiente é baixar o Android SDK no link abaixo: http://developer.android.com/sdk/index.html ✗ Toda a documentação da API do Android esta disponível em: http://developer.android.com
à um dispositivo de hardware normalmente é exposto para as aplicações através de entradas no /dev ou no /sys. ✗ O Android se baseia em uma camada adicional chamada HAL (Hardware Abstraction Layer) para abstrair o acesso ao hardware pelo seu framework. ✗ Boa parte dos dispositivos suportados pelo Android possuem uma HAL, que pode variar em comportamento e interface.
Drivers ... System Services Aplicações e Framework Binder JNI System call Camera HAL Sensors HAL Graphics HAL ... Kernel Camada nativa Framework Android Hardware
implementada pelo fabricante ou pelo AOSP através de bibliotecas compartilhadas (*.so). ✗ Um serviço do sistema (system service) correspondente ao hardware acessado é o responsável por carregar a biblioteca da HAL e utilizar suas funções. ✗ O Android não especifica como a HAL deve ser desenvolvida, apenas que uma API padronizada deve ser provida por ela para ser utilizada pelo sistema.
o fabricante pode apenas escrever um driver básico para o hardware (stub) e implementar toda a inteligência do acesso ao dispositivo na HAL. ✗ Desta forma, a licença usada na HAL não precisa ser necessariamente GPL.
tipo de hardware possui um serviço do sistema e uma camada HAL associada à este serviço. Exemplos: ✗ Lights Service e lights HAL. ✗ Wifi Service e wifi HAL. ✗ Sensors Service e sensors HAL. ✗ Power Management Service e power management HAL.
estão disponíveis em um dos diretórios abaixo: ✗ /vendor/lib/hw ✗ /system/lib/hw ✗ O nome da biblioteca tem o formato <hal>.<device>.so, onde o nome do dispositivo é lido de uma das propriedades abaixo: ✗ ro.hardware ✗ ro.product.board ✗ ro.board.platform ✗ ro.arch
normalmente implementada via camada ALSA do kernel. ✗ gralloc.<device>.so/hwcomposer.<device>.so: camada de vídeo. ✗ camera.<device>.so: acesso à câmera, normalmente (mas não necessariamente) implementado via camada V4L do kernel. ✗ gps.<device>.so: acesso ao GPS, normalmente via serial (tty). ✗ libril.so: acesso ao rádio (voz e dados).
interface Bluetooth (até a versão 4.1 usava-se o BlueZ, agora usa-se o bluedroid da Broadcom). ✗ nfc.<device>.so: acesso à interface de comunicação NFC. ✗ lights.<device>.so: controle de LEDS, backlight, etc. ✗ sensors.<device>.so: acesso aos sensores (acelerômetro, giroscópio, magnetômetro, pressão, proximidade, temperatura, etc). ✗ power.<device>.so: responsável pelo gerenciamento de energia.
trabalhoso e envolve conhecer o funcionamento interno dos serviços providos pelo framework do Android. ✗ Por este motivo, se possível, escolha um dispositivo que já possua uma implementação da HAL do Android. ✗ Caso não seja possível, você precisará estudar o funcionamento da HAL correspondente, e ler muito código!
a definição da HAL pode ser encontrada no AOSP em hardware/. ✗ As definições das interfaces encontram-se em: ✗ hardware/libhardware/include/hardware/ ✗ hardware/libhardware_legacy/include/hardware_legacy/ ✗ Uma implementação padrão da HAL esta disponível em hardware/libhardware/modules.
o suporte ao hardware de alguns dispositivos de mercado, que pode ser usado como referência para novas implementações. ✗ Veja o diretório device/ no AOSP para alguns exemplos. ✗ Uma visão geral da HAL esta documentada pelo Google no link abaixo: http://source.android.com/devices/index.html
necessita de uma camada HAL, por exemplo: ✗ Dispositivos de input (botões, mouse, teclado) são acessados diretamente via /dev/input/. ✗ Dispositivos de rede são acessados normalmente via interface de rede, através de uma conexão via socket com o daemon netd. ✗ Dispositivos de armazenamento (cartão SD) são acessados diretamente via system calls, através de uma conexão via socket com o daemon vold. ✗ O serviço Vibrator acessa diretamente a interface de GPIOs no /sys.
sistemas embarcados acontece via porta serial ou JTAG (para depuração em baixo nível). ✗ Esta configuração funciona bem em sistemas embarcados, mas em dispositivos móveis não possuímos normalmente estes tipos de interface. ✗ É por este motivo que o Google desenvolveu o ADB.
é uma ferramenta de debugging que pode funcionar em conexões USB ou TCP/IP. ✗ É composto por três componentes: ✗ Daemon ADB, que roda no target. ✗ Servidor ADB, que roda no host e é responsável pela comunicação com o target. ✗ Cliente ADB, que também roda no host e serve de interface (modo texto) para a execução de comandos no target.
host (normalmente é iniciado automaticamente). killserver Mata o servidor ADB no host. devices Lista os dispositivos acessíveis via ADB. connect Conecta ao daemon ADB via TCP (porta 5555 por padrão) disconnect Disconecta do dispositivo.
para o target. pull Copia arquivos do target para o host. sync Sincroniza os diretórios system/ e data/. install Instala um pacote Android (APK) no target. uninstall Desinstala um pacote Android (APK) do target.
sistema. shell Executa um comando ou inicia uma seção do shell. bugreport Gera um relatório de erro do target (status atual, logs, etc). waitfordevice Bloqueia até que o dispositivo esteja disponível.
com permissão de leitura e escrita. reboot Reinicia o dispositivo (opções bootloader e recovery disponíveis). rebootbootloader Reinicia o dispositivo no bootloader. root Reinicia o ADB com permissões de root (apenas se ro.secure=1 e ro.debuggable=1).
ADB para escutar comandos via USB. ✗ tcpip Reinicia o daemon ADB para escutar comandos via TCP. ✗ lolcat Mesmo que adb logcat. ✗ hell Mesmo que adb shell.
redirecionar qualquer porta entre o host e o target, possibilitando por exemplo o debugging com o GDB. ✗ No target: # gdbserver :1234 /system/bin/executable ✗ No host: $ adb forward tcp:1234 tcp:1234 $ prebuilt/Linux/toolchaineabi4.2.1/bin/armeabigdb \ out/target/product/productname/symbols/system/bin/executable
daemon do ADB abre um UNIX domain socket e espera por conexões. ✗ Processos que rodam na Dalvik se registram neste socket, tornando-se visíveis para debugging. ✗ A Dalvik implementa o JDWP (Java Debug Wire Protocol), permitindo usar o debugger Java (jdb) para depurar suas aplicações.
a lista de processos Java depuráveis com o comando abaixo: $ adb jdwp 271 376 ... ✗ Crie o redirecionamento para o PID do processo: $ adb forward tcp:8000 jdwp:376 ✗ E inicie o debugger: $ jdb attach localhost:8000
é uma ferramenta de debugging que possibilita, dentre outras tarefas: ✗ Exibir informações e logs dos processos em execução. ✗ Capturar a tela do dispositivo. ✗ Monitorar eventos (SMS, chamadas, localização, etc). ✗ Ele se conecta ao servidor ADB e se comunica com os processos Android através do JDWP. ✗ Esta integrado ao Eclipse através do plugin ADT, acessível em Window > Open Perspective > Other... > DDMS.
com informações de tracing de duas formas: ✗ Automaticamente com a função de profiling do DDMS (método impreciso). ✗ Manualmente através dos métodos startMethodTracing() e stopMethodTracing() da classe Debug. ✗ Através deste log, uma ferramenta chamada traceview é capaz de exibir informações de tracing e profiling da aplicação. ✗ Também através deste log, uma aplicação chamada dmtracedump é capaz de exibir o backtrace de chamadas de função da aplicação.
em python que permite analisar a performance de uma aplicação ou do sistema como um todo. ✗ Combina um conjunto de informações disponibilizadas pelo kernel para gerar um relatório em HTML sobre o sistema. ✗ Funciona a partir do Android 4.1. ✗ Mais informações no link abaixo: http://developer.android.com/tools/debugging/systrace.html
provê um mecanismo para coletar e visualizar informações do sistema. ✗ Os logs são armazenados em alguns buffers circulares do kernel, e podem ser exibidos com o comando logcat. ✗ Para exibir uma descrição das opções disponíveis: $ logcat help
filtrado por buffer, conforme abaixo: $ logcat b radio ✗ Os seguintes buffers estão disponíveis: ✗ main: buffer principal (é o padrão se a opção b não for usada). ✗ radio: buffer com mensagens relacionadas à comunicação com o radio. ✗ events: buffer com eventos do sistema.
por tag (identificador do processo) e prioridade: I/ActivityManager(585): Starting activity: Intent { action= android.intent.action...} ✗ As seguintes prioridades estão disponíveis (listadas da menor para a maior): V Verbose D Debug I Info W Warning E Error F Fatal S Silent
de comando para ser executada no dispositivo. ✗ É capaz de automatizar a geração de entradas para uma aplicação. ✗ Por exemplo, o comando abaixo é capaz de gerar 50 entradas aleatórias para o navegador: $ monkey p com.android.browser v 50 ✗ É possível criar scripts com o monkey para automatizar os testes de uma aplicação!
linha de comando para o host que permite controlar um target Android. ✗ Provê uma API completa em python para o desenvolvimento de aplicações de controle e teste de um dispositivo Android. ✗ Mais informações no link abaixo: http://developer.android.com/tools/help/monkeyrunner_concepts.html
de tirar o dump de um ou todos os serviços do sistema, invocando a função dump() implementada pelo serviço. # dumpsys power Power Manager State: mIsPowered=true mPowerState=1 mScreenOffTime=46793204 ms mPartialCount=1 mWakeLockState=SCREEN_ON_BIT mUserState= mPowerState=SCREEN_ON_BIT mLocks.gather=SCREEN_ON_BIT mNextTimeout=94351 now=46880555 46786s from now ...
com suporte ao fastboot. ✗ Portar o kernel Linux com os patches do Android. ✗ Sempre que possível, escolha um fabricante de plataforma que tenha o suporte ao Linux, de preferência com os patches do Android aplicados!
AOSP e customizar para a sua plataforma. ✗ Desenvolver e integrar a HAL (de preferência, escolha um hardware com a HAL pronta!). ✗ Desenvolver suas aplicações Android (normalmente o Launcher). ✗ Certificar-se no Google (opcional).
Ship Features Fearlessly
Turn features on and off without deploys. Used by thousands of Ruby developers.
→
sprado
masakiokuda
tetsuya28
y0hgi
kworkdev
usanchuu
yahonda
makocchi
pfn
kenichiodo
koukihosaka
hiracky16
greenmidori
afnizarnur
twada
sarafernandez
seathinner
jmmastey
axbom
3n
michielstock
dougneiner
sonatard
marcduiker
techseoconnect
