Capitulação detalhada de por que os dispositivos SD801 são excluídos do Nougat

Atualizado para refletir o requisito Vulkan ou OpenGL ES 3.1 para Android 7.0

Recentemente, muitos artigos foram escritos sobre atualizações de versão, as interações entre fornecedor e fabricante de chipset e o que isso significa para os dispositivos futuros. Por que isso aumentou esta semana?

Bem, descobriu-se esta semana que o venerável Nexus 5 não receberá a atualização para Android 7.0 (Nougat), e a Qualcomm anunciou que não será fornecendo suporte para o MSM8974 (mais comumente conhecido como Snapdragon 801) no 7.0. Este artigo foi escrito em colaboração com o XDA Recognized Desenvolvedor abelha.

O assunto atraiu bastante interesse de vários sites de notícias, mas muitos perdem as nuances sutis do que realmente está acontecendo nos bastidoresS. Este artigo explicará um pouco mais sobre como funcionam as atualizações de software, usando nossa experiência em trabalhar com OEMs em suas atualizações de firmware oficiais. Orientaremos você sobre o que acontece nos bastidores (e por quê) e por que você pode não obter o software mais recente em seu telefone.

A primeira etapa na vida de uma atualização de firmware Android é a atualização upstream. É nisso que o Google trabalha internamente. Em contraste com os “fluxos de trabalho abertos”, o Android é desenvolvido usando um fluxo de trabalho fechado, com código-fonte jogado por cima do muro a cada ano ou mais, quando uma nova versão é lançada. Originalmente, o Google disse que isso era para evitar a fragmentação de pessoas que executavam versões de última geração enquanto as coisas evoluíam rapidamente nos primeiros dias, mas eles parecem ter mantido esta política em lugar.

Em algum momento, geralmente antes do anúncio público de uma atualização (embora com a recente introdução de betas públicos, esses prazos estejam mudando), OEMs serão informados sobre uma atualização futura. Eles então receberão o código-fonte em um segundo momento para a atualização final (no passado, era às vezes um pouco antes do lançamento, embora também estejamos cientes de casos em que não há liberar).

Os repositórios AOSP upstream contêm suporte para dispositivos apenas para um número limitado de dispositivos. Normalmente, esses são seus dispositivos Nexus. No entanto, por razões que ficarão claras em breve, é importante notar que o Google não tem controle completo de hardware sobre esses dispositivos; os dispositivos são fabricados por um OEM, e esse OEM comprará um System-on-Chip (SoC) de um fabricante de chipset.

Assim que o código-fonte for lançado, a equipe de firmware do OEM irá (figurativamente) sentar e levantar os pés. A principal árvore de origem do Android não tem suporte de hardware para a infinidade de chipsets usados ​​em dispositivos de envio. Seu chipset Qualcomm provavelmente não é compatível com AOSP, por exemplo. Seu Exynos definitivamente não é. Mediatek ou HiSilicon? Esqueça!

O BSP contém os drivers e as camadas de abstração de hardware (HALs) necessários para colocar o Android em execução

O que é necessário agora é um Pacote de Apoio ao Conselho (BSP). Este é um pacote superconfidencial de componentes proprietários, entregue por um fabricante de chipset a um OEM. O BSP contém o código-fonte necessário para permitir que os OEMs criem o Android e os drivers necessários para seus dispositivos.

Vale a pena notar aqui que OEMs como a Qualcomm não confiam necessariamente totalmente em seus parceiros OEM – o BSP é disponibilizado com base na “necessidade de saber”. Os OEMs geralmente não têm acesso ao código-fonte de algumas das partes supersecretas do dispositivo (como o software executado na banda base). Ter esta parte fechada certamente também traz problemas potenciais, como mostra o quase abundante e recorrente ASN.1 analisando vulnerabilidades.

O BSP contém os drivers e as camadas de abstração de hardware (HALs) necessários para que o Android seja executado no seu dispositivo. AOSP contém um conjunto de HALs, que atuam como definições sobre o que o sistema operacional espera que seus drivers implementem. Para usar um exemplo ridiculamente simplificado (e inventado, para fins de demonstração), vamos imaginar a lanterna do seu telefone.

Um exemplo HAL - sua lanterna

Vamos imaginar que seu dispositivo tenha uma lanterna na parte traseira (se você tiver um Nexus 7 2013, precisará imaginar um pouco mais do que todo mundo – desculpe!). Isso é controlado por um motorista. Para nosso exemplo incrivelmente simples, vamos supor que o HAL v1 diga que você deveria ter uma função chamada “setLED” tomando um único parâmetro, o estado da luz. É um booleano – verdadeiro ou falso. Em C, isso ficaria mais ou menos assim:

void setLED(bool ledState) {

// here is the actual code to turn on or off the LED, based on ledState

}

Esta função é definida no código-fonte do BSP. O BSP é então compilado pelo OEM durante a construção da ROM, e esta se torna uma das bibliotecas proprietárias ".so" na partição ou área do fornecedor do seu dispositivo. Isso permite que um OEM mantenha em segredo certas partes do funcionamento de seu dispositivo. Por enquanto, vamos supor que eles queiram impedir que todos vejam como ligam e desligam o LED.

Agora imagine que o Google lance uma versão atualizada de seus HALs em uma versão futura do Android. Eles agora decidem que seria bom permitir que você atualizasse o brilho do seu LED, em vez de apenas ligá-lo ou desligá-lo. Talvez seja para flash adaptativo ou talvez seja apenas para forçar uma atualização do HAL e manter os fabricantes de chipset no mercado? Deixaremos que você, leitor, chegue à sua própria opinião sobre isso. Algumas atualizações do HAL têm benefícios claros (como o novo Camera HAL que expõe imagens brutas e similares), enquanto outras têm um propósito um pouco menos claro.

Com este novo HAL (fictício) para brilho, vamos supor que o Google diga que você precisa expor novamente uma função chamada setLED, mas desta vez com um número inteiro passado para brilho. Agora, 0 desligaria e 255 colocaria no máximo.

Se você for o OEM, poderá pegar seu código supersecreto para ligar aquele LED e colocá-lo nesta nova função. Você pode até usar modulação por largura de pulso para ajustar o brilho do LED com base no número. Você altera a função para aparecer assim agora:

void setLED(uint8_t ledBrightness) {

// some super-secret and ultra-confidential proprietary way to set LED brightness

}

E daí? Bem, agora esta nova versão do Android é incompatível com os “blobs” existentes. Seu OEM precisa usar esses novos blobs, porque o sistema operacional Android espera ver a nova definição de função e não "encontrará" a antiga quando procurar uma maneira de definir o LED.

Neste ponto, vamos fazer um breve intervalo para ver como as ROMs personalizadas (construídas a partir do código-fonte) são gerenciadas aqui. É o que os astutos entre vocês estarão gritando na sua tela agora - afinal, somos o XDA, a casa do HTC HD2, o telefone mais duradouro do mundo... (só para constar, os gênios malucos ali estão correndo Android 6.0 no HD2 atualmente! Nada mal para um telefone originalmente fornecido com Windows Mobile 6.5 em 2009)

Existem várias abordagens aqui - às vezes os desenvolvedores invadem a ROM e dizem ao sistema operacional para usar as antigas definições de função. Isso é um pouco confuso e exige muitas alterações para manter. A outra abordagem é "calçar" o binário OEM.

A abordagem "shim" é escrever e construir você mesmo uma pequena biblioteca nova, que contém a definição de função esperada - para nosso exemplo, suportaríamos o número inteiro para brilho. Então, dentro do calço, isso é traduzido para atender aos requisitos do antigo HAL. Então, para o nosso exemplo, talvez diríamos que qualquer brilho solicitado acima de 128 acenderá o LED, e qualquer brilho abaixo disso o desligará. Ou você poderia dizer que qualquer coisa diferente de zero irá ativá-lo. Depende do desenvolvedor. Eles compilam o shim e fazem com que o Android o use em vez do nativo. O calço então chama o blob OEM.

Um rápido `adb push` e uma reinicialização devem fazer o calço funcionar e permitir que você controle seu LED fictício, mesmo que você tenha apenas o antigo HAL.

O problema é que este é claramente um processo imperfeito. Agora você terá peculiaridades - este dispositivo terá um flash bastante ruim, que está totalmente ligado ou desligado. Isso não é o ideal - o sistema operacional pensa que está produzindo uma luz muito suave, mas o LED real está sendo informado de que está competindo em um concurso de sol artificial e está tentando cegá-lo. Mas ei, a vida não é perfeita e agora você tem um LED funcionando no seu telefone antigo!

(Sim, esta é uma das razões pelas quais existem peculiaridades e bugs quando os usuários e desenvolvedores do XDA gerenciam suas façanhas malucas e insanas de habilidade de portabilidade. Quero dizer, caramba, o Galáxia S II está carregando um aparentemente utilizável ROM do Android 6.0 agora. Muitos telefones lançados no ano passado ainda não têm 6.0!)

Voltemos à perspectiva do OEM. Infelizmente, a maioria dos OEMs já está trabalhando pelo menos 1 telefone à frente de onde estamos agora. O foco deles está no próximo telefone que estão prestes a vender - você não pode culpá-los, pois eles só ganham dinheiro com os dispositivos que vendem. Eles não ganham nenhum dinheiro com dispositivos que venderam há um ou dois anos, então precisam continuar lançando novos dispositivos para existirem. Esta é uma das razões pelas quais a HTC e o Blackberry estão em apuros - não importa quantos executivos estão mantendo o controle sobre seu antigo Blackberry Curve, já que não estão conseguindo a venda de um novo dispositivo lá.

Se o OEM não obtiver um BSP, ele não seguirá a abordagem XDA de hackear uma compilação. Por que? Bem, eles precisam oferecer suporte a este firmware para seus clientes. Se eles lançarem um firmware que funcione pela metade, os usuários irão odiá-los, reclamar e delirar, e manterão suas linhas de suporte funcionando por dias.

Os OEMs também precisam enfrentar as operadoras, pelo menos em mercados não europeus. As operadoras não querem que os clientes tenham problemas com atualizações de software. Na verdade, as operadoras muitas vezes preferem não lançar atualizações de software.

Para entender isso, imagine sua tia-avó Alice. É ela quem liga para você em horários inconvenientes do dia para pedir ajuda com “aquela coisa do computador”. Você então descreve como clicar no "menu Iniciar" e tem que identificá-lo como a "grande bandeira no canto inferior esquerdo" e fica confuso. Cerca de 45 minutos (e muita frustração) depois, descobre-se que tia Alice arrastou o menu Iniciar para a borda direita da tela e simplesmente precisou arrastá-lo de volta. Sim, com o botão esquerdo do mouse!

Agora imagine que você tem mil tias Alice. Todos estão ligando para o suporte ao cliente, sem conseguir encontrar o Candy Crush em seus telefones, preocupados que um hacker o tenha excluído de seus telefones. Ah, e os ícones parecem um pouco diferentes agora – talvez o hacker ainda esteja no telefone?

Sim, isso pretende ser um pouco de humor alegre, mas até que você experimente os motivos pelos quais as pessoas ligam para sua operadora em busca de suporte, você não acreditará nos problemas que elas têm. Uma atualização de software que altera o funcionamento do telefone ou a localização das coisas causará uma sobrecarga significativa de suporte. No mínimo, requer um novo treinamento da equipe de suporte (porque a maioria deles não é um leitor ávido do XDA, infelizmente).

Assim que o OEM obtiver o BSP, ele portará sua ROM e aplicará todas as alterações à ROM. Eles empilharão seus bloatware e adicionarão uma skin horrível de desenho animado que ficaria mais à vontade em um anime adolescente. Então eles vão testar.

Bastante.

Existem todos os tipos de requisitos que seu telefone deve cumprir. As redes móveis são projetadas para confiar no equipamento do usuário (o que chamamos de telefone) para se comportar corretamente. Isso significa que são necessários muitos testes para que o dispositivo seja aprovado. As atualizações de software correm o risco de alterar comportamentos, por isso as coisas precisam ser testadas novamente. É por isso que você normalmente verá informações sobre as próximas atualizações de software da Sony em serviços de teste externos, que confirmam que o firmware é compatível com os requisitos de teste.

Agora... o que acontece depois de uma ou duas atualizações (ou em alguns casos, nenhuma)? O fabricante do SoC não fornecerá ao OEM um BSP atualizado. Afinal, o fabricante do SoC não ganhará muito com isso. O OEM não está ganhando mais dinheiro com o seu telefone desde que ele foi vendido. E neste ponto, seu telefone não recebe mais atualizações importantes de versão.

Reduzir o número de BSPs que o OEM deseja entregar é uma ótima maneira de economizar dinheiro - se você só precisa do atual e não pretende entregar nenhuma versão principal aumenta, isso economizará dinheiro na compra e licenciamento inicial do SoC, mas às custas de alguns nerds irritados no XDA no futuro, se perguntando por que eles não conseguiram um atualizar.

As atualizações são complexas. Há muitas pessoas diferentes envolvidas na cadeia. Nada disso isenta os OEMs do atual estado indiferente e patético das atualizações no Android. No entanto, existem alguns desafios reais aqui.

Muitos OEMs são culpados por serem excessivamente promissores, e o subentrega inevitável que agora associamos. A triste realidade é que, para a maioria dos OEMs, as atualizações de software são apenas um aborrecimento que eles poderiam dispensar.

O setor móvel está principalmente preso à mentalidade dos feature phones. Ou seja, onde um dispositivo nunca recebe atualizações. Teste uma vez, envie-o e nunca mais olhe para trás. Com os problemas de segurança dos smartphones modernos e a enorme complexidade de executar um sistema operacional completo de uso geral, com centenas de bibliotecas externas, isso não é mais uma opção. Ou pelo menos isso não deveria ser. O Google tomou algumas medidas para corrigir isso, publicando pelo menos boletins de segurança e patches para versões existentes do Android (lembre-se de que, até muito recentemente, a única maneira de obter atualizações de segurança era por meio de uma nova versão principal do sistema operacional Android!)

Infelizmente, porém, isso não é suficiente. Embora o Google continue lançando atualizações, a segurança do seu dispositivo ainda depende do fabricante do SoC - já que os fabricantes de SoC estão tão petrificados com alguém descobrindo como acender alguns LEDs ou emitir um som através de um alto-falante, envia enormes quantidades de bolhas binárias em seus dispositivos. Esses blobs contêm códigos terrivelmente inseguros (basta dar uma olhada nos boletins de segurança anteriores do Google se você acha que isso é um exagero!) E precisam ser atualizados. O que significa que são necessários BSPs atualizados.

Os computadores desktop (e, por extensão, os laptops) são completamente diferentes em arquitetura dos dispositivos móveis. Seu celular ou tablet é na verdade um pedaço de silício altamente proprietário, projetado às pressas por algumas pessoas que têm boas intenções, mas não têm tempo suficiente para fazer algo bom. O mercado se move tão rapidamente que eles mal conseguem acompanhar o ritmo em que o marketing exige o lançamento de novos produtos.

Isso significa que atalhos são usados ​​- você não encontrará seu telefone compatível com o kernel Linux principal e descobrirá que cada telefone tem uma maneira diferente de inicializar. No seu laptop ou desktop, no entanto, os fornecedores optaram por algumas formas padrão de inicialização - anteriormente era MBR (registro mestre de inicialização) com BIOS, e agora é UEFI. Essa padronização possibilita rodar o mesmo software em cada dispositivo.

Embora tenham sido dados alguns passos nesse sentido recentemente, especialmente com o programa de divulgação da Sony e a sua kernel unificado, não é prático executar um kernel principal na maioria dos telefones, devido ao grande número de novos hacks específicos de fornecedores introduzidos em cada dispositivo.

Conectou o fone de ouvido ao contrário? Basta hackear nos drivers! Não há tempo para consertar isso no design de produção.

A equipe de fabricação montou o módulo da câmera de cabeça para baixo no lote de produção 1? Faça um hack para verificar o código da versão interna e vire o vídeo se for a versão 1!

Hacks como esses resolvem o problema imediato, mas apenas raspam a superfície das mudanças estranhas e específicas do produto que estão acontecendo. Caramba, às vezes há chips totalmente diferentes em diferentes revisões do mesmo telefone, devido a decisões comerciais. Isso levou a hacks nos motoristas e decisões estranhas que só faziam sentido na época, para fazer o telefone funcionar para que pudesse ser enviado na próxima semana.

Embora haja trabalho em andamento para suporte principal para chips ARM de 64 bits para inicialização usando UEFI, até agora houve nenhum movimento claro em direção a uma forma mais padronizada de inicializar dispositivos ARM. E isso é triste, porque significa que os telefones continuarão a ser jogados fora muito antes do fim de sua vida útil. vidas profissionais, porque é simplesmente muito caro manter a dívida técnica e a carga sobre seus Programas.

Por outro lado, se um OEM só ganhar dinheiro com a venda de um dispositivo, ele não precisa garantir que as pessoas continuem a comprar novos telefones? O mercado de PCs mudaria para esse modelo se não houvesse 30 anos de impulso e software legado já disponível usando a plataforma e o padrão de PC aberto?

Esta é uma pergunta difícil sem o conhecimento interno da Qualcomm, que infelizmente não temos no momento. No entanto, podemos extrair algumas informações da API do driver Android 7.0 e dos requisitos do CTS. Os requisitos CTS especificam o que o Google espera de um dispositivo executando um determinado firmware. O "grande martelo" usado para fazer cumprir esses requisitos é o licenciamento do Google para usar seu pacote proprietário do Google Play Services - se você não obedecer, não poderá enviar o Google Apps no dispositivo. Embora, para alguns, isso pode ser visto como uma vantagem, obviamente não é isso que os usuários desejam e esperam de um dispositivo.

O Android 7.0 não adicionou muitas alterações no HAL ou nos drivers (conforme descrito acima), portanto, é improvável que qualquer incompatibilidade venha daí especificamente. O que é mais provável que coloque um problema, no entanto, é a introdução de um novo requisito para a API gráfica Vulkan ou GLES 3.1, estar disponível para passar no CTS.

Atualmente, muitos Systems-on-Chip (SoCs) não têm suporte Vulkan em seus processadores gráficos, incluindo o MSM8974. É também aqui que provavelmente surgirá o problema de compatibilidade com o Android 7.0. Porém, mais uma vez, sem o conhecimento interno da Qualcomm e de seus planos futuros, é difícil para nós dar uma declaração definitiva sem qualificá-la. No momento, porém, acreditamos que é provável que este seja o caso "simples" de a Qualcomm descontinuar o suporte para o (aos seus olhos) chipset MSM8974 antigo e não fornece um BSP (pacote de suporte de placa) para 7.0 nessa plataforma. Se fosse esse o caso, isso significaria que os OEMs teriam quase certeza de não enviar o 7.0 no dispositivo - eles teriam que de alguma forma encontrar suporte Vulkan ou GLEs 3.1 para sua GPU e fonte de GPU o código é uma das partes ridiculamente bem protegidas das pilhas móveis (sem motivo real, acrescentaríamos - veja a AMD, abrindo o código-fonte de seu próprio driver AMDGPU no desktop para Linux). Infelizmente, porém, os gráficos Vulkan e acelerados (GLES) em geral são um pouco mais complexos do que um simples LED, então não veremos correções para introduzir compatibilidade.

Como o 7.0 não foi lançado há muito tempo, existe uma possibilidade real de outros chipsets (além do pequeno número dentro do próprio AOSP) serem deixados atrasado no 6.0, devido a problemas de hardware e driver (ou seja, nenhum BSP atualizado) ou falta de suporte do fornecedor de SoC em relação ao Vulkan ou GLES 3.1 API. Atualmente, nem o Snapdragon 800 nem o 801 suportam um destes.

A melhor aposta é vigiar este espaço - os desenvolvedores do XDA já estão fazendo um bom progresso com portas não oficiais para 7.0 para muitos dos dispositivos que não recebem suporte oficial para 7.0 do Google. No entanto, eles não têm suporte para Vulkan ou GLES 3.1 - talvez os desenvolvedores de jogos no Android comecem a experimente a frustração devido à fragmentação se um número suficiente de usuários começar a executar ROMs personalizados sem Vulkan ou GLES 3.1 apoiar?

A Apple tende a oferecer suporte à sua linha de iPhone na versão mais recente do iOS há cerca de 5 anos - o iPhone 4s foi lançado em outubro de 2011 e foi mantido atualizado até o iOS 9. No entanto, ele não receberá a próxima atualização do iOS 10, o que daria ao telefone uma vida útil efetiva de 5 anos, assumindo que o iOS 10 seja lançado por volta de outubro. É importante notar que a Apple nem sempre oferece suporte à API gráfica - o iPhone 4s e o iPhone 5 não apresentam a API gráfica Metal da Apple, que é um cenário semelhante ao visto no Android em Vulcano. A única diferença é que a Apple continuou a oferecer suporte a dispositivos mais antigos sem a nova API gráfica.

O que você acha? Você atualizará uma ROM personalizada em seu telefone para prolongar sua vida útil? Você disse nos comentários abaixo.