Em 2026, para nos alinharmos ao nosso modelo de desenvolvimento estável e garantir a estabilidade da plataforma para o ecossistema, vamos publicar o código-fonte no AOSP no segundo e quarto trimestres. Para criar e contribuir com o AOSP, use android-latest-release. A ramificação de manifesto android-latest-release sempre vai referenciar a versão mais recente enviada ao AOSP. Para mais informações, consulte Mudanças no AOSP.

O Google usa tecnologia de IA na tradução de conteúdos para seu idioma de preferência. As traduções com IA podem ter erros.

Sincronização de tempo

A plataforma de veículo definido por software (SDV, na sigla em inglês) do AAOS define mecanismos padrão para relatórios de origem de tempo de unidades de controle eletrônico (ECUs, na sigla em inglês) e superfícies padrão para expor informações de tempo em instâncias de SDV. Esta página fornece detalhes e orientações para o padrão SDV.

Arquitetura de relógio

A plataforma SDV tem dois relógios padrão:

Relógio UTC:é o relógio padrão de Tempo Universal Coordenado. O SOME/IP geralmente fornece isso das ECUs para o ambiente de execução da plataforma. Os casos de uso incluem validade do certificado, diagnósticos e V2X.
Relógio monotônico de rede:é um sinal de relógio não decrescente e altamente preciso fornecido pelas ECUs que a arquitetura de veículo mais ampla usa para garantir que os eventos sejam coordenados. As ECUs fornecem isso à plataforma SDV pelo gPTP. Esse relógio também é conhecido como relógio estável.

Os relógios na plataforma SDV têm requisitos arquitetônicos específicos:

Entrega de relógio:cada instância de VM tem acesso ao mesmo sinal de relógio monotônico fornecido pelas ECUs.
Integridade do relógio:espera-se que a entrada do relógio monotônico de rede seja uma fonte confiável para coordenar eventos entre serviços. A defesa contra possíveis vulnerabilidades do sistema, como ataques de repetição ou inversão de tempo, é baseada na integridade do relógio monotônico.
Uso de alarmes:as APIs de relógio da plataforma SDV não devem ser usadas para eventos com ocorrência de alta frequência (> 100 Hz) ou latência < 10 ms entre o agendamento e o horário do evento. APIs de alta frequência ou baixa latência precisam usar um driver de kernel.

APIs de relógio

O relógio monotônico de rede é exposto pela API clock_gettime(3) padrão:

// Network monotonic clock uses standard Linux API.
// This is represented as a dynamic clock in clock_gettime(3)
clock_gettime(clockid_t id, &timespec)

Esse relógio é fornecido por um mecanismo de rede PTP para todas as VMs e é registrado como um relógio dinâmico para fins de clock_gettime(3).

O relógio UTC é representado por CLOCK_REALTIME em clock_gettime(3).

Driver de dispositivo opcional

Os OEMs têm a opção de expor um bloco de dispositivos Linux para outras propriedades de tempo. Exponha isso com o processamento de permissões pelo sepolicy:

# in device/OEM/target/sepolicy/time/file_contexts
/dev/sdvtime u:object_r:time_device:s0

Os OEMs são responsáveis pelo desenvolvimento e pelas funcionalidades do driver de dispositivo Linux personalizado que expõe APIs ao bloco de dispositivos.

Notificações e callbacks

As notificações e os callbacks para componentes de tempo no SDV são recursos do espaço do usuário fornecidos pelo OEM. A plataforma SDV não fornece APIs específicas para essas funções.

Deve haver até um serviço OEM por VM que exija a funcionalidade de sincronização de tempo que processe todas as mudanças de tempo relevantes a serem monitoradas. Como exemplo, quando o estado confiável muda para a origem de tempo atual:

Espera-se que as mudanças nos estados da origem de tempo sejam eventos de baixa frequência. Portanto, um serviço OEM pode verificar as mudanças por meio de polling, por exemplo, uma vez por minuto.
As ECUs comunicam o status de estado confiável do relógio UTC pela rede, por exemplo, pelo SOME/IP.
Um serviço OEM publica tópicos específicos do Data Tunnel para mostrar essas mudanças aos assinantes.
Os OEMs personalizam a política de autorização para que os serviços determinem quais podem se inscrever nesses tópicos do Data Tunnel para ouvir mudanças de estado de tempo confiáveis.

Status e tratamento de erros

Os códigos de erro seguem as convenções das APIs Linux padrão envolvidas, por exemplo:

Se clock_gettime() falhar, isso retornará -1 e errno será definido. Isso implica que a operação de relógio não é compatível ou que a origem do relógio subjacente não está pronta.
Se fopen() falhar, isso retornará um ponteiro nulo e errno será definido. Isso implica que o dispositivo de bloco não está disponível.
Se uma chamada ioctl() falhar, isso retornará -1 e errno será definido. Isso implica que o código de solicitação especificado não tem uma resposta correspondente do driver subjacente.