Introdução

A indústria automotiva (FIAT, GM, Toyota, …) está cada vez mais pressionada a produzir o mais rápido possível novas funcionalidades para seus sistemas embarcados. A escolha do Android como plataforma de desenvolvimento em detrimento de seus concorrentes diretos (QNX e Windows Embedded Automotive) pode ser justificada através dos custos para adoção, seu código aberto e a existência de um conjunto de bibliotecas de suporte já funcionais, facilitando assim a tarefa de construção de novas aplicações.

Escolher um produto já testado e preparado para o mercado faz com que os produtos finais também possam usufruir de tal estabilidade de consequente qualidade. Além disso, o reaproveitamento do código traz além de redução no tempo dos produtos até o mercado uma redução de custos.

    Ambiente Automotivo

A aplicação do framework Android em automóveis pode ser encarada como uma tarefa árdua, visto que tal sistema operacional não possui seu foco nesse tipo de ambiente. Entre outros fatores técnicos, os primordiais são o tempo de resposta e o gasto energético. Esses podem influir de forma substancial na possibilidade – ou não – do uso da plataforma. Para que o resultado final seja aceitável é necessário que sejam executadas alterações no código-fonte como forma de adaptação a um hardware e ambientes específicos.

Particularmente, uma variável de suma importância é o tempo de inicialização da plataforma. Essa por sua vez irá reger entre outras coisas o nível de interatividade do sistema. Ainda, quanto mais rápida for a inicialização do Android, uma menor quantidade de informações do automóvel deixarão de ser tratadas – ou perdidas.

Reduzir o tempo de inicialização de qualquer sistema operacional não é uma tarefa simples. Normalmente otimiza-se diferentes porções e módulos de código, garantindo assim que globalmente o tempo seja reduzido.

Aqui consideramos melhorias em dois dos principais pontos da plataforma Android: Kernel Linux e camada de aplicação. Além disso, consideramos ainda uma melhoria no modo que informações de contexto são recuperadas do automóvel pelas aplicações nativas do sistema operacional.

    Componentes e Arquitetura

Como uma forma de melhor entendimento do problema, abaixo listamos os componentes principais da plataforma.

    Componentes de Hardware

1 – Veículo;

2 – Computador de bordo Android;

3 – Coletor de dados de sensores; e

4 – Bateria.

A ligação e interação entre todos esses componentes é dada como no diagrama apresentado pela figura abaixo.

De forma resumida, o computador de bordo Android é ligado a um coletor de dados/sinais do veículo e ambos alimentados sob uma tensão de 12v vinda da bateria. O coleto de dados/sinais fica responsável pelo rastreamento e obtenção dos dados de contexto do automóvel.

    Componentes de Software

Além de uma arquitetura específica para a construção da aplicação Android, algumas decisões de projeto foram tomadas:

a) Envio/recebimento de dados de/para o coletor de dados em um intervalo “sempre” menor que 0.5s;

b) Organização e tratamento das informações recebidas através de uma estrutura FIFO; e

c) Tratamento de informações críticas para o veículo diretamente na camada nativa do Android como forma de otimização da aplicação final.

A figura abaixo exemplifica de forma geral a arquitetura implementada durante o projeto. As duas camadas fazem referência somente aos elementos de software considerados na otimização.

      Otimizações Efetuadas

Abaixo segue uma descrição das otimizações executadas na plataforma Android de modo a melhorar o desempenho de inicialização da mesma.

1) Kernel:

– Remoções: Ícone de splash screen; Controladores de dispositivos (device drivers) desnecessários a plata- forma. Em um segundo momento, controladores de funcionalidades de baixa prioridade passaram a ser carregados como módulos; Suporte ao debug e profiling (OProfile, KGDB, etc); Funcionalidade de anonymous swap: O aumento no número de fluxos de execução (threads) causado pelo mesmo pode acarretar em uma degradação nas operações de E/S e paginação; Suporte ao hot-plugging, uma vez que não será utilizado; Na versão final, todas as opções de debug e mensagens de log. Entretanto, devido ao uso de tais mensagens como forma de se obter as marcações de tempo, a seção VIII não contempla tais melhorias; Suporte a RAID, SCSI, LVM e IDE [8]: Plataforma não fará uso de dispositivos deste tipo;

– Outras: Calibração manual da variável lpj (loops per jiffies): Se não preenchida manualmente seu cálculo leva determinado tempo durante a inicialização; Armazenamento do kernel já descompactado em memória flash (NAND). Ganho no tempo de carregamento, uma vez que a descompactação não precisa ocorrer; Redução no nível de mensagens de log do sistema.

2) Espaço de Usuário (Android):

– Remoções: Animação durante o boot; Aplicações (.apk) nativas da plataforma. Quanto menor o número de aplicações, menor o tempo necessário para iniciar cada uma; Serviços não utilizados pela plataforma dentro do componente nativo SystemServer; Verificações de consistência nas chamadas nativas executadas pelo JNI (variável de ambiente ro.kernel.android.checkjni); Suporte e acesso ao serviço de console, uma vez que esse não foi utilizado; Na versão final da aplicação automotiva as opções de debug e log também foram removidas.

– Outras: Redução no nível de logs do sistema; Ajustes na parte de pré-carga das classes: Durante a carga do Android é executado um pré-carregamento de todas as classes Java a serem utilizadas pela plataforma. Devido ao número reduzido de aplicações que consideramos, a grande maioria dos componentes de tal arquivo puderam ser removidos; Alteração do arquivo de inicialização do sistema (init.rc) de forma que contivesse somente os serviços e inicializações estritamente necessários; Criação de uma aplicação nativa para inicialização da parte crítica da aplicação final. Como citado anteriormente, a aplicação final se divide em duas partes, sendo que a mais baixa é responsável pela comunicação direta com o dispositivo de hardware e armazenamento dos dados para posterior envio às camadas superiores. Assim, o re-ordenamento das tarefas e a inicialização de tal parte prioritariamente garantem que uma menor quantidade de informações será perdida (caso ocorra).

   Instrumentação e Aferição dos Dados

A recuperação dos dados vindos da plataforma foi feita através de uma conexão serial (RS232). Através dela foi possível se obter os tempos de inicialização de cada um dos componentes listados anteriormente.

   Resultados

Após a implementação das otimizações descritas anteriormente, a melhoria no tempo de inicialização da plataforma pôde ser mensurada. Inicialmente aferiu-se a plataforma sem que houvessem modificações ou qualquer tipo de melhoria. A tabela abaixo descreve os tempos médios (em segundos – s) gastos para a inicialização da aplicação Android na plataforma.

O primeiro passo a ser tomado foi a otimização do kernel Linux do Android. A tabela abaixo descreve os tempos de inicialização do kernel após as melhorias propostas.

O segundo passo foi a aplicação das otimizações à camada Android. A tabela e figura abaixo descrevem os tempos médios de inicialização de cada um dos componentes após as melhorias executadas.

Resultados