Android

23 jun, 2017

O poder do Android Things além da GPIO e PWM

Publicidade

O ano de 2017 marcou o lançamento da plataforma Android Things, que promete trazer todo o conhecimento, ferramentas, bibliotecas, arquitetura e ideologia do desenvolvimento Android usados em smartphones e similares para plataformas de sistemas embarcados, como o Intel Edison.

Neste artigo, não pretendo falar sobre as bibliotecas, sobre a codificação ou, ainda, entrar em detalhes de como podemos usar o Firebase no Intel Edison. A ideia neste texto é passar minha visão sobre o poder do Google/Android Things no contexto da Internet das Coisas, mostrar o poder que nós, desenvolvedores, temos em mãos, conhecendo o ecossistema do desenvolvimento para a plataforma Android.

O primeiro ponto diz respeito ao coração da aplicação Android. O AndroidManifest está presente no desenvolvimento do Android Things e com o mesmo papel de protagonista. A diferença sutil é a presença de um filtro específico para o IOT_LAUNCHER. Ou seja, o conceito de Intent e Intent Filter, herdado do Android “Normal”, segue presente também.

Apenas para elucidar o leitor, veja a pequena alteração no AndroidManifest.xml:

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
   package="agora.humano.seja.com.helloworldthings" >

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

</manifest>

A Intent define a intenção de uma ação disparada de/para o sistema operacional Android. Sendo assim, o Intent Filter é justamente um filtro dessa ação. A categoria LAUNCHER, já conhecida dos desenvolvedores, define que o ponto de partida da aplicação móvel é aquela activity. Logo, o IOT_LAUNCHER tem exatamente a mesma função. A plataforma embarcada, como o Intel Edison, sabe qual atividade vai iniciar os trabalhos no momento em que a aplicação Android for executada.

Olhando o manifesto, notamos a presença da já conhecida Activity. No desenvolvimento Android para smartphone, ela tem a função de representar uma tela e seu contexto. Aqui, temos a ideia de uma atividade. Mas o mais importante é que todo o ciclo de vida de uma Activity e toda a Activity Stack são reaproveitados no Android Things.

O SDK do Android Things ganhou o incremento de algumas bibliotecas e classes de suma importância para o contexto da plataforma, como a classe PeripheralManagerService, que permite requisitar todas as portas a que temos acessos naquele hardware. Ou, ainda, a classe GPIO, que pode fazer a ligação com um LED RGB, por exemplo, ou com um relê que ligaria a lâmpada da sua casa. Tudo isso de forma muito simples.

Abaixo, segue um exemplo muito simples de como um LED ligado na porta digital 6 do Edison Arduino pode ser ligada. Ou, ainda, esse simples LED poderia muito bem ser substituído por um relê que ligaria uma tomada da nossa residência.

public class MainActivity extends AppCompatActivity {

   private Gpio ledGpio;
   private static final String GPIO_PIN = "IO13";

   @Override
   protected void onCreate(Bundle savedInstanceState) {
       super.onCreate(savedInstanceState);
       PeripheralManagerService service = new PeripheralManagerService();

       try {
           ledGpio = service.openGpio(GPIO_PIN);
           ledGpio.setValue(true);
       } catch (IOException e) {
           Log.e("GPIOS", "Error on PeripheralIO API", e);
       }
   }
}

Para um desenvolvedor experiente da plataforma Android, é quase inacreditável saber que todo o conhecimento poderá ser replicado para o mundo IoT. O único ponto de dúvida talvez seja a variável GPIN_PIN valorizada com IO13, sendo que, na descrição do parágrafo anterior, citei a porta digital 6.

Um ponto de atenção no Android Things é justamente o nome das portas que estaremos trabalhando. Mas, na documentação oficial, é possível selecionar a plataforma alvo e saber os nomes de todas as portas que devem ser usadas. Por exemplo, para o Intel Edison Arduino I/O, a seguinte imagem é encontrada (https://developer.android.com/things/hardware/edison-arduino-io.html):

Aliado ao poder da simplicidade e reutilização do conhecimento, podemos citar as bibliotecas do SDK que estarão presentes nas plataformas alvos do Android Things. Até o momento da escrita deste artigo, são elas: Intel Edison, Intel Joule, NXP Pico i.MX6UL e Raspberry Pi 3.

E veja agora as APIs suportadas pelo Android Things até o momento da escrita deste texto:

Ficou impressionado com as opções? Acredito fielmente que sim. Somente o set de opções do Firebase já seria muito valoroso. Agora, um desenvolvedor maker não precisa mais trabalhar com bibliotecas de comunicação serial ou Wi-Fi. Não precisa mais pensar no servidor de banco de dados NoSQL que receberá uma quantidade significativa de dados de sensores. O Firebase resolve isso da mesma forma simplista que resolve para smartphones.

E parece que os planos do Google para uma interligação de todas as coisas possíveis não param no Android Things. Um kit de desenvolvimento para o projeto Soli será lançado ainda este ano pela empresa. O Soli compreende um micro-radar de onda milimétrica que consegue interceptar e detectar gestos muito sutis como aqueles que fazemos com os dedos e as mãos. Para saber mais, navegue pela página do projeto aqui https://atap.google.com/soli/.

E ainda temos o Android Auto e o Android Wear. O primeiro chegou às terras brasileiras na primeira metade do ano passado. O Android Wear já é um velho conhecido. Mas o que importa é que o Android SDK e os principais pilares do desenvolvimento para smartphone são mantidos tanto para carros quando para vestíveis.

Ou seja, uma vez que o programador esteja apto a desenvolver para a plataforma Android, um mundo se abre aos seus dedos. E não estamos falando só de smartphones e tablet e seus bilhões de usuários, mas sim de plataformas embarcadas, sensores que detectam pequenos movimentos de mãos e dedos, automóveis e vestíveis.

E, para fechar o ciclo, é importante ressaltar que não é somente a filosofia de desenvolvimento que é compartilhada. O Google Play Services e o Firebase, que aceleram o desenvolvimento com APIs especializadas para features extremamente comuns, como mapas, banco de dados e push notifications, também são compartilhados. Difícil imaginar todas as possibilidades possíveis.