O Google tem o compromisso de promover a igualdade racial para as comunidades negras. Saiba como.

Verificação de compatibilidade com versões anteriores da estrutura HIDL

HALs HIDL garantir o núcleo do sistema Android (aka system.img ou quadro) é compatível. Enquanto fornecedor de testes Suite (VTS) testes de assegurar que HAL trabalho como esperado (por exemplo, 1,1 testes Hal são executados em todos os 1.2 implementações), testes de quadro é necessário para assegurar que, quando um HAL suportado (1.0, 1.1, ou 1.2) é fornecida, a framework funciona corretamente com esse HAL.

Para mais detalhes sobre HAL linguagem de definição de interface (HIDL), referem-se a HIDL , HIDL versionamento , e HIDL HAL Deprecation .

Sobre atualizações de HAL

Existem dois tipos de atualizações HAL: maior e menor. A maioria dos sistemas inclui apenas uma implementação HAL, mas várias implementações são suportadas. Por exemplo:

android.hardware.teleport@1.0 # initial interface
android.hardware.teleport@1.1 # minor version upgrade
android.hardware.teleport@1.2 # another minor version upgrade
...
android.hardware.teleport@2.0 # major version upgrade
...

A partição do sistema inclui, tipicamente, um daemon quadro (tal como teleportd ) que gere a comunicação com um grupo específico de implementações HAL. Alternativamente, sistemas pode, em vez incluem uma biblioteca de sistema (como android.hardware.configstore-utils ) que implementa o comportamento do cliente conveniente. No exemplo acima, teleportd deve trabalhar, não importa qual a versão do HAL está instalado no dispositivo.

Versões mantidas pelo Google

Se houver atualizações de versão principal (1.0, 2.0, 3.0, etc.), pelo menos um dispositivo mantido pelo Google deve manter uma implementação de cada versão principal até que essa versão seja descontinuada. Se nenhum dispositivo mantido pelo Google for fornecido com uma versão principal específica, o Google continuará a manter uma implementação antiga dessa versão principal.

Essa manutenção adiciona uma pequena sobrecarga adicional porque a implementação antiga (por exemplo, 1.2) pode ser mantida e não usada por padrão quando uma nova implementação (por exemplo, 2.0) é criada.

Testando atualizações de versões secundárias

Testar a compatibilidade com versões anteriores de versões secundárias na estrutura requer uma maneira de gerar implementações de versões secundárias automaticamente. Dadas as restrições em torno de versões Google conservados, hidl-gen só (e só pode) gerar adaptadores que levam a (x + n) a aplicação 1. e fornecer uma implementação 1.x; ele não pode gerar uma implementação 1.0 a partir de uma implementação 2.0 (por definição de uma versão principal).

Por exemplo, para executar testes 1.1 em uma implementação 1.2, você deve ser capaz de simular uma implementação 1.1. Os 1,2 interfaces podem ser automaticamente usado como 1.1 implementação com algumas pequenas diferenças no comportamento (como o quadro manualmente verificar qual versão algo é ou chamando castFrom sobre ele).

A ideia básica é esta:

  1. Instale uma interface x. (Y + n) em um dispositivo móvel Android.
  2. Instale e ative um adaptador de destino xy.
  3. Teste o dispositivo para verificar se ele funciona conforme o esperado ao executar uma versão secundária mais antiga.

Esses adaptadores ocultam completamente o fato de que a implementação é, na verdade, apoiada por uma interface 1.2 e fornece apenas a interface 1.1 (o adaptador pega uma interface 1.2 e faz com que pareça uma interface 1.1).

Fluxo de trabalho de exemplo

Neste exemplo, o dispositivo Android é executado android.hardware.foo@1.1::IFoo/default . Para garantir um cliente funciona corretamente com android.hardware.foo@1.0::IFoo/default :

  1. Em um terminal, execute o seguinte:
    $ PACKAGE=android.hidl.allocator@1.0-adapter
    $ INTERFACE=IAllocator
    $ INSTANCE=ashmem
    $ THREAD_COUNT=1 # can see current thread use on `lshal -i -e`
    $ m -j $PACKAGE
    $ /data/nativetest64/$PACKAGE/$PACKAGE $INTERFACE $INSTANCE $THREAD_COUNT
    Trying to adapt down android.hidl.allocator@1.0-adapter/default
    Press any key to disassociate adapter.
  2. Reinicie o cliente usando adb shell stop (ou start ) ou simplesmente matar o processo.
  3. Após a conclusão do teste, desassocie o adaptador.
  4. Restaure o estado do sistema reiniciando o dispositivo OU reiniciando o cliente.

Alvos adicionais

hidl-gen adiciona automaticamente alvos de compilação adicionais para os adaptadores para cada interface especificada com hidl_interface no sistema de compilação. Para o pacote abc@xy , existe um C ++ alvo adicional abc@xy-adapter .

Um adaptador para abc@xy toma como uma entrada alguns implementação, abc@x.(y+n)::ISomething/instance-name , e deve registar-se abc@xy::ISomething/instance-name que deve também unregistere o y+n implementação.

Dada a seguinte interface de amostra:

// IFoo.hal
package a.b.c@1.0;
interface IFoo {
    doFoo(int32_t a) generates (int64_t b);
    doSubInterface() generates (IFoo a);
};

O código fornecido pelo abc@1.0-adapter é semelhante ao exemplo abaixo:

// autogenerated code
// in namespace a::b::c::V1_0::IFoo
struct MockFoo {
    // takes some subclass of V1_0. May be V1_1, V1_2, etc...
    MockFoo(V1_0::IFoo impl) mImpl(impl) {}

    Return<int64_t> doFoo(int32_t a) {
        return this->mImpl->doFoo(a);
    }

    Return<V1_0::ICallback> doSubInterface() {
        // getMockForBinder returns MockCallback instance
        // that corresponds to a particular binder object
        // It can't return a new object every time or
        // clients using interfacesSame will have
        // divergent behavior when using the mock.
        auto _hidl_out = this->mImpl->doSubInterface();
        return getMockForBinder(_hidl_out);
    }
};

Os valores dos dados são encaminhados exatamente para dentro e para fora da classe simulada gerada automaticamente, exceto para subinterfaces, que são retornadas. Essas interfaces devem ser agrupadas no objeto de retorno de chamada mais recente correspondente.