Mecanismo de política de áudio configurável

No Android 14, o Android Automotive Operating System (AAOS) usa o mecanismo de política de áudio configurável (CAP) para gerenciamento de áudio do carro 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 ambos simultaneamente. As flags a seguir 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 do gerenciador 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 é compatível com o Android por padrão na forma do 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, 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 volume e desativação do som com as tabelas de volume

Inicialização do 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:

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

Conforme mostrado na figura, a configuração do mecanismo CAP é obtida pelo serviço de política de áudio ao analisar as informações do audio_policy_engine_configuration.xml arquivo 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, a estrutura de parâmetros 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 em versões anteriores

Para extrair 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 de estrutura pelo local do arquivo de descrição da estrutura:

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

Isso aponta para informações de estrutura no arquivo:

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

Uma estrutura básica é fornecida em Android . Como as informações de estrutura exigem as informações de estrutura da estratégia de produto, o Android oferece a buildStrategiesStructureFile.py ferramenta de geração, que pode gerar informações do arquivo XML de estratégia de produto disponível. Isso pode ser referenciado usando a genrule padrão buildstrategiesstructurerule da seguinte forma:

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 de política de áudio na pasta automotive. Outros exemplos mostram como configurar um build para enviar os arquivos na partição do fornecedor do dispositivo.

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

Assim como a 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 oferece ferramentas de build para gerar essas informações usando a configuração do mecanismo de política de áudio e os arquivos da estrutura de parâmetros. Consulte Configurações para mais informações.

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

No Android 16 e versões mais recentes, 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 mecanismo CAP no Android 16:

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

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

Nessa configuração, a estrutura do framework de parâmetros ainda é carregada pelo mecanismo de 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 AIDL Audio HAL usadas pelo serviço de política de áudio para obter a configuração do mecanismo CAP:

Figura 5. APIs AIDL Audio HAL.

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

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

Carregador padrão da HAL de áudio AIDL

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

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

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

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

Os fornecedores podem 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 automotivo 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 de estrutura lendo e analisando o [arquivo](https://cs.android.com/android/platform/superproject/+/android-latest-release:frameworks/av/services/audiopolicy/engineconfigurable/wrapper/ParameterManagerWrapper.cpp;l=71ParameterFrameworkConfigurationCap.xml

). Em particular, ele recebe as informações do arquivo de descrição da estrutura:

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

O framework solta 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. Portanto, eles precisam ser referenciados na configuração ou nos domínios. Para isso, o mecanismo AIDL config 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 mecanismo 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 do HIDL para o 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 especial, todas as referências à estratégia de produto precisam ser alteradas para usar os novos nomes. 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 oferece 40 estratégias de produto extensíveis do fornecedor de vx_1000 a vx_1039 . Todas as extensões de fornecedor precisam começar com o prefixo vx_ e seguir com um número que representa o ID da estratégia de produto na definição da estratégia de produto da HAL de áudio AIDL. O restante das definições (por exemplo, grupos de atributos de áudio, nome) é obtido 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 produto

As estratégias de produto oferecem uma maneira de personalizar como os fluxos 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 atributos de áudio, que identificam streams que devem 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 (ou seja, mídia, notificação, chamada).
• Os tipos de conteúdo descrevem o que está sendo reproduzido (ou seja, música, fala, vídeo, sonificação).
• Os tipos de flags definem comportamentos ou solicitações diferentes em relação ao stream.
• Os tipos de tags aceitam qualquer lista arbitrária de valores de string do fornecedor.
  • Cada string precisa começar com VX_ seguido 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á requisito para essa correspondência. Uma das principais utilidades 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 está associado a qualquer stream que corresponda aos atributos de áudio pertencentes ao grupo de atributos de áudio. A estratégia de produto de música de exemplo 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>

Nessa 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 do grupo de volume contêm um 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 ideal quando o volume é gerenciado. Cada curva de grupo de volume está 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 que contém música ou um jogo é iniciado, o último índice de volume definido para o grupo de volume de mídia é usado. Nesse caso, a curva da 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 tempo de execução para selecionar as regras adequadas a serem aplicadas, dependendo do estado atual do sistema de áudio.

Como mostrado na figura 5, a API contém vários domínios. O objetivo de cada um é 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 em 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
  • Surround codificado
  • Vibrar ao tocar

Cada domínio contém configurações que determinam as regras que devem afetar o comportamento. A ordem da configuração é importante. Verifique se as configurações estão 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 trecho de um arquivo de framework de parâmetros, 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 diferentes regras devem ser aplicadas ao processar a seleção de dispositivos de estratégias de produtos. As partes azuis descrevem as regras que devem ser consideradas, e a parte verde é a configuração aplicada. Este exemplo específico contém as seguintes configurações:

• Selecionar dispositivo Bluetooth A2DP para estratégia de produto musical (ID 1000, vx_1000)
  • Se usado para mídia, não exclui o 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 barramento estiverem disponíveis
  • Se o endereço for BUS00_MEDIA
• Selecionar o dispositivo de saída padrão

Para gerar o arquivo XML do mecanismo de política configurável correspondente, execute os arquivos do framework de parâmetros (PFW) pelo sistema de build definindo uma regra de build usando estas 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 do 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 de nível superior do framework de parâmetros.
   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	Arquivo XML de tipos de critérios, que descreve 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 será gerado com todos os domínios. Confira a seguir um trecho do arquivo gerado usando o exemplo de regras do 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 do CAP

Use 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 condições de aplicabilidade. A seguir, mostramos 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âmetros do 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 o ajuste no dispositivo. Para verificar se o dispositivo permite ajuste, 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" e 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 builds legados. Um build de lançamento define TuningAllowed como false sem uma porta de soquete (soquetes são proibidos para isso em builds de lançamento). As builds de engenharia e userdebug definem como true com a porta de soquete usada. Esse é o arquivo referenciado pelo audio_policy_pfw_toplevel. A ferramenta remote-process também precisa ser incluída no arquivo make ou de build 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 sockets também precisa ser incluída. Isso funciona apenas no modo de depuração porque o modo de lançamento não permite sockets:

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

Migração do CAP no Android 16

Devido às grandes mudanças trazidas pelo mecanismo CAP da HAL de áudio AIDL e pelas versões anteriores, há vários cenários de transição de dispositivos que você precisa considerar. Esta seção aborda os cenários de transição mais importantes e dá recomendações para o trabalho de ativação da configuração do mecanismo CAP.

Cenário 1: novo dispositivo usando o Android 16 ou versões mais recentes, sem fonte anterior para a configuração de CAP do dispositivo

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

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

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

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

Um novo dispositivo precisa ser lançado com o Android 16 ou uma versão mais recente na partição vendor. No entanto, como o OEM tem uma configuração de mecanismo CAP de dispositivo utilizável, ele vai querer usá-la como ponto de partida (ou reutilizá-la totalmente). A versão AIDL da configuração do CAP tem algumas mudanças em comparação com a versão do Android 15 e versões anteriores. Por isso, o fornecedor precisa converter a configuração atual para AIDL. Consulte a discussão em Estratégias de produto para ver as mudanças entre o Android 16 e versões anteriores. Em geral, o framework de áudio descobre 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 a partição do sistema

Nesse cenário, a partição vendor contém a configuração de CAP do dispositivo Android 15 e versões anteriores, além da definição de domínio de CAP do PfW. A partição vendor não é alterada, então ela 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 era compatível com AIDL no Android 15. Por isso, alguns fornecedores lançaram novos dispositivos com AIDL Audio HAL e CAP, que era carregado pelo framework de áudio. Esse modo híbrido não era oficial, mas está incluído no Android 16. Esse modo não pode ser usado para lançar novos dispositivos no Android 16, mas sim para permitir que dispositivos atuais com o fornecedor do Android 15 sejam atualizados para o Android 16 (a atualização da partição system).

O framework de áudio descobre a configuração de áudio da HAL de áudio AIDL sem a configuração de CAP. Para a configuração do CAP, o serviço de política de áudio (estrutura de áudio) volta a carregar a configuração do CAP da partição vendor. Nesse caso, a definição de domínio do CAP do 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 compatíveis de sistema e fornecedor para a configuração do CAP: