A partire dal 2026, per allinearci al nostro modello di sviluppo trunk stabile e garantire la stabilità della piattaforma per l'ecosistema, pubblicheremo il codice sorgente su AOSP nel secondo e nel quarto trimestre. Per compilare e contribuire ad AOSP, consigliamo di utilizzare android-latest-release anziché aosp-main. Il branch del manifest android-latest-release farà sempre riferimento alla release più recente pubblicata su AOSP. Per saperne di più, consulta la sezione Modifiche ad AOSP.

Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Provare lo sviluppo Android

Questo tutorial ti consente di provare per la prima volta lo sviluppo del sistema operativo Android.

Configurare lo sviluppo di Android

Prima di scaricare e creare il ramo del manifest android-latest-release di codice sorgente Android, assicurati che l'hardware soddisfi i requisiti necessari e che il software richiesto sia installato correttamente. Dovresti anche conoscere i seguenti termini:

Git: Git è un sistema di controllo della versione distribuito, senza costi e open source. Android utilizza Git per le operazioni locali come la creazione di rami, i commit, le differenze e le modifiche. Per informazioni su Git, consulta la documentazione di Git.
Repo: Repo è un wrapper Python per Git che semplifica l'esecuzione di operazioni complesse su più repository Git. Repo non sostituisce Git per tutte le operazioni di controllo della versione, ma semplifica solo le operazioni Git complesse. Repo utilizza i file manifest per aggregare i progetti Git nel superprogetto Android.
File manifest: Un file manifest è un file XML che specifica la posizione dei vari progetti Git nel codice sorgente di Android all'interno di una struttura del codice sorgente AOSP.

Soddisfare i requisiti hardware

La workstation di sviluppo deve soddisfare o superare i seguenti requisiti hardware:

Un sistema x86 a 64 bit.

Nota: puoi compilare le versioni AOSP precedenti alla 2.3.x sui sistemi a 32 bit.
Almeno 400 GB di spazio libero su disco per estrarre e creare il codice (250 GB per l'estrazione + 150 GB per la creazione).

Nota:se stai estraendo un mirror, hai bisogno di più spazio perché i mirror completi di Android Open Source Project (AOSP) contengono tutti i repository Git mai utilizzati.
Un minimo di 64 GB di RAM. Google utilizza macchine con 72 core e 64 GB di RAM per creare Android. Con questa configurazione hardware, una build completa di Android richiede circa 40 minuti e una build incrementale di Android solo pochi minuti. Al contrario, una build completa con una macchina a 6 core e 64 GB di RAM richiede circa 6 ore.

Soddisfare i requisiti di sistema

La workstation di sviluppo deve eseguire una distribuzione Linux a 64 bit con GNU C Library (glibc) 2.17 o versioni successive.

Installare i pacchetti richiesti

Per installare i pacchetti richiesti per Ubuntu 18.04 o versioni successive, esegui il seguente comando:

sudo apt-get install git-core gnupg flex bison build-essential zip curl zlib1g-dev libc6-dev-i386 x11proto-core-dev libx11-dev lib32z1-dev libgl1-mesa-dev libxml2-utils xsltproc unzip fontconfig

Installare il software richiesto

Prima di poter utilizzare AOSP, devi aver installato OpenJDK, Make, Python 3 e Repo. Il ramo della release più recente di Android include versioni precompilate di OpenJDK, Make e Python 3, quindi non sono necessari passaggi di installazione aggiuntivi. La sezione seguente spiega come installare Repo.

Installare Repo

Per installare Repo:

Scarica le informazioni sul pacchetto corrente:
```
sudo apt-get update
```
Esegui il seguente comando per installare il programma di avvio di Repo:
```
sudo apt-get install repo
```
Il programma di avvio di Repo fornisce uno script Python che inizializza un checkout e scarica lo strumento Repo completo.

Se l'operazione va a buon fine, vai al passaggio 4.
(Facoltativo) Installa manualmente Repo utilizzando la seguente serie di comandi:
```
export REPO=$(mktemp /tmp/repo.XXXXXXXXX)
curl -o ${REPO} https://storage.googleapis.com/git-repo-downloads/repo
gpg --recv-keys 8BB9AD793E8E6153AF0F9A4416530D5E920F5C65
curl -s https://storage.googleapis.com/git-repo-downloads/repo.asc | gpg --verify - ${REPO} && install -m 755 ${REPO} ~/bin/repo
```
I primi tre comandi configurano un file temporaneo, scaricano Repo nel file e verificano che la chiave fornita corrisponda alla chiave richiesta. Se questi comandi vanno a buon fine, l'ultimo comando installa il programma di avvio di Repo.
Verifica la versione del programma di avvio di Repo:
```
repo version
```
L'output dovrebbe indicare una versione 2.4 o successiva, ad esempio:

repo launcher version 2.45

Scaricare il codice sorgente di Android

Il codice sorgente di Android si trova in una raccolta di repository Git ospitati da Google. Ogni repository Git include l'intera cronologia del codice sorgente di Android, incluse le modifiche al codice sorgente e le date in cui sono state apportate. Per scaricare il codice sorgente di Android:

Vai alla home directory:
```
cd ~
```
Crea una sottodirectory di lavoro locale al suo interno:
```
mkdir aosp
```
Vai alla directory:
```
cd aosp
```
Inizializza il ramo della release più recente del codice sorgente del repository AOSP (android-latest-release):
```
repo init --partial-clone -b android-latest-release -u https://android.googlesource.com/platform/manifest
```
Inserisci o accetta le tue credenziali Git (nome, indirizzo email).
Sincronizza il codice sorgente:
```
repo sync -c -j8
```
Se riscontri problemi durante il download, consulta Risolvere e correggere i problemi di sincronizzazione.

Creare il codice

Per creare il codice:

Dalla directory di lavoro, esegui lo script envsetup.sh per configurare l'ambiente di build:
```
source build/envsetup.sh
```

Specifica un tipo di dispositivo target da creare con il comando lunch. Un target è una permutazione del dispositivo, ad esempio un modello o un fattore di forma specifico. Specifica questo target:

lunch aosp_cf_x86_64_only_phone-aosp_current-userdebug

Dovresti vedere una sinossi del target e dell'ambiente di build:

============================================
PLATFORM_VERSION_CODENAME=Baklava
PLATFORM_VERSION=Baklava
TARGET_PRODUCT=aosp_cf_x86_64_only_phone
TARGET_BUILD_VARIANT=userdebug
TARGET_ARCH=x86_64
TARGET_ARCH_VARIANT=silvermont
HOST_OS=linux
HOST_OS_EXTRA=Linux-6.10.11-1rodete2-amd64-x86_64-Debian-GNU/Linux-rodete
HOST_CROSS_OS=windows
BUILD_ID=BP1A.250305.020
OUT_DIR=out
============================================

Crea il target:
```
m
```

La prima build dovrebbe richiedere ore. Le build successive richiedono molto meno tempo. L'output della build viene visualizzato in $OUT_DIR.

Avviare Cuttlefish

Cuttlefish è l'emulatore Android utilizzato per testare le build.

Esegui i seguenti comandi per scaricare, creare e installare i pacchetti Debian dell'host:

sudo apt install -y git devscripts equivs config-package-dev debhelper-compat golang curl
git clone https://github.com/google/android-cuttlefish
cd android-cuttlefish
for dir in base frontend; do
pushd $dir
# Install build dependencies
sudo mk-build-deps -i
dpkg-buildpackage -uc -us
popd
done
sudo dpkg -i ./cuttlefish-base_*_*64.deb || sudo apt-get install -f
sudo dpkg -i ./cuttlefish-user_*_*64.deb || sudo apt-get install -f
sudo usermod -aG kvm,cvdnetwork,render $USER
sudo reboot

Il riavvio attiva l'installazione di moduli kernel aggiuntivi e applica le regole udev.

Avvia Cuttlefish:
```
launch_cvd --daemon
```
Connettiti al dispositivo Cuttlefish andando all'indirizzo https://localhost:8443 nel browser web. Viene visualizzato il dispositivo virtuale con Android.

Apportare una modifica

Aggiorna il codice sorgente seguendo questo elenco di modifiche di esempio changelist.

Dalla radice del checkout (directory aosp/), vai al progetto Git frameworks/native:
```
cd frameworks/native
```
Avvia un progetto temporaneo con questo comando:
```
repo start PROJECT_NAME.
```
Utilizza l'editor per modificare SurfaceFlinger.cpp nella seguente posizione:
```
aosp/frameworks/native/services/surfaceflinger/SurfaceFlinger.cpp
```

Trova questa riga:

void SurfaceFlinger::updateColorMatrixLocked() {

Aggiungi questa riga all'inizio di updateColorMatrixLocked():

mClientColorMatrix = mat4(vec4{1.0f, 0.0f, 0.0f, 0.0f}, vec4{0.0f, -1.0f, 0.0f, 0.0f},
                         vec4{0.0f, 0.0f, -1.0f, 0.0f}, vec4{0.0f, 1.0f, 1.0f, 1.0f});

Crea il codice:
```
m
```

Aggiorna la build sul dispositivo:

adb root
adb remount -R
adb root
adb sync
adb reboot

Verifica di vedere una modifica del colore sul dispositivo selezionato simile a quella mostrata nella Figura 1.

Figura 1. Aspetto dello schermo dopo la modifica del colore

Correggere un test

Questa parte del codelab utilizza un test di esempio presente nella struttura del codice sorgente e non superato.

Per eseguire, eseguire il debug e correggere il test:

Esegui:
```
atest DevCodelabTest
```
Il test non viene superato.

Nota: atest è uno strumento a riga di comando che consente di creare, installare ed eseguire test Android in locale.

Esamina l'analisi dello stack del test non superato:

STACKTRACE:
java.lang.AssertionError
 at org.junit.Assert.fail(Assert.java:87)
 at org.junit.Assert.assertTrue(Assert.java:42)
 at org.junit.Assert.assertTrue(Assert.java:53)
 at android.test.example.devcodelab.DevCodelabTest.testHelloWorld(DevCodelabTest.java:29)

L'ultima riga dell'analisi dello stack mostra il test non superato (testHelloWorld). Questo test si trova in un file denominato DevCodelabTest.java.

Per determinare la posizione del test da correggere, aggiungi WORKING_DIRECTORY/platform_testing/tests/example/devcodelab/src/ all'ultima riga dell'analisi dello stack fino al nome del file di test incluso. Quindi, android.test.example.devcodelab.DevCodelabTest diventa WORKING_DIRECTORY/platform_testing/tests/example/devcodelab/src/android/test/example/devcodelab/DevCodelabTest.java.
Modifica platform_testing/tests/example/devcodelab/src/android/test/example/devcodelab/DevCodelabTest.java e sostituisci Assert.assertTrue(false) con Assert.assertTrue(true).
Esegui di nuovo il test per verificare di aver risolto il problema:
```
atest DevCodelabTest
```

Caricare il codice per la revisione

Repo semplifica l'utilizzo di Git raggruppando comandi come git clone per operare contemporaneamente su numerosi repository Git (o progetti).

Per la revisione del codice dei tuoi progetti in Git, utilizza il sistema di revisione del codice basato sul web Gerrit.

Supponendo di aver apportato le modifiche nel progetto frameworks/native, esegui questi comandi per caricare le modifiche:
```
cd frameworks/native
repo start PROJECT_NAME.
git add .
git commit
```
Per il messaggio di commit, inserisci quanto segue:
```
Android PROJECT_NAME. change
Test: manual atest
```

Carica la modifica:

repo upload

Se l'operazione va a buon fine, viene visualizzato un messaggio simile al seguente:

Upload project frameworks/native/ to remote branch android17-release:
 branch PROJECT_NAME. ( 1 commit, Wed Aug 7 09:32:33 2019 -0700):
        ff46b36d android PROJECT_NAME. change
to https://android-review.googlesource.com/ (y/N)? y
remote: Processing changes: refs: 1, new: 1, done
remote:
remote: SUCCESS
remote:
remote:   https://android-review.googlesource.com/c/platform/frameworks/native/+/1098432 android PROJECT_NAME. change [NEW]
remote:
To https://android-review.googlesource.com/platform/frameworks/native
* [new branch]          PROJECT_NAME. -> refs/for/android17-release

Visualizzare la modifica in Gerrit

Per visualizzare la modifica in Gerrit, vai al link di output nel terminale. Il link è simile al seguente:

https://android-review.googlesource.com/c/platform/frameworks/native/+/1098432

Ripristinare la modifica

In genere, dopo i test e dopo la revisione e l'approvazione, invii la modifica in Gerrit e la unisci al repository. Invece, ai fini di questo codelab, ripristina il tuo lavoro:

In Gerrit, fai clic su Abbandona.
Abbandona il ramo temporaneo associato nella directory del progetto frameworks/native (o nelle relative sottodirectory):
```
repo abandon PROJECT_NAME.
```
Ripristina le modifiche apportate al file di test. Poiché non hai eseguito repo start, git commit e repo upload sulla modifica del test, puoi reimpostare il file stesso. Supponendo che tu sia in aosp/platform_testing directory, utilizza il seguente comando per reimpostare il file:
```
git reset HEAD tests/example/devcodelab/src/android/test/example/devcodelab/DevCodelabTest.java
git checkout .
```

Con questo si conclude il codelab per lo sviluppo della piattaforma Android.

Richiedere assistenza

Se riscontri errori durante questo codelab, segnalali utilizzando il link Issue Tracker nella parte inferiore di qualsiasi pagina. Invia le domande al gruppo android-building.

Digita ps -A | grep crosvm per verificare se crosvm è già in esecuzione. Se crossvm è in esecuzione, digita stop_cvd || true o kill crosvm processo con il PID del processo.