Panoramica dell'architettura

Android Open Source Project (AOSP) è disponibile pubblicamente e modificabile Codice sorgente di Android. Chiunque può scaricare e modificare l'AOSP per il proprio dispositivo. AOSP fornisce un'implementazione completa e pienamente funzionale dell'app mobile Android completamente gestita.

Esistono due livelli di compatibilità per i dispositivi che implementano AOSP: AOSP compatibilità e compatibilità Android. È necessario che un dispositivo compatibile con AOSP siano conformi all'elenco dei requisiti della il Compatibility Definition Document (CDD). Un Il dispositivo compatibile con Android deve essere conforme all'elenco dei requisiti del CDD e ai requisiti software del fornitore (VSR) e test come quelli della Suite di test del fornitore (VTS) e Suite di test di compatibilità (CTS). Per ulteriori informazioni informazioni sulla compatibilità con Android, consulta le Programma di compatibilità Android.

Architettura AOSP

Lo stack software per AOSP contiene i seguenti livelli:

AOSP.

Figura 1. AOSP.

Di seguito è riportato un elenco di definizioni dei termini utilizzati nella Figura 1:

App per Android
Un'app creata esclusivamente con l'API Android. Google Play Store è ampiamente utilizzato per trovare e scaricare app Android, anche se ci sono molte altre alternative. In alcuni casi, un produttore di dispositivi potrebbe voler preinstallare un'app per Android per supportare la funzionalità di base del dispositivo. Se ti interessa sviluppare app per Android, consulta developers.android.com.
App con privilegi
Un'app creata utilizzando una combinazione di API di Android e di sistema. Queste app devono essere preinstallate come app con privilegi su un dispositivo.
App del produttore del dispositivo
Un'app creata utilizzando una combinazione di API Android, API di sistema e accesso diretto l'accesso all'implementazione del framework Android. Perché un produttore di dispositivi potrebbero accedere direttamente alle API instabili nel framework Android, queste app devono essere preinstallati sul dispositivo e possono essere aggiornati solo quando il software di sistema sia aggiornato.
API di sistema
L'API di sistema rappresenta le API Android disponibili solo per i partner e OEM per l'inclusione in applicazioni in bundle. Queste API sono contrassegnate come @SystemApi nel codice sorgente.
API Android
L'API Android è l'API disponibile pubblicamente per le app per Android di terze parti sviluppatori. Per informazioni sull'API per Android, consulta Riferimento API Android.
Framework Android
Un gruppo di classi, interfacce e altro codice precompilato Java su cui in cui vengono create app. Parti del framework sono accessibili pubblicamente tramite la l'utilizzo dell'API Android. Altre parti del framework includono disponibili solo per gli OEM tramite le API di sistema. Android il codice framework viene eseguito all'interno del processo di un'app.
Servizi di sistema
I servizi di sistema sono componenti modulari e mirati, come system_server, SurfaceFlinger e MediaService. Funzionalità esposta dall'API Android Framework comunica con i servizi di sistema per accedere all'hardware sottostante.
Android Runtime (ART)
Un ambiente di runtime Java fornito da AOSP. ART esegue traduzione del bytecode dell'app in istruzioni specifiche per il processore eseguite dall'ambiente di runtime del dispositivo.
HAL (Hardware Astrazione Layer)
Un HAL è un livello di astrazione con un'interfaccia standard per i fornitori di hardware da implementare. Gli HAL consentono ad Android di essere indipendente dal conducente di livello inferiore implementazioni. L'uso di un HAL consente di implementare funzionalità senza che influenzano o modificano il sistema di livello superiore. Per ulteriori informazioni, consulta la panoramica dell'HAL.
Daemon e librerie nativi

I daemon nativi in questo livello includono init, healthd, logd e storaged. Questi daemon interagiscono direttamente con il kernel o altre interfacce e non dipendono da un'implementazione HAL basata sullo spazio utente.

Le librerie native in questo livello includono libc, liblog, libutils, libbinder e libselinux. Queste librerie native interagiscono direttamente al kernel o ad altre interfacce e non dipendono da un HAL basato su spazio utente implementazione.

Gernel

Il kernel è la parte centrale di qualsiasi sistema operativo e comunica con l'hardware sottostante di un dispositivo. Se possibile, il kernel AOSP viene suddiviso in moduli indipendenti dall'hardware e moduli specifici del fornitore. Per una descrizione, incluse le definizioni dei componenti del kernel AOSP, fai riferimento Panoramica del kernel.

Passaggi successivi

  • Se non hai mai utilizzato AOSP e vuoi iniziare lo sviluppo, consulta la sezione Inizia.
  • Per saperne di più su un livello specifico di AOSP, fai clic sul nome nella barra di navigazione a sinistra e inizia con la panoramica per quella sezione.