O Android 14 oferece suporte para dose sonora no framework e na HAL de áudio monitorando continuamente medições de dose sonora e emitindo alertas para usuários sobre os níveis de exposição prejudiciais.
A dose sonora é uma medição dos níveis de pressão sonora durante um período. Ao monitorar a dose sonora, podemos ajudar a proteger os usuários dos efeitos prejudiciais da exposição excessiva ou prolongada ao som, oferecendo melhor proteção auditiva ao usar fones de ouvido em dispositivos Android portáteis e minimizando a chance de perda auditiva.
Os novos padrões para dispositivos de audição seguros estão em conformidade com os requisitos regulamentares de proteção auditiva na IEC62368-1, 3ª edição (requer login) e na EN50332-3 (acesso limitado a assinantes), que introduzem o conceito de dose sonora.
A função de dose sonora permite que os OEMs sigam as novas regulamentações de segurança auditiva. Para oferecer suporte à dose sonora, os OEMs precisam seguir as especificações e regulamentações da interface para todas as personalizações e certificações. Uma implementação personalizada do OEM pode ignorar ou modificar a implementação padrão do AOSP de dose sonora. No entanto, é altamente recomendável usar a implementação do AOSP.
Cálculo da dose sonora
Os padrões na 3ª edição da IEC62368-1 e na EN50332-3 aumentam a precisão da medição da exposição ao som ao calcular a dose sonora calculada (CSD, na sigla em inglês). O CSD é calculado integrando os níveis de exposição momentânea (MEL) ao longo do tempo. Uma janela móvel contínua de sete dias de valores de CSD acumulados é mantida para o cálculo da dose sonora.
De acordo com a seção 10.6.3.2 da 3ª edição da IEC62368-1, se o valor de CSD atingir o limite de 100%, o sistema vai alertar o usuário sobre os níveis de som a cada aumento de 100%. Se o usuário não confirmar o aviso, o volume será reduzido ao valor predefinido da fonte de energia de radiação classe 1 (RS1) da Tabela 39 da IEC62368-1.
Conforme mencionado na seção 10.6.3.3 da 3ª edição da IEC62368-1, além dos avisos de dose sonora, o sistema precisa iniciar um aviso com base na exposição sempre que o valor de MEL exceder o valor da classe 2 (RS2) da fonte de energia de radiação da Tabela 39 da IEC62368-1.
Para a certificação com essas regulamentações e para tornar os valores de CSD mais relevantes, o sistema precisa usar valores de saída precisos, conforme percebido pelos usuários (como a saída de reprodução de mídia). É importante que o cálculo do CSD use valores próximos aos níveis de pressão sonora reais a que o usuário está exposto.
Arquitetura
Dependendo de onde os frames são capturados, as características de hardware e os efeitos dos transdutores podem influenciar o nível de potência dos frames renderizados. Para ter uma medição precisa do nível de pressão sonora de saída, estendemos o HAL para receber os valores de MEL diretamente do hardware e considerar possíveis efeitos aplicados pelo processador de sinal digital (DSP) ou pelas propriedades do alto-falante, como impedância, sensibilidade e resposta de frequência.
Se a HAL não puder fornecer valores de MEL, como um mecanismo de fallback, o framework de áudio vai analisar e calcular o CSD. Essa computação no framework de áudio é baseada nas informações sobre a saída renderizada informada pela HAL e nos frames enviados ao DSP de áudio.
A dose sonora apresenta dois componentes, SoundDoseHelper
e SoundDoseManager,
, conforme mostrado na Figura 1:
Figura 1. Componentes arquitetônicos do recurso de dose sonora.
SoundDoseHelper
A classe SoundDoseHelper
, que fica no processo systemserver
, é o
ponto principal de coleta de todos os dados relevantes de dosagem de som. A classe AudioService
gerencia a classe SoundDoseHelper
.
A classe SoundDoseHelper
é responsável pelo seguinte:
- Como processar novas informações de dosagem
- Como manter valores de dose sonora
- Recuperação de estado em caso de falha do
audioserver
- Acionamento de notificações da interface do sistema
- Diminuir o volume
SoundDoseManager
A classe SoundDoseManager
, que fica no processo audioserver
e faz parte da classe AudioFlinger
, coleta os dados de dose sonora do HAL ou os calcula internamente, como um fallback, dos frames enviados ao HAL. A classe SoundDoseManager
envia
os dados de dose sonora para a classe SoundDoseHelper
.
MelProcessor e MelAggregator
Se a HAL não puder fornecer valores de MEL, as utilidades MelProcessor
e MelAggregator
em libaudioutils
serão usadas para o cálculo interno da dose sonora.
Na classe MelProcessor
, a computação principal é realizada em um buffer com
amostras de áudio chamando MelProcessor::process(const void* buffer, size_t bytes)
.
Os OEMs podem usar MelProcessor
na implementação da HAL, se necessário.
A classe MelAggregator
recebe os valores de MEL de diferentes portas de áudio e calcula o valor de CSD com uma janela contínua de sete dias. O método MelAggregator::aggregateAndAddNewMelRecord_l(MelRecord mel)
executa a lógica. Os resultados são enviados à classe SoundDoseManager
para comunicação com AudioService
.
Implementação
As extensões de interface HIDL foram descontinuadas no Android 14.
Por isso, a nova interface HAL para recuperar valores de MEL calculados e emitir avisos
de exposição, chamada ISoundDose
,
é definida como parte da HAL de áudio AIDL. No entanto, para implementadores que precisam de mais tempo para integrar a HAL de áudio AIDL, temos uma HAL AIDL independente de dose sonora, que oferece a interface ISoundDoseFactory
. Isso será descontinuado no futuro.
Os métodos da HAL para suporte à dose sonora são mostrados na seguinte amostra de código:
/**
* This interface provides functions related to sound exposure control required for compliance to
* EN/IEC 62368-1 3rd edition. Implementing this interface is mandatory for devices for which
* compliance to this standard is mandated and implementing audio offload decoding or other direct
* playback paths where volume control happens below the audio HAL.
*/
@VintfStability
interface ISoundDose {
/**
* Max value in dBA used for momentary exposure warnings as defined by IEC62368-1
* 3rd edition. This value represents the default RS2 upper bound.
*/
const int DEFAULT_MAX_RS2 = 100;
/** Min value of the RS2 threshold in dBA as defined by IEC62368-1 3rd edition. */
const int MIN_RS2 = 80;
/**
* Sets the RS2 upper bound used for momentary exposure warnings. Default value is
* DEFAULT_MAX_RS2 as specified in IEC62368-1 3rd edition.
*
* @param rs2ValueDbA custom RS2 upper bound to use
* @throws EX_ILLEGAL_ARGUMENT if rs2ValueDbA is greater than DEFAULT_MAX_RS2 or lower
* than MIN_RS2
*/
void setOutputRs2UpperBound(float rs2ValueDbA);
/**
* Gets the RS2 upper bound used for momentary exposure warnings.
*
* @return the RS2 upper bound in dBA
*/
float getOutputRs2UpperBound();
/**
* Registers the HAL callback for sound dose computation. If sound dose is supported
* the MEL values and exposure notifications will be received through this callback
* only. The internal framework MEL computation will be disabled.
* It is not possible to unregister the callback. The HAL is responsible to provide
* the MEL values throughout its lifecycle.
*
* @param callback to use when new updates are available for sound dose
*/
void registerSoundDoseCallback(in IHalSoundDoseCallback callback);
@VintfStability
oneway interface IHalSoundDoseCallback {
/**
* Called whenever the current MEL value exceeds the set RS2 upper bound.
*
* @param currentDbA the current MEL value which exceeds the RS2 upper bound
* @param audioDevice the audio device where the MEL exposure warning was recorded
*/
void onMomentaryExposureWarning(float currentDbA, in AudioDevice audioDevice);
@VintfStability
parcelable MelRecord {
/**
* Array of continuously recorded MEL values >= MIN_RS2 (1 per second).
* First value in the array was recorded at 'timestamp'.
*/
float[] melValues;
/**
* Corresponds to the time in seconds, as reported by CLOCK_MONOTONIC, when
* the first MEL entry in melValues was recorded. The timestamp values have
* to be consistent throughout all audio ports, equal timestamp values will
* be aggregated.
*/
long timestamp;
}
/**
* Provides a MelRecord containing continuous MEL values sorted by timestamp.
* Note that all the MEL values originate from the audio device specified by audioDevice.
* In case values from multiple devices need to be reported, the caller should execute
* this callback once for every device.
*
* @param melRecord contains the MEL values used for CSD
* @param audioDevice the audio device where the MEL values were recorded
*/
void onNewMelValues(in MelRecord melRecord, in AudioDevice audioDevice);
}
}
A nova interface HAL implementa callbacks
que informam ao framework sobre a exposição momentânea e fornecem valores de MEL
sempre que o nível de saída excede RS1. Quando essas interfaces são implementadas, o framework as usa para relatórios de CSD. Sem essa implementação de callback, uma implementação alternativa em AudioFlinger
é usada para calcular estimativas de valores de CSD.
Suporte independente para AIDL de dose sonora
Até que os OEMs possam integrar a dose sonora na HAL de áudio AIDL, eles podem usar a
API AIDL independente ISoundDoseFactory
como uma solução alternativa. O ISoundDoseFactory
usa a interface ISoundDose
, conforme mostrado na
amostra de código a seguir:
@VintfStability
interface ISoundDoseFactory {
/**
* Retrieve the sound dose interface for a given audio HAL module name.
*
* If a device must comply to IEC62368-1 3rd edition audio safety requirements and is
* implementing audio offload decoding or other direct playback paths where volume control
* happens below the audio HAL, it must return an instance of the ISoundDose interface.
* The same instance must be returned during the lifetime of the HAL module.
* If the HAL module does not support sound dose, null must be returned, without throwing
* any errors.
*
* @param module for which we trigger sound dose updates.
* @return An instance of the ISoundDose interface implementation.
* @throws EX_ILLEGAL_STATE If there was an error creating an instance.
*/
@nullable ISoundDose getSoundDose(in @utf8InCpp String module);
}
Compatibilidade com HAL de áudio AIDL de dose sonora
A interface de dose sonora tem suporte de longo prazo como parte da HAL de áudio AIDL ao
estender a interface IModule
, conforme mostrado no exemplo de código a seguir:
@VintfStability
interface IModule {
…
/**
* Retrieve the sound dose interface.
*
* If a device must comply to IEC62368-1 3rd edition audio safety requirements and is
* implementing audio offload decoding or other direct playback paths where volume control
* happens below the audio HAL, it must return an instance of the ISoundDose interface.
* The same instance must be returned during the lifetime of the HAL module.
* If the HAL module does not support sound dose, null must be returned, without throwing
* any errors.
*
* @return An instance of the ISoundDose interface implementation.
* @throws EX_ILLEGAL_STATE If there was an error creating an instance.
*/
@nullable ISoundDose getSoundDose();
}
Esse recurso é uma implementação de uma nova regulamentação descrita na IEC62368-1 3ª edição e EN50332-3. Portanto, não há APIs voltadas para o público externo.
Os OEMs podem certificar os dispositivos implementando as novas interfaces HAL e fornecendo dados precisos de MEL para o CSD ao framework de áudio (recomendado) ou fornecendo uma implementação personalizada de dose sonora.
Ativar o cálculo da dose sonora
Por padrão, o AOSP é compatível com a lógica de segurança auditiva que garante a certificação com os padrões EN50332-2 e IEC62368-1 10.6.5 atuais.
No Android 14, o cálculo de dose sonora fica desativado por padrão.
Use as diretrizes a seguir para ativar o cálculo da dose sonora a partir do Android 14 QPR1.
Se as regulamentações de dose sonora forem aplicadas no seu país, verifique se
config_safe_media_volume_enabled
emconfig.xml
está definido comotrue
.Para obedecer às normas EN50332-3 e IEC62368-1 10.6.3, os fornecedores precisam sobrepor a flag
config_safe_sound_dosage_enabled
emconfig.xml
paratrue
. Para dispositivos que oferecem suporte à decodificação de descarga e não implementam as interfaces HAL de dose sonora,config_safe_sound_dosage_enabled
não pode ser definido comotrue
. Nesses casos, definirconfig_safe_sound_dosage_enabled
comotrue
pode levar a valores de CSD imprecisos e problemas de certificação para padrões de audição de segurança.
O gráfico de decisão a seguir descreve a lógica que determina se, com base nas restrições de país e nos valores das flags, os níveis de segurança auditiva do CSD ou legados (implementados antes do Android 14) são calculados.
Figura 2. Ative o cálculo de dose sonora (a lógica é adicionada no Android 14-QPR1).
Validação
Ao implementar a interface HAL para dose sonora, os OEMs precisam validar os casos de teste do VTS definidos por VtsHalAudioCoreTargetTest
(link em inglês)
para a implementação da HAL de áudio AIDL do IModule ou por VtsHalSoundDoseFactoryTargetTest
(link em inglês)
para a implementação da HAL AIDL de dose sonora independente.