A partire dal 27 marzo 2025, ti consigliamo di utilizzare android-latest-release anziché aosp-main per compilare e contribuire ad AOSP. Per ulteriori informazioni, vedi Modifiche ad AOSP.
Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
L'Android Open Source Project (AOSP) è disponibile pubblicamente e modificabile
codice sorgente di Android. Chiunque può scaricare e modificare AOSP per il proprio dispositivo. AOSP
fornisce un'implementazione completa e perfettamente funzionante della piattaforma
mobile Android.
Esistono due livelli di compatibilità per i dispositivi che implementano AOSP: compatibilità AOSP e compatibilità Android. Un dispositivo compatibile con AOSP deve
essere conforme all'elenco dei requisiti nel
Compatibility Definition Document (CDD). Un
dispositivo compatibile con Android deve essere conforme all'elenco dei requisiti nel CDD
e ai requisiti e ai test del software del fornitore (VSR), ad esempio quelli della
suite di test del fornitore (VTS) e della
suite di test di compatibilità (CTS). Per ulteriori
informazioni sulla compatibilità con Android, consulta il
Programma di compatibilità Android.
Architettura AOSP
Lo stack software per AOSP contiene i seguenti livelli:
Figura 1. Architettura dello stack software AOSP.
Di seguito è riportato un elenco delle definizioni dei termini utilizzati nella Figura 1:
App per Android
Un'app creata esclusivamente utilizzando l'API Android. Google
Play Store è ampiamente utilizzato per trovare e scaricare app per Android, anche se esistono
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, visita il sito
developers.android.com.
App privilegiata
Un'app creata utilizzando una combinazione di API Android e di sistema. Queste app
devono essere preinstallate come app privilegiate su un dispositivo.
App del produttore del dispositivo
Un'app creata utilizzando una combinazione di API Android, API di sistema e accesso diretto all'implementazione del framework Android. Poiché un produttore di dispositivi
potrebbe accedere direttamente ad API instabili all'interno del framework Android, queste app
devono essere preinstallate sul dispositivo e possono essere aggiornate solo quando viene aggiornato il software di sistema
del dispositivo.
API di sistema
L'API di sistema rappresenta le API Android disponibili solo per partner e
OEM per l'inclusione nelle applicazioni in bundle. Queste API sono contrassegnate come @SystemApi
nel codice sorgente.
API Android
L'API Android è l'API disponibile pubblicamente per gli sviluppatori di app per Android di terze parti. Per informazioni sull'API Android, consulta
Riferimento API Android.
Framework Android
Un gruppo di classi, interfacce e altro codice precompilato Java su cui
vengono create le app. Parti del framework sono accessibili pubblicamente tramite l'utilizzo dell'API Android. Altre parti del framework sono
disponibili solo per gli OEM tramite l'utilizzo delle API di sistema. Il codice del framework Android 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. La funzionalità esposta dall'API del framework Android comunica con i servizi di sistema per accedere all'hardware sottostante.
Android Runtime (ART)
Un ambiente di runtime Java fornito da AOSP. ART esegue la
traduzione del bytecode dell'app in istruzioni specifiche del processore
che vengono eseguite dall'ambiente di runtime del dispositivo.
Hardware Abstraction Layer (HAL)
Un HAL è un livello di astrazione con un'interfaccia standard che i fornitori di hardware possono implementare. Gli HAL consentono ad Android di essere indipendente dalle implementazioni dei driver di livello inferiore. L'utilizzo di un HAL consente di implementare funzionalità senza
influenzare o modificare il sistema di livello superiore. Per ulteriori informazioni,
consulta la panoramica di HAL.
Librerie e daemon 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 con
il kernel o altre interfacce e non dipendono da un'implementazione HAL
basata sullo spazio utente.
Kernel
Il kernel è la parte centrale di qualsiasi sistema operativo e comunica con l'hardware sottostante di un dispositivo. Ove possibile, il kernel AOSP è suddiviso
in moduli indipendenti dall'hardware e moduli specifici del fornitore. Per una descrizione,
incluse le definizioni, dei componenti del kernel AOSP, consulta la
panoramica del kernel.
Passaggi successivi
Se non hai mai utilizzato AOSP e vuoi iniziare a sviluppare, consulta la
sezione Inizia.
Se vuoi saperne di più su un livello specifico di AOSP, fai clic sul nome della sezione nel riquadro di navigazione a sinistra e inizia con la panoramica della sezione.
I campioni di contenuti e codice in questa pagina sono soggetti alle licenze descritte nella Licenza per i contenuti. Java e OpenJDK sono marchi o marchi registrati di Oracle e/o delle sue società consociate.
Ultimo aggiornamento 2025-07-24 UTC.
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Mancano le informazioni di cui ho bisogno","missingTheInformationINeed","thumb-down"],["Troppo complicato/troppi passaggi","tooComplicatedTooManySteps","thumb-down"],["Obsoleti","outOfDate","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Problema relativo a esempi/codice","samplesCodeIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 2025-07-24 UTC."],[],[],null,["# Architecture overview\n\nThe *Android Open Source Project (AOSP)* is publicly available and modifiable\nAndroid source code. Anyone can download and modify AOSP for their device. AOSP\nprovides a complete and fully functional implementation of the Android mobile\nplatform.\n| **Note:** AOSP can't provide support for apps that require backend services, such as a cloud messaging or advanced location services app. AOSP also doesn't include a full set of end-user apps that might be needed for particular types of devices.\n\nThere are two levels of compatibility for devices implementing AOSP: AOSP\ncompatibility and Android compatibility. An *AOSP-compatible device* must\nconform to the list of requirements in the\n[Compatibility Definition Document (CDD)](/docs/compatibility/cdd). An\n*Android-compatible device* must conform to the list of requirements in the CDD\nand Vendor Software Requirements (VSR) and tests such as those in the\n[Vendor Test Suite (VTS)](/docs/core/tests/vts) and\n[Compatibility Test Suite (CTS)](/docs/compatibility/cts). For further\ninformation on Android compatibility, refer to the\n[Android compatibility program](/docs/compatibility).\n\nAOSP architecture\n-----------------\n\nThe software stack for AOSP contains the following layers:\n\n**Figure 1.** AOSP software stack architecture.\n\nFollowing is a list of definitions for terms used in Figure 1:\n\n*Android app*\n: An app created solely using the Android API. Google\n Play Store is widely used to find and download Android apps, though there are\n many other alternatives. In some cases, a device manufacturer might want to\n preinstall an Android app to support the core functionality of the device. If\n you're interested in developing Android apps, refer to\n [developers.android.com](https://developer.android.com/).\n\n*Privileged app*\n: An app created using a combination of the Android and system APIs. These apps\n must be preinstalled as privileged apps on a device.\n\n*Device manufacturer app*\n: An app created using a combination of the Android API, system API, and direct\n access to the Android framework implementation. Because a device manufacturer\n might directly access unstable APIs within the Android framework, these apps\n must be preinstalled on the device and can be updated only when the device's\n system software is updated.\n\n*System API*\n: The System API represents Android APIs available only to partners and\n OEMs for inclusion in bundled applications. These APIs are marked as @SystemApi\n in the source code.\n\n*Android API*\n: The Android API is the publicly available API for third-party Android app\n developers. For information on the Android API, refer to\n [Android API reference](https://developer.android.com/reference).\n\n*Android framework*\n: A group of Java classes, interfaces, and other precompiled code upon which\n apps are built. Portions of the framework are publicly accessible through the\n use of the Android API. Other portions of the framework are\n available only to OEMs through the use of the system APIs. Android\n framework code runs inside an app's process.\n\n*System services*\n: System services are modular, focused components such as `system_server`,\n SurfaceFlinger, and MediaService. Functionality exposed by Android framework API\n communicates with system services to access the underlying hardware.\n\n*Android runtime (ART)*\n: A Java runtime environment provided by AOSP. ART performs the\n translation of the app's bytecode into processor-specific instructions\n that are executed by the device's runtime environment.\n\n*Hardware abstraction layer (HAL)*\n: A HAL is an abstraction layer with a standard interface for hardware vendors\n to implement. HALs allow Android to be agnostic about lower-level driver\n implementations. Using a HAL lets you implement functionality without\n affecting or modifying the higher level system. For further information,\n see the [HAL overview](/docs/core/architecture/hal).\n\n*Native daemons and libraries*\n\n: Native daemons in this layer include `init`, `healthd`, `logd`, and\n `storaged`. These daemons interact directly with the kernel or other interfaces\n and don't depend on a userspace-based HAL implementation.\n\n Native libraries in this layer include `libc`, `liblog`, `libutils`,\n `libbinder`, and `libselinux`. These Native libraries interact directly with\n the kernel or other interfaces and don't depend on a userspace-based HAL\n implementation.\n\n*Kernel*\n\n: The kernel is the central part of any operating system and talks to the\n underlying hardware on a device. Where possible, the AOSP kernel is split\n into hardware-agnostic modules and vendor-specific modules. For a description,\n including definitions, of AOSP kernel components, refer to the\n [Kernel overview](/docs/core/architecture/kernel).\n\nWhat's next?\n------------\n\n- If you're new to AOSP, and want to get started with development, refer to the [Get started section](/docs/setup).\n- If you want to learn more about a specific layer of AOSP, click the section's name in the left navigation and begin with the overview for that section."]]
