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 opensource
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!
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
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.
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/gitrepodownloads/repo
✗ Com o repo é possível baixar e gerenciar uma versão específica do
Android, composta por diversos repositórios git, descritos em um
arquivo XML (manifest.xml).
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.
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 fulleng
✗ Ao selecionar o combo, o comando lunch irá criar as variáveis de
ambiente necessárias para a compilação:
$ env | grep "ANDROID|TARGET"
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 fulleng
$ make j4
✗ E para executar o emulador:
$ emulator &
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/
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.
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.
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().
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/SYSVIPC.html
✗ Por exemplo, esta implementação usa um contador de referência para
destruir regiões de memória que não estão mais sendo usadas.
✗ Via interface /dev/ashmem uma aplicação requisita uma região de
memória e compartilha com outros processos via Binder.
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);
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.
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.
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.
/appprivate Diretório de instalação das aplicações com
proteção de cópia habilitada.
/appasec Aplicações encriptadas.
/data Contém um diretório para cada aplicação
instalada (home das aplicações).
113. Embedded Labworks
DIRETÓRIO DATA (cont.)
/dalvikcache 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.
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.
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/dbusdaemon
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 (earlyinit, init, earlyfs, fs, postfs,
earlyboot, 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 earlyinit
write /proc/1/oom_adj 16
setcon u:r:init:s0
start ueventd
✗ São vários os comandos disponíveis, dentre eles chdir, chmod,
chown, class_start, class_stop, copy, export, ifup, insmod,
loglevel, mkdir, mount, start, stop, 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 earlyinit
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.
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.dexoptflags]: [m=y]
[net.hostname]: [android67af414597e8c083]
[persist.service.bdroid.bdaddr]: [22:22:da:0a:2d:31]
[ro.board.platform]: [imx6]
[ro.boot.hardware]: [freescale]
[ro.build.date]: [Fri Jun 21 15:01:11 CST 2013]
[ro.build.product]: [wandboard]
[ro.build.user]: [root]
[sys.boot_completed]: [1]
[wifi.interface]: [wlan0]
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 –startsystemserver
class main
socket zygote stream 660 root system
onrestart write /sys/android_power/request_state wake
onrestart write /sys/power/state on
onrestart restart media
onrestart restart netd
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
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 inheritproduct, $(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 inheritproduct, $(SRC_TARGET_DIR)/product/full.mk)
✗ Estes arquivos de makefile pré-configurados estão disponíveis em
no código-fonte do sistema de build em build/target/product.
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_superdroideng
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/buildsystem.html.
208. Embedded Labworks
MACROS
✗ Vimos no exemplo o uso da macro mydir para retornar o diretório
corrente da aplicação:
LOCAL_PATH := $(call mydir)
✗ Várias outras macros estão disponíveis para uso, como por exemplo:
✗
alljavafilesunder: retorna todos os arquivos java recursivamente, a
partir do diretório passado como parâmetro.
✗
allsubdircfiles: retorna todos os arquivos C recursivamente, a partir
do diretório corrente.
✗ A maioria das macros estão definidas em build/core/definitions.mk.
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.