Embedded Labworks

Por Sergio Prado. São Paulo, Agosto de 2013® Copyright Embedded Labworks 2004-2013. All rights reserved.

Portando o Android para uma plataforma embarcada

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://sergioprado.org/palestras/escbrazil2013

Embedded Labworks

SOBRE O PALESTRANTE

✗ 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

1. Introdução

2. Hardware, bootloader e kernel

3. Plataforma Android

4. Sistema de build

5. Camada HAL

6. Links e recursos

Embedded Labworks

Portando o Android para uma plataforma embarcada

Introdução

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)

✗ Esta apresentação é baseada no Jelly Bean 4.2.

Embedded Labworks

PRINCIPAIS CARACTERÍSTICAS

✗ Código aberto.

✗ Interface gráfica com uma experiência familiar.

✗ Framework para desenvolvimento de aplicações.

✗ Ecossistema de aplicações disponíveis.

✗ Suporte à hardware (aceleradores gráficos, sensores, tecnologias wireless, 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 pelo AOSP, incluindo os últimos smartphones e tablets de referência do Google.

Embedded Labworks

COMUNIDADE E LICENÇAS

✗ Qualquer um pode contribuir com o projeto, mas a comunidade é bem fechada em torno do Google.https://android-review.googlesource.com

✗ A grande maioria dos pacotes estão sob as licenças Apache e BSD, com alguns pacotes sob licenças GPL/LGPL.

✗ 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

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

DIAGRAMA DE BLOCOS ANDROID

Fonte: http://source.android.com

Embedded Labworks

PASSOS PARA PORTAR O ANDROID

1. Escolher uma plataforma compatível com os requisitos de hardware do Android.

2. Portar o bootloader para a plataforma de desenvolvimento.

3. Portar o kernel Linux para a plataforma de desenvolvimento, aplicando os patches do Android se necessário.

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

Portando o Android para uma plataforma embarcada

Hardware, bootloader e kernel

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).

✗ Comunicação wireless (Bluetooth, WiFi, NFC, etc).

Embedded Labworks

ANDROID COMPATIBILITY PROGRAM

✗ 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):✗ Compliance Definition Document (CDD): descreve os requisitos necessários

(software e hardware) para que um dispositivo possa ser considerado compatível com Android.

✗ Compliance Test Suite (CTS): ferramenta para testes unitários do framework do Android (APIs, Dalvik, permissões, etc), que deve ser realizado no dispositivo.

✗ Cada versão do Android tem os seus documentos! Mais informações no link abaixo:http://source.android.com/compatibility/

Embedded Labworks

BOOTLOADER

✗ 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.

✗ Uma funcionalidade normalmente presente em bootloaders para o Android é o fastboot, um protocolo que inclui uma ferramenta host que se comunica via USB com o dispositivo e permite gravação na flash e atualização de firmware.http://goo.gl/WYyd5

✗ Normalmente cada fabricante de hardware disponibiliza um bootloader (o U-Boot é padrão em plataformas abertas).

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 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 staging), sendo possível subir um sistema Android com uma versão vanilla do kernel.

Embedded Labworks

ALTERAÇÕES NO KERNEL (OBRIGATÓRIAS)

✗ Binder: Mecanismo de IPC/RPC do Android.

✗ Ashmem: Anonymous Shared Memory é um mecanismo de memória compartilhada similar ao POSIX SHM disponível no Linux, mas com comportamento diferente, como por exemplo o uso de um contador de referência para destruir regiões de memória que não estão mais sendo usadas.

✗ Logger: driver que provê um mecanismo de log para todo o sistema Android, mantendo 4 buffers circulares em kernel space que podem ser acessados via biblioteca liblog.

✗ Monotonic Event Timestamps: prover na camada de input do kernel um clock monotônico.

Embedded Labworks

ALTERAÇÕES NO KERNEL (RECOMENDADAS)

✗ Wakelock: lock criado para o gerenciamento de energia. Um sistema Android entra em modo sleep sempre que possível. Para evitar que o sistema entre no modo de sleep, a aplicação deve segurar um wakelock.

✗ Alarm: driver que integra as funcionalidades de RTC e Timer do Linux, provendo aos usuários a capacidade de temporização e alarme mesmo quando o sistema esta em modo sleep.

✗ Low-Memory Killer: responsável por matar processos cujos componentes possuem baixa prioridade e estão sem utilização durante certo tempo.

✗ 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.

Embedded Labworks

ALTERAÇÕES NO KERNEL (OPCIONAIS)

✗ 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.

✗ Paranoid networking: adiciona um controle de acesso à rede por processo.

✗ Goldfish emulator: suporte ao emulador Goldfish no kernel.

✗ Netfilter: Alterações para permitir contabilização do uso da rede pelas aplicações.

✗ Timed GPIO: 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 Linux (pode ser necessário algum tipo de adaptação dependendo da versão do kernel).https://android.googlesource.com/kernel/common.git

Embedded Labworks

DICAS DESENVOLVIMENTO KERNEL

✗ No desenvolvimento do kernel ou de algum driver para uma plataforma que irá rodar o Android, faça o debug em um sistema GNU/Linux comum.

✗ Depois que o kernel estiver rodando e funcionando, comece a trabalhar na camada Android.

Embedded Labworks

Portando o Android para uma plataforma embarcada

Plataforma Android

Embedded Labworks

PLATAFORMA ANDROID

Linux Kernel

InitToolbox

Daemons nativos

Bibliotecas(bionic, etc) HAL

Dalvik Runtime

System Services

Android API

Aplicações

BibliotecasJava

API

Binder

JNI

Embedded Labworks

CAMADA NATIVA

✗ Tudo que roda fora da máquina virtual pode ser considerado parte da camada nativa da plataforma Android.

✗ Esta camada é composta por bibliotecas e aplicações utilizadas pelo sistema (biblioteca do sistema, daemons, ferramentas de linha de comando, etc).

✗ Por questões de licença, boa parte dos pacotes open source comuns em Linux (glibc, busybox, etc) foram reimplementados no Android.

Embedded Labworks

APLICAÇÕES E DAEMONS NATIVOS

✗ toolbox: substitui o Busybox, provendo aplicações e ferramentas para acesso via shell.

✗ ueventd: faz o papel do udev em sistemas GNU/Linux, sendo responsável pelo gerenciamento dos dispositivos no /dev.

✗ vold: gerencia dispositivos de armazenamento e pontos de montagem.

✗ netd: gerencia a rede (tethering, NAT, PPP, etc).

✗ installd: gerenciar instalação e desinstalação de aplicativos (*.apk).

✗ adbd: gerencia a conexão ADB.

Embedded Labworks

BIBLIOTECAS NATIVAS

✗ Bibliotecas específicas do Android: bionic, binder, logging, dalvik, stagefright, opengl, etc.

✗ Algumas bibliotecas externas usadas pela plataforma Android: openssl, expat (XML parser), libjpeg, sqlite, webKit, zlib, etc.

Embedded Labworks

ALGUMAS FERRAMENTAS NATIVAS

✗ getprop/setprop: configurar propriedades gerais do sistema.

✗ logcat: ferramenta para exibir o log do sistema.

✗ logwrapper: permite executar um comando e redirecionar as saídas padrão e de erro para o log do Android.

✗ getevent/sendevent: manipular a camada input do sistema.

✗ netcfg: exibir informações e configurar interfaces de rede.

Embedded Labworks

FRAMEWORK ANDROID

✗ Baseado em Java.

✗ Dalvik é a máquina virtual Java do Android, com suporte à JIT e otimizada para sistemas embarcados (interpreta arquivos dex).

✗ Possui os seguintes componentes:✗ System Services.

✗ Classes Java do projeto Apache Harmony.

✗ Android API.

✗ Todo o framework Android se comunica com a camada nativa via JNI (Java Native Interface).

Embedded Labworks

SYSTEM SERVICES

✗ Conjunto de serviços do Android responsável por prover funcionalidades para as aplicações (Power Manager, Activity Manager, Package Manager, Location Manager, etc).

✗ Listando os serviços:

# service listFound 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

SYSTEM SERVICES (cont.)

✗ Estes serviços não são muito bem documentados, então para entender seu funcionamento na maioria dos casos você precisa ler o código-fonte!

✗ A comunicação com os serviços é realizada via API do Android, que internamente usa o binder como mecanismo de IPC.

PowerManager pm = (PowerManager) getSystemService(POWER_SERVICE);PowerManager.WakeLock wakeLock = pm.newWakeLock(                  PowerManager.FULL_WAKE_LOCK, "myPreciousWakeLock");wakeLock.acquire(100);

Embedded Labworks

SYSTEM SERVICES E O BINDER

Binder driver (/dev/binder)

Aplicação Service Manager

Power ManagerActivity ManagerMount Service...

SystemServer

1 234

Embedded Labworks

APLICAÇÕES

✗ As aplicações Android são compostas por 4 tipos diferentes de componentes:✗ Activities: classe gerenciadora da interface com o usuário.

✗ Services: processos rodando em background que podem prover serviços para outros componentes.

✗ Broadcast receivers: realiza o registro para receber um evento do sistema: nível baixo de bateria, modo avião habilitado, etc.

✗ Content providers: banco de dados que possibilita disponibilizar dados de uma aplicação para outras aplicações.

✗ Os componentes se comunicam entre si através de um mecanismo de mensagens chamado de intent.

Embedded Labworks

REGISTRANDO ACTIVITY COMO BROWSER<!­­ AndroidManifest.xml ­­> 

<activity android:name=".BrowserActivitiy"           android:label="@string/app_name">  <intent­filter>     <action android:name="android.intent.action.VIEW" />     <category android:name="android.intent.category.DEFAULT" />     <data android:scheme="http"/>   </intent­filter></activity>

Embedded Labworks

EXECUTANDO ACTIVITY DO TIPO BROWSERIntent i = new Intent(Intent.ACTION_VIEW,                      Uri.parse("http://www.sergioprado.org"));startActivity(i);

Embedded Labworks

INICIALIZAÇÃO (VERSÃO SIMPLIFICADA)

Kernel Linux

initinit.rc

Zygote

SystemServer

app_process

Activity Manager

Launcher

C/C++

Javastart(launcher)

Embedded Labworks

Portando o Android para uma plataforma embarcada

Sistema de build

Embedded Labworks

CÓDIGO-FONTE

✗ Código-fonte do projeto AOSP esta disponível em:http://source.android.com

✗ O código-fonte é dividido em diversos repositórios git, que podem ser acessados em:http://android.googlesource.com

✗ O Google criou uma ferramenta chamada repo para gerenciar os repositórios git.

✗ Um arquivo XML (manifest.xml) descreve todos os repositórios e é usado pela ferramenta repo para baixar todo o código-fonte do Android.

Embedded Labworks

REPO$ repo init ­u https://android.googlesource.com/platform/manifest

$ repo sync[...] Alguns dias depois...

$ lsabi       dalvik       frameworks       Makefile  prebuiltsbionic    development  gdk              ndk       sdkbootable  device       hardware         out       systembuild     docs         libcore          packagescts       external     libnativehelper  pdk

Embedded Labworks

OUTROS REPOSITÓRIOS

✗ O Google AOSP é o repositório principal mas oferece suporte limitado à dispositivos de hardware.

✗ A Linaro fornece uma árvore alternativa e atualizada com suporte à um conjunto maior de dispositivos de hardware (ARM):http://linaro.org

✗ 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 (ex: Rowboat para os chips Sitara da TI).

✗ BSP do fabricante pode fornecer bom suporte mas normalmente é bem desatualizado.

Embedded Labworks

SISTEMA DE BUILD

✗ Todo o mecanismo de compilação é baseado em Makefiles (Android.mk).

✗ Não existe nenhum sistema de configuração para definir o que vai ser compilado, como o kconfig ou o autotools.

✗ Configuração do que é compilado depende basicamente de variáveis de ambiente do shell ou de definições estáticas em um arquivo chamado buildspec.mk.

✗ As variáveis que definem o que será compilado em um build estão associadas ao conceito de produto (ex: crespo para o Google Nexus S).

Embedded Labworks

CONFIGURANDO$ source build/envsetup.sh

$ 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. mini_armv7a_neon­userdebug     [...]

Which would you like? [full­eng]

Embedded Labworks

COMPILANDO$ make[...] Mais alguns dias depois...

$ ls out/target/product/generic/android­info.txt        installed­files.txt       systemclean_steps.mk          obj                       system.imgdata                    previous_build_config.mk  testdex_bootjars            ramdisk.img               userdata.imghardware­qemu.ini       root                      userdata­qemu.imghardware­qemu.ini.lock  symbols                   userdata­qemu.img.lock

Embedded Labworks

IMAGENS E PARTIÇÕES

Sdcard

Cache

Data (data.img)

System (system.img)

Initrd (ramdisk.img) /

/system

/data

/cache

/sdcard

Read-only

Read-write

BootloaderKernel Linux

raw

Embedded Labworks

PRODUTOS

✗ O Android utiliza o conceito de produto, que contém as especificações de um produto Android (arquitetura, camada HAL, conjunto de aplicações, etc).

✗ Cada produto pode ter mais de uma variante, configurável através da variável LOCAL_MODULE_TAGS no arquivo de compilação do pacote (Android.mk).

✗ eng: build de desenvolvimento, incluindo todos os módulos selecionados pelo produto.

✗ user: build de produção, incluindo apenas módulos com a tag optional ou sem definição de tags (não inclui módulos com as tags eng, tests e debug).

✗ userdebug: idêntico ao build de produção, mas inclui módulos com a tag debug, e também habilita o ADB por padrão.

✗ É possível visualizar os produtos e suas variantes 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:

✗ <product_name>.mk:  Makefile do produto, com informações gerais sobre o produto (nome, dispositivo, módulos, overlays, etc). Uma lista completa das opções em build/core/product.mk.

✗ AndroidProducts.mk: deve incluir o Makefile do seu produto.

✗ BoardConfig.mk: Configuração da plataforma de hardware (arquitetura, bootloader, kernel, etc).

✗ vendorsetup.sh: Adiciona o produto ao menu do comando lunch.

Embedded Labworks

full_superdroid.mk$(call inherit­product, $(SRC_TARGET_DIR)/product/full.mk)

DEVICE_PACKAGE_OVERLAYS :=

PRODUCT_PACKAGES +=

PRODUCT_COPY_FILES +=

PRODUCT_NAME := full_superdroidPRODUCT_DEVICE := superdroidPRODUCT_MODEL := Super Android robot

Embedded Labworks

AndroidProducts.mk PRODUCT_MAKEFILES := \

$(LOCAL_DIR)/full_superdroid.mk

Embedded Labworks

BoardConfig.mkTARGET_NO_KERNEL := trueTARGET_NO_BOOTLOADER := true

TARGET_ARCH := armTARGET_ARCH_VARIANT := armv7­aTARGET_CPU_ABI := armeabi

BOARD_USES_GENERIC_AUDIO := trueUSE_CAMERA_STUB := true

Embedded Labworks

vendorsetup.shadd_lunch_combo full_superdroid­eng

Embedded Labworks

OUTRAS CUSTOMIZAÇÕES

✗ Possíveis alterações e customizações que devem ficar no diretório do produto criado em device/<company>/<device>:

✗ Alteração da configuração padrão dos daemons da camada nativa (init.rc, vold.fstab, ueventd.rc, etc).

✗ Inclusão de blobs e outros arquivos (firmware, shell scripts, imagem de boot, etc).

✗ Overlay da configuração do framework Android em overlay/.

✗ Aplicações Android como a implementação de um Launcher customizado.

✗ Implementação da camada HAL.

Embedded Labworks

Portando o Android para uma plataforma embarcada

Camada HAL

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.

✗ A camada HAL é normalmente implementada pelo fabricante ou pelo OSAP através de bibliotecas compartilhadas (*.so).

Embedded Labworks

A CAMADA HAL (cont.)

Kernel Linux

Driver

HAL (*.so)

HW Service

System Server

android.*

Aplicações

Kernel space

User space

C

Java

Embedded Labworks

EXEMPLO HAL AUDIO

Fonte: http://source.android.com

Embedded Labworks

LISTAGEM DA CAMADA HAL

✗ O local padrão para colocar as bibliotecas de implementação da camada HAL é o diretório /system/lib/hw, e o nome da biblioteca tem o formato <hal>.<device>.so.

# ls /system/lib/hw/                                          audio.a2dp.default.so audio.primary.default.soaudio.primary.imx6.so audio.r_submix.default.soaudio_policy.default.so bluetooth.default.socamera.goldfish.so camera.imx6.sogps.goldfish.so gralloc.default.sogralloc.imx6.so gralloc_viv.imx6.sohwcomposer.imx6.so hwcomposer_viv.imx6.sokeystore.default.so lights.goldfish.solights.imx6.so local_time.default.sopower.default.so power.imx6.sosensors.WANDBOARD.so sensors.goldfish.so

Embedded Labworks

LISTAGEM DAS CAMADAS HAL

✗ audio.primary.<device>.so: camada de áudio, normalmente implementado via camada ALSA do kernel.

✗ gralloc.<device>.so/hwcomposer.<device>.so: camada de vídeo.

✗ camera.<device>.so: acesso à câmera, normalmente (mas não necessariamente) implementado via camada V4L.

✗ gps.<device>.so: acesso ao GPS, normalmente via serial (tty).

✗ libril.so: acesso ao rádio (voz e dados).

Embedded Labworks

LISTAGEM DAS CAMADAS HAL (cont.)

✗ bluetooth.<device>.so: acesso à interface Bluetooth (até a versão 4.1 usava-se o BlueZ, agora usa-se o bluedroid da Broadcom.

✗ nfc.<device>.so: acesso à interface de comunicação NFC.

✗ lights.<device>.so: controle de LEDS, backlight, etc.

✗ sensors.<device>.so: acesso à sensores (acelerômetro, giroscópio, magnetômetro, pressão, proximidade, temperatura, etc).

✗ power.<device>.so: responsável pelo gerenciamento de energia.

Embedded Labworks

IMPLEMENTANDO A CAMADA HAL

✗ Implementar uma camada HAL é trabalhoso e envolve conhecer o funcionamento interno dos serviços providos pelo framework do Android.

✗ Por este motivo, se possível, escolha um dispositivo que já possui suporte à camada HAL do Android.

✗ Caso não seja possível, você precisará estudar o funcionamento da camada HAL e ler muito código!

✗ Uma visão geral da camada HAL esta documentada no link abaixo:http://source.android.com/devices/index.html

Embedded Labworks

IMPLEMENTANDO A CAMADA HAL (cont.)

✗ A implementação da camada HAL pode ser encontrada no AOSP em hardware/. Em específico, as definições das interfaces encontram-se em:✗ hardware/libhardware/include/hardware/

✗ hardware/libhardware_legacy/include/hardware_legacy/

✗ Uma implementação padrão da camada HAL esta disponível em hardware/libhardware/modules.

✗ O AOSP inclui o suporte à hardware para alguns dispositivos de mercado, que pode ser usado como ponto de partida para novas implementações. Veja o diretório device/ para alguns exemplos.

Embedded Labworks

OUTROS ACESSOS

✗ Nem todo acesso ao hardware necessita de uma camada HAL, por exemplo:

✗ Dispositivos de input (botões, mouse, teclado) são acessados diretamente via /dev/input/.

✗ Dispositivos de rede são acessados normalmente via interface de rede através de uma conexão via socket com o daemon netd.

✗ Dispositivos de armazenamento (cartão SD) são acessados diretamente via system calls através de uma conexão via socket com o daemon vold.

✗ O serviço de Vibrator acessa diretamente via camada nativa a interface de GPIOs no /sys.

Embedded Labworks

RESUMO

✗ Em resumo, o que você precisa fazer para portar o Android para uma plataforma embarcada:

✗ Portar o bootloader, de preferência com suporte ao fastboot.

✗ Portar o kernel Linux com os patches do Android.

✗ Criar um produto no AOSP e customizar para a sua plataforma.

✗ Desenvolver e integrar as camadas HAL.

✗ Sempre que possível, escolha um fabricante que tenha o suporte ao Android!

Embedded Labworks

LINKS

✗ Android Open Source Project:https://source.android.com/

✗ Android Developer:https://developer.android.com/

✗ Android Tools Project Site:http://tools.android.com/

Embedded Labworks

LINKS (cont.)

✗ Linaro Android:https://wiki.linaro.org/Platform/Android

✗ Embedded Linux Wiki - Android Session:http://www.elinux.org/Android_Portal

✗ Android Builder's Summit Videos:http://video.linux.com/

Embedded Labworks

LIVROS

Embedded AndroidKarim Yaghmour

Programming AndroidZigurd Mednieks & cia

Embedded Labworks

TREINAMENTO ANDROID EMBARCADO

EM BREVE!

Embedded Labworks

Por Sergio Prado. São Paulo, Agosto de 2013® Copyright Embedded Labworks 2004-2013. All rights reserved.

OBRIGADO!

E-mail sergio.prado@e-labworks.comWebsite http://e-labworks.com