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, utilizza android-latest-release. 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 utilizza la tecnologia AI per tradurre i contenuti nella tua lingua preferita. Le traduzioni generate dall'AI potrebbero contenere errori.

Provare lo sviluppo Android

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

Configura per lo sviluppo Android

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

Git: Git è un sistema di controllo della versione distribuito, open source e senza costi. Android utilizza Git per le operazioni locali come branching, commit, diff e modifiche. Per assistenza con l'apprendimento di Git, consulta la documentazione di Git.
Repo: Repo è un wrapper Python attorno a 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 l'esecuzione di 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 dove si trovano i vari progetti Git nel codice sorgente Android all'interno di un albero dei sorgenti AOSP.

Requisiti hardware di Meet

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

Un sistema x86 a 64 bit.

Nota: puoi compilare versioni di AOSP precedenti alla 2.3.x su sistemi a 32 bit.
Almeno 400 GB di spazio su disco libero per eseguire il checkout e la build del codice (250 GB per il checkout + 150 GB per la build).

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

Soddisfa i requisiti del sistema operativo

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

Installa i pacchetti richiesti

Per installare i pacchetti richiesti per Ubuntu 18.04 o versioni successive, esegui questo 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

Installa il software richiesto

Prima di poter lavorare con AOSP, devi aver installato OpenJDK, Make, Python 3 e Repo. Il ramo di release più recente di Android include versioni predefinite di OpenJDK, Make e Python 3, pertanto non sono necessari ulteriori passaggi di installazione. La sezione seguente spiega come installare Repo.

Installa Repo

Per installare Repo, segui questi passaggi:

Scarica le informazioni sul pacchetto attuale:
```
sudo apt-get update
```
Esegui questo comando per installare l'Avvio app 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 a quella richiesta. Se questi comandi vengono eseguiti correttamente, l'ultimo comando installa l'Avvio app Repo.

Verifica la versione di Repo Launcher:
```
repo version
```
L'output dovrebbe indicare una versione 2.4 o successiva, ad esempio:
```
repo launcher version 2.45
```

Scarica 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 Android, incluse le modifiche al codice sorgente e la data in cui sono state apportate. Per scaricare il codice sorgente di Android:

Vai alla tua home directory:
```
cd ~
```
Crea una sottodirectory di lavoro locale al suo interno:
```
mkdir aosp
```
Vai alla directory:
```
cd aosp
```

Inizializza il branch dell'ultima release 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
```
In caso di problemi durante il download, consulta Risolvi i problemi di sincronizzazione.

Crea 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 di destinazione 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 un riepilogo del tuo 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 potrebbe richiedere ore. Le build successive richiedono molto meno tempo. L'output della build viene visualizzato in $OUT_DIR.

Avvia Cuttlefish

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

Esegui questi comandi per scaricare, creare e installare i pacchetti Debian 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
tools/buildutils/build_packages.sh
sudo apt install -y ./cuttlefish-base_*.deb ./cuttlefish-user_*.deb
sudo usermod -aG kvm,cvdnetwork,render $USER
sudo reboot

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

Dopo il riavvio della workstation, vai alla directory aosp, configura l'ambiente di build e avvia Cuttlefish:

cd ~/aosp
source build/envsetup.sh
lunch aosp_cf_x86_64_only_phone-aosp_current-userdebug
launch_cvd --daemon

Connettiti al dispositivo Cuttlefish andando all'indirizzo https://localhost:8443 nel tuo browser web. Viene visualizzato il tuo dispositivo virtuale Android.

apporta una modifica

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

Dalla directory principale del checkout (directory aosp/), vai al progetto Git frameworks/native:
```
cd frameworks/native
```
Avvia un branch temporaneo con questo comando:
```
repo start BRANCH_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 che il colore del dispositivo selezionato cambi.

Correggi un test

Questa parte del codelab utilizza un test di esempio che si trova nell'albero di origine e che non va a buon fine. Per eseguire, eseguire il debug e correggere il test, segui queste istruzioni:

Esegui:
```
atest DevCodelabTest
```
Il test non va a buon fine.

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 con esito negativo:

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 che non va a buon fine (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. Pertanto, 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
```

Carica il codice per la revisione

Repo semplifica l'utilizzo di Git raggruppando comandi come git clone per lavorare su più repository (o progetti) Git contemporaneamente. Per la revisione del codice dei tuoi progetti in Git, utilizza il sistema di revisione del codice basato sul web Gerrit.

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

Carica la modifica:

repo upload

Se l'operazione riesce, viene visualizzato un messaggio simile al seguente:

Upload project frameworks/native/ to remote branch android17-release:
  branch BRANCH_NAME ( 1 commit, Wed Aug 7 09:32:33 2019 -0700):
         ff46b36d Android BRANCH_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 BRANCH_NAME change [NEW]
remote:
To https://android-review.googlesource.com/platform/frameworks/native
* [new branch]          BRANCH_NAME -> refs/for/android17-release

Visualizza la modifica in Gerrit

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

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

Ripristina la modifica

In genere, dopo i test e l'esame 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 Abandon (Abbandona).
Abbandona il branch temporaneo associato nella directory del progetto frameworks/native (o nelle sue sottodirectory):
```
repo abandon BRANCH_NAME .
```
Ripristina le modifiche apportate al file di test. Poiché non hai eseguito repo start, git commit e repo upload sulla modifica di test, puoi reimpostare il file stesso. Supponendo che tu sia nella directory aosp/platform_testing, utilizza i seguenti comandi per reimpostare il file:
```
git reset HEAD tests/example/devcodelab/src/android/test/example/devcodelab/DevCodelabTest.java
git checkout .
```

Il codelab per lo sviluppo della piattaforma Android è terminato.

Richiedi assistenza

Se riscontri errori durante questo codelab, segnalali utilizzando il link di 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 crosvm è in esecuzione, digita il processo stop_cvd || true o kill crosvm con il PID del processo.