Samsung, Exynos y AOSP explicados: una historia de traición

Recuerden, recuerden, la primera de la Nota, el lanzamiento de ICS y la trama.

No conozco ninguna razón por la que alguna vez deba olvidarse la traición de Superbrick.

Los miembros mayores del foro y los usuarios de Android de los primeros dispositivos Samsung pueden recordar vagamente el Fiasco del superladrillo. Los acontecimientos que condujeron a Superbrick son largos y complejos. En aras de la brevedad, un tl; La explicación principal es que una actualización de ICS filtrada para algunas variantes de operador del Galaxy S2 i9100 y del Galaxy Note N7000 causó un ladrillo permanente. Este no era un ladrillo duro ordinario, ya que un dispositivo afectado no podía resucitar a través de un JTAG y estaba completamente muerto y no respondía. El superladrillo afectó al eMMC del dispositivo y, por lo tanto, las reparaciones solo se pudieron realizar con un cambio completo de la placa base.

El descargo de responsabilidad que generalmente acompaña a las "filtraciones" también fue válido en este caso: las filtraciones son esencialmente software "inédito" que puede o no ser apto para el consumo público. Sin embargo, para complicar las cosas, este kernel ICS superbricking llegó al Galaxy Note N7000 como una versión oficial disponible a través de actualizaciones de Kies y OTA.

El fiasco de Superbrick y el drama que siguió, cortesía de la actitud de Samsung hacia los desarrolladores, fueron destacados en una serie de 13 publicaciones de Andrew Dodd, también conocido como desarrollador reconocido senior de XDA. Entropía512 en su Google+. Puedes encontrar el comienzo de esta serie de publicaciones. aquí. Nosotros altamente recomendado que los lectores se tomen un tiempo libre y lean la serie completa de publicaciones para tener una conciencia contextual completa y comprender toda la gravedad de la situación que ocurrió en 2012-13.

Para resaltar algunos puntos importantes, aquí hay algunos fragmentos (con énfasis adicional) de las publicaciones:

"...Obviamente, casi todos los que me siguen están al tanto de la reciente tormenta en las redes sociales resultante de la frustración que La comunidad de firmware de Android de terceros (especialmente los usuarios y desarrolladores de CyanogenMod) ha estado experimentando con Samsung. El fiasco del "Superbrick", la falta de documentación del SoC Exynos4 de Samsung en comparación con los SoC de Qualcomm y TI, y una larga lista de otros problemas: todo esto ha llegado recientemente a un punto crítico con la decisión de todos los mantenedores de dispositivos Exynos4 actualmente activos de no aceptar ningún dispositivo nuevo..." - Publicación principal.

"...En noviembre, Samsung lanzó XWKK5 para I9100 y UCKK6 para I777. Bluetooth HID en estas compilaciones no funcionaría con ningún kernel creado en origen, solo con los archivos binarios asociados con esas compilaciones. Samsung nunca lanzó otra actualización de la fuente Gingerbread para el I9100, a pesar de que sus archivos binarios mostraron evidencia clara de un cambio funcional en la fuente. De manera similar, la fuente I777 UCKK6 no se lanzó hasta algún momento desconocido a mediados de 2012; estoy bastante seguro de que no fue hasta después de que se lanzó I9100 ICS, en el mejor de los casos. Así es: Samsung estaba violando la GPL con I777 UCKK6 y todas las versiones I9100 Gingerbread desde XWKK5 (noviembre de 2011) hasta que lanzaron oficialmente el I9100 ICS (marzo de 2012). En realidad, Técnicamente todavía lo son, ya que la fuente Gingerbread correspondiente a esos núcleos nunca se publicó, pero en realidad no importa. más..."

"...Casi al mismo tiempo, Samsung lanzó la Tab 7.0 Plus y la Tab 7.7, ambas basadas en el mismo SoC Exynos 4210 que se encuentra en el GS2... Estos dispositivos usaban un chip wifi de la serie Atheros AR6000. Curiosamente, Atheros proporciona fuente para estos dispositivos bajo una licencia dual, GPL y BSD. (Como Atheros posee todos los derechos de autor de todos los componentes de su controlador de referencia, esto es legal). Samsung eligió la licencia BSD para este controlador. El resultado final es que, cuando se le preguntó por la fuente del controlador wifi (que no estaba presente en las fuentes de estos dispositivos), Samsung respondió con "el código es de licencia dual GPL o BSD". Elegimos BSD [en lugar de GPL]"..." - Publicación principal

"...Si había alguna conclusión obvia que sacar del ICS en el GT-I9100, era que Las pieles del fabricante no duran.. Después de ejecutar el firmware I9100 ICS en el I777 (principalmente mediante ingeniería inversa de los canales de micrófono intercambiados en este dispositivo, que tomó la mayor parte de un fin de semana de trabajo...), era obvio que Touchwizz revirtió muchos de los beneficios de ICS. Partes del firmware eran "nuevas", partes eran "Gingerbread heredado" y las constantes discontinuidades eran discordantes... - Publicación principal

Peor aún... Lanzamiento de ICS oficial para el N7000 con XXLPY. Pensamos que Samsung nunca permitiría que un error horrible como este entrara en un kernel lanzado, pero estábamos equivocados...

- Publicación principal

"...Un contacto de Samsung finalmente reconoció que estaban al tanto de la situación y que estaban "trabajando diligentemente" en ello... Finalmente, se nos presentó la "solución" de Samsung. Chainfire NO estaba contento con la "solución" propuesta, yo tampoco... No implicaba protección a nivel de kernel y era inferior a lo que ya teníamos con BOARD_SUPPRESS_EMMC_WIPE en CM. Además nos pidieron que no distribuyéramos la solución y que redireccionáramos a los desarrolladores del kernel a buscarles una solución..."

"...Samsung también se negó prácticamente a discutir cualquier solución que involucre gestores de arranque... El razonamiento, que no tenía sentido, fue que casi todos sus reclamos de garantía debido a firmware personalizado antes de este defecto de eMMC se debían a corrupción del gestor de arranque... Por supuesto, esto no tiene sentido, ya que Queríamos analizar métodos de recuperación de la corrupción del gestor de arranque, lo que eliminaría la mayoría de estos costos de garantía para Samsung.. Incluso nos ofrecimos a hacer la mayor parte de la ingeniería y la implementación de la solución nosotros mismos, siempre y cuando Samsung solo nos diera algunos pequeños componentes específicos que Dominik y Adam necesitaban..."

"...Samsung, después de "trabajar diligentemente" durante un mes, nos lanza una granada a la cara

A principios de julio, se filtró XXLQ5 para el I9100. En un día se acumularon numerosos informes sobre ladrillos. No mucho tiempo después, XWLPM se puso en marcha en Kies y La gente también estaba construyendo ladrillos de izquierda a derecha con esta construcción..

A pesar de afirmar ser trabajando diligentemente En este problema, Samsung tomó un dispositivo que antes era seguro y lo puso en peligro..." - Publicación principal

"... Entonces, en este punto: estamos a mediados de noviembre de 2012 y ni un solo dispositivo afectado por el eMMC defectuoso de Samsung ha recibido una solución del kernel. Si bien los esfuerzos de la comunidad tienen tasas de daño MUY bajas, siempre y cuando los núcleos oficiales de Samsung estén vulnerable, todavía recibiré un MP cada pocos días de un usuario de Superbrick que necesita ayuda y que no puedo ayuda..." - Publicación principal

"...A mediados de agosto, decidí ir en contra de mi buen juicio y comprar un Note 10.1 (variante WiFi - GT-N8013). Pensé que como compartía un SoC con el I9300, sería una apuesta bastante segura...

Ahora que lo había confirmado, tanto por la falta de funcionalidad del controlador wifi como por varias comparaciones de cadenas con la copia de seguridad kernel original, que las fuentes publicadas para cualquier variante de N80xx NO coincidían con los kernels originales (todos tenían el mismo wifi roto conductor y otras personas que estaban trabajando con las fuentes se quejaron de problemas similares), le planteé el problema a mi contacto en Samsung...

Localizaron a alguien y la respuesta de esa persona fue: Samsung no tenía la obligación de proporcionar una fuente que coincidiera con la compilación UEALGB para GT-N8013, ya que no era una compilación oficial. Sí, es cierto, alguien en realidad se atrevió a afirmar que el firmware preinstalado en cada unidad GT-N8013 vendida en Estados Unidos era una FUGA. Esta fue la tercera vez que alguien dentro de Samsung Mobile mintió descaradamente en la cara de mi contacto..." - Publicación principal

"... Entonces, entre eso, otras cosas (ver entregas anteriores de esta saga para ver muchos ejemplos) y Superbrick, Casi todos los mantenedores de Exynos4 estaban al límite del agotamiento con Samsung y especialmente con Exynos4.

Indiqué que el Note 10.1 iba a ser mi último dispositivo y no estaba seguro de cuánto tiempo me quedaría con el I777 y el N7000, ya que en ese momento también estaba agotado.

Estaba cansado de estar meses detrás del resto del equipo de Cyanogenmod porque trabajaba con dispositivos que tenían más blobs y más interrupciones en la interfaz que cualquier otro dispositivo.

(A excepción de los dispositivos Tegra3, pero la gente ya sabía que debían evitarlos a menos que estuvieran en un Nexus)..." - Publicación principal

"...Cerca del final [de BABBQ 2012] fue la presentación de relaciones con los desarrolladores de Samsung. Aquí fue donde prometieron mejorar la calidad del código fuente de referencia y la documentación para Exynos4, aliviando en teoría las preocupaciones de la comunidad. El contenido real de la presentación prometía poco. casi todo lo que anunciaron eran cosas que ya existían técnicamente pero que eran de poca o ninguna utilidad debido a que estaban desactualizadas o simplemente no eran funcionales..." - Publicación principal

Todo esto ha sido solo otro caso más en el que Samsung habla y hace promesas y no las cumple, tal como han estado hablando y haciendo promesas durante más de un año. Se supone que las placas de desarrollo están ADELANTE a los teléfonos: no necesitan lidiar con pruebas de operador, certificaciones inalámbricas, o cualquiera de las cosas que suelen ser conocidas por frenar el teléfono actualizaciones. Además, su objetivo previsto son los DESARROLLADORES, por lo que deberían ser la "vanguardia". Esta es la fuente de referencia de Qualcomm y TI: es absolutamente lo último, por delante de todo lo visto en los teléfonos. Lo que estamos recibiendo de Samsung tiene más de 6 meses de antigüedad: ICS para un SoC que estaba en un teléfono que se lanzó con ICS en la primavera de 2012, y que recibió una actualización oficial de Jellybean (aprobaciones de operador/certificados inalámbricos y todo) a principios de octubre 2012... ¿Pero todavía están trabajando en ICS como fuente de referencia?

- Publicación principal

La serie concluyó con una publicación resumida que se puede encontrar aquí. Recomendamos a todos los usuarios que lo lean antes de continuar.

El punto de partida de este artículo fue intentar explicar por qué los dispositivos Exynos generalmente carecen de desarrollo basado en AOSP en comparación con los dispositivos Qualcomm. La serie de publicaciones de G+ mencionada y citada anteriormente destacó las dificultades que enfrenta el mantenedor de un dispositivo Exynos. La publicación está fechada para el período 2011-2013, por lo que nos comunicamos con algunos de los desarrolladores mencionados para averiguar cómo está la situación actualmente. Después de todo, muchas cosas pueden cambiar en 3 años en el mundo móvil.

Al parecer, no para Samsung y su soporte para AOSP.

P: ¿Por qué las ROM AOSP tardan tanto en llegar a los dispositivos Exynos, en comparación con, por ejemplo, los dispositivos Qualcomm?

R: Desarrollador senior reconocido de XDA códigoworkx:

Qualcomm publica un código fuente siempre actualizado que es necesario para que todos los componentes de su plataforma funcionen en aosp. Ver aquí.

Samsung no hace nada.

Desarrollador senior reconocido de XDA Entropía512:

"Qualcomm CAF es muy superior en términos de trazabilidad hacia/desde versiones OEM (nunca he visto un dispositivo OEM que no sea un Nexus que no fuera fácilmente rastreable hasta una etiqueta CAF en CódigoAurora), calidad del código y frecuencia de actualizaciones de señal (que no tiene KitKat para el "Arndale Octa" y nada más nuevo que ICS para el Exynos4). Además de estar desactualizado, no hay absolutamente ninguna trazabilidad entre los OEM de Samsung Mobile. lanzamientos y la fuente de referencia Exynos, mientras que todos los OEM tienen una cantidad bastante decente de trazabilidad hasta CAF (HTC y Samsung algo menos que otros, pero aún mucho mejor que cualquier otra cosa). Exinos)

Espera, ¿finalmente lanzaron JB para Origen Quad? No hasta que KitKat estuvo a punto de salir... Y lo que llamaron JB probablemente estuvo cerca del desastre inútil que fue su "ICS" de pan de jengibre

Exynos3, también conocido como Hummingbird, fue una historia completamente diferente gracias al Nexus S, pero Samsung se ha asegurado de nunca compartir un conjunto de chips entre los dispositivos Nexus y cualquiera de sus otros dispositivos desde entonces. (Galaxy Nexus era OMAP4, mientras que todo lo demás de esa época, con algunas excepciones, era Exynos4, Nexus 10 y Samsung Chromebook fueron dos de los únicos Los dispositivos Exynos 5250 alguna vez se enviaron, Exynos 54xx cambió de GPU Mali a PowerVR junto con una gran cantidad de otros cambios, por lo que manta fue inútil para I9500. etc.)"

P: ¿Cuál es el futuro de Exynos Development? ¿Qué medidas podría tomar Samsung para ser más amigable con los desarrolladores?

R: Código de trabajox:

No hay futuro. Todos los desarrolladores a los que les ha escrito dejaron de funcionar en dispositivos Exynos hace mucho tiempo. La mayoría de ellos incluso dejaron de funcionar en dispositivos Samsung en general.

Hemos pedido más de una vez el código fuente y no pasó nada. Simplemente no les importa la comunidad. Lo único que les importa es $$$

Está claro que la situación es casi idéntica a la de hace más de tres años. Los dispositivos Samsung, específicamente los basados ​​en Exynos, siguen siendo malos ejemplos de cómo mostrar el trabajo de la comunidad de desarrollo fuera de los ejemplos basados ​​en Touchwiz. Todo el desarrollo del dispositivo se limita en gran medida a modificaciones de Touchwiz, con escenarios personalizados ROM que giran en torno a agregar o eliminar funciones del "skin" del sistema operativo de código cerrado de Samsung a la inversa ingeniería.

Esto no quiere decir que los dispositivos Exynos no tengan soporte alguno para las ROM AOSP. Las Roms AOSP, como CM y similares, no eventualmente aterrizan en estos dispositivos, pero vienen después de una gran cantidad de piratería informática de bajo nivel y esfuerzos extremos por parte de los mantenedores lo suficientemente valientes como para dedicar todo su tiempo libre a arreglar lo que Samsung rompió. Incluso entonces, el resultado final no es una experiencia AOSP como la que se esperaría normalmente, y por esto, puedes culpar con seguridad a Samsung.

Las heridas de Superbrick aún están frescas en aquellos que unieron su corazón y su alma para trabajar por una causa rota que se hace llamar Samsung. Si está buscando obtener un dispositivo cuyo primer criterio sea el desarrollo de ROM personalizado y la compatibilidad con desarrolladores de ROM de terceros, siga las sabias palabras compartidas por Codeworkx:

Deje de apoyar a estas empresas comprando sus dispositivos.

Tome un dispositivo Sony o Nexus, obtenga roms Aosp de calidad, buen soporte comunitario y simplemente sea feliz.