Em 2011, no Google I/O, foi lançado o ADK (Accessory Developer Kit), um hardware baseado no Arduino que possui como chamariz um protocolo (Android Open Accessory Protocol) específico para troca de dados entre a plataforma de prototipagem e o smartphone com Android.

A sua primeira versão é mostrada na figura abaixo. Essa versão foi criada com o molde do Arduino Mega. Na parte superior, encontra-se um shield com alguns sensores e atuadores em anexo. Alguns deles são: transistores e relês, sensor de temperatura, sensor de luz, leds coloridos e um sensor no estilo joystick. Na primeira versão do protocolo, o Android suportado era o 3.1 e superiores.

No ano seguinte, o Google I/O apresentou a nova versão do ADK, mostrada na figura abaixo. Além das mudanças claras no hardware, que não seguia mais o padrão Arduino, houve alterações no protocolo AOA.

Seguindo seu hardware base, o ADK também é open hardware. Sendo assim, surgiram diversas versões do Arduino/ADK não oficiais do Google, mas que atendiam aos requisitos do protocolo AOA. Logo abaixo, temos dois exemplos de destaque.

À esquerda, temos o ADK da Seeed Studio, uma importante fabricante de hardware, como arduinos, sensores e atuadores. À direita, temos o Iteaduino, uma versão com uma brincadeira bem clara em relação à rivalidade Android x iOS:

ADK Seeed Studio

ADK Iteaduino

A codificação para uso do ADK envolve duas partes. No sketch, que é codificado para o Arduino, é necessário identificar alguns dados do acessório construído; dessa forma, ele se tornará único e poderá ser reconhecido de forma singular pelo smartphone Android. Abaixo, um exemplo desse trecho de código:

#include <AndroidAccessory.h>  
AndroidAccessory acc("Fabricande", "Modelo", "Descrição", "Versão", "URI", "Serial");

void loop(){}
void setup(){}

No lado do Android, é necessário definir essas mesmas informações em um arquivo XML (Extensible Markup Language). Além disso, no manifesto é criado um Intent Filter para interceptar o evento de conectividade de um ADK na porta serial do smartphone.

Nesse mesmo filtro, também é definido o XML que detalha de forma única qual acessório exato é esperado. Veja um trecho de código que exemplifica isso. Essa codificação era apenas para as partes se conhecerem. Posteriormente, era feita a troca de dados entre ambos, através do protocolo AOA.

<activity ... >
    <intent-filter ...>
    <meta-data                 
         android:name="android.hardware.usb.action.USB_ACCESSORY_ATTACHED"
         android:resource="@xml/accessory_filter" />
</activity>

//res->xml->accessory_filter
<resources>
<usb-accessory manufacturer="Fabricante" model="Modelo" version="Versao" />
</resources>

Porém, o ADK não teve continuidade por parte do próprio Google. Versões do hardware continuaram a ser criadas por outras empresas, mas não tivemos um ADK 2013 ou 2014, por exemplo. Outra prova desse abandono é a falta de documentação sobre essa plataforma de hardware no developer.android.com, principal fonte de documentação para desenvolvedores Android. Isso tudo tem uma resposta fácil. O Google voltou-se para o Android Things.

O Android Things trouxe o sistema operacional Android para plataformas de desenvolvimento System-on-Modules (SoMs). A lista de produtos homologados e que suportam o Android Things é dinâmica.

Quando ouvi falar sobre essa tecnologia, corri para o site de desenvolvedores do Google e vi que o Intel Edison era uma das plataformas suportadas. Felizmente, tinha um em casa e o testei com sucesso.

Quando soube que o Raspberry Pi também estava na lista, comprei o novo Raspberry Pi Zero. Porém, depois do anúncio do novo Android Things 1.0, a lista de plataformas suportadas retirou o Edison, e percebi que somente o Raspberry Pi 3 Model B é suportado.

Uma das novidades na nova versão é um console semelhante ao que temos no Firebase, por exemplo. Dentre outras facilidades, como controle em tempo real dos dispositivos com seus projetos IoT, o console nos fornece download de uma ferramenta chamada de Android Things Setup Utility.

Esse zip, ao ser descompactado, oferece um utilitário para Mac, Windows e Linux, capaz de configurar a imagem corretamente em um mini SDCard. Este, por sua vez, irá no slot do Raspberry Pi e será justamente seu sistema operacional.

Veja na imagem abaixo o screenshot desse utilitário no console do Android Things.

Esse utilitário o guiará no processo de gravação do SDCard. Depois de finalizado, é possível conectar o Raspberry Pi à sua rede Wi-Fi, caso o leitor possua o dongle Wifi para isso. Ou, ainda, é possível conectar diretamente um cabo RJ-45 na entrada correspondente, existente no Raspberry. No meu caso, parti para essa opção.

Depois de conectado, precisamos saber o IP do Raspberry, para que possamos enviar o programa para ele e também visualizar seu sistema operacional em execução. Como não tenho aparelho de televisão há mais de 10 anos, não podia escolher a opção de simplesmente usar um cabo HDMI, como é de praxe.

Sendo assim, entrei nas configurações do meu roteador e consegui encontrar qual o IP que o DHCP entregou para o Raspberry Pi.

De posse do IP, basta digitar o comando:

adb connect <ip>

Ao conectar, algumas ferramentas de espelhamento de tela, como o Vysor, já o reconhecem. Sendo assim, podemos visualizar o Android Things rodando, em tempo real, na interface gráfica do hardware alvo. No meu caso, passo a ver o sistema operacional que está rodando no Raspberry Pi. Veja na imagem abaixo um screenshot:

Depois dessa conexão, também é possível usar a IDE Android Studio para programar o Raspberry Pi (ou qualquer uma das outras plataformas suportadas). Basta seguir o fluxo normal de criação de uma nova aplicação Android, mas é preciso atentar para escolha da plataforma Android Things na segunda tela do wizard, como mostra a figura abaixo:

Aqui vem o mais surpreendente: o desenvolvedor que já programa para Android vai reutilizar praticamente todo o seu conhecimento para programar para o Android Things. Existem apenas duas peculiaridades que vejo como relevantes em um primeiro momento. A primeira delas é no manifesto da aplicação (veja no trecho de código abaixo).

Temos uma nova permissão de usuário para acessar os periféricos do Raspberry Pi através de suas portas GPIO. Temos uma nova biblioteca de usuário, definida na tag uses-library, além de um filtro novo para a activity, o IOT_LAUNCHER.

<uses-permission
   android:name="com.google.android.things.permission.USE_PERIPHERAL_IO"/>

<application>
   <uses-library android:name="com.google.android.things" />

   <activity android:name=".MainActivity">
       <intent-filter>
           <action android:name="android.intent.action.MAIN" />

           <category android:name="android.intent.category.LAUNCHER" />
       </intent-filter>
       <intent-filter>
           <action android:name="android.intent.action.MAIN" />

           <category android:name="android.intent.category.IOT_LAUNCHER" />
           <category android:name="android.intent.category.DEFAULT" />
       </intent-filter>
   </activity>
</application>

O segundo ponto é justamente a API para trabalhar com os periféricos e, mais importante, saber como trabalhar com eles. Por exemplo, no Raspberry Pi 3 Model B, temos uma representação gráfica dos nomes que cada GPIO recebe. Veja na figura abaixo:

Sendo assim, se desejarmos acender um LED, vamos utilizar um GPIO de terra e a outra entrada pode se um PWM. Logo, podemos ver a entrada da energia do LED no GPIO numerado com 33 e nomeado com BCM13.

E, no código da aplicação Android, usaremos a classe PeripheralManager para controlar justamente essas portas. Veja como ficaria esse trecho de código no Android:

PeripheralManager service = PeripheralManager.getInstance();
try {
   mLedGpio = service.openGpio("BCM13");
   mLedGpio.setDirection(Gpio.DIRECTION_OUT_INITIALLY_LOW);
   mLedGpio.setValue(true);
} catch (IOException e) {
   Log.e(TAG, "Error on PeripheralIO API", e);
}

Pronto. Com isso, o desenvolvedor Android passa a programar para Rasberry Pi, Pico i.MX7D I/O e outras plataformas System On Chip. A reutilização de conhecimento já adquirido é fantástica. O console que temos para o Android Things eleva o nível de controle de nossos produtos para um patamar bem alto.

Sendo assim, agora é imaginar seus produtos para Internet of Things e pôr a mão na massa!

***

Artigo publicado na revista iMasters, edição #27: https://issuu.com/imasters/docs/imasters_27_issuu