De la tienda al estante: una capitulación en profundidad de por qué los dispositivos MSM8974 están excluidos del turrón

Actualizado para reflejar el requisito de Vulkan o OpenGL ES 3.1 para Android 7.0

Recientemente, se han escrito muchos artículos sobre actualizaciones de versiones, las interacciones entre el proveedor y el fabricante del chipset, y lo que esto significa para los dispositivos en adelante. ¿Por qué ha surgido esto esta semana?

Bueno, surgió esta semana dado que el venerable Nexus 5 no recibirá la actualización a Android 7.0 (Nougat), y Qualcomm anunció que no proporcionará soporte para el MSM8974 (más comúnmente conocido como Snapdragon 801) en 7.0. Este artículo fue escrito en colaboración con el abejorro Reconocido desarrollador.

El tema ha atraído bastante interés de varios sitios de noticias, pero muchos se pierden los sutiles matices de lo que realmente está sucediendo detrás de escena . Este artículo explicará un poco más sobre cómo funcionan las actualizaciones de software, utilizando nuestra experiencia en el trabajo con OEM en sus actualizaciones oficiales de firmware. Te guiaremos a través de lo que sucede detrás de escena (y por qué), y por qué es posible que no termines obteniendo el último software en tu teléfono.

El primer paso en la vida de una actualización de firmware de Android es la actualización ascendente. Esto es en lo que Google trabaja internamente. A diferencia de los "flujos de trabajo abiertos", Android se desarrolla utilizando un flujo de trabajo cerrado, con el código fuente arrojado a la pared cada año más o menos, cuando sale una nueva versión. Originalmente, Google dijo que esto era para evitar la fragmentación de las personas que ejecutan versiones innovadoras mientras las cosas evolucionaban rápidamente en los primeros días, pero parecen haber mantenido esta política en su lugar.

En algún momento, generalmente antes del anuncio público de una actualización (aunque con la reciente introducción de versiones beta públicas, estas escalas de tiempo están cambiando), los OEM serán informados de una próxima actualización . Luego recibirán el código fuente en un segundo momento para la actualización final (en el pasado, a veces era un poco antes del lanzamiento, aunque también estamos al tanto de los casos en que no hay lanzamiento anticipado).

Los repositorios AOSP ascendentes contienen soporte para dispositivos solo para un número limitado de dispositivos. Estos son típicamente sus dispositivos Nexus. Sin embargo, por razones que quedarán claras en breve, es importante tener en cuenta que Google no tiene un control completo del hardware sobre estos dispositivos; los dispositivos son fabricados por un OEM, y ese OEM comprará un System-on-Chip (SoC) de un fabricante de conjuntos de chips.

Una vez que se libera el código fuente, el equipo de firmware del OEM (en sentido figurado) se sentará y se pondrá de pie. El árbol fuente principal de Android no tiene soporte de hardware para la gran cantidad de chipsets utilizados en los dispositivos de envío. Su chipset Qualcomm probablemente no sea compatible con AOSP, por ejemplo. Tu Exynos definitivamente no lo es. Mediatek o HiSilicon? ¡Olvídalo!

"El BSP contiene los controladores y las capas de abstracción de hardware (HAL) necesarias para ejecutar Android"

Lo que se necesita ahora es un paquete de soporte de placa (BSP) . Este es un paquete súper confidencial de componentes patentados, entregado por un fabricante de chips a un OEM. El BSP contiene el código fuente necesario para permitir que los OEM compilen Android y los controladores necesarios para su dispositivo.

Vale la pena señalar aquí que los OEM como Qualcomm no necesariamente confían completamente en sus socios OEM: el BSP se pone a disposición en una base de "necesidad de saber". Los fabricantes de equipos originales generalmente no tienen acceso al código fuente de algunas de las partes súper secretas del dispositivo (como el software que se ejecuta en la banda base). Tener esta parte cerrada ciertamente también tiene problemas potenciales, como lo demuestran las vulnerabilidades de análisis ASN.1 casi copiosas y recurrentes.

El BSP contiene los controladores y las capas de abstracción de hardware (HAL) necesarias para que Android se ejecute en su dispositivo. AOSP contiene un conjunto de HAL, que actúan como definiciones de lo que el sistema operativo espera que implementen sus controladores. Para usar un ejemplo ridículamente demasiado simplificado (e inventado, con fines de demostración), imaginemos la linterna en su teléfono.

Un ejemplo de HAL: tu linterna

Imaginemos que su dispositivo tiene una linterna en la parte posterior (si tiene un Nexus 7 2013, tendrá que imaginar un poco más que todos los demás, ¡lo siento!). Esto es controlado por un conductor. Para nuestro ejemplo loco y simple, supongamos que v1 HAL dice que debería tener una función llamada "setLED" que toma un solo parámetro, el estado de la luz. Es un booleano, verdadero o falso. En C, esto se vería así:

vacío setLED (bool ledState) {

// aquí está el código real para encender o apagar el LED, basado en ledState

}

Esta función se define dentro del código fuente BSP. Luego, el OEM compila el BSP durante la construcción de la ROM, y se convierte en una de las bibliotecas “.so” patentadas en la partición o área del proveedor de su dispositivo. Esto permite que un OEM mantenga en secreto ciertas partes del funcionamiento de su dispositivo. Por ahora, supongamos que quieren evitar que todos vean cómo encienden y apagan ese LED.

Ahora imagine que Google lanza una versión actualizada de sus HAL en una versión futura de Android. Ahora deciden que sería bueno permitirle actualizar el brillo de su LED, en lugar de simplemente encenderlo o apagarlo. ¿Tal vez esto es para flash adaptativo, o tal vez es solo para forzar una actualización de HAL y mantener a los fabricantes de chipsets en el negocio? Le dejaremos, lector, llegar a su propia opinión al respecto. Algunas actualizaciones de HAL tienen un beneficio claro (como la nueva cámara HAL que expone disparos sin procesar y similares), mientras que otras tienen un propósito menos claro.

Con este nuevo (ficticio) HAL para brillo, supongamos que Google dice que necesita exponer nuevamente una función llamada setLED, pero esta vez con un número entero para brillo. Ahora, 0 lo apagaría y 255 lo pondría por completo.

Si usted es el OEM, puede tomar su código súper secreto para encender ese LED y ponerlo en esta nueva función. Incluso puede usar la modulación de ancho de pulso para ajustar el brillo del LED en función del número. Cambia la función para que aparezca así ahora:

vacío setLED (uint8_t ledBrightness) {

// alguna forma patentada súper secreta y ultra confidencial de configurar el brillo del LED

}

¿Y qué? Bueno, ahora esta nueva versión de Android es incompatible con los "blobs" existentes. Su OEM necesita usar estos nuevos blobs, porque el sistema operativo Android espera ver la nueva definición de función, y no "encontrará" la antigua cuando busque una forma de configurar el LED.

En este punto, tomemos un breve intermedio para ver cómo las ROM personalizadas (construidas a partir de la fuente) se manejan aquí. Es lo que los astutos entre ustedes gritarán en su pantalla en este momento: después de todo, somos el hogar del HTC HD2, el teléfono más duradero del mundo ... (solo para el registro, los genios locos están ejecutando Android 6.0 en el HD2 en estos días! No está mal para un teléfono originalmente enviado con Windows Mobile 6.5 en 2009)

Aquí se adoptan varios enfoques: a veces los desarrolladores piratean la ROM y le dicen al sistema operativo que use las definiciones de funciones antiguas. Eso es un poco desordenado y hace muchos cambios para mantener. El otro enfoque es "calzar" el binario OEM.

El enfoque "shim" es escribir y construir una pequeña biblioteca nueva usted mismo, que contenga la definición de función esperada; para nuestro ejemplo, admitiríamos el número entero para el brillo. Luego, dentro de la cuña, esto se traduce para cumplir con los requisitos del antiguo HAL. Entonces, para nuestro ejemplo, podríamos decir que cualquier brillo solicitado por encima de 128 encenderá el LED, y cualquier cosa debajo de eso lo apagará. O podría decir que cualquier cosa que no sea cero lo encenderá. Depende del desarrollador. Compilan la cuña y hacen que Android la use en lugar de la nativa. La cuña luego llama al blob OEM.

Un rápido `adb push` y reinicio debería hacer que la cuña funcione y le permita controlar su LED ficticio, aunque solo tenga el HAL anterior.

El problema es que este es claramente un proceso imperfecto. Ahora obtendrá peculiaridades: este dispositivo tendrá un flash bastante malo, que está completamente encendido o completamente apagado. Eso no es ideal: el sistema operativo cree que está haciendo una luz muy suave, pero se le dice al LED real que está compitiendo en un concurso de sol artificial y está tratando de cegarte. Pero bueno, la vida no es perfecta, ¡y ahora tienes un LED que funciona en tu teléfono antiguo!

(Sí, esta es una de las razones por las que hay caprichos y errores cuando los usuarios y los desarrolladores manejan sus hazañas locas y locas de portar destreza. Quiero decir, diablos, el Galaxy S II está llevando una ROM Android 6.0 aparentemente utilizable ahora. ¡los teléfonos lanzados el año pasado todavía no tienen 6.0!)

Volvamos a la perspectiva del OEM. Lamentablemente, la mayoría de los OEM ya están trabajando al menos 1 teléfono antes de donde estamos ahora. Se centran en el próximo teléfono que están a punto de vender: realmente no se les puede culpar, ya que solo ganan dinero con los dispositivos que venden. No ganan dinero con los dispositivos que vendieron hace uno o dos años, por lo que deben seguir lanzando nuevos dispositivos para que existan. Esta es una de las razones por las que HTC y Blackberry están en problemas: no importa cuántos ejecutivos mantengan un control mortal sobre su antigua Blackberry Curve, ya que no están obteniendo una nueva venta de dispositivos allí.

Si el OEM no obtiene un BSP, no van a seguir el método de piratear una construcción. ¿Por qué? Bueno, necesitan soportar este firmware para sus clientes . Si lanzan un firmware que funciona a medias, los usuarios los odiarán, y despotricarán y desvariarán, y mantendrán sus líneas de soporte sonando durante días.

Los OEM también tienen que competir con los operadores, al menos en mercados no europeos. Los operadores no quieren que los clientes tengan problemas con las actualizaciones de software. De hecho, los operadores prefieren no publicar actualizaciones de software.

Para entender esto, imagina a tu tía abuela Alice. Ella es quien te llama por teléfono en momentos inconvenientes del día para pedir ayuda con "esa cosa de la computadora". Luego describe cómo hacer clic en el "menú Inicio", y tiene que identificarlo como la "gran bandera en la esquina inferior izquierda", y se encuentra con confusión. Aproximadamente 45 minutos (y mucha frustración) más tarde, emerge Tía Alice ha arrastrado su menú de inicio al borde derecho de la pantalla, y simplemente necesitaba arrastrarlo hacia atrás. Sí, con el botón izquierdo del mouse!

Ahora imagina que tienes mil tías Alice '. Todos están llamando por teléfono a su atención al cliente, incapaces de encontrar a Candy Crush en su teléfono, preocupados de que un hacker lo haya eliminado de su teléfono. Ah, y los iconos se ven un poco diferentes ahora, ¿tal vez el hacker todavía está en su teléfono?

Sí, está destinado a ser un poco de humor alegre, pero hasta que experimente las razones por las que las personas llamarán a su proveedor de soporte, no creerá los problemas que tienen. Una actualización de software que cambia la forma en que funciona el teléfono, o dónde están las cosas, causará una sobrecarga de soporte significativa. Como mínimo, requiere una nueva capacitación del personal de soporte (porque la mayoría de ellos no son su ávido lector, lamentablemente).

Una vez que el OEM obtiene el BSP, transferirán su ROM y aplicarán todos sus cambios a la ROM. Se apilarán en su bloatware y agregarán una horrible piel de dibujos animados que se vería más en casa en el Anime de un adolescente. Luego lo probarán.

Mucho.

Hay todo tipo de requisitos que debe cumplir su teléfono. Las redes móviles están diseñadas para confiar en el equipo del usuario (lo que llamamos el teléfono) para que se comporte correctamente. Esto significa que se necesitan muchas pruebas para obtener la aprobación del dispositivo. Las actualizaciones de software corren el riesgo de cambiar los comportamientos, por lo que las cosas deben probarse nuevamente. Es por eso que comúnmente verá información sobre las próximas actualizaciones de software de Sony de servicios de prueba externos, que confirman que el firmware cumple con los requisitos de prueba.

Ahora ... ¿qué sucede después de una actualización o dos (o en algunos casos, ninguna)? El fabricante de SoC no le dará al OEM un BSP actualizado . Después de todo, el fabricante de SoC no obtendrá mucho de esto. El OEM no gana más dinero con su teléfono desde que se vendió. Y en este punto, su teléfono no recibe más actualizaciones importantes de la versión.

Reducir el número de BSP que el OEM quiere que se entregue es una excelente manera de ahorrar dinero: si solo necesita el actual y no tiene la intención de entregar ningún aumento importante de la versión, esto ahorrará dinero en la compra y licencia inicial de SoC, pero a expensas de algunos nerds enojados en el futuro, preguntándose por qué no recibieron una actualización.

Las actualizaciones son complejas. Hay muchas personas diferentes involucradas en la cadena. Nada de esto excusa a los fabricantes de equipos originales del estado actual y poco patético de las actualizaciones en Android. Sin embargo, hay algunos desafíos reales aquí.

Muchos fabricantes de equipos originales son los culpables del exceso de promesas y la inevitable entrega insuficiente que ahora asociamos. La triste realidad es que para la mayoría de los fabricantes de equipos originales, las actualizaciones de software son solo una molestia que podrían prescindir.

El sector móvil está mayormente atrapado en la mentalidad de los teléfonos con funciones. Es decir, donde un dispositivo nunca recibe actualizaciones. Pruébelo una vez, envíelo y nunca mire hacia atrás. Con los problemas de seguridad de los teléfonos inteligentes modernos y la gran complejidad de ejecutar un sistema operativo completo de propósito general, con cientos de bibliotecas externas, eso ya no es una opción. O al menos no debería serlo. Google ha dado algunos pasos para solucionar esto, al menos publicando boletines de seguridad y parches para las versiones existentes de Android (recuerde que hasta hace muy poco, ¡la única forma de obtener actualizaciones de seguridad era a través de una nueva versión principal del sistema operativo Android!)

Sin embargo, esto no es realmente suficiente. A pesar de que Google sigue lanzando actualizaciones, la seguridad de su dispositivo todavía depende del fabricante de SoC, ya que los fabricantes de SoC están tan aterrorizados de que alguien descubra cómo encienden un par de LED o emiten un sonido a través de un altavoz, envían grandes cantidades de gotas binarias en sus dispositivos Estos blobs contienen un código bastante inseguro (solo eche un vistazo a los boletines de seguridad de Google anteriores si cree que esto es una exageración) y necesita actualizarlos. Lo que significa que se requieren BSP actualizados.

Las computadoras de escritorio (y, por extensión, las computadoras portátiles) son completamente diferentes en arquitectura que los dispositivos móviles. Su teléfono móvil o tableta es efectivamente un trozo de silicio altamente patentado, diseñado rápidamente por algunas personas que tienen buenas intenciones, pero que no tienen el tiempo suficiente para hacer algo bueno. El mercado se mueve tan rápido que apenas pueden seguir el ritmo al que el marketing exige que se lancen nuevos productos.

Esto significa que se toman atajos: no encontrará su teléfono compatible con el núcleo principal de Linux, y encontrará que cada teléfono tiene una forma diferente de arrancar. Sin embargo, en su computadora portátil o de escritorio, los proveedores se decidieron por algunas formas estándar de arranque: anteriormente era MBR (registro de arranque maestro) con un BIOS, y ahora es UEFI. Esta estandarización permite ejecutar el mismo software en cada dispositivo.

Si bien recientemente se han dado algunos pasos hacia esto, especialmente con el programa de extensión de Sony y su núcleo unificado, no es práctico ejecutar un núcleo principal en la mayoría de los teléfonos, debido a la gran cantidad de nuevos hacks específicos de proveedores introducidos en cada dispositivo.

¿Conectó la toma de auriculares al revés? ¡Solo piratea en los controladores! No hay tiempo para arreglarlo en el diseño de producción.

¿El equipo de fabricación ha montado el módulo de la cámara al revés en el lote de producción 1? ¡Lanza un truco para verificar el código interno de la versión y voltea el video si es la versión 1!

Los trucos como estos resuelven el problema inmediato, pero solo raspan la superficie de los cambios extraños y específicos del producto que ocurren. Diablos, incluso a veces hay chips completamente diferentes en diferentes revisiones del mismo teléfono, debido a decisiones comerciales. Estos conducen a piratas en los conductores y a decisiones extrañas que solo tenían sentido en ese momento, para que el teléfono funcione y pueda enviarse la próxima semana.

Si bien hay un trabajo en curso para el soporte de línea principal para los chips ARM de 64 bits para arrancar usando UEFI, hasta ahora no ha habido un movimiento claro hacia una forma más estandarizada para arrancar dispositivos ARM . Y eso es triste, porque significa que los teléfonos continuarán siendo desechados mucho antes del final de su vida laboral, porque es simplemente demasiado costoso mantener la deuda técnica y la carga sobre su software.

Por otro lado, si un OEM solo ganará dinero con la venta de un dispositivo, ¿no necesitan asegurarse de que las personas continúen comprando teléfonos nuevos? ¿Se movería el mercado de PC a este modelo si no hubiera 30 años de impulso y software heredado usando la plataforma de PC abierta y el estándar?

Esta es una pregunta difícil sin el conocimiento interno de Qualcomm, que lamentablemente no tenemos en este momento. Sin embargo, podemos extraer alguna información de la API del controlador de Android 7.0 y los requisitos de CTS. Los requisitos de CTS especifican lo que Google espera de un dispositivo que ejecute un firmware determinado. El "gran martillo" utilizado para hacer cumplir estos requisitos es la licencia de Google para usar su paquete de servicios de Google Play patentado: si no cumple, no puede enviar Google Apps en el dispositivo . Si bien, para algunos, esto podría verse como una ventaja, esto obviamente no es lo que los usuarios quieren y esperan de un dispositivo.

Android 7.0 no ha agregado mucho a través de cambios en el HAL o los controladores (como se describe anteriormente), por lo que es poco probable que surja alguna incompatibilidad específicamente. Sin embargo, lo que es más probable que plantee un problema es la introducción de un nuevo requisito para que la API de gráficos Vulkan, o GLES 3.1, esté disponible para pasar CTS.

En la actualidad, muchos sistemas en chip (SoC) no han tenido soporte Vulkan en su procesador de gráficos, incluido el MSM8974. También es muy probable que surja el problema de compatibilidad con Android 7.0. Sin embargo, una vez más, sin el conocimiento interno de Qualcomm y sus planes futuros, es difícil para nosotros dar una declaración definitiva sin calificarla. Por el momento, sin embargo, creemos que es probable que este sea el caso "simple" de que Qualcomm suspenda el soporte para el chipset MSM8974 (en sus ojos) obsoleto y no proporcione un BSP (paquete de soporte de placa) para 7.0 en esa plataforma. Si ese fuera el caso, significaría que los OEM estarían casi seguros de no enviar 7.0 en el dispositivo; tendrían que encontrar de alguna manera soporte Vulkan o GLEs 3.1 para su GPU, y el código fuente de GPU es uno de los ridículamente guardados partes de las pilas móviles (sin ninguna razón real, agregaríamos: vea AMD, abriendo su propio controlador AMDGPU en el escritorio para Linux). Lamentablemente, sin embargo, los gráficos Vulkan y acelerados (GLES) en general son un poco más complejos que un simple LED, por lo que esto no es algo que vamos a ver cuñas para introducir compatibilidad.

Como 7.0 no ha estado disponible por mucho tiempo, existe una posibilidad real de que otros conjuntos de chips (aparte del pequeño número dentro de AOSP) se queden atrás en 6.0, debido a problemas de hardware y controladores (es decir, no hay BSP actualizado) o falta de soporte de proveedores de SoC con respecto a la API Vulkan o GLES 3.1. En la actualidad, ni el Snapdragon 800 ni el 801 admiten uno de estos.

La mejor opción es mirar este espacio : los desarrolladores ya están haciendo un buen progreso con puertos no oficiales a 7.0 para muchos de los dispositivos que no reciben soporte oficial 7.0 de Google. Sin embargo, estos no son compatibles con Vulkan o GLES 3.1, ¿tal vez los desarrolladores de juegos en Android comenzarán a experimentar frustración a través de la fragmentación si suficientes usuarios comienzan a ejecutar ROM personalizadas sin soporte de Vulkan o GLES 3.1?

Apple tiende a admitir su línea de iPhone en la última versión de iOS durante aproximadamente 5 años: el iPhone 4s se lanzó en octubre de 2011 y se ha mantenido actualizado hasta iOS 9. No recibirá la próxima actualización de iOS 10, sin embargo, lo que le daría al teléfono una vida útil efectiva de 5 años, suponiendo que iOS 10 se lance alrededor de octubre. Vale la pena señalar que Apple no siempre respalda la compatibilidad con la API de gráficos: el iPhone 4s y el iPhone 5 no cuentan con la API de gráficos metálicos de Apple, que es un escenario algo similar al visto con Android en Vulkan. La única diferencia es que Apple continuó admitiendo los dispositivos más antiguos sin la nueva API de gráficos.

¿Qué piensas? ¿Destellarás una ROM personalizada en tu teléfono para extender su vida útil? ¿Has dicho en los comentarios a continuación.