En este artículo exploramos la verdad de por qué los dispositivos Snapdragon 801 no reciben Android Nougat. Desde los fabricantes de chipsets hasta los proveedores, ¡los problemas son muchos!
Actualizado para reflejar el requisito de Vulkan u 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 el futuro. ¿Por qué ha llegado a subir 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 la recibirá. brindando soporte para MSM8974 (más comúnmente conocido como Snapdragon 801) en 7.0. Este artículo fue escrito como una colaboración con XDA Recognized Desarrollador abejorro.
El tema ha atraído bastante interés en varios sitios de noticias, pero Muchos se pierden los matices sutiles de lo que realmente sucede detrás de escena.s. Este artículo explicará un poco más sobre cómo funcionan las actualizaciones de software, utilizando nuestra experiencia trabajando con fabricantes de equipos originales en sus actualizaciones de firmware oficiales. Le explicaremos lo que sucede detrás de escena (y por qué) y por qué es posible que no termine obteniendo el software más reciente en su teléfono.
El primer paso en la vida de una actualización del firmware de Android es la actualización ascendente. En esto trabaja Google internamente. En contraste con los "flujos de trabajo abiertos", Android se desarrolla utilizando un flujo de trabajo cerrado, con el código fuente tirado por la pared aproximadamente cada año, cuando sale una nueva versión. Originalmente, Google dijo que esto era para evitar la fragmentación de las personas que ejecutan versiones de última generación. Si bien las cosas evolucionaron rápidamente en los primeros días, pero parecen haber mantenido esta política en 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, estos plazos están cambiando), Se informará a los OEM sobre una próxima actualización. Luego recibirán el código fuente en un segundo momento para la actualización final (en el pasado, era a veces un poco antes del lanzamiento, aunque también somos conscientes de casos en los que no hay una antelación liberar).
Los repositorios AOSP ascendentes contienen soporte de dispositivos solo para una cantidad limitada de dispositivos. Estos suelen ser sus dispositivos Nexus. Sin embargo, por razones que quedarán claras en breve, es importante señalar que Google no tiene control total 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 chipsets.
Una vez que se publique el código fuente, el equipo de firmware del OEM (en sentido figurado) se sentará y levantará los pies. El árbol principal de fuentes de Android no tiene soporte de hardware para la gran cantidad de conjuntos de chips utilizados en los dispositivos de envío. Lo más probable es que su chipset Qualcomm 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) necesarios para ejecutar Android.
Lo que se necesita ahora es una Paquete de apoyo a la junta directiva (BSP). Este es un paquete súper confidencial de componentes propietarios, entregado por un fabricante de chipsets a un OEM. El BSP contiene el código fuente necesario para permitir a los OEM crear Android y los controladores necesarios para su dispositivo.
Vale la pena señalar aquí que los OEM como Qualcomm no necesariamente confían plenamente en sus socios OEM: el BSP está disponible según la "necesidad de saberlo". Los OEM 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). Ciertamente, tener esta parte cerrada también tiene problemas potenciales, como lo demuestra el cercano copioso y periódico ASN.1 analizando vulnerabilidades.
El BSP contiene los controladores y las capas de abstracción de hardware (HAL) necesarios 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 simplificado (e inventado, con fines de demostración), imaginemos la linterna de su teléfono.
Un ejemplo HAL - Tu linterna
Imaginemos que tu dispositivo tiene una linterna en la parte posterior (si tienes un Nexus 7 2013, tendrás que imaginar un poco más que los demás, ¡lo siento!). Esto lo controla un conductor. Para nuestro ejemplo increíblemente simple, supongamos que el HAL v1 dice que debe tener una función llamada "setLED" que tome un solo parámetro, el estado de la luz. Es un valor booleano: verdadero o falso. En C, esto se vería así:
void setLED(bool ledState) {
// here is the actual code to turn on or off the LED, based on ledState
}
Esta función está definida dentro del código fuente de BSP. Luego, el OEM compila el BSP durante la construcción de la ROM, y esta se convierte en una de las bibliotecas propietarias ".so" en la partición o área del proveedor de su dispositivo. Esto permite a un OEM mantener 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 sea para flash adaptativo, o tal vez sea solo para forzar una actualización de HAL y mantener a los fabricantes de chipsets en el negocio? Le dejaremos a usted, el lector, llegar a su propia opinión al respecto. Algunas actualizaciones de HAL tienen beneficios claros (como la nueva cámara HAL que expone tomas en bruto y similares), mientras que otras tienen un propósito algo menos claro.
Con este nuevo HAL (ficticio) para el brillo, supongamos que Google dice que necesita exponer nuevamente una función llamada setLED, pero esta vez con un número entero pasado para el brillo. Ahora, 0 lo desactivaría y 255 lo activarí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 podrías usar la modulación de ancho de pulso para ajustar el brillo del LED según el número. Cambias la función para que aparezca así ahora:
void setLED(uint8_t ledBrightness) {
// some super-secret and ultra-confidential proprietary way to set LED brightness
}
¿Así que lo que? 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 anterior cuando busque una manera de configurar el LED.
En este punto, hagamos un breve intermedio para ver cómo se administran aquí las ROM personalizadas (construidas desde el código fuente). Es lo que los astutos entre ustedes estarán gritando en su pantalla ahora mismo; después de todo, somos XDA, el hogar de HTC HD2, el teléfono más duradero del mundo... (Sólo para que conste, los genios locos de allí están corriendo Android 6.0 en el HD2 estos días! Nada mal para un teléfono enviado originalmente con Windows Mobile 6.5 en 2009)
Se han adoptado 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 complicado y requiere muchos cambios para mantenerlo. El otro enfoque es "cuñar" el binario OEM.
El enfoque "shim" es escribir y construir usted mismo una pequeña biblioteca nueva, 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, tal vez diríamos que cualquier brillo solicitado por encima de 128 encenderá el LED, y cualquier brillo por debajo lo apagará. O podría decir que cualquier cosa que no sea cero lo activará. Depende del desarrollador. Compilan el shim y hacen que Android lo use en lugar del nativo. Luego, la corrección llama al blob OEM.
Un rápido "empuje de adb" y un reinicio deberían activar la cuña y permitirle controlar su LED ficticio, aunque solo tenga el antiguo HAL.
El problema es que éste es claramente un proceso imperfecto. Ahora obtendrás peculiaridades: este dispositivo tendrá un flash bastante malo, que estará completamente encendido o completamente apagado. Eso no es ideal: el sistema operativo cree que está generando una luz muy suave, pero al LED real se le dice 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 antiguo teléfono.
(Sí, esta es una de las razones por las que hay peculiaridades y errores cuando los usuarios y desarrolladores de XDA logran sus locas e insanas hazañas de portabilidad. Quiero decir, diablos, el Galaxia S II lleva un aparentemente utilizable ROM de Android 6.0 ahora. ¡Muchos 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 fabricantes de equipos originales ya están trabajando al menos con un teléfono por delante de donde nos encontramos ahora. Su atención se centra en el próximo teléfono que están a punto de vender; no se les puede culpar, ya que sólo ganan dinero con los dispositivos que venden. No ganan dinero con los dispositivos que vendieron hace uno o dos años, por lo que tienen que seguir lanzando nuevos dispositivos para existir. Esta es una de las razones por las que HTC y Blackberry están en problemas: no importa cuántos ejecutivos mantengan el control de su viejo Blackberry Curve, ya que no consiguen vender un nuevo dispositivo allí.
Si el OEM no obtiene un BSP, no adoptará el enfoque XDA de piratear una compilación. ¿Por qué? Bien, Necesitan soportar este firmware para sus clientes.. Si lanzan un firmware que funciona a medias, los usuarios los odiarán, despotricarán y delirarán, y mantendrán sus líneas de soporte sonando durante días.
Los OEM también tienen que competir con los transportistas, al menos en los mercados no europeos. Los operadores no quieren que los clientes tengan problemas con las actualizaciones de software. De hecho, los operadores a menudo prefieren no publicar actualizaciones de software.
Para entender esto, imagina a tu tía abuela Alice. Ella es la que te llama a horas inoportunas del día para pedirte ayuda con "esa cosa de la computadora". Luego describe cómo hacer clic en el "menú Inicio" y tiene que identificarlo como la "bandera grande en la esquina inferior izquierda", y se encuentra con confusión. Aproximadamente 45 minutos (y mucha frustración) después, resulta que la tía Alice arrastró su menú de inicio al borde derecho de la pantalla y simplemente necesitaba arrastrarlo hacia atrás. ¡Sí, con el botón izquierdo del ratón!
Ahora imagina que tienes mil tía Alice'. Todos están llamando a su atención al cliente, sin poder encontrar Candy Crush en su teléfono, preocupados de que un hacker lo haya eliminado de su teléfono. Ah, y los íconos se ven un poco diferentes ahora: ¿tal vez el hacker todavía está en su teléfono?
Sí, esto pretende ser un poco de humor alegre, pero hasta que experimentes las razones por las que las personas llaman a su proveedor para pedir ayuda, no creerás los problemas que tienen. Una actualización de software que cambie el funcionamiento del teléfono o la ubicación de las cosas provocará una importante sobrecarga de soporte. Como mínimo, requiere volver a capacitar al personal de soporte (porque, lamentablemente, la mayoría de ellos no son sus ávidos lectores de XDA).
Una vez que el OEM obtenga el BSP, transferirá su ROM y aplicará todos sus cambios a la ROM. Agregarán su bloatware y agregarán una apariencia horrible de dibujos animados que se vería más como en casa en un anime para adolescentes. Luego lo probarán.
Mucho.
Hay todo tipo de requisitos que su teléfono debe cumplir. Las redes móviles están diseñadas para confiar en que el equipo del usuario (lo que llamamos teléfono) se comportará correctamente. Esto significa que se necesitan muchas pruebas para aprobar el dispositivo. Las actualizaciones de software corren el riesgo de cambiar comportamientos, por lo que es necesario volver a probar las cosas. 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 lo vendió. Y en este punto, su teléfono no recibe más actualizaciones de versión importantes.
Reducir la cantidad de BSP que el OEM desea entregar es una excelente manera de ahorrar dinero, si solo necesita el actual y no tiene intención de entregar ninguna versión principal. aumenta, esto ahorrará dinero en la compra y licencia inicial de SoC, pero a expensas de algunos nerds enojados en XDA en el futuro, preguntándose por qué no obtuvieron un actualizar.
Las actualizaciones son complejas. Hay muchas personas diferentes involucradas en la cadena. Nada de esto excusa a los OEM del actual estado indiferente y patético de las actualizaciones en Android. No obstante, aquí hay algunos desafíos reales.
Muchos fabricantes de equipos originales tienen la culpa de hacer demasiadas promesas, y la inevitable insuficiencia de resultados que ahora asociamos. La triste realidad es que para la mayoría de los OEM, las actualizaciones de software son sólo una molestia de la que podrían prescindir.
El sector móvil está mayoritariamente estancado en la mentalidad de los teléfonos básicos. Es decir, cuando un dispositivo nunca recibe actualizaciones. Pruébelo una vez, envíelo y nunca mire atrás. Con los problemas de seguridad de los teléfonos inteligentes modernos y la enorme complejidad de ejecutar un sistema operativo completo de propósito general, con cientos de bibliotecas externas, esa ya no es una opción. O al menos eso no debería ser. Google ha tomado algunas medidas para solucionar este problema, al menos publicando boletines y parches de seguridad 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 importante del sistema operativo Android).
Lamentablemente, esto no es suficiente. Aunque Google sigue publicando actualizaciones, la seguridad de su dispositivo aún depende del fabricante del SoC, ya que los fabricantes de SoC están tan petrificados alguien descubre cómo enciende un par de LED o emite un sonido a través de un altavoz, envía enormes cantidades de burbujas binarias en su dispositivos. Estos blobs contienen un código terriblemente inseguro (¡solo eche un vistazo a los boletines de seguridad anteriores de Google si cree que esto es una exageración!), y es necesario actualizarlos. Lo que significa que se requieren BSP actualizados.
Las computadoras de escritorio (y, por extensión, las computadoras portátiles) tienen una arquitectura completamente diferente a la de los dispositivos móviles. Su teléfono móvil o tableta es en realidad un trozo de silicio de propiedad exclusiva, diseñado apresuradamente por algunas personas que tienen buenas intenciones, pero que no tienen tiempo suficiente para hacer algo bueno. El mercado se mueve tan rápido que apenas pueden seguir el ritmo al que el marketing exige el lanzamiento de nuevos productos.
Esto significa que se toman atajos: no encontrará que su teléfono sea compatible con el kernel 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 optaron por algunas formas estándar de inicio: anteriormente era MBR (registro de inicio maestro) con 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 kernel 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ó el conector para auriculares al revés? ¡Simplemente hackéelo 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? ¡Haz un truco para verificar el código de la versión interna y voltea el video si es la versión 1!
Trucos como estos resuelven el problema inmediato, pero solo raspan la superficie de los cambios extraños y específicos del producto que se están produciendo. Demonios, a veces incluso hay chips completamente diferentes en diferentes revisiones del mismo teléfono, debido a decisiones comerciales. Esto llevó a hackeos en los controladores y decisiones extrañas que solo tenían sentido en ese momento, para que el teléfono funcionara y pudiera enviarse la próxima semana.
Si bien se está trabajando para lograr soporte principal para que los chips ARM de 64 bits arranquen usando UEFI, hasta ahora ha habido No hay un movimiento claro hacia una forma más estandarizada de arrancar dispositivos ARM.. Y eso es triste, porque significa que los teléfonos seguirán siendo desechados mucho antes del final de su vida útil. vidas laborales, porque es simplemente demasiado caro mantener la deuda técnica y la carga sobre sus software.
Por otro lado, si un OEM sólo gana dinero con la venta de un dispositivo, ¿no necesita asegurarse de que la gente siga comprando teléfonos nuevos? ¿El mercado de PC pasaría a este modelo si no hubieran existido 30 años de impulso y software heredado utilizando la plataforma y el estándar de PC abiertos?
Esta es una pregunta difícil sin el conocimiento interno de Qualcomm, que lamentablemente no tenemos en este momento. Sin embargo, podemos extraer información de los requisitos CTS y API del controlador de Android 7.0. Los requisitos de CTS especifican lo que Google espera de un dispositivo que ejecuta un firmware determinado. El "gran martillo" utilizado para hacer cumplir estos requisitos es la licencia de Google para utilizar su paquete patentado de servicios Google Play. Si no cumples, no podrás enviar Google Apps al dispositivo.. Si bien, para algunos, esto podría verse como una ventaja, obviamente esto no es lo que los usuarios quieren y esperan de un dispositivo.
Android 7.0 no ha agregado muchos cambios en HAL o controladores (como se describió anteriormente), por lo que es poco probable que cualquier incompatibilidad provenga de allí específicamente. Sin embargo, lo que probablemente planteará un problema es la introducción de un nuevo requisito para la API de gráficos Vulkan o GLES 3.1, estar disponible para aprobar CTS.
En la actualidad, muchos Systems-on-Chip (SoC) no tienen soporte para Vulkan en su procesador gráfico, incluido el MSM8974. Aquí 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 deje de dar soporte a el (a sus ojos) chipset MSM8974 envejecido y no proporciona un BSP (paquete de soporte de placa) para 7.0 en esa plataforma. Si ese fuera el caso, significaría que es casi seguro que los OEM no incluirán 7.0 en el dispositivo; tendrían que encontrar de alguna manera soporte para Vulkan o GLE 3.1 para su GPU y fuente de GPU. El código es una de las partes ridículamente bien protegidas de las pilas móviles (sin ninguna razón real, agregaríamos: vea AMD, abre el código fuente de 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 no veremos ajustes para introducir compatibilidad con esto.
Como la versión 7.0 no ha estado disponible por mucho tiempo, existe una posibilidad real de que queden otros conjuntos de chips (aparte del pequeño número dentro del propio AOSP) atrasado en 6.0, debido a problemas de hardware y controladores (es decir, sin BSP actualizado) o a la falta de soporte del proveedor de SoC con respecto a Vulkan o GLES 3.1 API. Actualmente, ni el Snapdragon 800 ni el 801 son compatibles con ninguno de estos.
La mejor apuesta es mirar este espacio. - Los desarrolladores de XDA ya están haciendo buenos progresos 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 comiencen a experimente frustración debido a la fragmentación si suficientes usuarios comienzan a ejecutar ROM personalizadas sin Vulkan o GLES 3.1 ¿apoyo?
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. Sin embargo, no recibirá la próxima actualización de iOS 10, 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 admite la API de gráficos; el iPhone 4s y el iPhone 5 no lo hacen. cuentan con la API de gráficos Metal de Apple, que es un escenario algo similar al visto con Android en Vulcano. La única diferencia es que Apple siguió admitiendo los dispositivos más antiguos sin la nueva API de gráficos.
¿Qué opinas? ¿Actualizarás una ROM personalizada en tu teléfono para extender su vida útil? ¿Tienes algo que decir en los comentarios a continuación?