Descripción general

Los dispositivos Android incluyen varias particiones que cumplen distintas funciones en la de inicio rápido.

Particiones estándar

  • Partición boot. Esta partición contiene una imagen de kernel y se crea usando mkbootimg. Puedes usar una partición virtual para escribir en la memoria flash cualquiera de las imágenes directamente sin escribir en la memoria flash una nueva partición de inicio. Esta partición también contiene el ramdisk genérico en los dispositivos que se lanzaron antes Android 13

    • kernel. La partición virtual kernel reemplaza el kernel (zImage, zImage-dtb, Image.gz-dtb) escribiendo la nueva imagen del kernel sobre la anterior. imagen de kernel. Si el kernel de desarrollo proporcionado no es compatible, podrías debes actualizar la partición vendor, system o dtb (si la hay) con módulos de kernel asociados.

    • ramdisk. La partición virtual ramdisk reemplaza el ramdisk escribir la imagen del ramdisk nueva sobre la imagen del ramdisk anterior.

    La operación de reemplazo determina la ubicación de inicio de la imagen existente en una eMMC y copia la imagen nueva en esa ubicación. La imagen nueva (kernel o ramdisk) podría ser más grande que el existente; para liberar espacio, puede mover los datos después de la imagen o abandonar la operación un error.

  • Partición init_boot. Esta partición contiene el ramdisk genérico para dispositivos que se lanzan con Android 13 y versiones posteriores.

  • Partición system. Esta partición contiene el framework de Android.

  • Partición odm. Esta partición contiene el fabricante del diseño original (ODM) personalizaciones a los paquetes de asistencia para la junta del proveedor (BSP) del sistema en chip (SoC). Estas personalizaciones permiten que los ODM reemplacen o personalicen componentes del SoC. implementar módulos de kernel para componentes específicos de la placa, daemons Funciones específicas de ODM en capas de abstracción de hardware (HAL) Esta partición está opcional; por lo general, se usa para contener personalizaciones, de modo que los dispositivos usar una sola imagen de proveedor para varios SKU de hardware. Para obtener información detallada, consulta ODM. Particiones.

  • Partición odm_dlkm. Esta partición está diseñada para almacenar el kernel de ODM módulos. Almacenar módulos de kernel de ODM en la partición odm_dlkm (en lugar de a la partición odm) permite actualizar los módulos de kernel ODM sin actualizar la partición odm.

  • Partición recovery. Esta partición almacena la imagen de recuperación, que es se inician durante el proceso inalámbrico. Dispositivos que admiten sin inconvenientes en las actualizaciones pueden almacenar las imágenes de recuperación ramdisk incluido en la imagen boot o init_boot (en lugar de un disco imagen).

  • Partición cache. Esta partición almacena datos temporales y es opcional si un dispositivo usa actualizaciones fluidas. No es necesario que la partición de caché que se pueden escribir desde el bootloader, pero deben borrarse. La partición El tamaño depende del tipo de dispositivo y la disponibilidad de espacio en userdata. por lo general, entre 50 MB y 100 MB es suficiente.

  • Partición misc. Esta partición la usa la partición de recuperación y está 4 KB o más grande

  • Partición userdata. Esta partición contiene apps instaladas por el usuario y datos, incluidos los de personalización.

  • Partición metadata. Esta partición se usa para almacenar los metadatos de encriptación cuando el dispositivo usa metadatos encriptación. El tamaño es El tamaño máximo es de 16 MB. No está encriptado y no se capturan instantáneas de sus datos. Se borrarán cuando se restablezca la configuración de fábrica del dispositivo. El uso de esta partición es estrictamente limitado.

  • Partición vendor. Esta partición contiene cualquier objeto binario que no distribuible a AOSP. Si el dispositivo no contiene información de propiedad exclusiva, puedes omitir esta partición.

  • Partición vendor_dlkm. Esta partición se dedica a almacenar datos módulos de kernel. Almacena módulos de kernel del proveedor en la partición vendor_dlkm (a diferencia de la partición vendor) permite actualizar los archivos módulos sin actualizar la partición vendor.

  • Partición radio. Esta partición contiene la imagen de radio y es necesaria solo para dispositivos que incluyan una radio con software específico de radio o una partición dedicada.

  • Partición tos. Esta partición almacena la imagen binaria de Trusty OS y solo se usa si el dispositivo incluye Trusty. Para obtener información detallada, consulta las Condiciones del Servicio. Particiones.

  • Partición pvmfw. Esta partición almacena la máquina virtual protegida Firmware (pvmfw), que es el primer código que se ejecuta en VMs protegidas. Consulta Firmware de máquina virtual protegida para obtener más detalles.

Particiones dinámicas

Los dispositivos que ejecutan Android 11 y versiones posteriores admiten particiones dinámicas, que son un sistema de partición del espacio de usuario para Android que permite crear, cambiar el tamaño o destruir particiones durante una conexión inalámbrica actualizaciones. Para obtener más información, consulta particiones.

Designa particiones críticas

Si el dispositivo requiere particiones o datos específicos para ejecutarse, debes designarlos esas particiones o datos como protegidos o reinstalables, es decir, Se pueden volver a compilar, proporcionar o extraer con un comando fastboot oem. Esto incluye datos como la configuración específica de fábrica por dispositivo, números de serie, de calibración y más.

Cambios en Android 11

Android 11 incluye varios cambios en las particiones, incluidas las restricciones de vinculación a bibliotecas y las nuevas variantes de imagen de Soong.

Diseño de partición de Android

Figura 1: Diseño de partición en Android 11

  • Imagen de sistema única (SSI). Una nueva imagen conceptual que contiene la Imágenes system y system_ext. Cuando estas particiones son comunes para un conjunto de los dispositivos de destino, estos pueden compartir el SSI y omitir la compilación Imágenes system y system_ext.

  • Partición system_ext. Una partición nueva que puede usar recursos system y puede incluir módulos de sistema que hagan lo siguiente:

    • Extiende los módulos del sistema del AOSP en la partición system. Recomendaciones subir esos módulos a AOSP para que se puedan instalar en system para la partición más reciente.

    • Agrupa módulos específicos de OEM o SoC. Te recomendamos desagrupar esos módulos. para que puedan instalarse en la partición product o vendor.

  • Partición system. Imagen del sistema común que se usa para los productos del OEM. Mié recomendamos quitar los módulos propietarios de la partición system, ya sea ascendiéndolas a AOSP o moviéndolas a la partición system_ext

  • Partición product. Esta partición ahora puede usar las interfaces permitidas para instalar módulos específicos del producto que no estén incluidos en ningún otro y particiones.

Cambios en VNDK

El kit de desarrollo nativo del proveedor (VNDK) es un conjunto de bibliotecas instaladas en la partición system y diseñadas exclusivamente para que los proveedores implementen sus HAL.

  • En Android 10 y versiones anteriores, la partición vendor puede vincularse a bibliotecas de VNDK en la partición system, pero no se puede vincular a otras bibliotecas en system por cada partición. Los módulos nativos en la partición product se pueden vincular a cualquier biblioteca en la partición system.

  • En Android 11 y versiones posteriores, product y vendor Las particiones pueden vincularse a bibliotecas de VNDK en la partición system, pero no vínculo a otras bibliotecas en la partición system.

Variantes de productos de Soong

El sistema de compilación de Soong usa variantes de imágenes para dividir las dependencias de compilación. Los módulos nativos (/build/soong/cc) pueden mutar el sistema módulos de procesos a la variante principal y los módulos de procesos de proveedores a la variante de proveedor; un módulo en una variante de imagen no puede vincularse a otros módulos en una variante de imagen diferente.

  • En Android 10 o versiones anteriores, un módulo del sistema crea automáticamente variantes principales. También puede crear variantes de proveedores definiendo vendor_available: true en su Android.bp archivos; esto permite que los módulos de proveedores se vinculen con módulos del sistema. Las bibliotecas del VNDK, que son variantes de proveedores de las bibliotecas system, también pueden Crea variantes de proveedores para módulos de proveedores definiendo vendor_available: true en sus archivos Android.bp (consulta ejemplo).

  • En Android 11, un módulo del sistema también puede crear una variante de producto (además de las variantes principales y de proveedor) de la siguiente manera: definir vendor_available: true

  • En Android 12 o versiones posteriores, un módulo del sistema con vendor_available: true crea una variante de proveedor, además de la versión principal. variante. Para crear una variante de producto, product_available: true debe cumplir con los siguientes requisitos: definido. Algunas bibliotecas del VNDK sin product_available: true no son disponibles para los módulos de productos.