Processo de lançamento de imagem genérica do kernel (GKI)

Este documento descreve como o GKI é lançado, incluindo lançamentos de emergência semanais, mensais e fora de banda. O objetivo deste documento é fornecer aos OEMs uma orientação sobre onde obter o GKI, bem como o processo para correções de emergência fora de banda. Os OEMs também podem usar o guia de desenvolvimento do GKI para saber mais sobre como podem trabalhar com a equipe do Kernel do Android para otimizar o kernel do GKI para seus produtos.

Cadência de lançamento do GKI

O GKI é lançado em uma cadência mensal após o congelamento do KMI.

Lançamento do GKI do Android 13 e 14

A tabela a seguir é aplicável apenas a android13-5.10 , android13-5.15 e android14-6.1 .

Construções certificadas mensalmente da GKI	Data limite do check-in	Data de preparação do pré-carregamento do GKI	Confirmado?
Outubro	14 de outubro de 2022	31 de outubro de 2022	Sim
novembro	14 de novembro de 2022	30 de novembro de 2022	Sim
dezembro	9 de dezembro de 2022	21 de dezembro de 2022	Sim
Janeiro	17 de janeiro de 2023	31 de janeiro de 2023	Sim
Fevereiro	15 de fevereiro de 2023	28 de fevereiro de 2023	Sim
Marchar	15 de março de 2023	31 de março de 2023	Sim
abril	13 de abril de 2023	28 de abril de 2023	Sim
Poderia	17 de maio de 2023	31 de maio de 2023	Sim
Junho	15 de junho de 2023	30 de junho de 2023	Sim
Julho	18 de julho de 2023	31 de julho de 2023	Sim
Agosto	16 de agosto de 2023	31 de agosto de 2023	Sim
Setembro	14 de setembro de 2023	29 de setembro de 2023	Sim
Outubro	18 de outubro de 2023	31 de outubro de 2023	Sim
novembro	10 de novembro de 2023	30 de novembro de 2023	Sim
dezembro	7 de dezembro de 2023	22 de dezembro de 2023	Sim

Lançamento do Android 12 GKI

Depois de maio de 2023, os lançamentos android12-5.10 GKI ocorrerão em uma cadência de 2 meses e serão publicados no meio do mês. A tabela a seguir é aplicável apenas a android12-5.10 .

Construções certificadas mensalmente da GKI	Data limite do check-in	Data de preparação do pré-carregamento do GKI	Confirmado?
Julho	3 de julho de 2023	14 de julho de 2023	Sim
Setembro	1º de setembro de 2023	15 de setembro de 2023	Sim
novembro	3 de novembro de 2023	17 de novembro de 2023	Sim
Janeiro	5 de janeiro de 2024	19 de janeiro de 2024	Sim

Validade de compilação do GKI para OEMs

Os OEMs podem usar um Android GKI lançado recentemente. Os OEMs podem lançar compilações certificadas pela GKI, desde que estejam em conformidade com os requisitos LTS do Android Security Bulletin (ASB).

Lançamentos semanais de desenvolvimento

As liberações são testadas com chocos para garantir que passem por um padrão mínimo de qualidade .

Os binários GKI estão disponíveis para autoatendimento em ci.android.com à medida que as alterações são mescladas. As compilações semanais não serão certificadas, mas podem ser usadas como base para desenvolvimento e testes. As compilações semanais não podem ser usadas para compilações de dispositivos de produção para usuários finais.

Lançamentos certificados mensais

As versões mensais do GKI contêm um boot.img testado que inclui um certificado inserido pelo Google para atestar que os binários foram criados a partir de uma linha de base de código-fonte conhecida.

A cada mês, um release candidate mensal do GKI (não certificado) é selecionado após a data limite de check-in, que geralmente é a segunda compilação semanal daquele mês. Depois que o release candidate mensal for selecionado, novas alterações não serão aceitas no lançamento daquele mês. Durante o período de janela fechada, apenas correções de bugs que causam falha no teste podem ser corrigidas. O release candidate passa por garantia de qualidade — conforme descrito na seção de qualificação GKI — para garantir que os testes de conformidade sejam aprovados na construção GSI+GKI com um dispositivo de referência e também com choco.

Figura 1. Cronograma de lançamento do GKI

Processo de respin de emergência

Um respin refere-se ao processo de reintegração, reconstrução, novo teste e recertificação de um binário após um lançamento público do kernel GKI . Você pode solicitar uma nova rotação de um binário certificado em qualquer uma das seguintes circunstâncias:

• Para atualizar uma lista de símbolos.
• Para aplicar uma correção a um bug, incluindo bugs encontrados durante a aprovação do laboratório da operadora.
• Para adicionar um gancho de fornecedor .
• Para aplicar um patch a um recurso existente.
• Para aplicar um patch de segurança (após 6 meses).

Os patches de segurança são automaticamente mesclados em uma ramificação de lançamento por até 6 meses após o lançamento da ramificação. Após o prazo de 6 meses, você deve solicitar uma nova rodada para aplicar patches de segurança a uma filial.

Antes de solicitar uma nova rodada, observe as seguintes diretrizes:

• Respins são permitidos apenas em ramificações de lançamento após o lançamento público inicial de uma compilação mensal .

• Solicitações de respin são aceitas apenas para um determinado branch de lançamento por no máximo seis meses após o lançamento público inicial. Após seis meses, as filiais são elegíveis para respin apenas para patches de segurança citados em um Boletim de Segurança do Android .

• Quando os requisitos LTS , definidos pelo Android Security Bulletin (ASB), fazem com que o branch não esteja em conformidade, o branch é obsoleto. Solicitações de respin para ramificações obsoletas não são aceitas. A data de descontinuação de um determinado branch de lançamento do GKI está incluída nas notas mensais de compilação do lançamento do GKI em Releases . Para planejamento futuro, os requisitos do LTS são atualizados anualmente em maio e novembro. Por exemplo, a ramificação android12-5.10-2023-07 (5.10.177) não é compatível com respins após 1º de maio de 2024, porque a ramificação android12-5.10-2023-07 (5.10.177) não está em conformidade com o Requisitos LTS da ASB-2024-05.

• Os respins são aplicáveis ​​apenas para correções urgentes de bugs, atualizações da lista de símbolos ou para aplicar um patch para corrigir um recurso existente.

• Todos os patches que vão para o branch de lançamento mensal já devem estar mesclados no branch de desenvolvimento principal do GKI. Por exemplo, se um patch for necessário para uma nova rotação de android12-5.10-2022-09 , ele já deverá estar mesclado em android12-5.10 .

• Você deve escolher os patches do branch de desenvolvimento principal do GKI e fazer upload do patch para o branch de lançamento mensal.

• Na solicitação de respin, você deve atribuir uma prioridade (urgência) à solicitação. Esta prioridade ajuda a equipe da GKI a ajudar melhor os parceiros em tempo hábil. Para solicitações críticas ou urgentes, marque a prioridade como P0 . Para solicitações P0 e P1, você também deverá justificar a urgência. A tabela a seguir fornece um mapeamento da prioridade do bug e do tempo de resolução (ESRT):

  Prioridade	ESRT
  P0	2 dias úteis
  P1	5 dias úteis
  P2	10 dias úteis
  P3	15 dias úteis

• Você deve enviar uma solicitação de respin separada por branch de lançamento. Por exemplo, se um respin for necessário para android12-5.10-2022-08 e android12-5.10-2022-09 , você deverá criar duas solicitações de respin.

• Depois que uma compilação for fornecida e uma solicitação de respin for marcada como corrigida, você não deverá reabrir a solicitação de respin para adicionar CLs adicionais. Você deve enviar uma nova solicitação de respin se houver patches adicionais que precisem ser mesclados.

• Para cada CL em consideração, adicione as tags a seguir. O progresso na solicitação de respin é bloqueado sem esta informação.

  • Bug : o ID do bug deve ser adicionado à mensagem de commit para cada CL.
  • Change-Id : deve ser idêntico ao Change-Id da alteração do branch base.

• Se uma solicitação de respin exigir sua resposta e você não responder dentro de três dias úteis, a prioridade será rebaixada em um nível (por exemplo, P0 será rebaixado para P1 ). Se você não responder por duas semanas, o bug será marcado como Não será corrigido (obsoleto) .

Envie uma solicitação de respin

O diagrama a seguir mostra o processo de respin. O processo começa quando o Parceiro OEM (você) envia a solicitação de respin.

Figura 2. O processo de respin

Para entrar no processo de respin:

1. Preencha o formulário de solicitação GKI Respin . e entre em contato com seu gerente técnico de conta do Google imediatamente. Este formulário cria um bug de solicitação de respin GKI. Os bugs de solicitação de respin são visíveis para você (o solicitante), para a equipe do GKI e para indivíduos específicos que você adiciona à lista de CC do bug.
   • Se você já tiver uma correção, a solicitação deverá apontar para o envio do patch no AOSP para que o Google possa revisá-la. Se o envio do patch não for viável, o patch deverá ser anexado como um arquivo de texto à solicitação.
   • Se você não tiver uma correção, a solicitação deverá conter o máximo de informações possível, incluindo o número da versão do kernel e os registros, para que o Google possa ajudar a depurar o problema.
2. A equipe do Google GKI analisa a solicitação e a aprova ou a atribui de volta a você se mais informações forem necessárias.
3. Depois que uma correção é acordada, o código da equipe do Google GKI analisa (CR+2) a alteração. A revisão inicia o prazo ESRT. A equipe do GKI mescla, cria, testa a regressão e certifica a mudança.
4. O binário é lançado em ci.android.com . O prazo ESRT termina e a equipe do Google GKI marca a solicitação como corrigida e faz referência à compilação respin. A compilação respin também pode ser publicada na página de versões de versão da imagem genérica do kernel (GKI) .

Qualificações GKI

Tipos de compilações GKI	Aplicação da qualidade	Notas
Semanalmente	Teste de choco Bota Subconjunto de VTS Subconjunto de CTS	Não certificado. Somente para testes e dispositivo seja exibido. Não pode ser usado para iniciar dispositivos.
Mensalmente (certificado)	Teste de choco Bota VTS CTS Teste de hardware de referência Bota VTS CTS
Respins (certificados)	Teste de choco Bota VTS Subconjunto de CTS Teste de dispositivo de referência Bota VTS	Construído com base em uma versão certificada pela GKI. A construção é certificada após qualificação.

Onde obter artefatos de construção

Artefatos para todos os lançamentos podem ser obtidos em ci.android.com .

Você pode encontrar mais informações sobre o CI, incluindo os resultados do teste no painel de integração contínua do Android .

Perguntas frequentes

É possível construir um novo binário GKI baseado em um GKI já lançado?

Sim, isso é conhecido como respin. O processo de respin é suportado desde que a versão GKI lançada (na qual o respin é solicitado) esteja em conformidade com os requisitos LTS do Android Security Bulletin (ASB).

É possível reproduzir binários GKI?

Sim, consulte o exemplo abaixo.

GKI 2.0
5.10 kernel prebuilts from build 7364300
https://ci.android.com/builds/submitted/7364300/kernel_aarch64/latest

Para reproduzir o exemplo, baixe manifest_$id.xml e execute o seguinte comando:

repo init -u https://android.googlesource.com/kernel/manifest
mv manifest_7364300.xml .repo/manifests
repo init -m manifest_7364300.xml --depth=1
repo sync
# build the GKI images
# You may want to use LTO=thin to build faster for development
BUILD_CONFIG=common/build.config.gki.aarch64 build/build.sh
# (optional) build virtual platform modules
BUILD_CONFIG=common-modules/virtual-device/build.config.virtual_device.aarch64 build/build.sh

Você pode recuperar sua cópia do artefato GKI em out/.../dist .

O binário GKI (incluindo o patch de rotação de emergência) foi criado na base de código mais recente?

Os Respins contêm apenas patches que estão além dos kernels certificados mensalmente que foram escolhidos. Esses respins contêm todas as correções de bugs de bloqueio de inicialização relatadas até um determinado momento pelos OEMs usando a versão mensal base correspondente. Veja no exemplo a seguir como acontece esse tipo de cenário.

• OEM1 e OEM2 decidem usar a versão binária GKI a partir de novembro de 2021.
• OEM1 e OEM2 encontram problemas que exigem patches para suporte. Esses patches podem ser diferentes ou iguais.
• Os respins acima do binário de novembro de 2021 lançaram correções de bloqueio relatadas por OEM1 e OEM2 durante a janela de respins, mas nada mais.
• Os problemas mencionados no segundo item também estão incluídos nas versões mensais subsequentes do GKI.

O respin de outubro tem todos os patches enviados pelo OEM, mas outros patches OEM nos afetam, porque não foram testados especificamente com nossos produtos. É possível incluir apenas nosso patch?

Isso não é possível. Um caminho de respin "por OEM" atualmente não é escalável. Em vez disso, a equipe GKI examina cada alteração que ocorre nas compilações respin e testa as alterações com todo o hardware disponível antes de criar uma nova compilação. Se a equipe do GKI descobrir que o problema é específico de um OEM/dispositivo/modelo, a equipe do GKI poderá garantir que o código adicionado pela alteração seja executado apenas no dispositivo/modelo/SKU afetado.

O principal benefício dos respins unificados é que todos os dispositivos que usam a mesma base de lançamento se beneficiam uns dos outros, especialmente se os bugs descobertos forem genéricos e aplicáveis ​​a todos os usuários. Os principais bugs do kernel encontrados nos testes de operadora são um exemplo específico desse conceito.

Existem situações em que o Google fornece informações específicas sobre patches de OEM e cenários de problemas, para que os OEMs possam avaliar o impacto e o risco da implementação dos patches em seus produtos?

O Google nunca adicionará uma alteração a uma versão respin até que o problema seja compreendido e todos os detalhes tenham sido coletados. Isso é visto no changelog (mensagem de commit). O Google não revela qual dispositivo específico isso afeta, mas os OEMs sempre podem encontrar a descrição e a solução do problema no changelog.

,

Este documento descreve como o GKI é lançado, incluindo lançamentos de emergência semanais, mensais e fora de banda. O objetivo deste documento é fornecer aos OEMs uma orientação sobre onde obter o GKI, bem como o processo para correções de emergência fora de banda. Os OEMs também podem usar o guia de desenvolvimento do GKI para saber mais sobre como podem trabalhar com a equipe do Kernel do Android para otimizar o kernel do GKI para seus produtos.

Cadência de lançamento do GKI

O GKI é lançado em uma cadência mensal após o congelamento do KMI.

Lançamento do GKI do Android 13 e 14

A tabela a seguir é aplicável apenas a android13-5.10 , android13-5.15 e android14-6.1 .

Construções certificadas mensalmente da GKI	Data limite do check-in	Data de preparação do pré-carregamento do GKI	Confirmado?
Outubro	14 de outubro de 2022	31 de outubro de 2022	Sim
novembro	14 de novembro de 2022	30 de novembro de 2022	Sim
dezembro	9 de dezembro de 2022	21 de dezembro de 2022	Sim
Janeiro	17 de janeiro de 2023	31 de janeiro de 2023	Sim
Fevereiro	15 de fevereiro de 2023	28 de fevereiro de 2023	Sim
Marchar	15 de março de 2023	31 de março de 2023	Sim
abril	13 de abril de 2023	28 de abril de 2023	Sim
Poderia	17 de maio de 2023	31 de maio de 2023	Sim
Junho	15 de junho de 2023	30 de junho de 2023	Sim
Julho	18 de julho de 2023	31 de julho de 2023	Sim
Agosto	16 de agosto de 2023	31 de agosto de 2023	Sim
Setembro	14 de setembro de 2023	29 de setembro de 2023	Sim
Outubro	18 de outubro de 2023	31 de outubro de 2023	Sim
novembro	10 de novembro de 2023	30 de novembro de 2023	Sim
dezembro	7 de dezembro de 2023	22 de dezembro de 2023	Sim

Lançamento do Android 12 GKI

Depois de maio de 2023, os lançamentos android12-5.10 GKI ocorrerão em uma cadência de 2 meses e serão publicados no meio do mês. A tabela a seguir é aplicável apenas a android12-5.10 .

Construções certificadas mensalmente da GKI	Data limite do check-in	Data de preparação do pré-carregamento do GKI	Confirmado?
Julho	3 de julho de 2023	14 de julho de 2023	Sim
Setembro	1º de setembro de 2023	15 de setembro de 2023	Sim
novembro	3 de novembro de 2023	17 de novembro de 2023	Sim
Janeiro	5 de janeiro de 2024	19 de janeiro de 2024	Sim

Validade de compilação do GKI para OEMs

Os OEMs podem usar um Android GKI lançado recentemente. Os OEMs podem lançar compilações certificadas pela GKI, desde que estejam em conformidade com os requisitos LTS do Android Security Bulletin (ASB).

Lançamentos semanais de desenvolvimento

As liberações são testadas com chocos para garantir que passem por um padrão mínimo de qualidade .

Os binários GKI estão disponíveis para autoatendimento em ci.android.com à medida que as alterações são mescladas. As compilações semanais não serão certificadas, mas podem ser usadas como base para desenvolvimento e testes. As compilações semanais não podem ser usadas para compilações de dispositivos de produção para usuários finais.

Lançamentos certificados mensais

As versões mensais do GKI contêm um boot.img testado que inclui um certificado inserido pelo Google para atestar que os binários foram criados a partir de uma linha de base de código-fonte conhecida.

A cada mês, um release candidate mensal do GKI (não certificado) é selecionado após a data limite de check-in, que geralmente é a segunda compilação semanal daquele mês. Depois que o release candidate mensal for selecionado, novas alterações não serão aceitas no lançamento daquele mês. Durante o período de janela fechada, apenas correções de bugs que causam falha no teste podem ser corrigidas. O release candidate passa por garantia de qualidade — conforme descrito na seção de qualificação GKI — para garantir que os testes de conformidade sejam aprovados na construção GSI+GKI com um dispositivo de referência e também com choco.

Figura 1. Cronograma de lançamento do GKI

Processo de respin de emergência

Um respin refere-se ao processo de reintegração, reconstrução, novo teste e recertificação de um binário após um lançamento público do kernel GKI . Você pode solicitar uma nova rotação de um binário certificado em qualquer uma das seguintes circunstâncias:

• Para atualizar uma lista de símbolos.
• Para aplicar uma correção a um bug, incluindo bugs encontrados durante a aprovação do laboratório da operadora.
• Para adicionar um gancho de fornecedor .
• Para aplicar um patch a um recurso existente.
• Para aplicar um patch de segurança (após 6 meses).

Os patches de segurança são automaticamente mesclados em uma ramificação de lançamento por até 6 meses após o lançamento da ramificação. Após o prazo de 6 meses, você deve solicitar uma nova rodada para aplicar patches de segurança a uma filial.

Antes de solicitar uma nova rodada, observe as seguintes diretrizes:

• Respins são permitidos apenas em ramificações de lançamento após o lançamento público inicial de uma compilação mensal .

• Solicitações de respin são aceitas apenas para um determinado branch de lançamento por no máximo seis meses após o lançamento público inicial. Após seis meses, as filiais são elegíveis para respin apenas para patches de segurança citados em um Boletim de Segurança do Android .

• Quando os requisitos LTS , definidos pelo Android Security Bulletin (ASB), fazem com que o branch não esteja em conformidade, o branch é obsoleto. Solicitações de respin para ramificações obsoletas não são aceitas. A data de descontinuação de um determinado branch de lançamento do GKI está incluída nas notas mensais de compilação do lançamento do GKI em Releases . Para planejamento futuro, os requisitos do LTS são atualizados anualmente em maio e novembro. Por exemplo, a ramificação android12-5.10-2023-07 (5.10.177) não é compatível com respins após 1º de maio de 2024, porque a ramificação android12-5.10-2023-07 (5.10.177) não está em conformidade com o Requisitos LTS da ASB-2024-05.

• Os respins são aplicáveis ​​apenas para correções urgentes de bugs, atualizações da lista de símbolos ou para aplicar um patch para corrigir um recurso existente.

• Todos os patches que vão para o branch de lançamento mensal já devem estar mesclados no branch de desenvolvimento principal do GKI. Por exemplo, se um patch for necessário para uma nova rotação de android12-5.10-2022-09 , ele já deverá estar mesclado em android12-5.10 .

• Você deve escolher os patches do branch de desenvolvimento principal do GKI e fazer upload do patch para o branch de lançamento mensal.

• Na solicitação de respin, você deve atribuir uma prioridade (urgência) à solicitação. Esta prioridade ajuda a equipe da GKI a ajudar melhor os parceiros em tempo hábil. Para solicitações críticas ou urgentes, marque a prioridade como P0 . Para solicitações P0 e P1, você também deverá justificar a urgência. A tabela a seguir fornece um mapeamento da prioridade do bug e do tempo de resolução (ESRT):

  Prioridade	ESRT
  P0	2 dias úteis
  P1	5 dias úteis
  P2	10 dias úteis
  P3	15 dias úteis

• Você deve enviar uma solicitação de respin separada por branch de lançamento. Por exemplo, se um respin for necessário para android12-5.10-2022-08 e android12-5.10-2022-09 , você deverá criar duas solicitações de respin.

• Depois que uma compilação for fornecida e uma solicitação de respin for marcada como corrigida, você não deverá reabrir a solicitação de respin para adicionar CLs adicionais. Você deve enviar uma nova solicitação de respin se houver patches adicionais que precisem ser mesclados.

• Para cada CL em consideração, adicione as tags a seguir. O progresso na solicitação de respin é bloqueado sem esta informação.

  • Bug : o ID do bug deve ser adicionado à mensagem de commit para cada CL.
  • Change-Id : deve ser idêntico ao Change-Id da alteração do branch base.

• Se uma solicitação de respin exigir sua resposta e você não responder dentro de três dias úteis, a prioridade será rebaixada em um nível (por exemplo, P0 será rebaixado para P1 ). Se você não responder por duas semanas, o bug será marcado como Não será corrigido (obsoleto) .

Envie uma solicitação de respin

O diagrama a seguir mostra o processo de respin. O processo começa quando o Parceiro OEM (você) envia a solicitação de respin.

Figura 2. O processo de respin

Para entrar no processo de respin:

1. Preencha o formulário de solicitação GKI Respin . e entre em contato com seu gerente técnico de conta do Google imediatamente. Este formulário cria um bug de solicitação de respin GKI. Os bugs de solicitação de respin são visíveis para você (o solicitante), para a equipe do GKI e para indivíduos específicos que você adiciona à lista de CC do bug.
   • Se você já tiver uma correção, a solicitação deverá apontar para o envio do patch no AOSP para que o Google possa revisá-la. Se o envio do patch não for viável, o patch deverá ser anexado como um arquivo de texto à solicitação.
   • Se você não tiver uma correção, a solicitação deverá conter o máximo de informações possível, incluindo o número da versão do kernel e os registros, para que o Google possa ajudar a depurar o problema.
2. A equipe do Google GKI analisa a solicitação e a aprova ou a atribui de volta a você se mais informações forem necessárias.
3. Depois que uma correção é acordada, o código da equipe do Google GKI analisa (CR+2) a alteração. A revisão inicia o prazo ESRT. A equipe do GKI mescla, cria, testa a regressão e certifica a mudança.
4. O binário é lançado em ci.android.com . O prazo ESRT termina e a equipe do Google GKI marca a solicitação como corrigida e faz referência à compilação respin. A compilação respin também pode ser publicada na página de versões de versão da imagem genérica do kernel (GKI) .

Qualificações GKI

Tipos de compilações GKI	Aplicação da qualidade	Notas
Semanalmente	Teste de choco Bota Subconjunto de VTS Subconjunto de CTS	Não certificado. Somente para testes e dispositivo seja exibido. Não pode ser usado para iniciar dispositivos.
Mensalmente (certificado)	Teste de choco Bota VTS CTS Teste de hardware de referência Bota VTS CTS
Respins (certificados)	Teste de choco Bota VTS Subconjunto de CTS Teste de dispositivo de referência Bota VTS	Construído com base em uma versão certificada pela GKI. A construção é certificada após qualificação.

Onde obter artefatos de construção

Artefatos para todos os lançamentos podem ser obtidos em ci.android.com .

Você pode encontrar mais informações sobre o CI, incluindo os resultados do teste no painel de integração contínua do Android .

Perguntas frequentes

É possível construir um novo binário GKI baseado em um GKI já lançado?

Sim, isso é conhecido como respin. O processo de respin é suportado desde que a versão GKI lançada (na qual o respin é solicitado) esteja em conformidade com os requisitos LTS do Android Security Bulletin (ASB).

É possível reproduzir binários GKI?

Sim, consulte o exemplo abaixo.

GKI 2.0
5.10 kernel prebuilts from build 7364300
https://ci.android.com/builds/submitted/7364300/kernel_aarch64/latest

Para reproduzir o exemplo, baixe manifest_$id.xml e execute o seguinte comando:

repo init -u https://android.googlesource.com/kernel/manifest
mv manifest_7364300.xml .repo/manifests
repo init -m manifest_7364300.xml --depth=1
repo sync
# build the GKI images
# You may want to use LTO=thin to build faster for development
BUILD_CONFIG=common/build.config.gki.aarch64 build/build.sh
# (optional) build virtual platform modules
BUILD_CONFIG=common-modules/virtual-device/build.config.virtual_device.aarch64 build/build.sh

Você pode recuperar sua cópia do artefato GKI em out/.../dist .

O binário GKI (incluindo o patch de rotação de emergência) foi criado na base de código mais recente?

Os Respins contêm apenas patches que estão além dos kernels certificados mensalmente que foram escolhidos. Esses respins contêm todas as correções de bugs de bloqueio de inicialização relatadas até um determinado momento pelos OEMs usando a versão mensal base correspondente. Veja no exemplo a seguir como acontece esse tipo de cenário.

• OEM1 e OEM2 decidem usar a versão binária GKI a partir de novembro de 2021.
• OEM1 e OEM2 encontram problemas que exigem patches para suporte. Esses patches podem ser diferentes ou iguais.
• Os respins acima do binário de novembro de 2021 lançaram correções de bloqueio relatadas por OEM1 e OEM2 durante a janela de respins, mas nada mais.
• Os problemas mencionados no segundo item também estão incluídos nas versões mensais subsequentes do GKI.

O respin de outubro tem todos os patches enviados pelo OEM, mas outros patches OEM nos afetam, porque não foram testados especificamente com nossos produtos. É possível incluir apenas nosso patch?

Isso não é possível. Um caminho de respin "por OEM" atualmente não é escalável. Em vez disso, a equipe GKI examina cada alteração que ocorre nas compilações respin e testa as alterações com todo o hardware disponível antes de criar uma nova compilação. Se a equipe do GKI descobrir que o problema é específico de um OEM/dispositivo/modelo, a equipe do GKI poderá garantir que o código adicionado pela alteração seja executado apenas no dispositivo/modelo/SKU afetado.

O principal benefício dos respins unificados é que todos os dispositivos que usam a mesma base de lançamento se beneficiam uns dos outros, especialmente se os bugs descobertos forem genéricos e aplicáveis ​​a todos os usuários. Os principais bugs do kernel encontrados nos testes de operadora são um exemplo específico desse conceito.

Existem situações em que o Google fornece informações específicas sobre patches de OEM e cenários de problemas, para que os OEMs possam avaliar o impacto e o risco da implementação dos patches em seus produtos?

O Google nunca adicionará uma alteração a uma versão respin até que o problema seja compreendido e todos os detalhes tenham sido coletados. Isso é visto no changelog (mensagem de commit). O Google não revela qual dispositivo específico isso afeta, mas os OEMs sempre podem encontrar a descrição e a solução do problema no changelog.