AIDL estável

O Android 10 adiciona suporte à Linguagem de definição de interface do Android (AIDL) estável, uma nova maneira de acompanhar a interface de programação do aplicativo (API) e a interface binária do aplicativo (ABI) fornecida pelas interfaces AIDL. A AIDL estável funciona exatamente como a AIDL, mas o sistema de build acompanha a compatibilidade da interface, e há restrições sobre o que pode ser feito:

• As interfaces são definidas no sistema de build com aidl_interfaces.
• As interfaces só podem conter dados estruturados. Os parceláveis que representam os tipos preferidos são criados automaticamente com base na definição do AIDL e são marshalled e unmarshalled automaticamente.
• As interfaces podem ser declaradas como estáveis (compatíveis com versões anteriores). Quando isso acontece, a API é rastreada e controlada em um arquivo ao lado da interface AIDL.

AIDL estruturada x estável

AIDL estruturado se refere a tipos definidos puramente no AIDL. Por exemplo, uma declaração parcelável (um parcelable personalizado) não é uma AIDL estruturada. Os Parcelables com os campos definidos na AIDL são chamados de parcelas estruturadas (link em inglês).

A AIDL estável requer AIDL estruturada para que o sistema de build e o compilador possam entender se as mudanças feitas em parcelables são compatíveis com versões anteriores. No entanto, nem todas as interfaces estruturadas são estáveis. Para ser estável, uma interface precisa usar apenas tipos estruturados, além dos seguintes recursos de controle de versão. Por outro lado, uma interface não é estável se o sistema de build principal for usado para criá-la ou se unstable:true estiver definido.

Definir uma interface AIDL

Uma definição de aidl_interface tem esta aparência:

aidl_interface {
    name: "my-aidl",
    srcs: ["srcs/aidl/**/*.aidl"],
    local_include_dir: "srcs/aidl",
    imports: ["other-aidl"],
    versions_with_info: [
        {
            version: "1",
            imports: ["other-aidl-V1"],
        },
        {
            version: "2",
            imports: ["other-aidl-V3"],
        }
    ],
    stability: "vintf",
    backend: {
        java: {
            enabled: true,
            platform_apis: true,
        },
        cpp: {
            enabled: true,
        },
        ndk: {
            enabled: true,
        },
        rust: {
            enabled: true,
        },
    },

}

• name: o nome do módulo de interface AIDL que identifica exclusivamente uma interface AIDL.
• srcs: a lista de arquivos de origem AIDL que compõem a interface. O caminho de um tipo Foo AIDL definido em um pacote com.acme precisa estar em <base_path>/com/acme/Foo.aidl, em que <base_path> pode ser qualquer diretório relacionado ao diretório em que Android.bp está. No exemplo anterior, <base_path> é srcs/aidl.
• local_include_dir: o caminho de onde o nome do pacote começa. Ele corresponde a <base_path> explicado acima.
• imports: uma lista de módulos aidl_interface usados. Se uma das suas interfaces AIDL usar uma interface ou um parcelável de outra aidl_interface, coloque o nome dela aqui. Ele pode ser o nome sozinho, para se referir à versão mais recente, ou o nome com o sufixo de versão (como -V1) para se referir a uma versão específica. A especificação de uma versão é compatível desde o Android 12.
• versions: as versões anteriores da interface que estão congeladas em api_dir, a partir do Android 11, versions são congeladas em aidl_api/name. Se não houver versões congeladas de uma interface, isso não será especificado e não haverá verificações de compatibilidade. Esse campo foi substituído por versions_with_info no Android 13 e versões mais recentes.
• versions_with_info: lista de tuplas, cada uma contendo o nome de uma versão congelada e uma lista com importações de versão de outros módulos aidl_interface que essa versão do aidl_interface importou. A definição da versão V de uma interface AIDL IFACE está localizada em aidl_api/IFACE/V. Esse campo foi introduzido no Android 13 e não deve ser modificado diretamente em Android.bp. O campo é adicionado ou atualizado invocando *-update-api ou *-freeze-api. Além disso, os campos versions são migrados automaticamente para versions_with_info quando um usuário invoca *-update-api ou *-freeze-api.
• stability: a sinalização opcional para a promessa de estabilidade dessa interface. Isso é compatível apenas com "vintf". Se stability não estiver definido, o sistema de build vai verificar se a interface é compatível com versões anteriores, a menos que unstable seja especificado. Ser desativado corresponde a uma interface com estabilidade dentro deste contexto de compilação (ou seja, todas as coisas do sistema, por exemplo, as coisas em system.img e partições relacionadas ou todas as coisas do fornecedor, por exemplo, as coisas em vendor.img e partições relacionadas). Se stability for definido como "vintf", isso corresponde a uma promessa de estabilidade: a interface precisa ser mantida estável enquanto for usada.
• gen_trace: a flag opcional para ativar ou desativar o rastreamento. No Android 14 e versões mais recentes, o padrão é true para os back-ends cpp e java.
• host_supported: a sinalização opcional que, quando definida como true, disponibiliza as bibliotecas geradas para o ambiente do host.
• unstable: a flag opcional usada para marcar que essa interface não precisa ser estável. Quando esse valor é definido como true, o sistema de build não cria o despejo de API para a interface nem exige que ela seja atualizada.
• frozen: a sinalização opcional que, quando definida como true, significa que a interface não terá alterações desde a versão anterior. Isso permite mais verificações no tempo de build. Quando definido como false, significa que a interface está em desenvolvimento e tem novas mudanças. Portanto, executar foo-freeze-api gera uma nova versão e muda automaticamente o valor para true. Introduzido no Android 14.
• backend.<type>.enabled: essas sinalizações alternam cada um dos back-ends para os quais o compilador da AIDL gera código. Há suporte para quatro back-ends: Java, C++, NDK e Rust. Os back-ends Java, C++ e NDK são ativados por padrão. Se algum desses três back-ends não for necessário, ele precisará ser desativado explicitamente. O Rust fica desativado por padrão até o Android 15.
• backend.<type>.apex_available: a lista de nomes APEX para os quais a biblioteca de stubs gerada está disponível.
• backend.[cpp|java].gen_log: a flag opcional que controla se é necessário gerar um código adicional para coletar informações sobre a transação.
• backend.[cpp|java].vndk.enabled: a flag opcional para tornar essa interface parte do VNDK. O padrão é false.
• backend.[cpp|ndk].additional_shared_libraries: introduzida no Android 14, essa flag adiciona dependências às bibliotecas nativas. Essa flag é útil com ndk_header e cpp_header.
• backend.java.sdk_version: a sinalização opcional para especificar a versão do SDK em que a biblioteca de stubs Java é criada. O padrão é "system_current". Não defina quando backend.java.platform_apis for true.
• backend.java.platform_apis: flag opcional que precisa ser definida como true quando as bibliotecas geradas precisam ser criadas com base na API da plataforma em vez do SDK.

Para cada combinação de versões e back-ends ativados, uma biblioteca stub é criada. Para saber como se referir à versão específica da biblioteca de stub para um back-end específico, consulte Regras de nomenclatura de módulos.

Gravar arquivos AIDL

As interfaces na AIDL estável são semelhantes às interfaces tradicionais, com a exceção de que elas não podem usar parcelables não estruturados, porque elas não são estáveis. Consulte AIDL estruturada x estável. A principal diferença na AIDL estável é a forma como as parcelas são definidas. Anteriormente, os parcelables eram declarados com antecedência. Na AIDL estável (e, portanto, estruturada), os campos e variáveis parceláveis são definidos explicitamente.

// in a file like 'some/package/Thing.aidl'
package some.package;

parcelable SubThing {
    String a = "foo";
    int b;
}

Um padrão é aceito (mas não obrigatório) para boolean, char, float, double, byte, int, long e String. No Android 12, os padrões para enumerações definidas pelo usuário também têm suporte. Quando um padrão não é especificado, um valor vazio ou semelhante a 0 é usado. As enumerações sem um valor padrão são inicializadas como 0, mesmo que não haja um enumerador zero.

Usar bibliotecas de stubs

Depois de adicionar bibliotecas de stub como dependência ao seu módulo, você poderá incluí-las nos seus arquivos. Confira exemplos de bibliotecas de stubs no sistema de build (Android.mk também pode ser usado para definições de módulos legados):

cc_... {
    name: ...,
    shared_libs: ["my-module-name-cpp"],
    ...
}
# or
java_... {
    name: ...,
    // can also be shared_libs if your preference is to load a library and share
    // it among multiple users or if you only need access to constants
    static_libs: ["my-module-name-java"],
    ...
}
# or
rust_... {
    name: ...,
    rustlibs: ["my-module-name-rust"],
    ...
}

Exemplo em C++:

#include "some/package/IFoo.h"
#include "some/package/Thing.h"
...
    // use just like traditional AIDL

Exemplo em Java:

import some.package.IFoo;
import some.package.Thing;
...
    // use just like traditional AIDL

Exemplo em Rust:

use aidl_interface_name::aidl::some::package::{IFoo, Thing};
...
    // use just like traditional AIDL

Interfaces de controle de versão

Declarar um módulo com o nome foo também cria um destino no sistema de build que pode ser usado para gerenciar a API do módulo. Quando criado, o foo-freeze-api adiciona uma nova definição de API em api_dir ou aidl_api/name, dependendo da versão do Android, e adiciona um arquivo .hash, ambos representando a versão recém-congelada da interface. O foo-freeze-api também atualiza a propriedade versions_with_info para refletir a versão adicional e imports para a versão. Basicamente, imports em versions_with_info é copiado do campo imports. No entanto, a versão estável mais recente é especificada em imports em versions_with_info para a importação, que não tem uma versão explícita. Depois que a propriedade versions_with_info é especificada, o sistema de build executa verificações de compatibilidade entre versões congeladas e também entre a árvore principal (ToT, na sigla em inglês) e a versão congelada mais recente.

Além disso, você precisa gerenciar a definição da API da versão do ToT. Sempre que uma API for atualizada, execute foo-update-api para atualizar aidl_api/name/current, que contém a definição da API da versão ToT.

Para manter a estabilidade de uma interface, os proprietários podem adicionar:

• Métodos para o fim de uma interface (ou métodos com novos sequências explicitamente definidos)
• Elementos no final de um parcelável (requer que um padrão seja adicionado para cada elemento)
• Valores constantes
• No Android 11, os enumeradores
• No Android 12, os campos no final de uma união

Nenhuma outra ação é permitida, e ninguém mais pode modificar uma interface. Caso contrário, há o risco de colisão com alterações feitas por um proprietário.

Para testar se todas as interfaces estão congeladas para lançamento, é possível criar com as seguintes variáveis de ambiente definidas:

• AIDL_FROZEN_REL=true m ...: o build exige que todas as interfaces estáveis da AIDL sejam congeladas e não tenham um campo owner: especificado.
• AIDL_FROZEN_OWNERS="aosp test": o build exige que todas as interfaces AIDL estáveis sejam congeladas com o campo owner: especificado como "aosp" ou "test".

Estabilidade das importações

A atualização das versões de importações para versões congeladas de uma interface é compatível com versões anteriores na camada da AIDL estável. No entanto, isso exige a atualização de todos os servidores e clientes que usam uma versão anterior da interface, e alguns apps podem ficar confusos ao misturar diferentes versões de tipos. Em geral, para pacotes comuns ou somente tipos, isso é seguro, porque o código precisa ser escrito para processar tipos desconhecidos de transações de IPC.

No código da plataforma Android, android.hardware.graphics.common é o maior exemplo desse tipo de upgrade de versão.

Usar interfaces com controle de versões

Métodos de interface

No momento da execução, ao tentar chamar novos métodos em um servidor antigo, os novos clientes recebem um erro ou uma exceção, dependendo do back-end.

• O back-end cpp recebe ::android::UNKNOWN_TRANSACTION.
• O back-end ndk recebe STATUS_UNKNOWN_TRANSACTION.
• O back-end java recebe android.os.RemoteException com uma mensagem informando que a API não está implementada.

Para saber mais sobre estratégias para lidar com isso, consulte consultar versões e como usar os padrões.

Parcelables

Quando novos campos são adicionados a parceláveis, os clientes e servidores antigos os descartam. Quando novos clientes e servidores recebem parceláveis antigos, os valores padrão dos novos campos são preenchidos automaticamente. Isso significa que os padrões precisam ser especificados para todos os novos campos em um parcelável.

Os clientes não devem esperar que os servidores usem os novos campos, a menos que saibam que o servidor está implementando a versão que tem o campo definido (consulte consultar versões).

Tipos enumerados e constantes

Da mesma forma, clientes e servidores precisam rejeitar ou ignorar enumeradores e valores constantes não reconhecidos, conforme apropriado, já que mais podem ser adicionados no futuro. Por exemplo, um servidor não deve ser abortado quando recebe um enumerador que ele não conhece. O servidor precisa ignorar o enumerador ou retornar algo para que o cliente saiba que ele não tem suporte nesta implementação.

Sindicatos

A tentativa de enviar uma união com um novo campo falha se o receptor for antigo e não conhecer o campo. A implementação nunca vai encontrar a união com o novo campo. A falha será ignorada se for uma transação unidirecional. Caso contrário, o erro será BAD_VALUE(para o back-end do C++ ou NDK) ou IllegalArgumentException(para o back-end do Java). O erro é recebido se o cliente estiver enviando um conjunto de união para o novo campo em um servidor antigo ou quando for um cliente antigo recebendo a união de um novo servidor.

Gerenciar várias versões

Um namespace do vinculador no Android pode ter apenas uma versão de uma interface aidl específica para evitar situações em que os tipos de aidl gerados têm várias definições. O C++ tem a regra de uma definição, que exige apenas uma definição de cada símbolo.

O build do Android gera um erro quando um módulo depende de versões diferentes da mesma biblioteca aidl_interface. O módulo pode depender dessas bibliotecas diretamente ou indiretamente por dependências das dependências. Esses erros mostram o gráfico de dependência do módulo com falha para as versões em conflito da biblioteca aidl_interface. Todas as dependências precisam ser atualizadas para incluir a mesma versão (geralmente a mais recente) dessas bibliotecas.

Se a biblioteca de interface for usada por muitos módulos diferentes, pode ser útil criar cc_defaults, java_defaults e rust_defaults para qualquer grupo de bibliotecas e processos que precisem usar a mesma versão. Ao introduzir uma nova versão da interface, esses padrões podem ser atualizados e todos os módulos que os utilizam são atualizados juntos, garantindo que não usem versões diferentes da interface.

cc_defaults {
  name: "my.aidl.my-process-group-ndk-shared",
  shared_libs: ["my.aidl-V3-ndk"],
  ...
}

cc_library {
  name: "foo",
  defaults: ["my.aidl.my-process-group-ndk-shared"],
  ...
}

cc_binary {
  name: "bar",
  defaults: ["my.aidl.my-process-group-ndk-shared"],
  ...
}

Quando os módulos aidl_interface importam outros módulos aidl_interface, isso cria outras dependências que exigem que versões específicas sejam usadas juntas. Essa situação pode se tornar difícil de gerenciar quando há módulos aidl_interface comuns importados em vários módulos aidl_interface usados juntos nos mesmos processos.

aidl_interfaces_defaults pode ser usado para manter uma definição das versões mais recentes das dependências para uma aidl_interface que pode ser atualizada em um único local e usada por todos os módulos aidl_interface que querem importar essa interface comum.

aidl_interface_defaults {
  name: "android.popular.common-latest-defaults",
  imports: ["android.popular.common-V3"],
  ...
}

aidl_interface {
  name: "android.foo",
  defaults: ["my.aidl.latest-ndk-shared"],
  ...
}

aidl_interface {
  name: "android.bar",
  defaults: ["my.aidl.latest-ndk-shared"],
  ...
}

Desenvolvimento com base em sinalizações

Interfaces em desenvolvimento (descongeladas) não podem ser usadas em dispositivos de lançamento porque não têm compatibilidade com versões anteriores.

O AIDL oferece suporte ao substituto de execução para essas bibliotecas de interface descongeladas para que o código seja escrito de acordo com a versão descongelada mais recente e ainda seja usado em dispositivos de lançamento. O comportamento compatível com versões anteriores dos clientes é semelhante ao comportamento atual, e com o substituto, as implementações também precisam seguir esses comportamentos. Consulte Usar interfaces com controle de versão.

Sinalização de build da AIDL

A sinalização que controla esse comportamento é RELEASE_AIDL_USE_UNFROZEN definida em build/release/build_flags.bzl. true significa que a versão descongelada da interface é usada no tempo de execução, e false significa que as bibliotecas das versões descongeladas se comportam como a última versão congelada. É possível substituir a flag para true para desenvolvimento local, mas ela precisa ser revertida para false antes do lançamento. Normalmente, o desenvolvimento é feito com uma configuração que tem a flag definida como true.

Matriz de compatibilidade e manifestos

Os objetos da interface do fornecedor (objetos VINTF) definem quais versões são esperadas e quais são fornecidas em ambos os lados da interface do fornecedor.

A maioria dos dispositivos que não são do Cuttlefish tem como alvo a matriz de compatibilidade mais recente apenas depois que as interfaces são congeladas. Portanto, não há diferença nas bibliotecas AIDL baseadas em RELEASE_AIDL_USE_UNFROZEN.

Matrizes

As interfaces pertencentes ao parceiro são adicionadas às matrizes de compatibilidade específicas do dispositivo ou do produto que o dispositivo segmenta durante o desenvolvimento. Portanto, quando uma versão nova e descongelada de uma interface é adicionada a uma matriz de compatibilidade, as versões congeladas anteriores precisam permanecer para RELEASE_AIDL_USE_UNFROZEN=false. Para isso, use arquivos de matriz de compatibilidade diferentes para diferentes configurações de RELEASE_AIDL_USE_UNFROZEN ou permita as duas versões em um único arquivo de matriz de compatibilidade usado em todas as configurações.

Por exemplo, ao adicionar uma versão 4 descongelada, use <version>3-4</version>.

Quando a versão 4 estiver congelada, você poderá remover a versão 3 da matriz de compatibilidade porque a versão 4 congelada será usada quando RELEASE_AIDL_USE_UNFROZEN for false.

Manifestos

No Android 15, uma mudança em libvintf foi introduzida para modificar os arquivos de manifesto no momento da build com base no valor de RELEASE_AIDL_USE_UNFROZEN.

Os manifestos e os fragmentos declaram qual versão de uma interface um serviço implementa. Ao usar a versão descongelada mais recente de uma interface, o manifesto precisa ser atualizado para refletir essa nova versão. Quando RELEASE_AIDL_USE_UNFROZEN=false, as entradas do manifesto são ajustadas por libvintf para refletir a mudança na biblioteca AIDL gerada. A versão é modificada da versão descongelada, N, para a última versão congelada N - 1. Portanto, os usuários não precisam gerenciar vários manifestos ou fragmentos de manifesto para cada um dos serviços.

Mudanças no cliente HAL

O código do cliente HAL precisa ser compatível com versões anteriores congeladas anteriores. Quando RELEASE_AIDL_USE_UNFROZEN é false, os serviços sempre parecem a última versão congelada ou anterior. Por exemplo, chamar novos métodos descongelados retorna UNKNOWN_TRANSACTION, ou novos campos parcelable têm os valores padrão. Os clientes do framework do Android precisam ser compatíveis com versões anteriores, mas esse é um novo detalhe para clientes de fornecedores e clientes de interfaces de propriedade de parceiros.

Mudanças na implementação da HAL

A maior diferença no desenvolvimento de HAL com o desenvolvimento baseado em sinalizações é a exigência de que as implementações de HAL sejam compatíveis com versões anteriores da última versão congelada para funcionar quando RELEASE_AIDL_USE_UNFROZEN for false. Considerar a compatibilidade com versões anteriores nas implementações e no código do dispositivo é um novo exercício. Consulte Usar interfaces com versão.

As considerações de compatibilidade com versões anteriores geralmente são as mesmas para os clientes e servidores e para o código do framework e do fornecedor, mas há diferenças sutis que você precisa conhecer, já que agora você está implementando duas versões que usam o mesmo código-fonte (a versão atual, não congelada).

Exemplo: uma interface tem três versões congeladas. A interface é atualizada com um novo método. O cliente e o serviço são atualizados para usar a nova biblioteca da versão 4. Como a biblioteca V4 é baseada em uma versão descongelada da interface, ela se comporta como a última versão congelada, a versão 3, quando RELEASE_AIDL_USE_UNFROZEN é false e impede o uso do novo método.

Quando a interface é congelada, todos os valores de RELEASE_AIDL_USE_UNFROZEN usam essa versão congelada, e o código que processa a compatibilidade com versões anteriores pode ser removido.

Ao chamar métodos em callbacks, é necessário processar o caso em que UNKNOWN_TRANSACTION é retornado. Os clientes podem estar implementando duas versões diferentes de um callback com base na configuração de lançamento. Portanto, não presume-se que o cliente envia a versão mais recente, e novos métodos podem retornar essa versão. Isso é semelhante à maneira como os clientes da AIDL estáveis mantêm a compatibilidade com versões anteriores dos servidores descrita em Usar interfaces com controle de versões.

// Get the callback along with the version of the callback
ScopedAStatus RegisterMyCallback(const std::shared_ptr<IMyCallback>& cb) override {
    mMyCallback = cb;
    // Get the version of the callback for later when we call methods on it
    auto status = mMyCallback->getInterfaceVersion(&mMyCallbackVersion);
    return status;
}

// Example of using the callback later
void NotifyCallbackLater() {
  // From the latest frozen version (V2)
  mMyCallback->foo();
  // Call this method from the unfrozen V3 only if the callback is at least V3
  if (mMyCallbackVersion >= 3) {
    mMyCallback->bar();
  }
}

Novos campos em tipos existentes (parcelable, enum, union) podem não existir ou conter os valores padrão quando RELEASE_AIDL_USE_UNFROZEN é false e os valores de novos campos que um serviço tenta enviar são descartados no processo.

Os novos tipos adicionados nessa versão descongelada não podem ser enviados ou recebidos pela interface.

A implementação nunca recebe uma chamada para novos métodos de clientes quando RELEASE_AIDL_USE_UNFROZEN é false.

Use os novos enumeradores apenas com a versão em que foram introduzidos, e não com a versão anterior.

Normalmente, você usa foo->getInterfaceVersion() para saber qual versão a interface remota está usando. No entanto, com o suporte de controle de versão baseado em sinalizadores, você está implementando duas versões diferentes. Portanto, é recomendável receber a versão da interface atual. Para fazer isso, confira a versão da interface do objeto atual, por exemplo, this->getInterfaceVersion() ou os outros métodos de my_ver. Consulte Como consultar a versão da interface do objeto remoto para mais informações.

Novas interfaces estáveis do VINTF

Quando um novo pacote de interface da AIDL é adicionado, não há uma última versão congelada. Portanto, não há um comportamento alternativo quando RELEASE_AIDL_USE_UNFROZEN é false. Não use essas interfaces. Quando RELEASE_AIDL_USE_UNFROZEN é false, o Service Manager não permite que o serviço registre a interface e os clientes não a encontram.

É possível adicionar os serviços de forma condicional com base no valor da flag RELEASE_AIDL_USE_UNFROZEN no makefile do dispositivo:

ifeq ($(RELEASE_AIDL_USE_UNFROZEN),true)
PRODUCT_PACKAGES += \
    android.hardware.health.storage-service
endif

Se o serviço fizer parte de um processo maior e não puder ser adicionado ao dispositivo de forma condicional, verifique se ele foi declarado com IServiceManager::isDeclared(). Se ele for declarado e não conseguir se registrar, interrompa o processo. Se não for declarado, o registro não vai ser feito.

Cuttlefish como ferramenta de desenvolvimento

Todos os anos, depois que o VINTF é congelado, ajustamos a matriz de compatibilidade de framework (FCM) target-level e o PRODUCT_SHIPPING_API_LEVEL do Cuttlefish para que reflitam os dispositivos lançados com a versão do ano que vem. Ajustamos target-level e PRODUCT_SHIPPING_API_LEVEL para garantir que haja algum dispositivo de lançamento testado e que atenda aos novos requisitos para a versão do próximo ano.

Quando RELEASE_AIDL_USE_UNFROZEN é true, o Cuttlefish é usado para o desenvolvimento de futuras versões do Android. Ele é destinado ao nível do FCM e ao PRODUCT_SHIPPING_API_LEVEL da versão do Android do próximo ano, exigindo que ele satisfaça os requisitos de software do fornecedor (VSR, na sigla em inglês) da próxima versão.

Quando RELEASE_AIDL_USE_UNFROZEN é false, o Cuttlefish tem o target-level anterior e o PRODUCT_SHIPPING_API_LEVEL para refletir um dispositivo de lançamento. No Android 14 e versões anteriores, essa diferenciação seria realizada com diferentes ramificações do Git que não detectam a mudança no target-level do FCM, no nível da API de envio ou em qualquer outro código destinado à próxima versão.

Regras de nomenclatura de módulos

No Android 11, para cada combinação de versões e backends ativados, um módulo de biblioteca de rascunho é criado automaticamente. Para se referir a um módulo de biblioteca de stubs específico para vinculação, não use o nome do módulo aidl_interface, mas sim o nome do módulo da biblioteca de stubs, que é ifacename-version-backend, em que

• ifacename: nome do módulo aidl_interface
• version é um dos
  • Vversion-number para as versões congeladas
  • Vlatest-frozen-version-number + 1 para a versão da ponta da árvore (ainda não congelada)
• backend é um dos
  • java para o back-end Java,
  • cpp para o back-end de C++;
  • ndk ou ndk_platform para o back-end do NDK. O primeiro é para apps e o último é para uso da plataforma até o Android 13. No Android 13 e versões mais recentes, use apenas ndk.
  • rust para o back-end do Rust.

Suponha que haja um módulo com o nome foo, que a versão mais recente dele seja 2 e que ele seja compatível com NDK e C++. Nesse caso, a AIDL gera estes módulos:

• Com base na versão 1
  • foo-V1-(java|cpp|ndk|ndk_platform|rust)
• Com base na versão 2 (a versão estável mais recente)
  • foo-V2-(java|cpp|ndk|ndk_platform|rust)
• Com base na versão do ToT
  • foo-V3-(java|cpp|ndk|ndk_platform|rust)

Em comparação com o Android 11:

• foo-backend, que faz referência à versão estável mais recente, se torna foo-V2-backend.
• foo-unstable-backend, que se referia à versão do ToT, passa a ser foo-V3-backend

Os nomes dos arquivos de saída são sempre iguais aos nomes dos módulos.

• Com base na versão 1: foo-V1-(cpp|ndk|ndk_platform|rust).so
• Com base na versão 2: foo-V2-(cpp|ndk|ndk_platform|rust).so
• Com base na versão do ToT: foo-V3-(cpp|ndk|ndk_platform|rust).so

Observe que o compilador AIDL não cria um módulo de versão unstable nem um módulo sem controle de versão para uma interface AIDL estável. No Android 12 e versões mais recentes, o nome do módulo gerado em uma interface AIDL estável sempre inclui a versão.

Novos métodos de metainterface

O Android 10 adiciona vários métodos de metainterface para a AIDL estável.

Consultar a versão da interface do objeto remoto

Os clientes podem consultar a versão e o hash da interface que o objeto remoto está implementando e comparar os valores retornados com os valores da interface que o cliente está usando.

Exemplo com o back-end cpp:

sp<IFoo> foo = ... // the remote object
int32_t my_ver = IFoo::VERSION;
int32_t remote_ver = foo->getInterfaceVersion();
if (remote_ver < my_ver) {
  // the remote side is using an older interface
}

std::string my_hash = IFoo::HASH;
std::string remote_hash = foo->getInterfaceHash();

Exemplo com o back-end ndk (e ndk_platform):

IFoo* foo = ... // the remote object
int32_t my_ver = IFoo::version;
int32_t remote_ver = 0;
if (foo->getInterfaceVersion(&remote_ver).isOk() && remote_ver < my_ver) {
  // the remote side is using an older interface
}

std::string my_hash = IFoo::hash;
std::string remote_hash;
foo->getInterfaceHash(&remote_hash);

Exemplo com o back-end java:

IFoo foo = ... // the remote object
int myVer = IFoo.VERSION;
int remoteVer = foo.getInterfaceVersion();
if (remoteVer < myVer) {
  // the remote side is using an older interface
}

String myHash = IFoo.HASH;
String remoteHash = foo.getInterfaceHash();

Para a linguagem Java, o lado remoto PRECISA implementar getInterfaceVersion() e getInterfaceHash() da seguinte maneira: super é usado em vez de IFoo para evitar erros de cópia e colagem. A anotação @SuppressWarnings("static") pode ser necessária para desativar os avisos, dependendo da configuração javac:

class MyFoo extends IFoo.Stub {
    @Override
    public final int getInterfaceVersion() { return super.VERSION; }

    @Override
    public final String getInterfaceHash() { return super.HASH; }
}

Isso ocorre porque as classes geradas (IFoo, IFoo.Stub etc.) são compartilhadas entre o cliente e o servidor. Por exemplo, as classes podem estar no caminho de classe de inicialização. Quando as classes são compartilhadas, o servidor também é vinculado à versão mais recente das classes, mesmo que ele possa ter sido criado com uma versão mais antiga da interface. Se essa metainterface for implementada na classe compartilhada, ela sempre retornará a versão mais recente. No entanto, ao implementar o método como acima, o número da versão da interface é incorporado ao código do servidor porque IFoo.VERSION é um static final int inline quando referenciado. Assim, o método pode retornar a versão exata com que o servidor foi criado.

Lidar com interfaces mais antigas

É possível que um cliente seja atualizado com a versão mais recente de uma interface AIDL, mas o servidor esteja usando a interface AIDL antiga. Nesses casos, chamar um método em uma interface antiga retorna UNKNOWN_TRANSACTION.

Com o AIDL estável, os clientes têm mais controle. No lado do cliente, é possível definir uma implementação padrão para uma interface AIDL. Um método na implementação padrão é invocado apenas quando o método não está implementado no lado remoto (porque foi criado com uma versão mais antiga da interface). Como os padrões são definidos globalmente, eles não podem ser usados em contextos potencialmente compartilhados.

Exemplo em C++ no Android 13 e versões mais recentes:

class MyDefault : public IFooDefault {
  Status anAddedMethod(...) {
   // do something default
  }
};

// once per an interface in a process
IFoo::setDefaultImpl(::android::sp<MyDefault>::make());

foo->anAddedMethod(...); // MyDefault::anAddedMethod() will be called if the
                         // remote side is not implementing it

Observação: antes do Android 13, o IFoo::setDefaultImpl recebia um std::unique_ptr<IFoo> em vez de ::android::sp<IFoo>.

Exemplo em Java:

IFoo.Stub.setDefaultImpl(new IFoo.Default() {
    @Override
    public xxx anAddedMethod(...)  throws RemoteException {
        // do something default
    }
}); // once per an interface in a process

foo.anAddedMethod(...);

Observação: em Java, setDefaultImpl está na classe Stub, não na classe interface.

Não é necessário fornecer a implementação padrão de todos os métodos em uma interface AIDL. Os métodos com garantia de implementação no lado remoto (porque você tem certeza de que o controle remoto é criado quando os métodos estavam na descrição da interface AIDL) não precisam ser substituídos na classe impl padrão.

Observação: a implementação padrão não é usada para chamadas de método unidirecional. Isso acontece porque não há como um cliente saber se o controle remoto tem o método e se ele foi executado ou não. Não há confirmação do lado remoto no caso de chamadas de método unidirecional.

Converter a AIDL atual em AIDL estruturada ou estável

Se você tiver uma interface e um código AIDL que a usam, siga as etapas a seguir para converter a interface em uma interface AIDL estável.

1. Identifique todas as dependências da interface. Para cada pacote do qual a interface depende, determine se o pacote é definido em AIDL estável. Se não for definido, o pacote precisará ser convertido.

2. Converta todos os parceláveis na interface em parceláveis estáveis. Os arquivos da interface podem permanecer inalterados. Para isso, expresse a estrutura diretamente nos arquivos AIDL. As classes de gerenciamento precisam ser reescritas para usar esses novos tipos. Isso pode ser feito antes de criar um pacote aidl_interface (abaixo).

3. Crie um pacote aidl_interface (conforme descrito acima) que contenha o nome do módulo, as dependências dele e todas as outras informações necessárias. Para estabilizar (não apenas estruturar) o código, ele também precisa ter uma versão. Para mais informações, consulte Controle de versões de interfaces.