A partir del 27 de marzo de 2025, te recomendamos que uses android-latest-release en lugar de aosp-main para compilar y contribuir a AOSP. Para obtener más información, consulta Cambios en AOSP.
Actualizaciones del sistema que no son de A/B
Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
Las actualizaciones que no son de AB son una metodología OTA obsoleta que usan los dispositivos Android más antiguos (Android 6 y versiones anteriores). Estos dispositivos tienen una partición de recuperación dedicada que contiene el software necesario para descomprimir un paquete de actualización descargado y aplicar la actualización a las otras particiones.
En dispositivos Android más antiguos sin particiones A/B, el espacio de la memoria flash suele contener las siguientes particiones:
- inicio
-
Contiene el kernel de Linux y un sistema de archivos raíz mínimo (cargado en un disco RAM). Activa el sistema y otras particiones, y comienza el entorno de ejecución ubicado en la partición del sistema.
- sistema
-
Contiene aplicaciones y bibliotecas del sistema que tienen código fuente disponible en el Proyecto de código abierto de Android (AOSP). Durante el funcionamiento normal, esta partición se activa de solo lectura, y su contenido solo cambia durante una actualización inalámbrica.
- de proveedor
-
Contiene aplicaciones y bibliotecas del sistema que no tienen código fuente disponible
en el Proyecto de código abierto de Android (AOSP). Durante el funcionamiento normal, esta partición se activa en modo de solo lectura, y su contenido cambia solo durante una actualización inalámbrica.
- userdata
-
Almacena los datos guardados por las aplicaciones que instaló el usuario, etcétera. Por lo general, el proceso de actualización OTA no afecta a esta partición.
- caché
-
Área de retención temporal que usan algunas aplicaciones (acceder a esta partición requiere permisos especiales de la app) y para el almacenamiento de paquetes de actualización OTA descargados. Otros programas usan este espacio con la expectativa de que los archivos puedan desaparecer en cualquier momento. Algunas instalaciones de paquetes OTA pueden borrar esta partición por completo. La caché también contiene los registros de actualización de una actualización OTA.
- recuperación
-
Contiene un segundo sistema Linux completo, incluido un kernel y el binario de recuperación especial
que lee un paquete y usa su contenido para actualizar las otras particiones.
- misc
-
Es una partición pequeña que usa la recuperación para ocultar información sobre lo que está haciendo en caso de que se reinicie el dispositivo mientras se aplica el paquete OTA.
Vida útil de una actualización OTA
Una actualización OTA típica contiene los siguientes pasos:
-
El dispositivo realiza un registro periódico en los servidores OTA y recibe una notificación sobre la disponibilidad de una actualización, incluida la URL del paquete de actualización y una cadena de descripción para mostrarle al usuario.
-
Actualiza las descargas a una partición de caché o de datos, y su firma criptográfica se verifica con los certificados de
/system/etc/security/otacerts.zip. Se le solicita al usuario que instale la actualización.
-
El dispositivo se reinicia en el modo de recuperación, en el que se inician el kernel y el sistema de la partición de recuperación en lugar del kernel de la partición de inicio.
-
init inicia el binario de recuperación. Encuentra argumentos de línea de comandos en
/cache/recovery/command que lo dirigen al paquete descargado.
-
La recuperación verifica la firma criptográfica del paquete con las claves públicas en
/res/keys (parte del disco de RAM contenido en la partición de recuperación).
-
Los datos se extraen del paquete y se usan para actualizar las particiones de inicio, del sistema o del proveedor según sea necesario. Uno de los archivos nuevos que quedan en la partición del sistema contiene el contenido de la nueva partición de recuperación.
-
El dispositivo se reinicia de forma normal.
-
Se carga la partición de inicio actualizada, se activa y comienza a ejecutar objetos binarios
en la partición del sistema actualizada.
-
Como parte del inicio normal, el sistema verifica el contenido de la partición de recuperación con el contenido deseado (que antes se almacenaba como un archivo en
/system). Son diferentes, por lo que la partición de recuperación se vuelve a escribir con el contenido deseado. (En los arranques posteriores, la partición de recuperación ya contiene el contenido nuevo, por lo que no es necesario volver a escribir en la memoria flash).
Se completó la actualización del sistema. Los registros de actualización se pueden encontrar en /cache/recovery/last_log.#.
Actualiza los paquetes
Un paquete de actualización es un archivo .zip que contiene el objeto binario ejecutable META-INF/com/google/android/update-binary. Después de verificar la firma en el
paquete, recovery extrae este objeto binario a /tmp y lo ejecuta,
pasando los siguientes argumentos:
-
Actualiza el número de versión de la API binaria. Si cambian los argumentos que se pasan al binario de actualización, este número aumenta.
-
Es el descriptor de archivo del canal de comandos. El programa de actualización puede usar este canal para enviar comandos al binario de recuperación, principalmente para cambios en la IU, como indicar el progreso al usuario.
-
Nombre del archivo
.zip del paquete de actualización.
Un paquete de actualización puede usar cualquier objeto binario vinculado estáticamente como el objeto binario de actualización. Las herramientas de compilación de paquetes OTA usan el programa de actualización (bootable/recovery/updater), que proporciona un lenguaje de secuencias de comandos simple que puede realizar muchas tareas de instalación. Puedes reemplazar cualquier otro objeto binario que se ejecute en el dispositivo.
Para obtener detalles sobre el binario del actualizador, la sintaxis de edify y las funciones integradas, consulta Dentro de los paquetes inalámbricos.
Cómo migrar desde versiones anteriores
Cuando se migra desde la versión de Android 2.3/3.0/4.0, el cambio principal es la conversión de todas las funciones específicas del dispositivo de un conjunto de funciones C con nombres predefinidos a objetos C++.
En la siguiente tabla, se enumeran las funciones anteriores y los métodos nuevos que tienen un propósito aproximadamente equivalente:
| Función C |
Método de C++ |
| device_recovery_start() |
Device::RecoveryStart() |
device_toggle_display()
device_reboot_now()
|
RecoveryUI::CheckKey()
(también RecoveryUI::IsKeyPressed())
|
| device_handle_key() |
Device::HandleMenuKey() |
| device_perform_action() |
Device::InvokeMenuItem() |
| device_wipe_data() |
Device::WipeData() |
| device_ui_init() |
ScreenRecoveryUI::Init() |
La conversión de funciones anteriores a métodos nuevos debería ser bastante sencilla. No olvides agregar la nueva función make_device() para crear y mostrar una instancia de tu nueva subclase de Device.
El contenido y las muestras de código que aparecen en esta página están sujetas a las licencias que se describen en la Licencia de Contenido. Java y OpenJDK son marcas registradas de Oracle o sus afiliados.
Última actualización: 2025-07-27 (UTC)
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Falta la información que necesito","missingTheInformationINeed","thumb-down"],["Muy complicado o demasiados pasos","tooComplicatedTooManySteps","thumb-down"],["Desactualizado","outOfDate","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Problema con las muestras o los códigos","samplesCodeIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 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."]]
