Samsung, Exynos e AOSP explicados: uma história de traição

Lembre-se, lembre-se, o primeiro da Nota, o lançamento e o enredo do ICS

Não conheço nenhuma razão pela qual a traição do Superbrick deva ser esquecida

Membros mais antigos do fórum e usuários de Android dos primeiros dispositivos Samsung podem se lembrar vagamente do Fiasco do supertijolo. Os eventos que levaram ao Superbrick são longos e complexos. Por uma questão de brevidade, um tl; A explicação dr é que uma atualização ICS vazada para algumas variantes de operadora do Galaxy S2 i9100 e do Galaxy Note N7000 causou um tijolo permanente. Este não era um tijolo duro comum, já que um dispositivo afetado não podia ser ressuscitado por meio de um JTAG e estava completamente morto e sem resposta. O superbrick afetou o eMMC do dispositivo e, portanto, os reparos só poderiam ser feitos com uma troca completa da placa-mãe.

A isenção de responsabilidade que geralmente acompanha os “vazamentos” também era válida neste caso, de que os vazamentos são essencialmente software “não lançado” que pode ou não ser adequado para consumo público. No entanto, para complicar as coisas, esse kernel ICS superbricking chegou ao Galaxy Note N7000 como um lançamento oficial disponível por meio de atualizações Kies e OTA.

O fiasco do Superbrick e o drama que se seguiu, cortesia da atitude da Samsung em relação aos desenvolvedores, foram destacados em uma série de 13 postagens de Andrew Dodd, também conhecido como XDA Senior Recognized Developer Entropia512 em seu Google+. Você pode encontrar o início desta série de postagens aqui. Nós altamente recomendado que os leitores tirem uma folga e leiam a série completa de postagens para adquirir uma consciência contextual completa e compreender toda a gravidade da situação que aconteceu em 2012-13.

Para destacar alguns pontos importantes, aqui estão alguns trechos (com ênfase adicional) das postagens:

"...Obviamente, quase todos que me seguem estão cientes da recente tempestade nas redes sociais resultante da frustração que comunidade de firmware Android de terceiros (especialmente usuários e desenvolvedores do CyanogenMod) tem experimentado Samsung. O fiasco "Superbrick", a falta de documentação do SoC Exynos4 da Samsung em comparação com os SoCs da Qualcomm e da TI e uma longa lista de outros problemas - tudo recentemente chegou ao auge com a decisão de todos os mantenedores de dispositivos Exynos4 atualmente ativos de não aceitar nenhum novo dispositivo..." - Postagem principal.

"...Em novembro, a Samsung lançou o XWKK5 para I9100 e UCKK6 para I777. O Bluetooth HID nessas compilações não funcionaria com nenhum kernel construído no código-fonte - apenas com binários associados a essas compilações. A Samsung nunca lançou outra atualização da fonte Gingerbread para o I9100, embora seus binários mostrassem evidências claras de uma mudança funcional na fonte. Da mesma forma, a fonte I777 UCKK6 não foi lançada até algum momento desconhecido em meados de 2012 - tenho quase certeza de que não antes do lançamento do I9100 ICS, na melhor das hipóteses. É isso mesmo - a Samsung estava violando a GPL com I777 UCKK6 e todos os I9100 Gingerbread construídos desde XWKK5 (novembro de 2011) até o lançamento oficial do I9100 ICS (março de 2012) - Na verdade, tecnicamente eles ainda são, já que a fonte do Gingerbread correspondente a esses kernels nunca foi lançada, mas isso realmente não importa mais..."

"...Na mesma época, a Samsung lançou o Tab 7.0 Plus e o Tab 7.7, ambos baseados no mesmo SoC Exynos 4210 encontrado no GS2...Esses dispositivos usavam um chip wifi da série Atheros AR6000. Curiosamente, a Atheros fornece fonte para esses dispositivos sob licença dupla, GPL e BSD. (Como a Atheros detém todos os direitos autorais de todos os componentes de seu driver de referência, isso é legal.) A Samsung escolheu a licença BSD para este driver. O resultado final é que, quando solicitada a fonte do driver wifi (que não estava presente nas gotas de origem desses dispositivos), A Samsung respondeu com “o código é de licença dupla GPL ou BSD. Escolhemos BSD [em vez de GPL]"..." - Postagem pai

"...Se houve alguma conclusão óbvia a ser tirada do ICS no GT-I9100, foi que skins de fabricantes não duram. Depois de obter o firmware I9100 ICS em execução no I777 (principalmente pela engenharia reversa dos canais de microfone trocados no este aparelho, que demorou quase um fim de semana de trabalho...), era óbvio que o Touchwizz reverteu muitos dos benefícios do ICS. Partes do firmware eram "novas", partes eram "gengibre legado" e as constantes descontinuidades eram chocantes... - Postagem pai

Pior ainda... ICS oficial lançado para o N7000 com XXLPY. Achamos que a Samsung nunca permitiria que um bug horrível como esse entrasse em um kernel lançado, mas estávamos errados...

- Postagem pai

"...Um contato na Samsung finalmente reconheceu que estava ciente da situação e "trabalhando diligentemente" nela... Eventualmente, a “solução” da Samsung foi-nos apresentada. Chainfire NÃO ficou feliz com a "solução" proposta, nem eu... Não envolvia nenhuma proteção em nível de kernel e era inferior ao que já tínhamos implementado com BOARD_SUPPRESS_EMMC_WIPE no CM. Além disso, eles nos pediram para não distribuir a solução e redirecionar os desenvolvedores do kernel em busca de uma solução para eles..."

"...A Samsung também se recusou a discutir quaisquer soluções envolvendo bootloaders... O raciocínio, que não fazia sentido, era que quase todas as reclamações de garantia devido a firmware personalizado antes desse defeito do eMMC eram devido à corrupção do bootloader... É claro que isso não faz sentido, já que queríamos discutir métodos de recuperação de corrupção do bootloader, o que eliminaria a maioria desses custos de garantia para Samsung. Estávamos até nos oferecendo para fazermos nós mesmos a maior parte da engenharia e implantação da solução, desde que a Samsung apenas nos desse alguns pequenos componentes específicos de que Dominik e Adam precisavam..."

"...Samsung, depois de “trabalhar diligentemente” durante um mês, joga uma granada na nossa cara

No início de julho, o XXLQ5 vazou para o I9100. Dentro de um dia, vários relatos de tijolos se acumularam. Não muito tempo depois, o XWLPM foi ao ar no Kies, e as pessoas também estavam quebrando a torto e a direito com esta construção.

Apesar de afirmar ser trabalhando diligentemente sobre este problema, em vez disso, a Samsung pegou um dispositivo anteriormente seguro e o colocou em perigo..." - Postagem pai

"...Então, neste momento - estamos em meados de novembro de 2012 e nem um único dispositivo afetado pelo eMMC defeituoso da Samsung recebeu uma correção de kernel. Embora os esforços da comunidade tenham reduzido as taxas de danos, desde que os kernels oficiais da Samsung sejam vulnerável, ainda receberei um PM a cada poucos dias de um usuário Superbricked que precisa de ajuda e não posso ajuda..." - Postagem pai

"...Em meados de agosto, decidi ir contra o bom senso e comprar um Note 10.1 (variante WiFi - GT-N8013). Achei que, como ele compartilhava um SoC com o I9300, seria uma aposta bastante segura...

Agora que eu confirmei, tanto pela não funcionalidade do driver wifi, quanto por várias comparações de strings com o backup kernel de estoque, que as fontes lançadas para qualquer variante do N80xx NÃO correspondiam aos kernels de estoque (todos eles tinham o mesmo wifi quebrado motorista e outras pessoas que trabalhavam com as fontes reclamaram de questões semelhantes.), levantei a questão com meu contato em Samsung...

Eles rastrearam alguém e a resposta dessa pessoa foi: a Samsung não tinha obrigação de fornecer uma fonte que correspondesse à versão UEALGB do GT-N8013, pois não era uma versão oficial. Sim, isso mesmo - alguém na verdade ousou afirmar que o firmware pré-instalado em cada unidade GT-N8013 vendida nos Estados Unidos era um VAZAMENTO. Esta foi a terceira vez que alguém da Samsung Mobile mentiu descaradamente na cara do meu contato..." - Postagem pai

"...Então, entre isso, outras coisas (veja os capítulos anteriores desta saga para muitos exemplos), e Superbrick, praticamente todos os mantenedores do Exynos4 estavam no limite da exaustão com a Samsung e especialmente com Exinos4.

Indiquei que o Note 10.1 seria meu último aparelho, e não tinha certeza de quanto tempo ficaria com o I777 e o N7000, pois também estava exausto neste momento.

Eu estava cansado de ficar meses atrás do resto da equipe do Cyanogenmod porque trabalhei com dispositivos que tinham mais blobs e mais quebras de interface nos blobs do que qualquer outro dispositivo

(Exceto dispositivos Tegra3, mas as pessoas já sabiam que deveriam evitá-los, a menos que estivessem em um Nexus.)..." - Postagem pai

"...Perto do final [do BABBQ 2012] ocorreu a apresentação de relações com desenvolvedores da Samsung. Foi aqui que eles prometeram melhorar a qualidade do código-fonte de referência e da documentação do Exynos4, em teoria aliviando as preocupações da comunidade. O conteúdo real da apresentação prometia pouco - quase tudo o que eles anunciaram eram coisas que já existiam tecnicamente, mas eram de pouca ou nenhuma utilidade por estarem desatualizadas ou simplesmente não funcionarem..." - Postagem pai

Tudo isso foi apenas mais um caso em que a Samsung fala e faz promessas e não cumpre, assim como vem falando e fazendo promessas há mais de um ano. As placas de desenvolvimento devem estar À FRENTE dos aparelhos - elas não precisam lidar com testes de operadora, certificações sem fio ou qualquer uma das coisas que geralmente são notórias por atrasar o uso do aparelho atualizações. Além disso, o alvo pretendido são os DESENVOLVEDORES, então eles devem ser a "vanguarda". Isso é o que é a fonte de referência da Qualcomm e da TI - é o que há de mais recente, à frente de qualquer coisa vista em aparelhos. O que recebemos da Samsung está desatualizado há mais de 6 meses – ICS para um SoC que estava em um aparelho lançado com ICS na primavera de 2012, e que recebeu uma atualização oficial do Jellybean (aprovações de operadora/certificados sem fio e tudo) no início de outubro 2012... Mas eles ainda estão trabalhando no ICS como fonte de referência???

- Postagem pai

A série foi concluída com uma postagem resumida que pode ser encontrada aqui. Recomendamos que todos os usuários leiam antes de prosseguir.

O ponto de partida deste artigo foi tentar explicar por que os dispositivos Exynos geralmente carecem de desenvolvimento baseado em AOSP quando comparados aos dispositivos Qualcomm. A série de postagens do G+ mencionada e citada acima destacou as dificuldades enfrentadas por um mantenedor de um dispositivo Exynos. A postagem está datada do período de 2011-2013, então entramos em contato com alguns dos desenvolvedores mencionados para descobrir como está a situação atualmente. Afinal, muita coisa pode mudar em 3 anos no mundo mobile.

Parece que não é para a Samsung e seu suporte ao AOSP.

P: Por que as ROMs AOSP demoram tanto para chegar aos dispositivos Exynos, em comparação com os dispositivos Qualcomm?

R: Desenvolvedor Sênior Reconhecido XDA códigoworkx:

A Qualcomm lança código-fonte sempre atualizado, necessário para que todos os componentes de sua plataforma funcionem no aosp. Ver aqui.

A Samsung não faz nada.

Desenvolvedor Sênior Reconhecido XDA Entropia512:

"Qualcomm CAF é muito superior em termos de rastreabilidade de/para versões OEM (nunca vi um dispositivo OEM diferente de um Nexus que não fosse facilmente rastreável até uma etiqueta CAF em CódigoAurora), qualidade do código e frequência de atualizações para Sinal (que não tem KitKat para o "Arndale Octa" e nada mais recente do que ICS para o Exynos4.) Além de estar desatualizado, há rastreabilidade absolutamente zero entre o OEM da Samsung Mobile lançamentos e a fonte de referência Exynos, enquanto todos os OEMs têm uma quantidade razoável de rastreabilidade até CAF (HTC e Samsung um pouco menos que outros, mas ainda muito melhor do que qualquer coisa Exinos)

Espere, eles finalmente lançaram JB para o Origen Quad? Não até que KitKat estivesse quase fora... E o que eles chamavam de JB provavelmente estava próximo do desastre inútil que era o seu Pão de gengibre "ICS"

Exynos3, também conhecido como Hummingbird, foi uma história completamente diferente graças ao Nexus S, mas a Samsung fez questão de nunca compartilhar um chipset entre dispositivos Nexus e qualquer um de seus outros dispositivos desde então. (O Galaxy Nexus era OMAP4, enquanto todo o resto daquela época, com algumas exceções, era o Exynos4, o Nexus 10 e o Samsung Chromebook eram dois dos únicos Dispositivos Exynos 5250 já lançados, o Exynos 54xx mudou da GPU do Mali para o PowerVR junto com um monte de outras mudanças, então o manta era inútil para o I9500, etc.)"

P: Qual é o futuro do Exynos Development? Que medidas a Samsung poderia tomar para se tornar mais amigável ao desenvolvedor?

R: Códigoworkx:

Não há futuro. Todos os desenvolvedores para os quais você escreveu pararam de trabalhar em dispositivos exynos há muito tempo. A maioria deles até parou de funcionar em aparelhos Samsung em geral.

Pedimos mais de uma vez o código-fonte e nada aconteceu. Eles simplesmente não se importam com a comunidade. Eles só se importam com $$$

É claro que a situação é quase idêntica à que era há mais de 3 anos. Os dispositivos Samsung, especificamente baseados em Exynos, continuam sendo maus exemplos de demonstração do trabalho da comunidade de desenvolvimento fora dos exemplos baseados em Touchwiz. Todo o desenvolvimento do dispositivo permanece em grande parte restrito a modificações no Touchwiz, com cenário de personalização ROMs que giram em torno da adição ou remoção de recursos da "skin" do sistema operacional de código fechado da Samsung por meio de reverso Engenharia.

Isso não quer dizer que os dispositivos Exynos não tenham absolutamente nenhum suporte para ROMs AOSP. Roms AOSP, como CM e similares, fazem eventualmente pousam nesses dispositivos, mas eles vêm depois de muitos hackers de baixo nível e esforços extremos de mantenedores corajosos o suficiente para dedicar todo o seu tempo livre consertando o que a Samsung quebrou. Mesmo assim, o resultado final não é uma experiência AOSP como você esperaria normalmente e, por isso, você pode culpar a Samsung com segurança.

As feridas do Superbrick ainda estão frescas naqueles que unem coração e alma para trabalhar por uma causa quebrada que se autodenomina Samsung. Se você deseja obter um dispositivo cujo primeiro critério seja o desenvolvimento de ROM personalizada e suporte a desenvolvedores de ROM de terceiros, siga as palavras de sabedoria compartilhadas por Codeworkx:

Pare de apoiar essas empresas comprando seus dispositivos.

Pegue um dispositivo Sony ou Nexus, obtenha ROMs Aosp de qualidade, bom suporte da comunidade e simplesmente seja feliz.