自 2025 年 3 月 27 日起,我们建议您使用 android-latest-release
而非 aosp-main
构建 AOSP 并为其做出贡献。如需了解详情,请参阅 AOSP 的变更。
设备类型限制
使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
在 Android 音频中,audio_devices_t
用于表示音频设备的类型,且在音频源代码广泛用作位字段来过滤或选择一种或多种特定设备。在 Android 11 之前,音频输入/输出设备的类型数上限为 30,且无法添加新的音频设备类型。我们取消了对音频设备类型数量的限制,以允许添加新的音频设备类型。
为了取消对音频设备类型数量的限制,音频设备类型现在为枚举值,而非位掩码。
所有现有音频设备类型均保持不变。AUDIO_DEVICE_BIT_IN
仍可用于区分输入设备和输出设备。添加的新音频设备类型是枚举值,与现有值之间存在一定的差异。
原始设备制造商 (OEM) 不应将 audio_devices_t
用作位掩码,因为这样做可能会导致在添加新的枚举音频设备类型后产生异常结果。
示例和源代码
在 Android 11 之前,位掩码形式的音频设备类型的用途通常有以下两种。
- 使用
audio_devices_t
值表示多个音频设备。
- 检查
audio_devices_t
值是否包含特定类别的音频设备类型。
为了表示多个音频设备类型,可使用 /libaudiofoundation/include/media/AudioContainers.h
中名为 DeviceTypeSet
的类,前者是 audio_devices_t
的 std::set
容器。该类是在面向供应商的 libaudiofoundation
库中声明的。为了表示采用 C 代码的多个音频设备类型,可使用数组或 audio_devices_t
列表。
如需检查某设备类型是否属于特定类别,请使用 /system/media/audio/include/system/audio.h
中的辅助函数 audio_is_.*_device
。如果存在多个音频设备类型,请使用 libaudiofoundation
中的辅助函数。例如,使用 AudioContainers.h
中的 areAllOfSameDeviceType (DeviceTypeSet, std::function)
可检查所有特定音频设备类型是否属于同一类型。
实现
原始设备制造商 (OEM) 需要从音频 HAL 实现中移除音频设备类型位字段表示法。
- 移除位字段中存储的所有设备。
不应使用 audio_devices_t
来表示多个音频设备类型,而应使用列表或矢量。
- 停止使用位操作对设备类型进行比较。
在 Android 11 之前,可将音频设备类型用作位字段。在这种情况下,通常使用位操作对设备类型进行比较。添加新的枚举音频设备类型时,位操作可能会导致异常结果。请改用辅助函数。如果是单个音频设备类型,则使用直接比较方法比较两个值。如需检查音频设备类型是否属于特定类别,请使用 /system/media/audio/include/system/audio.h
中的辅助函数。例如:audio_is_output_device(audio_devices_t device)
。
- 停止为音频设备类型组使用预定义的值。
system/media/audio/include/system/audio-base-utils.h
中有一些音频设备类型组 AUDIO_DEVICE_OUT_ALL
的预定义的值。这些值都会被保留,但可能会被废弃,因为添加新的枚举音频设备类型后,这些值是错误的。audio-base-utils.h
中定义的新音频设备类型组是音频设备类型的数组(如 AUDIO_DEVICE_OUT_ALL_ARRAY
)。
- 实现
create_audio_patch()
和 release_audio_patch()
方法(而非 set_parameters
)进行路由。
set_parameters
方法将音频设备类型用作位字段,因此,添加新的枚举音频设备类型后可能会出现异常结果。
目前需要使用的音频补丁程序为以下两种:
- 从混音端口到设备端口的补丁程序(用于播放)
- 从设备端口到混音端口的补丁程序(用于录音)
在后续更新中,可能需要从设备到设备的其他补丁程序。
创建音频补丁程序时,如果未指定补丁程序句柄,则音频 HAL 需要生成可标识音频补丁程序的唯一补丁程序句柄。否则,音频 HAL 应使用指定音频补丁程序句柄更新相应音频补丁程序。
如果使用的是旧版音频 HAL 和 AOSP HIDL 封装容器,则旧版音频 HAL 应将主要 HAL 版本设为 3.0。
如需启用音频补丁程序功能,音频 HAL 应将主要 HAL 版本设为 3.0 或更高版本。如需了解详情,请参阅默认 HIDL 实现中的 Device::supportsAudioPatches()
,也可以参阅 Cuttlefish 的音频 HAL。
自定义
您无法关闭该功能,也无法还原框架中的音频设备重构以添加音频设备类型。
添加的所有音频设备类型都可以表示设置了单个位的设备类型,因此当前 HAL 实现仍会正常运行。
如果已添加新的音频设备类型,且原始设备制造商 (OEM) 希望使用新类型,则必须升级其音频 HAL 实现并将 HIDL 迁移到 6.0 或更高版本。必须将主要 HAL 版本升级到 3.0 并实现 create_audio_patch
和 release_audio_patch
方法,因为使用 set_parameters
路由音频流可能会导致新添加的音频设备类型时出现异常结果。
验证
原始设备制造商 (OEM) 必须更新其 HAL 实现。适用于音频 HAL 的 VTS 可用于验证实现是否按预期运行。可在 VTS 文件中找到所有测试。
本页面上的内容和代码示例受内容许可部分所述许可的限制。Java 和 OpenJDK 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC):2025-03-26。
[null,null,["最后更新时间 (UTC):2025-03-26。"],[],[],null,["# Device type limit\n\nIn Android audio, `audio_devices_t` is used to represent the audio device type. It's\nwidely used in audio source code as a bit field to filter or select one or more\nspecified devices. Prior to Android 11, there was a limit of 30\naudio input/output device types, and no spare slots to add new audio device types. We've\nremoved the limit on the number of audio device types to allow\nnew audio device types to be added.\n\nTo remove the limit on the number of audio device types, audio device types are now\nenumerated values instead of bit masks.\n\nAll the existing audio device types are kept as is. `AUDIO_DEVICE_BIT_IN` is\nstill used to distinguish input or output devices. When adding new audio device types, they're\nenumerated values in the gaps between existing values.\n\nOEMs shouldn't use `audio_devices_t` as a bit mask, because that can cause\nunexpected results when new enumerated audio device types are added.\n\nExamples and source\n-------------------\n\nBefore Android 11, there were two typical usages of audio device\ntypes as bit masks.\n\n- Using the `audio_devices_t` value to represent multiple audio devices.\n- Checking if the `audio_devices_t` value contains audio device types from a specified category.\n\nTo represent multiple audio device types, a class named `DeviceTypeSet` in the\n[`/libaudiofoundation/include/media/AudioContainers.h`](https://cs.android.com/android/platform/superproject/+/android-latest-release:frameworks/av/media/libaudiofoundation/include/media/AudioContainers.h)\nis used, which is a `std::set` container of `audio_devices_t`. The\nclass is declared in the vendor-available\n[`libaudiofoundation`](https://cs.android.com/android/platform/superproject/+/android-latest-release:frameworks/av/media/libaudiofoundation/) library. To represent\nmultiple audio\ndevice types in C code, an array or a list of `audio_devices_t` can be used.\n\nTo check if a single device type is of a specified category, use helper functions\n`audio_is_.*_device` in [`/system/media/audio/include/system/audio.h`](https://cs.android.com/android/platform/superproject/+/android-latest-release:system/media/audio/include/system/audio.h).\nFor multiple audio device types case, use helper functions in `libaudiofoundation`. For\nexample, use\n`areAllOfSameDeviceType (DeviceTypeSet, std::function`)\nin [`AudioContainers.h`](https://cs.android.com/android/platform/superproject/+/android-latest-release:frameworks/av/media/libaudiofoundation/include/media/AudioContainers.h) to check if all the given audio device types\nare of the same type.\n\nImplementation\n--------------\n\nOEMs need to remove audio device type bit field representation from audio HAL implementation.\n\n1. Remove all storage of devices on a bit field. `audio_devices_t` shouldn't be used to represent multiple audio device\n types. Instead, use a list or vector.\n\n2. Stop using bit operations for device types comparisons. Before Android 11, audio device types can be used as a\n bitfield. In that case, it's common to use bit operations for device types\n comparisons. When new, enumerated audio device types are added, the bit operations may cause\n unexpected results. Instead, use helper functions as an alternative. If there's a single\n audio device type, then use direct comparison to compare the two values. To check if an audio\n device type is of a specified category, use helper functions in\n [`/system/media/audio/include/system/audio.h`](https://cs.android.com/android/platform/superproject/+/android-latest-release:system/media/audio/include/system/audio.h). For example,\n `audio_is_output_device(audio_devices_t device)`.\n\n3. Stop using predefined values for groups of audio device types. There are some predefined values for groups of audio device types,\n `AUDIO_DEVICE_OUT_ALL`, in\n `system/media/audio/include/system/audio-base-utils.h`. All these values are\n reserved but might be deprecated as they won't be correct when new enumerated\n audio device types are added. There are new groups of audio device types defined in\n `audio-base-utils.h`, which are arrays of audio device types, such as\n `AUDIO_DEVICE_OUT_ALL_ARRAY`.\n\n4. Implement the `create_audio_patch()` and `release_audio_patch()` methods for routing instead of `set_parameters`.\n\n The `set_parameters` method uses audio device types as a bitfield, so there can be\n unexpected results if new enumerated audio device types are added.\n\n Currently, two kinds of audio patches are required:\n - Mix to device patches, for playback\n - Device to mix patches, for recording\n\n In subsequent updates, additional patches might be required for device to device.\n\n When creating an audio patch, if the patch handle isn't\n specified, the audio HAL is required to generate a unique patch handle that can\n identify the audio patch. Otherwise,\n the audio HAL should use the given audio patch handle to update the audio patch.\n\n If using a legacy audio HAL and the AOSP HIDL wrapper, the legacy audio HAL should set\n the major HAL version to 3.0.\n\n To enable the audio patch feature, the audio HAL should set\n the major HAL version to 3.0 or\n higher. Refer to `Device::supportsAudioPatches()` in\n [default HIDL implementation](https://cs.android.com/android/platform/superproject/+/android-latest-release:hardware/interfaces/audio/core/all-versions/default/Device.cpp)\n for more information, which can also be found on audio HAL for Cuttlefish.\n\nCustomization\n-------------\n\nIt's not possible to turn the feature off, or to revert the audio device refactoring in the\nframework that makes it possible to add audio device types.\n\nAll of the audio device types added allow representing a device type with a single bit set,\nso current HAL implementations still work.\n\nIf new audio device types are added and OEMs want to use them, they\nhave to upgrade their audio HAL implementation and move to HIDL version 6.0 or higher. It's\nmandatory to upgrade the major HAL version to 3.0 and implement the\n`create_audio_patch` and `release_audio_patch` methods, because\nusing `set_parameters` to route the stream can cause unexpected results when\nnew audio device types are added.\n\nValidation\n----------\n\nThe required work for OEMs is to update their HAL implementations. VTS for\naudio HAL can be used to validate if the implementation works as intended. All\nthe tests can be found in the\n[VTS files](https://cs.android.com/android/platform/superproject/+/android-latest-release:hardware/interfaces/audio/core/all-versions/vts)."]]