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.
Aggiornamenti di sistema non A/B
Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
Gli aggiornamenti non AB sono una metodologia OTA deprecata utilizzata dai dispositivi Android meno recenti (Android 6 e versioni precedenti). Questi dispositivi dispongono di una partizione di ripristino dedicata contenente il software necessario per scompattare un pacchetto di aggiornamento scaricato e applicare l'aggiornamento alle altre partizioni.
Sui dispositivi Android meno recenti senza partizioni A/B, lo spazio flash in genere contiene le seguenti partizioni:
- avvio
-
Contiene il kernel Linux e un file system radice minimo (caricato in un disco RAM). Monta
il sistema e altre partizioni e avvia il runtime situato nella partizione di sistema.
- di infotainment
-
Contiene applicazioni e librerie di sistema il cui codice sorgente è disponibile nell'Android Open Source Project (AOSP). Durante il normale funzionamento, questa partizione viene montata in sola lettura; i suoi contenuti cambiano solo durante un aggiornamento OTA.
- fornitore
-
Contiene applicazioni e librerie di sistema per le quali non è disponibile il codice sorgente
su Android Open Source Project (AOSP). Durante il normale funzionamento, questa partizione viene montata
in sola lettura; i relativi contenuti cambiano solo durante un aggiornamento OTA.
- userdata
-
Memorizza i dati salvati dalle applicazioni installate dall'utente e così via. Questa partizione non viene solitamente modificata dalla procedura di aggiornamento OTA.
- cache
-
Spazio di accodamento temporaneo utilizzato da alcune applicazioni (l'accesso a questa partizione richiede autorizzazioni speciali per le app) e per l'archiviazione dei pacchetti di aggiornamento OTA scaricati. Altri programmi utilizzano questo
spazio con l'aspettativa che i file possano scomparire in qualsiasi momento. Alcune installazioni di pacchetti OTA possono comportare l'eliminazione completa di questa partizione. La cache contiene anche
i log di aggiornamento di un aggiornamento OTA.
- recupero
-
Contiene un secondo sistema Linux completo, incluso un kernel e il codice binario di ripristino speciale
che legge un pacchetto e utilizza i relativi contenuti per aggiornare le altre partizioni.
- misc
-
Piccola partizione utilizzata dal recupero per archiviare alcune informazioni sulle operazioni in corso nel caso in cui il dispositivo venga riavviato durante l'applicazione del pacchetto OTA.
Ciclo di vita di un aggiornamento OTA
Un tipico aggiornamento OTA contiene i seguenti passaggi:
-
Il dispositivo esegue un controllo regolare con i server OTA e riceve una notifica della disponibilità di un
aggiornamento, incluso l'URL del pacchetto di aggiornamento e una stringa di descrizione da mostrare all'utente.
-
Aggiorna i download in una cache o una partizione di dati e la firma crittografica viene verificata
in base ai certificati in
/system/etc/security/otacerts.zip. All'utente viene chiesto di installare l'aggiornamento.
-
Il dispositivo si riavvia in modalità di ripristino, in cui vengono avviati il kernel e il sistema nella partizione di ripristino anziché il kernel nella partizione di avvio.
-
Il file binario di ripristino viene avviato da init. Trova gli argomenti della riga di comando in
/cache/recovery/command che rimandano al pacchetto scaricato.
-
Il recupero verifica la firma crittografica del pacchetto in base alle chiavi pubbliche in
/res/keys (parte del disco RAM contenuto nella partizione di ripristino).
-
I dati vengono estratti dal pacchetto e utilizzati per aggiornare le partizioni di boot, di sistema e/o del fornitore, se necessario. Uno dei nuovi file rimasti nella partizione di sistema contiene i contenuti della nuova partizione di ripristino.
-
Il dispositivo si riavvia normalmente.
-
La partizione di avvio appena aggiornata viene caricata, montata e inizia a eseguire i binari
nella partizione di sistema appena aggiornata.
-
Durante la normale procedura di avvio, il sistema controlla i contenuti della partizione di ripristino rispetto ai contenuti desiderati (che in precedenza erano memorizzati come file in
/system). Se sono diversi, la partizione di ripristino viene riflashata con i contenuti desiderati. (Al riavvio successivo, la partizione di ripristino contiene già i nuovi contenuti, quindi non è necessario eseguire il reflash.)
L'aggiornamento di sistema è stato completato. I log di aggiornamento sono disponibili in
/cache/recovery/last_log.#.
Aggiorna i pacchetti
Un pacchetto di aggiornamento è un file .zip contenente il file binario eseguibile
META-INF/com/google/android/update-binary. Dopo aver verificato la firma sul
pacchetto, recovery estrae questo file binario in /tmp ed esegue il file binario,
passando i seguenti argomenti:
-
Aggiorna il numero di versione dell'API binaria. Se gli argomenti passati all'aggiornamento
cambiano in formato binario, questo numero aumenta.
-
Descrittore file della pipe di comando. Il programma di aggiornamento può utilizzare questo pipe per inviare nuovamente i comandi al file binario di ripristino, principalmente per le modifiche all'interfaccia utente, ad esempio per indicare l'avanzamento all'utente.
-
Nome del file del pacchetto di aggiornamento
.zip.
Un pacchetto di aggiornamento può utilizzare qualsiasi file binario collegato in modo statico come file binario di aggiornamento. Gli strumenti di compilazione del pacchetto OTA utilizzano il programma di aggiornamento (bootable/recovery/updater), che fornisce un semplice linguaggio di scripting in grado di eseguire molte attività di installazione. Puoi sostituire
qualsiasi altro file binario in esecuzione sul dispositivo.
Per informazioni dettagliate sul file binario dell'aggiornamento, sulla sintassi di edify e sulle funzioni predefinite, consulta
Informazioni sui pacchetti OTA.
Eseguire la migrazione dalle release precedenti
Durante la migrazione dalla release Android 2.3/3.0/4.0, la modifica più importante è la conversione di tutte le funzionalità specifiche del dispositivo da un insieme di funzioni C con nomi predefiniti a oggetti C++.
La tabella seguente elenca le vecchie funzioni e i nuovi metodi che hanno una finalità approssimativamente equivalente:
| Funzione C |
Metodo C++ |
| device_recovery_start() |
Device::RecoveryStart() |
device_toggle_display()
device_reboot_now()
|
RecoveryUI::CheckKey()
(anche RecoveryUI::IsKeyPressed())
|
| device_handle_key() |
Device::HandleMenuKey() |
| device_perform_action() |
Device::InvokeMenuItem() |
| device_wipe_data() |
Device::WipeData() |
| device_ui_init() |
ScreenRecoveryUI::Init() |
La conversione delle vecchie funzioni nei nuovi metodi dovrebbe essere ragionevolmente semplice. Non dimenticare di aggiungere la nuova funzione make_device() per creare e restituire un'istanza della nuova sottoclasse Device.
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-27 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-27 UTC."],[],[],null,["# Non-A/B system updates\n\nNon AB updates are a deprecated OTA methodology used by older Android Devices (Android 6 and\nearlier). These devices have a dedicated recovery partition containing the software needed to\nunpack a downloaded update package and apply the update to the other partitions.\n\n\nOn older Android devices without A/B partitions, the flash space typically contains the\nfollowing partitions:\n\nboot\n:\n Contains the Linux kernel and a minimal root filesystem (loaded into a RAM disk). It mounts\n system and other partitions and starts the runtime located on the system partition.\n\nsystem\n:\n Contains system applications and libraries that have source code available on Android Open\n Source Project (AOSP). During normal operation, this partition is mounted read-only; its\n contents change only during an OTA update.\n\nvendor\n:\n Contains system applications and libraries that do *not* have source code available\n on Android Open Source Project (AOSP). During normal operation, this partition is mounted\n read-only; its contents change only during an OTA update.\n\nuserdata\n:\n Stores the data saved by applications installed by the user, etc. This partition is not\n normally touched by the OTA update process.\n\ncache\n:\n Temporary holding area used by a few applications (accessing this partition requires special\n app permissions) and for storage of downloaded OTA update packages. Other programs use this\n space with the expectation that files can disappear at any time. Some OTA package\n installations may result in this partition being wiped completely. The cache also contains\n the update logs from an OTA update.\n\nrecovery\n:\n Contains a second complete Linux system, including a kernel and the special recovery binary\n that reads a package and uses its contents to update the other partitions.\n\nmisc\n:\n Tiny partition used by recovery to stash some information away about what it is doing in\n case the device is restarted while the OTA package is being applied.\n\nLife of an OTA update\n---------------------\n\nA typical OTA update contains the following steps:\n\n1. Device performs regular check in with OTA servers and is notified of the availability of an update, including the URL of the update package and a description string to show the user.\n2. Update downloads to a cache or data partition, and its cryptographic signature is verified against the certificates in `/system/etc/security/otacerts.zip`. User is prompted to install the update.\n3. Device reboots into recovery mode, in which the kernel and system in the recovery partition are booted instead of the kernel in the boot partition.\n4. Recovery binary is started by init. It finds command-line arguments in `/cache/recovery/command` that point it to the downloaded package.\n5. Recovery verifies the cryptographic signature of the package against the public keys in `/res/keys` (part of the RAM disk contained in the recovery partition).\n6. Data is pulled from the package and used to update the boot, system, and/or vendor partitions as necessary. One of the new files left on the system partition contains the contents of the new recovery partition.\n7. Device reboots normally.\n 1. The newly updated boot partition is loaded, and it mounts and starts executing binaries in the newly updated system partition.\n 2. As part of normal startup, the system checks the contents of the recovery partition against the desired contents (which were previously stored as a file in `/system`). They are different, so the recovery partition is reflashed with the desired contents. (On subsequent boots, the recovery partition already contains the new contents, so no reflash is necessary.)\n\n\nThe system update is complete! The update logs can be found in\n`/cache/recovery/last_log.`\u003cvar translate=\"no\"\u003e#\u003c/var\u003e.\n\nUpdate packages\n---------------\n\n\nAn update package is a `.zip` file that contains the executable binary\n`META-INF/com/google/android/update-binary`. After verifying the signature on the\npackage, `recovery` extracts this binary to `/tmp` and runs the binary,\npassing the following arguments:\n\n- **Update binary API version number**. If the arguments passed to the update binary change, this number increments.\n- **File descriptor of the *command pipe***. The update program can use this pipe to send commands back to the recovery binary, mostly for UI changes, such as indicating progress to the user.\n- **Filename of the update package `.zip` file**.\n\n\nAn update package can use any statically linked binary as the update binary. The OTA package\nconstruction tools use the updater program (`bootable/recovery/updater`), which\nprovides a simple scripting language that can do many installation tasks. You can substitute\nany other binary running on the device.\n\n\nFor details on the updater binary, edify syntax, and builtin functions, see\n[Inside OTA Packages](/docs/core/ota/nonab/inside_packages).\n\nMigrate from previous releases\n------------------------------\n\n\nWhen migrating from Android 2.3/3.0/4.0 release, the major change is the conversion of all the\ndevice-specific functionality from a set of C functions with predefined names to C++ objects.\nThe following table lists the old functions and the new methods that serve a roughly\nequivalent purpose:\n\n| C function | C++ method |\n|---------------------------------------------|----------------------------------------------------------|\n| device_recovery_start() | Device::RecoveryStart() |\n| device_toggle_display() device_reboot_now() | RecoveryUI::CheckKey() (also RecoveryUI::IsKeyPressed()) |\n| device_handle_key() | Device::HandleMenuKey() |\n| device_perform_action() | Device::InvokeMenuItem() |\n| device_wipe_data() | Device::WipeData() |\n| device_ui_init() | ScreenRecoveryUI::Init() |\n\n\nConversion of old functions to new methods should be reasonably straightforward. Don't forget\nto add the new `make_device()`\nfunction to create and return an instance of your new Device subclass."]]
