SlideShare une entreprise Scribd logo

Treinamento Android Embarcado

•
•
Odair Sousa
Odair Sousa

Treinamento Android Embarcado

Mobile
1  sur  356
Télécharger pour lire hors ligne
Embedded Labworks Por Sergio Prado. São Paulo, Maio de 2013 ® Copyright Embedded Labworks 2004-2013. 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ório dl/ Aplicações e componentes open­source que serão usados durante as atividades de laboratório docs/ Documentação guides/ Guias de consulta (shell, vi, etc)   hardware/ Documentação do hardware   training/ Slides e atividades de laboratório ex/ Exercícios de laboratório tools/ 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) ✗ Este treinamento é baseado no Jelly Bean 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 850.000 aplicações em set/2013). ✗ 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 DIAGRAMA DE BLOCOS Fonte: http://source.android.com
Embedded Labworks PORTANDO O ANDROID (PASSO-A-PASSO) 1. Escolher uma plataforma de hardware compatível com os requisitos do Android. 2. Portar o bootloader para a plataforma de desenvolvimento. 3. Portar o kernel Linux para a plataforma de desenvolvimento (com os patches do Android aplicados). 4. Preparar o sistema de build do Android para compilar e gerar uma versão customizada da plataforma Android para o seu hardware. 5. Implementar a camada HAL do Android para os dispositivos de hardware presentes no sistema.
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 12.04, já que esta é a configuração usada e testada pelo Google, mas o sistema de build deve funcionar em outras máquinas Linux ou MacOS (instalação nativa ou máquina virtual). ✗ É necessário uma máquina com boa capacidade de processamento (ex: Core i7) e com bastante espaço em disco (os fontes do Android 4.2 ocupam 10G de disco, passando de 25G depois de compilado!). ✗ Pré-requisitos de software: git 1.7+, python 2.6/2.7, make 3.81/3.82, JDK 6. ✗ Consulte o link abaixo para instruções mais completas: http://source.android.com/source/initializing.html
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 (últimos smartphones e tablets do mercado). ✗ 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/git­repo­downloads/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="UTF­8"?> <manifest>   <remote  name="aosp"            fetch=".."            review="https://android­review.googlesource.com/" />   <default revision="refs/tags/android­4.2.2_r1.1"            remote="aosp"            sync­j="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! $ ls abi       dalvik       frameworks       Makefile  prebuilts bionic    development  gdk              ndk       sdk bootable  device       hardware         out       system build     docs         libcore          packages cts       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 ANDROID PARA A WANDBOARD $ repo init ­u git://www.wandboard.org/android/manifest.git ­m default.xml  $ repo sync ­j4 [...] $ ls abi       dalvik       frameworks  libnativehelper  prebuilts bionic    development  gdk         Makefile         sdk bootable  device       hardware    ndk              system build     docs         kernel_imx  packages cts       external     libcore     pdk ✗ Instruções para baixar o código-fonte do Android para a Wandboard no link abaixo: http://www.wandboard.org/index.php/downloads
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. ✗ 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/: outras 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 LABORATÓRIO Preparando a máquina e baixando o código-fonte
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 Yocto. ✗ 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 do comando lunch.
Embedded Labworks LUNCH $ lunch You're building on Linux Lunch menu... pick a combo:      1. full­eng      2. full_x86­eng      3. vbox_x86­eng      4. full_mips­eng      5. full_grouper­userdebug      6. full_tilapia­userdebug      7. imx53_smd­eng      8. imx53_smd­user Which would you like? [full­eng]
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 full­eng ✗ 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 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/ android­info.txt        installed­files.txt       system clean_steps.mk          obj                       system.img data                    previous_build_config.mk  test dex_bootjars            ramdisk.img               userdata.img hardware­qemu.ini       root                      userdata­qemu.img hardware­qemu.ini.lock  symbols                   userdata­qemu.img.lock
Embedded Labworks OUTROS COMANDOS MAKE ✗ Limpar a compilação do produto selecionado: $ make clean ✗ Limpar a compilação de todos os produtos: $ make clobber ✗ Limpar apenas o necessário em uma troca de configuração (produto): $ make installclean
Embedded Labworks OUTROS COMANDOS MAKE (cont.) ✗ Exibir os comandos executados durante a compilação: $ make showcommands ✗ Compilar apenas um módulo: $ make <module> ✗ Limpar a compilação de um módulo: $ make clean­<module>
Embedded Labworks OUTROS COMANDOS DE COMPILAÇÃO ✗ Compilar o sistema de qualquer diretório: $ m ✗ Compilar todos os módulos no diretório corrente: $ mm ✗ Compilar todos os módulos de um diretório específico: $ mmm <diretório>
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 full, full_x86 e full_mips. ✗ É capaz de emular a interface com o usuário via monitor, teclado e mouse. ✗ Diversos outros dispositivos de hardware e eventos como coordenadas GPS, recebimento de SMS ou mudança de status da bateria podem ser emulados através de uma conexão telnet.
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 full­eng $ 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, em específico ARMv7 (Cortex-A8) com um ou mais núcleos rodando acima de 1GHz. ✗ Arquiteturas como x86 e MIPS também são suportadas por outras empresas ou pela comunidade: http://www.android-x86.org/ http://developer.mips.com/android/ ✗ A partir do Android 4.0, é necessário também uma GPU com suporte à OpenGL ES 2.0.
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/guides: ✗ 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: ✗ Inicialização básica do hardware. ✗ Carregar outro binário (normalmente um sistema operacional) da memória flash, da rede ou de outro dispositivo de armazenamento não volátil para a RAM. ✗ Passar o controle da CPU para este binário. ✗ Além destas funcionalidades básicas, a maioria dos bootloaders possui uma linha de comandos para a execução de diferentes operações, como verificação de memória, formatação da flash e rotinas de diagnóstico.
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 $ fastboot usage: 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   reboot­bootloader                        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 eventos Exportaçã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 subir um sistema Android com uma versão vanilla 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 Manager Activity Manager Mount Service ... System Server 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/SYSV­IPC.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, 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 WAKELOCKS (cont.) ✗ API em espaço de kernel: #include <linux/wakelock.h> void wake_lock_init(struct wakelock *lock, int type,                      const char *name); void wake_lock(struct wake_lock *lock); void wake_unlock(struct wake_lock *lock); void wake_lock_timeout(struct wake_lock *lock, long timeout); void wake_lock_destroy(struct wake_lock *lock);
Embedded Labworks WAKELOCKS (cont.) ✗ API em espaço de usuário: $ echo mylock > /sys/power/wake_lock $ echo mylock > /sys/power/wake_unlock
Embedded Labworks ALARM TIMER ✗ O Linux não possui nativamente um mecanismo de timer capaz de acordar o sistema quando o mesmo encontra-se em modo suspenso. ✗ Timers ou HRT (High Resolution Timers) são capazes de acordar um processo, mas não um sistema em modo suspenso. ✗ Um RTC é capaz de acordar um sistema em modo suspenso, mas não um processo.
Embedded Labworks ALARM TIMER (cont.) ✗ O alarm timer é um driver do kernel que integra as funcionalidades de RTC e Timer do Linux, sendo capaz de acordar um processo, mesmo com o sistema em modo suspenso. ✗ O acesso é exportado para o usuário através do arquivo /dev/alarm, possibilitando sua configuração através de chamadas ioctl().
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 $ logcat D/KeyguardViewMediator( 2276): setHidden false D/KeyguardViewMediator( 2276): setHidden false I/FlashBarService( 2809): mPkgManagerReceiver : onReceive D/Launcher.HomeFragment( 2999): onResume D/MenuAppsGridFragment( 2999): onResume D/KeyguardViewMediator( 2276): setHidden false I/power   ( 2276): *** release_dvfs_lock : lockType : 1  E/DataRouter( 1904): After the usb select W/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 DESENVOLVIMENTO DE DRIVERS ✗ No desenvolvimento de algum driver para uma plataforma que irá rodar o Android, teste e depure em um sistema GNU/Linux comum. ✗ Depois que o driver estiver rodando e funcionando, comece a trabalhar na camada Android.
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: ✗ Camada nativa: bibliotecas e aplicações que rodam fora da máquina virtual Java. ✗ Framework Android: serviços do sistema, classes java e API para o desenvolvimento de aplicações. ✗ Aplicações Android. ✗ Estes componentes estão distribuídos em três imagens diferentes (ramdisk, system e userdata), montados respectivamente nos diretórios /, /system e /data.
Embedded Labworks IMAGENS ANDROID $ ls out/target/product/wandboard/ android­info.txt    obj                      root           u­boot­6quad.bin boot.img            previous_build_config.mk symbols        u­boot­6solo.bin clean_steps.mk      ramdisk.img              system         u­boot.bin data                ramdisk­recovery.img     system.img     uImage installed­files.txt recovery                 test           userdata.img kernel              recovery.img             u­boot­6dl.bin
Embedded Labworks A INICIALIZAÇÃO ✗ No boot, o kernel monta a imagem do RAM disk (rootfs) e executa o processo init. ✗ O init processa os arquivos de configuração, inicializando o sistema e montando os outros sistemas de arquivo: ✗ system: binários e bibliotecas nativas, bibliotecas Java, arquivos de configuração e aplicações padrão (normalmente montado como somente leitura). ✗ data: aplicações instaladas pelo usuário, dados do usuário, etc. ✗ cache: arquivos temporários, downloads em andamento, etc. ✗ sdcard: arquivos e documentos do usuário (vídeos, sons, imagens, etc), normalmente montado com vfat. Não é essencial para o funcionamento do sistema.
Embedded Labworks PONTOS DE MONTAGEM /cache /d /data /system /etc /mnt /root /sbin /storage /vendor /proc /sys /dev /acct Rootfs (RAM disk) Kernel Virtual FS Data Image SDCARD procfs sysfs tmpfs cgroup /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. /storage    Ponto de montagem para o cartão SD (antigamente montado em /sdcard). /cache    Ponto de montagem para a partição cache, usada para armazenar arquivos temporários, downloads em andamento, etc.
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.
Embedded Labworks DIRETÓRIO SYSTEM (cont.) /app Aplicações pré-instaladas. /etc Arquivos de configuração. /media Arquivos de mídia (animação do boot, etc). /fonts Fontes instaladas no sistema.
Embedded Labworks DIRETÓRIO DATA /app Diretório de instalação das aplicações. /app­private Diretório de instalação das aplicações com proteção de cópia habilitada. /app­asec Aplicações encriptadas. /data Contém um diretório para cada aplicação instalada (home das aplicações).
Embedded Labworks DIRETÓRIO DATA (cont.) /dalvik­cache Cache da máquina virtual Java. /local Diretório com permissão de escrita para qualquer usuário. /property Armazena as propriedades persistentes do sistema. /system Banco de dados do sistema (contas, lista de aplicações instaladas, etc).
Embedded Labworks IMAGENS NO CARTÃO Sdcard Cache Data (data.img) System (system.img) Initrd (ramdisk.img) / /system /data /cache /storage Read-only Read-write Bootloader Kernel Linux raw
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 ANDROID E LINUX LADO-A-LADO ✗ É relativamente fácil colocar um sistema GNU/Linux lado-a-lado com um sistema Android, porque: ✗ A maioria dos diretórios do rootfs são pontos de montagem de um sistema de arquivo virtual ou links para outros diretórios do sistema. ✗ Quase todo o sistema Android esta localizado nos diretórios /system e /data.
Embedded Labworks ADB ✗ O ADB (Android Debug Bridge) é uma ferramenta de debugging desenvolvida pelo Google que possibilita o acesso via USB ou TCP/IP à qualquer dispositivo Android. ✗ Com o ADB, dentre outras opções, é possível: ✗ Iniciar uma seção do shell. ✗ Ler e copiar arquivos do dispositivo. ✗ Exibir o log do sistema. ✗ Debbuging com GDB ou JDB. ✗ Estudaremos o ADB com mais detalhes na seção de Debugging.
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) Init Toolbox Daemons nativos Camada HAL Dalvik / Android Runtime / Zygote System Services Android API Aplicações Bibliotecas Java 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, a 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 esta 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 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 esta 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 BUSYBOX addgroup,  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 COMANDOS TOOLBOX ls,  mount,  cat,  ps,  kill,  ln,  insmod,  rmmod,  lsmod,  ifconfig,  setconsole, rm, mkdir, rmdir, reboot, 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
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 # ps USER     PID   PPID  VSIZE  RSS     WCHAN    PC         NAME root      1     0     372    228   800f0f58 0000e890 S /init root      949   1     356    4     800f0f58 0000e890 S /sbin/ueventd root      1299  1     300    4     8008e0c0 00019510 S /sbin/watchdogd root      1311  1     824    484   80045b44 2ab8a9b0 S /system/bin/sh system    1312  1     892    184   803e275c 2aca3008 S /system/bin/servicemanager root      1313  1     4068   744   ffffffff 2ac607d0 S /system/bin/vold root      1314  1     9688   924   ffffffff 2abd27d0 S /system/bin/netd root      1315  1     936    232   80414198 2ac3ead4 S /system/bin/debuggerd system    1316  1     216852 8276  ffffffff 2ac6e008 S /system/bin/surfaceflinger root      1317  1     638504 34448 ffffffff 2ac3712c S zygote drm       1318  1     9000   2996  ffffffff 2acbb008 S /system/bin/drmserver media     1319  1     207624 6520  ffffffff 2ac3c008 S /system/bin/mediaserver bluetooth 1320  1     1400   488   800f0f58 2ab8bf98 S /system/bin/dbus­daemon install   1321  1     904    444   804b91c0 2abfbd98 S /system/bin/installd keystore  1322  1     1832   684   80414198 2ab36ad4 S /system/bin/keystore root      1323  1     2436   692   ffffffff 2abc57d0 S /system/bin/rild media_rw  1326  1     4860   164   ffffffff 2abddd98 S /system/bin/sdcard root      1328  1     6120   932   ffffffff 2ac68760 S /system/bin/ingsvcd root      1329  1     3448   4     ffffffff 00015f2c S /sbin/adbd
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 os arquivos de dispositivo no /dev.
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 debugging. ✗ É invocado pelo linker da Bionic para fazer análise postmortem de um processo que finalizou de forma inesperada. ✗ Gera um arquivo de debugging em /data/tombstones e possibilita o debug via gdb.
Embedded Labworks OUTROS DAEMONS ✗ adbd: daemon para gerenciar a conexão ADB. ✗ system_server: daemon que contém a maioria dos serviços do Android. ✗ servicemanager: responsável pelo gerenciamento da comunicação com o Binder, funcionando como um índice para todos os serviços que usam o Binder no sistema. ✗ mediaserver: responsável pelos serviços de media (audio, video, etc). ✗ keystore: gerencia o armazenamento e acesso à chaves criptográficas, como por exemplo certificados SSL.
Embedded Labworks OUTRAS BIBLIOTECAS E APLICAÇÕES ✗ stagefright: biblioteca responsável pela codificação e decodificação de arquivos multimedia (equivalente ao gstreamer). ✗ bluedroid: stack Bluetooth, que serve de interface entre os serviços do Android e a camada HAL de acesso ao hardware. ✗ dalvik: máquina virtual Java, portável e leve, responsável por executar aplicações Android. ✗ app_process: ferramenta capaz de instanciar a Dalvik e executar uma aplicação Java.
Embedded Labworks COMANDOS NATIVOS ✗ 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 NATIVOS (cont.) ✗ start/stop: iniciar/parar serviços. ✗ log: logar uma mensagem no sistema de log do Android. ✗ logcat: exibir o log do sistema. ✗ wipe: apagar a partição system ou data. ✗ logwrapper: permite executar um comando e redirecionar as saídas padrão e de erro para o log do Android. ✗ netcfg: exibir informações e configurar as interfaces de rede.
Embedded Labworks A CAMADA 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 Bootloader Carrega o kernel para a RAM e inicia init Inicia outros serviços e aplicações Kernel Monta o rootfs indicado por ”root=” Inicia a aplicação ”init” Shell Outras aplicações Rootfs
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, é capaz de: ✗ Configurar o sistema (montar sistemas de arquivo, exportar variáveis de ambiente, criar e definir permissões de arquivos, etc). ✗ Iniciar os daemons e gerenciar sua execução. ✗ Gerenciar eventos de hotplug de dispositivos de hardware (através do ueventd). ✗ 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 ARQUIVOS DE CONFIGURAÇÃO (cont.) ✗ Os arquivos de configuração possuem basicamente dois tipos de declaração: ✗ Ações que podem ser tomadas de acordo com algum evento do sistema: on <trigger>     <command>     <command> ✗ Serviços que são gerenciados pelo init: service <name> <pathname> [ <argument> ]*     <option>     <option>
Embedded Labworks SERVIÇOS E AÇÕES ✗ Apenas a declaração de ações resultam na execução de comandos pelo processo init. ✗ A declaração de serviços servem apenas para descrever os serviços, que normalmente são iniciados com os comandos start ou class_start, através de alguma ação disparada por um evento. ✗ São basicamente duas as fontes de eventos que podem disparar uma ação: ✗ Triggers pré-definidos de boot (early­init, init, early­fs, fs, post­fs, early­boot, boot). ✗ Mudança em alguma propriedade do sistema.
Embedded Labworks TRIGGERS DE BOOT ✗ Os triggers de boot são eventos gerados automaticamente pelo init no boot do sistema. ✗ Esta é a lista completa de triggers de boot, por ordem de execução: ✗ early-init ✗ init ✗ early-fs ✗ fs ✗ post-fs ✗ early-boot ✗ boot
Embedded Labworks TRIGGERS DE BOOT (cont.) ✗ Cada ação disparada por um evento (trigger) irá causar a execução de um ou mais comandos: on early­init     write /proc/1/oom_adj ­16     setcon u:r:init:s0     start ueventd ✗ São vários os comandos disponíveis, dentre eles chdir, chmod, chown, class_start, class_stop, copy, export, ifup, insmod, loglevel, mkdir, mount, start, stop, restart. ✗ Uma descrição (desatualizada) dos comandos esta disponível nos fontes em system/core/init/readme.txt.
Embedded Labworks SERVIÇOS ✗ Os serviços são daemons iniciados e gerenciados pelo processo init, declarados conforme abaixo: service <name> <pathname> [ <argument> ]*     <option>     <option> ✗ Esta declaração apenas descreve o serviço, mas não o inicia. ✗ Um serviço é iniciado no disparo de uma ação, através de alguns comandos como o start ou o class_start.
Embedded Labworks SERVIÇOS (EXEMPLOS) 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 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 UEVENTD ✗ O daemon ueventd (parte do init) é executado no boot do sistema, sendo o responsável pelo gerenciamento dos eventos de hotplug gerados pelo kernel. service ueventd /sbin/ueventd     class core     critical     seclabel u:r:ueventd:s0 on early­init     start ueventd
Embedded Labworks UEVENTD (cont.) ✗ O ueventd captura os eventos de hotplug e cria ou remove os arquivos de dispositivo no /dev. ✗ 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 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 EXEMPLO UEVENTD <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 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.dexopt­flags]: [m=y] [net.hostname]: [android­67af414597e8c083] [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 criado. ✗ Alterando o init.rc ou outro arquivo de configuração do init. ✗ Em tempo de execução, as propriedades do sistema podem ser alteradas através da ferramenta setprop. ✗ As propriedades podem também ser monitoradas com o comando watchprops.
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. ✗ A implementação de máquina virtual Java utilizada no Android é a Dalvik.
Embedded Labworks DALVIK ✗ A Dalvik é uma máquina virtual Java, portável e leve, responsável por executar as aplicações Android. ✗ Projetada para executar várias instancias ao mesmo tempo, consumindo pouca memória. ✗ Duas formas de execução: ✗ fast: otimizada para a arquitetura, mas não portável. ✗ portable: toda escrita em C, um pouco lenta, mas funciona em todas as plataformas. ✗ Usa o framework de 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 –start­system­server     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 Zygote System Server app_process Activity Manager Launcher C/C++ Java start(Launcher) daemons Power Manager Outros Serviços
Embedded Labworks PROCESSOS NA INICIALIZAÇÃO # ps USER     PID   PPID  VSIZE  RSS     WCHAN    PC         NAME root      1     0     372    228   800f0f58 0000e890 S /init root      949   1     356    4     800f0f58 0000e890 S /sbin/ueventd root      1315  1     824    492   80045b44 2ac9d9b0 S /system/bin/sh system    1316  1     892    184   803e275c 2acab008 S /system/bin/servicemanager root      1321  1     638504 34440 ffffffff 2abad12c S zygote drm       1322  1     9004   3000  ffffffff 2acb6008 S /system/bin/drmserver media     1323  1     208648 6512  ffffffff 2ab48008 S /system/bin/mediaserver system    1621  1321  914932 43172 ffffffff 2abad008 S system_server u0_a9     1698  1321  855328 58212 ffffffff 2abadf20 S com.android.systemui u0_a2     1781  1321  649212 19328 ffffffff 2abadf20 S com.android.inputmethod.latin radio     1792  1321  661760 21868 ffffffff 2abadf20 S com.android.phone u0_a31    1815  1321  851020 38768 ffffffff 2abadf20 S com.android.launcher u0_a39    1830  1321  646836 15572 ffffffff 2abadf20 S com.android.location.fused u0_a17    1960  1321  649628 18152 ffffffff 2abadf20 S com.android.providers.calendar u0_a23    1996  1321  657840 19948 ffffffff 2abadf20 S com.android.email u0_a24    2013  1321  655480 16904 ffffffff 2abadf20 S com.android.exchange u0_a38    2089  1321  654508 17564 ffffffff 2abadf20 S com.android.calendar
Embedded Labworks LABORATÓRIO Alterando o processo de inicialização do Android
Embedded Labworks Android embarcado Produtos
Embedded Labworks PLACAS, DISPOSITIVOS E PRODUTOS Arquitetura Placa (hardware) Dispositivo (periféricos) Produto (customizações)
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. Por exemplo, na versão 4.2.2 do Android, são definidos vários produtos para a linha Nexus, além de um produto para a Pandaboard. ✗ Adicionar um produto é normalmente uma das primeiras tarefas ao portar o Android para uma plataforma embarcada. ✗ Os produtos disponíveis podem ser exibidos e selecionados com o comando lunch.
Embedded Labworks CRIANDO UM PRODUTO ✗ Para criar um produto é necessário criar um diretório em device/<company>/<device>, onde estarão todos os arquivos de definição do produto. $ mkdir ­p device/labworks/superdroid/ ✗ E depois implementar um arquivo chamado AndroidProducts.mk, que deve incluir o Makefile do seu produto através da variável PRODUCT_MAKEFILES: PRODUCT_MAKEFILES :=      $(LOCAL_DIR)/full_superdroid.mk
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 inherit­product, $(SRC_TARGET_DIR)/product/full.mk) PRODUCT_NAME   := full_superdroid PRODUCT_DEVICE := superdroid PRODUCT_MODEL  := Super Android robot PRODUCT_BRAND  := Android
Embedded Labworks ADICIONANDO APLICAÇÕES ✗ Neste makefile é necessário definir todas as aplicações que estarão presentes no produto. ✗ Normalmente isso é feito incluindo outro makefile que contém um conjunto de aplicações já pré-definidas, conforme exemplo anterior: $(call inherit­product, $(SRC_TARGET_DIR)/product/full.mk) ✗ Estes arquivos de makefile pré-configurados estão disponíveis em no código-fonte do sistema de build em build/target/product.
Embedded Labworks ADICIONANDO APLICAÇÕES (cont.) ✗ As aplicações também podem ser incluídas no produto através da variável PRODUCT_PACKAGES: PRODUCT_PACKAGES +=         LiveWallpapers          Gallery2                   SoundRecorder           Camera                  Email                   FSLOta                  CactusPlayer            VideoEditor             FSLProfileApp           FSLProfileService       PinyinIME          
Embedded Labworks ADICIONANDO APLICAÇÕES (cont.) ✗ Ao criar um pacote específico para o seu produto, seja uma aplicação Android, biblioteca ou aplicação nativa, coloque-a dentro do diretório do produto criado. ✗ Por exemplo, uma necessidade comum é a implementação de uma aplicação Launcher específica para o seu produto. O código-fonte desta aplicação deve ir dentro do diretório do produto criado. ✗ Isso facilita a manutenção, como por exemplo ao fazer upgrade de versão do Android, já que todas as alterações do seu produto ficam centralizadas em um único diretório. ✗ Veremos como fazer isso mais adiante no treinamento.
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 OVERLAYS ✗ 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 OVERLAYS (cont.) ✗ Para realizar o overlay o primeiro passo é criar o diretório overlay com a mesma estrutura de diretórios do código-fonte do Android: $ tree device/samsung/manta/overlay/  ──├ frameworks      │ ──└ base          │ ──├ core              │ │ ──└ res                  │ │ ──└ res                      │ │ ──├ values                          │ │ │ ──└ config.xml                      │ │ ──└ xml                          │ │ ──├ power_profile.xml                          │ │ ──└ storage_list.xml
Embedded Labworks OVERLAYS (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 ✗ Uma lista completa das opções que podem ser usadas no Makefile do produto estão disponíveis no código-fonte do sistema de build em build/core/product.mk.
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_NO_KERNEL := true TARGET_NO_BOOTLOADER := true TARGET_ARCH := arm TARGET_ARCH_VARIANT := armv7­a­neon TARGET_CPU_ABI := armeabi BOARD_USES_GENERIC_AUDIO := true USE_CAMERA_STUB := 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_superdroid­eng
Embedded Labworks RESUMO ✗ Crie o diretório do produto em device/<company>/<device>, e implemente os seguintes arquivos: ✗ AndroidProducts.mk: inclua o Makefile do seu produto. ✗ <product_name>.mk: defina informações gerais sobre o produto (nome, dispositivo, módulos, overlays, etc). ✗ BoardConfig.mk: defina a configuração da plataforma de hardware (arquitetura, bootloader, kernel, etc). ✗ vendorsetup.sh: adicione o produto ao menu do comando lunch.
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 my­dir) include $(CLEAR_VARS) LOCAL_SRC_FILES = helloworld.c LOCAL_MODULE = HelloWorld LOCAL_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 (user, debug, eng, development, 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 my­dir) include $(CLEAR_VARS) LOCAL_VARIABLE_1 := value_1 LOCAL_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 arquivos pré-compilados no target. ✗ BUILD_MULTI_PREBUILT instala múltiplos arquivos 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/build­system.html.
Embedded Labworks MACROS ✗ Vimos no exemplo o uso da macro my­dir para retornar o diretório corrente da aplicação: LOCAL_PATH := $(call my­dir) ✗ Várias outras macros estão disponíveis para uso, como por exemplo: ✗ all­java­files­under: retorna todos os arquivos java recursivamente, a partir do diretório passado como parâmetro. ✗ all­subdir­c­files: 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_name> ✗ Para limpar a compilação de um módulo: $ make clean­<module_name> ✗ Para listar todos os módulos que serão compilados: $ make modules
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 de 3 fatores: ✗ Definição da tag do módulo. ✗ Escolha da variante do produto. ✗ Conteúdo da variável PRODUCT_PACKAGES do produto.
Embedded Labworks TAGS ✗ As tags classificam os módulos e estão diretamente ligadas à variante escolhida no comando lunch: ✗ user: build de produção, inclui módulos com a tag user. ✗ userdebug: mesmo que a variante user, mas inclui também módulos com a tag debug, e habilita o ADB por padrão. ✗ eng: mesmo que a variante userdebug, mas inclui também módulos com as tags eng e development. ✗ As tags são definidas através da variável LOCAL_MODULE_TAGS no Android.mk do módulo.
Embedded Labworks TAGS (cont.) ✗ Módulos sem tag ou com a tag optional precisam ser incluídos na variável PRODUCT_PACKAGES do produto para serem instalados. ✗ As tags de aplicações Android (*.apk) são ignoradas. As aplicações Android precisam ser incluídas na variável PRODUCT_PACKAGES do produto para serem instaladas.
Embedded Labworks DICAS ✗ Implemente novos módulos no diretório do produto em device/<company>/<device>. ✗ Use como padrão em novos módulos a tag optional, não esquecendo de incluir o nome do módulo na variável  PRODUCT_PACKAGES do produto. ✗ Na dúvida sobre a implementação de um Android.mk, consulte os diversos exemplos disponíveis no código-fonte do Android, 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) Init Toolbox Daemons nativos Camada HAL Dalvik / Android Runtime / Zygote System Services Android API Aplicações Bibliotecas Java API Binder JNI 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 é baseada em Java. ✗ O framework Android se comunica com a camada nativa via JNI (Java Native Interface).
Embedded Labworks COMPONENTES ✗ Componentes do framework Android: ✗ Android Runtime, Dalvik 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 o Android Runtime, Dalvik e Zygote quando estudamos o processo de inicialização do Android. ✗ Falaremos sobre as classes Java e a API do Android quando estudarmos a camada de aplicações do sistema. ✗ Nosso foco nesta seção são os System Services, núcleo do framework Android.
Embedded Labworks SYSTEM SERVICES ✗ System Services são os serviços do Android responsáveis por prover funcionalidades para as aplicações. Exemplos: ✗ Power Manager para gerenciamento de energia. ✗ Activity Manager para gerenciamento da execução dos componentes Android. ✗ Package Manager para gerenciamento de pacotes Android (APK). ✗ Location Manager para gerenciamento de localização (ex: GPS). ✗ O Android 4.2 possui em torno de 70 serviços!
Embedded Labworks LISTANDO OS SERVIÇOS # service list Found 68 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 dreams: [android.service.dreams.IDreamManager] 5 commontime_management: [] 6 samplingprofiler: [] 7 diskstats: [] [...]
Embedded Labworks SERVIÇOS E SEUS PROCESSOS ✗ Alguns serviços são processos que rodam nativamente e são executados pelo processo init no boot (Surface Flinger, DRM Server, Media Server). ✗ Mas a maioria dos serviços fazem parte do processo System Server, executado pelo Zygote no boot do sistema.
Embedded Labworks SERVIÇOS E SEUS 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. ✗ drmserver: processo do DRM Server, responsável pelo gerenciamento de conteúdos protegidos por direitos autorais.
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
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.
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado
Treinamento Android Embarcado

Recommandé

Microcontroladores x microprocessadores
Microcontroladores x microprocessadoresMicrocontroladores x microprocessadores
Microcontroladores x microprocessadoresmiroslayer
 
Visão de Testes de Software segundo o SWEBOK
Visão de Testes de Software segundo o SWEBOKVisão de Testes de Software segundo o SWEBOK
Visão de Testes de Software segundo o SWEBOKMário Pravato Junior
 
Comandos CMD
Comandos CMDComandos CMD
Comandos CMDJoao Andre Picao
 
Paradigmas De Linguagem De Programação.
Paradigmas De Linguagem De Programação.Paradigmas De Linguagem De Programação.
Paradigmas De Linguagem De Programação.Valmon Gaudencio
 
SO-05 Gerenciamento de Memória e Alocação
SO-05 Gerenciamento de Memória e AlocaçãoSO-05 Gerenciamento de Memória e Alocação
SO-05 Gerenciamento de Memória e AlocaçãoEduardo Nicola F. Zagari
 
Projeto de Software
Projeto de SoftwareProjeto de Software
Projeto de SoftwareWagner Zaparoli
 
Aula 2 - Técnicas de Prototipação I
Aula 2 - Técnicas de Prototipação IAula 2 - Técnicas de Prototipação I
Aula 2 - Técnicas de Prototipação IPaolo Passeri
 
Construir microservices em python nunca foi tão simples como com o Nameko!
Construir microservices em python nunca foi tão simples como com o Nameko!Construir microservices em python nunca foi tão simples como com o Nameko!
Construir microservices em python nunca foi tão simples como com o Nameko!Flávio Pimenta
 

Recommandé

Microcontroladores x microprocessadores
Microcontroladores x microprocessadoresMicrocontroladores x microprocessadores
Microcontroladores x microprocessadoresmiroslayer
 
Visão de Testes de Software segundo o SWEBOK
Visão de Testes de Software segundo o SWEBOKVisão de Testes de Software segundo o SWEBOK
Visão de Testes de Software segundo o SWEBOKMário Pravato Junior
 
Comandos CMD
Comandos CMDComandos CMD
Comandos CMDJoao Andre Picao
 
Paradigmas De Linguagem De Programação.
Paradigmas De Linguagem De Programação.Paradigmas De Linguagem De Programação.
Paradigmas De Linguagem De Programação.Valmon Gaudencio
 
SO-05 Gerenciamento de Memória e Alocação
SO-05 Gerenciamento de Memória e AlocaçãoSO-05 Gerenciamento de Memória e Alocação
SO-05 Gerenciamento de Memória e AlocaçãoEduardo Nicola F. Zagari
 
Projeto de Software
Projeto de SoftwareProjeto de Software
Projeto de SoftwareWagner Zaparoli
 
Aula 2 - Técnicas de Prototipação I
Aula 2 - Técnicas de Prototipação IAula 2 - Técnicas de Prototipação I
Aula 2 - Técnicas de Prototipação IPaolo Passeri
 
Construir microservices em python nunca foi tão simples como com o Nameko!
Construir microservices em python nunca foi tão simples como com o Nameko!Construir microservices em python nunca foi tão simples como com o Nameko!
Construir microservices em python nunca foi tão simples como com o Nameko!Flávio Pimenta
 
Selenium ide apresentação
Selenium ide apresentaçãoSelenium ide apresentação
Selenium ide apresentaçãoPriscila Calderão
 
Conceitos e fundamentos sobre testes de software e garantia da qualidade
Conceitos e fundamentos sobre testes de software e garantia da qualidadeConceitos e fundamentos sobre testes de software e garantia da qualidade
Conceitos e fundamentos sobre testes de software e garantia da qualidaderzauza
 
Git e GitHub: Versionamento de Código Fácil
Git e GitHub: Versionamento de Código FácilGit e GitHub: Versionamento de Código Fácil
Git e GitHub: Versionamento de Código FácilTiago Antônio da Silva
 
Linguagem C 03 Estruturas De Decisao
Linguagem C 03 Estruturas De DecisaoLinguagem C 03 Estruturas De Decisao
Linguagem C 03 Estruturas De DecisaoRegis Magalhães
 
Introdução ao owasp zap aula-01
Introdução ao owasp zap aula-01 Introdução ao owasp zap aula-01
Introdução ao owasp zap aula-01 prof-claudio
 
FreeBSD para leigos
FreeBSD para leigosFreeBSD para leigos
FreeBSD para leigosPedro Neto
 
Técnica de Levantamento de Requisitos: etnografia
Técnica de Levantamento de Requisitos: etnografiaTécnica de Levantamento de Requisitos: etnografia
Técnica de Levantamento de Requisitos: etnografiaMessias Batista
 
Conhecendo o Django
Conhecendo o DjangoConhecendo o Django
Conhecendo o DjangoMarcos Thomaz
 
POO - Aula 10 - Polimorfismo
POO - Aula 10 - PolimorfismoPOO - Aula 10 - Polimorfismo
POO - Aula 10 - PolimorfismoFelipe J. R. Vieira
 
Desenvolvimento de aplicações para dispositivos móveis módulo i - aula 2
Desenvolvimento de aplicações para dispositivos móveis módulo i - aula 2Desenvolvimento de aplicações para dispositivos móveis módulo i - aula 2
Desenvolvimento de aplicações para dispositivos móveis módulo i - aula 2Carlos Eugenio Torres
 
Node.JS - Workshop do básico ao avançado
Node.JS - Workshop do básico ao avançadoNode.JS - Workshop do básico ao avançado
Node.JS - Workshop do básico ao avançadoEduardo Bohrer
 
ISO/IEC 15504 SPICE + 33000
ISO/IEC 15504 SPICE + 33000ISO/IEC 15504 SPICE + 33000
ISO/IEC 15504 SPICE + 33000Luis Guilherme Rodrigues
 
Desenvolvimento de aplicações para dispositivos móveis módulo i - aula 1
Desenvolvimento de aplicações para dispositivos móveis módulo i - aula 1Desenvolvimento de aplicações para dispositivos móveis módulo i - aula 1
Desenvolvimento de aplicações para dispositivos móveis módulo i - aula 1Carlos Eugenio Torres
 
Exemplo de Plano de testes
Exemplo de Plano de testes Exemplo de Plano de testes
Exemplo de Plano de testes Leandro Rodrigues
 
Clean Code
Clean CodeClean Code
Clean CodeBruno Lui
 
FreeBSD
FreeBSDFreeBSD
FreeBSDAnderson Favaro
 
Testes em métodos ágeis
Testes em métodos ágeisTestes em métodos ágeis
Testes em métodos ágeisQualister
 
1 requisitos funcionais e não funcionais ok
1 requisitos funcionais e não funcionais ok1 requisitos funcionais e não funcionais ok
1 requisitos funcionais e não funcionais okMarcos Morais de Sousa
 
Criando o Primeiro Projeto no Android Studio
Criando o Primeiro Projeto no Android StudioCriando o Primeiro Projeto no Android Studio
Criando o Primeiro Projeto no Android StudioTiago Antônio da Silva
 
Licenças de software livre
Licenças de software livreLicenças de software livre
Licenças de software livrePetronio Candido
 
Googleappsparaempresas apresentaoepropostacomercial-q-i-2011-120218153034-php...
Googleappsparaempresas apresentaoepropostacomercial-q-i-2011-120218153034-php...Googleappsparaempresas apresentaoepropostacomercial-q-i-2011-120218153034-php...
Googleappsparaempresas apresentaoepropostacomercial-q-i-2011-120218153034-php...Odair Sousa
 
Apostila Linux.Sxw
Apostila Linux.SxwApostila Linux.Sxw
Apostila Linux.SxwOdair Sousa
 

Contenu connexe

Tendances

Conceitos e fundamentos sobre testes de software e garantia da qualidade
Conceitos e fundamentos sobre testes de software e garantia da qualidadeConceitos e fundamentos sobre testes de software e garantia da qualidade
Conceitos e fundamentos sobre testes de software e garantia da qualidaderzauza
 
Git e GitHub: Versionamento de Código Fácil
Git e GitHub: Versionamento de Código FácilGit e GitHub: Versionamento de Código Fácil
Git e GitHub: Versionamento de Código FácilTiago Antônio da Silva
 
Linguagem C 03 Estruturas De Decisao
Linguagem C 03 Estruturas De DecisaoLinguagem C 03 Estruturas De Decisao
Linguagem C 03 Estruturas De DecisaoRegis Magalhães
 
Introdução ao owasp zap aula-01
Introdução ao owasp zap aula-01 Introdução ao owasp zap aula-01
Introdução ao owasp zap aula-01 prof-claudio
 
FreeBSD para leigos
FreeBSD para leigosFreeBSD para leigos
FreeBSD para leigosPedro Neto
 
Técnica de Levantamento de Requisitos: etnografia
Técnica de Levantamento de Requisitos: etnografiaTécnica de Levantamento de Requisitos: etnografia
Técnica de Levantamento de Requisitos: etnografiaMessias Batista
 
Desenvolvimento de aplicações para dispositivos móveis módulo i - aula 2
Desenvolvimento de aplicações para dispositivos móveis módulo i - aula 2Desenvolvimento de aplicações para dispositivos móveis módulo i - aula 2
Desenvolvimento de aplicações para dispositivos móveis módulo i - aula 2Carlos Eugenio Torres
 
Node.JS - Workshop do básico ao avançado
Node.JS - Workshop do básico ao avançadoNode.JS - Workshop do básico ao avançado
Node.JS - Workshop do básico ao avançadoEduardo Bohrer
 
Desenvolvimento de aplicações para dispositivos móveis módulo i - aula 1
Desenvolvimento de aplicações para dispositivos móveis módulo i - aula 1Desenvolvimento de aplicações para dispositivos móveis módulo i - aula 1
Desenvolvimento de aplicações para dispositivos móveis módulo i - aula 1Carlos Eugenio Torres
 
Testes em métodos ágeis
Testes em métodos ágeisTestes em métodos ágeis
Testes em métodos ágeisQualister
 
1 requisitos funcionais e não funcionais ok
1 requisitos funcionais e não funcionais ok1 requisitos funcionais e não funcionais ok
1 requisitos funcionais e não funcionais okMarcos Morais de Sousa
 
Criando o Primeiro Projeto no Android Studio
Criando o Primeiro Projeto no Android StudioCriando o Primeiro Projeto no Android Studio
Criando o Primeiro Projeto no Android StudioTiago Antônio da Silva
 
Licenças de software livre
Licenças de software livreLicenças de software livre
Licenças de software livrePetronio Candido
 

Tendances (20)

Selenium ide apresentação
Selenium ide apresentaçãoSelenium ide apresentação
Selenium ide apresentação
 
Conceitos e fundamentos sobre testes de software e garantia da qualidade
Conceitos e fundamentos sobre testes de software e garantia da qualidadeConceitos e fundamentos sobre testes de software e garantia da qualidade
Conceitos e fundamentos sobre testes de software e garantia da qualidade
 
Git e GitHub: Versionamento de Código Fácil
Git e GitHub: Versionamento de Código FácilGit e GitHub: Versionamento de Código Fácil
Git e GitHub: Versionamento de Código Fácil
 
Linguagem C 03 Estruturas De Decisao
Linguagem C 03 Estruturas De DecisaoLinguagem C 03 Estruturas De Decisao
Linguagem C 03 Estruturas De Decisao
 
Introdução ao owasp zap aula-01
Introdução ao owasp zap aula-01 Introdução ao owasp zap aula-01
Introdução ao owasp zap aula-01
 
FreeBSD para leigos
FreeBSD para leigosFreeBSD para leigos
FreeBSD para leigos
 
Técnica de Levantamento de Requisitos: etnografia
Técnica de Levantamento de Requisitos: etnografiaTécnica de Levantamento de Requisitos: etnografia
Técnica de Levantamento de Requisitos: etnografia
 
Conhecendo o Django
Conhecendo o DjangoConhecendo o Django
Conhecendo o Django
 
POO - Aula 10 - Polimorfismo
POO - Aula 10 - PolimorfismoPOO - Aula 10 - Polimorfismo
POO - Aula 10 - Polimorfismo
 
Desenvolvimento de aplicações para dispositivos móveis módulo i - aula 2
Desenvolvimento de aplicações para dispositivos móveis módulo i - aula 2Desenvolvimento de aplicações para dispositivos móveis módulo i - aula 2
Desenvolvimento de aplicações para dispositivos móveis módulo i - aula 2
 
Node.JS - Workshop do básico ao avançado
Node.JS - Workshop do básico ao avançadoNode.JS - Workshop do básico ao avançado
Node.JS - Workshop do básico ao avançado
 
ISO/IEC 15504 SPICE + 33000
ISO/IEC 15504 SPICE + 33000ISO/IEC 15504 SPICE + 33000
ISO/IEC 15504 SPICE + 33000
 
Desenvolvimento de aplicações para dispositivos móveis módulo i - aula 1
Desenvolvimento de aplicações para dispositivos móveis módulo i - aula 1Desenvolvimento de aplicações para dispositivos móveis módulo i - aula 1
Desenvolvimento de aplicações para dispositivos móveis módulo i - aula 1
 
Exemplo de Plano de testes
Exemplo de Plano de testes Exemplo de Plano de testes
Exemplo de Plano de testes
 
Clean Code
Clean CodeClean Code
Clean Code
 
FreeBSD
FreeBSDFreeBSD
FreeBSD
 
Testes em métodos ágeis
Testes em métodos ágeisTestes em métodos ágeis
Testes em métodos ágeis
 
1 requisitos funcionais e não funcionais ok
1 requisitos funcionais e não funcionais ok1 requisitos funcionais e não funcionais ok
1 requisitos funcionais e não funcionais ok
 
Criando o Primeiro Projeto no Android Studio
Criando o Primeiro Projeto no Android StudioCriando o Primeiro Projeto no Android Studio
Criando o Primeiro Projeto no Android Studio
 
Licenças de software livre
Licenças de software livreLicenças de software livre
Licenças de software livre
 

En vedette

Googleappsparaempresas apresentaoepropostacomercial-q-i-2011-120218153034-php...
Googleappsparaempresas apresentaoepropostacomercial-q-i-2011-120218153034-php...Googleappsparaempresas apresentaoepropostacomercial-q-i-2011-120218153034-php...
Googleappsparaempresas apresentaoepropostacomercial-q-i-2011-120218153034-php...Odair Sousa
 
Apostila Linux.Sxw
Apostila Linux.SxwApostila Linux.Sxw
Apostila Linux.SxwOdair Sousa
 
Manual3 negociocerto
Manual3 negociocertoManual3 negociocerto
Manual3 negociocertoOdair Sousa
 
What is Bitcoin? And what's going on?
What is Bitcoin? And what's going on?What is Bitcoin? And what's going on?
What is Bitcoin? And what's going on?Claire Ingram Bogusz
 
NPR Simile Timeline
NPR Simile TimelineNPR Simile Timeline
NPR Simile Timelinejohntynan
 
ICT: mennyttä, olevaa ja tulevaa
ICT: mennyttä, olevaa ja tulevaaICT: mennyttä, olevaa ja tulevaa
ICT: mennyttä, olevaa ja tulevaaAri Rapo
 
Overview of Bitcoin - Sweden
Overview of Bitcoin - SwedenOverview of Bitcoin - Sweden
Overview of Bitcoin - SwedenRobin Teigland
 
Introdução ao android - siecomp 2015.1
Introdução ao android - siecomp 2015.1Introdução ao android - siecomp 2015.1
Introdução ao android - siecomp 2015.1Afonso Machado
 
Экосистема Common Lisp
Экосистема Common LispЭкосистема Common Lisp
Экосистема Common LispVsevolod Dyomkin
 
Desenvolvimento para Android - Bento Gonçalves (08/2011)
Desenvolvimento para Android - Bento Gonçalves (08/2011)Desenvolvimento para Android - Bento Gonçalves (08/2011)
Desenvolvimento para Android - Bento Gonçalves (08/2011)Gustavo Ciello
 
Android CodeLab - Nearby Places: Google Maps + Google Places
Android CodeLab - Nearby Places: Google Maps + Google PlacesAndroid CodeLab - Nearby Places: Google Maps + Google Places
Android CodeLab - Nearby Places: Google Maps + Google PlacesJordan Silva
 
Introdução ao desenvolvimento de apps para Android - Dia 1/2
Introdução ao desenvolvimento de apps para Android - Dia 1/2Introdução ao desenvolvimento de apps para Android - Dia 1/2
Introdução ao desenvolvimento de apps para Android - Dia 1/2Matheus Calegaro
 
Introdução ao Desenvolvimento Android
Introdução ao Desenvolvimento AndroidIntrodução ao Desenvolvimento Android
Introdução ao Desenvolvimento AndroidJosé Alexandre Macedo
 
Iniciando no mundo mobile - Programando para android
Iniciando no mundo mobile - Programando para androidIniciando no mundo mobile - Programando para android
Iniciando no mundo mobile - Programando para androidDiemesleno Souza Carvalho
 

En vedette (20)

Googleappsparaempresas apresentaoepropostacomercial-q-i-2011-120218153034-php...
Googleappsparaempresas apresentaoepropostacomercial-q-i-2011-120218153034-php...Googleappsparaempresas apresentaoepropostacomercial-q-i-2011-120218153034-php...
Googleappsparaempresas apresentaoepropostacomercial-q-i-2011-120218153034-php...
 
Apostila Linux.Sxw
Apostila Linux.SxwApostila Linux.Sxw
Apostila Linux.Sxw
 
Manual3 negociocerto
Manual3 negociocertoManual3 negociocerto
Manual3 negociocerto
 
What is Bitcoin? And what's going on?
What is Bitcoin? And what's going on?What is Bitcoin? And what's going on?
What is Bitcoin? And what's going on?
 
NPR Simile Timeline
NPR Simile TimelineNPR Simile Timeline
NPR Simile Timeline
 
ICT: mennyttä, olevaa ja tulevaa
ICT: mennyttä, olevaa ja tulevaaICT: mennyttä, olevaa ja tulevaa
ICT: mennyttä, olevaa ja tulevaa
 
Workshop Magento
Workshop MagentoWorkshop Magento
Workshop Magento
 
Overview of Bitcoin - Sweden
Overview of Bitcoin - SwedenOverview of Bitcoin - Sweden
Overview of Bitcoin - Sweden
 
Introdução ao android - siecomp 2015.1
Introdução ao android - siecomp 2015.1Introdução ao android - siecomp 2015.1
Introdução ao android - siecomp 2015.1
 
Экосистема Common Lisp
Экосистема Common LispЭкосистема Common Lisp
Экосистема Common Lisp
 
Boas Práticas em Android
Boas Práticas em AndroidBoas Práticas em Android
Boas Práticas em Android
 
Desenvolvimento para Android - Bento Gonçalves (08/2011)
Desenvolvimento para Android - Bento Gonçalves (08/2011)Desenvolvimento para Android - Bento Gonçalves (08/2011)
Desenvolvimento para Android - Bento Gonçalves (08/2011)
 
Android CodeLab - Nearby Places: Google Maps + Google Places
Android CodeLab - Nearby Places: Google Maps + Google PlacesAndroid CodeLab - Nearby Places: Google Maps + Google Places
Android CodeLab - Nearby Places: Google Maps + Google Places
 
Aula android 01.pdf
Aula android 01.pdfAula android 01.pdf
Aula android 01.pdf
 
Introdução ao desenvolvimento de apps para Android - Dia 1/2
Introdução ao desenvolvimento de apps para Android - Dia 1/2Introdução ao desenvolvimento de apps para Android - Dia 1/2
Introdução ao desenvolvimento de apps para Android - Dia 1/2
 
Introdução ao Desenvolvimento Android
Introdução ao Desenvolvimento AndroidIntrodução ao Desenvolvimento Android
Introdução ao Desenvolvimento Android
 
AIX Guide
AIX GuideAIX Guide
AIX Guide
 
Android Aula 5
Android Aula 5Android Aula 5
Android Aula 5
 
Android Aula 4
Android Aula 4Android Aula 4
Android Aula 4
 
Iniciando no mundo mobile - Programando para android
Iniciando no mundo mobile - Programando para androidIniciando no mundo mobile - Programando para android
Iniciando no mundo mobile - Programando para android
 

Similaire à Treinamento Android Embarcado

Testes automatizados.pptx
Testes automatizados.pptxTestes automatizados.pptx
Testes automatizados.pptxCarlos Gonzaga
 
Introdução à plataforma Android
Introdução à plataforma AndroidIntrodução à plataforma Android
Introdução à plataforma AndroidNatanael Fonseca
 
ASP.NET e Visual Studio 2010
ASP.NET e Visual Studio 2010ASP.NET e Visual Studio 2010
ASP.NET e Visual Studio 2010Norton Guimarães
 
ASP.NET Core + Docker Compose: deployment descomplicado com containers - .NET...
ASP.NET Core + Docker Compose: deployment descomplicado com containers - .NET...ASP.NET Core + Docker Compose: deployment descomplicado com containers - .NET...
ASP.NET Core + Docker Compose: deployment descomplicado com containers - .NET...Renato Groffe
 
Android Core Aula 1 - Histórico, Arquitetura e Compilação da plataforma
Android Core Aula 1 - Histórico, Arquitetura e Compilação da plataformaAndroid Core Aula 1 - Histórico, Arquitetura e Compilação da plataforma
Android Core Aula 1 - Histórico, Arquitetura e Compilação da plataformaFelipe Silveira
 
CEPUG 2 - Bem-vindo a Framework CodeIgniter
CEPUG 2 - Bem-vindo a Framework CodeIgniterCEPUG 2 - Bem-vindo a Framework CodeIgniter
CEPUG 2 - Bem-vindo a Framework CodeIgniterEric Silva
 
Webinar: Debugging em Linux embarcado
Webinar: Debugging em Linux embarcadoWebinar: Debugging em Linux embarcado
Webinar: Debugging em Linux embarcadoEmbarcados
 
Docker para Desenvolvedores - Developers-BR - Julho-2018
Docker para Desenvolvedores - Developers-BR - Julho-2018Docker para Desenvolvedores - Developers-BR - Julho-2018
Docker para Desenvolvedores - Developers-BR - Julho-2018Renato Groff
 
Container revolucao
Container revolucaoContainer revolucao
Container revolucaoFernando Ike
 
Interoperabilidade com .NET em ambiente Mainframe
Interoperabilidade com .NET em ambiente MainframeInteroperabilidade com .NET em ambiente Mainframe
Interoperabilidade com .NET em ambiente MainframeAlessandro Binhara
 
Docker para Desenvolvedores - Developers-BR - Agosto-2018
Docker para Desenvolvedores - Developers-BR - Agosto-2018Docker para Desenvolvedores - Developers-BR - Agosto-2018
Docker para Desenvolvedores - Developers-BR - Agosto-2018Renato Groff
 
Construção e provisionamento de ambientes de desenvolvimento virtualizados
Construção e provisionamento de ambientes de desenvolvimento virtualizadosConstrução e provisionamento de ambientes de desenvolvimento virtualizados
Construção e provisionamento de ambientes de desenvolvimento virtualizadosThiago Rodrigues
 
Integração contínua com Jenkins
Integração contínua com JenkinsIntegração contínua com Jenkins
Integração contínua com JenkinsAécio Pires
 
Play Framework - Desenvolvendo Aplicações Web com Java sem Dor
Play Framework - Desenvolvendo Aplicações Web com Java sem DorPlay Framework - Desenvolvendo Aplicações Web com Java sem Dor
Play Framework - Desenvolvendo Aplicações Web com Java sem DorAllyson Barros
 
Programação Android - Básico
Programação Android - BásicoProgramação Android - Básico
Programação Android - BásicoHugoDalevedove
 

Similaire à Treinamento Android Embarcado (20)

Testes automatizados.pptx
Testes automatizados.pptxTestes automatizados.pptx
Testes automatizados.pptx
 
Introdução à plataforma Android
Introdução à plataforma AndroidIntrodução à plataforma Android
Introdução à plataforma Android
 
ASP.NET e Visual Studio 2010
ASP.NET e Visual Studio 2010ASP.NET e Visual Studio 2010
ASP.NET e Visual Studio 2010
 
ASP.NET Core + Docker Compose: deployment descomplicado com containers - .NET...
ASP.NET Core + Docker Compose: deployment descomplicado com containers - .NET...ASP.NET Core + Docker Compose: deployment descomplicado com containers - .NET...
ASP.NET Core + Docker Compose: deployment descomplicado com containers - .NET...
 
Android Core Aula 1 - Histórico, Arquitetura e Compilação da plataforma
Android Core Aula 1 - Histórico, Arquitetura e Compilação da plataformaAndroid Core Aula 1 - Histórico, Arquitetura e Compilação da plataforma
Android Core Aula 1 - Histórico, Arquitetura e Compilação da plataforma
 
CEPUG 2 - Bem-vindo a Framework CodeIgniter
CEPUG 2 - Bem-vindo a Framework CodeIgniterCEPUG 2 - Bem-vindo a Framework CodeIgniter
CEPUG 2 - Bem-vindo a Framework CodeIgniter
 
Webinar: Debugging em Linux embarcado
Webinar: Debugging em Linux embarcadoWebinar: Debugging em Linux embarcado
Webinar: Debugging em Linux embarcado
 
Docker para Desenvolvedores - Developers-BR - Julho-2018
Docker para Desenvolvedores - Developers-BR - Julho-2018Docker para Desenvolvedores - Developers-BR - Julho-2018
Docker para Desenvolvedores - Developers-BR - Julho-2018
 
Container revolucao
Container revolucaoContainer revolucao
Container revolucao
 
Interoperabilidade com .NET em ambiente Mainframe
Interoperabilidade com .NET em ambiente MainframeInteroperabilidade com .NET em ambiente Mainframe
Interoperabilidade com .NET em ambiente Mainframe
 
Docker para Desenvolvedores - Developers-BR - Agosto-2018
Docker para Desenvolvedores - Developers-BR - Agosto-2018Docker para Desenvolvedores - Developers-BR - Agosto-2018
Docker para Desenvolvedores - Developers-BR - Agosto-2018
 
Continuous Deployment e DevOps na Nuvem
Continuous Deployment e DevOps na NuvemContinuous Deployment e DevOps na Nuvem
Continuous Deployment e DevOps na Nuvem
 
Construção e provisionamento de ambientes de desenvolvimento virtualizados
Construção e provisionamento de ambientes de desenvolvimento virtualizadosConstrução e provisionamento de ambientes de desenvolvimento virtualizados
Construção e provisionamento de ambientes de desenvolvimento virtualizados
 
Integração contínua com Jenkins
Integração contínua com JenkinsIntegração contínua com Jenkins
Integração contínua com Jenkins
 
Minicurso Intel XDK
Minicurso Intel XDKMinicurso Intel XDK
Minicurso Intel XDK
 
Minicurso Intel XDK
Minicurso Intel XDKMinicurso Intel XDK
Minicurso Intel XDK
 
Play Framework - Desenvolvendo Aplicações Web com Java sem Dor
Play Framework - Desenvolvendo Aplicações Web com Java sem DorPlay Framework - Desenvolvendo Aplicações Web com Java sem Dor
Play Framework - Desenvolvendo Aplicações Web com Java sem Dor
 
Java Seminar
Java SeminarJava Seminar
Java Seminar
 
Curso Básico Android - Aula 01
Curso Básico Android - Aula 01Curso Básico Android - Aula 01
Curso Básico Android - Aula 01
 
Programação Android - Básico
Programação Android - BásicoProgramação Android - Básico
Programação Android - Básico
 

Treinamento Android Embarcado

  • 1. Embedded Labworks Por Sergio Prado. São Paulo, Maio de 2013 ® Copyright Embedded Labworks 2004-2013. All rights reserved. Android embarcado
  • 2. 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
  • 3. 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
  • 4. 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.
  • 5. Embedded Labworks AMBIENTE DE LABORATÓRIO /opt/labs/ Ambiente de laboratório dl/ Aplicações e componentes open­source que serão usados durante as atividades de laboratório docs/ Documentação guides/ Guias de consulta (shell, vi, etc)   hardware/ Documentação do hardware   training/ Slides e atividades de laboratório ex/ Exercícios de laboratório tools/ Ferramentas de uso geral
  • 6. Embedded Labworks DURANTE O TREINAMENTO ✗ Pergunte... ✗ Expresse seu ponto de vista... ✗ Troque experiências... ✗ Ajude... ✗ Participe!
  • 7. Embedded Labworks Android embarcado Introdução ao sistema operacional Android
  • 8. 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.
  • 9. 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) ✗ Este treinamento é baseado no Jelly Bean 4.2.
  • 10. Embedded Labworks PRINCIPAIS CARACTERÍSTICAS ✗ Código aberto. ✗ Interface gráfica com uma experiência familiar. ✗ Ecossistema de aplicações disponíveis (aproximadamente 850.000 aplicações em set/2013). ✗ Framework para desenvolvimento de aplicações. ✗ Ambiente de desenvolvimento completo, incluindo IDE, emulador e ferramentas de debugging.
  • 11. 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!
  • 12. 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.
  • 13. 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).
  • 14. 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)
  • 15. 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).
  • 16. 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/
  • 17. Embedded Labworks ARQUITETURA LINUX EMBARCADO Hardware Bootloader Linux kernel Biblioteca C (glibc, eglibc, uclibc, etc) Biblioteca Biblioteca Aplicação Aplicação Sistema GNU/Linux
  • 18. 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
  • 19. 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.
  • 20. Embedded Labworks DIAGRAMA DE BLOCOS Fonte: http://source.android.com
  • 21. Embedded Labworks PORTANDO O ANDROID (PASSO-A-PASSO) 1. Escolher uma plataforma de hardware compatível com os requisitos do Android. 2. Portar o bootloader para a plataforma de desenvolvimento. 3. Portar o kernel Linux para a plataforma de desenvolvimento (com os patches do Android aplicados). 4. Preparar o sistema de build do Android para compilar e gerar uma versão customizada da plataforma Android para o seu hardware. 5. Implementar a camada HAL do Android para os dispositivos de hardware presentes no sistema.
  • 23. Embedded Labworks MÁQUINA DE DESENVOLVIMENTO ✗ É recomendado o uso de uma máquina de 64 bits com o Ubuntu 12.04, já que esta é a configuração usada e testada pelo Google, mas o sistema de build deve funcionar em outras máquinas Linux ou MacOS (instalação nativa ou máquina virtual). ✗ É necessário uma máquina com boa capacidade de processamento (ex: Core i7) e com bastante espaço em disco (os fontes do Android 4.2 ocupam 10G de disco, passando de 25G depois de compilado!). ✗ Pré-requisitos de software: git 1.7+, python 2.6/2.7, make 3.81/3.82, JDK 6. ✗ Consulte o link abaixo para instruções mais completas: http://source.android.com/source/initializing.html
  • 24. 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 (últimos smartphones e tablets do mercado). ✗ Testar a imagem gerada no emulador.
  • 25. 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
  • 27. 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/git­repo­downloads/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).
  • 28. Embedded Labworks MANIFEST.XML <?xml version="1.0" encoding="UTF­8"?> <manifest>   <remote  name="aosp"            fetch=".."            review="https://android­review.googlesource.com/" />   <default revision="refs/tags/android­4.2.2_r1.1"            remote="aosp"            sync­j="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" />   [...]
  • 29. 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! $ ls abi       dalvik       frameworks       Makefile  prebuilts bionic    development  gdk              ndk       sdk bootable  device       hardware         out       system build     docs         libcore          packages cts       external     libnativehelper  pdk
  • 30. 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).
  • 31. 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
  • 32. 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
  • 33. 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/
  • 34. Embedded Labworks ANDROID PARA A WANDBOARD $ repo init ­u git://www.wandboard.org/android/manifest.git ­m default.xml  $ repo sync ­j4 [...] $ ls abi       dalvik       frameworks  libnativehelper  prebuilts bionic    development  gdk         Makefile         sdk bootable  device       hardware    ndk              system build     docs         kernel_imx  packages cts       external     libcore     pdk ✗ Instruções para baixar o código-fonte do Android para a Wandboard no link abaixo: http://www.wandboard.org/index.php/downloads
  • 35. 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.
  • 36. 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.
  • 37. Embedded Labworks DIRETÓRIOS: FRAMEWORK E APPS ✗ dalvik/: código-fonte da máquina virtual Dalvik. ✗ libcore/: biblioteca Java (Apache Harmony) ✗ frameworks/: código-fonte do framework do Android. ✗ packages/: aplicações Android.
  • 38. 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/: outras ferramentas de desenvolvimento e aplicações de debugging. ✗ cts/: ferramentas do CTS (Compatibility Test Suite).
  • 39. 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.
  • 40. Embedded Labworks LABORATÓRIO Preparando a máquina e baixando o código-fonte
  • 42. 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 Yocto. ✗ Já o Android tem sua própria solução de sistema de build!
  • 43. 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.
  • 44. 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.
  • 45. 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.
  • 46. 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).
  • 47. 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 do comando lunch.
  • 49. 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 full­eng ✗ Ao selecionar o combo, o comando lunch irá criar as variáveis de ambiente necessárias para a compilação: $ env | grep "ANDROID|TARGET"
  • 50. 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
  • 51. 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.
  • 52. 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).
  • 53. 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>/.
  • 55. Embedded Labworks OUTROS COMANDOS MAKE ✗ Limpar a compilação do produto selecionado: $ make clean ✗ Limpar a compilação de todos os produtos: $ make clobber ✗ Limpar apenas o necessário em uma troca de configuração (produto): $ make installclean
  • 56. Embedded Labworks OUTROS COMANDOS MAKE (cont.) ✗ Exibir os comandos executados durante a compilação: $ make showcommands ✗ Compilar apenas um módulo: $ make <module> ✗ Limpar a compilação de um módulo: $ make clean­<module>
  • 57. Embedded Labworks OUTROS COMANDOS DE COMPILAÇÃO ✗ Compilar o sistema de qualquer diretório: $ m ✗ Compilar todos os módulos no diretório corrente: $ mm ✗ Compilar todos os módulos de um diretório específico: $ mmm <diretório>
  • 58. 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 full, full_x86 e full_mips. ✗ É capaz de emular a interface com o usuário via monitor, teclado e mouse. ✗ Diversos outros dispositivos de hardware e eventos como coordenadas GPS, recebimento de SMS ou mudança de status da bateria podem ser emulados através de uma conexão telnet.
  • 59. 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 full­eng $ make ­j4 ✗ E para executar o emulador: $ emulator &
  • 61. Embedded Labworks LABORATÓRIO Compilando o Android e testando no emulador
  • 63. 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
  • 64. 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
  • 65. Embedded Labworks HARDWARE TÍPICO COM ANDROID Fonte: http://www.opersys.com/
  • 66. Embedded Labworks CPU ✗ Oficialmente o Android suporta as arquiteturas ARM, x86 e MIPS. ✗ O mais comum é encontrar o Android rodando em plataformas ARM, em específico ARMv7 (Cortex-A8) com um ou mais núcleos rodando acima de 1GHz. ✗ Arquiteturas como x86 e MIPS também são suportadas por outras empresas ou pela comunidade: http://www.android-x86.org/ http://developer.mips.com/android/ ✗ A partir do Android 4.0, é necessário também uma GPU com suporte à OpenGL ES 2.0.
  • 67. 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.
  • 68. 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).
  • 69. 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
  • 70. 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.
  • 71. Embedded Labworks REFERÊNCIAS E DOCUMENTAÇÃO ✗ A documentação do hardware esta disponível no ambiente de laboratório em docs/guides: ✗ 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/
  • 72. 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
  • 73. Embedded Labworks BOOTLOADER ✗ O bootloader é o código responsável por: ✗ Inicialização básica do hardware. ✗ Carregar outro binário (normalmente um sistema operacional) da memória flash, da rede ou de outro dispositivo de armazenamento não volátil para a RAM. ✗ Passar o controle da CPU para este binário. ✗ Além destas funcionalidades básicas, a maioria dos bootloaders possui uma linha de comandos para a execução de diferentes operações, como verificação de memória, formatação da flash e rotinas de diagnóstico.
  • 74. 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
  • 75. 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.
  • 76. Embedded Labworks FERRAMENTA FASTBOOT $ fastboot usage: 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   reboot­bootloader                        reboot device into bootloader   help                                     show this help message
  • 77. 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.
  • 78. 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
  • 79. 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 eventos Exportação de informações Gerenciamento do hardware Notificação de eventos
  • 80. 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 subir um sistema Android com uma versão vanilla do kernel.
  • 81. 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().
  • 82. Embedded Labworks BINDER (cont.) Binder driver (/dev/binder) Aplicação Service Manager Power Manager Activity Manager Mount Service ... System Server 1 234
  • 83. 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/SYSV­IPC.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.
  • 84. 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).
  • 85. Embedded Labworks WAKELOCKS (cont.) ✗ A resposta do Android para este problema são os wakelocks, onde o usuário (aplicação, driver) utiliza uma API para definir quando o sistema pode entrar no modo de baixo consumo. ✗ O sistema entra em modo de baixo consumo sempre que possível (quando nenhum processo estiver segurando um wakelock).
  • 86. Embedded Labworks WAKELOCKS (cont.) ✗ API em espaço de kernel: #include <linux/wakelock.h> void wake_lock_init(struct wakelock *lock, int type,                      const char *name); void wake_lock(struct wake_lock *lock); void wake_unlock(struct wake_lock *lock); void wake_lock_timeout(struct wake_lock *lock, long timeout); void wake_lock_destroy(struct wake_lock *lock);
  • 87. Embedded Labworks WAKELOCKS (cont.) ✗ API em espaço de usuário: $ echo mylock > /sys/power/wake_lock $ echo mylock > /sys/power/wake_unlock
  • 88. Embedded Labworks ALARM TIMER ✗ O Linux não possui nativamente um mecanismo de timer capaz de acordar o sistema quando o mesmo encontra-se em modo suspenso. ✗ Timers ou HRT (High Resolution Timers) são capazes de acordar um processo, mas não um sistema em modo suspenso. ✗ Um RTC é capaz de acordar um sistema em modo suspenso, mas não um processo.
  • 89. Embedded Labworks ALARM TIMER (cont.) ✗ O alarm timer é um driver do kernel que integra as funcionalidades de RTC e Timer do Linux, sendo capaz de acordar um processo, mesmo com o sistema em modo suspenso. ✗ O acesso é exportado para o usuário através do arquivo /dev/alarm, possibilitando sua configuração através de chamadas ioctl().
  • 90. 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.
  • 91. 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).
  • 92. 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.
  • 94. 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.
  • 95. 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.
  • 96. 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
  • 97. 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.
  • 98. Embedded Labworks DESENVOLVIMENTO DE DRIVERS ✗ No desenvolvimento de algum driver para uma plataforma que irá rodar o Android, teste e depure em um sistema GNU/Linux comum. ✗ Depois que o driver estiver rodando e funcionando, comece a trabalhar na camada Android.
  • 99. 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
  • 100. 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.
  • 101. 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.
  • 102. 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!
  • 103. Embedded Labworks ROOTFS NO ANDROID ✗ O espaço de usuário do Android é composto por 3 principais componentes: ✗ Camada nativa: bibliotecas e aplicações que rodam fora da máquina virtual Java. ✗ Framework Android: serviços do sistema, classes java e API para o desenvolvimento de aplicações. ✗ Aplicações Android. ✗ Estes componentes estão distribuídos em três imagens diferentes (ramdisk, system e userdata), montados respectivamente nos diretórios /, /system e /data.
  • 105. Embedded Labworks A INICIALIZAÇÃO ✗ No boot, o kernel monta a imagem do RAM disk (rootfs) e executa o processo init. ✗ O init processa os arquivos de configuração, inicializando o sistema e montando os outros sistemas de arquivo: ✗ system: binários e bibliotecas nativas, bibliotecas Java, arquivos de configuração e aplicações padrão (normalmente montado como somente leitura). ✗ data: aplicações instaladas pelo usuário, dados do usuário, etc. ✗ cache: arquivos temporários, downloads em andamento, etc. ✗ sdcard: arquivos e documentos do usuário (vídeos, sons, imagens, etc), normalmente montado com vfat. Não é essencial para o funcionamento do sistema.
  • 106. Embedded Labworks PONTOS DE MONTAGEM /cache /d /data /system /etc /mnt /root /sbin /storage /vendor /proc /sys /dev /acct Rootfs (RAM disk) Kernel Virtual FS Data Image SDCARD procfs sysfs tmpfs cgroup /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
  • 107. 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.
  • 108. 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).
  • 109. 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. /storage    Ponto de montagem para o cartão SD (antigamente montado em /sdcard). /cache    Ponto de montagem para a partição cache, usada para armazenar arquivos temporários, downloads em andamento, etc.
  • 110. 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.
  • 111. Embedded Labworks DIRETÓRIO SYSTEM (cont.) /app Aplicações pré-instaladas. /etc Arquivos de configuração. /media Arquivos de mídia (animação do boot, etc). /fonts Fontes instaladas no sistema.
  • 112. Embedded Labworks DIRETÓRIO DATA /app Diretório de instalação das aplicações. /app­private Diretório de instalação das aplicações com proteção de cópia habilitada. /app­asec Aplicações encriptadas. /data Contém um diretório para cada aplicação instalada (home das aplicações).
  • 113. Embedded Labworks DIRETÓRIO DATA (cont.) /dalvik­cache Cache da máquina virtual Java. /local Diretório com permissão de escrita para qualquer usuário. /property Armazena as propriedades persistentes do sistema. /system Banco de dados do sistema (contas, lista de aplicações instaladas, etc).
  • 114. Embedded Labworks IMAGENS NO CARTÃO Sdcard Cache Data (data.img) System (system.img) Initrd (ramdisk.img) / /system /data /cache /storage Read-only Read-write Bootloader Kernel Linux raw
  • 115. 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.
  • 116. Embedded Labworks ANDROID E LINUX LADO-A-LADO ✗ É relativamente fácil colocar um sistema GNU/Linux lado-a-lado com um sistema Android, porque: ✗ A maioria dos diretórios do rootfs são pontos de montagem de um sistema de arquivo virtual ou links para outros diretórios do sistema. ✗ Quase todo o sistema Android esta localizado nos diretórios /system e /data.
  • 117. Embedded Labworks ADB ✗ O ADB (Android Debug Bridge) é uma ferramenta de debugging desenvolvida pelo Google que possibilita o acesso via USB ou TCP/IP à qualquer dispositivo Android. ✗ Com o ADB, dentre outras opções, é possível: ✗ Iniciar uma seção do shell. ✗ Ler e copiar arquivos do dispositivo. ✗ Exibir o log do sistema. ✗ Debbuging com GDB ou JDB. ✗ Estudaremos o ADB com mais detalhes na seção de Debugging.
  • 118. Embedded Labworks LABORATÓRIO Compilando e testando o Android no target
  • 120. Embedded Labworks CAMADA NATIVA Linux Kernel Bibliotecas (bionic, etc) Init Toolbox Daemons nativos Camada HAL Dalvik / Android Runtime / Zygote System Services Android API Aplicações Bibliotecas Java API Binder JNI System call
  • 121. 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, a camada nativa do Android foi praticamente escrita do zero. Em alguns casos, é bastante diferente do que vemos em um sistema Linux tradicional!
  • 122. 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 esta disponível nos diretórios bionic/, system/core/, external/ e frameworks/base/.
  • 123. 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!
  • 124. 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
  • 125. 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.
  • 126. 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 esta 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.
  • 127. Embedded Labworks COMANDOS BUSYBOX addgroup,  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
  • 128. Embedded Labworks COMANDOS TOOLBOX ls,  mount,  cat,  ps,  kill,  ln,  insmod,  rmmod,  lsmod,  ifconfig,  setconsole, rm, mkdir, rmdir, reboot, 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
  • 129. 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.
  • 130. 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
  • 131. 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.
  • 132. Embedded Labworks DAEMONS EM EXECUÇÃO # ps USER     PID   PPID  VSIZE  RSS     WCHAN    PC         NAME root      1     0     372    228   800f0f58 0000e890 S /init root      949   1     356    4     800f0f58 0000e890 S /sbin/ueventd root      1299  1     300    4     8008e0c0 00019510 S /sbin/watchdogd root      1311  1     824    484   80045b44 2ab8a9b0 S /system/bin/sh system    1312  1     892    184   803e275c 2aca3008 S /system/bin/servicemanager root      1313  1     4068   744   ffffffff 2ac607d0 S /system/bin/vold root      1314  1     9688   924   ffffffff 2abd27d0 S /system/bin/netd root      1315  1     936    232   80414198 2ac3ead4 S /system/bin/debuggerd system    1316  1     216852 8276  ffffffff 2ac6e008 S /system/bin/surfaceflinger root      1317  1     638504 34448 ffffffff 2ac3712c S zygote drm       1318  1     9000   2996  ffffffff 2acbb008 S /system/bin/drmserver media     1319  1     207624 6520  ffffffff 2ac3c008 S /system/bin/mediaserver bluetooth 1320  1     1400   488   800f0f58 2ab8bf98 S /system/bin/dbus­daemon install   1321  1     904    444   804b91c0 2abfbd98 S /system/bin/installd keystore  1322  1     1832   684   80414198 2ab36ad4 S /system/bin/keystore root      1323  1     2436   692   ffffffff 2abc57d0 S /system/bin/rild media_rw  1326  1     4860   164   ffffffff 2abddd98 S /system/bin/sdcard root      1328  1     6120   932   ffffffff 2ac68760 S /system/bin/ingsvcd root      1329  1     3448   4     ffffffff 00015f2c S /sbin/adbd
  • 133. 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 os arquivos de dispositivo no /dev.
  • 134. 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).
  • 135. 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.
  • 136. 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.
  • 137. 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.
  • 138. Embedded Labworks DEBUGGERD ✗ O debuggerd é um daemon de debugging. ✗ É invocado pelo linker da Bionic para fazer análise postmortem de um processo que finalizou de forma inesperada. ✗ Gera um arquivo de debugging em /data/tombstones e possibilita o debug via gdb.
  • 139. Embedded Labworks OUTROS DAEMONS ✗ adbd: daemon para gerenciar a conexão ADB. ✗ system_server: daemon que contém a maioria dos serviços do Android. ✗ servicemanager: responsável pelo gerenciamento da comunicação com o Binder, funcionando como um índice para todos os serviços que usam o Binder no sistema. ✗ mediaserver: responsável pelos serviços de media (audio, video, etc). ✗ keystore: gerencia o armazenamento e acesso à chaves criptográficas, como por exemplo certificados SSL.
  • 140. Embedded Labworks OUTRAS BIBLIOTECAS E APLICAÇÕES ✗ stagefright: biblioteca responsável pela codificação e decodificação de arquivos multimedia (equivalente ao gstreamer). ✗ bluedroid: stack Bluetooth, que serve de interface entre os serviços do Android e a camada HAL de acesso ao hardware. ✗ dalvik: máquina virtual Java, portável e leve, responsável por executar aplicações Android. ✗ app_process: ferramenta capaz de instanciar a Dalvik e executar uma aplicação Java.
  • 141. Embedded Labworks COMANDOS NATIVOS ✗ 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.
  • 142. Embedded Labworks COMANDOS NATIVOS (cont.) ✗ start/stop: iniciar/parar serviços. ✗ log: logar uma mensagem no sistema de log do Android. ✗ logcat: exibir o log do sistema. ✗ wipe: apagar a partição system ou data. ✗ logwrapper: permite executar um comando e redirecionar as saídas padrão e de erro para o log do Android. ✗ netcfg: exibir informações e configurar as interfaces de rede.
  • 143. Embedded Labworks A CAMADA 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.
  • 146. Embedded Labworks VISÃO GERAL DO BOOT Bootloader Carrega o kernel para a RAM e inicia init Inicia outros serviços e aplicações Kernel Monta o rootfs indicado por ”root=” Inicia a aplicação ”init” Shell Outras aplicações Rootfs
  • 147. 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
  • 148. 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!
  • 149. Embedded Labworks INIT DO ANDROID ✗ O processo init do Android, através de alguns arquivos de configuração, é capaz de: ✗ Configurar o sistema (montar sistemas de arquivo, exportar variáveis de ambiente, criar e definir permissões de arquivos, etc). ✗ Iniciar os daemons e gerenciar sua execução. ✗ Gerenciar eventos de hotplug de dispositivos de hardware (através do ueventd). ✗ Monitorar as propriedades do sistema e executar ações específicas quando uma propriedade for modificada.
  • 150. 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.
  • 151. Embedded Labworks ARQUIVOS DE CONFIGURAÇÃO (cont.) ✗ Os arquivos de configuração possuem basicamente dois tipos de declaração: ✗ Ações que podem ser tomadas de acordo com algum evento do sistema: on <trigger>     <command>     <command> ✗ Serviços que são gerenciados pelo init: service <name> <pathname> [ <argument> ]*     <option>     <option>
  • 152. Embedded Labworks SERVIÇOS E AÇÕES ✗ Apenas a declaração de ações resultam na execução de comandos pelo processo init. ✗ A declaração de serviços servem apenas para descrever os serviços, que normalmente são iniciados com os comandos start ou class_start, através de alguma ação disparada por um evento. ✗ São basicamente duas as fontes de eventos que podem disparar uma ação: ✗ Triggers pré-definidos de boot (early­init, init, early­fs, fs, post­fs, early­boot, boot). ✗ Mudança em alguma propriedade do sistema.
  • 153. Embedded Labworks TRIGGERS DE BOOT ✗ Os triggers de boot são eventos gerados automaticamente pelo init no boot do sistema. ✗ Esta é a lista completa de triggers de boot, por ordem de execução: ✗ early-init ✗ init ✗ early-fs ✗ fs ✗ post-fs ✗ early-boot ✗ boot
  • 154. Embedded Labworks TRIGGERS DE BOOT (cont.) ✗ Cada ação disparada por um evento (trigger) irá causar a execução de um ou mais comandos: on early­init     write /proc/1/oom_adj ­16     setcon u:r:init:s0     start ueventd ✗ São vários os comandos disponíveis, dentre eles chdir, chmod, chown, class_start, class_stop, copy, export, ifup, insmod, loglevel, mkdir, mount, start, stop, restart. ✗ Uma descrição (desatualizada) dos comandos esta disponível nos fontes em system/core/init/readme.txt.
  • 155. Embedded Labworks SERVIÇOS ✗ Os serviços são daemons iniciados e gerenciados pelo processo init, declarados conforme abaixo: service <name> <pathname> [ <argument> ]*     <option>     <option> ✗ Esta declaração apenas descreve o serviço, mas não o inicia. ✗ Um serviço é iniciado no disparo de uma ação, através de alguns comandos como o start ou o class_start.
  • 157. 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.
  • 158. 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.
  • 159. Embedded Labworks UEVENTD ✗ O daemon ueventd (parte do init) é executado no boot do sistema, sendo o responsável pelo gerenciamento dos eventos de hotplug gerados pelo kernel. service ueventd /sbin/ueventd     class core     critical     seclabel u:r:ueventd:s0 on early­init     start ueventd
  • 160. Embedded Labworks UEVENTD (cont.) ✗ O ueventd captura os eventos de hotplug e cria ou remove os arquivos de dispositivo no /dev. ✗ 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 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.
  • 161. Embedded Labworks EXEMPLO UEVENTD <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
  • 162. 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).
  • 163. 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.
  • 164. Embedded Labworks LISTANDO AS PROPRIEDADES ✗ As propriedades podem ser listadas com o comando getprop: # getprop [alsa.mixer.capture.headset]: [Capture] [dalvik.vm.dexopt­flags]: [m=y] [net.hostname]: [android­67af414597e8c083] [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]
  • 165. 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 criado. ✗ Alterando o init.rc ou outro arquivo de configuração do init. ✗ Em tempo de execução, as propriedades do sistema podem ser alteradas através da ferramenta setprop. ✗ As propriedades podem também ser monitoradas com o comando watchprops.
  • 166. 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 }
  • 167. 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.
  • 168. 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
  • 169. 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. ✗ A implementação de máquina virtual Java utilizada no Android é a Dalvik.
  • 170. Embedded Labworks DALVIK ✗ A Dalvik é uma máquina virtual Java, portável e leve, responsável por executar as aplicações Android. ✗ Projetada para executar várias instancias ao mesmo tempo, consumindo pouca memória. ✗ Duas formas de execução: ✗ fast: otimizada para a arquitetura, mas não portável. ✗ portable: toda escrita em C, um pouco lenta, mas funciona em todas as plataformas. ✗ Usa o framework de bibliotecas Java do projeto Apache Harmony.
  • 171. 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 –start­system­server     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
  • 172. 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.
  • 173. 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.
  • 174. Embedded Labworks INICIALIZAÇÃO (RESUMIDA) Kernel Linux init init.rc, *.rc Zygote System Server app_process Activity Manager Launcher C/C++ Java start(Launcher) daemons Power Manager Outros Serviços
  • 175. Embedded Labworks PROCESSOS NA INICIALIZAÇÃO # ps USER     PID   PPID  VSIZE  RSS     WCHAN    PC         NAME root      1     0     372    228   800f0f58 0000e890 S /init root      949   1     356    4     800f0f58 0000e890 S /sbin/ueventd root      1315  1     824    492   80045b44 2ac9d9b0 S /system/bin/sh system    1316  1     892    184   803e275c 2acab008 S /system/bin/servicemanager root      1321  1     638504 34440 ffffffff 2abad12c S zygote drm       1322  1     9004   3000  ffffffff 2acb6008 S /system/bin/drmserver media     1323  1     208648 6512  ffffffff 2ab48008 S /system/bin/mediaserver system    1621  1321  914932 43172 ffffffff 2abad008 S system_server u0_a9     1698  1321  855328 58212 ffffffff 2abadf20 S com.android.systemui u0_a2     1781  1321  649212 19328 ffffffff 2abadf20 S com.android.inputmethod.latin radio     1792  1321  661760 21868 ffffffff 2abadf20 S com.android.phone u0_a31    1815  1321  851020 38768 ffffffff 2abadf20 S com.android.launcher u0_a39    1830  1321  646836 15572 ffffffff 2abadf20 S com.android.location.fused u0_a17    1960  1321  649628 18152 ffffffff 2abadf20 S com.android.providers.calendar u0_a23    1996  1321  657840 19948 ffffffff 2abadf20 S com.android.email u0_a24    2013  1321  655480 16904 ffffffff 2abadf20 S com.android.exchange u0_a38    2089  1321  654508 17564 ffffffff 2abadf20 S com.android.calendar
  • 176. Embedded Labworks LABORATÓRIO Alterando o processo de inicialização do Android
  • 178. Embedded Labworks PLACAS, DISPOSITIVOS E PRODUTOS Arquitetura Placa (hardware) Dispositivo (periféricos) Produto (customizações)
  • 179. 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. Por exemplo, na versão 4.2.2 do Android, são definidos vários produtos para a linha Nexus, além de um produto para a Pandaboard. ✗ Adicionar um produto é normalmente uma das primeiras tarefas ao portar o Android para uma plataforma embarcada. ✗ Os produtos disponíveis podem ser exibidos e selecionados com o comando lunch.
  • 180. Embedded Labworks CRIANDO UM PRODUTO ✗ Para criar um produto é necessário criar um diretório em device/<company>/<device>, onde estarão todos os arquivos de definição do produto. $ mkdir ­p device/labworks/superdroid/ ✗ E depois implementar um arquivo chamado AndroidProducts.mk, que deve incluir o Makefile do seu produto através da variável PRODUCT_MAKEFILES: PRODUCT_MAKEFILES :=      $(LOCAL_DIR)/full_superdroid.mk
  • 181. 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 inherit­product, $(SRC_TARGET_DIR)/product/full.mk) PRODUCT_NAME   := full_superdroid PRODUCT_DEVICE := superdroid PRODUCT_MODEL  := Super Android robot PRODUCT_BRAND  := Android
  • 182. Embedded Labworks ADICIONANDO APLICAÇÕES ✗ Neste makefile é necessário definir todas as aplicações que estarão presentes no produto. ✗ Normalmente isso é feito incluindo outro makefile que contém um conjunto de aplicações já pré-definidas, conforme exemplo anterior: $(call inherit­product, $(SRC_TARGET_DIR)/product/full.mk) ✗ Estes arquivos de makefile pré-configurados estão disponíveis em no código-fonte do sistema de build em build/target/product.
  • 183. Embedded Labworks ADICIONANDO APLICAÇÕES (cont.) ✗ As aplicações também podem ser incluídas no produto através da variável PRODUCT_PACKAGES: PRODUCT_PACKAGES +=         LiveWallpapers          Gallery2                   SoundRecorder           Camera                  Email                   FSLOta                  CactusPlayer            VideoEditor             FSLProfileApp           FSLProfileService       PinyinIME          
  • 184. Embedded Labworks ADICIONANDO APLICAÇÕES (cont.) ✗ Ao criar um pacote específico para o seu produto, seja uma aplicação Android, biblioteca ou aplicação nativa, coloque-a dentro do diretório do produto criado. ✗ Por exemplo, uma necessidade comum é a implementação de uma aplicação Launcher específica para o seu produto. O código-fonte desta aplicação deve ir dentro do diretório do produto criado. ✗ Isso facilita a manutenção, como por exemplo ao fazer upgrade de versão do Android, já que todas as alterações do seu produto ficam centralizadas em um único diretório. ✗ Veremos como fazer isso mais adiante no treinamento.
  • 185. 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).
  • 186. 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
  • 187. Embedded Labworks OVERLAYS ✗ 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/.
  • 188. Embedded Labworks OVERLAYS (cont.) ✗ Para realizar o overlay o primeiro passo é criar o diretório overlay com a mesma estrutura de diretórios do código-fonte do Android: $ tree device/samsung/manta/overlay/  ──├ frameworks      │ ──└ base          │ ──├ core              │ │ ──└ res                  │ │ ──└ res                      │ │ ──├ values                          │ │ │ ──└ config.xml                      │ │ ──└ xml                          │ │ ──├ power_profile.xml                          │ │ ──└ storage_list.xml
  • 189. Embedded Labworks OVERLAYS (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 ✗ Uma lista completa das opções que podem ser usadas no Makefile do produto estão disponíveis no código-fonte do sistema de build em build/core/product.mk.
  • 190. 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.
  • 191. 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.
  • 193. 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.
  • 194. 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_superdroid­eng
  • 195. Embedded Labworks RESUMO ✗ Crie o diretório do produto em device/<company>/<device>, e implemente os seguintes arquivos: ✗ AndroidProducts.mk: inclua o Makefile do seu produto. ✗ <product_name>.mk: defina informações gerais sobre o produto (nome, dispositivo, módulos, overlays, etc). ✗ BoardConfig.mk: defina a configuração da plataforma de hardware (arquitetura, bootloader, kernel, etc). ✗ vendorsetup.sh: adicione o produto ao menu do comando lunch.
  • 198. 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.
  • 200. 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.
  • 201. Embedded Labworks EXEMPLO (cont.) ✗ LOCAL_MODULE é o nome do módulo. ✗ LOCAL_MODULE_TAGS classifica o módulo através de uma tag (user, debug, eng, development, optional). ✗ include $(BUILD_EXECUTABLE) indica ao sistema de build que este módulo deve compilado como um binário.
  • 203. 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.
  • 204. 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 arquivos pré-compilados no target. ✗ BUILD_MULTI_PREBUILT instala múltiplos arquivos pré- compilados no target.
  • 205. 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.
  • 206. 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.
  • 207. 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/build­system.html.
  • 208. Embedded Labworks MACROS ✗ Vimos no exemplo o uso da macro my­dir para retornar o diretório corrente da aplicação: LOCAL_PATH := $(call my­dir) ✗ Várias outras macros estão disponíveis para uso, como por exemplo: ✗ all­java­files­under: retorna todos os arquivos java recursivamente, a partir do diretório passado como parâmetro. ✗ all­subdir­c­files: retorna todos os arquivos C recursivamente, a partir do diretório corrente. ✗ A maioria das macros estão definidas em build/core/definitions.mk.
  • 209. Embedded Labworks COMPILANDO UM MÓDULO ✗ Para compilar um módulo (do diretório principal do Android): $ make <module_name> ✗ Para limpar a compilação de um módulo: $ make clean­<module_name> ✗ Para listar todos os módulos que serão compilados: $ make modules
  • 210. 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 de 3 fatores: ✗ Definição da tag do módulo. ✗ Escolha da variante do produto. ✗ Conteúdo da variável PRODUCT_PACKAGES do produto.
  • 211. Embedded Labworks TAGS ✗ As tags classificam os módulos e estão diretamente ligadas à variante escolhida no comando lunch: ✗ user: build de produção, inclui módulos com a tag user. ✗ userdebug: mesmo que a variante user, mas inclui também módulos com a tag debug, e habilita o ADB por padrão. ✗ eng: mesmo que a variante userdebug, mas inclui também módulos com as tags eng e development. ✗ As tags são definidas através da variável LOCAL_MODULE_TAGS no Android.mk do módulo.
  • 212. Embedded Labworks TAGS (cont.) ✗ Módulos sem tag ou com a tag optional precisam ser incluídos na variável PRODUCT_PACKAGES do produto para serem instalados. ✗ As tags de aplicações Android (*.apk) são ignoradas. As aplicações Android precisam ser incluídas na variável PRODUCT_PACKAGES do produto para serem instaladas.
  • 213. Embedded Labworks DICAS ✗ Implemente novos módulos no diretório do produto em device/<company>/<device>. ✗ Use como padrão em novos módulos a tag optional, não esquecendo de incluir o nome do módulo na variável  PRODUCT_PACKAGES do produto. ✗ Na dúvida sobre a implementação de um Android.mk, consulte os diversos exemplos disponíveis no código-fonte do Android, especialmente no diretório external/.
  • 216. Embedded Labworks FRAMEWORK ANDROID Linux Kernel Bibliotecas (bionic, etc) Init Toolbox Daemons nativos Camada HAL Dalvik / Android Runtime / Zygote System Services Android API Aplicações Bibliotecas Java API Binder JNI System call
  • 217. Embedded Labworks O FRAMEWORK ✗ O framework Android é a camada responsável por prover serviços para as aplicações Android. ✗ A maioria dos componentes é baseada em Java. ✗ O framework Android se comunica com a camada nativa via JNI (Java Native Interface).
  • 218. Embedded Labworks COMPONENTES ✗ Componentes do framework Android: ✗ Android Runtime, Dalvik e Zygote. ✗ System Services. ✗ Classes Java do projeto Apache Harmony. ✗ Android API. ✗ Código-fonte em frameworks/, dalvik/ e libcore/.
  • 219. Embedded Labworks COMPONENTES (cont.) ✗ Já falamos sobre o Android Runtime, Dalvik e Zygote quando estudamos o processo de inicialização do Android. ✗ Falaremos sobre as classes Java e a API do Android quando estudarmos a camada de aplicações do sistema. ✗ Nosso foco nesta seção são os System Services, núcleo do framework Android.
  • 220. Embedded Labworks SYSTEM SERVICES ✗ System Services são os serviços do Android responsáveis por prover funcionalidades para as aplicações. Exemplos: ✗ Power Manager para gerenciamento de energia. ✗ Activity Manager para gerenciamento da execução dos componentes Android. ✗ Package Manager para gerenciamento de pacotes Android (APK). ✗ Location Manager para gerenciamento de localização (ex: GPS). ✗ O Android 4.2 possui em torno de 70 serviços!
  • 221. Embedded Labworks LISTANDO OS SERVIÇOS # service list Found 68 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 dreams: [android.service.dreams.IDreamManager] 5 commontime_management: [] 6 samplingprofiler: [] 7 diskstats: [] [...]
  • 222. Embedded Labworks SERVIÇOS E SEUS PROCESSOS ✗ Alguns serviços são processos que rodam nativamente e são executados pelo processo init no boot (Surface Flinger, DRM Server, Media Server). ✗ Mas a maioria dos serviços fazem parte do processo System Server, executado pelo Zygote no boot do sistema.
  • 223. Embedded Labworks SERVIÇOS E SEUS 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. ✗ drmserver: processo do DRM Server, responsável pelo gerenciamento de conteúdos protegidos por direitos autorais.
  • 224. 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
  • 225. 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.