A partir de 27 de março de 2025, recomendamos usar android-latest-release em vez de aosp-main para criar e contribuir com o AOSP. Para mais informações, consulte Mudanças no AOSP.
Atualizações do sistema que não são A/B
Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
As atualizações não AB são uma metodologia descontinuada de OTA usada por dispositivos Android mais antigos (Android 6 e
anteriores). Esses dispositivos têm uma partição de recuperação dedicada que contém o software necessário para
descompactar um pacote de atualização transferido por download e aplicar a atualização às outras partições.
Em dispositivos Android mais antigos sem partições A/B, o espaço de inicialização geralmente contém as
seguintes partições:
- inicialização
-
Contém o kernel do Linux e um sistema de arquivos raiz mínimo (carregado em um disco RAM). Ele monta
o sistema e outras partições e inicia o ambiente de execução localizado na partição do sistema.
- system
-
Contém aplicativos e bibliotecas do sistema que têm código-fonte disponível no Android Open
Source Project (AOSP). Durante a operação normal, essa partição é montada como somente leitura. O conteúdo dela
muda apenas durante uma atualização OTA.
- fornecedor
-
Contém aplicativos e bibliotecas do sistema que não têm o código-fonte disponível
no Android Open Source Project (AOSP). Durante a operação normal, essa partição é montada
somente leitura. O conteúdo dela muda apenas durante uma atualização OTA.
- userdata
-
Armazena os dados salvos por aplicativos instalados pelo usuário etc. Essa partição normalmente não é
afetada pelo processo de atualização OTA.
- cache
-
Área de retenção temporária usada por alguns aplicativos (o acesso a essa partição requer permissões
especiais do app) e para o armazenamento de pacotes de atualização OTA transferidos por download. Outros programas usam esse
espaço com a expectativa de que os arquivos possam desaparecer a qualquer momento. Algumas instalações de pacotes OTA podem resultar na eliminação completa dessa partição. O cache também contém
os registros de atualização de uma atualização OTA.
- recuperação
-
Contém um segundo sistema Linux completo, incluindo um kernel e o binário de recuperação especial
que lê um pacote e usa o conteúdo dele para atualizar as outras partições.
- Diversos
-
Pequena partição usada pela recuperação para armazenar algumas informações sobre o que está sendo feito
caso o dispositivo seja reiniciado enquanto o pacote OTA está sendo aplicado.
Vida útil de uma atualização OTA
Uma atualização OTA típica contém as seguintes etapas:
-
O dispositivo faz o check-in regular com os servidores OTA e é notificado sobre a disponibilidade de uma
atualização, incluindo o URL do pacote de atualização e uma string de descrição para mostrar ao usuário.
-
Faz a atualização de downloads para uma partição de dados ou de cache, e a assinatura criptográfica é verificada
em relação aos certificados em
/system/etc/security/otacerts.zip. O usuário é solicitado a instalar a atualização.
-
O dispositivo é reinicializado no modo de recuperação, em que o kernel e o sistema na partição de recuperação
são inicializados em vez do kernel na partição de inicialização.
-
O binário de recuperação é iniciado pelo init. Ele encontra argumentos de linha de comando em
/cache/recovery/command que apontam para o pacote transferido.
-
A recuperação verifica a assinatura criptográfica do pacote em relação às chaves públicas em
/res/keys (parte do disco RAM contido na partição de recuperação).
-
Os dados são extraídos do pacote e usados para atualizar as partições de inicialização, do sistema e/ou do fornecedor, conforme necessário. Um dos novos arquivos deixados na partição do sistema contém o
conteúdo da nova partição de recuperação.
-
O dispositivo é reinicializado normalmente.
-
A partição de inicialização atualizada é carregada, montada e começa a executar binários
na partição do sistema atualizada.
-
Como parte da inicialização normal, o sistema verifica o conteúdo da partição de recuperação
em relação ao conteúdo desejado (que foi armazenado anteriormente como um arquivo em
/system). Como eles são diferentes, a partição de recuperação é reescrita com
o conteúdo desejado. (Em inicializações subsequentes, a partição de recuperação já contém o
novo conteúdo, portanto, não é necessário refazer o flash.)
A atualização do sistema foi concluída. Os registros de atualização podem ser encontrados em
/cache/recovery/last_log.#.
Atualizar pacotes
Um pacote de atualização é um arquivo .zip que contém o binário executável
META-INF/com/google/android/update-binary. Depois de verificar a assinatura no
pacote, o recovery extrai esse binário para /tmp e o executa,
transmitindo os seguintes argumentos:
-
Atualize o número da versão da API binária. Se os argumentos transmitidos para a mudança
de binário da atualização forem alterados, esse número vai aumentar.
-
Descritor de arquivos do canal de comando. O programa de atualização pode usar esse pipe para enviar comandos de volta ao binário de recuperação, principalmente
para mudanças na interface, como indicar o progresso ao usuário.
-
Nome do arquivo
.zip do pacote de atualização.
Um pacote de atualização pode usar qualquer binário vinculado estaticamente como o binário de atualização. As ferramentas de construção
do pacote OTA usam o programa de atualização (bootable/recovery/updater), que
oferece uma linguagem de script simples que pode realizar muitas tarefas de instalação. É possível substituir
qualquer outro binário em execução no dispositivo.
Para saber mais sobre o binário do atualizador, a sintaxe do edify e as funções integradas, consulte
Dentro dos pacotes OTA.
Migrar de versões anteriores
Ao migrar do Android 2.3/3.0/4.0, a principal mudança é a conversão de todas as
funcionalidades específicas do dispositivo de um conjunto de funções C com nomes predefinidos para objetos C++.
A tabela a seguir lista as funções antigas e os novos métodos que servem a uma finalidade
equivalente:
| Função C |
Método C++ |
| device_recovery_start() |
Device::RecoveryStart() |
device_toggle_display()
device_reboot_now()
|
RecoveryUI::CheckKey()
(também RecoveryUI::IsKeyPressed())
|
| device_handle_key() |
Device::HandleMenuKey() |
| device_perform_action() |
Device::InvokeMenuItem() |
| device_wipe_data() |
Device::WipeData() |
| device_ui_init() |
ScreenRecoveryUI::Init() |
A conversão de funções antigas em novos métodos precisa ser razoavelmente simples. Não se esqueça
de adicionar a nova função make_device()
para criar e retornar uma instância da nova subclasse de dispositivo.
O conteúdo e os exemplos de código nesta página estão sujeitos às licenças descritas na Licença de conteúdo. Java e OpenJDK são marcas registradas da Oracle e/ou suas afiliadas.
Última atualização 2025-07-27 UTC.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Não contém as informações de que eu preciso","missingTheInformationINeed","thumb-down"],["Muito complicado / etapas demais","tooComplicatedTooManySteps","thumb-down"],["Desatualizado","outOfDate","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Problema com as amostras / o código","samplesCodeIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 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."]]
