Esta guía describe las mejores prácticas recomendadas por Google para aplicar parches de seguridad que son evaluados por Android Compatibility Test Suite (CTS). Está destinada a los fabricantes de equipos OEM compatibles con Android (fabricantes) que contarán con asistencia durante más de tres (3) años, como vehículos, televisores, decodificadores, electrodomésticos, etc. Esta guía no está destinada a usuarios finales ( por ejemplo, propietarios de vehículos).
Agradecimientos y descargos de responsabilidad
Esta guía no vincula legal ni contractualmente a Google ni a otros fabricantes y no pretende ser un conjunto de requisitos. Más bien, esta guía es una ayuda instructiva que describe las prácticas recomendadas.
Comentario
Esta guía no pretende ser exhaustiva; se planean revisiones adicionales. Envíe sus comentarios a manufacturers-guide-android@googlegroups.com.
Glosario
| Término | Definición |
|---|---|
| CAC | Compromiso de compatibilidad con Android. Anteriormente conocido como el Acuerdo Anti-Fragmentación de Android (AFA). |
| AOSP | Proyecto de código abierto de Android |
| ASB | Boletín de seguridad de Android |
| BSP | Paquete de soporte de la placa |
| DDC | Documento de definición de compatibilidad |
| CTS | Conjunto de pruebas de compatibilidad |
| FOTA | Firmware por aire |
| GPS | Sistema de Posicionamiento Global |
| MISRA | Asociación de confiabilidad del software de la industria del motor |
| NIST | Instituto Nacional de Normas y Tecnología |
| DAB | Diagnóstico a bordo ( OBD-II es una mejora sobre OBD-I tanto en capacidad como en estandarización ) |
| OEM | Fabricante Original de Equipo |
| sistema operativo | Sistema operativo |
| SEI | Instituto de Ingeniería de Software |
| SOC | Sistema en chip |
| COMPENSACIÓN | Inicio de producción |
| SPL | Nivel de parche de seguridad |
| TPMS | Sistema de monitoreo de presion en llantas |
Acerca del sistema operativo Android
Android es una pila de software completa basada en Linux y de código abierto diseñada para una variedad de dispositivos y factores de forma. Desde su primer lanzamiento en 2008, Android se ha convertido en el sistema operativo ("SO") más popular, con más de 1400 millones de dispositivos en todo el mundo (2016). Aproximadamente el 67% de esos dispositivos usan Android 5.0 (Lollipop) o más reciente a partir de marzo de 2017 (las cifras más recientes están disponibles en el panel de control de Android ). Si bien la gran mayoría de los dispositivos son teléfonos móviles y tabletas, Android está creciendo en relojes inteligentes, televisores y dispositivos de información y entretenimiento para vehículos ("IVI").
La cantidad de aplicaciones de Android disponibles en Google Play Store ha llegado a más de 2,2 millones (2016). El desarrollo de aplicaciones de 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 de Compatibility Test Suite (CTS) . Los programas de compatibilidad con Android garantizan que cualquier aplicación de Android pueda ejecutarse en cualquier dispositivo compatible con Android que admita las funciones requeridas para la aplicación.
Google publica regularmente nuevas versiones del sistema operativo, actualizaciones de seguridad del sistema operativo e información sobre las vulnerabilidades descubiertas. Los fabricantes deben revisar el Boletín de seguridad de Android para determinar la aplicabilidad de estas actualizaciones a los productos compatibles con el sistema operativo Android. Para obtener una revisión de la seguridad, la compatibilidad y los sistemas de compilación de Android, consulte lo siguiente:
- Asegure un dispositivo Android
- Actualizaciones de seguridad y recursos
- Conjunto de pruebas de compatibilidad
- Nombres en clave, etiquetas y números de compilación
Acerca de los vehículos conectados (producto canónico 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, TPMS) y cumplir con los objetivos de economía de combustible. . La siguiente ola de conectividad introdujo funciones de conveniencia para el conductor, como entrada remota sin llave, sistemas telemáticos y funciones avanzadas de información y entretenimiento, como Bluetooth, Wi-Fi y proyección de teléfonos inteligentes. Hoy en día, los sensores integrados y la conectividad (por ejemplo, GPS) respaldan los sistemas de conducción semiautónomos y de seguridad.
A medida que aumenta el número de conexiones de vehículos, también lo hace el área de la superficie potencial de ataque de vehículos. Las conexiones traen consigo una colección similar de preocupaciones de seguridad cibernética que para la electrónica de consumo. Sin embargo, si bien los reinicios, las actualizaciones diarias de parches y los comportamientos inexplicables son la norma para los productos electrónicos de consumo, son inconsistentes para los productos con sistemas críticos para la seguridad, como los vehículos.
Los fabricantes deben adoptar un enfoque proactivo para garantizar la seguridad continua y la postura de seguridad de un producto en el campo. En resumen, los fabricantes deben conocer las vulnerabilidades de seguridad conocidas en el producto y adoptar un enfoque basado en el riesgo para abordarlas.
Garantizar la seguridad a largo plazo
Un vehículo conectado a menudo tiene una o más unidades de control electrónico ("ECU") que incluyen múltiples componentes de software, como SO, bibliotecas, utilidades, etc. Los fabricantes deben realizar un seguimiento de dichos componentes e identificar las vulnerabilidades conocidas publicadas con un análisis proactivo, que incluye:
- Evaluar regularmente el producto contra la base de datos de vulnerabilidades y exposiciones comunes (CVE).
- Recopilación de inteligencia para fallas de seguridad relacionadas con el producto.
- Pruebas de seguridad.
- Analizando activamente los boletines de seguridad de Android.
Ejemplo de actualizaciones de parches de seguridad y sistema operativo (IVI con Android):
Figura 1. Muestra de la implementación de actualizaciones de seguridad y SO principales durante la vida útil 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 de producción (SOP) inicial. |
| ② | Lanzamiento inicial | Algunos meses antes de que Android X se convierta en la primera versión del sistema operativo incluida 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, aplicado (retrocedido) por el fabricante a Android X. Esta actualización se incluye en el producto y el reloj de producción comienza a correr en el año cero con Android X.y2. En este ejemplo, el fabricante tomó la decisión de no enviar el lanzamiento anual más reciente de Android X+1. Las razones para enviar la versión más reciente incluyen agregar nuevas funciones, abordar nuevas vulnerabilidades de seguridad y/o enviar servicios de Google o de terceros que requieren la versión más reciente de Android. Las razones contra el envío con la versión más reciente es la falta de tiempo inherente al proceso de desarrollo y lanzamiento del vehículo requerido para integrar, probar y validar los cambios, incluido el cumplimiento de todos los requisitos normativos y de certificación. |
| ③ | Actualización completa del sistema operativo | Después del SOP, el fabricante lanza la actualización del sistema operativo Android X+2, que son dos lanzamientos de Android después de la versión utilizada 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 sale como X+2.y0 aproximadamente 1,25 años después del SOP. Esta actualización del sistema operativo puede o no ser compatible con los productos de campo. Si es así, se podría crear un plan para actualizar los vehículos desplegados. A menos que existan otros acuerdos comerciales, la decisión de realizar una actualización completa del sistema operativo queda totalmente a discreción del fabricante. |
| ④ | Actualización de seguridad | Dos años después de la vida útil de producción del vehículo, el fabricante parchea el sistema operativo 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 están en (X+2.y3) OS + nivel de parche de seguridad de Android. Si bien los fabricantes pueden seleccionar parches de seguridad individuales de cualquier ASB individual, deben corregir todos los problemas requeridos en el boletín para usar el nivel de parche de seguridad de Android (SPL) asociado con el boletín (por ejemplo, 2017-02-05). Es responsabilidad del fabricante realizar el backport y la liberación de seguridad para el producto admitido. |
| ⑤ | Actualización completa del sistema operativo | Una repetición del paso 3 (Actualización completa del sistema operativo), la segunda actualización completa del sistema operativo lleva el producto a Android X+4, tres años después de la vida útil de producción del vehículo. El fabricante ahora está equilibrando los requisitos de hardware más nuevos de una versión reciente de Android con el hardware del producto y el usuario se beneficia de un sistema operativo Android actualizado. El fabricante publica una actualización sin actualizaciones de seguridad, por lo que el producto ahora se encuentra en (X+4.y0) OS + 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 los más de 6 años de vida útil prevista para el vehículo aún requieren soporte de seguridad. |
| ⑥ | Actualización de seguridad | Una repetición del 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 transferir algunas o todas esas actualizaciones a Android X+4. Es responsabilidad del Fabricante fusionar, 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 estarán cubiertos en ASB. |
| ⑦ | Actualización de seguridad | Ocho años después del ciclo de vida de producción del vehículo, cuatro lanzamientos de Android desde la última actualización del sistema operativo en el Paso 5 (Actualización completa del sistema operativo) y diez años desde que se especificó Android X, la carga de curar y respaldar los parches de seguridad recae completamente en el fabricante para aquellas versiones anteriores a tres años desde el lanzamiento público del nivel API. |
Prácticas recomendadas de seguridad
Para dificultar los compromisos de seguridad, Google recomienda y emplea el uso de las mejores prácticas comúnmente aceptadas para la seguridad y la ingeniería de software, como se describe en Implementación de la seguridad .
Directrices de seguridad
Las prácticas recomendadas para la seguridad incluyen:
- Utilice las últimas versiones de bibliotecas externas y componentes de código abierto.
- No incluya la funcionalidad de depuración intrusiva en las versiones de lanzamiento del sistema operativo.
- Elimine la funcionalidad no utilizada (para reducir la superficie de ataque innecesaria).
- Utilice el principio de privilegios mínimos y otras mejores prácticas de desarrollo de aplicaciones de Android .
Pautas de desarrollo de software
Las prácticas recomendadas para el desarrollo de software seguro para el ciclo de vida del sistema incluyen:
- Realice modelos de amenazas para clasificar e identificar activos, amenazas y mitigaciones potenciales.
- Realice una revisión de arquitectura/diseño para garantizar un diseño seguro y sólido.
- Realice revisiones periódicas del código para identificar los antipatrones y los errores lo antes posible.
- Diseñe, implemente y ejecute pruebas unitarias de cobertura de alto código, que incluyen:
- Pruebas funcionales (incluidos casos de prueba negativos)
- Pruebas de regresión periódicas (para garantizar que los errores corregidos no vuelvan a aparecer)
- Fuzz testing (como parte del conjunto de pruebas unitarias)
- Use herramientas de análisis de código fuente estático (compilación de escaneo, pelusa, etc.) para identificar problemas potenciales.
- Utilice herramientas dinámicas de análisis de código fuente, como AddressSanitizer, UndefinedBehaviorSanitizer y FORTIFY_SOURCE (para componentes nativos) para identificar y mitigar posibles problemas durante el desarrollo del sistema.
- Tenga una estrategia de gestión para el código fuente del software y la versión/configuración de la versión.
- Contar con una estrategia de gestión de parches para la generación y despliegue de parches de software.
Política de respaldo de seguridad
Actualmente, Google brinda soporte activo para backports de seguridad de vulnerabilidades de seguridad descubiertas e informadas durante tres (3) años desde el lanzamiento público del nivel API . El soporte activo consiste en lo siguiente:
- Recibir e investigar informes de vulnerabilidad.
- Cree, pruebe y publique actualizaciones de seguridad.
- Proporcione versiones periódicas de actualizaciones de seguridad y detalles del boletín de seguridad.
- Realice la evaluación de la gravedad según las pautas establecidas.
Después de tres años desde la fecha de lanzamiento público del nivel API, Google recomienda las siguientes pautas:
- Utilice un tercero (como un proveedor de SoC o un proveedor de Kernel) para obtener soporte de respaldo para las actualizaciones de seguridad del sistema operativo con una antigüedad de más de tres años desde el lanzamiento de la API.
- Utilice un tercero para realizar revisiones de código utilizando los ASB proporcionados públicamente. Si bien los ASB identifican vulnerabilidades para la versión compatible actualmente, un fabricante puede usar la información proporcionada para comparar las actualizaciones recién lanzadas con versiones anteriores. Estos datos se pueden usar para realizar análisis de impacto y potencialmente generar parches similares para versiones del sistema operativo anteriores a tres años desde el lanzamiento de la API.
- Cuando corresponda, cargue actualizaciones de seguridad en el Proyecto de código abierto de Android (AOSP).
- El fabricante debe coordinar el manejo de las actualizaciones de seguridad para el código específico del proveedor (por ejemplo, el código específico del dispositivo patentado).
- El fabricante debe unirse al grupo de notificación de vista previa para socios del Boletín de seguridad de Android NDA (requiere la firma de acuerdos legales como el NDA para desarrolladores). Los boletines deben incluir:
- Anuncios
- Resumen de problemas por nivel de parche, incluidos CVE y gravedad
- Detalles de vulnerabilidad cuando corresponda
Referencias adicionales
Para obtener instrucciones sobre codificación segura y prácticas de desarrollo de software, consulte lo siguiente:
- Asociación de Confiabilidad del Software de la Industria del Motor (MISRA) .
- Instituto de ingeniería de software (SEI) Herramientas y métodos .
- Instituto Nacional de Estándares y Tecnología (NIST).
Prácticas de productos recomendadas
Google fomenta el uso de las siguientes prácticas recomendadas.
Directrices generales de lanzamiento
En general, se recomienda que cualquier producto conectado se inicie con la última versión del sistema operativo, y un fabricante debe intentar utilizar la versión más reciente del sistema operativo antes de iniciar el producto. Si bien es necesario bloquear la versión para impulsar la estabilidad antes de la prueba y la validación, el fabricante debe equilibrar la estabilidad del producto obtenida de las versiones anteriores del sistema operativo con las versiones más nuevas del sistema operativo que tienen menos vulnerabilidades de seguridad conocidas y protecciones de seguridad mejoradas.
Las pautas recomendadas incluyen:
- Debido a los largos plazos de desarrollo inherentes al proceso de desarrollo de vehículos, es posible que los fabricantes deban lanzar con la versión del sistema operativo n-2 o anterior.
- Mantenga la conformidad con la compatibilidad con Android para cada versión del sistema operativo Android lanzada a través de una campaña inalámbrica (OTA).
- Implemente el producto Android Firmware-over-the-air (FOTA) con capacidad para actualizaciones rápidas y fáciles de usar para el cliente. La FOTA debe realizarse utilizando las mejores prácticas de seguridad, como la firma de código y la conexión TLS entre el producto y el back office de TI.
- Envíe las vulnerabilidades de seguridad de Android identificadas de forma independiente al equipo de seguridad de Android.
Nota: Google ha contemplado el tipo de dispositivo o las notificaciones específicas de la industria en los boletines de seguridad de Android. Sin embargo, debido a que Google no conoce el kernel, los controladores o los conjuntos de chips para un dispositivo determinado (vehículo, TV, dispositivo portátil, teléfono, etc.), Google no tiene una forma determinista de etiquetar cualquier problema de seguridad con un tipo de dispositivo.
Pautas del ciclo del producto
El fabricante debe hacer todo lo posible por utilizar la última versión del sistema operativo o las actualizaciones de seguridad para la versión en uso durante las mejoras del ciclo del producto. Las actualizaciones se pueden realizar durante las actualizaciones periódicas recurrentes del producto, o para las revisiones para abordar la calidad y/u otros problemas. Las prácticas recomendadas incluyen:
- Cree un plan para abordar las actualizaciones de controladores, kernel y protocolos.
- Utilice un método apropiado de la industria para proporcionar actualizaciones a los vehículos desplegados.
Documento de definición de compatibilidad (CDD)
El Documento de definición de compatibilidad (CDD) describe los requisitos para que un dispositivo se considere compatible con Android. El CDD es público y está disponible para todos; puede descargar versiones de CDD desde Android 1.6 hasta la última versión desde source.android.com .
Satisfacer estos requisitos para un producto implica los siguientes pasos básicos:
- El socio firma el Compromiso de compatibilidad de Android (ACC) con Google. Luego se asigna un consultor de soluciones técnicas (TSC) como guía.
- El socio completa la revisión de CDD para la versión del sistema operativo Android del producto.
- El socio ejecuta y envía los resultados de CTS (descritos a continuación) hasta que los resultados sean aceptables para la compatibilidad con Android.
Conjunto de pruebas de compatibilidad (CTS)
La herramienta de prueba Compatibility Test Suite (CTS) verifica que la implementación de un producto sea compatible con Android y que se incluyan los parches de seguridad más recientes. CTS es público, de código abierto y está disponible para todos; puede descargar versiones de CTS desde Android 1.6 hasta la última versión desde source.android.com .
Cada compilación de software de Android lanzada al público (imágenes de instalación de fábrica y de 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 última versión correspondiente de CDD 7.1 y CTS 7.1 cuando se crea y prueba una imagen de compilación con intención de lanzamiento. Se recomienda encarecidamente a los fabricantes que utilicen CTS de forma temprana y frecuente para identificar y solucionar problemas.
Flujo de trabajo de CTS
El flujo de trabajo de CTS implica configurar el entorno de prueba, ejecutar pruebas, interpretar los resultados y comprender el código fuente de CTS. Las siguientes pautas están destinadas a ayudar a los usuarios de CTS (por ejemplo, desarrolladores, fabricantes) a usar el CTS de manera efectiva y eficiente.
- Ejecute pruebas con frecuencia . CTS está diseñado como una herramienta automatizada que se integra en su sistema de compilación. Ejecutar CTS con frecuencia puede ayudarlo a encontrar defectos de manera rápida y temprana cuando se produce una degradación o regresión del software.
- Descargue y examine el código fuente de CTS . El código fuente completo de CTS es un software de código abierto que cualquiera 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 ayudarlo a identificar por qué.
- Obtenga el CTS más reciente . Las nuevas versiones de Android pueden actualizar el CTS con correcciones de errores, mejoras y nuevas pruebas. Verifique las descargas de CTS con frecuencia y actualice su programa CTS según sea necesario. El fabricante y Google acordarán que la versión de CTS pase por el lanzamiento del producto, ya que el producto debe congelarse en algún momento mientras se continúa actualizando el CTS.
Pasando el CTS
Para un producto compatible con Android, Google garantiza que los resultados de las pruebas de los informes CTS y CTS Verifier del dispositivo sean aceptables. En principio, todas las pruebas deben pasar. Sin embargo, una prueba que falla por razones distintas a que el dispositivo no cumple con los requisitos de compatibilidad de Android está sujeta a revisión por parte de Google. Durante este proceso:
- El fabricante proporciona a Google los parches CTS propuestos, las validaciones de parches y las justificaciones para probar el argumento.
- Google examina el material enviado y, si se acepta, actualiza las pruebas CTS pertinentes para que el dispositivo pase la próxima revisión de CTS.
Si una prueba CTS falla repentinamente después de aplicar un parche de seguridad, el fabricante debe modificar el parche para que no rompa la compatibilidad O mostrar que la prueba es incorrecta y proporcionar una solución para la prueba (como se describe anteriormente).
El CTS permanece abierto para revisiones de correcciones de prueba. Por ejemplo, Android 4.4 sigue aceptando correcciones (consulte https://android-review.googlesource.com/#/c/273371/ ).
Preguntas frecuentes (FAQ)
P: ¿Quién es responsable de aplicar actualizaciones de seguridad a una implementación específica de Android?
R: El fabricante que proporciona directamente el dispositivo es el 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 soluciones potenciales, que Google pone a disposición de todos los niveles de API admitidos como parte del proceso de actualización de seguridad regular. Desde agosto de 2015, Google ha mantenido una cadencia regular de publicación de boletines y enlaces a actualizaciones de source.android.com ; Google también publica actualizaciones de seguridad como parte de los principales lanzamientos del sistema operativo. Consulte también la política de respaldo de seguridad .
P: Si un fabricante integró todos los parches AOSP de un ASB pero no integró los parches del proveedor BSP mencionado en el mismo boletín, ¿puede aumentar el nivel de seguridad (por ejemplo, aplicar el parche correspondiente a la plataforma/construcción)?
R: Para declarar un nivel de parche de seguridad (SPL) de Android, un fabricante debe abordar todos los problemas necesarios publicados en el Boletín de seguridad de Android ( incluidos los boletines anteriores ) y asignados a un SPL de Android en particular. Por ejemplo, un fabricante que utiliza el boletín de seguridad de marzo de 2017 (2017-03-01 SPL) ha solucionado todos los problemas necesarios 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, incluidos las actualizaciones específicas del dispositivo asociadas al 2017-02-05 SPL.
P: ¿Qué sucede cuando el fabricante no está de acuerdo con las actualizaciones de seguridad proporcionadas por el proveedor de BSP O cuando los proveedores no proporcionan las actualizaciones de seguridad exigidas por un 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 el dispositivo pueda pasar las pruebas de seguridad asociadas. Como tal, el problema no es tomar 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 CVE en ASB. El Fabricante es libre de usar las actualizaciones de seguridad provistas o, si tiene un cambio que es más apropiado para su dispositivo, usar ese cambio en su lugar.
Por ejemplo, considere un caso en el que Google aborda una vulnerabilidad de seguridad de AOSP mediante un cambio de código que permite que el componente siga siendo totalmente funcional y compatible con la CDD. Si el fabricante determina que el componente no es necesario en el dispositivo o no lo exige la CDD (o las pruebas de certificación relacionadas), el fabricante puede eliminar el componente para reducir las necesidades de servicio futuras y reducir la superficie de ataque. Aunque el fabricante no usó la actualización de seguridad proporcionada, se aseguró de que el dispositivo no sea vulnerable a la CVE documentada en el boletín de seguridad. Sin embargo, al desviarse de la actualización de seguridad recomendada, el fabricante corre el riesgo de abordar incorrectamente el problema, introducir nuevas vulnerabilidades de seguridad o reducir la funcionalidad de la compilación final.
Si bien trabajamos con todos los socios de SoC para garantizar que existan soluciones para todos los problemas en un ASB, recomendamos que los fabricantes aseguren un acuerdo de servicio con sus proveedores de SoC para el ciclo de vida de un dispositivo. Los SoC pueden dejar de prestar servicio a un conjunto de chips antes de lo deseado, por lo que establecer acuerdos antes de la selección del conjunto de chips del dispositivo es una parte importante del proceso de lanzamiento del dispositivo.
Por último, en los casos en los que sea imposible adquirir directamente o crear de forma independiente una solución para un problema documentado en un ASB, un fabricante podría mantener el SPL de Android anterior y agregar las nuevas soluciones disponibles a la compilación. Sin embargo, esta práctica eventualmente 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 su SoC de antemano para evitar esta práctica.
P: Si el fabricante determina que un elemento ASB no se aplica a su producto, ¿es necesario aplicar o reparar el elemento para cumplir con los otros requisitos de Google o para aprobar CTS?
R: No requerimos que se tomen parches para declarar un nivel de parche de seguridad de Android (SPL); requerimos que el fabricante certifique que su construcción no es vulnerable al problema.
Un ejemplo es cuando un componente que se está parcheando no existe en el sistema del fabricante, o si un componente se elimina del sistema del fabricante para solucionar un problema. En ese caso, el sistema puede ser compatible sin requerir que el fabricante tome un parche.
Esto es fundamentalmente diferente de un fabricante que desea, por ejemplo, solo corregir parches críticos, sin tomar otros parches aplicables que harían que una prueba de seguridad fallara. En este caso, se supone que no se ha cumplido el SPL.