Vous êtes-vous déjà demandé pourquoi les appareils Exynos ne bénéficient pas du meilleur support AOSP? Découvrez-le dans notre récapitulatif des événements !
Rappelez-vous, rappelez-vous, le premier de la note, la version et l'intrigue d'ICS
Je ne vois aucune raison pour laquelle la trahison de Superbrick devrait être oubliée
Les membres plus âgés du forum et les utilisateurs Android des premiers appareils Samsung se souviennent peut-être vaguement du Fiasco des superbriques. Les événements qui mènent à Superbrick sont longs et complexes. Par souci de brièveté, un tl; L'explication du Dr est qu'une fuite de mise à jour ICS pour quelques variantes d'opérateur du Galaxy S2 i9100 et du Galaxy Note N7000 a provoqué un problème. brique permanente. Il ne s’agissait pas d’une brique dure ordinaire, car un appareil concerné ne pouvait pas être ressuscité via un JTAG et était complètement mort et ne répondait plus. La superbe brique a affecté l'eMMC de l'appareil et, par conséquent, les réparations ne peuvent être effectuées qu'avec un changement complet de la carte mère.
L'avertissement qui accompagne généralement les « fuites » était également valable dans ce cas, à savoir que les fuites sont essentiellement des logiciels « inédits » qui peuvent ou non être adaptés à la consommation publique. Cependant, pour compliquer les choses, ce noyau ICS superbe a été intégré au Galaxy Note N7000 en tant que version officielle disponible via les mises à jour Kies et OTA.
Le fiasco de Superbrick et le drame qui l'a accompagné, dû à l'attitude de Samsung envers les développeurs, a été souligné dans une série de 13 articles rédigée par Andrew Dodd, alias XDA Senior Recognized Developer. Entropie512 sur son Google+. Vous pouvez retrouver le début de cette série d'articles ici. Nous recommande fortement que les lecteurs prennent un peu de temps et lisent la série complète d'articles pour acquérir une conscience contextuelle complète et comprendre toute la gravité de la situation qui s'est produite en 2012-2013.
Pour souligner quelques points importants, voici quelques extraits (avec accentuation) des articles :
"... De toute évidence, presque tous ceux qui me suivent sont au courant de la récente tempête sur les réseaux sociaux résultant de la frustration des La communauté de micrologiciels Android tiers (en particulier les utilisateurs et les développeurs de CyanogenMod) a été confrontée à Samsung. Le fiasco "Superbrick", le manque de documentation du SoC Exynos4 de Samsung par rapport aux SoC de Qualcomm et TI, et une longue liste d'autres problèmes - tout cela a récemment atteint son paroxysme avec la décision de tous les mainteneurs d'appareils Exynos4 actuellement actifs de ne pas prendre de nouveaux appareils..." - Message parent.
"...En novembre, Samsung a lancé XWKK5 pour le I9100 et UCKK6 pour le I777. Bluetooth HID sur ces versions ne fonctionnerait avec aucun noyau construit à la source - uniquement avec les binaires associés à ces versions. Samsung n'a jamais publié une autre mise à jour de la source Gingerbread pour le I9100, même si ses binaires montraient des preuves claires d'un changement fonctionnel de la source. De même, la source I777 UCKK6 n'a été publiée qu'à une date inconnue à la mi-2012 - je suis presque certain qu'au mieux, pas avant la sortie de l'I9100 ICS. C'est vrai: Samsung violait la GPL avec I777 UCKK6 et chaque version I9100 Gingerbread de XWKK5 (novembre 2011) jusqu'à la sortie officielle du I9100 ICS (mars 2012) - En fait, techniquement, ils le sont toujours, car la source Gingerbread correspondant à ces noyaux n'a jamais été publiée, mais cela n'a pas vraiment d'importance plus..."
"... À peu près à la même époque, Samsung a lancé les Tab 7.0 Plus et Tab 7.7, tous deux basés sur le même SoC Exynos 4210 que celui du GS2... Ces appareils utilisaient une puce wifi de la série Atheros AR6000. Il est intéressant de noter qu'Atheros fournit la source de ces appareils sous une double licence, GPL et BSD. (Comme Atheros détient l'intégralité des droits d'auteur sur tous les composants de son pilote de référence, cela est légal.) Samsung a choisi la licence BSD pour ce pilote. Le résultat final est que, lorsqu'on lui demande la source du pilote wifi (qui n'était pas présente dans les fichiers sources de ces appareils), Samsung a répondu par "le code est à double licence GPL ou BSD. Nous choisissons BSD [sur GPL]"..." - Message parent
"...S'il y avait une conclusion évidente à tirer de l'ICS sur le GT-I9100, c'était bien celle-ci. les skins du fabricant ne durent pas. Après avoir exécuté le micrologiciel I9100 ICS sur le I777 (principalement par rétro-ingénierie des canaux micro échangés sur cet appareil, qui a pris la majeure partie d'un week-end de travail...), il était évident que Touchwizz annulait de nombreux avantages de ICS. Certaines parties du firmware étaient "nouvelles", d'autres étaient "anciennes Gingerbread" et les discontinuités constantes étaient choquantes... - Message parent
Encore pire... ICS officiel lancé pour le N7000 avec XXLPY. Nous pensions que Samsung ne laisserait jamais un horrible bug comme celui-ci s'introduire dans un noyau publié, mais nous avions tort...
- Message parent
"...Un contact chez Samsung avait finalement reconnu qu'il était au courant de la situation et qu'il "y travaillait avec diligence"... Finalement, la « solution » de Samsung nous a été présentée. Chainfire n'était PAS satisfait de la "solution" proposée, moi non plus... Cela n'impliquait aucune protection au niveau du noyau et était inférieur à ce que nous avions déjà en place avec BOARD_SUPPRESS_EMMC_WIPE dans CM. De plus ils nous ont demandé de ne pas distribuer la solution et de rediriger vers eux les développeurs du noyau à la recherche d'une solution..."
"...Samsung a également quasiment refusé de discuter de solutions impliquant des chargeurs de démarrage... Le raisonnement, qui n'avait aucun sens, était que presque toutes leurs réclamations au titre de la garantie dues à un micrologiciel personnalisé avant ce défaut eMMC étaient dues à une corruption du chargeur de démarrage... Bien entendu, cela n’a aucun sens puisque nous voulions discuter des méthodes de récupération après une corruption du chargeur de démarrage, ce qui éliminerait la majorité de ces coûts de garantie pour Samsung. Nous proposions même de réaliser nous-mêmes la majorité de l'ingénierie et du déploiement de la solution, à condition que Samsung nous fournisse simplement quelques petits composants spécifiques dont Dominik et Adam avaient besoin..."
"...Samsung, après avoir « travaillé assidûment » pendant un mois, nous lance une grenade au visage
Début juillet, XXLQ5 a fuité pour le I9100. En une journée, de nombreux rapports de briques se sont accumulés. Peu de temps après, XWLPM a été mis en ligne sur Kies, et les gens briquaient à gauche et à droite avec cette construction aussi.
Bien qu'il prétende être travailler avec diligence sur ce problème, au lieu de cela, Samsung a pris un appareil auparavant sûr et l'a mis en danger..." - Message parent
"...Donc, à ce stade - nous sommes à la mi-novembre 2012, et pas un seul appareil affecté par l'eMMC défectueux de Samsung n'a reçu de correctif du noyau. Bien que les efforts de la communauté entraînent des taux de dégâts BEAUCOUP réduits, tant que les noyaux officiels de Samsung sont vulnérable, je vais toujours recevoir un MP tous les quelques jours d'un utilisateur de Superbricked qui a besoin d'aide et que je ne peux pas aide..." - Message parent
"...À la mi-août, j'ai décidé d'aller à l'encontre d'un meilleur jugement et d'acheter un Note 10.1 (variante WiFi - GT-N8013). Je pensais que comme il partageait un SoC avec le I9300, ce serait une valeur assez sûre...
Maintenant que j'avais confirmé, à la fois par la non-fonctionnalité du pilote wifi et diverses comparaisons de chaînes avec le fichier sauvegardé noyau d'origine, que les sources publiées pour toute variante N80xx ne correspondaient PAS aux noyaux d'origine (tous avaient le même wifi défectueux conducteur et d'autres personnes qui travaillaient avec les sources se sont plaintes de problèmes similaires.), j'ai soulevé le problème avec mon contact au Samsung...
Ils ont retrouvé quelqu'un, et la réponse de cette personne a été la suivante: Samsung n'était pas obligé de fournir une source correspondant à la version UEALGB du GT-N8013, car il ne s'agissait pas d'une version officielle. Oui, c'est vrai - quelqu'un en fait a osé affirmer que le firmware préinstallé sur chaque unité GT-N8013 vendue aux États-Unis était une FUITE. C'était la troisième fois que quelqu'un au sein de Samsung Mobile mentait de manière flagrante au visage de mon contact..." - Message parent
"...Donc entre ça, d'autres choses (voir les précédents épisodes de cette saga pour de nombreux exemples), et Superbrick, la quasi-totalité des mainteneurs d'Exynos4 étaient au bord de l'épuisement avec Samsung et surtout avec Exynos4.
J'ai indiqué que le Note 10.1 allait être mon dernier appareil, et je ne savais pas combien de temps je resterais avec le I777 et le N7000, car j'étais également épuisé à ce stade.
J'en avais marre d'être en retard de plusieurs mois sur le reste de l'équipe CyanogenMod parce que je travaillais avec des appareils qui avaient plus de blobs et plus de ruptures d'interface dans les blobs que n'importe quel autre appareil.
(Sauf pour les appareils Tegra3, mais les gens savaient déjà qu'il fallait les éviter à moins d'être dans un Nexus.)..." - Message parent
"... Vers la fin [du BABBQ 2012] a eu lieu la présentation des relations avec les développeurs de Samsung. C'est là qu'ils ont promis d'améliorer la qualité du code source de référence et de la documentation d'Exynos4, atténuant en théorie les inquiétudes de la communauté. Le contenu réel de la présentation promettait peu - presque tout ce qu'ils annonçaient étaient des éléments qui existaient déjà techniquement mais qui étaient de peu ou pas d'utilité car obsolètes ou simplement non fonctionnels..." - Message parent
Tout cela n’est qu’un autre cas où Samsung parle et fait des promesses mais ne tient pas ses promesses, tout comme ils parlent et font des promesses depuis plus d’un an. Les cartes de développement sont censées être en avance sur les combinés - elles n'ont pas besoin de s'occuper des tests des opérateurs, certifications sans fil, ou tout autre élément généralement connu pour retenir le combiné mises à jour. De plus, leur cible est les DÉVELOPPEURS, ils devraient donc être à la pointe de la technologie. C'est ce qu'est la source de référence de Qualcomm et TI: c'est la dernière en date, en avance sur tout ce qui est vu sur les combinés. Ce que nous recevons de Samsung est obsolète depuis plus de 6 mois - ICS pour un SoC qui se trouvait dans un combiné lancé avec ICS. au printemps 2012, et qui a reçu une mise à jour officielle de Jellybean (approbations des opérateurs/certificats sans fil et tout) début octobre 2012... Mais ils travaillent toujours sur ICS pour leur source de référence ???
- Message parent
La série s'est conclue par un article de synthèse que l'on peut retrouver ici. Nous recommandons à tous les utilisateurs de le lire avant de continuer.
Le point de départ de cet article était d'essayer d'expliquer pourquoi les appareils Exynos manquent généralement en termes de développement basé sur AOSP par rapport aux appareils Qualcomm. La série d'articles G+ mentionnée et citée ci-dessus a mis en évidence les difficultés rencontrées par un responsable d'un appareil Exynos. Le message est daté de la période 2011-2013, nous avons donc contacté quelques-uns des développeurs mentionnés pour comprendre l'état actuel de la situation. Après tout, beaucoup de choses peuvent changer en 3 ans dans le monde mobile.
Pas pour Samsung et son support pour AOSP, semble-t-il.
Q: Pourquoi les ROM AOSP mettent-elles autant de temps à arriver pour les appareils Exynos, par rapport aux appareils Qualcomm, par exemple ?
R: Développeur senior reconnu XDA codeworkx:
Qualcomm publie un code source toujours à jour, nécessaire au fonctionnement de tous les composants de sa plate-forme sur aosp. Voir ici.
Samsung ne fait rien.
Développeur senior reconnu XDA Entropie512:
"Qualcomm CAF est largement supérieur en termes de traçabilité vers/depuis les versions OEM (je n'ai jamais vu d'appareil OEM autre qu'un Nexus qui n'était pas facilement traçable jusqu'à une étiquette CAF à CodeAurora), la qualité du code et la fréquence des mises à jour de Insignal (qui n'a pas de KitKat pour le "Arndale Octa" et rien de plus récent que ICS pour l'Exynos4.) En plus d'être obsolète, il n'y a absolument aucune traçabilité entre le fabricant OEM de Samsung Mobile. versions et la source de référence Exynos, tandis que tous les OEM ont une traçabilité assez décente jusqu'à CAF (HTC et Samsung un peu moins que d'autres, mais toujours bien mieux que tout Exynos)
Attendez, ils ont finalement sorti JB pour l'Origen Quad? Pas avant la sortie de KitKat... Et ce qu'ils appelaient JB était sans doute proche du désastre inutile qu'était leur Pain d'épices "ICS"
Exynos3, alias Hummingbird, était une histoire complètement différente grâce au Nexus S, mais Samsung s'est fait un devoir de ne jamais partager de chipset entre les appareils Nexus et aucun de ses autres appareils depuis lors. (Le Galaxy Nexus était OMAP4 alors que tout le reste de cette époque, à quelques exceptions près, était Exynos4, le Nexus 10 et le Chromebook Samsung étaient deux des seuls Appareils Exynos 5250 jamais livrés, Exynos 54xx est passé du GPU Mali à PowerVR avec tout un tas d'autres changements, donc manta était inutile pour I9500, etc.)"
Q: Quel est l’avenir du développement d’Exynos? Quelles mesures Samsung pourrait-il prendre pour se rendre plus convivial pour les développeurs ?
R: Codeworkx :
Il n'y a pas d'avenir. Tous les développeurs auxquels vous avez écrit ont cessé de fonctionner sur les appareils exynos depuis longtemps. La plupart d’entre eux ont même arrêté de travailler sur les appareils Samsung en général.
Nous avons demandé plus d'une fois le code source et rien ne s'est produit. Ils ne se soucient tout simplement pas de la communauté. Tout ce qui les intéresse c'est $$$
Force est de constater que la situation est quasiment identique à ce qu’elle était il y a plus de 3 ans. Les appareils Samsung, en particulier basés sur Exynos, restent de mauvais exemples de présentation du travail de la communauté de développement en dehors des exemples basés sur Touchwiz. Tout le développement de l'appareil reste largement limité aux modifications de Touchwiz, avec la scène de la personnalisation ROM tournant autour de l'ajout ou de la suppression de fonctionnalités du "skin" du système d'exploitation à source fermée de Samsung via l'inversion ingénierie.
Cela ne veut pas dire que les appareils Exynos ne bénéficient absolument d’aucune prise en charge pour les ROM AOSP. Les Roms AOSP, comme CM et autres, le font finalement atterrissent sur ces appareils, mais ceux-ci surviennent après de nombreux piratages de bas niveau et des efforts extrêmes de la part de responsables suffisamment courageux pour consacrer tout leur temps libre à réparer ce que Samsung a cassé. Même dans ce cas, le résultat final n’est pas une expérience AOSP à laquelle on s’attend normalement, et pour cela, vous pouvez en toute sécurité blâmer Samsung.
Les blessures de Superbrick sont encore fraîches sur ceux qui ont uni leur cœur et leur âme pour œuvrer en faveur d'une cause brisée qui s'appelle Samsung. Si vous cherchez à obtenir un appareil dont le premier critère est le développement de ROM personnalisé et la prise en charge de développeurs de ROM tiers, suivez les paroles de sagesse partagées par Codeworkx :
Arrêtez de soutenir ces entreprises en achetant leurs appareils.
Prenez un appareil Sony ou Nexus, obtenez des roms aosp de qualité, un bon support communautaire et soyez simplement heureux.