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

Esta página foi traduzida pela API Cloud Translation.

AIDL para HALs

O Android 11 apresenta a capacidade de usar AIDL para HALs no Android. Isso torna possível implementar partes do Android sem HIDL. Transição HALs para usar AIDL exclusivamente quando possível (quando HALs upstream usam HIDL, HIDL deve ser usado).

HALs que usam AIDL para se comunicar entre componentes de estrutura, como os de system.img , e componentes de hardware, como os de vendor.img , devem usar AIDL estável. No entanto, para se comunicar dentro de uma partição, por exemplo, de um HAL para outro, não há restrição quanto ao mecanismo IPC a ser usado.

Motivação

O AIDL existe há mais tempo que o HIDL e é usado em muitos outros lugares, como entre componentes da estrutura do Android ou em aplicativos. Agora que o AIDL tem suporte à estabilidade, é possível implementar uma pilha inteira com um único tempo de execução de IPC. AIDL também possui um sistema de versionamento melhor que o HIDL.

Usar uma única linguagem IPC significa ter apenas uma coisa para aprender, depurar, otimizar e proteger.
AIDL suporta versão in-loco para os proprietários de uma interface:
- Os proprietários podem adicionar métodos ao final das interfaces ou campos aos parcelables. Isso significa que é mais fácil a versão do código ao longo dos anos, e também o custo ano a ano é menor (os tipos podem ser alterados no local e não há necessidade de bibliotecas extras para cada versão de interface).
- As interfaces de extensão podem ser anexadas em tempo de execução em vez de no sistema de tipos, portanto, não há necessidade de rebasear extensões downstream em versões mais recentes de interfaces.
Uma interface AIDL existente pode ser usada diretamente quando seu proprietário optar por estabilizá-la. Antes, uma cópia inteira da interface teria que ser criada em HIDL.

Escrevendo uma interface AIDL HAL

Para que uma interface AIDL seja usada entre o sistema e o fornecedor, a interface precisa de duas alterações:

Cada definição de tipo deve ser anotada com @VintfStability .
A declaração aidl_interface precisa incluir stability: "vintf", .

Somente o proprietário de uma interface pode fazer essas alterações.

Ao fazer essas alterações, a interface deve estar no manifesto VINTF para funcionar. Teste isso (e requisitos relacionados, como verificar se as interfaces liberadas estão congeladas) usando o teste VTS vts_treble_vintf_vendor_test . Você pode usar uma interface @VintfStability sem esses requisitos chamando AIBinder_forceDowngradeToLocalStability no back-end do NDK, android::Stability::forceDowngradeToLocalStability no back-end C++ ou android.os.Binder#forceDowngradeToSystemStability no back-end Java em um objeto binder antes de ser enviado para outro processo. O downgrade de um serviço para a estabilidade do fornecedor não é compatível com Java porque todos os aplicativos são executados em um contexto de sistema.

Além disso, para portabilidade máxima de código e para evitar problemas potenciais, como bibliotecas adicionais desnecessárias, desative o back-end CPP.

Observe que o uso de back- backends no exemplo de código abaixo está correto, pois há três back-ends (Java, NDK e CPP). O código abaixo informa como selecionar o back-end CPP especificamente, para desativá-lo.

    aidl_interface: {
        ...
        backends: {
            cpp: {
                enabled: false,
            },
        },
    }

Encontrando interfaces AIDL HAL

As interfaces AIDL estáveis do AOSP para HALs estão nos mesmos diretórios base das interfaces HIDL, em pastas aidl .

hardware/interfaces
frameworks/hardware/interfaces
sistema/hardware/interfaces

Você deve colocar interfaces de extensão em outros subdiretórios de hardware/interfaces em vendor ou hardware .

Interfaces de extensão

O Android tem um conjunto de interfaces AOSP oficiais a cada versão. Quando os parceiros Android desejam adicionar funcionalidade a essas interfaces, eles não devem alterá-las diretamente, pois isso significaria que o tempo de execução do Android é incompatível com o tempo de execução do Android AOSP. Para dispositivos GMS, evitar a alteração dessas interfaces também é o que garante que a imagem GSI continue funcionando.

As extensões podem ser registradas de duas maneiras diferentes:

em tempo de execução, veja as extensões anexadas .
autônomo, registrado globalmente e em VINTF.

No entanto, uma extensão é registrada, quando componentes específicos do fornecedor (ou seja, não fazem parte do AOSP upstream) usam a interface, não há possibilidade de conflito de mesclagem. No entanto, quando são feitas modificações downstream em componentes AOSP upstream, podem ocorrer conflitos de mesclagem e as seguintes estratégias são recomendadas:

as adições de interface podem ser enviadas para o AOSP na próxima versão
adições de interface que permitem maior flexibilidade, sem conflitos de mesclagem, podem ser upstream na próxima versão

Parcelables de extensão: ParcelableHolder

ParcelableHolder é um Parcelable que pode conter outro Parcelable . O principal caso de uso do ParcelableHolder é tornar um Parcelable extensível. Por exemplo, imagem que os implementadores de dispositivos esperam poder estender um Parcelable definido por AOSP, AospDefinedParcelable , para incluir seus recursos de valor agregado.

Anteriormente, sem ParcelableHolder , os implementadores de dispositivos não podiam modificar uma interface AIDL estável definida por AOSP porque seria um erro adicionar mais campos:

parcelable AospDefinedParcelable {
  int a;
  String b;
  String x; // ERROR: added by a device implementer
  int[] y; // added by a device implementer
}

Conforme visto no código anterior, essa prática é interrompida porque os campos adicionados pelo implementador do dispositivo podem ter um conflito quando o Parcelable for revisado nas próximas versões do Android.

Usando ParcelableHolder , o proprietário de um parcelable pode definir um ponto de extensão em um Parcelable .

parcelable AospDefinedParcelable {
  int a;
  String b;
  ParcelableHolder extension;
}

Em seguida, os implementadores de dispositivos podem definir seu próprio Parcelable para sua extensão.

parcelable OemDefinedParcelable {
  String x;
  int[] y;
}

Finalmente, o novo Parcelable pode ser anexado ao Parcelable original através do campo ParcelableHolder .


// Java
AospDefinedParcelable ap = ...;
OemDefinedParcelable op = new OemDefinedParcelable();
op.x = ...;
op.y = ...;

ap.extension.setParcelable(op);

...

OemDefinedParcelable op = ap.extension.getParcelable(OemDefinedParcelable.class);

// C++
AospDefinedParcelable ap;
OemDefinedParcelable op;
std::shared_ptr<OemDefinedParcelable> op_ptr = make_shared<OemDefinedParcelable>();

ap.extension.setParcelable(op);
ap.extension.setParcelable(op_ptr);

...

std::shared_ptr<OemDefinedParcelable> op_ptr;

ap.extension.getParcelable(&op_ptr);

// NDK
AospDefinedParcelable ap;
OemDefinedParcelable op;
ap.extension.setParcelable(op);

...

std::optional<OemDefinedParcelable> op;
ap.extension.getParcelable(&op);

// Rust
let mut ap = AospDefinedParcelable { .. };
let op = Rc::new(OemDefinedParcelable { .. });

ap.extension.set_parcelable(Rc::clone(&op));

...

let op = ap.extension.get_parcelable::<OemDefinedParcelable>();

Construindo contra o tempo de execução AIDL

AIDL tem três back-ends diferentes: Java, NDK, CPP. Para usar AIDL estável, você deve sempre usar a cópia do sistema do libbinder em system/lib*/libbinder.so e falar em /dev/binder . Para o código na imagem do fornecedor, isso significa que o libbinder (do VNDK) não pode ser usado: esta biblioteca possui uma API C++ instável e internos instáveis. Em vez disso, o código do fornecedor nativo deve usar o backend NDK do AIDL, vincular-se a libbinder_ndk (que é suportado pelo sistema libbinder.so ) e vincular-se às bibliotecas -ndk_platform criadas pelas entradas aidl_interface .

Nomes de instâncias do servidor AIDL HAL

Por convenção, os serviços AIDL HAL têm um nome de instância no formato $package.$type/$instance . Por exemplo, uma instância do vibrador HAL é registrada como android.hardware.vibrator.IVibrator/default .

Escrevendo um servidor AIDL HAL

Os servidores @VintfStability AIDL devem ser declarados no manifesto VINTF, por exemplo assim:

    <hal format="aidl">
        <name>android.hardware.vibrator</name>
        <version>1</version>
        <fqname>IVibrator/default</fqname>
    </hal>

Caso contrário, eles devem registrar um serviço AIDL normalmente. Ao executar testes VTS, espera-se que todos os AIDL HALs declarados estejam disponíveis.

Escrevendo um cliente AIDL

Os clientes AIDL devem se declarar na matriz de compatibilidade, por exemplo, assim:

    <hal format="aidl" optional="true">
        <name>android.hardware.vibrator</name>
        <version>1-2</version>
        <interface>
            <name>IVibrator</name>
            <instance>default</instance>
        </interface>
    </hal>

Convertendo um HAL existente de HIDL para AIDL

Use a ferramenta hidl2aidl para converter uma interface HIDL em AIDL.

Características do hidl2aidl :

Crie arquivos .aidl com base nos arquivos .hal para o pacote fornecido
Crie regras de compilação para o pacote AIDL recém-criado com todos os back-ends habilitados
Crie métodos de tradução nos back-ends Java, CPP e NDK para traduzir dos tipos HIDL para os tipos AIDL
Crie regras de compilação para bibliotecas de tradução com dependências necessárias
Crie declarações estáticas para garantir que os enumeradores HIDL e AIDL tenham os mesmos valores nos back-ends CPP e NDK

Siga estas etapas para converter um pacote de arquivos .hal em arquivos .aidl:

Compile a ferramenta localizada em system/tools/hidl/hidl2aidl .
Construir esta ferramenta a partir da fonte mais recente fornece a experiência mais completa. Você pode usar a versão mais recente para converter interfaces em ramificações mais antigas de versões anteriores.
```
m hidl2aidl
```
Execute a ferramenta com um diretório de saída seguido do pacote a ser convertido.
```
hidl2aidl -o <output directory> <package>
```
Por exemplo:
```
hidl2aidl -o . android.hardware.nfc@1.2
```
Leia os arquivos gerados e corrija quaisquer problemas com a conversão.
- conversion.log contém quaisquer problemas não tratados a serem corrigidos primeiro.
- Os arquivos .aidl gerados podem ter avisos e sugestões que podem precisar de ação. Esses comentários começam com // .
- Aproveite para limpar e fazer melhorias no pacote.
Construa apenas os alvos que você precisa.
- Desative os back-ends que não serão usados. Prefira o back-end NDK sobre o back-end CPP, consulte Escolhendo o tempo de execução .
- Remova as bibliotecas de tradução ou qualquer código gerado que não será usado.
Consulte Principais diferenças AIDL/HIDL .
- Usar o Status e as exceções integrados do AIDL geralmente melhoram a interface e eliminam a necessidade de outro tipo de status específico da interface.

Sepolicy para AIDL HALs

Um tipo de serviço AIDL que é visível para o código do fornecedor deve ter o atributo vendor_service . Caso contrário, a configuração de sepolicy é a mesma de qualquer outro serviço AIDL (embora haja atributos especiais para HALs). Aqui está um exemplo de definição de um contexto de serviço HAL:

    type hal_foo_service, service_manager_type, vendor_service;

Para a maioria dos serviços definidos pela plataforma, um contexto de serviço com o tipo correto já é adicionado (por exemplo, android.hardware.foo.IFoo/default já estaria marcado como hal_foo_service ). No entanto, se um cliente de estrutura oferecer suporte a vários nomes de instância, nomes de instância adicionais deverão ser adicionados em arquivos service_contexts específicos do dispositivo.

    android.hardware.foo.IFoo/custom_instance u:object_r:hal_foo_service:s0

Os atributos HAL devem ser adicionados quando criamos um novo tipo de HAL. Um atributo HAL específico pode estar associado a vários tipos de serviço (cada um dos quais pode ter várias instâncias, como acabamos de discutir). Para um HAL, foo , temos hal_attribute(foo) . Esta macro define os atributos hal_foo_client e hal_foo_server . Para um determinado domínio, as macros hal_client_domain e hal_server_domain associam um domínio a um determinado atributo HAL. Por exemplo, o servidor do sistema sendo um cliente deste HAL corresponde à política hal_client_domain(system_server, hal_foo) . Um servidor HAL também inclui hal_server_domain(my_hal_domain, hal_foo) . Normalmente, para um determinado atributo HAL, também criamos um domínio como hal_foo_default para referência ou HALs de exemplo. No entanto, alguns dispositivos usam esses domínios para seus próprios servidores. A distinção entre domínios para vários servidores só importa se tivermos vários servidores que atendem à mesma interface e precisam de um conjunto de permissões diferente em suas implementações. Em todas essas macros, hal_foo não é realmente um objeto de sepolicy. Em vez disso, esse token é usado por essas macros para se referir ao grupo de atributos associados a um par cliente-servidor.

No entanto, até agora, não associamos hal_foo_service e hal_foo (o par de atributos de hal_attribute(foo) ). Um atributo HAL é associado aos serviços AIDL HAL usando a macro hal_attribute_service (os HALs HIDL usam a macro hal_attribute_hwservice ). Por exemplo, hal_attribute_service(hal_foo, hal_foo_service) . Isso significa que os processos hal_foo_client podem obter o HAL e os processos hal_foo_server podem registrar o HAL. A aplicação dessas regras de registro é feita pelo gerenciador de contexto ( servicemanager ). Observe que os nomes de serviço nem sempre podem corresponder aos atributos HAL. Por exemplo, podemos ver hal_attribute_service(hal_foo, hal_foo2_service) . Geralmente, porém, como isso implica que os serviços são sempre usados juntos, podemos considerar remover o hal_foo2_service e usar hal_foo_service para todos os nossos contextos de serviço. A maioria dos HALs que definem vários hal_attribute_service porque o nome do atributo HAL original não é geral o suficiente e não pode ser alterado.

Juntando tudo isso, um exemplo de HAL se parece com isso:

    public/attributes:
    // define hal_foo, hal_foo_client, hal_foo_server
    hal_attribute(foo)

    public/service.te
    // define hal_foo_service
    type hal_foo_service, vendor_service, protected_service, service_manager_type

    public/hal_foo.te:
    // allow binder connection from client to server
    binder_call(hal_foo_client, hal_foo_server)
    // allow client to find the service, allow server to register the service
    hal_attribute_service(hal_foo, hal_foo_service)
    // allow binder communication from server to service_manager
    binder_call(hal_foo_server, servicemanager)

    private/service_contexts:
    // bind an AIDL service name to the selinux type
    android.hardware.foo.IFooXxxx/default u:object_r:hal_foo_service:s0

    private/<some_domain>.te:
    // let this domain use the hal service
    binder_use(some_domain)
    hal_client_domain(some_domain, hal_foo)

    vendor/<some_hal_server_domain>.te
    // let this domain serve the hal service
    binder_use(some_hal_server_domain)
    hal_server_domain(some_hal_server_domain, hal_foo)

Interfaces de extensão anexadas

Uma extensão pode ser anexada a qualquer interface do binder, seja uma interface de nível superior registrada diretamente no gerenciador de serviços ou uma subinterface. Ao obter uma extensão, você deve confirmar se o tipo da extensão é o esperado. As extensões só podem ser definidas a partir do processo que atende a um fichário.

Extensões anexadas devem ser usadas sempre que uma extensão modifica a funcionalidade de um HAL existente. Quando uma funcionalidade totalmente nova é necessária, esse mecanismo não precisa ser usado, e uma interface de extensão pode ser registrada diretamente no gerenciador de serviços. As interfaces de extensão anexadas fazem mais sentido quando são anexadas a subinterfaces, porque essas hierarquias podem ser profundas ou de várias instâncias. O uso de uma extensão global para espelhar a hierarquia da interface do fichário de outro serviço exigiria uma contabilidade extensa para fornecer funcionalidade equivalente às extensões anexadas diretamente.

Para definir uma extensão no binder, use as seguintes APIs:

No back-end do NDK: AIBinder_setExtension
No back-end Java: android.os.Binder.setExtension
No back-end do CPP: android::Binder::setExtension

Para obter uma extensão em um binder, use as seguintes APIs:

No back-end do NDK: AIBinder_getExtension
No back-end Java: android.os.IBinder.getExtension
No back-end do CPP: android::IBinder::getExtension

Você pode encontrar mais informações sobre essas APIs na documentação da função getExtension no back-end correspondente. Um exemplo de como usar extensões pode ser encontrado em hardware/interfaces/tests/extension/vibrator .

Principais diferenças AIDL/HIDL

Ao usar AIDL HALs ou usar interfaces AIDL HAL, esteja ciente das diferenças em comparação com a gravação de HIDL HALs.

A sintaxe da linguagem AIDL está mais próxima de Java. A sintaxe HIDL é semelhante ao C++.
Todas as interfaces AIDL possuem status de erro integrados. Em vez de criar tipos de status personalizados, crie ints de status constantes em arquivos de interface e use EX_SERVICE_SPECIFIC nos backends CPP/NDK e ServiceSpecificException no backend Java. Consulte Tratamento de erros .
AIDL não inicia automaticamente os conjuntos de encadeamentos quando os objetos do binder são enviados. Eles devem ser iniciados manualmente (consulte gerenciamento de threads ).
AIDL não aborta em erros de transporte não verificados (HIDL Return aborta em erros não verificados).
AIDL só pode declarar um tipo por arquivo.
Os argumentos AIDL podem ser especificados como in/out/inout além do parâmetro de saída (não há "retornos de chamada síncronos").
AIDL usa um fd como o tipo primitivo em vez de handle.
O HIDL usa versões principais para alterações incompatíveis e versões secundárias para alterações compatíveis. No AIDL, as alterações compatíveis com versões anteriores são feitas no local. AIDL não tem um conceito explícito de versões principais; em vez disso, isso é incorporado aos nomes dos pacotes. Por exemplo, AIDL pode usar o nome do pacote bluetooth2 .