Mecanismo de política de áudio configurável

No Android 14, o Android Automotive OS (AAOS) aproveita o gerenciamento de áudio do carro do mecanismo de política de áudio configurável (CAP, na sigla em inglês) na zona de áudio principal. Especificamente, o mecanismo CAP permite que o AAOS controle apenas o roteamento de áudio, apenas o volume de áudio ou o roteamento e o volume simultaneamente. As seguintes flags podem ser usadas para controlar o comportamento:

• Use a flag useCoreAudioVolume para ativar o gerenciamento de volume do CAP. Quando esse valor é true, o serviço de áudio do carro usa APIs de gerenciamento de áudio para gerenciar os grupos de volume.

• Use a flag useCoreAudioRouting para ativar o gerenciamento de roteamento de áudio do CAP. Quando esse valor é true, o serviço de áudio do carro usa o roteamento de política de áudio configurável para gerenciar o roteamento de áudio.

O mecanismo de política de áudio também tem suporte no Android por padrão na forma de mecanismo de política de áudio padrão.

Contexto

O mecanismo CAP é baseado no framework de parâmetros da Intel, que é um framework baseado em plug-ins e regras para processar parâmetros. Para o gerenciamento de áudio do Android em particular, o mecanismo CAP introduziu a capacidade de definir regras de arquivos XML para especificar o seguinte:

• Estratégia de produtos de áudio
• Regras para seleção de dispositivos de saída de áudio
• Regras para seleção de dispositivos de entrada de áudio
• Regras para gerenciar o volume e desativar o som com as tabelas de volume

Inicialização de CAP antes do Android 16

A figura a seguir mostra uma visão geral de alto nível do gerenciamento de configuração do mecanismo de política de áudio configurável no Android 6 e versões mais recentes:

Figura 1. Gerenciamento de configuração do mecanismo CAP a partir do Android 6.

Como mostrado na figura, a configuração do mecanismo CAP é obtida pelo serviço de política de áudio analisando as informações do arquivo audio_policy_engine_configuration.xml na partição vendor. O arquivo de configuração do mecanismo CAP usa o esquema definido em audio_policy_engine_configuration.xsd para receber as informações necessárias. audio_policy_engine_configuration.xml é um exemplo para o setor automotivo. Exemplos semelhantes para outros formatos estão na pasta frameworks/av/services/audiopolicy/engineconfigurable/config/example/.

A figura a seguir mostra informações mais detalhadas sobre como as informações configuráveis do mecanismo de política de áudio são carregadas no serviço de política de áudio. Nesse caso, o framework de parâmetro carrega a estrutura e as configurações dos arquivos XML.

Figura 2. Informações de CAP carregadas no serviço de política de áudio.

Arquivos de estrutura CAP no Android 15 e versões anteriores

Para conseguir a estrutura e as configurações, o serviço de política de áudio lê o arquivo ParameterFrameworkConfigurationPolicy.xml. Isso faz referência às informações da estrutura pelo local do arquivo de descrição da estrutura:

<StructureDescriptionFileLocation Path="Structure/Policy/PolicyClass.xml"/>

Isso aponta para informações estruturais no arquivo:

/vendor/etc/parameter-framework/Structure/Policy/PolicyClass.xml

Uma estrutura de esqueleto é fornecida no Android . As informações de estrutura exigem as informações de estrutura da estratégia de produto. Por isso, o Android fornece a ferramenta de geração buildStrategiesStructureFile.py, que pode gerar informações do arquivo XML da estratégia de produto disponível. Isso pode ser referenciado pelo genrule default buildstrategiesstructurerule da seguinte maneira:

genrule {
    name: "buildstrategiesstructure_gen",
    defaults: ["buildstrategiesstructurerule"],
    srcs: [
        ":audio_policy_engine_configuration_files",
    ],
}

Em que audio_policy_engine_configuration_files são os arquivos de configuração do mecanismo de política de áudio. Este exemplo para o setor automotivo faz referência aos arquivos de configuração da política de áudio na pasta automotiva. Outros exemplos mostram como configurar um build para enviar os arquivos na partição do fornecedor do dispositivo.

Arquivos de configuração do CAP no Android 15 e versões anteriores

Semelhante à estrutura, as informações de configuração, que representam regras e valores dos parâmetros, são referenciadas no arquivo ParameterFrameworkConfigurationPolicy.xml como:

<SettingsConfiguration>
  <ConfigurableDomainsFileLocation Path="Settings/Policy/PolicyConfigurableDomains.xml"/>
</SettingsConfiguration>

O Android também fornece ferramentas de build para gerar essas informações usando a configuração do mecanismo de política de áudio e os arquivos de framework de parâmetro. Consulte Configurações para mais informações.

Inicialização da CAP da HAL de áudio AIDL

A partir do Android 16, a definição da API AIDL Audio HAL é expandida com as configurações do mecanismo de política de áudio, AudioHalCapConfiguration.aidl. A figura a seguir mostra uma visão geral de alto nível do gerenciamento de configuração do motor CAP no Android 16:

Figura 3. Gerenciamento de configuração do mecanismo CAP a partir do Android 16.

O serviço de política de áudio extrai as informações do mecanismo CAP usando as APIs HAL de áudio AIDL diretamente, em vez de analisar as informações de arquivos XML na partição do fornecedor do dispositivo.

Nessa configuração, a estrutura do parâmetro ainda é carregada pelo mecanismo CAP no lado do servidor de áudio.

Figura 4. Estrutura do mecanismo CAP.

Em todos os casos, a configuração precisa especificar totalmente as informações relacionadas às estratégias de produto, aos grupos de volume e aos critérios.

A figura a seguir mostra uma visão geral de alto nível das APIs HAL de áudio AIDL que são usadas pelo serviço de política de áudio para receber a configuração do mecanismo CAP:

Figura 5. APIs HAL de áudio AIDL.

Nessa configuração, o serviço de política de áudio extrai as seguintes informações do HAL de áudio AIDL:

• Configuração
• Estratégias
• Volumes
• Critérios
• Configurações

Carregador HAL de áudio AIDL padrão

Para facilitar a transição de HIDL para AIDL, a HAL de áudio AIDL padrão oferece um carregador de mecanismo CAP XML. Os fornecedores podem usar esse carregador diretamente, estendendo o HAL de áudio com o HAL de áudio padrão ou referenciando a biblioteca libaudioserviceexampleimpl.

O carregador HAL de áudio AIDL padrão usa audio_policy_engine_configuration.xml para receber as seguintes informações:

• Configuração
• Estratégias
• Volumes
• Critérios

As informações da estrutura são obtidas do arquivo PolicyConfigurableDomains.xml. A principal diferença em relação ao mecanismo anterior é que as informações da estrutura também são obtidas pelo HAL de áudio AIDL em vez do framework de parâmetros no serviço de política de áudio.

O fornecedor pode usar a ferramenta domaingeneratorpolicyrule para gerar os domínios configuráveis usando as informações da configuração do mecanismo de política de áudio. O exemplo de dispositivo virtual Cuttlefish para automóveis pode ser usado como referência.

Estrutura na configuração da AIDL

No Android 16 e versões mais recentes, o serviço de política de áudio obtém as informações da estrutura lendo e analisando o arquivo ParameterFrameworkConfigurationCap.xml. Especificamente, ele extrai as informações do arquivo de descrição da estrutura:

<StructureDescriptionFileLocation Path="Structure/Policy/CapClass.xml"/>

O framework salva os arquivos necessários na pasta /etc/parameter-framework/ com as informações necessárias.

A estrutura representa os parâmetros que precisam ser controlados. Por isso, eles precisam ser referenciados na configuração ou nos domínios. Para isso, a configuração do mecanismo AIDL precisa usar um nome predeterminado para os parâmetros. Para as estratégias de produto, as estruturas são configuradas em CapProductStrategies.xml.

Estratégias de produto padrão

Começando com os padrões fornecidos no motor padrão, as estratégias de produto começam com o prefixo STRATEGY_:

• STRATEGY_PHONE
• STRATEGY_SONIFICATION
• STRATEGY_ENFORCED_AUDIBLE
• STRATEGY_ACCESSIBILITY
• STRATEGY_SONIFICATION_RESPECTFUL
• STRATEGY_MEDIA
• STRATEGY_DTMF
• STRATEGY_CALL_ASSISTANT
• STRATEGY_TRANSMITTED_THROUGH_SPEAKER

Esse formato foi fornecido para facilitar a transição de HIDL para AIDL em dispositivos que usavam estratégias padrão. Essa mudança de formato tem algumas implicações para os arquivos atuais (por exemplo, PfW, XML) usados para configurar o mecanismo. Em particular, todas as referências à estratégia do produto precisam ser alteradas para usar os novos nomes. Por exemplo:

Estratégias de produto definidas pelo OEM

O mecanismo configurável permite que os OEMs mudem a definição das estratégias de produto. Para continuar oferecendo suporte a isso, o arquivo de estratégia de produto CapProductStrategies.xml também fornece 40 estratégias de produto estendidas do fornecedor de vx_1000 a vx_1039 . Todas as extensões do fornecedor precisam começar com o prefixo vx_ e seguir com um número que represente o ID da estratégia do produto na definição da estratégia do produto HAL de áudio AIDL. O restante das definições (por exemplo, grupos de atributos de áudio, nome) são obtidas do objeto AudioHALProductStrategy na configuração do mecanismo HAL de áudio.

Assim como nas estratégias de produto padrão, as referências de OEMs definidas pelo fornecedor também precisam ser adaptadas entre a configuração não AIDL e a configuração AIDL, por exemplo:

Estratégias de produtos

As estratégias de produto oferecem uma maneira de personalizar como os streams de áudio são categorizados e agrupados. Isso permite maior flexibilidade na configuração de dispositivos de áudio, incluindo como eles são roteados e como os volumes são gerenciados. Cada estratégia de produto pode ter um ou mais grupos de atributo de áudio, que identificam os fluxos que precisam ser associados a essa estratégia. Esses grupos de atributos de áudio permitem uma abordagem mais granular para categorizar áudio e podem ser uma mistura dos seguintes tipos:

• Os tipos de uso descrevem por que um som está sendo reproduzido, por exemplo, mídia, notificação ou chamada.
• Os tipos de tipo de conteúdo descrevem o que está sendo reproduzido, ou seja, música, fala, vídeo, sonificação.
• Os tipos Flag definem comportamentos ou solicitações diferentes em relação ao fluxo.
• Os tipos Tags oferecem suporte a qualquer lista arbitrária de valores de string do fornecedor.
  • Cada string precisa começar com VX_ seguida por uma string alfanumérica (por exemplo, VX_OEM, VX_NAVIGATION).

<ProductStrategy name="music" id="1008">
    <AttributesGroup streamType="AUDIO_STREAM_MUSIC" volumeGroup="media">
        <Attributes> <Usage value="AUDIO_USAGE_MEDIA"/> </Attributes>
        <Attributes> <Usage value="AUDIO_USAGE_GAME"/> </Attributes>
        <!-- Default product strategy has empty attributes -->
        <Attributes></Attributes>
    </AttributesGroup>
</ProductStrategy>

Este trecho mostra um exemplo de estratégia de produto usada em emuladores de carro. Ele contém dois atributos de áudio com mídia de uso de áudio e jogo, respectivamente. Essa estratégia de produto corresponde ao contexto de áudio MUSIC usado no serviço de áudio do carro, mas não há um requisito para essa correspondência. Um dos principais utilitários para OEMs que usam o CAP com o Android é permitir definições de agrupamento de áudio mais flexíveis.

Grupos de volumes

Além disso, cada grupo de atributos de áudio precisa ter um grupo de volume associado. Esse grupo de volume é associado a qualquer stream que corresponda aos atributos de áudio pertencentes ao grupo de atributos de áudio. O exemplo de estratégia de produto de música na seção Estratégias de produto tem o grupo de volume media, e a definição do grupo de volume de mídia é a seguinte:

<volumeGroup>
    <name>media</name>
    <indexMin>0</indexMin>
    <indexMax>40</indexMax>
    <volume deviceCategory="DEVICE_CATEGORY_SPEAKER">
        <point>0,-2400</point>
        <point>33,-1600</point>
        <point>66,-800</point>
        <point>100,0</point>
    </volume>
</volumeGroup>

Nesta definição, o grupo de volumes contém:

• Nome do grupo
• Índice mínimo do grupo
• Índice máximo do grupo
• Curvas de grupo de volume

As curvas de grupo de volume contêm mapeamento pontual entre o índice do grupo de volume e o ganho de volume em milibels. Os pontos fornecidos são usados para interpolar linearmente o ganho de correspondência mais adequado quando o volume é gerenciado. Cada curva de grupo de volume é associada a uma categoria de tipo de dispositivo, por exemplo, fone de ouvido, alto-falante, mídia externa.

O grupo de volume gerencia o volume dos streams que fazem parte do grupo de atributos de áudio. Por exemplo, quando um stream com atributos de áudio contendo música ou jogo é iniciado, o último índice de volume definido para o grupo de volume de mídia é usado. Nesse caso, a curva de categoria de dispositivo correspondente é selecionada com base no dispositivo selecionado, e o ganho correspondente é definido quando o stream é iniciado.

Configurações

No mecanismo CAP, as configurações são usadas para definir as condições ou regras que determinam como o áudio deve se comportar. Essas configurações são avaliadas no momento da execução para selecionar as regras adequadas a ser aplicadas, dependendo do estado atual do sistema de áudio.

Conforme mostrado na Figura 5, a API contém vários domínios. O objetivo de cada domínio é dividir a lógica em problemas de roteamento menores para resolver (por exemplo, dispositivo 1, dispositivo 2).

Cada domínio tem configurações, e cada configuração tem um conjunto de regras. As regras são estabelecidas com base nos critérios fornecidos por AudioPolicyManager:

• Modo de áudio
• Dispositivos de entrada e saída disponíveis
• Endereços de dispositivos de entrada e saída disponíveis
• Usar para
  • Mídia
  • Comunicação
  • Gravando
  • Base
  • Sistema
  • Áudio do sistema HDMI
  • Som surround codificado
  • Vibrar ao tocar

Cada domínio contém configurações que determinam as regras que afetam o comportamento. A ordem das configurações é importante, e é necessário garantir que elas estejam na ordem necessária. Depois que as regras de uma configuração são validadas, ela é selecionada.

O código a seguir mostra um exemplo de extrato de um arquivo de parâmetro, que pode ser usado para gerar o arquivo XML necessário para configurar domínios configuráveis:

supDomain: DeviceForProductStrategies
  supDomain: Music
    domain: SelectedDevice
      conf: BluetoothA2dp
        ForceUseForMedia IsNot NO_BT_A2DP
        ForceUseForCommunication IsNot BT_SCO
        AvailableOutputDevices Includes BLUETOOTH_A2DP
        component:/Policy/policy/product_strategies/vx_1000/selected_output_devices/mask
          bluetooth_a2dp = 1
          bus = 0
      conf: Bus
        AvailableOutputDevices Includes Bus
        AvailableOutputDevicesAddresses Includes BUS00_MEDIA
        component: /Policy/policy/product_strategies/vx_1000/selected_output_devices/mask
          bluetooth_a2dp = 0
          bus = 1
      conf: Default
        component: /Policy/policy/product_strategies/vx_1000/selected_output_devices/mask
          bluetooth_a2dp = 0
          bus = 0

O domínio DeviceForProductStrategies define como regras diferentes devem ser aplicadas ao processar a seleção de dispositivos de estratégias de produtos. As partes azuis descrevem as regras que precisam ser consideradas, e a parte verde é a configuração aplicada. Este exemplo específico contém as seguintes configurações:

• Selecionar o dispositivo Bluetooth A2DP para a estratégia de produtos de música (ID 1000, vx_1000)
  • Se usado para mídia, não exclui A2DP
  • Se usado para comunicação, não é BT SCO
  • Se houver dispositivos disponíveis, inclua BT A2DP
• Selecione o dispositivo de barramento
  • Se os dispositivos de ônibus estiverem disponíveis
  • Se o endereço for BUS00_MEDIA
• Selecione o dispositivo de saída padrão

Para gerar o arquivo XML do mecanismo de política configurável correspondente, execute os arquivos de framework de parâmetros (PFW, na sigla em inglês) pelo sistema de build, definindo uma regra de build usando as seguintes etapas:

1. No arquivo Android.bp, crie um grupo de arquivos para o arquivo:

   filegroup {
       name: ":device_for_product_strategies.pfw",
       srcs: ["engine/parameter-framework/Settings/device_for_product_strategyies.pfw"],
   }
   

2. Adicione o arquivo a outros arquivos de PfW (se houver).

   filegroup {
       name: "edd_files",
       srcs: [
           ":device_for_input_source.pfw",
           ":volumes.pfw",
           ":device_for_product_strategyies.pfw",
       ],
   }
   

3. Crie a regra de geração de domínio correspondente:

   genrule {
       name: "domaingeneratorpolicyrule_gen",
       defaults: ["domaingeneratorpolicyrule"],
       srcs: [
           ":audio_policy_engine_criterion_types",
           ":audio_policy_pfw_structure_files",
           ":audio_policy_pfw_toplevel",
           ":edd_files",
       ],
   }
   

   Em que domaingeneratorpolicyrule é uma regra de geração fornecida pelo framework para gerar o arquivo PolicyConfigurableDomains.xml. Os outros arquivos de origem (scrs) incluídos nas regras de geração de domínio são os seguintes:

   Origem	Descrição
   audio_policy_pfw_toplevel	Arquivo de configuração do parâmetro de framework de nível superior.
   audio_policy_pfw_structure_files	Arquivos de estrutura de geração de domínio, que são usados para gerar os arquivos de configuração.
   audio_policy_engine_criterion_types	Tipos de critérios do arquivo XML, que descrevem os critérios usados durante a geração.
   edd_files	Lista de arquivos de domínio único (cada um contendo uma única tag <ConfigurableDomain>).

Depois de executar a regra de geração no build, o PolicyConfigurableDomains.xml é gerado com todos os domínios. Confira abaixo um trecho do arquivo gerado usando o exemplo de regras de PfW:

---ConfigurableDomain Name="DeviceForProductStrategies.Music.SelectedDevice"---
<Configurations>
  <Configuration Name="BluetoothA2dp">
    <CompoundRule Type="All">
      <SelectionCriterionRule SelectionCriterion="ForceUseForMedia" MatchesWhen="IsNot" Value="NO_BT_A2DP"/>
      <SelectionCriterionRule SelectionCriterion="ForceUseForCommunication" MatchesWhen="IsNot" Value="BT_SCO"/>
      <SelectionCriterionRule SelectionCriterion="AvailableOutputDevices" MatchesWhen="Includes" Value="BLUETOOTH_A2DP"/>
    </CompoundRule>
  </Configuration>
  <Configuration Name="Bus">
    <CompoundRule Type="All">
      <SelectionCriterionRule SelectionCriterion="AvailableOutputDevices" MatchesWhen="Includes" Value="BUS"/>
      <SelectionCriterionRule SelectionCriterion="AvailableOutputDevicesAddresses" MatchesWhen="Includes" Value="BUS00_MEDIA"/>
    </CompoundRule>
  </Configuration>
  <Configuration Name="Default">
    <CompoundRule Type="All"/>
  </Configuration>
</Configurations>

Depuração de CAP

É possível usar o remote-process para despejar as configurações do CAP:

adb root && adb remount
adb shell remote-process unix:///dev/socket/audioserver/policy_debug dumpDomains

Isso mostra todos os domínios e configurações, incluindo as condições de aplicabilidade. O exemplo a seguir mostra um trecho do dispositivo automotivo Cuttlefish usando o Bluetooth A2DP, o dispositivo de barramento e as configurações padrão. Consulte Configurações:

- ConfigurableDomain: DeviceForProductStrategies.Music.SelectedDevice =
 {Sequence aware: no, Last applied configuration: Bus}
  - Configuration: BluetoothA2dp
    - CompoundRule = All
      - SelectionCriterionRule = ForceUseForMedia IsNot NO_BT_A2DP
      - SelectionCriterionRule = ForceUseForCommunication IsNot BT_SCO
      - SelectionCriterionRule = AvailableOutputDevices Includes BLUETOOTH_A2DP
  - Configuration: Bus
    - CompoundRule = All
      - SelectionCriterionRule = AvailableOutputDevices Includes BUS
      - SelectionCriterionRule = AvailableOutputDevicesAddresses Includes BUS00_MEDIA_CARD_0_DEV_0
  - Configuration: Default
    - CompoundRule = All

Para mais informações sobre outros comandos disponíveis para depurar o framework de parâmetro CAP, use esta ferramenta:

adb shell remote-process unix:///dev/socket/audioserver/policy_debug help

Para usar a ferramenta, os fabricantes de OEM precisam permitir a sintonização no dispositivo. Para verificar se o dispositivo permite a sintonia, use o seguinte comando:

adb shell cat /system/etc/parameter-framework/ParameterFrameworkConfigurationCap.xml

No Android 15 e versões anteriores, o arquivo pode ser diferente. Use o seguinte comando:

adb shell cat /system/etc/parameter-framework/ParameterFrameworkConfigurationPolicy.xml

O arquivo precisa conter TuningAllowed="true" com a porta do servidor correspondente:

<?xml version="1.0" encoding="UTF-8"?>
<ParameterFrameworkConfiguration xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    SystemClassName="Policy" TuningAllowed="true" ServerPort="unix:///dev/socket/audioserver/policy_debug">
    <SubsystemPlugins>
        <Location Folder="">
            <Plugin Name="libpolicy-subsystem.so"/>
        </Location>
    </SubsystemPlugins>
    <StructureDescriptionFileLocation Path="Structure/Policy/CapClass.xml"/>
</ParameterFrameworkConfiguration>

Esse arquivo é gerado automaticamente de acordo com o tipo de imagem de build. Use um arquivo diferente para lançamento ou depuração para build legado. Um build de lançamento define TuningAllowed como false sem uma porta de soquete (os soquetes são proibidos para isso em builds de lançamento). As construções de engenharia e userdebug definem o valor como true com a porta de soquete usada. Esse é o arquivo referenciado pelo audio_policy_pfw_toplevel. A ferramenta de processo remoto também precisa ser incluída no arquivo de build ou make do dispositivo:

# Tool used for debug Parameter Framework (only for eng and userdebug builds)
PRODUCT_PACKAGES_DEBUG += remote-process

A política do SELinux correspondente para permitir soquetes também precisa ser incluída. Isso funciona apenas para o modo de depuração, porque o modo de lançamento não permite sockets explicitamente:

BOARD_SEPOLICY_DIRS += frameworks/av/services/audiopolicy/engineconfigurable/sepolicy

Migração de CAP no Android 16

Considerando as principais mudanças trazidas pelo mecanismo HAL CAP de áudio AIDL e versões anteriores, há vários cenários de transição de dispositivo que você precisa considerar. Esta seção aborda os cenários de transição mais importantes e oferece recomendações para ativar a configuração do mecanismo CAP.

Cenário 1: novo dispositivo usando o Android 16 ou mais recente, sem origem anterior para a configuração do CAP do dispositivo

Um novo dispositivo precisa ser iniciado com o código do Android 16 ou mais recente na partição vendor. Isso significa que ele precisa expor a configuração configurável do mecanismo de política de áudio pela interface HAL de áudio AIDL. A configuração do motor de CAP do dispositivo precisa ser copiada dos exemplos. Não deve haver uma definição de domínio de CAP de PfW na partição vendor.

A imagem do sistema usada para o dispositivo é o Android 16 ou mais recente. O framework de serviço de áudio descobre a configuração do CAP pela interface HAL de áudio AIDL. Assim, ele inicializa o PfW usando a definição de domínio CAP do PfW da imagem do sistema e carrega a configuração do CAP do dispositivo recebida pela AIDL.

Para conferir um exemplo, consulte o dispositivo virtual Cuttlefish automotivo, que foi introduzido nesta mudança e pode ser referenciado para os arquivos necessários, regras de build e arquivos de make necessários para configurar os arquivos de configuração necessários. Isso funciona com os carregadores fornecidos na HAL de áudio AIDL padrão.

Cenário 2: novo dispositivo usando o Android 16 ou mais recente, de um dispositivo anterior usando o CAP

Um novo dispositivo precisa ser iniciado com o código do Android 16 ou mais recente na partição vendor. No entanto, como o OEM tem uma configuração de mecanismo CAP de dispositivo utilizável, ele quer usá-la como ponto de partida (ou reutilizá-la totalmente). A versão AIDL da configuração do CAP tem algumas mudanças em relação ao Android 15 e versões anteriores. Portanto, o fornecedor precisa converter a configuração atual em AIDL. Consulte a discussão em Estratégias de produtos para saber quais são as mudanças entre o Android 16 e versões anteriores. Em geral, o framework de áudio detecta e carrega a configuração do CAP da mesma forma que no Cenário 1.

Cenário 3: dispositivo atual com CAP atualizando para o Android 16 apenas na partição do sistema

Nesse cenário, a partição vendor contém a versão do Android 15 e anteriores da configuração de CAP do dispositivo e a definição de domínio de CAP de PfW. A partição vendor não é alterada, portanto, ainda usa a HAL HIDL. O framework segue o cenário do Android 15 e versões anteriores e carrega toda a configuração relacionada ao CAP da partição vendor.

Cenário 4: dispositivo lançado no Android 15, com CAP

O CAP não tinha suporte na AIDL no Android 15. Por isso, alguns fabricantes lançaram novos dispositivos com a HAL de áudio AIDL e o CAP, que foram carregados pelo framework de áudio. Esse modo híbrido não era oficial, mas foi incluído no Android 16. Esse modo não deve ser usado para lançar novos dispositivos no Android 16, mas sim para atualizar dispositivos existentes com o fornecedor do Android 15 para o Android 16 (a atualização de partição system).

O framework de áudio descobre a configuração de áudio HAL de áudio AIDL sem a configuração de CAP. Para a configuração do CAP, o serviço de política de áudio (framework de áudio) volta a carregar a configuração do CAP da partição vendor. Nesse caso, a definição de domínio do CAP de PfW e a configuração do CAP do dispositivo precisam ser carregadas da partição vendor.

Resumo da migração do CAP

A tabela a seguir resume as configurações e os requisitos do sistema e do fornecedor compatíveis com a configuração do CAP: