Portando o Android para uma plataforma embarcada
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

Portando o Android para uma plataforma embarcada

  • 1,441 views
Uploaded on

Slides da apresentação realizada no ESC Brazil 2013. ...

Slides da apresentação realizada no ESC Brazil 2013.

Resumo: Portar o Android para uma plataforma embarcada exige conhecimentos diversos do sistema operacional, incluindo o kernel Linux, a camada HAL e a integração com o framework de aplicações do Android. Durante a apresentação, diversos tópicos serão abordados, visando cobrir as principais atividades do desenvolvedor que pretende portar o Android para uma plataforma embarcado: visão geral dos componentes do Android e o processo de boot, sistema de build do Android, hands-on baixando os fontes e compilando, principais alterações no kernel Linux, compilando o Linux com suporte ao Android, diretórios e sistema de arquivos do Android, desenvolvendo a camada HAL e adicionando o suporte a determinado hardware no sistema operacional (exemplo em uma plataforma ARM), desenvolvimento nativo e JNI, máquina virtual e system services, debugging com Android.

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
1,441
On Slideshare
1,441
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
61
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Portando o Android para uma plataforma embarcada Embedded Labworks Por Sergio Prado. São Paulo, Agosto de 2013 ® Copyright Embedded Labworks 2004-2013. All rights reserved.
  • 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://sergioprado.org/palestras/escbrazil2013
  • 3. 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
  • 4. 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
  • 5. Embedded Labworks Portando o Android para uma plataforma embarcada Introdução
  • 6. 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.
  • 7. 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.3 (Gingerbread) ✗ 3.0/3.1/3.2 (Honeycomb) ✗ 4.0 (Ice Cream Sandwich) ✗ ✗ 2.2 (Frozen Yogurt) 4.1/4.2/4.3 (Jelly Bean) Esta apresentação é baseada no Jelly Bean 4.2.
  • 8. 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).
  • 9. 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.
  • 10. 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.
  • 11. 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).
  • 12. Embedded Labworks ARQUITETURA LINUX EMBARCADO Aplicação Sistema GNU/Linux Biblioteca Aplicação Biblioteca Biblioteca C (glibc, eglibc, uclibc, etc) Linux kernel Bootloader Hardware
  • 13. Embedded Labworks ARQUITETURA ANDROID Aplicação Plataforma Android Aplicação Aplicação Aplicação Framework (serviços e API) Camada nativa (bibliotecas, daemons e ferramentas) Linux kernel Bootloader Hardware
  • 14. Embedded Labworks DIAGRAMA DE BLOCOS ANDROID Fonte: http://source.android.com
  • 15. 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.
  • 16. Embedded Labworks Portando o Android para uma plataforma embarcada Hardware, bootloader e kernel
  • 17. Embedded Labworks HARDWARE TÍPICO COM ANDROID Fonte: http://www.opersys.com/
  • 18. 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.
  • 19. 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.
  • 20. 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).
  • 21. 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/
  • 22. 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).
  • 23. 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.
  • 24. 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.
  • 25. 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.
  • 26. 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.
  • 27. 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
  • 28. 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.
  • 29. Embedded Labworks Portando o Android para uma plataforma embarcada Plataforma Android
  • 30. Embedded Labworks PLATAFORMA ANDROID Aplicações API Android API Bibliotecas Java Binder System Services Dalvik Runtime JNI Init Toolbox Daemons nativos Bibliotecas (bionic, etc) Linux Kernel HAL
  • 31. 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.
  • 32. 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.
  • 33. 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.
  • 34. 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.
  • 35. 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: ✗ ✗ Classes Java do projeto Apache Harmony. ✗ ✗ System Services. Android API. Todo o framework Android se comunica com a camada nativa via JNI (Java Native Interface).
  • 36. 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 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: [] [...]
  • 37. 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);
  • 38. Embedded Labworks SYSTEM SERVICES E O BINDER Service Manager Aplicação System Server Power Manager Activity Manager Mount Service ... 4 3 1 2 Binder driver (/dev/binder)
  • 39. 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.
  • 40. 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>
  • 41. Embedded Labworks EXECUTANDO ACTIVITY DO TIPO BROWSER Intent i = new Intent(Intent.ACTION_VIEW,                       Uri.parse("http://www.sergioprado.org")); startActivity(i);
  • 42. Embedded Labworks INICIALIZAÇÃO (VERSÃO SIMPLIFICADA) Launcher System Server Activity Manager start(launcher) Java Zygote init.rc init app_process Kernel Linux C/C++
  • 43. Embedded Labworks Portando o Android para uma plataforma embarcada Sistema de build
  • 44. 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.
  • 45. Embedded Labworks REPO $ repo init ­u https://android.googlesource.com/platform/manifest $ repo sync [...] Alguns dias depois... $ ls abi       dalvik       frameworks       Makefile  prebuilts bionic    development  gdk              ndk       sdk bootable  device       hardware         out       system build     docs         libcore          packages cts       external     libnativehelper  pdk
  • 46. 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.
  • 47. 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).
  • 48. 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]
  • 49. Embedded Labworks COMPILANDO $ make [...] Mais alguns dias depois... $ ls out/target/product/generic/ android­info.txt        installed­files.txt       system clean_steps.mk          obj                       system.img data                    previous_build_config.mk  test dex_bootjars            ramdisk.img               userdata.img hardware­qemu.ini       root                      userdata­qemu.img hardware­qemu.ini.lock  symbols                   userdata­qemu.img.lock
  • 50. Embedded Labworks IMAGENS E PARTIÇÕES Bootloader Kernel Linux Read-only raw Initrd (ramdisk.img) / System (system.img) /system Data (data.img) /data Cache /cache Sdcard /sdcard Read-write
  • 51. 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.
  • 52. 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.
  • 53. 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_superdroid PRODUCT_DEVICE := superdroid PRODUCT_MODEL := Super Android robot
  • 54. Embedded Labworks AndroidProducts.mk PRODUCT_MAKEFILES :=  $(LOCAL_DIR)/full_superdroid.mk
  • 55. Embedded Labworks BoardConfig.mk TARGET_NO_KERNEL := true TARGET_NO_BOOTLOADER := true TARGET_ARCH := arm TARGET_ARCH_VARIANT := armv7­a TARGET_CPU_ABI := armeabi BOARD_USES_GENERIC_AUDIO := true USE_CAMERA_STUB := true
  • 56. Embedded Labworks vendorsetup.sh add_lunch_combo full_superdroid­eng
  • 57. 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.
  • 58. Embedded Labworks Portando o Android para uma plataforma embarcada Camada HAL
  • 59. 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).
  • 60. Embedded Labworks A CAMADA HAL (cont.) Aplicações android.* System Server HW Service Java C HAL (*.so) User space Kernel space Driver Kernel Linux
  • 61. Embedded Labworks EXEMPLO HAL AUDIO Fonte: http://source.android.com
  • 62. 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.so audio.primary.imx6.so audio.r_submix.default.so audio_policy.default.so bluetooth.default.so camera.goldfish.so camera.imx6.so gps.goldfish.so gralloc.default.so gralloc.imx6.so gralloc_viv.imx6.so hwcomposer.imx6.so hwcomposer_viv.imx6.so keystore.default.so lights.goldfish.so lights.imx6.so local_time.default.so power.default.so power.imx6.so sensors.WANDBOARD.so sensors.goldfish.so
  • 63. Embedded Labworks LISTAGEM DAS CAMADAS HAL ✗ ✗ ✗ audio.primary.<device>.so: camada de implementado via camada ALSA do kernel. áudio, normalmente 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).
  • 64. 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.
  • 65. 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
  • 66. 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.
  • 67. 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.
  • 68. Embedded Labworks RESUMO ✗ Em resumo, o que você precisa fazer para portar o Android para uma plataforma embarcada: ✗ ✗ Portar o kernel Linux com os patches do Android. ✗ Criar um produto no AOSP e customizar para a sua plataforma. ✗ ✗ Portar o bootloader, de preferência com suporte ao fastboot. Desenvolver e integrar as camadas HAL. Sempre que possível, escolha um fabricante que tenha o suporte ao Android!
  • 69. 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/
  • 70. 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/
  • 71. Embedded Labworks LIVROS Embedded Android Karim Yaghmour Programming Android Zigurd Mednieks & cia
  • 72. Embedded Labworks TREINAMENTO ANDROID EMBARCADO EM BREVE!
  • 73. OBRIGADO! E-mail Website sergio.prado@e-labworks.com http://e-labworks.com Embedded Labworks Por Sergio Prado. São Paulo, Agosto de 2013 ® Copyright Embedded Labworks 2004-2013. All rights reserved.