Visão geral da arquitetura

O Android Open Source Project (AOSP) está disponível publicamente e é um código-fonte modificável do Android. Qualquer pessoa pode fazer o download e modificar o AOSP para o dispositivo. O AOSP oferece uma implementação completa e totalmente funcional da plataforma móvel Android.

Há dois níveis de compatibilidade para dispositivos que implementam o AOSP: compatibilidade com o AOSP e compatibilidade com o Android. Um dispositivo compatível com AOSP precisa estar em conformidade com a lista de requisitos no Documento de definição de compatibilidade (CDD). Um dispositivo compatível com o Android precisa estar em conformidade com a lista de requisitos do CDD e dos requisitos de software do fornecedor (VSR, na sigla em inglês) e testes, como os do conjunto de teste de fornecedor (VTS, na sigla em inglês) e do conjunto de teste de compatibilidade (CTS, na sigla em inglês). Para mais informações sobre a compatibilidade com o Android, consulte o Programa de compatibilidade do Android.

Arquitetura do AOSP

A pilha de software do AOSP contém as seguintes camadas:

Arquitetura de pilha de software do AOSP.

Figura 1. Arquitetura de pilha de software do AOSP.

Confira a seguir uma lista de definições dos termos usados na Figura 1:

App Android
Um app criado exclusivamente usando a API do Android. A Google Play Store é amplamente usada para encontrar e fazer o download de apps Android, embora existam muitas outras alternativas. Em alguns casos, um fabricante de dispositivos pode querer pré-instalar um app Android para oferecer suporte à funcionalidade principal do dispositivo. Se você tiver interesse em desenvolver apps Android, consulte developers.android.com.
App privilegiado
Um app criado usando uma combinação das APIs do Android e do sistema. Esses apps precisam ser pré-instalados como apps privilegiados em um dispositivo.
App do fabricante do dispositivo
Um app criado usando uma combinação da API do Android, da API do sistema e do acesso direto à implementação do framework do Android. Como um fabricante de dispositivos pode acessar diretamente APIs instáveis no framework do Android, esses apps precisam ser pré-instalados no dispositivo e só podem ser atualizados quando o software do sistema do dispositivo é atualizado.
API System
A API System representa APIs do Android disponíveis apenas para parceiros e OEMs para inclusão em aplicativos agrupados. Essas APIs são marcadas como @SystemApi no código-fonte.
API do Android
A API Android é a API disponível publicamente para desenvolvedores de apps Android de terceiros. Para informações sobre a API do Android, consulte a Referência da API do Android.
Framework do Android
Um grupo de classes Java, interfaces e outros códigos pré-compilados em que os apps são criados. Partes do framework são acessíveis publicamente pelo uso da API do Android. Outras partes do framework estão disponíveis apenas para OEMs usando as APIs do sistema. O código do framework do Android é executado dentro do processo de um app.
Serviços do sistema
Os serviços do sistema são componentes modulares e focados, como system_server, SurfaceFlinger e MediaService. A funcionalidade exposta pela API do framework do Android se comunica com os serviços do sistema para acessar o hardware.
Android Runtime (ART)
Um ambiente de execução Java fornecido pelo AOSP. O ART realiza a tradução do bytecode do app em instruções específicas do processador que são executadas pelo ambiente de execução do dispositivo.
Camada de abstração de hardware (HAL)
Uma HAL é uma camada de abstração com uma interface padrão para fornecedores de hardware implementarem. Os HALs permitem que o Android seja independente de implementações de driver de nível inferior. O uso de um HAL permite implementar funcionalidades sem afetar ou modificar o sistema de nível superior. Para mais informações, consulte a visão geral do HAL.
Bibliotecas e daemons nativos

Os demônios nativos nessa camada incluem init, healthd, logd e storaged. Esses demônios interagem diretamente com o kernel ou outras interfaces e não dependem de uma implementação de HAL baseada no espaço do usuário.

As bibliotecas nativas nessa camada incluem libc, liblog, libutils, libbinder e libselinux. Essas bibliotecas nativas interagem diretamente com o kernel ou outras interfaces e não dependem de uma implementação HAL baseada no espaço do usuário.

Kernel

O kernel é a parte central de qualquer sistema operacional e se comunica com o hardware subjacente de um dispositivo. Sempre que possível, o kernel do AOSP é dividido em módulos independentes de hardware e específicos do fornecedor. Para uma descrição, incluindo definições, dos componentes do kernel do AOSP, consulte a Visão geral do kernel.

Quais são as próximas etapas?

  • Se você não conhece o AOSP e quer começar a desenvolver, consulte a Seção "Introdução".
  • Se você quiser saber mais sobre uma camada específica do AOSP, clique no nome da seção na navegação à esquerda e comece com a visão geral dela.