Guía para fabricantes sobre la seguridad a largo plazo de Android

En esta guía, se describen las prácticas recomendadas que recomienda Google para aplicar parches de seguridad que evalúa el conjunto de pruebas de compatibilidad (CTS) de Android. Está destinado a los fabricantes de equipos OEM compatibles con Android (fabricantes) que tendrán asistencia por más de tres años, como vehículos, TVs, decodificadores y electrodomésticos. Esta guía no está destinada a los usuarios finales (por ejemplo, los propietarios de vehículos).

Confirmaciones y renuncias de responsabilidad

Esta guía no vincula a Google ni a otros fabricantes de forma legal ni contractual, y no pretende ser un conjunto de requisitos. En cambio, esta guía es una ayuda didáctica que describe las prácticas recomendadas.

Comentarios

Esta guía no tiene como objetivo ser exhaustiva; se planifican revisiones adicionales. Envía comentarios a manufacturers-guide-android@googlegroups.com.

Glosario

Término Definición
ACC Compromiso de compatibilidad con Android. Anteriormente, se conocía como el Acuerdo de Antifragmentación (AFA) de Android.
AOSP Proyecto de código abierto de Android
ASB Boletín de seguridad de Android
BSP Paquete de asistencia para la placa
CDD Documento de definición de compatibilidad
CTS Conjunto de pruebas de compatibilidad (CTS)
FOTA firmware de forma inalámbrica
GPS sistema de posicionamiento global
MISRA Motor Industry Software Reliability Association
NIST Instituto Nacional de Estándares y Tecnología
OBD diagnóstico a bordo (OBD-II es una mejora con respecto a OBD-I en cuanto a capacidad y estandarización)
OEM fabricante del equipo original
SO Sistema operativo
SEI Software Engineering Institute
SoC sistema en chip
SOP inicio de la producción
SPL Nivel del parche de seguridad
TPMS sistema de supervisión de la presión de los neumáticos

Información acerca del SO Android

Android es una pila de software completa de código abierto basada en Linux diseñada para una variedad de dispositivos y factores de forma. Desde su primera versión en 2008, Android se convirtió en el sistema operativo (SO) más popular, con más de 1,400 millones de dispositivos en todo el mundo (2016). Aproximadamente el 67% de esos dispositivos usa Android 5.0 (Lollipop) o versiones posteriores a marzo de 2017 (las cifras más recientes están disponibles en el panel de Android). Si bien la gran mayoría de los dispositivos son teléfonos celulares y tablets, Android está creciendo en relojes inteligentes, TVs y dispositivos de infoentretenimiento (IVI) para vehículos.

La cantidad de apps para Android disponibles en Google Play Store alcanzó más de 2.2 millones (2016). El desarrollo de apps para Android está respaldado por el programa de compatibilidad de Android, que define un conjunto de requisitos a través del Documento de definición de compatibilidad (CDD) y proporciona herramientas de prueba a través del Conjunto de pruebas de compatibilidad (CTS). Los programas de compatibilidad de Android garantizan que cualquier app para Android se pueda ejecutar en cualquier dispositivo compatible con Android que admita las funciones requeridas para la app.

Google lanza nuevas versiones del SO, actualizaciones de seguridad del SO y información sobre las vulnerabilidades descubiertas con regularidad. Los fabricantes deben revisar el Boletín de seguridad de Android para determinar la aplicabilidad de estas actualizaciones a los productos compatibles con el SO Android. Para revisar la seguridad, la compatibilidad y los sistemas de compilación de Android, consulta los siguientes vínculos:

Información acerca de los vehículos conectados (productos canónicos de larga duración)

Los vehículos comenzaron a conectarse con la introducción de la radio AM en la década de 1920. A partir de ahí, la cantidad de conexiones físicas e inalámbricas externas comenzó a crecer a medida que los reguladores y los fabricantes de automóviles recurrieron a la electrónica para facilitar el diagnóstico y el servicio (por ejemplo, el puerto OBD-II), mejorar la seguridad (por ejemplo, el TPMS) y cumplir con los objetivos de economía de combustible. La siguiente ola de conectividad introdujo funciones de conveniencia para el conductor, como la entrada sin llave remota, los sistemas de telemática y las funciones avanzadas de infoentretenimiento, como Bluetooth, Wi-Fi y proyección de smartphones. Hoy en día, los sensores y la conectividad integrados (por ejemplo, el GPS) admiten sistemas de conducción semiautónoma y segura.

A medida que aumenta la cantidad de conexiones de vehículos, también lo hace el área de la posible superficie de ataque del vehículo. Las conexiones traen consigo una serie de inquietudes de seguridad cibernética similares a las de la electrónica de consumo. Sin embargo, si bien los reinicios, las actualizaciones diarias de parches y los comportamientos inexplicables son la norma para la electrónica de consumo, no son coherentes para los productos con sistemas de seguridad esenciales, como los vehículos.

Los fabricantes deben adoptar un enfoque proactivo para garantizar la postura de seguridad y protección continua de un producto en el campo. En resumen, los fabricantes deben estar al tanto de las vulnerabilidades de seguridad conocidas del producto y adoptar un enfoque basado en riesgos para abordarlas.

Garantiza la seguridad a largo plazo

Un vehículo conectado suele tener una o más unidades de control electrónico (ECU) que incluyen varios componentes de software, como el SO, bibliotecas, utilidades, etcétera. Los fabricantes deben hacer un seguimiento de esos componentes y, con un análisis proactivo, identificar las vulnerabilidades publicadas conocidas, incluidas las siguientes:

  • Evaluar el producto periódicamente en función de la base de datos de vulnerabilidades y exposiciones comunes (CVE)
  • Recopilación de información para detectar fallas de seguridad relacionadas con los productos
  • Pruebas de seguridad
  • Analizan de forma activa los Boletines de seguridad de Android.

Ejemplos de actualizaciones de parches de seguridad y del SO (IVI con Android):

Figura 1: Ejemplo de lanzamiento de actualizaciones importantes del SO y de seguridad durante el ciclo de vida del vehículo

# Paso Actividades

①

 Rama de desarrollo El fabricante selecciona una versión de Android (Android X). En este ejemplo, "Android X" se convierte en la base de lo que se enviará en el vehículo dos años antes del inicio inicial de la producción (SOP).
② Lanzamiento inicial Algunos meses antes de que Android X se convierta en la primera versión del SO que se envía en el producto, las actualizaciones de seguridad se toman de los boletines de seguridad de Android (ASB) y, posiblemente, de otras fuentes que el fabricante considere valiosas. Y2 = el segundo boletín de seguridad para la versión X de Android, que el fabricante aplica (portabilidad a versiones anteriores) a Android X. Esta actualización se envía en el producto y el reloj de producción comienza a marcar en el año cero con Android X.y2.

En este ejemplo, el fabricante tomó la decisión de no enviar la versión anual más reciente de Android X+1. Los motivos para enviar la versión más reciente incluyen agregar funciones nuevas, abordar nuevas vulnerabilidades de seguridad o enviar servicios de Google o de terceros que requieren la versión más reciente de Android. Los motivos en contra de realizar envíos con la versión más reciente son la falta de tiempo inherente al proceso de desarrollo y lanzamiento del vehículo necesario para integrar, probar y validar los cambios, incluido el cumplimiento de todos los requisitos reglamentarios y de certificación.
③ Actualización completa del SO Después del SOP, el fabricante lanza la actualización del SO Android X+2, que son dos versiones de Android después de la versión que se usó para el producto inicial (Android X0). Las actualizaciones de seguridad de ASB están disponibles para el nivel de API (a partir de la fecha de envío), por lo que la actualización se envía como X+2.y0 aproximadamente 1.25 años después de la SOP. Es posible que esta actualización del SO sea o no compatible con los productos implementados. Si es así, se podría crear un plan para actualizar los vehículos implementados.

A menos que se hayan celebrado otros acuerdos comerciales, la decisión de realizar una actualización completa del SO es totalmente discrecional del fabricante.
④ Actualización de seguridad Dos años después del ciclo de vida de producción del vehículo, el fabricante aplica parches al SO Android X+2. Esta decisión se basa en la evaluación de riesgos del fabricante. El fabricante elige la tercera actualización de seguridad de ASB para la versión X+2 como base de la actualización. Los productos que reciben la actualización de seguridad ahora tienen el nivel de parche de seguridad de Android y el SO (X+2.y3).

Si bien los fabricantes pueden seleccionar parches de seguridad individuales de cualquier ASB, deben corregir todos los problemas obligatorios del boletín para usar el nivel de parche de seguridad (SPL) de Android asociado con el boletín (por ejemplo, 2017-02-05). Es responsabilidad del fabricante realizar la portabilidad a versiones anteriores y la versión de seguridad del producto compatible.
⑤ Actualización completa del SO Una repetición del paso 3 (Actualización completa del SO), la segunda actualización completa del SO lleva el producto a Android X+4, tres años después del ciclo de vida de producción del vehículo. Ahora, el fabricante equilibra los requisitos de hardware más recientes de una versión reciente de Android con el hardware del producto, y el usuario se beneficia de un SO Android actualizado. El fabricante lanza una actualización sin actualizaciones de seguridad, por lo que el producto ahora está en el nivel (X+4.y0) del SO + el nivel de parche de seguridad de Android.

En este ejemplo, debido a limitaciones de hardware, X+4 es la última versión principal de Android que se proporcionará para este producto, aunque más de 6 años de vida útil esperada para el vehículo aún requieren compatibilidad de seguridad.
⑥ Actualización de seguridad Repite el paso 4 (Actualización de seguridad). El fabricante tiene la tarea de tomar las actualizaciones de seguridad de ASB de una versión mucho más reciente de Android (X+6) y portar algunas o todas esas actualizaciones a Android X+4. Es responsabilidad del fabricante combinar, integrar y realizar las actualizaciones (o contratar a un tercero). Además, el fabricante debe tener en cuenta que los problemas de seguridad en las versiones de Android que ya no son compatibles no se abordan en el ASB.
⑦ Actualización de seguridad Ocho años después del ciclo de vida de producción del vehículo, cuatro versiones de Android desde la última actualización del SO en el paso 5 (Actualización completa del SO) y diez años desde que se especificó Android X, la responsabilidad de seleccionar y portar parches de seguridad recae por completo en el fabricante para esas versiones que tengan más de tres años desde el lanzamiento público a nivel de API.

Prácticas recomendadas de seguridad

Para dificultar los ataques de seguridad, Google recomienda y emplea el uso de prácticas recomendadas generalmente aceptadas para la seguridad y la ingeniería de software, como se describe en Implementación de seguridad.

Lineamientos de seguridad

Estas son algunas prácticas recomendadas para la seguridad:

  • Usa las versiones más recientes de las bibliotecas externas y los componentes de código abierto.
  • No incluyas funciones de depuración invasivas en las versiones de lanzamiento del SO.
  • Quita las funciones que no se usan (para reducir la superficie de ataque innecesaria).
  • Usa el principio de privilegio mínimo y otras prácticas recomendadas para el desarrollo de apps para Android.

Lineamientos para el desarrollo de software

Entre las prácticas recomendadas para el desarrollo de software seguro durante el ciclo de vida del sistema, se incluyen las siguientes:

  • Realiza un modelado de amenazas para clasificar e identificar recursos, amenazas y posibles mitigaciones.
  • Realiza una revisión de la arquitectura o el diseño para garantizar un diseño seguro y sólido.
  • Realiza revisiones de código con regularidad para identificar antipatrones y errores lo antes posible.
  • Diseñar, implementar y ejecutar pruebas de unidades con alta cobertura de código, incluidos los siguientes:
    • Pruebas funcionales (incluidos los casos de prueba negativos)
    • Pruebas de regresión regulares (para garantizar que no vuelvan a aparecer errores corregidos)
    • Prueba de fuzz (como parte del paquete de pruebas de unidades)
  • Usa herramientas de análisis de código fuente estático (scan-build, lint, etc.) para identificar posibles problemas.
  • Usa herramientas de análisis de código fuente dinámico, como AddressSanitizer, UndefinedBehaviorSanitizer y FORTIFY_SOURCE (para componentes nativos), para identificar y mitigar posibles problemas durante el desarrollo del sistema.
  • Tener una estrategia de administración para el código fuente del software y la configuración o versión de lanzamiento
  • Tener una estrategia de administración de parches para la generación y la implementación de parches de software

Política de portabilidad a versiones anteriores de seguridad

Actualmente, Google proporciona asistencia activa para la portabilidad de seguridad de las vulnerabilidades de seguridad descubiertas y denunciadas durante tres (3) años a partir de la versión pública del nivel de API. La asistencia activa consiste en lo siguiente:

  1. Recibir e investigar informes de vulnerabilidades
  2. Crear, probar y lanzar actualizaciones de seguridad
  3. Proporcionar lanzamientos recurrentes de actualizaciones de seguridad y detalles de boletines de seguridad
  4. Realiza la evaluación de gravedad según los lineamientos establecidos.

Después de tres años desde la fecha de lanzamiento público del nivel de API, Google recomienda los siguientes lineamientos:

  • Usa un tercero (como el proveedor de SoC o el proveedor de Kernel) para obtener compatibilidad con portabilidad a versiones anteriores para actualizaciones de seguridad del SO que tengan más de tres años desde el lanzamiento de la API.
  • Usa un tercero para realizar revisiones de código con los ASBs proporcionados públicamente. Si bien los ASBs identifican vulnerabilidades para la versión compatible actual, un fabricante puede usar la información proporcionada para comparar las actualizaciones publicadas recientemente con las versiones anteriores. Estos datos se pueden usar para realizar un análisis de impacto y, potencialmente, generar parches similares para versiones de SO más antiguas que tres años desde el lanzamiento de la API.
  • Cuando corresponda, sube actualizaciones de seguridad al Proyecto de código abierto de Android (AOSP).
  • El fabricante debe coordinar el control de las actualizaciones de seguridad del código específico del proveedor (por ejemplo, el código propietario específico del dispositivo).
  • El fabricante debe unirse al grupo de notificaciones de vista previa para socios del NDA de boletines de seguridad de Android (requiere la firma de acuerdos legales, como el NDA para desarrolladores). Los boletines deben incluir lo siguiente:
    • Anuncios
    • Resumen de los problemas por nivel de parche, incluidos CVE y gravedad
    • Detalles de la vulnerabilidad cuando corresponda

Referencias adicionales

Para obtener instrucciones sobre la programación segura y las prácticas de desarrollo de software, consulta lo siguiente:

Google recomienda el uso de las siguientes prácticas recomendadas.

Por lo general, se recomienda que cualquier producto conectado se lance con la versión más reciente del SO, y el fabricante debe intentar usar la versión más reciente del SO antes de lanzar el producto. Si bien es necesario bloquear la versión para mejorar la estabilidad antes de las pruebas y la validación, el fabricante debe equilibrar la estabilidad del producto obtenida de versiones anteriores del SO con versiones más recientes que tengan menos vulnerabilidades de seguridad conocidas y protecciones de seguridad mejoradas.

Entre los lineamientos recomendados, se incluyen los siguientes:

  • Debido a los largos tiempos de desarrollo inherentes al proceso de desarrollo de vehículos, es posible que los fabricantes necesiten lanzar con la versión n-2 del SO o una anterior.
  • Mantener la conformidad con la compatibilidad de Android para cada versión del SO Android lanzada con una campaña inalámbrica (OTA)
  • Implementa productos compatibles con la actualización de firmware por aire (FOTA) de Android para obtener actualizaciones rápidas y fáciles de usar. La actualización OTA debe realizarse con prácticas recomendadas de seguridad, como la firma de código y la conexión TLS entre el producto y el backend de TI.
  • Envía vulnerabilidades de seguridad de Android identificadas de forma independiente al equipo de Seguridad de Android.

Nota: Google consideró notificaciones específicas del tipo de dispositivo o de la industria en los boletines de seguridad de Android. Sin embargo, como Google no conoce el kernel, los controladores ni los conjuntos de chips de un dispositivo determinado (vehículo, TV, wearable, teléfono, etc.), Google no tiene una forma determinista de etiquetar un problema de seguridad determinado con un tipo de dispositivo.

El fabricante debe hacer todo lo posible por usar la versión más reciente del SO o las actualizaciones de seguridad para la versión en uso durante las mejoras del ciclo de vida del producto. Las actualizaciones se pueden realizar durante las actualizaciones periódicas y recurrentes de productos o para aplicar parches que aborden problemas de calidad o de otro tipo. Entre las prácticas recomendadas, se incluyen las siguientes:

  • Crea un plan para abordar las actualizaciones de controladores, kernels y protocolos.
  • Usa un método adecuado para la industria para proporcionar actualizaciones a los vehículos implementados.

Documento de definición de compatibilidad (CDD)

En el Documento de definición de compatibilidad (CDD), se describen los requisitos para que un dispositivo se considere compatible con Android. El CDD es público y está disponible para todos. Puedes descargar versiones del CDD desde Android 1.6 hasta la versión más reciente en source.android.com.

Para satisfacer estos requisitos de un producto, se deben seguir los siguientes pasos básicos:

  1. El socio firma el Compromiso de Compatibilidad con Android (ACC) con Google. Luego, se asigna un asesor de soluciones técnicas (TSC) como guía.
  2. El socio completa la revisión del CDD para la versión del SO de Android del producto.
  3. El socio ejecuta y envía los resultados del CTS (que se describen a continuación) hasta que sean aceptables para la compatibilidad con Android.

Conjunto de pruebas de compatibilidad (CTS)

La herramienta de prueba del Conjunto de pruebas de compatibilidad (CTS) verifica que la implementación de un producto sea compatible con Android y que se incluyan los parches de seguridad más recientes. El CTS es público, de código abierto y está disponible para todos. Puedes descargar versiones de CTS desde Android 1.6 hasta la versión más reciente en source.android.com.

Cada compilación de software de Android que se lanza al público (imágenes de instalación de fábrica y actualización de campo) debe demostrar la compatibilidad con Android a través de los resultados de CTS. Por ejemplo, si el dispositivo ejecuta Android 7.1, se debe hacer referencia a la versión más reciente correspondiente de CDD 7.1 y CTS 7.1 cuando se crea y prueba una imagen de compilación de intent de lanzamiento. Se recomienda encarecidamente a los fabricantes que usen CTS con anticipación y con frecuencia para identificar y solucionar problemas.

NOTA: Es posible que los socios que firmen otros acuerdos, como los Servicios Móviles de Google (GMS), deban cumplir con otros requisitos.

Flujo de trabajo de CTS

El flujo de trabajo de CTS implica configurar el entorno de pruebas, ejecutar pruebas, interpretar los resultados y comprender el código fuente de CTS. Los siguientes lineamientos están diseñados para ayudar a los usuarios de CTS (por ejemplo, desarrolladores y fabricantes) a usar el CTS de manera eficaz y eficiente.

  • Ejecuta pruebas con frecuencia. CTS está diseñado como una herramienta automatizada que se integra en tu sistema de compilación. Ejecutar CTS con frecuencia puede ayudarte a encontrar defectos con rapidez y rapidez cuando se producen degradaciones o regresiones del software.
  • Descarga y examina el código fuente de CTS. El código fuente completo de CTS es software de código abierto que cualquier persona puede descargar y usar (el código fuente descargado se puede compilar y ejecutar por completo). Cuando una prueba falla en el dispositivo, examinar la sección relevante del código fuente puede ayudarte a identificar el motivo.
  • Obtén la versión más reciente de CTS. Las nuevas versiones de Android pueden actualizar el CTS con correcciones de errores, mejoras y pruebas nuevas. Consulta la sección Descargas de CTS con frecuencia y actualiza tu programa de CTS según sea necesario. El fabricante y Google deben acordar la versión de CTS que se aprobará para el lanzamiento del producto, ya que el producto debe inmovilizarse en algún momento mientras el CTS se sigue actualizando.

Pasa el CTS

En el caso de un producto compatible con Android, Google se asegura de que los resultados de las pruebas del CTS y del verificador de CTS del dispositivo sean aceptables. En principio, todas las pruebas deben aprobarse. Sin embargo, Google revisará las pruebas que fallan por motivos distintos a que el dispositivo no cumpla con los requisitos de compatibilidad de Android. Durante este proceso, sucede lo siguiente:

  1. El fabricante proporciona a Google los parches de CTS propuestos, las validaciones de parches y las justificaciones para demostrar el argumento.
  2. Google examina el material enviado y, si se acepta, actualiza las pruebas de CTS relevantes para que el dispositivo apruebe la próxima revisión del CTS.

Si una prueba de CTS falla repentinamente después de aplicar un parche de seguridad, el fabricante debe modificar el parche para que no afecte la compatibilidad O mostrar que la prueba es incorrecta y proporcionar una solución para la prueba (como se describió anteriormente).

El CTS permanecerá abierto para las revisiones de las correcciones de prueba. Por ejemplo, Android 4.4 sigue aceptando correcciones (consulta https://android-review.googlesource.com/#/c/273371/).

Preguntas frecuentes

P.: ¿Quién es responsable de aplicar actualizaciones de seguridad a una implementación específica de Android?

A: El fabricante que proporciona el dispositivo directamente es responsable. Esta entidad no es Google, que publica actualizaciones de seguridad en AOSP y no para un dispositivo específico (como un vehículo).

P.: ¿Cómo maneja Google los problemas de seguridad en Android?

R.: Google investiga continuamente los problemas y desarrolla posibles soluciones, que pone a disposición de todos los niveles de API compatibles como parte del proceso de actualización de seguridad habitual. Desde agosto de 2015, Google mantiene una cadencia regular de publicación de boletines y vínculos a actualizaciones en source.android.com. Google también publica actualizaciones de seguridad como parte de las versiones principales del SO. Consulta también la política de portabilidad a versiones anteriores de seguridad.

P.: Si un fabricante integró todos los parches de AOSP de un ASB, pero no integró los parches del proveedor de BSP mencionado en el mismo boletín, ¿puede aumentar el nivel de seguridad (por ejemplo, aplicar el parche correspondiente a la plataforma o compilación)?

R.: Para declarar un nivel de parche de seguridad (SPL) de Android, el fabricante debe abordar todos los problemas necesarios que se publican en el Boletín de seguridad de Android (incluidos los boletines anteriores) y asignarlos a un SPL de Android en particular. Por ejemplo, un fabricante que usa el boletín de seguridad de marzo de 2017 (SPL del 1 de marzo de 2017) abordó todos los problemas obligatorios documentados en el boletín de marzo de 2017 para ese SPL y todas las actualizaciones anteriores, incluidas las actualizaciones específicas del dispositivo para todos los boletines de seguridad de Android anteriores, incluidas las actualizaciones específicas del dispositivo asociadas al SPL del 5 de febrero de 2017.

P.: ¿Qué sucede cuando el fabricante no está de acuerdo con las actualizaciones de seguridad que proporciona el proveedor de la BSP O cuando los proveedores no proporcionan las actualizaciones de seguridad que exige una ASB?

R.: Un ASB describe las vulnerabilidades de seguridad (enumeradas por una lista de CVE) y, a menudo, proporciona pruebas de seguridad coincidentes. El objetivo es garantizar que las vulnerabilidades enumeradas ya no se puedan reproducir en un dispositivo y que este pueda aprobar las pruebas de seguridad asociadas. Por lo tanto, el problema no es aplicar una actualización de seguridad proporcionada por Google o un proveedor externo, sino que el fabricante certifique que el dispositivo no es vulnerable a la lista de CVEs del ASB. El fabricante puede usar las actualizaciones de seguridad proporcionadas o, si tiene un cambio que es más adecuado para su dispositivo, puede usar ese cambio.

Por ejemplo, considera un caso en el que Google aborda una vulnerabilidad de seguridad de AOSP con un cambio de código que permite que el componente siga siendo completamente funcional y cumpla con el CDD. Si el fabricante determina que el componente no es necesario en el dispositivo o que no es obligatorio según el CDD (o las pruebas de certificación relacionadas), puede quitarlo para reducir las necesidades de mantenimiento futuras y la superficie de ataque. Aunque el fabricante no usó la actualización de seguridad proporcionada, se aseguró de que el dispositivo no sea vulnerable al CVE documentado en el boletín de seguridad. Sin embargo, si se desvía de la actualización de seguridad recomendada, el fabricante corre el riesgo de abordar el problema de forma incorrecta, introducir nuevas vulnerabilidades de seguridad o, de alguna manera, reducir la funcionalidad de la compilación final.

Si bien trabajamos con todos los socios de SoC para garantizar que existan correcciones para todos los problemas de un ASB, recomendamos que los fabricantes obtengan un acuerdo de reparación con sus proveedores de SoC para el ciclo de vida de un dispositivo. Es posible que los SoC dejen de dar servicio a un chipset antes de lo deseado, por lo que establecer acuerdos antes de la selección del chipset del dispositivo es una parte importante del proceso de lanzamiento del dispositivo.

Por último, en los casos en que sea imposible adquirir directamente una solución para un problema documentado en un ASB o crear una de forma independiente, un fabricante podría mantener el SPL de Android anterior y, aun así, agregar las correcciones nuevas disponibles a la compilación. Sin embargo, esta práctica con el tiempo generará problemas con la certificación de compilación (ya que Android garantiza que el nivel de parche de seguridad más reciente esté disponible en los dispositivos certificados). Google recomienda trabajar con tu SoC con anticipación para evitar esta práctica.

P.: Si el fabricante determina que un elemento de la ASB no es aplicable a su producto, ¿se debe aplicar o parchear el elemento para cumplir con los otros requisitos de Google o para aprobar la CTS?

R.: No exigimos que se apliquen parches para declarar un nivel de parche de seguridad de Android (SPL). Lo que sí exigimos es que el fabricante certifique que su compilación no es vulnerable al problema.

Un ejemplo es cuando un componente al que se le aplica un parche no existe en el sistema del fabricante o cuando se quita un componente del sistema del fabricante para solucionar un problema. En ese caso, el sistema puede cumplir con los requisitos sin que el fabricante tenga que aplicar un parche.

Esto es muy diferente de un fabricante que, por ejemplo, solo quiera corregir parches críticos y no aplicar otros parches aplicables que provocarían que falle una prueba de seguridad. En este caso, se supone que no se cumplió el SPL.