Como usar o SDK do Android e as ferramentas do fornecedor de smartphones para inicializar outro kernel?

Question

Fiz algum progresso pesquisando uma solução:

1) Limpei todos os dados do usuário dos dispositivos a serem usados para experimentos (inicialização no modo de recuperação > limpar cache/limpar dados/redefinição de fábrica)

2) Consultado em fontes não oficiais

Há uma série de artigos e postagens em fóruns na rede. Alguns deles são úteis. A maioria deles é bastante antiga e foi atualizada pela última vez há muito tempo. O ruim é que a maioria deles contém informações sobre como fazer root nos dispositivos (ou seja, quebrar a segurança do sistema operacional ao instalar deliberadamente um rootkit que explora uma vulnerabilidade conhecida para aumentar seus privilégios) e links para scripts não confiáveis/de baixa reputação contendo tais rootkits. Estas informações potencialmente prejudiciais são misturadas com partes úteis que dão uma visão geral das opções disponíveis.

Muitos artigos são publicados no site xda-developers.com, seufórumseção ewiki.

Alguns artigos wiki úteis:

Esses artigos wiki geralmente são mantidos de maneira bastante precária (as últimas edições foram em 2015).

3) Escolha a plataforma (x86, ASUS Zenfone2)

No meu caso, eu estava escolhendo entre meus próprios dispositivos Android usados. A maioria deles possui CPUs baseadas em ARM. O mais recente e poderoso foi o ASUS com CPU Intel x86 (conjunto de instruções de 64 bits). A outra razão para escolher o x86 foi o melhor suporte ao Linux e a necessidade de executar contêineres lxc baseados em x86/AMD64. A escolha do ARM exigiria o desenvolvimento de uma ramificação de contêiner separada ou a utilização de algum tipo de ferramenta de emulação/conversão (não tenho certeza se tais ferramentas são eficientes/bem mantidas/suportadas).

4) Percebi que a meta pode ser inalcançável com ferramentas oficiais (suportadas pelo fornecedor)

Enviei um e-mail ao suporte técnico da ASUS sobre o uso da ferramenta de desbloqueio do bootloader. Mas a resposta foi simples: “A ferramenta apenas desbloqueia o bootloader, não podemos ajudá-lo com outras etapas, nem podemos dizer o que acontece se você usar a ferramenta”. Ou seja, a ferramenta é inútil (nem sei se funcionou de alguma forma no meu caso e como é diferente do fastboot oem unlock). Para ativar a ferramenta, primeiro tive que fazer o downgrade para o Android 5.0, pois não era compatível com versões mais recentes da ROM. Todas as coisas relacionadas à alteração do bootloader e à inicialização de outras imagens não são oficiais, não são suportadas, não são recomendadas, quebram a garantia, etc.

5) [OPCIONAL: NOTA1] Escolha e instale a recuperação (não suportada oficialmente pelo telefone ou fornecedor do sistema operacional)

'Recuperação'- é um jargão Android para bootloader / BIOS (uma partição separada na memória do dispositivo que mantém um sistema leve baseado em Linux que inicializa primeiro e apresenta um menu do bootloader com ferramentas disponíveis como 'backup', 'wipe cache', 'factory reset', ' carregar ROM personalizada' etc.). A recuperação OEM original não permite atualizar ROM personalizada ou inicializar sistema operacional personalizado.

O projeto parece maduro, bem estruturado, mantido ativamente e geralmente dá a impressão de ser um valioso projeto global de código aberto. A quantidade de dispositivos e fornecedores suportados é muitonotável. É claro que eu preferiria usar a versão de recuperação mantida e endossada pelo fornecedor do telefone e baixada de seu site oficial (no meu caso, ASUS).

NOTA 1:Depois de instalar o TWRP e obter mais informações sobre as ferramentas do SDK, percebi que provavelmente era possível atualizar a ROM personalizada sem instalar uma recuperação personalizada (utilizando as ferramentas adb e fastboot do pacote de ferramentas da plataforma SDK).

NOTA 2:O processo de instalação está bem documentado para cada modelo. Eu usei o 'Método de instalação Fastboot'. Breve descrição do método (consulte a página no site TWRP relevante para o seu dispositivo): 1) Instale as ferramentas Android SDK (você precisará apenas dos componentes adb e fastboot do pacote platform-tools), 2) Ative o 'modo de desenvolvedor' em seu dispositivo tocando 7 vezes na linha 'Número da versão' em Configurações> menu Sobre, 3) Em Configurações> Opções do desenvolvedor habilite 'Depuração USB', 4) Conecte-se ao seu PC através de USB, 5) No seu PC você pode verificar se o dispositivo é conectado passando o comando adb devices, 6) Execute adb reboot bootloaderpara entrar no modo fastboot, 7) Coloque o arquivo de imagem correto baixado do site TWRP e renomeado como 'twrp.img' na pasta que contém os binários adb e fastboot (normalmente pasta 'ferramentas de plataforma' ), 8) Executar fastboot flash recovery twrp.img.No meu caso, a imagem foi atualizada com sucesso, embora o adb tenha relatado um erroFAILED (remote: Permission denied), 9) Executar fastboot reboot. Você também pode reiniciar seu dispositivo no menu TWRP. O importante é permitir que o TWRP corrija sua ROM de estoque (partição com sistema operacional Android) para evitar que ele limpe o TWRP e substitua-o pela recuperação de estoque após a inicialização. Caso contrário você terá que repetir o processo. Sim, isso foi assustador, daí a etapa 1.

6) Mergulhei na documentação oficial do AOSP

Depois de perder a esperança de usar uma abordagem de caixa preta para o sistema operacional Android para atingir a meta, comecei a revisar as seções gerais sobre a arquitetura do sistema operacional Android e os requisitos para dispositivos suportados.

Boas fotos (arquitetura):

Bootloader e informações de segurança:

Conclusão principal:O Android definitivamente introduziu recursos úteis do sistema operacional para executar o kernel Linux reduzido em uma ampla gama de dispositivos proprietários (mundo FMCG) com padrões de hardware flexíveis. Um dos recursos mais úteis que poderia e provavelmente deveria ser adotado pelo Linux convencional é a camada de abstração HAL, que permite lidar com o zoológico de drivers propiciatórios de uma maneira razoável. A coisa modular do kernel com a divisão do kernel em partes dependentes de SoC e dependentes de placa, recursos de economia de energia e recursos de segurança também são notáveis.

Boas notícias:Desenvolvedores de kernel Linux ealgunsos fornecedores de distro estão bem cientes de todas essas partes boas e estão fazendo o possível para introduzir as alterações correspondentes. Estatísticas oficiais (ver Figura 2 doseção de documento AOSP correspondente) mostram boas evidências de convergência entre o código AOSP e o Linux convencional. Há um efeito económico positivo definitivo da convergência para ambos os lados (comunidades AOSP e Linux). Quando se trata de partes interessadas como a Google e os produtores de hardware que protegem os seus investimentos, eles parecem ir na direção oposta. O Google protege seus investimentos no ecossistema e na base de usuários, os produtores de hardware estão protegendo seus investimentos no desenvolvimento e produção de hardware de última geração. O atrito entre essas duas forças cria uma espécie de vetor positivo. Na minha opinião, deveria haver algum tipo de acordo entre o Google e os produtores de hardware que regulasse esse atrito de maneira sensata. Por exemplo, os produtores de hardware podem atrasar o commit de seus blobs de driver específicos da placa no kernel do Linux por, digamos, 2 a 3 anos (para blobs de driver específicos do SoC, esse período talvez deva ser mais curto). Isso garantiria aos desenvolvedores do Google e AOSP que o ecossistema Android retirasse toda a nata do mercado (todas as novas compras modernas de dispositivos de hardware de última geração, receitas de anúncios, software pago e serviços de usuários de última geração). Após esses 2-3 anos, os dispositivos (não mais considerados de última geração) são lançados gratuitamente, enviando os blobs de driver para o Linux (fornecedores de hardware de alto nível, é claro, prefeririam submeter o código-fonte). A duração do período é bastante próxima do período de garantia normal definido para a maioria dos dispositivos pelos fornecedores de hardware e de um período de atualizações oficiais do Android (incluindo atualizações de segurança) distribuídas por esses fornecedores. Justo.

Más notícias:Parece ser muito difícil negociar tal acordo(doravante - o Acordo)de maneira sábia e explícita. O principal problema está na sua natureza global. Pense nas possíveis considerações legais (leis antitruste em várias jurisdições, questões fiscais transfronteiriças, etc. etc.), número de fornecedores de hardware (OEMs, ODMs, produtores de SoC, etc. etc.) e outras partes interessadas envolvidas (Google, AOSP, Android desenvolvedores, Linux, fornecedores de distribuição Linux - servidor, desktop e possivelmente móvel, outros projetos baseados em Linux, GNU, FSF, etc., etc., até os usuários finais). A falta de um acordo está definitivamente desacelerando a convergência entre Linux e AOSP, para pesar comum de nossos usuários. Do ponto de vista do hardware, a convergência total foi possível há vários anos, quando os dispositivos convencionais [CPU x86 multi-core / > 2 Gb de RAM / > unidade flash de 16 Gb] chegaram ao mercado. O problema é evidente quando este hardware não pode ser usado para executar um kernel Linux padrão (uma distribuição de servidor, nem mesmo desktop). Os instaladores estão ausentes, as ferramentas de flashing não são oficialmente suportadas pelos fornecedores, a documentação é escassa e dispersa. Em junho de 2019 as coisas poderiam ser muito melhores...

7) O próximo passo seria monitorar os esforços realizados pelas principais comunidades orientadas para a conversão e apoiar os fornecedores, bem como as etapas tomadas pelos fornecedores de hardware e AOSP/Google para negociar o acordo.

Answer 1