Visão geral da arquitetura

O Android Open Source Project (AOSP) está disponível publicamente e pode ser modificado Código-fonte do Android. Qualquer pessoa pode fazer o download e modificar o AOSP para o dispositivo. AOSP oferece uma implementação completa e totalmente funcional do app Android para de plataforma.

Há dois níveis de compatibilidade para dispositivos que implementam o AOSP: o AOSP e a compatibilidade com Android. Um dispositivo compatível com o AOSP precisa estão em conformidade com a lista de requisitos Documento de definição de compatibilidade (CDD). Um Um dispositivo compatível com Android precisa estar em conformidade com a lista de requisitos do CDD. e requisitos de software do fornecedor (VSR, na sigla em inglês) e testes como os da Pacote de testes de fornecedor (VTS) e Conjunto de teste de compatibilidade (CTS). Para mais informações sobre compatibilidade com o Android, consulte 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.

Veja a seguir uma lista de definições para os termos usados na Figura 1:

App Android
Um app criado exclusivamente usando a API Android. Google A Play Store é muito 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 se você tiver interesse em desenvolver apps Android, consulte developers.android.com (link em inglês).
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 de o acesso à implementação do framework do Android. Como um fabricante de dispositivos possam acessar diretamente APIs instáveis no framework do Android, esses apps pré-instalado no dispositivo e só pode ser atualizado quando o software do sistema está atualizado.
API do sistema
A API System representa as APIs do Android disponíveis apenas para parceiros e OEMs para inclusão em aplicativos em pacote. Essas APIs estão marcadas como @SystemApi. no código-fonte.
API Android
A API Android está disponível publicamente para aplicativos Android de terceiros desenvolvedores de aplicativos. Para mais informações sobre a API Android, consulte Referência da API do Android.
Framework do Android
Um grupo de classes, interfaces e outros códigos Java pré-compilados sobre os quais são desenvolvidos. Partes da estrutura são acessíveis ao público por meio do uso da API do Android. Outras partes da estrutura são disponível apenas para OEMs por meio das APIs do sistema. Android o código do framework é executado no 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. 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 executa a tradução do bytecode do app em instruções específicas do processador que são executados 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 precisam ser implementados. As HALs permitem que o Android seja independente do driver de nível inferior e implementações. O uso de HAL permite implementar funcionalidades sem afetar ou modificar o sistema de nível superior. Para mais informações, consulte a visão geral da HAL.
Daemons e bibliotecas nativos

Os daemons nativos nessa camada incluem init, healthd, logd e storaged. Esses daemons interagem diretamente com o kernel ou outras interfaces e não dependam 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 interagem diretamente kernel ou outras interfaces e não dependem de uma HAL baseada no espaço do usuário implementação.

Kernel

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

Qual é a próxima etapa?

  • Se você é novo no AOSP e quer começar a desenvolver, consulte a seção Como começar.
  • Para saber mais sobre uma camada específica do AOSP, clique no na navegação à esquerda e comece com a visão geral dessa seção.