El Reconocimiento de Wi-Fi que se agregó a Android 8.0 permite que los dispositivos compatibles descubran, se conecten, y rango (agregados en Android 9) entre sí directamente mediante el protocolo de reconocimiento de Wi-Fi sin acceso a Internet o a la red móvil. Esta función, basada en la especificación Wi-Fi Aware (versiones 2.0, 3.0, 3.1 y 4.0) de la Wi-Fi Alliance (WFA), permite compartir fácilmente datos de alta capacidad de procesamiento entre dispositivos y apps confiables que de otro modo estarían fuera de la red.
Ejemplos y fuente
Para usar esta función, los fabricantes de dispositivos deben implementar la HAL del proveedor de Wi-Fi. En Android 14 y versiones posteriores, la interfaz de la HAL del proveedor se define con AIDL. En el caso de Android 13 y versiones anteriores, la interfaz de la HAL del proveedor se define con HIDL.
Sigue la interfaz de Wi-Fi para emplear la función de reconocimiento de Wi-Fi. Según la interfaz que se implemente, esto sucederá:
- AIDL:
hardware/interfaces/wifi/aidl - HIDL:
hardware/interfaces/wifi/1.2o posterior
Puedes consultar el HAL de Wi-Fi heredado para ver cómo se correlaciona con las interfaces AIDL y HIDL: hardware/libhardware_legacy/+/main/include/hardware_legacy/wifi_nan.h.
Implementación
Los fabricantes de dispositivos deben proporcionar compatibilidad con el framework y con HAL/firmware:
- Framework:
- Código del AOSP
- Habilita el reconocimiento: Requiere una marca de función y una marca de compilación.
- Compatibilidad con HAL de Wi-Fi Aware (NAN) (lo que implica compatibilidad con firmware)
Para implementar esta función, los fabricantes de dispositivos implementan la interfaz Wi-Fi y habilitan dos marcas de función:
En
BoardConfig.mkoBoardConfig-common.mk, ubicado endevice/<oem>/<device>, agrega la siguiente marca:WIFI_HIDL_FEATURE_AWARE := trueEn
device.mk, ubicado endevice/<oem>/<device>, modifica el Es la variable de entornoPRODUCT_COPY_FILESpara incluir compatibilidad con Wi-Fi. Función de reconocimiento:PRODUCT_COPY_FILES += frameworks/native/data/etc/android.hardware.wifi.aware.xml:$(TARGET_COPY_OUT_VENDOR)/etc/permissions/android.hardware.wifi.aware.xml
Wi-Fi Aware incluye el rango de dispositivos pares que usan el protocolo IEEE 802.11mc, también conocido como tiempo de ida y vuelta (RTT). Esta subfunción de Reconocimiento de Wi-Fi se condicional en el dispositivo que admita la función Wi-Fi RTT, es decir, requiere el dispositivo para admitir Wi-Fi Aware y Wi-Fi RTT. Para obtener más detalles, consulta Wi-Fi RTT
De lo contrario, todo lo necesario para esta función se incluye en el AOSP.
La marca WIFI_HIDL_FEATURE_AWARE se ignora si el
WIFI_HAL_INTERFACE_COMBINATIONS
la marca de verificación. Para obtener más información, consulta Simultaneidad de varias interfaces de Wi-Fi.
Aleatorización de MAC
Android requiere que la dirección MAC del descubrimiento de Wi-Fi Aware (NMI) y las interfaces de datos (NDP) sean aleatorias y no sean idénticas a la dirección MAC real del dispositivo. Las direcciones MAC deben ser las siguientes:
- Se genera de forma aleatoria cada vez que se habilita o se vuelve a habilitar el reconocimiento de Wi-Fi.
Cuando se habilita Wi-Fi Aware, la dirección MAC se debe aleatorizar en un intervalo regular configurado por el parámetro
NanConfigRequest.macAddressRandomizationIntervalSec. El framework lo configura de forma predeterminada en 30 minutos.
Suspender y reanudar
En Android 14 y versiones posteriores, Wi-Fi Aware admite que las apps con privilegios suspendan y reanuden las sesiones de descubrimiento activas (incluidas todas las rutas de datos asociadas con esas sesiones). La compatibilidad con esta función permite que los dispositivos reanuden las sesiones de descubrimiento más rápido y usen menos energía, ya que las sesiones de descubrimiento se pueden suspender.
Si un dispositivo admite esta función de suspensión y reanudación, el firmware suspende la sesión de Wi-Fi Aware cuando una app con privilegios suspende la sesión de descubrimiento. Cuando una sesión de descubrimiento está suspendida, el dispositivo no transmite ni recibe tramas para esa sesión, incluidos los NDP activos en esa sesión. Si se suspenden todas las sesiones de descubrimiento, el dispositivo no transmite ni recibe tramas de Wi-Fi Aware.
Cuando una app con privilegios reanuda una sesión de descubrimiento suspendida, el framework la regresa a su estado anterior, incluidas todas las sesiones de NDP asociadas. La reanudación de una sesión de descubrimiento suspendida es más rápida que abrir Wi-Fi Aware y crear una sesión de descubrimiento nueva.
Para admitir la capacidad de suspender y reanudar las sesiones de descubrimiento, el dispositivo
Los fabricantes deben brindar compatibilidad con HAL y firmware. Para obtener más información, consulta IWifiNanIface.java.
Los fabricantes de dispositivos pueden usar comunicaciones fuera de banda (por ejemplo, BLE) para lo siguiente: Sincronizar, suspender y reanudar en varios dispositivos.
Validación
Android proporciona un conjunto de pruebas de unidades, pruebas del Conjunto de pruebas de compatibilidad (CTS) y pruebas del verificador del CTS para validar la función Wi-Fi Aware. Wi-Fi Aware también se puede probar con el Conjunto de pruebas de proveedores (VTS).
Pruebas de unidades
Las pruebas de paquetes de Wi-Fi Aware se ejecutan con lo siguiente:
Pruebas de servicio:
atest com.android.server.wifi.awarePruebas del administrador:
atest android.net.wifi.awarePruebas del Conjunto de pruebas de compatibilidad (CTS)
Usa pruebas de CTS para validar la función de reconocimiento de Wi-Fi. El CTS detecta cuándo la función esté habilitada y que incluya automáticamente las pruebas asociadas.
Las pruebas de CTS se pueden activar con lo siguiente:
atest SingleDeviceTestPruebas del verificador del CTS
Las pruebas del verificador de CTS validan el comportamiento de Wi-Fi Aware con dos dispositivos: un dispositivo de prueba y un dispositivo conocido como bueno. Para ejecutar las pruebas, abre el verificador del CTS y ve a la sección titulada Pruebas de reconocimiento de Wi-Fi.