View
4.180
Download
57
Category
Preview:
DESCRIPTION
Slides do treinamento de Android embarcado da Labworks.
Citation preview
Embedded Labworks
Por Sergio Prado. São Paulo, Abril de 2015® Copyright Embedded Labworks 2004-2015. All rights reserved.
Android embarcado
Embedded Labworks
SOBRE ESTE DOCUMENTO
✗ Este documento é disponibilizado 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
Embedded Labworks
SOBRE O INSTRUTOR
✗ Sergio Prado tem mais 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
Embedded Labworks
AGENDA DO TREINAMENTO
✗ DIA 1: Introdução, código-fonte, sistema de build, embarcando o Android, camada nativa.
✗ DIA 2: Processo de inicialização, criação de produtos, desenvolvimento de módulos, framework Android.
✗ DIA 3: System services, aplicações Android, HAL, debugging.
Embedded Labworks
AMBIENTE DE LABORATÓRIO
/opt/labs/ Ambiente de laboratóriodl/ Aplicações e componentes opensource
que serão usados durante asatividades de laboratório
docs/ Documentaçãoguides/ Guias de consulta (shell, vi, etc)
hardware/ Documentação do hardware training/ Slides e atividades de laboratórioex/ Exercícios de laboratóriotools/ Ferramentas de uso geral
Embedded Labworks
DURANTE O TREINAMENTO
✗ Pergunte...
✗ Expresse seu ponto de vista...
✗ Troque experiências...
✗ Ajude...
✗ Participe!
Embedded Labworks
Android embarcado
Introdução ao sistema operacional Android
Embedded Labworks
HISTÓRICO
✗ 2003: Começou como uma startup chamada 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.
Embedded Labworks
VERSÕES
✗ Desde então, todo ano, em torno 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)
✗ 4.4 (KitKat)
✗ 5.0/5.1 (Lollipop)
✗ Este treinamento é baseado no Kit Kat 4.4.2.
Embedded Labworks
PRINCIPAIS CARACTERÍSTICAS
✗ Código aberto.
✗ Interface gráfica com uma experiência familiar.
✗ Ecossistema de aplicações disponíveis (aproximadamente 1.400.000 aplicações em abril/2015).
✗ Framework para desenvolvimento de aplicações.
✗ Ambiente de desenvolvimento completo, incluindo IDE, emulador e ferramentas de debugging.
Embedded Labworks
PRINCIPAIS CARACTERÍSTICAS (cont.)
✗ Suporte total à tecnologias web via WebKit.
✗ Suporte à hardware:✗ Aceleradores gráficos via OpenGL ES.
✗ Tecnologias de comunicação sem fio (Bluetooth, WiFi, NFC, GSM, CDMA, UMTS, LTE, etc).
✗ Sensores (acelerômetro, giroscópio, compasso, etc).
✗ Etc!
Embedded Labworks
ANDROID EM SISTEMAS EMBARCADOS
✗ Estas e outras características levaram o Android a ser avaliado e utilizado como sistema operacional em aplicações embarcadas.
Embedded Labworks
ANDROID OPEN SOURCE PROJECT
✗ O Android é 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 nativamente pelo AOSP, incluindo os últimos smartphones e tablets de referência do Google (linha Nexus).
Embedded Labworks
COMUNIDADE
✗ Qualquer um pode contribuir com o 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)
Embedded Labworks
LICENÇAS
✗ A grande maioria dos pacotes estão 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).
Embedded Labworks
CERTIFICAÇÃO
✗ Para que o dispositivo possa ter a marca Android e possa usar as aplicações do Google, é necessário certificá-lo através do Android Compatibility Program (ACP):✗ Compatibility Definition Document (CDD): descreve os requisitos
necessários (software e hardware) para que um dispositivo possa ser considerado compatível com Android.
✗ Compatibility 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/
Embedded Labworks
ARQUITETURA LINUX EMBARCADO
Hardware
Bootloader
Linux kernel
Biblioteca C (glibc, eglibc, uclibc, etc)
Biblioteca Biblioteca
Aplicação Aplicação
Sistema GNU/Linux
Embedded Labworks
ARQUITETURA ANDROID
Hardware
Bootloader
Linux kernel
Camada nativa (bibliotecas, daemons e ferramentas)
Framework (serviços e API)
Aplicação
Plataforma Android
Aplicação Aplicação Aplicação
Embedded Labworks
COMPONENTES DO SISTEMA
✗ Bootloader depende do fabricante 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.
Embedded Labworks
Android embarcado
Código-fonte
Embedded Labworks
MÁQUINA DE DESENVOLVIMENTO
✗ É recomendado o uso de uma máquina de 64 bits com o Ubuntu 14.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.4 ocupam 50G de disco, mais 25G para cada produto 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
Embedded Labworks
CÓDIGO-FONTE
✗ Instruções sobre a utilização do código-fonte 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 (emulador e dispositivos da linha Nexus).
✗ Testar a imagem gerada no emulador.
Embedded Labworks
AOSP E REPOSITÓRIOS GIT
✗ O AOSP é 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
Embedded Labworks
REPOSITÓRIOS GIT
Embedded Labworks
FERRAMENTA REPO
✗ Para gerenciar as centenas de 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 http://commondatastorage.googleapis.com/gitrepodownloads/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).
Embedded Labworks
MANIFEST.XML<?xml version="1.0" encoding="UTF8"?><manifest>
<remote name="aosp" fetch=".." review="https://androidreview.googlesource.com/" /> <default revision="refs/tags/android4.2.2_r1.1" remote="aosp" syncj="4" />
<project path="build" name="platform/build" groups="pdk" > <copyfile src="core/root.mk" dest="Makefile" /> </project> <project path="abi/cpp" name="platform/abi/cpp" groups="pdk" /> <project path="bionic" name="platform/bionic" groups="pdk" /> <project path="bootable/bootloader/legacy" name="platform/bootable/bootloader/legacy" /> <project path="bootable/diskinstaller" name="platform/bootable/diskinstaller" /> <project path="bootable/recovery" name="platform/bootable/recovery" groups="pdk" /> <project path="cts" name="platform/cts" /> <project path="dalvik" name="platform/dalvik" /> <project path="development" name="platform/development" /> <project path="device/asus/grouper" name="device/asus/grouper" groups="device,grouper" /> <project path="device/asus/tilapia" name="device/asus/tilapia" groups="device,grouper" />
[...]
Embedded Labworks
BAIXANDO O AOSP COM O REPO
$ repo init u https://android.googlesource.com/platform/manifest
$ repo sync[...] Aqui ele vai clonar cada um dos repositórios git!
$ lsabi dalvik frameworks Makefile prebuiltsbionic development gdk ndk sdkbootable device hardware out systembuild docs libcore packagescts external libnativehelper pdk
Embedded Labworks
OUTROS COMANDOS REPO
✗ repo diff (faz um 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).
Embedded Labworks
REPO E COLABORAÇÃO
✗ O Google desenvolveu uma 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
Embedded Labworks
OUTROS REPOSITÓRIOS ANDROID
✗ O Google AOSP é o repositório principal mas oferece suporte limitado à dispositivos de hardware.
✗ O BSP do fabricante pode fornecer bom suporte mas normalmente é mais desatualizado.
✗ A Linaro (focada em ARM) fornece uma árvore alternativa e atualizada com suporte à um conjunto maior de dispositivos de hardware:
https://wiki.linaro.org/Platform/Android
Embedded Labworks
OUTROS REPOSITÓRIOS ANDROID (cont.)
✗ O Cyanogen Mod 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, como por exemplo o Rowboat para os chips Sitara da TI:
https://code.google.com/p/rowboat/
Embedded Labworks
DIRETÓRIOS: BOOTLOADER, KERNEL E HAL
✗ bootable/: bootloader de referência e imagem de recovery.
✗ kernel_imx/: kernel para a Wandboard (i.MX6), não existe no AOSP!
✗ hardware/: definição da interface HAL e implementação padrão para alguns dispositivos de hardware.
✗ device/: configurações e componentes específicos dos produtos suportados.
Embedded Labworks
DIRETÓRIOS: CÓDIGO-FONTE NATIVO
✗ bionic/: biblioteca C padrão 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.
Embedded Labworks
DIRETÓRIOS: FRAMEWORK E APPS
✗ dalvik/: código-fonte da máquina virtual Dalvik.
✗ art/: código-fonte da máquina virtual ART (Android runtime), sucessora da Dalvik.
✗ libcore/: biblioteca Java (Apache Harmony)
✗ frameworks/: código-fonte do framework do Android.
✗ packages/: aplicações Android.
Embedded Labworks
DIRETÓRIOS: FERRAMENTAS
✗ ndk/: ferramentas do NDK (Native 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/, tools/, developers/: ferramentas de desenvolvimento e aplicações de debugging.
✗ cts/: ferramentas do CTS (Compatibility Test Suite).
Embedded Labworks
DIRETÓRIOS: BUILD e DOCUMENTAÇÃO
✗ build/: scripts, Makefiles e outros componentes do sistema de build.
✗ prebuilts/: binários pré-compilados, incluindo os toolchains.
✗ docs/: conteúdo do site http://source.android.com.
Embedded Labworks
ANDROID CROSS REFERENCE
Embedded Labworks
ANDROID CROSS REFERENCE (cont.)
Embedded Labworks
LABORATÓRIO
Baixando e estudando o código-fonte do Android
Embedded Labworks
Android embarcado
Sistema de build
Embedded Labworks
SISTEMAS DE BUILD
✗ Sistemas de build tem 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 Poky (Yocto Project).
✗ Já o Android tem sua própria solução de sistema de build!
Embedded Labworks
SISTEMA DE BUILD DO ANDROID
✗ A sistema 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.
Embedded Labworks
ENVSETUP.SH
✗ O primeiro passo para usar o 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.
Embedded Labworks
ENVSETUP.SH (cont.)
✗ Alguns comandos criados pelo envsetup.sh 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.
Embedded Labworks
O PRODUTO
✗ Após executar o script envsetup.sh, 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).
Embedded Labworks
CONFIGURANDO O PRODUTO
✗ A configuração do produto é 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 dos comandos lunch ou choosecombo.
Embedded Labworks
LUNCH
$ lunch
You're building on Linux
Lunch menu... pick a combo: 1. aosp_armeng 2. aosp_x86eng 3. aosp_mipseng 4. vbox_x86eng 5. aosp_mantauserdebug 6. imx53_smdeng 7. imx53_smduser 8. arm2_6dqeng ...
Which would you like? [aosp_armeng]
Embedded Labworks
LUNCH (cont.)
✗ O comando lunch vai exibir 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 aosp_armeng
✗ Ao selecionar o combo, o comando lunch irá criar as variáveis de ambiente necessárias para a compilação:
$ env | grep "ANDROID\|TARGET"
Embedded Labworks
CHOOSECOMBO
$ choosecombo Build type choices are: 1. release 2. debug
Which would you like? [1]
Which product would you like? [aosp_arm]
Variant choices are: 1. user 2. userdebug 3. eng
Which would you like? [eng]
Embedded Labworks
COMPILANDO
✗ Para compilar, é só executar o 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
Embedded Labworks
O QUE FAZ O MAKE?
✗ Os diversos 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.
Embedded Labworks
O QUE FAZ O MAKE? (cont.)
✗ Após 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).
Embedded Labworks
DIRETÓRIO OUT
✗ Ao final do processo de 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>/.
Embedded Labworks
IMAGENS FINAIS
$ ls out/target/product/generic/androidinfo.txt fake_packages rootcache hardwareqemu.ini symbolscache.img installedfiles.txt systemclean_steps.mk obj system.imgdata previous_build_config.mk userdata.imgdex_bootjars ramdisk.img userdataqemu.img
Embedded Labworks
OUTROS TARGETS DO MAKE
✗ Limpar o diretório de compilação (out/):
$ make clean
✗ Exibir os comandos executados durante a compilação:
$ make showcommands
✗ Gerar apenas a imagem da partição system:
$ make snod
Embedded Labworks
OUTROS TARGETS DO MAKE (cont.)
✗ Lista todos os módulos que podem ser compilados:
$ make modules
✗ Compilar apenas um módulo:
$ make <module>
✗ Limpar a compilação de um módulo:
$ make clean<module>
Embedded Labworks
OUTROS TARGETS DO MAKE (cont.)
✗ Compilar o sistema de qualquer diretório:
$ m
✗ Compilar todos os módulos do diretório corrente:
$ mm
✗ Compilar todos os módulos de um diretório específico:
$ mmm <diretório>
Embedded Labworks
EMULADOR
✗ O Android possui um emulador de dispositivos móveis, capaz de rodar na máquina host e emular o sistema gerado.
✗ Este emulador pode ser compilado através dos produtos aosp_arm, aosp_x86 e aosp_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.
Embedded Labworks
EMULADOR (cont.)
✗ Internamente, o emulador do Android é uma interface gráfica desenvolvida em cima do qemu.
http://qemu.org
✗ Para compilar uma imagem do Android para o emulador
$ source build/envsetup.sh$ lunch aosp_armeng$ make j4
✗ E para executar o emulador:
$ emulator &
Embedded Labworks
O EMULADOR
Embedded Labworks
LABORATÓRIO
Compilando o Android e testando no emulador
Embedded Labworks
Android embarcado
Android embarcado
Embedded Labworks
ARQUITETURA ANDROID
Hardware
Bootloader
Linux kernel
Camada nativa (bibliotecas, daemons e ferramentas)
Framework (serviços e API)
Aplicação
Plataforma Android
Aplicação Aplicação Aplicação
Embedded Labworks
HARDWARE
Hardware
Bootloader
Linux kernel
Camada nativa (bibliotecas, daemons e ferramentas)
Framework (serviços e API)
Aplicação
Plataforma Android
Aplicação Aplicação Aplicação
Embedded Labworks
HARDWARE TÍPICO COM ANDROID
Fonte: http://www.opersys.com/
Embedded Labworks
CPU
✗ Oficialmente o Android suporta as arquiteturas ARM, x86 e MIPS.
✗ O mais comum é encontrar o Android rodando em plataformas ARM 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.
Embedded Labworks
MEMÓRIA E ARMAZENAMENTO
✗ Segundo o Google, é 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.
Embedded Labworks
OUTRAS CARACTERÍSTICAS RECOMENDADAS
✗ Display com touchscreen (especificação mínima definida pelo Google: 2,5", 426x320, 16 bits).
✗ Botões de navegação (MENU, HOME, BACK). Os botões também podem ser emulados em software.
✗ Sensores (acelerômetro, magnetrômetro, GPS, giroscópio, etc).
✗ Comunicação wireless (Bluetooth, WiFi, NFC, etc).
Embedded Labworks
WANDBOARD QUAD
✗ i.MX6 Quad (4 núcleos ARM Cortex-A9) rodando à 1GHz.
✗ 2G de RAM DDR3.
✗ Duas interfaces de cartão SD e uma interface SATA.
✗ Saídas de áudio (comum e S/PDIF) e vídeo HDMI.
✗ Ethernet Gigabit, USB host e OTG, WiFi, Bluetooth, serial, etc. http://wandboard.org
Embedded Labworks
DISPLAY E PLACA ADAPTADORA
✗ Display LCD de 7” com resolução de 800x480 (WVGA) da Touch Revolution.
✗ Touchscreen capacitivo.
✗ Placa adaptadora para a Wandboard com suporte ao display de 7” da Touch Revolution e 4 botões.
Embedded Labworks
REFERÊNCIAS E DOCUMENTAÇÃO
✗ A documentação do hardware esta disponível no ambiente de laboratório em docs/hardware:
✗ IMX6DQRM.pdf (datasheet do i.MX6)
✗ WandboardQuadUserguide.pdf (guia de usuário da placa)
✗ FusionTouchDisplayDatasheet.pdf (datasheet do display)
✗ AdapterBoardSchematic.tar.gz (esquemático da placa adaptadora)
✗ Recursos na internet:http://wandboard.org/https://community.freescale.com/
Embedded Labworks
BOOTLOADER
Hardware
Bootloader
Linux kernel
Camada nativa (bibliotecas, daemons e ferramentas)
Framework (serviços e API)
Aplicação
Plataforma Android
Aplicação Aplicação Aplicação
Embedded Labworks
BOOTLOADER
✗ O bootloader é o código responsável por:✗ Inicializar o hardware.
✗ Carregar e executar um outro binário (normalmente um sistema operacional).
✗ 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.
Embedded Labworks
BOOTLOADER NO ANDROID
✗ Não é necessário nenhum 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
Embedded Labworks
FASTBOOT
✗ É acessível via ferramenta fastboot.
✗ 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.
Embedded Labworks
FERRAMENTA FASTBOOT$ fastbootusage: fastboot [ <option> ] <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
Embedded Labworks
BOOTLOADER NO AOSP
✗ O bootloader não faz 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.
Embedded Labworks
KERNEL
Hardware
Bootloader
Linux kernel
Camada nativa (bibliotecas, daemons e ferramentas)
Framework (serviços e API)
Aplicação
Plataforma Android
Aplicação Aplicação Aplicação
Embedded Labworks
VISÃO GERAL DO KERNEL
Biblioteca C
Hardware
Biblioteca Biblioteca Aplicação User space
Kernel
AplicaçãoAplicação
Chamadas de sistema Notificação de eventosExportação de informações
Gerenciamento do hardware Notificação de eventos
Embedded Labworks
O KERNEL LINUX NO ANDROID
✗ Assim como 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 executar um sistema Android com uma versão oficial do kernel.
Embedded Labworks
BINDER
✗ Mecanismo de IPC/RPC do Android, adicionando 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().
Embedded Labworks
BINDER (cont.)
Binder driver (/dev/binder)
Aplicação Service Manager
Power ManagerActivity ManagerMount Service...
SystemServer
1 234
Embedded Labworks
ASHMEM
✗ Ashmem (Anonymous Shared Memory) é um 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.
Embedded Labworks
WAKELOCKS
✗ Toda CPU moderna possui alguns estados 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 com a tela desligada, o smartphone pode estar executando outra função (tocando uma música, instalando uma aplicação, etc).
Embedded Labworks
WAKELOCKS (cont.)
✗ A resposta do Android para este problema são os wakelocks, onde o usuário (aplicação nativa, aplicação Android, 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).
Embedded Labworks
ALARM TIMER
✗ O alarm timer é um driver do kernel que integra as funcionalidades de RTC e timer do Linux, sendo capaz de acordar um processo em um tempo no futuro, 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().
Embedded Labworks
LOW MEMORY KILLER
✗ Quando o sistema fica 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.
Embedded Labworks
KLOGGER
✗ Logs são uma ferramenta importante para 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).
Embedded Labworks
KLOGGER (cont.)
✗ O Android implementa um driver 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.
Embedded Labworks
FERRAMENTA LOGCAT
$ logcatD/KeyguardViewMediator( 2276): setHidden falseD/KeyguardViewMediator( 2276): setHidden falseI/FlashBarService( 2809): mPkgManagerReceiver : onReceiveD/Launcher.HomeFragment( 2999): onResumeD/MenuAppsGridFragment( 2999): onResumeD/KeyguardViewMediator( 2276): setHidden falseI/power ( 2276): *** release_dvfs_lock : lockType : 1 E/DataRouter( 1904): After the usb selectW/ActivityManager( 2276): mDVFSLock.release()[...]
Embedded Labworks
OUTRAS ALTERAÇÕES
✗ Monotonic Event Timestamps: provê na 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.
Embedded Labworks
OUTRAS ALTERAÇÕES (cont.)
✗ Paranoid networking: adiciona um 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.
Embedded Labworks
COMO ESCOLHER O KERNEL?
✗ Certifique-se de que 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
Embedded Labworks
KERNEL NO AOSP
✗ O kernel não faz 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.
Embedded Labworks
ROOTFS
Hardware
Bootloader
Linux kernel
Camada nativa (bibliotecas, daemons e ferramentas)
Framework (serviços e API)
Aplicação
Plataforma Android
Aplicação Aplicação Aplicação
Embedded Labworks
SISTEMAS DE ARQUIVO
✗ Sistemas de arquivo são 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.
Embedded Labworks
SISTEMA DE ARQUIVO ROOT
✗ Um sistema de 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.
Embedded Labworks
ORGANIZAÇÃO DO ROOTFS
✗ A organização do rootfs 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!
Embedded Labworks
ROOTFS NO ANDROID
✗ O espaço de usuário do Android é composto por 3 principais componentes:✗ ramdisk: montado no diretório /, portanto é o rootfs do Android. Possui
aplicações básicas e arquivos de inicialização do sistema.✗ system: montado no diretório /system, contém binários e bibliotecas
nativas, bibliotecas Java, arquivos de configuração e aplicações padrão.✗ userdata: montado no diretório /data, contém arquivos gerados em
tempo de execução (aplicações instaladas pelo usuário, dados do usuário, etc).
✗ As imagens ramdisk e system são montadas normalmente com permissão de apenas leitura, enquanto que a imagem userdata é montada com permissão de leitura e escrita.
Embedded Labworks
IMAGENS ANDROID$ ls out/target/product/wandboard/androidinfo.txt obj symbolsboot.img previous_build_config.mk systemclean_steps.mk ramdisk.img system.imgdata ramdiskrecovery.img uboot6quad.binfake_packages recovery uboot.bininstalledfiles.txt recovery.img uImagekernel root userdata.img
Embedded Labworks
A INICIALIZAÇÃO
✗ No boot, o kernel monta o rootfs (ramdisk) e executa o processo init.
✗ O processo init interpreta os arquivos de configuração (init.rc, init.*.rc), inicializando o sistema e montando as imagens system e userdata.
✗ Opcionalmente, algumas outras partições podem ser montadas, dentre elas:✗ cache: armazenamento temporário, como por exemplo downloads em
andamento.
✗ sdcard: armazenamento externo, incluindo arquivos e documentos do usuário (vídeos, sons, imagens, etc).
Embedded Labworks
PONTOS DE MONTAGEM
/cache/d/data/system/etc/mnt/root/sbin/sdcard/vendor/proc/sys/dev/acct
Rootfs (RAM disk)
Kernel Virtual FS
Data Image
SDCARD
procfssysfstmpfscgroup
/anr/app/app-private/backup/dalvik-cache/data/dontpanic/local/misc/property/secure/system
Cache Image
System Image
/app/bin/etc/fonts/framework/lib/usr/xbin
Embedded Labworks
DIRETÓRIOS ROOTFS
proc Montado com o sistema de 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.
Embedded Labworks
DIRETÓRIOS ROOTFS (cont.)
etc Link para /system/etc, contendo 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).
Embedded Labworks
DIRETÓRIOS ROOTFS (cont.)
system Ponto de montagem para 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.
sdcard Link para o ponto de montagem do sdcard.
cache Ponto de montagem para a partição cache, usada para armazenar arquivos temporários, downloads em andamento, etc.
Embedded Labworks
DIRETÓRIO SYSTEM
bin Binários instalados no sistema.
xbin 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 (opcional).
Embedded Labworks
DIRETÓRIO SYSTEM (cont.)
app Aplicações pré-instaladas.
privapp Aplicações pré-instaladas com nível de previlégio de execução do sistema.
etc Arquivos de configuração do sistema.
usr Arquivos de configuração do framework.
media Arquivos de mídia (animação do boot, áudio, etc).
fonts Fontes instaladas no sistema.
Embedded Labworks
DIRETÓRIO DATA
/app Diretório de instalação das aplicações.
/appprivate Diretório de instalação das aplicações com proteção de cópia habilitada.
/appasec Aplicações encriptadas.
/applib Bibliotecas utilizadas pelas aplicações.
/data Contém um diretório para cada aplicação instalada (home das aplicações).
Embedded Labworks
DIRETÓRIO DATA (cont.)
/dalvikcache Cache da máquina virtual Java.
/local/tmp 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).
Embedded Labworks
PARTIÇÕES E IMAGENS
Sdcard
Cache
Data (userdata.img)
System (system.img)
Initrd (ramdisk.img) /
/system
/data
/cache
/sdcard
Read-only
Read-write
Bootloader
Kernel Linux
Embedded Labworks
PERMISSÕES
✗ O esquema de segurança do Android é 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.
Embedded Labworks
ADB
✗ O ADB (Android Debug Bridge) é uma ferramenta de depuração 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 do treinamento.
Embedded Labworks
LABORATÓRIO
Compilando e testando o Android no target
Embedded Labworks
Android embarcado
Camada nativa
Embedded Labworks
CAMADA NATIVA
Linux Kernel
Bibliotecas(bionic, etc)
InitToolbox
Daemons nativos
CamadaHAL
Dalvik / Android Runtime / Zygote
System Services
Android API
Aplicações
BibliotecasJava
API
Binder
JNI
System call
Embedded Labworks
CAMADA NATIVA (cont.)
✗ A camada nativa do 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, boa parte da camada nativa do Android foi praticamente escrita do zero. Em alguns casos, é bastante diferente do que vemos em um sistema Linux tradicional!
Embedded Labworks
BIBLIOTECAS
✗ A Android possui mais de 200 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 está disponível nos diretórios bionic/, system/core/, external/ e frameworks/base/.
Embedded Labworks
BIBLIOTECA C
✗ Um dos principais componentes de 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!
Embedded Labworks
BIONIC
✗ Por questões de licença, o Google 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
Embedded Labworks
BUSYBOX
✗ Um sistema Linux requer diversas aplicações 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.
Embedded Labworks
COMANDOS BUSYBOXaddgroup, adduser, adjtimex, ar, arp, arping, ash, awk, basename, bbconfig, bbsh, brctl, bunzip2, busybox, bzcat, bzip2, cal, cat, catv, chat, chattr, chcon, chgrp, chmod, chown, chpasswd, chpst, chroot, chrt, chvt, cksum, clear, cmp, comm, cp, cpio, crond, crontab, cryptpw, cttyhack, cut, date, dc, dd, deallocvt, delgroup, deluser, depmod, devfsd, df, dhcprelay, diff, dirname, dmesg, dnsd, dos2unix, dpkg, dpkg_deb, du, dumpkmap, dumpleases, e2fsck, echo, ed, egrep, eject, env, envdir, envuidgid, ether_wake, expand, expr, fakeidentd, false, fbset, fbsplash, fdflush, fdformat, fdisk, fetchmail, fgrep, find, findfs, fold, free, freeramdisk, fsck, fsck_minix, ftpget, ftpput, fuser, getenforce, getopt, getsebool, getty, grep, gunzip, gzip, halt, hd, hdparm, head, hexdump, hostid, hostname, httpd, hush, hwclock, id, ifconfig, ifdown, ifenslave, ifup, inetd, init, inotifyd, insmod, install, ip, ipaddr, ipcalc, ipcrm, ipcs, iplink, iproute, iprule, iptunnel, kbd_mode, kill, killall, killall5, klogd, lash, last, length, less, linux32, linux64, linuxrc, ln, load_policy, loadfont, loadkmap, logger, login, logname, logread, losetup, lpd, lpq, lpr, ls, lsattr, lsmod, lzmacat, makedevs, man, matchpathcon, md5sum, mdev, mesg, microcom, mkdir, mke2fs, mkfifo, mkfs_minix, mknod, mkswap, mktemp, modprobe, more, mount, mountpoint, msh, mt, mv, nameif, nc, netstat, nice, nmeter, nohup, nslookup, od, openvt, parse, passwd, patch, pgrep, pidof, ping, ping6, pipe_progress, pivot_root, pkill, poweroff, printenv, printf, ps, pscan, pwd, raidautorun, rdate, rdev, readahead, readlink, readprofile, realpath, reboot, renice, reset, resize, restorecon, rm, rmdir, rmmod, route, rpm, rpm2cpio, rtcwake, run_parts, runcon, runlevel, runsv, runsvdir, rx, script, sed, selinuxenabled, sendmail, seq, sestatus, setarch, setconsole, setenforce, setfiles, setfont, setkeycodes, setlogcons, setsebool, setsid, setuidgid, sh, sha1sum, showkey, slattach, sleep, softlimit, sort, split, start_stop_daemon, stat, strings, stty, su, sulogin, sum, sv, svlogd, swapoff, swapon, switch_root, sync, sysctl, syslogd, tac, tail, tar, taskset, tcpsvd, tee, telnet, telnetd, test, tftp, tftpd, time, top, touch, tr, traceroute, true, tty, ttysize, tune2fs, udhcpc, udhcpd, udpsvd, umount, uname, uncompress, unexpand, uniq, unix2dos, unlzma, unzip, uptime, usleep, uudecode, uuencode, vconfig, vi, vlock, watch, watchdog, wc, wget, which, who, whoami, xargs, yes, zcat, zcip
Embedded Labworks
TOOLBOX
✗ Por questões de licença, o Android implementou uma ferramenta equivalente ao Busybox chamada Toolbox, liberando-a sob a licença BSD.
✗ O código-fonte está disponível em system/core/toolbox/.
✗ O Toolbox é bem mais limitado quando comparado ao Busybox, mas inclui comandos específicos do Android (getprop, log, etc).
✗ De qualquer forma, o Busybox pode ser integrado e instalado em um sistema Android facilmente.
Embedded Labworks
COMANDOS TOOLBOXls, mount, cat, ps, kill, ln, insmod, rmmod, lsmod, ifconfig, setconsole, rm, mkdir, rmdir, getevent, sendevent, date, wipe, sync, umount, start, stop, notify, cmp, dmesg, route, hd, dd, df, getprop, setprop, watchprops, log, sleep, renice, printenv, smd, chmod, chown, newfs_msdos, netstat, ioctl, mv, schedtop, top, iftop, id, uptime, vmstat, nandread, ionice, touch, lsof, du, md5, clear, getenforce, setenforce, chcon, restorecon, runcon, getsebool, setsebool, load_policy, swapon, swapoff, mkswap, readlink
Embedded Labworks
INIT
✗ A aplicação init é executada pelo 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.
Embedded Labworks
SHELL
✗ O shell do Android é baseado 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
Embedded Labworks
DAEMONS
✗ Os daemons são processos responsáveis por 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.
Embedded Labworks
DAEMONS EM EXECUÇÃO# psUSER PID PPID VSIZE RSS WCHAN PC NAMEroot 1 0 548 372 800f9b4c 0001a068 S /initroot 1050 1 528 4 800f9b4c 0001a068 S /sbin/ueventdroot 1419 1 472 4 800968d4 00026024 S /sbin/watchdogdroot 1456 1 1436 4 8011da80 000112a8 S /sbin/healthdsystem 1459 1 1008 180 80417da4 2aba6664 S /system/bin/servicemanagerroot 1460 1 4664 936 ffffffff 2abf4f7c S /system/bin/voldroot 1461 1 9708 1076 ffffffff 2ac4af7c S /system/bin/netdroot 1462 1 1032 240 8045a0b8 2ab12378 S /system/bin/debuggerdsystem 1463 1 213084 5400 ffffffff 2ac99834 S /system/bin/surfaceflingerroot 1464 1 677876 40988 ffffffff 2ac7f7b0 S zygotedrm 1465 1 9556 3224 ffffffff 2ac93664 S /system/bin/drmservermedia 1466 1 22208 6496 ffffffff 2ac70664 S /system/bin/mediaserverinstall 1467 1 992 220 804ffbec 2ac573a0 S /system/bin/installdkeystore 1468 1 3348 988 80417da4 2acfd664 S /system/bin/keystoreroot 1469 1 2416 688 ffffffff 2abdaf7c S /system/bin/rildmedia_rw 1471 1 6072 436 ffffffff 2ad523a0 S /system/bin/sdcardroot 1480 1 3564 4 ffffffff 00019118 S /sbin/adbdroot 2364 1 936 500 80049b80 2ac88208 S /system/bin/sh
Embedded Labworks
UEVENTD
✗ O ueventd é responsável pelo gerenciamento 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 e remove os arquivos de dispositivo no /dev.
Embedded Labworks
UEVENTD (cont.)
✗ Os arquivos de configuração /ueventd.rc e /ueventd.<plat form>.rc são usados para definir as permissões dos arquivos de dispositivos criados.
✗ O campo <platform> no nome do arquivo de configuração é lido do sistema na ordem abaixo:
✗ Variável androidboot.hardware na linha de comandos do kernel.
✗ Campo Hardware do arquivo /proc/cpuinfo.
Embedded Labworks
UEVENTD.RC
# <path> <permission> <user> <group>/dev/null 0666 root root/dev/zero 0666 root root/dev/full 0666 root root/dev/ptmx 0666 root root/dev/tty 0666 root root/dev/random 0666 root root/dev/urandom 0666 root root/dev/ashmem 0666 root root/dev/binder 0666 root root/dev/log/* 0666 root log/dev/snd/dsp 0660 system audio/dev/snd/dsp1 0660 system audio/dev/snd/mixer 0660 system audio/dev/graphics/* 0660 root graphics
Embedded Labworks
VOLD
✗ O vold (Volume Daemon) monitora eventos 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).
Embedded Labworks
RILD
✗ O rild (Radio Interface Layer Daemon) 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.
Embedded Labworks
NETD
✗ O netd (Network Management Service Daemon) é 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.
Embedded Labworks
INSTALLD
✗ O installd (Install Daemon) é responsável pela instalação e desinstalação de aplicações Android (*.apk).
✗ Também é capaz de verificar integridade dos pacotes, instalar bibliotecas nativas, etc.
Embedded Labworks
DEBUGGERD
✗ O debuggerd é um daemon de depuração.
✗ É 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 a depuração com o gdb.
Embedded Labworks
OUTROS DAEMONS
✗ adbd: gerencia conexões via ADB.
✗ keystore: gerencia o armazenamento e acesso à chaves criptográficas, como por exemplo certificados SSL.
✗ watchdogd: daemon de watchdog para proteção contra travamentos da camada de usuário.
Embedded Labworks
COMANDOS DA CAMADA NATIVA
✗ netcfg: exibir informações e configurar as interfaces de rede.
✗ 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.
Embedded Labworks
COMANDOS DA CAMADA NATIVA (cont.)
✗ start/stop: iniciar/parar serviços do init.
✗ wipe: apagar a partição system ou data.
✗ log: logar uma mensagem no sistema de log do Android.
✗ logcat: exibir o log do sistema.
✗ logwrapper: permite executar um comando e redirecionar as saídas padrão e de erro para o log do Android.
Embedded Labworks
HAL
✗ Em sistemas Linux, o 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.
Embedded Labworks
LABORATÓRIO
Usando algumas ferramentas nativas
Embedded Labworks
Android embarcado
Processo de inicialização
Embedded Labworks
VISÃO GERAL DO BOOT
BootloaderCarrega o kernel para a RAM e inicia
initInicia outros serviços e aplicações
KernelMonta o rootfs indicado por ”root=”
Inicia a aplicação ”init”
Shell Outras aplicações
Rootfs
Embedded Labworks
A INICIALIZAÇÃO
✗ Após montar o rootfs, o 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
Embedded Labworks
MECANISMOS DE INICIALIZAÇÃO
✗ Assim que executado, o 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!
Embedded Labworks
INIT DO ANDROID
✗ O processo init do Android, através de alguns arquivos de configuração, é responsável por:
✗ Inicializar 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.
✗ Monitorar as propriedades do sistema e executar ações específicas quando uma propriedade for modificada.
Embedded Labworks
ARQUIVO DE CONFIGURAÇÃO
✗ O arquivo de configuração init.rc é utilizado para flexibilizar o funcionamento da aplicação init do Android.
✗ Outros arquivos de configuração podem ser incluídos com a diretiva import. Exemplo:
import /init.usb.rc
import /init.${ro.hardware}.rc
✗ A propriedade ro.hardware é setada pelo processo init, lendo do sistema na ordem abaixo:✗ Variável androidboot.hardware na linha de comandos do kernel.
✗ Campo Hardware do arquivo /proc/cpuinfo.
Embedded Labworks
SERVIÇOS E AÇÕES
✗ Os arquivos de configuração possuem basicamente dois tipos de declaração:
✗ Declaração de ação:on <trigger> <command> <command>
✗ Declaração de serviço:service <name> <pathname> [ <argument> ]* <option> <option>
Embedded Labworks
SERVIÇOS E AÇÕES (cont.)
✗ Apenas a declaração de ação resulta na execução de comandos pelo processo init.
✗ A declaração de serviço serve apenas para descrever o serviço, mas não significa que o mesmo será executado.
✗ Os serviços são executados com os comandos start ou class_start, dentro de alguma declaração de ação.
Embedded Labworks
TRIGGERS DE AÇÃO
✗ Existem duas fontes de eventos (triggers) que podem disparar uma ação:
✗ Triggers de boot.
✗ Mudança de propriedade.
Embedded Labworks
TRIGGERS DE BOOT
✗ Os triggers de boot são eventos gerados automaticamente pelo init no boot do sistema.
✗ Os seguintes triggers são gerados, nesta ordem: earlyinit, init, earlyfs, fs, postfs, postfsdata, earlyboot, boot.
✗ Cada trigger pode disparar a execução de um ou mais comandos, definidos nos arquivos de configuração do init. Exemplo:
on earlyinit write /proc/1/oom_adj 16 setcon u:r:init:s0 start ueventd
Embedded Labworks
COMANDOS
✗ São vários os comandos que podem ser usados no arquivo de configuração do init, dentre eles chdir, chmod, chown, class_start, class_stop, copy, export, ifup, insmod, loglevel, mkdir, mount, start, stop, symlink, restart.
✗ Uma descrição (desatualizada) dos comandos esta disponível nos fontes em system/core/init/readme.txt.
✗ Não são comandos do shell!
✗ Existem quatro comandos que podem ser usados para iniciar e parar serviços do init: start, stop, class_start e class_stop.
Embedded Labworks
DECLARAÇÃO DE SERVIÇOS
✗ Os serviços são processos iniciados e gerenciados pelo init, e devem ser declarados conforme abaixo:
service <name> <pathname> [ <argument> ]* <option> <option> <option> <option>
Embedded Labworks
DECLARAÇÃO DE SERVIÇOS (cont.)
service surfaceflinger /system/bin/surfaceflinger class main user system group graphics drmrpc onrestart restart zygote
service adbd /sbin/adbd class core socket adbd stream 660 system system disabled
Embedded Labworks
INICIANDO SERVIÇOS
✗ A declaração apenas descreve o serviço, mas não o inicia.
✗ Um serviço é iniciado no disparo de uma ação, através dos comandos start ou class_start. Exemplo:
on earlyinit start ueventd
Embedded Labworks
OPÇÕES DOS SERVIÇOS
class Classe à que pertence o serviço.
user Usuário do serviço.
group Grupo do serviço.
socket Criar um socket UNIX e passar o descritor ao iniciar o processo.
Embedded Labworks
OPÇÕES DOS SERVIÇOS (cont.)
disabled Não iniciar automaticamente 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.
Embedded Labworks
PROPRIEDADES
✗ Propriedades são configurações globais compartilhadas por 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 (informações do build, configuração da Dalvik, etc).
✗ /default.prop: propriedades padrão adicionais (basicamente configurações do ADB e da interface USB).
Embedded Labworks
PROPRIEDADES (cont.)
✗ /system/default.prop e /data/local.prop: propriedades específicas da plataforma (opcional).
✗ /data/property: diretório com propriedades criadas ou alteradas em tempo de execução, que persistem durante o boot.
✗ O processo init é o responsável pelo gerenciamento das propriedades, através de um UNIX domain socket em /dev/socket/property_service.
Embedded Labworks
LISTANDO AS PROPRIEDADES
✗ As propriedades podem ser listadas com o comando getprop:
# getprop[alsa.mixer.capture.headset]: [Capture][dalvik.vm.dexoptflags]: [m=y][net.hostname]: [android67af414597e8c083][persist.service.bdroid.bdaddr]: [22:22:da:0a:2d:31][ro.board.platform]: [imx6][ro.boot.hardware]: [freescale][ro.build.date]: [Fri Jun 21 15:01:11 CST 2013][ro.build.product]: [wandboard][ro.build.user]: [root][sys.boot_completed]: [1][wifi.interface]: [wlan0]
Embedded Labworks
MUDANDO PROPRIEDADES
✗ As propriedades podem ser alteradas 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.
✗ 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.
Embedded Labworks
PERMISSÕES
✗ Por padrão, os processos podem apenas 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 }
Embedded Labworks
PROPRIEDADES ESPECIAIS
ro.* Propriedades de apenas leitura, só 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.
Embedded Labworks
PROPRIEDADES NO INIT
✗ O processo init é 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
Embedded Labworks
APP_PROCESS
✗ O app_process é uma ferramenta de linha de comando capaz de instanciar uma máquina virtual para executar uma aplicação Java.
✗ Para realizar este trabalho, o app_process utiliza os serviços providos pela Android Runtime, uma biblioteca do sistema chamada libandroid_runtime.so.
✗ Esta biblioteca utiliza os serviços da camada nativa (log, propriedades, etc) para configurar e iniciar a máquina virtual Java.
Embedded Labworks
MÁQUINA VIRTUAL JAVA
✗ Até a versão 4.4 (Kitkat), a implementação de máquina virtual Java utilizada por padrão no Android é a Dalvik.
✗ A partir da versão 5.0 (Lollipop), a implementação de máquina virtual utilizada passou a ser a ART (Android Runtime).
✗ A principal vantagem da ART é a capacidade de compilar a aplicação para o target em tempo de instalação, o que deve melhorar a performance de execução das aplicações.
✗ Ambas implementações de máquina virtual utilizam as bibliotecas Java do projeto Apache Harmony.
Embedded Labworks
ZYGOTE
✗ Na inicialização do sistema, o app_process é utilizado para executar a aplicação Java mais importante do sistema, o Zygote.
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
Embedded Labworks
ZYGOTE (cont.)
✗ O zygote é um dos principais daemons do Android, responsável por:✗ 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.
Embedded Labworks
SYSTEM SERVER
✗ O system server é um processo separado executado pelo Zygote durante sua inicialização.
✗ Este processo é responsável por registrar a maioria dos 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.
Embedded Labworks
INICIALIZAÇÃO (RESUMIDA)
Kernel Linux
init
init.rc, *.rc
ZygoteSystemServer
app_process
Activity Manager Launcher
C/C++
Java
start(Launcher)
daemons
Power Manager
OutrosServiços
Embedded Labworks
PROCESSOS NA INICIALIZAÇÃO# psUSER PID PPID VSIZE RSS WCHAN PC NAMEroot 1 0 548 372 800f9b4c 0001a068 S /initsystem 1445 1 1008 180 80417da4 2acb5664 S /system/bin/servicemanagersystem 1449 1 213340 5768 ffffffff 2ac20834 S /system/bin/surfaceflingerroot 1450 1 677876 40992 ffffffff 2abd87b0 S zygotedrm 1451 1 9556 3224 ffffffff 2acfd664 S /system/bin/drmservermedia 1452 1 26288 6824 ffffffff 2ac87664 S /system/bin/mediaserversystem 1812 1450 943248 39368 ffffffff 2abd9834 S system_serveru0_a6 1872 1450 892260 41228 ffffffff 2abd9834 S com.android.systemuiu0_a1 1951 1450 691612 23184 ffffffff 2abd9834 S android.process.mediau0_a28 1965 1450 696456 23568 ffffffff 2abd9834 S com.android.inputmethod.latinradio 1999 1450 705552 24404 ffffffff 2abd9834 S com.android.phoneu0_a13 2014 1450 901736 41664 ffffffff 2abd9834 S com.android.launcheru0_a43 2027 1450 688048 17304 ffffffff 2abd9834 S com.android.printspoolersystem 2046 1450 698380 19828 ffffffff 2abd9834 S com.android.settingsu0_a11 2174 1450 689728 19864 ffffffff 2abd9834 S com.android.providers.calendaru0_a14 2189 1450 691892 19992 ffffffff 2abd9834 S com.android.mmsu0_a17 2216 1450 699528 23480 ffffffff 2abd9834 S com.android.emailu0_a35 2237 1450 695060 19640 ffffffff 2abd9834 S com.android.calendaru0_a37 2259 1450 690752 18096 ffffffff 2abd9834 S com.android.exchangeu0_a42 2273 1450 691788 20092 ffffffff 2abd9834 S com.android.deskclocku0_a8 2389 1450 686788 16352 ffffffff 2abd9834 S com.android.musicfx
Embedded Labworks
LABORATÓRIO
Alterando o processo de inicialização do Android
Embedded Labworks
Android embarcado
Produtos
Embedded Labworks
PRODUTO
✗ Um produto define todas as informações 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 (linha Nexus do Google).
✗ 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.
Embedded Labworks
CRIANDO UM PRODUTO
✗ Para criar um produto é necessário criar um diretório em device/<company>/<product>, 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
Embedded Labworks
MAKEFILE DO PRODUTO
✗ O próximo passo é 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
Embedded Labworks
MAKEFILE DO PRODUTO (cont.)
✗ O makefile do produto é usado para definir as características de software do produto (aplicações, bibliotecas, arquivos de configuração, etc).
✗ Para facilitar o desenvolvimento deste makefile, é possível herdar as configurações de um outro produto, conforme exemplo abaixo:
$(call inheritproduct, $(SRC_TARGET_DIR)/product/full.mk)
✗ Estes makefiles de produtos pré-configurados estão disponíveis no código-fonte do sistema de build em build/target/product.
Embedded Labworks
ADICIONANDO APLICAÇÕES
✗ Componentes de software podem ser incluídos no produto através da variável PRODUCT_PACKAGES:
PRODUCT_PACKAGES += \
LiveWallpapers \
Gallery2 \
SoundRecorder \
Camera \
Email \
FSLOta \
CactusPlayer \
VideoEditor \
FSLProfileApp \
FSLProfileService \
PinyinIME
Embedded Labworks
COPIANDO ARQUIVOS
✗ Na definição de um produto, é 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).
Embedded Labworks
COPIANDO ARQUIVOS (cont.)
✗ Estas customizações podem ser realizadas através da variável PRODUCT_COPY_FILES:
PRODUCT_COPY_FILES += \
device/labworks/superdroid/init.rc:root/init.rc \
device/labworks/superdroid/vold.fstab:system/etc/vold.fstab \
device/labworks/superdroid/gpsreset.sh:system/etc/gpsreset.sh
Embedded Labworks
OVERLAY
✗ Overlay é um mecanismo que possibilita 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/.
Embedded Labworks
OVERLAY (cont.)
✗ Para realizar o overlay o primeiro passo é criar o diretório de 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
Embedded Labworks
OVERLAY (cont.)
✗ E depois declarar o overlay no Makefile do produto usando DEVICE_PACKAGE_OVERLAYS ou PRODUCT_PACKAGE_OVERLAY:
DEVICE_PACKAGE_OVERLAYS := \
device/labworks/superdroid/overlay
Embedded Labworks
DEFININDO PROPRIEDADES
✗ Um produto pode definir ou 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.
Embedded Labworks
CONFIGURAÇÃO DA PLACA
✗ Junto com a definição 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.
Embedded Labworks
BoardConfig.mk
TARGET_ARCH := arm
TARGET_ARCH_VARIANT := armv7aneon
TARGET_CPU_VARIANT := cortexa9
TARGET_CPU_ABI := armeabi
BOARD_HAVE_BLUETOOTH := true
BOARD_USES_GENERIC_AUDIO := true
TARGET_USERIMAGES_USE_EXT4 := true
Embedded Labworks
OUTRAS VARIÁVEIS
✗ TARGET_EXTRA_CFLAGS: Flags adicionais que serão 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.
Embedded Labworks
vendorsetup.sh
✗ Para o produto aparecer no menu do comando lunch, é necessário criar o arquivo vendorsetup.sh e adicionar o produto conforme abaixo:
add_lunch_combo full_superdroideng
✗ Este procedimento é opcional. É possível selecionar e compilar um produto mesmo que o mesmo não seja exibido no menu do comando lunch.
Embedded Labworks
RESUMO
✗ Crie o diretório do produto em device/<company>/<product>, 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.
Embedded Labworks
LABORATÓRIO
Criando um novo produto
Embedded Labworks
Android embarcado
Módulos
Embedded Labworks
MÓDULOS
✗ Todo componente no sistema de build 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.
Embedded Labworks
EXEMPLO
LOCAL_PATH := $(call mydir)include $(CLEAR_VARS)
LOCAL_SRC_FILES = helloworld.cLOCAL_MODULE = HelloWorldLOCAL_MODULE_TAGS = optional
include $(BUILD_EXECUTABLE)
Embedded Labworks
EXEMPLO (cont.)
✗ Todas as variáveis são pré-fixadas 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.
Embedded Labworks
EXEMPLO (cont.)
✗ LOCAL_MODULE é o nome do módulo.
✗ LOCAL_MODULE_TAGS classifica o módulo através de uma tag (debug, eng, optional).
✗ include $(BUILD_EXECUTABLE) indica ao sistema de build que este módulo deve compilado como um binário.
Embedded Labworks
TEMPLATE
LOCAL_PATH := $(call mydir)include $(CLEAR_VARS)
LOCAL_VARIABLE_1 := value_1LOCAL_VARIABLE_2 := value_2...
include $(BUILD_MODULE_TYPE)
Embedded Labworks
BUILD TYPES
✗ BUILD_EXECUTABLE compila e gera um 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.
Embedded Labworks
BUILD TYPES (cont.)
✗ BUILD_RAW_EXECUTABLE compila e gera 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 um binário pré-compilado no target.
✗ BUILD_MULTI_PREBUILT instala múltiplos binários pré-compilados no target.
Embedded Labworks
BUILD TYPES (cont.)
✗ BUILD_HOST_EXECUTABLE compila e gera 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.
Embedded Labworks
DIRETÓRIOS DE INSTALAÇÃO
✗ Dependendo do tipo de 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 as variáveis LOCAL_MODULE_PATH ou LOCAL_MODULE_CLASS.
Embedded Labworks
OUTRAS VARIÁVEIS INTERESSANTES
✗ LOCAL_CFLAGS definem flags extras 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.
Embedded Labworks
MACROS
✗ Vimos no exemplo o uso da 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.
Embedded Labworks
COMPILANDO UM MÓDULO
✗ Para compilar um módulo (do diretório principal do Android):
$ make <module>
✗ Para limpar a compilação de um módulo:
$ make clean<module>
✗ Para listar todos os módulos que serão compilados:
$ make modules
Embedded Labworks
COMPILANDO UM MÓDULO (cont.)
✗ Após compilar o 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 do sistema depende da variante de compilação do produto (user, userdebug, eng).
Embedded Labworks
VARIANTES DE COMPILAÇÃO
✗ user: são incluídos na imagem todos os módulos configurados na variável PRODUCT_PACKAGES do produto.
✗ userdebug: são incluídos na imagem todos os módulos da variante user, além dos módulos com a tag debug.
✗ eng: são incluídos na imagem todos os módulos da variante userdebug, além dos módulos com a tag eng.
Embedded Labworks
IMPLEMENTANDO
✗ Como padrão, utilize em novos módulos a tag optional e inclua o nome do módulo na variável PRODUCT_PACKAGES do produto.
✗ Caso seja um módulo de testes, utilize as tags eng, debug ou tests, conforme a necessidade.
✗ Implemente novos módulos no diretório do produto em device/<company>/<product>.
✗ Na dúvida sobre a implementação de um Android.mk, consulte os diversos exemplos disponíveis no código-fonte do Android, especialmente no diretório external/.
Embedded Labworks
LABORATÓRIO
Adicionando módulos ao sistema de build
Embedded Labworks
Android embarcado
Framework Android
Embedded Labworks
FRAMEWORK ANDROID
Linux Kernel
Bibliotecas(bionic, etc)
InitToolbox
Daemons nativos
CamadaHAL
Dalvik / Android Runtime / Zygote
System Services
Android API
Aplicações
BibliotecasJava
API
Binder
JNI/Sockets
System call
Embedded Labworks
O FRAMEWORK
✗ O framework Android é a camada responsável por prover serviços para as aplicações Android.
✗ A maioria dos componentes são baseados em Java.
✗ O framework Android se comunica com a camada nativa via UNIX domain sockets e JNI (Java Native Interface).
Embedded Labworks
COMPONENTES
✗ Componentes do framework Android:✗ Android Runtime, Dalvik/ART e Zygote.
✗ System Services.
✗ Classes Java do projeto Apache Harmony.
✗ Android API.
✗ Código-fonte em frameworks/, dalvik/ e libcore/.
Embedded Labworks
COMPONENTES (cont.)
✗ Já falamos sobre a Android Runtime, Dalvik/ART 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.
Embedded Labworks
SYSTEM SERVICES
✗ System Services são serviços do Android responsáveis por prover acesso à determinado recurso para o sistema. Exemplos:
✗ Power Manager para gerenciamento de energia.
✗ Activity Manager para gerenciamento da execução dos componentes de uma aplicação Android.
✗ Package Manager para gerenciamento de pacotes Android (APK).
✗ Location Manager para gerenciamento de localização (ex: GPS).
✗ O Android 4.4 possui em torno de 76 serviços!
Embedded Labworks
LISTANDO OS SERVIÇOS
# service listFound 76 services:0 phone: [com.android.internal.telephony.ITelephony]1 iphonesubinfo: [com.android.internal.telephony.IPhoneSubInfo]2 simphonebook: [com.android.internal.telephony.IIccPhoneBook]3 isms: [com.android.internal.telephony.ISms]4 media_router: [android.media.IMediaRouterService]5 print: [android.print.IPrintManager]6 assetatlas: [android.view.IAssetAtlas]7 dreams: [android.service.dreams.IDreamManager]8 commontime_management: []9 samplingprofiler: []10 diskstats: []11 appwidget: [com.android.internal.appwidget.IAppWidgetService]12 backup: [android.app.backup.IBackupManager]13 uimode: [android.app.IUiModeManager]14 serial: [android.hardware.ISerialManager][...]
Embedded Labworks
VANTAGENS
✗ Principais vantagens da implementação dos serviços do sistema no Android:
✗ Abstrair o acesso à determinado recurso do sistema.
✗ Controlar e centralizar o acesso ao recurso.
✗ Garantir segurança no acesso ao recurso.
Embedded Labworks
SERVIÇOS E PROCESSOS
✗ A maioria dos 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, Healthd).
✗ Os serviços podem também estar encapsulados em uma aplicação Android (Ex: Nfc).
Embedded Labworks
SERVIÇOS E PROCESSOS (cont.)
✗ system_server: processo 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.
Embedded Labworks
SERVIÇOS E PROCESSOS (cont.)
✗ drmserver: processo do DRM Server, responsável pelo gerenciamento de conteúdos protegidos por direitos autorais.
✗ healthd: serviço de monitoramento do status da bateria.
Embedded Labworks
INICIALIZAÇÃO DOS SERVIÇOS
Kernel Linux
init
init.rc, *.rc
Zygote
app_process
Activity Manager
Power Manager
...
surfaceflinger
drmserver
mediaserver
system_server
healthd
Embedded Labworks
MECANISMO DE COMUNICAÇÃO
✗ Em sistemas operacionais modernos, 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.
Embedded Labworks
COMO FUNCIONA O BINDER?
✗ Na 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.
Embedded Labworks
INICIALIZAÇÃO DO BINDER
Service Manager System Services
/dev/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.
Embedded Labworks
COMUNICAÇÃO VIA BINDER
✗ Quando uma aplicação Android 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.
Embedded Labworks
EXEMPLO (POWER MANAGER SERVICE)
PowerManager pm = (PowerManager) getSystemService(POWER_SERVICE);
PowerManager.WakeLock wakeLock = pm.newWakeLock( PowerManager.FULL_WAKE_LOCK, "myWakeLock");
wakeLock.acquire(250);
Embedded Labworks
DIAGRAMA (POWER MANAGER SERVICE)
Service Manager Power Manager 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.
Embedded Labworks
DOCUMENTAÇÃO DOS SERVIÇOS
✗ Os serviços do sistema 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/SystemServer.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.
Embedded Labworks
PROCESSOS INICIADOS POR SERVIÇOS
✗ Os serviços do 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.
✗ O Activity Manager também envia um Intent do tipo Intent.BOOT_COMPLETED, notificando sobre o final do processo de boot para sistema.
Embedded Labworks
COMANDOS DO FRAMEWORK
service permite interagir com os serviços registrados no sistema.
input permite injetar eventos de input no sistema (teclado, touchscreen, etc).
wm permite interagir com o Window Manager.
media permite interagir com o Media Server.
Embedded Labworks
COMANDOS DO FRAMEWORK (cont.)
am permite se comunicar 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, Connectivity Manager, USB Manager).
Embedded Labworks
MODIFICANDO O FRAMEWORK
✗ A arquitetura do framework 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.
Embedded Labworks
LABORATÓRIO
Manipulando o framework Android
Embedded Labworks
Android embarcado
Estendendo o framework
Embedded Labworks
POR QUÊ?
✗ Em alguns casos, principalmente quando estamos trabalhando com sistemas embarcados, a API do Android pode não suportar determinado dispositivo de hardware (GPIO, porta serial, E2PROM, etc).
✗ E na ausência de uma API, o modelo de segurança do Android não permite que uma aplicação acesse diretamente um dispositivo de hardware.
✗ Neste caso, a melhor solução é estender o framework do Android, adicionando o suporte ao novo dispositivo de hardware.
Embedded Labworks
AS CAMADAS
Kernel
HAL
Serviço
API
Aplicação
Kernel space
User space
Binder
JNI
Embedded Labworks
A APLICAÇÃO
✗ O que queremos é uma aplicação que possa ter acesso ao dispositivo de hardware através de um serviço do sistema:
GPIOManager gpio = (GPIOManager) getSystemService(Context.GPIO_SERVICE);gpio.write(GPIO_NUM, value);
Embedded Labworks
MANAGER
✗ O primeiro passo para estender o framework é criar a classe Manager.
✗ A classe Manager será responsável por fornecer uma API para as aplicações acessarem o dispositivo de hardware.
✗ A classe Manager se comunicará com o serviço via Binder.
✗ As classes Manager são normalmente implementadas em:
frameworks/base/core/java/android/os/
frameworks/base/services/java/com/android/server/
Embedded Labworks
CLASSE MANAGER (EXEMPLO)
public class GPIOManager{ IGPIOService mService;
public GPIOManager(IGPIOService service) { mService = service; }
public int write(int number, int value) { try { return mService.set(number, value); } catch (RemoteException e) { return 0; } }}
Embedded Labworks
SERVIÇOS
✗ A implementação do serviço se divide em duas partes:✗ A definição de sua interface através da linguagem AIDL.
✗ A implementação do serviço em si.
✗ Boa parte dos serviços estão implementados no código-fonte em frameworks/base/services/.
Embedded Labworks
AIDL
✗ AIDL é a linguagem usada pelo Android para definir a interface de acesso entre um cliente e um servidor na comunicação via Binder.
// IGPIOService.aidl
interface IGPIOService {
int set(int number, int value);
}
✗ Uma ferramenta chamada aidl é responsável por converter o arquivo aidl na sua implementação Java, para ser usada tanto pelo cliente (Manager) quanto pelo servidor (Serviço).
✗ Mais informações sobre o aidl na documentação do Google em http://developer.android.com/guide/components/aidl.html.
Embedded Labworks
SERVIÇO (EXEMPLO)
public class GPIOService extends IGPIOService.Stub {
private static final String TAG = "GPIO";
public GPIOService(Context context) { super(); Log.i(TAG, "Service started"); }
public int set(int number, int value) { return set_native(number, value); }
private static native int set_native(int number, int value);}
Embedded Labworks
PROXY E STUB
Manager
Proxy (marshalling)
Binder
Stub (unmarshalling)
Serviço
Kernel
HAL
Serviço
API
Aplicação
Kernel space
User space
Binder
JNI
As classes Proxy e Stub são criadas através da declaração da interface via AIDL.
Embedded Labworks
JNI
✗ Os serviços que possibilitam o acesso à um dispositivo de hardware utilizam normalmente algumas funções nativas implementadas em C ou C++ para acessar o hardware.
✗ Para implementar este acesso é utilizado o JNI, um framework de desenvolvimento 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, o JNI está implementado na biblioteca libnativehelper.so.
Embedded Labworks
JNI (EXEMPLO)
#include "jni.h"#include "JNIHelp.h"
static int set_native(JNIEnv *env, jobject obj, jint number, jint value){ if (gpio_export(number)) return 1;
if (gpio_set_direction(number, "out")) return 1;
return gpio_write(number, value);}
Embedded Labworks
SERVIÇO DE GPIO
GPIO Driver
HAL (Biblioteca GPIO)
GPIO Service
GPIO Manager
Aplicação
Kernel space
User space
C/C++
Java
Binder
GPIOService.javacom_android_server_GPIOService.cpp
GPIOManager.java
IGPIOService.aidlIGPIOService.java
libgpio.so
Embedded Labworks
PROBLEMAS EM ESTENDER O FRAMEWORK
✗ Possibilidade de quebrar a API e adicionar algum bug.
✗ Impossibilita a certificação do dispositivo pelo Google (não passará pelo CTS).
✗ É trabalhoso manter e portar as alterações para outras versões do Android.
Embedded Labworks
SOLUÇÕES ALTERNATIVAS
✗ Serviços podem ser implementados separadamente, através de aplicações standalone (C/C++):frameworks/native/services/surfaceflinger/
✗ Serviços podem também ser implementados dentro de uma aplicação Android:packages/apps/Nfc/
✗ É possível extender a API do Android sem alterar seu framework através de Platform Libraries.device/sample/frameworks/PlatformLibrary/README.txt
✗ E usar um SDK add-on para integrar no Eclipse:device/sample/products/sample_addon.mk
Embedded Labworks
LABORATÓRIO
Estendendo o framework do Android
Embedded Labworks
Android embarcado
Aplicações Android
Embedded Labworks
APLICAÇÕES ANDROID
Linux Kernel
Bibliotecas(bionic, etc)
InitToolbox
Daemons nativos
CamadaHAL
Dalvik / Android Runtime / Zygote
System Services
Android API
Aplicações
BibliotecasJava
API
Binder
JNI
System call
Embedded Labworks
APLICAÇÕES ANDROID (cont.)
✗ Tudo o que vimos 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.
Embedded Labworks
API ANDROID
✗ Todo o desenvolvimento de aplicações é 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 está disponível em:
http://developer.android.com/reference/packages.html
Embedded Labworks
COMPONENTES DAS APLICAÇÕES
✗ As aplicações Android são compostas por 4 tipos diferentes de componentes:
✗ Activities
✗ Services
✗ Broadcast receivers
✗ Content providers
Embedded Labworks
ACTIVITIES
✗ Activities representam as telas de interface 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.
Embedded Labworks
BACK STACK
Activity 1
Back Stack
Activity 2
Back Stack
Activity 1
Activity 3
Back Stack
Activity 2
Activity 1
Activity 2
Back Stack
Activity 1
Inicia activity 2 Inicia activity 3 Volta navegação
Activity em foreground
Activity 3removida do
stack!
Embedded Labworks
SERVICES
✗ Services (serviços) são componentes que rodam 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!
Embedded Labworks
BROADCAST RECEIVERS
✗ Broadcast receivers são componentes que 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.
Embedded Labworks
CONTENT PROVIDERS
✗ Content providers são capazer de prover acesso aos dados de forma organizada, similar à um banco de dados relacional.
✗ Uma aplicação deve implementar um content provider quando deseja compartilhar dados com outras aplicações.
✗ A maioria das aplicações utiliza o SQlite para armazenar os dados, mas o desenvolvedor pode usar outros tipos de armazenamento se desejar (memória, disco, rede, etc).
Embedded Labworks
ARMAZENAMENTO PERSISTENTE
✗ Uma aplicação pode armazenar dados 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.
✗ Mais informações em:
http://developer.android.com/guide/topics/data/data-storage.html
Embedded Labworks
ARQUIVO DE MANIFESTO
✗ Toda aplicação possui um 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.
Embedded Labworks
ARQUIVO DE MANIFESTO (EXEMPLO)<manifest package="com.example.android.notepad"> <application android:icon="@drawable/app_notes" android:label="@string/app_name" > <activity android:name="NotesList" android:label="@string/title_notes_list"> <intentfilter> <action android:name="android.intent.action.MAIN" /> <category android:name="android.intent.category.LAUNCHER" /> </intentfilter> <intentfilter> <action android:name="android.intent.action.VIEW" /> <action android:name="android.intent.action.EDIT" /> <action android:name="android.intent.action.PICK" /> <category android:name="android.intent.category.DEFAULT" /> <data android:mimeType="vnd.android.cursor.dir/vnd.google.note" /> </intentfilter> </activity> </application></manifest>
Embedded Labworks
COMUNICAÇÃO ENTRE COMPONENTES
✗ Uma aplicação pode conter um ou mais componentes.
✗ Uma 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.
Embedded Labworks
INTENT
✗ O intent é um mecanismo de 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.
Embedded Labworks
INTENT (cont.)
✗ Activities, Services e Broadcast receivers 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.
✗ Mais informações sobre Intents:
http://developer.android.com/guide/components/intents-filters.html
Embedded Labworks
REGISTRANDO ACTIVITY COMO BROWSER
<! AndroidManifest.xml > <activity android:name=".BrowserActivitiy" android:label="@string/app_name"> <intentfilter> <action android:name="android.intent.action.VIEW" /> <category android:name="android.intent.category.DEFAULT" /> <data android:scheme="http"/> </intentfilter></activity>
Embedded Labworks
EXECUTANDO ACTIVITY DO TIPO BROWSER
Intent i = new Intent(Intent.ACTION_VIEW, Uri.parse("http://www.sergioprado.org"));startActivity(i);
Embedded Labworks
DIAGRAMA INTENT
ActivityManager
AplicaçãoAndroid
PackageManager Zygote
AplicaçãoBrowser
1
2 3
4
Embedded Labworks
RECURSOS
✗ Além do código-fonte, uma aplicação pode 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.
Embedded Labworks
PROCESSOS NO ANDROID
✗ Por padrão no Android, 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.
Embedded Labworks
THREADS DE EXECUÇÃO
✗ Como uma aplicação Android 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.
Embedded Labworks
CRIANDO THREADS
✗ Existem duas formas de implementar 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).
✗ Mais informações em:
http://developer.android.com/reference/android/os/AsyncTask.html
Embedded Labworks
CICLO DE VIDA DA APLICAÇÃO
✗ Um ponto 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.
Embedded Labworks
CICLO DE VIDA DA APLICAÇÃO (cont.)
✗ Por 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.
Embedded Labworks
CICLO DE VIDA DA APLICAÇÃO (DIAGRAMA)
Referência: http://developer.android.com
Embedded Labworks
GERENCIAMENTO DE MEMÓRIA
✗ Quando o uso de 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.
Embedded Labworks
PRIORIDADE DOS PROCESSOS
✗ O sistema define a prioridade de cada processo de acordo com seu status:
✗ Processos vazios (sem componentes).
✗ Processos em background que não são mais visíveis aos usuários.
✗ Serviço iniciado por um processo em background.
✗ Processos visíveis, como uma activity que não esta mais em foreground mas ainda é visível no display.
✗ Processos rodando em foreground possuem a maior prioridade (activity, service ou broadcast receiver ativo).
Embedded Labworks
SEGURANÇA
✗ Uma vez instalada, cada aplicação roda 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.
Embedded Labworks
SEGURANÇA (cont.)
✗ Para que uma aplicação possa 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.
✗ Uma lista completa das permissões existentes está disponível em:
http://developer.android.com/reference/android/Manifest.permission.html
Embedded Labworks
PERMISSÕES ...<usespermission android:name="android.permission.WRITE_SMS" /> <usespermission android:name="android.permission.READ_SMS" /> <usespermission android:name="android.permission.RECEIVE_SMS" />...
Embedded Labworks
PERMISSÕES (cont.)
✗ Quando a aplicação tentar acessar 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.
Embedded Labworks
EXEMPLO PERMISSÃO SMS
Aplicação
Phone Manager PackageManager
HAL (rild)
Kernel
Unix domain Socket
Binder
Binder
23
4
5
Android API
SmsManager.sendTextMessage()1
Embedded Labworks
NDK
✗ O NDK (Native Development Kit) é 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++!
Embedded Labworks
NDK (cont.)
✗ Também é empacotado igual à 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.
Embedded Labworks
DISTRIBUINDO APLICAÇÕES
✗ As aplicações podem ser instaladas 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!
https://f-droid.org/
Embedded Labworks
FERRAMENTAS E DOCUMENTAÇÃO
✗ O Android Studio é a ferramenta oficial liberada pelo Google para o desenvolvimento de aplicações Android.
http://developer.android.com/tools/studio/index.html
✗ Também é possível utilizar o Eclipse com o plugin ADT (Android Developer Tools).
http://developer.android.com/sdk/installing/installing-adt.html
✗ Toda a documentação da API do Android está disponível em:
http://developer.android.com
Embedded Labworks
LABORATÓRIO
Desenvolvendo aplicações Android
Embedded Labworks
Android embarcado
Android HAL
Embedded Labworks
ABSTRAÇÃO DE HARDWARE NO LINUX
Kernel Linux
Bibliotecas e Aplicações
Kernel space
Hardware
User space
Driver
Embedded Labworks
ABSTRAÇÃO DE HARDWARE NO ANDROID
Kernel Linux
Driver
HAL (*.so)
HW Service
System Services
API (android.*)
Aplicações
Kernel space
User space
C
Java
Embedded Labworks
ANDROID HAL
✗ Em sistemas Linux, o acesso à 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.
Embedded Labworks
MOTIVAÇÕES
✗ As duas principais motivações para a decisão de utilizar uma camada adicional de abstração de hardware no Android:
✗ Desacoplamento do código Java da camada nativa e do hardware.
✗ Liberdade para o fabricante implementar a lógica de acesso ao hardware na HAL e liberar sob qualquer licença de software.
Embedded Labworks
IMPLEMENTAÇÃO
✗ A HAL é normalmente 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.
Embedded Labworks
SERVIÇOS E HAL
✗ De forma geral, cada 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.
Embedded Labworks
SERVIÇOS E HAL (cont.)
Hardware
CameraDriver
SensorsDrivers
DisplayDrivers ...
Aplicações e API
Binder
JNI/Socket
System call
CameraHAL
SensorsHAL
GraphicsHAL ...
Kernel
Camada nativa
FrameworkAndroid
Hardware
MediaServer
SensorsService
Surface Flinger ...
Embedded Labworks
GRAPHICS HAL
Embedded Labworks
AUDIO HAL
Embedded Labworks
BLUETOOTH HAL
Embedded Labworks
SENSORS HAL
Embedded Labworks
BIBLIOTECAS DA HAL
✗ As bibliotecas da 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
Embedded Labworks
LISTAGEM HAL
# ls /system/lib/hwaudio.a2dp.default.so gralloc_viv.imx6.soaudio_policy.default.so hwcomposer_fsl.imx6.soaudio.primary.default.so hwcomposer.imx6.soaudio.primary.imx6.so hwcomposer_viv.imx6.soaudio.r_submix.default.so keystore.default.soaudio.usb.default.so lights.imx6.sobluetooth.default.so local_time.default.socamera.imx6.so power.default.sogralloc.default.so power.imx6.sogralloc.imx6.so
Embedded Labworks
DESCRIÇÃO DA HAL
✗ audio.primary.<device>.so: camada de áudio, 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).
Embedded Labworks
DESCRIÇÃO DA HAL (cont.)
✗ bluetooth.<device>.so: acesso à 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.
Embedded Labworks
IMPLEMENTANDO A HAL
✗ Implementar uma HAL é 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-fonte!
Embedded Labworks
IMPLEMENTANDO A HAL (cont.)
✗ Uma visão geral da HAL está documentada pelo Google:
http://source.android.com/devices/index.html
✗ O código-fonte com a definição da HAL e alguns exemplos pode ser encontrada no diretório hardware/.
✗ A definição da API encontra-se em:
hardware/libhardware/include/hardware/hardware/libhardware_legacy/include/hardware_legacy/
Embedded Labworks
IMPLEMENTANDO A HAL (cont.)
✗ Uma implementação padrão da HAL está disponível em hardware/libhardware/modules.
✗ O AOSP inclui o código-fonte da HAL para suportar alguns dispositivos de hardware de mercado, que pode ser usado como referência para novas implementações.
✗ Veja o diretório device/ no AOSP para alguns exemplos.
Embedded Labworks
OUTROS ACESSOS
✗ Nem todo acesso ao hardware 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.
Embedded Labworks
LABORATÓRIO
Implementando uma HAL de sensores
Embedded Labworks
Android embarcado
Debugging
Embedded Labworks
FERRAMENTAS DO SISTEMA
✗ Várias ferramentas de linha de comando estão disponíveis para ajudar na análise do sistema como um todo.
✗ Algumas ferramentas são comuns em sistemas Linux, outras são específicas do Android.
✗ Elas permitem analisar o funcionamento de uma determinada parte do sistema, como memória, CPU, acesso à rede, etc.
Embedded Labworks
FERRAMENTAS DO SISTEMA (cont.)
ps listar todos os processos em execução.
top exibir os processos ordenados por consumo de recursos (memória e CPU).
cpustats estatística de uso da(s) CPU(s).
schedtop estatísticas de uso de CPU por processo.
Embedded Labworks
FERRAMENTAS DO SISTEMA (cont.)
procrank exibe uma lista de processos ordenados por consumo de RAM.
procmem informações de uso de memória por determinado processo.
showmap exibe o mapa de memória de um processo.
strace monitora as chamadas de sistema de uma aplicação.
Embedded Labworks
LOGCAT
✗ O sistema de logs do Android 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
Embedded Labworks
LOG POR BUFFER
✗ O log pode ser filtrado por buffer, conforme abaixo:
# logcat b radio
✗ Os seguintes buffers estão disponíveis:✗ radio: mensagens relacionadas à comunicação com o radio.
✗ events: mensagens do sistema, principalmente relacionada à eventos do framework.
✗ system: mensagens do sistema, usado principalmente pela camada nativa e pelo framework Android.
✗ main: todo o restante, mas principalmente mensagens de log das aplicações.
Embedded Labworks
TAG E PRIORIDADE
✗ Os logs são exibidos 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 VerboseD DebugI InfoW WarningE ErrorF Fatal
Embedded Labworks
FILTRANDO POR TAG E PRIORIDADE
✗ Filtro por tag:
$ logcat s ActivityManager
✗ Filtro por tag e prioridade:
$ logcat s ActivityManager:I
✗ Filtro por prioridade:
$ logcat s *:E
Embedded Labworks
DUMPSYS
✗ O dumpsys é uma ferramenta capaz 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
...
Embedded Labworks
DUMPSTATE
✗ O dumpstate é uma ferramenta capaz de tirar um dump de todo o sistema.
# dumpstate
[...]
Kernel: Linux version 2.6.2900261g0097074dirty (digit@digit.mtv.corp.google.c
om) (gcc version 4.4.0 (GCC) ) #20 Wed Mar 31 09:54:02 PDT 2010
Command line: qemu=1 console=ttyS0 android.checkjni=1 android.qemud=ttyS1 androi
d.ndns=1
MEMORY INFO (/proc/meminfo)
MemTotal:
94096 kB
[...]
CPU INFO (top n 1 d 1 m 30 t)
User 2%, System 11%, IOW 33%, IRQ 0%
User 3 + Nice 0 + Sys 15 + Idle 67 + IOW 42 + IRQ 0 + SIRQ 0 = 127
[...]
Embedded Labworks
ADB
✗ Normalmente o processo de depuração em 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.
Embedded Labworks
ADB (cont.)
✗ O ADB (Android Debug Bridge) é uma ferramenta de debugging que pode funcionar em conexões USB ou TCP/IP.
✗ É composto por quatro componentes:✗ Cliente ADB (host), que serve de interface (modo texto) para a
execução de comandos no target.
✗ Servidor ADB (host), que gerencia a comunicação com o(s) cliente(s) ADB e se comunica com o daemon ADB no target.
✗ Driver Android USB Gadget (target).
✗ Daemon ADB (target), que recebe e trata os comandos recebidos do host.
Embedded Labworks
ARQUITETURA ADB
ADB Server
ADB ClientUsuário
Android Gadget Driver
adbd
Host Target
Embedded Labworks
COMANDOS ADB
startserver Inicia o servidor ADB no 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.
Embedded Labworks
COMANDOS ADB (cont.)
push Copia arquivos do host 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.
Embedded Labworks
COMANDOS ADB (cont.)
logcat Imprime o log do 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.
Embedded Labworks
COMANDOS ADB (cont.)
remount Remonta a partição system/ compermissão de leitura e escrita.
reboot Reinicia o dispositivo (opçõesbootloader 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).
Embedded Labworks
COMANDOS ADB (cont.)
✗ usb Reinicia o daemon 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.
Embedded Labworks
GDB
✗ Com o parâmetro forward do comando ADB é possível redirecionar qualquer porta entre o host e o target, possibilitando por exemplo o debugging com o GDB via ADB!
✗ 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
Embedded Labworks
ARQUITETURA ADB E GDB
ADB Server
Usuário
Android Gadget Driver
adbd
Host Target
localhost:1234
gdbserver
localhost:1234
gdb
Embedded Labworks
DEPURANDO APLICAÇÕES JAVA
✗ Durante a inicialização, o 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.
Embedded Labworks
JDB NA LINHA DE COMANDO
✗ Exiba primeiro a lista de processos Java depuráveis com o comando abaixo:
$ adb jdwp271376...
✗ Crie o redirecionamento para o PID do processo:
$ adb forward tcp:8000 jdwp:376
✗ E inicie o debugger:
$ jdb attach localhost:8000
Embedded Labworks
ARQUITETURA ADB E JDB
ADB Server
Usuário
Android Gadget Driver
adbd
Host Target
jdwp:pid
Processo Java
localhost:8000
jdb
Embedded Labworks
TOMBSTONES
✗ Sempre que um processo encerra abruptamente (crash) no Android, um arquivo especial chamado tombstone é gerado no diretório /data/tombstones/.
✗ Estes arquivos podem ajudar na análise do problema em um componente do sistema (aplicação, framework, biblioteca nativa, etc).
✗ Através dos tombstones, e usando uma ferramenta do toolchain chamada addr2line, conseguimos chegar na linha de código com problema!
Embedded Labworks
TOMBSTONE (EXEMPLO)*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***Build fingerprint: 'unknown'Revision: '405522'pid: 10071, tid: 10071, name: tcpdump >>> tcpdump <<<signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 00000000 r0 ffffffa0 r1 ffffffff r2 ffffff98 r3 00000000 r4 0002f0e0 r5 7ec459b4 r6 00000001 r7 2abdae14 r8 00000000 r9 00000000 sl 00000000 fp 7ec459ac ip 2abdaf38 sp 7ec457f8 lr 2ab8e433 pc 2ab8e446 cpsr 60000030 d0 9d2d6d40019b7a7b d1 0000000000000000 d2 0000000000000000 d3 0000000000000000[...]
backtrace: #00 pc 0004c446 /system/xbin/tcpdump #01 pc 0001273f /system/lib/libc.so (__libc_init+38) #02 pc 0000d1f0 /system/xbin/tcpdump stack: 7ec457b8 2acb6041 /system/bin/linker
Embedded Labworks
ANR
✗ ANR ou "Application Not Responding" é um erro comum em aplicações Android.
✗ A mensagem de ANR é exibida se um componente de uma aplicação em foreground ficar mais de 5 segundos sem responder à um evento de entrada (botão, touch, etc).
✗ Quando a ANR acontece, um log com informações do erro é salvo em /data/anr/traces.txt.
Embedded Labworks
ANR (EXEMPLO) pid 11663 at 19700102 00:53:03 Cmd line: com.android.development
DALVIK THREADS:(mutexes: tll=0 tsl=0 tscl=0 ghl=0)
"main" prio=5 tid=1 TIMED_WAIT | group="main" sCount=1 dsCount=0 obj=0x2b6d19a0 self=0x4c8a2010 | sysTid=11663 nice=0 sched=0/0 cgrp=[nocpusubsys] handle=716739548 | state=S schedstat=( 0 0 0 ) utm=9 stm=1 core=1 at java.lang.VMThread.sleep(Native Method) at java.lang.Thread.sleep(Thread.java:1031) at java.lang.Thread.sleep(Thread.java:1013) at com.android.development.BadBehaviorActivity$BadService.onStartCommand (BadBehaviorActivity.java:66) at android.app.ActivityThread.handleServiceArgs(ActivityThread.java:2656) at android.app.ActivityThread.access$1900(ActivityThread.java:141) at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1331) at android.os.Handler.dispatchMessage(Handler.java:99) at android.os.Looper.loop(Looper.java:137)
Embedded Labworks
DEV TOOLS
✗ Dev Tools é uma aplicação disponível no AOSP em development/apps/Development.
✗ Esta aplicação possui diversas ferramentas interessantes para testar e depurar o sistema, incluindo:
✗ Exibição de estatísticas de uso da CPU no display.
✗ Customização do comportamento da GPU.
✗ Exibição de informações sobre o touchscreen no display.
✗ Possibilidade de causar crash ou ANR.
Embedded Labworks
MONKEY
✗ Monkey é uma ferramenta de linha 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!
Embedded Labworks
MONKEYRUNNER
✗ O monkeyrunner é uma ferramenta de 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
Embedded Labworks
EXEMPLO SCRIPT MONKEYRUNNERfrom com.android.monkeyrunner import MonkeyRunner, MonkeyDevice
device = MonkeyRunner.waitForConnection()
device.installPackage('myproject/bin/MyApplication.apk')
package = 'com.example.android.myapplication'activity = 'com.example.android.myapplication.MainActivity'runComponent = package + '/' + activity
device.startActivity(component=runComponent)
device.press('KEYCODE_MENU', MonkeyDevice.DOWN_AND_UP)
result = device.takeSnapshot()result.writeToFile('myproject/shot1.png','png')
Embedded Labworks
DDMS
✗ O DDMS (Dalvik Debug Monitor Server) é 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.
Embedded Labworks
DDMS NO ECLIPSE
Embedded Labworks
TRACING
✗ A aplicação pode gerar um arquivo 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.
Embedded Labworks
TRACEVIEW
Embedded Labworks
DMTRACEDUMP
Embedded Labworks
LABORATÓRIO
Usando ferramentas de debugging
Embedded Labworks
Android embarcado
E agora?
Embedded Labworks
RECURSOS ONLINE
✗ Android Open Source Project:
https://source.android.com/
✗ Android Developer:
https://developer.android.com/
✗ Android Tools Project Site (SDK):
http://tools.android.com/
Embedded Labworks
RECURSOS ONLINE (cont.)
✗ Embedded Linux Wiki (seção sobre o Android):
http://www.elinux.org/Android_Portal
✗ Linaro Android:
https://wiki.linaro.org/Platform/Android
✗ CyanogenMod:
http://www.cyanogenmod.org/
Embedded Labworks
RECURSOS ONLINE (cont.)
✗ XDA Developer (seção sobre o Android):
https://www.xda-developers.com/tag/all-android/
✗ Android Builder's Summit vídeos:
http://video.linux.com/
Embedded Labworks
LIVROS
Embedded AndroidKarim Yaghmour
Android InternalsJonathan Levin
Embedded Labworks
PERGUNTAS OU COMENTÁRIOS FINAIS?
Embedded Labworks
Por Sergio Prado. São Paulo, Abril de 2015® Copyright Embedded Labworks 2004-2015. All rights reserved.
OBRIGADO!
E-mail sergio.prado@e-labworks.comWebsite http://e-labworks.com
Recommended