Criar a interface HAL

É preciso usar o HIDL para descrever todas as flags de build usadas para e compilar o framework. As sinalizações de criação relevantes precisam ser agrupadas e incluídas em um um único arquivo .hal. Como usar HIDL para especificar itens de configuração inclui os seguintes benefícios:

• Controle de versão (para adicionar novos itens de configuração, os fornecedores/OEMs precisam estender explicitamente o HAL)
• Bem documentado
• Controle de acesso usando o SELinux
• Verificação de integridade dos itens de configuração por meio do Teste do fornecedor Pacote (verificação de intervalo, verificação de interdependência entre itens etc.)
• APIs geradas automaticamente em C++ e Java

Identificar as flags de build usadas pelo framework

Comece identificando as configurações usadas para compilar condicionalmente o e abandonar configurações obsoletas para diminuir o conjunto. Por exemplo: o seguinte conjunto de flags de build é identificado para surfaceflinger:

• TARGET_USES_HWC2
• TARGET_BOARD_PLATFORM
• TARGET_DISABLE_TRIPLE_BUFFERING
• TARGET_FORCE_HWC_FOR_VIRTUAL_DISPLAYS
• NUM_FRAMEBUFFER_SURFACE_BUFFERS
• TARGET_RUNNING_WITHOUT_SYNC_FRAMEWORK
• VSYNC_EVENT_PHASE_OFFSET_NS
• SF_VSYNC_EVENT_PHASE_OFFSET_NS
• PRESENT_TIME_OFFSET_FROM_VSYNC_NS
• MAX_VIRTUAL_DISPLAY_DIMENSION

Criar uma interface HAL

As configurações do build para um subsistema são acessadas por uma interface HAL, enquanto interfaces para fornecer valores de configuração são agrupadas no pacote HAL. android.hardware.configstore (atualmente na versão 1.0). Por exemplo, para criar um arquivo de interface HAL para surfaceflinger, hardware/interfaces/configstore/1.0/ISurfaceFlingerConfigs.hal:

package android.hardware.configstore@1.0;

interface ISurfaceFlingerConfigs {
    // TO-BE-FILLED-BELOW
};

Depois de criar o arquivo .hal, execute hardware/interfaces/update-makefiles.sh para adicionar o novo .hal para o Android.bp e arquivos Android.mk.

Adicionar funções para flags de build

Para cada flag de build, adicione uma nova função à interface. Por exemplo, em hardware/interfaces/configstore/1.0/ISurfaceFlingerConfigs.hal:

interface ISurfaceFlingerConfigs {
    disableTripleBuffering() generates(OptionalBool ret);
    forceHwcForVirtualDisplays() generates(OptionalBool ret);
    enum NumBuffers: uint8_t {
        USE_DEFAULT = 0,
        TWO = 2,
        THREE = 3,
    };
    numFramebufferSurfaceBuffers() generates(NumBuffers ret);
    runWithoutSyncFramework() generates(OptionalBool ret);
    vsyncEventPhaseOffsetNs generates (OptionalUInt64 ret);
    presentTimeOffsetFromSyncNs generates (OptionalUInt64 ret);
    maxVirtualDisplayDimension() generates(OptionalInt32 ret);
};

Ao adicionar uma função:

• Use os nomes concisos. Evitar a conversão da variável do makefile em nomes de função e lembre-se de que TARGET_ e Os prefixos BOARD_ não são mais necessários.
• Adicione comentários. Ajude os desenvolvedores a entender a finalidade do do item de configuração, como ele muda o comportamento do framework, os valores válidos e outras informações informações imprecisas ou inadequadas.

Os tipos de retorno da função podem ser Optional[Bool|String|Int32|UInt32|Int64|UInt64]: Os tipos são definidos em types.hal no mesmo diretório e unir valores primitivos com uma que indica se o valor é especificado pela HAL; Caso contrário, o padrão é usado.

struct OptionalString {
    bool specified;
    string value;
};

Quando apropriado, defina o tipo enumerado que melhor representa o tipo do item de configuração e usar esse tipo enumerado como o tipo de retorno. No exemplo acima, o tipo enumerado NumBuffers é definido para limitar o número de objetos valores. Ao definir esses tipos de dados personalizados, adicione um campo ou um valor de enumeração (por exemplo, USE_DEFAULT) para indicar se o valor é ou não especificado pela HAL.

Não é obrigatório que um único sinalizador de criação se torne uma única função HIDL Os proprietários de módulo também podem agregar flags de compilação intimamente relacionadas a um struct e tem uma função que retorna esse struct (fazer isso pode reduzir número de chamadas de função).

Por exemplo, uma opção para agregar duas flags de build em um só struct em hardware/interfaces/configstore/1.0/ISurfaceFlingerConfigs.hal é:

 interface ISurfaceFlingerConfigs {
    // other functions here
    struct SyncConfigs {
        OptionalInt64 vsyncEventPhaseoffsetNs;
        OptionalInt64 presentTimeoffsetFromSyncNs;
    };
    getSyncConfigs() generates (SyncConfigs ret);
    // other functions here
};

Alternativas para uma única função HAL

Como alternativa ao uso de uma única função HAL para todas as flags de compilação, a HAL também oferece funções simples, como getBoolean(string key) e getInteger(string key). O real Os pares key=value são armazenados em arquivos separados e no serviço HAL. fornece valores lendo/analisando esses arquivos.

Embora essa abordagem seja fácil de definir, ela não inclui os benefícios fornecidos pelo HIDL (controle de versões aplicado, facilidade de documentação, controle de acesso) Por isso, ele não é recomendado.

Interfaces únicas e múltiplas

O design da interface HAL para itens de configuração apresenta duas opções:

• Uma única interface que abrange todos os itens de configuração
• Várias interfaces, cada uma abrangendo um conjunto de configurações relacionadas itens

Usar uma única interface é mais fácil, mas pode se tornar impossível de manter à medida que itens de configuração são adicionados a um único arquivo. Além disso, o controle de acesso não é refinado, ou seja, um processo que tem acesso à interface pode ler todos os itens de configuração (o acesso a um conjunto parcial de itens de configuração não pode ser concedido). Se o acesso não for concedido, os itens de configuração não poderão ser ler.

Devido a esses problemas, o Android usa várias interfaces com uma única HAL. para um grupo de itens de configuração relacionados. Por exemplo: ISurfaceflingerConfigs para assuntos relacionados a surfaceflinger os itens de configuração e IBluetoothConfigs para recursos de Bluetooth itens de configuração.