O Android Things é uma versão customizada do Android para sistemas embarcados, com foco em aplicações de IoT.

Possui diversas semelhanças com o Android porque a arquitetura do sistema operacional é a mesma, boa parte da API do Android está disponível no Android Things e todo o desenvolvimento continua sendo feito no Android Studio, permitindo nos beneficiar de todo o ecossistema de ferramentas e recursos do Android, além da imensa comunidade de desenvolvedores.

Por outro lado, é diferente porque algumas APIs não estão disponíveis e outras foram desenvolvidas exclusivamente para o Android Things, além do sistema operacional ter sido customizado para rodar aplicações no modo standalone, com controle total do hardware.

Através da imagem abaixo, disponível na documentação oficial do Android Things, podemos ver que a arquitetura do sistema operacional continua basicamente a mesma. As aplicações Android (ou Android Things) se comunicam com o framework Java através da API, que utiliza um mecanismo de IPC chamado Binder para se comunicar com os serviços do framework, que por sua vez acessa o hardware através de uma camada de abstração (HAL). Se quiser entender melhor a arquitetura interna do Android, dê uma olhada nos artigos “Introdução ao funcionamento interno do Android” e “Entendendo o processo de boot do Android” (um pouco antigos mas de forma geral ainda válidos).

Mas as semelhanças param por aí, a começar pelo Things Support Library, o bloquinho em laranja no diagrama acima.

Comparado com dispositivos móveis, sistemas embarcados tem um relacionamento muito mais próximo com o hardware. Por este motivo, o Android Things estende o framework Java do Android com algumas APIs específicas para periféricos não encontrados em dispositivos móveis, incluindo GPIO, PWM, I2C, SPI e UART.

Por exemplo, o método abaixo utiliza a API de GPIO do Things Support Library para acionar um pino de I/O da placa:

1
2
3
4
5
6
7
8
9
10

public void configureOutput(Gpio gpio) throws IOException {
    try {
        PeripheralManagerService manager = new PeripheralManagerService();
        Gpio gpio = manager.openGpio(IO17);
        gpio.setDirection(Gpio.DIRECTION_OUT_INITIALLY_HIGH);
        gpio.setValue(true);
    } catch (IOException e) {
        Log.w(TAG, "Unable to access GPIO", e);
    }
}

A documentação das APIs de acesso aos periféricos está disponível no site oficial do projeto.

O Things Support Library também possui uma API para desenvolver um device driver em espaço de usuário. Imagine que você tenha um GPS conectado a uma porta serial, ou um acelerômetro conectado ao barramento I2C. Esta API permite que você implemente um serviço capaz de injetar eventos de hardware no framework, que podem ser consumidos por outras aplicações. Isso basicamente substitui a necessidade de desenvolver um driver no kernel e/ou uma HAL.

A documentação da API de desenvolvimento de drivers em user space está disponível no site do projeto.

Por fim, outra grande diferença é que o Android Things é customizado para a execução de uma única aplicação.

Para quem já precisou customizar o Android e executar uma aplicação de forma isolada (kiosk mode), removendo componentes do sistema operacional como a barra notificação e os botões de navegação, sabe das dificuldades.

No Android Things, sua aplicação executa de forma isolada. Não existem notificações, e por isso não existe a necessidade de uma barra de notificações. Não existem também os botões de navegação, deixando a aplicação com controle total da interface gráfica. Isso se o dispositivo tiver um display, porque o Android Things não exige um sistema com interface gráfica, permitindo construir aplicações headless. E tem uma lista grande de aplicações de exemplo no site do projeto.

Gostei! Onde eu baixo o código-fonte?

Não baixa. No donuts for you! :(

O Google decidiu, pelo menos por enquanto, manter a plataforma do Android Things fechada e sob seu controle. No momento, são sete as plataformas de hardware suportadas e homologadas pelo Google para rodar o Android Things, incluindo a Raspberry Pi 3 e alguns kits de desenvolvimento baseados no i.MX da NXP. A lista completa de plataformas de hardware suportadas está disponível no site do projeto.

Isso significa que está disponível apenas uma imagem pré-compilada do sistema operacional para as plataformas de hardware homologadas pelo Google. E se você quiser construir um hardware customizado para rodar o Android Things, precisará iniciar um processo de desenvolvimento e homologação do seu hardware em conjunto com o Google.

O Google criou uma interface Web chamada Android Things Console para gerenciar as imagens do Android Things para as plataformas de hardware suportadas. E até que esta interface de gerenciamento é interessante. No primeiro acesso, devemos criar um produto, selecionando a plataforma de hardware que iremos utilizar, dentre as plataformas de hardware suportadas oficialmente pelo projeto:

Depois teremos acesso a uma console para gerenciar as imagens do nosso produto. Esta interface permite construir e baixar a imagem do Android Things, adicionar à imagem um Bundle (conjunto de aplicações que irão compor o nosso produto), além de ser capaz de gerenciar automaticamente o processo de atualização remota (OTA). Por exemplo, se atualizarmos nossa aplicação (Bundle) no servidor do Google, um serviço no Android Things irá identificar e realizar a atualização automaticamente no dispositivo de hardware.

Se este projeto vai dar certo não sabemos.

Um problema que vejo está relacionado aos requisitos de hardware necessários para rodar o Android Things. Se analizarmos as plataformas de hardware oficialmente suportadas, temos placas com múltiplos núcleos de CPU, 512MB+ de RAM e 4GB+ de armazenamento. Por mais que o custo do hardware tenha diminuido nos últimos anos, não precisamos de tudo isso para controlar as luzes de uma residência ou abrir o portão da garagem, certo? Por este motivo, talvez devemos visualizar o Android Things como uma solução de gateway para IoT, e não como uma solução para a ponta (nó IoT).

Além disso, o fato do projeto ser fechado e controlado pelo Google, pelo menos enquanto escrevo este artigo, me deixa com um pé atrás. O que faz do Android um sucesso, incluindo seu uso em diversas soluções de sistemas embarcados, é o fato do código-fonte estar disponível. É difícil escalar um projeto fechado como o Android Things, e não vejo como ele evoluir para suportar milhares de dispositivos, criando um bom ecossistema de fornecedores, fabricantes, usuários e entusiastas que justifique o uso do sistema operacional.

E se o projeto não evoluir, pode ter o mesmo fim que seu antecessor, o Brillo. É esperar para ver.

Um abraço,

Sergio Prado