Descripción general de las funciones y API

Android 11 incluye excelentes funciones y API para desarrolladores. En las siguientes secciones, obtendrás información sobre las funciones de tus apps y cómo comenzar a usar las API relacionadas.

Para obtener una lista detallada de las API nuevas, modificadas y quitadas, consulta el informe de diferencias de API. Para obtener detalles sobre las nuevas API, consulta la referencia de la API de Android. Las nuevas API están destacadas para que sea más fácil identificarlas. Además, para conocer las áreas en las que los cambios de la plataforma podrían afectar tus apps, asegúrate de revisar los cambios en el comportamiento de Android 11 para apps orientadas a Android R (y para todas las apps) y los cambios en la privacidad.

Nuevas experiencias

Controles de dispositivos

Android 11 incluye una nueva API de ControlsProviderService que puedes usar a fin de exponer controles para dispositivos externos conectados. Estos controles aparecen en Controles de dispositivos, en el menú de encendido de Android. Para obtener más información, consulta Cómo controlar dispositivos externos.

Controles de contenido multimedia

En Android 11, se actualiza la forma en que se muestran los controles de contenido multimedia. Los controles de contenido multimedia aparecen cerca de la configuración rápida. Se organizan las sesiones de varias apps en un carrusel deslizable que incluye las transmisiones locales en el teléfono; las transmisiones remotas, como las detectadas en dispositivos externos o sesiones de transmisión; y las sesiones reanudables anteriores en el orden en que se reprodujeron por última vez.

Los usuarios pueden reiniciar las sesiones anteriores desde el carrusel sin tener que iniciar la app. Cuando comienza la reproducción, el usuario interactúa con los controles de contenido multimedia de la manera habitual.

Para obtener más información, consulta Controles de contenido multimedia.

Pantallas

Mejor compatibilidad con pantallas de cascada

Android 11 proporciona varias API para brindar compatibilidad con las pantallas de cascada, que envuelven los bordes del dispositivo. S tratan como una variante de las pantallas con cortes. Los métodos DisplayCutout.getSafeInset…() existentes ahora muestran la inserción segura para evitar las áreas de cascada y los cortes. Para procesar el contenido de tu app en el área de la cascada, haz lo siguiente:

  • Llama al método DisplayCutout.getWaterfallInsets() para obtener las dimensiones exactas de la inserción de cascada.

  • Establece el atributo de diseño de ventana layoutInDisplayCutoutMode en LAYOUT_IN_DISPLAY_CUTOUT_MODE_ALWAYS para permitir que se extienda la ventana a las áreas con cortes y de cascada en todos los bordes de la pantalla. Debes asegurarte de que no haya contenido esencial en las áreas con cortes o de cascada.

Sensor de ángulo de bisagra y plegables

Android 11 permite que las apps que se ejecutan en dispositivos con configuraciones de pantalla basadas en bisagras determinen el ángulo de la bisagra proporcionando un nuevo sensor con TYPE_HINGE_ANGLE y una nueva SensorEvent que puede supervisar el ángulo de la bisagra y proporcionar una medición en grados entre dos partes integrales del dispositivo. Puedes usar esas mediciones sin procesar para realizar animaciones detalladas mientras el usuario manipula el dispositivo.

Si bien a algunos tipos de apps (como selectores y fondos de pantalla) les puede resultar útil conocer el ángulo de bisagra exacto, la mayoría de las apps deben usar la biblioteca Window Manager de Jetpack para recuperar la postura del dispositivo llamando a DeviceState.getPosture().

Como alternativa, tu app puede llamar a registerDeviceChangeCallback() para recibir información cuando cambie DeviceState y reaccionar cuando se modifique la postura.

Responder a la postura del dispositivo es un método más seguro y confiable, gracias a las diferentes configuraciones de ventana y dispositivo que existen actualmente en el mercado y que vendrán en el futuro.

Conversaciones

Mejoras en las conversaciones

Android 11 incorpora una serie de mejoras en la forma en que se manejan las conversaciones. Las conversaciones son bidireccionales y en tiempo real entre dos o más personas. Esas conversaciones tienen especial importancia y los usuarios disponen de varias opciones nuevas para interactuar con ellas.

Para obtener más información sobre las conversaciones y la manera en que tu app puede admitirlas, consulta Personas y conversaciones.

Burbujas de chat

Las burbujas ahora están disponibles para que los desarrolladores ayuden a mostrar conversaciones en todo el sistema. Burbujas fue una función experimental de Android 10 que se habilitaba mediante una opción para desarrolladores. En Android 11, esto ya no es necesario.

Si una app está orientada a Android 11 (API nivel 30), las notificaciones no se muestran como burbujas, a menos que cumplan con los nuevos requisitos de conversación. Específicamente, la notificación debe estar asociada a un acceso directo.

Antes de Android 11, si se quería enviar una notificación, era necesario especificar explícitamente que la notificación se configuraba siempre en el modo de IU del documento. A partir de Android 11, ya no se necesita establecer esa configuración de forma explícita. Si la notificación aparece en una burbuja, la plataforma configura automáticamente la notificación para que siempre se inicie en el modo de IU del documento.

Hay varias mejoras en el rendimiento de las burbujas, y los usuarios ahora tienen más flexibilidad a la hora de habilitar e inhabilitar burbujas de cada app. Para los desarrolladores que implementaron la compatibilidad experimental, hay algunos cambios en las API de Android 11:

Indicadores visuales de 5G

En Android 11 (API nivel 30) y versiones posteriores, las apps con el permiso android.Manifest.permission.READ_PHONE_STATE pueden solicitar actualizaciones de información sobre la visualización de números telefónicos mediante PhoneStateListener.onDisplayInfoChanged(). Esto incluye la información de la tecnología de acceso de radio para fines de marketing y desarrollo de la marca.

Esta nueva API proporciona varias soluciones de visualización de íconos de 5G para diferentes proveedores. Las tecnologías compatibles son las siguientes:

  • LTE
  • LTE con agregación de proveedores (LTE+)
  • Pro LTE avanzado (5Ge)
  • NR (5G)
  • NR en bandas celulares milimétricas (5G+)

Privacidad

Android 11 introduce una gran cantidad de cambios y restricciones para mejorar la privacidad del usuario. Para obtener más información, visita la página Privacidad.

Seguridad

Cómo realizar actualizaciones de autenticación biométrica

Para ayudarte a controlar el nivel de seguridad de los datos de tu app, Android 11 ofrece varias mejoras en la autenticación biométrica.

Tipos de autenticación

Android 11 incluye la interfaz BiometricManager.Authenticators, que define los tipos de autenticación que admite la clase BiometricManager:

BIOMETRIC_STRONG
Autenticación mediante un elemento de hardware que cumple con el nivel de seguridad Fuerte según lo definido en la página Definición de compatibilidad.
BIOMETRIC_WEAK
Autenticación mediante un elemento de hardware que cumple con el nivel de seguridad Débil según lo definido en la página Definición de compatibilidad.
DEVICE_CREDENTIAL
Autenticación mediante una credencial de bloqueo de pantalla: el PIN, el patrón o la contraseña del usuario.

Para definir los tipos de autenticación biométrica que acepta tu app, pasa un tipo de autenticación o una combinación de bits de tipos al método setAllowedAuthenticators(). Por ejemplo, si tu app acepta un elemento de hardware "fuerte" o una credencial de bloqueo de pantalla, envía BIOMETRIC_STRONG | DEVICE_CREDENTIAL.

Para comprobar si los elementos de autenticación necesarios están disponibles, pasa la misma combinación de bits de tipos al método canAuthenticate(). Si es necesario, invoca la acción de intent ACTION_BIOMETRIC_ENROLL. En el intent adicional, proporciona el conjunto de autenticadores que acepta tu app. Este intent solicita al usuario que registre las credenciales de un autenticador que acepte tu app.

Después de que el usuario se autentique, podrás verificar si lo hizo usando una credencial de dispositivo o una credencial biométrica llamando al método getAuthenticationType().

Compatibilidad adicional con las claves de autenticación según el uso

Android 11 proporciona mayor compatibilidad con las claves de autenticación según el uso dentro de la clase BiometricPrompt. Para esta clave, el usuario deberá presentar una credencial biométrica, una credencial de dispositivo o ambas credenciales cada vez que tu app necesite acceder a datos protegidos por esa clave. Las claves de autenticación según el uso son útiles para transacciones importantes, como realizar un pago grande o actualizar los historiales médicos de una persona.

Para asociar un objeto BiometricPrompt con una clave de autenticación por uso, agrega un código similar al siguiente:

Kotlin

val authPerOpKeyGenParameterSpec =
        KeyGenParameterSpec.Builder("myKeystoreAlias", key-purpose)
    // Accept either a biometric credential or a device credential.
    // To accept only one type of credential, include only that type as the
    // 2nd argument.
    .setUserAuthenticationParameters(0 /* duration */,
            KeyProperties.AUTH_BIOMETRIC_STRONG or
            KeyProperties.AUTH_DEVICE_CREDENTIAL)
    .build()

Java

KeyGenParameterSpec authPerOpKeyGenParameterSpec =
        new KeyGenParameterSpec.Builder("myKeystoreAlias", key-purpose)
    // Accept either a biometric credential or a device credential.
    // To accept only one type of credential, include only that type as the
    // 2nd argument.
    .setUserAuthenticationParameters(0 /* duration */,
            KeyProperties.AUTH_BIOMETRIC_STRONG |
            KeyProperties.AUTH_DEVICE_CREDENTIAL)
    .build();

Métodos obsoletos:

En Android 11, los siguientes métodos dejan de estar disponibles:

  • El método setDeviceCredentialAllowed().
  • El método setUserAuthenticationValidityDurationSeconds().
  • La versión sobrecargada de canAuthenticate() que no toma argumentos.

Uso compartido seguro de grandes conjuntos de datos

En algunas situaciones, como las relacionadas con el aprendizaje automático o la reproducción de contenido multimedia, es posible que tu app requiera usar el mismo conjunto de datos de gran tamaño que otra app. En versiones anteriores de Android, tu app y la otra tenían que descargar una copia separada del mismo conjunto de datos.

Para ayudar a mitigar la redundancia de datos, tanto en la red como en el disco, Android 11 permite que se almacenen estos grandes conjuntos de datos en la caché del dispositivo mediante blobs de datos compartidos. Si deseas obtener más información sobre cómo compartir conjuntos de datos, consulta la guía detallada sobre cómo compartir conjuntos de datos de gran tamaño.

Cómo realizar encriptación basada en archivos después de un reinicio inalámbrico sin credenciales de usuario

Después de que el dispositivo completa una actualización inalámbrica y se reinicia, las claves encriptadas por credencial (CE) que se encuentran en el almacenamiento protegido mediante credenciales están disponibles de inmediato para las operaciones de encriptación basada en archivos (FBE). Esto significa que, después de una actualización inalámbrica, tu app puede reanudar las operaciones que requieren las claves CE antes de que el usuario ingrese su PIN, patrón o contraseña.

Rendimiento y calidad

Depuración inalámbrica

Android 11 admite la implementación y la depuración de tu app de forma inalámbrica desde tu estación de trabajo a través de Android Debug Bridge (adb). Por ejemplo, puedes implementar tu app depurable en varios dispositivos remotos sin conectar físicamente tu dispositivo a través de USB y lidiar con problemas comunes de conexión USB, como la instalación de controladores.

Para usar la depuración inalámbrica, debes sincronizar tu dispositivo con tu estación de trabajo mediante un código de vinculación. Ambos elementos deben estar conectados a la misma red inalámbrica. Para conectarte a tu dispositivo, sigue estos pasos:

Cuadro de diálogo de vinculación de ADB inalámbrico
  1. En tu estación de trabajo, actualiza a la versión más reciente de las Herramientas de la plataforma del SDK.
  2. En el dispositivo, habilita las Opciones para desarrolladores.
  3. Habilita la opción Depuración inalámbrica.
  4. En el cuadro de diálogo que pregunta ¿Quieres permitir la depuración inalámbrica en esta red?, haz clic en Permitir.
  5. Selecciona Vincular dispositivo mediante código de vinculación. Toma nota del código de vinculación, la dirección IP y el número de puerto que se muestran en el dispositivo (consulta la imagen).
  6. En tu estación de trabajo, abre una terminal y navega hasta android_sdk/platform-tools.
  7. Ejecuta adb pair ipaddr:port. Usa la dirección IP y el número de puerto del paso 5.

  8. Cuando se te pregunte, ingresa el código de vinculación que recibiste en el paso 5. Debería aparecer un mensaje para confirmar que se vinculó correctamente tu dispositivo.

    Enter pairing code: 482924
Successfully paired to 192.168.1.130:37099 [guid=adb-235XY]

  9. Solo para Linux o Microsoft Windows: Ejecuta adb connect ipaddr:port. Usa la dirección IP y el puerto que se indican en Depuración inalámbrica (consulta la imagen que aparece a continuación).

    número de puerto y dirección IP del adb inalámbrico

Instalación del APK de ADB incremental

La instalación de APK grande (más de 2 GB) en un dispositivo puede llevar mucho tiempo, incluso si solo se realiza un pequeño cambio en una app. La instalación incremental del APK de ADB (Android Debug Bridge) acelera este proceso mediante la instalación de suficientes APK para iniciar la app mientras se transmiten los datos restantes en segundo plano. adb install usará automáticamente esta función si es compatible con el dispositivo y si tienes instaladas la versión más reciente de las Herramientas de la plataforma del SDK. Si no es compatible, se usará de forma silenciosa el método de instalación predeterminado.

Usa el siguiente comando adb para utilizar la función. Si el dispositivo no admite la instalación incremental, el comando falla y muestra una explicación detallada.

adb install --incremental

Antes de ejecutar una instalación del APK de ADB incremental, debes firmar tu APK y crear un archivo de esquema de firma de APK v4. Se debe colocar el archivo de firma v4 junto al APK para poder usar esta función.

Cómo detectar errores con el asignador de memoria nativa

GWP-ASan es una función de asignación de memoria nativa que ayuda a encontrar errores ampliados de búfer libre y del montón. Puedes habilitar esta función de forma global o para subprocesos específicos de tu app. Si quieres obtener más información, consulta la guía de GWP-Asan.

API de Neural Networks 1.3

Android 11 expande y mejora la API de Neural Networks (NNAPI).

Nuevas operaciones

NNAPI 1.3 introduce un nuevo tipo de operando, TENSOR_QUANT8_ASYMM_SIGNED, con el objetivo de admitir el nuevo esquema de cuantificación de TensorFlow Lite.

Además, NNAPI 1.3 introduce las siguientes operaciones nuevas:

  • QUANTIZED_LSTM
  • IF
  • WHILE
  • ELU
  • HARD_SWISH
  • FILL
  • RANK

Nuevos controles de AA

NNAPI 1.3 presenta nuevos controles para que el aprendizaje automático funcione sin problemas:

API térmica del NDK

Cuando los dispositivos se calientan demasiado, es posible que aceleren la CPU o la GPU, y esto puede afectar las apps de maneras inesperadas. Las apps o los juegos que incorporan gráficos complejos, procesamiento intensivo o actividad de red sostenida tienen más probabilidades de encontrar problemas.

Usa la API térmica de NDK en Android 11 para supervisar los cambios de temperatura en el dispositivo y tomar medidas para mantener un consumo de energía y la temperatura del dispositivo más bajos. Esta API es similar a la API termal de Java; puedes usarla para recibir notificaciones de cualquier cambio de estado o consultar el estado actual directamente.

Texto y entrada

Transiciones del IME mejoradas

Android 11 presenta nuevas API para mejorar las transiciones de los editores de métodos de entrada (IME), como los teclados en pantalla. Estas API facilitan el ajuste del contenido de tu app en sincronización con la aparición y desaparición del IME y con otros elementos, como las barras de estado y de navegación.

Para mostrar un IME mientras cualquier EditText está enfocada, llama a view.getInsetsController().show(Type.ime()). (Puedes llamar a este método en cualquier vista con la misma jerarquía que EditText centrado, no tienes que llamarlo específicamente en EditText). Para ocultar el IME, llama a view.getInsetsController().hide(Type.ime()). Para comprobar si un IME es visible actualmente, llama a view.getRootWindowInsets().isVisible(Type.ime()).

Para sincronizar las vistas de tu app con la apariencia y desaparición del IME, establece un objeto de escucha en una vista mediante WindowInsetsAnimation.Callback en View.setWindowInsetsAnimationCallback(). (Puedes configurar este objeto de escucha en cualquier vista; no es necesario que sea EditText). El IME llama al método onPrepare() del objeto de escucha; luego, llama a onStart() al comienzo de la transición. Luego, llama a onProgress() en cada progreso de la transición. Cuando finaliza la transición, el IME llama a onEnd(). En cualquier momento de la transición, puedes llamar a WindowInsetsAnimation.getFraction() para saber cuánto progreso ha realizado.

Para ver un ejemplo de cómo usar estas API, consulta la nueva muestra de código de WindowInsetsAnimation.

Cómo controlar la animación del IME

También puedes tomar el control de la animación IME o de la animación de otra barra del sistema, como la de navegación. Para ello, primero llama a setOnApplyWindowInsetsListener() y establece un nuevo objeto de escucha para los cambios de inserción de ventana:

Kotlin

rootView.setOnApplyWindowInsetsListener { rootView, windowInsets ->
    val barsIme = windowInsets.getInsets(Type.systemBars() or Type.ime())
    rootView.setPadding(barsIme.left, barsIme.top, barsIme.right,
                          barsIme.bottom)

      // We return the new WindowInsets.CONSUMED to stop the insets being
      // dispatched any further into the view hierarchy. This replaces the
      // deprecated WindowInsets.consumeSystemWindowInsets() and related
      // functions.
    WindowInsets.CONSUMED
}

Java

mRoot.setOnApplyWindowInsetsListener(new View.OnApplyWindowInsetsListener() {
   @Override
   public WindowInsets onApplyWindowInsets(View v, WindowInsets insets) {

       Insets barsIME = insets.getInsets(Type.systemBars() | Type.ime());
       mRootView.setPadding(barsIme.left, barsIme.top, barsIme.right,
                             barsIme.bottom);

      // We return the new WindowInsets.CONSUMED to stop the insets being
      // dispatched any further into the view hierarchy. This replaces the
      // deprecated WindowInsets.consumeSystemWindowInsets() and related
      // functions.
       return WindowInsets.CONSUMED;
   }
});

Para mover el IME u otra barra del sistema, invoca el método controlWindowInsetsAnimation() del controlador:

Kotlin

view.windowInsetsController.controlWindowInsetsAnimation(
       Type.ime(),
       1000,
       LinearInterpolator(),
       cancellationSignal,
       object : WindowInsetsAnimationControlListener() {
           fun onReady(controller: WindowInsetsAnimationController,
                         types: Int) {
               // update IME inset
             controller.setInsetsAndAlpha(Insets.of(0, 0, 0, inset),
                           1f /* alpha */, 0.1 /* fraction progress */)
           }
       }
);

Java

mRoot.getWindowInsetsController().controlWindowInsetsAnimation(
       Type.ime(), 1000, new LinearInterpolator(), cancellationSignal,
       new WindowInsetsAnimationControlListener() {
           @Override
           public void onReady(
                   @NonNull WindowInsetsAnimationController controller,
                   int types
                   ) {
                   // update IME inset
                   controller.setInsetsAndAlpha(Insets.of(0, 0, 0, inset),
                           1f /* alpha */, 0.1 /* fraction progress */);
           }

           @Override
           public void onCancelled() {}
       });

Actualización de las bibliotecas de ICU

En Android 11, se actualizó el paquete de android.icu para usar la versión 66 de la biblioteca de ICU, mientras que en Android 10 se usaba la versión 63. La nueva versión de la biblioteca incluye datos actualizados de la configuración regional de CLDR y una serie de mejoras en la compatibilidad con la internacionalización en Android.

Entre los cambios más importantes de las nuevas versiones de la biblioteca, se incluyen los siguientes:

  • Muchas API de formato ahora admiten un nuevo tipo de objeto de resultado que extiende FormattedValue.
  • Se mejoró la API de LocaleMatcher con una clase de constructor, compatibilidad con el tipo java.util.Locale y una clase de resultado que incluye datos adicionales sobre una coincidencia.
  • Ahora se admite Unicode 13.

Contenido multimedia

Cómo asignar búferes de MediaCodec

Android 11 incluye una nueva API de MediaCodec que brinda más control a las apps cuando se asignan los búferes de entrada y salida. Esto permite que tu app administre la memoria de manera más eficiente.

Nuevas clases:

Nuevos métodos:

Además, cambió el comportamiento de dos métodos en MediaCodec.Callback():

onInputBufferAvailable()
En lugar de llamar a MediaCodec.getInputBuffer() y MediaCodec.queueInputBuffer() con el índice, si se configura para usar la API de Block Model, las apps deben usar MediaCodec.getQueueRequest con el índice y adjuntar un LinearBlock/HardwareBuffer a la ranura.
onOutputBufferAvailable()
En lugar de llamar a MediaCodec.getOutputBuffer() con el índice, las app pueden usar MediaCodec.getOutputFrame() con el índice para obtener el objeto OutputFrame con más información y los búferes LinearBlock/HardwareBuffer.

Decodificación de latencia baja en MediaCodec

Android 11 mejora la clase MediaCodec con el objetivo de admitir la decodificación de latencia baja para juegos y otras apps que se ejecutan en tiempo real. Puedes comprobar si un códec admite la decodificación de latencia baja pasando FEATURE_LowLatency a MediaCodecInfo.CodecCapabilities.isFeatureSupported().

Si deseas activar o desactivar la decodificación de latencia baja, realiza una de las siguientes acciones:

Se dio de baja OpenSL ES

A partir de NDK r21b Beta 2, se dio de baja la API de OpenSL ES. En su lugar, debes usar Oboe.

La plataforma aún admite OpenSL ES para las apps existentes. Sin embargo, aparece una advertencia de compilación cuando se usa OpenSL ES con una minSdkVersion de 30 o superior.

Nueva función de AAudio: AAudioStream_release()

La función AAudioStream_close() actualiza y cierra una transmisión de audio al mismo tiempo. Esto puede ser peligroso. Si otro proceso intenta acceder a la transmisión después de que se cierra, el proceso fallará.

La nueva función AAudioStream_release() actualiza la transmisión, pero no la cierra. Así, se liberan sus recursos y se deja la transmisión en un estado conocido. El objeto persiste hasta que llamas a la función AAudioStream_close().

API de MediaParser

MediaParser es una nueva API de bajo nivel para la extracción de contenido multimedia. Es más flexible que MediaExtractor y proporciona control adicional sobre la función de extracción de contenido multimedia.

Selector de salida

En Android 11, se implementa un nuevo comportamiento para las apps que usan las API de Cast y Mediarouter.

Además de acceder a las opciones de transmisión desde una app, las opciones de cambio también aparecen en el reproductor de contenido multimedia del sistema. Esto ayuda al usuario a pasar sin problemas de un dispositivo a otro a medida que cambia su contexto de visualización y reproducción, como cuando mira videos en la cocina o en el teléfono, o cuando escucha audio en el hogar o en el automóvil.

Cuando se presiona el botón de selección de ruta en una notificación de contenido multimedia, aparece el selector de salida con estas opciones predeterminadas:

  • La bocina del dispositivo actual
  • Todos los dispositivos de audio Bluetooth conectados

Las apps también pueden proporcionar más opciones según sus capacidades, como Transmitir.

Las apps pueden usar la nueva API de MediaRouter2 para personalizar las opciones de enrutamiento. Puedes excluir dispositivos que no admitas (como filtrar las transmisiones de Chromecast de solo audio si estás mirando un televisor inteligente con Netflix) o incluir otros dispositivos especiales que tu app reconozca.

Conectividad

Mejoras en Wi-Fi Passpoint

Passpoint permite que las apps realicen la autenticación de forma automática y silenciosa, y que se conecten a hotspots Wi-Fi seguros. Las apps que se orientan a la API nivel 30 o superior pueden usar las siguientes funciones adicionales de Passpoint.

Aplicación y notificación de la fecha de vencimiento
La aplicación de fechas de vencimiento en los perfiles permite que el framework evite la conexión automática con puntos de acceso con credenciales vencidas, que están destinados a fallar. Esto evita el uso de tiempo de comunicación y permite ahorrar batería y ancho de banda de backend. Muestra al usuario una notificación cuando su perfil está dentro del rango y caducó.
Coincidencias con FQDN
Permite la configuración de un dominio AAA por separado de un nombre de dominio completamente calificado (FQDN) con protocolo de consulta de acceso de red (ANQP) mediante un nodo Extension/Android en un objeto de administración (MO) de PerProviderSubscription (PPS).
CA privadas autofirmadas
Para los perfiles de Passpoint R1, Android acepta CA privadas autofirmadas a fin de autenticar la conexión.
Permitir varios perfiles con FQDN idéntico
Permitir la instalación de varios perfiles de Passpoint con FQDN idénticos No se usa el FQDN como clave para los perfiles. Las API de Passpoint existentes que requieren FQDN, como remove, aplican la solicitud a todos los perfiles que coinciden con el mismo FQDN.
Permitir la instalación de perfiles sin un certificado de CA raíz
Se permiten los perfiles sin un certificado de CA raíz. En este caso, el sistema verifica los certificados de servidor AAA contra los certificados públicos de CA raíz instalados en el almacén de confianza.
Adaptaciones mejoradas de proveedores de hogar y roaming
El sistema se adapta a las redes Home o Roaming, independientemente del método de autenticación que se publicite. Además, se agregó coincidencia para el hogar para las listas OtherHomePartners y HomeOIList.

Se expandió la API de sugerencias de Wi-Fi

En Android 11, se expandió la API de sugerencias de Wi-Fi para aumentar las capacidades de administración de red de tu app, incluidas las siguientes:

  • Las apps de administración de conectividad pueden administrar sus propias redes permitiendo solicitudes de desconexión.
  • Las redes de Passpoint están integradas en la API de sugerencias y se pueden sugerir al usuario.
  • Las API de Analytics te permiten obtener información sobre la calidad de tus redes.

Actualizaciones de CallScreeningService

A partir de Android 11, una clase CallScreeningService puede solicitar información sobre el estado de verificación STIR/SHAKEN (verstat) de las llamadas entrantes. Se proporciona esta información como parte de los detalles de la llamada de las llamadas entrantes.

Si un CallScreeningService tiene el permiso READ_CONTACTS, la app recibe una notificación cuando hay llamadas entrantes o llamadas salientes a un número en los contactos del usuario.

Actualizaciones de la API de Open Mobile

A partir de Android 11, la API de Open Mobile (OMAPI) tiene funciones adicionales:

  • Permite analizar reglas para privilegios de proveedor.

  • Permite personalizar el acceso de Elementos seguros incorporados (eSE) o el aprovisionamiento de un eSE mediante una o más de las siguientes opciones:

    • Permiso con privilegios del sistema
    • Identificadores de aplicación (AID) de la Regla de acceso a la aplicación principal (ARA-M) configurable
    • API del sistema para restablecer el lector de OMAPI

  • Proporciona a los lectores un indicador claro para que las apps filtren la capacidad del dispositivo.

VPN de gran rendimiento

Las apps que se orientan a la API nivel 30 o superior, o que se ejecutan en dispositivos lanzados en la API nivel 29 pueden aplicar IKEv2/IPsec a las VPN basadas en apps y configuradas por el usuario.

Las VPN se ejecutan de forma nativa en el sistema operativo, lo que simplifica el código necesario para establecer conexiones VPN de tipo IKEv2/IPsec en las apps.

Control de acceso a la red por proceso

A partir de Android 11, las apps que trabajan con datos sensibles del usuario pueden otorgar acceso a la red por proceso. Si especificas de manera explícita a qué procesos se les permite el acceso a la red, aislarás todo el código que no necesite subir datos.

Si bien no se garantiza que tu app no suba datos de forma accidental, es una manera de reducir las posibilidades de que se produzcan errores en tu app debido a filtraciones de datos.

A continuación, se muestra un ejemplo de un archivo de manifiesto en el que se usa la nueva función:

<processes>
    <process />
    <deny-permission android:name="android.permission.INTERNET" />
    <process android:process=":withoutnet1" />
    <process android:process="com.android.cts.useprocess.withnet1">
        <allow-permission android:name="android.permission.INTERNET" />
    </process>
    <allow-permission android:name="android.permission.INTERNET" />
    <process android:process=":withoutnet2">
        <deny-permission android:name="android.permission.INTERNET" />
    </process>
    <process android:process="com.android.cts.useprocess.withnet2" />
</processes>

Cómo permitir varias configuraciones de Passpoint instaladas con el mismo FQDN

A partir de Android 11, puedes usar PasspointConfiguration.getUniqueId() a fin de obtener un identificador único para un objeto PasspointConfiguration, lo que permite a los usuarios instalar varios perfiles con el mismo nombre de dominio completamente calificado (FQDN).

Esta función es útil cuando un proveedor implementa más de una combinación de código móvil de país (MCC) y código de red móvil (MNC) en su red, pero tiene un solo FQDN. En Android 11 y versiones posteriores, se puede instalar más de un perfil con el mismo FQDN que coincida con la red como proveedor principal cuando el usuario instale una tarjeta SIM con MCC o MNC.

Compatibilidad con antenas GNSS

Android 11 introduce la clase GnssAntennaInfo, que permite a tu app aprovechar mejor el posicionamiento de precisión centimétrica que puede proporcionar el sistema global de navegación por satélite (GNSS). Una vez que el usuario otorga a tu app el permiso ACCESS_FINE_LOCATION, esta puede acceder a los siguientes detalles relacionados con la antena GNSS:

  • Coordenadas de variación del centro de fase (PCO)
  • Correcciones de variación del centro de fase (PCV)
  • Correcciones de ganancia de señal

Para determinar si un dispositivo puede proporcionar información de la antena GNSS a tu app, llama al método hasGnssAntennaInfo().

Consideraciones de privacidad

  • La antena GNSS puede identificar solo el modelo del dispositivo, no un dispositivo individual.
  • Para usar la clase GnssAntennaInfo, se requiere el permiso ACCESS_FINE_LOCATION.

Gráficos

Decodificador de imágenes NDK

La API de ImageDecoder de NDK proporciona una API estándar para que las apps C/C++ de Android decodifiquen imágenes de forma directa. Los desarrolladores de aplicaciones ya no necesitan usar las API de framework (a través de JNI) ni empaquetar bibliotecas de decodificación de imágenes de terceros. Para obtener más información, consulta la Guía para desarrolladores sobre el decodificador de imágenes.

API de velocidad de fotogramas

Android 11 proporciona una API que permite que las apps informen al sistema acerca de la velocidad de fotogramas deseada para reducir la vibración en dispositivos compatibles con varias frecuencias de actualización. Para obtener información sobre cómo usar esta API, consulta la Guía de frecuencia de fotogramas.

Solicitud y comprobación de compatibilidad con la latencia baja

Algunas pantallas pueden realizar el posprocesamiento de gráficos, como ciertas pantallas y TVs externas. Este posprocesamiento mejora los gráficos, pero puede aumentar la latencia. Las pantallas más recientes compatibles con HDMI 2.1 tienen un modo de latencia baja automática (ALLM, también conocido como modo de juego), que desactiva el posprocesamiento a fin de minimizar la latencia. Para obtener más información sobre el ALLM, consulta la especificación HDMI 2.1.

Una ventana puede solicitar que se use el modo de latencia baja automática si está disponible. El ALLM es particularmente útil para apps como videoconferencias y juegos, donde la baja latencia es más importante que obtener los mejores gráficos posibles.

Para activar o desactivar el posprocesamiento mínimo, llama al método Window.setPreferMinimalPostProcessing() o establece el atributo preferMinimalPostProcessing de la ventana como true. No todas las pantallas admiten un posprocesamiento mínimo. Para averiguar si una pantalla específica lo admite, llama al nuevo método Display.isMinimalPostProcessingSupported().

Inyección de la capa de depuración de gráficos de rendimiento

Ahora las apps pueden cargar capas de gráficos externos (GLES, Vulkan) en código de aplicaciones nativas para exponer la misma funcionalidad que una app depurable, pero sin incurrir en la sobrecarga de rendimiento. Esta función es especialmente importante cuando creas el perfil de tu aplicación con herramientas como GAPID. Para crear un perfil de tu app, incluye el siguiente elemento de metadatos en el archivo del manifiesto de tu aplicación, en lugar de hacer que esta sea depurable:

<application ... >
    <meta-data android:name="com.android.graphics.injectLayers.enable"
                  android:value="true" />
</application>

ANGLE para OpenGL ES

Puedes ejecutar aplicaciones secundarias con ANGLE para evaluar el rendimiento y decidir si una app en particular debe usar ANGLE, en lugar de los controladores OpenGL ES nativos. Para obtener instrucciones, consulta Cómo usar ANGLE para OpenGL ES.

Imágenes y cámara

Silencia los sonidos y las vibraciones de las notificaciones durante la captura activa

A partir de Android 11, cuando usas activamente la cámara, tu app puede silenciar solo las vibraciones, los sonidos y las vibraciones, o bien no usar setCameraAudioRestriction().

Compatibilidad ampliada con la cámara en Android Emulator

Android 11 presenta funciones mejoradas para la cámara de Android Emulator. Entre las funciones adicionales, se incluyen las siguientes:

  • Captura de RAW
  • Reprocesamiento de YUV
  • Dispositivos de nivel 3
  • Compatibilidad con cámara lógica
  • Emulación de la orientación del sensor mediante datos del administrador de sensores
  • Aplicación de estabilización de video mediante la reducción de la frecuencia del protocolo de enlace
  • Aplicación de mejora de bordes mediante la eliminación del escalamiento en la canalización de YUV
  • Cámaras simultáneas

Compatibilidad con el uso simultáneo de más de una cámara

En Android 11, se agregaron API para admitir consultas sobre el uso de más de una cámara a la vez, incluidas las cámaras frontal y posterior.

Usa los siguientes métodos para comprobar la compatibilidad con el dispositivo en el que se ejecuta tu app:

  • getConcurrentCameraIds() muestra un Set de combinaciones de ID de cámara que pueden transmitirse de forma simultánea con combinaciones de transmisión garantizadas cuando las configura el mismo proceso de aplicación.
  • isConcurrentSessionConfigurationSupported() consulta si los dispositivos de cámara pueden admitir de forma simultánea las configuraciones de sesión correspondientes.

Mejor compatibilidad con imágenes HEIF con varios fotogramas

A partir de Android 11, si llamas a ImageDecoder.decodeDrawable() y pasas una imagen HEIF que contiene una secuencia de fotogramas (como una animación o una foto de ráfaga), el método muestra un AnimatedImageDrawable que contiene toda la secuencia de la imagen. En versiones anteriores de Android, el método mostraba un objeto BitmapDrawable de solo un fotograma.

Si el gráfico HEIF contiene varios fotogramas que no están en una secuencia, puedes recuperar un fotograma individual llamando al método MediaMetadataRetriever.getImageAtIndex().

Accesibilidad

Actualizaciones para desarrolladores de servicios de accesibilidad

Si creas un servicio de accesibilidad personalizado, puedes usar las siguientes funciones en Android 11:

  • La explicación de un servicio de accesibilidad orientado al usuario ahora admite HTML e imágenes, además de texto sin formato. Esta flexibilidad facilita la tarea de explicarles a los usuarios finales qué objetivo tiene tu servicio y cómo puede ayudarlos.
  • Para trabajar con una descripción del estado de un elemento de la IU que sea más significativo semánticamente que contentDescription, invoca el método getStateDescription().
  • Para solicitar que los eventos táctiles omitan el explorador táctil del sistema, llama al método setTouchExplorationPassthroughRegion(). Asimismo, para solicitar que los gestos eludan el detector de gestos del sistema, llama a setGestureDetectionPassthroughRegion().
  • Puedes solicitar acciones del IME, como "enter" y "next", además de capturas de pantalla de ventanas que no tienen habilitada la marca FLAG_SECURE.

Funciones adicionales

Motivos de salida del proceso de la app

Android 11 presenta el método ActivityManager.getHistoricalProcessExitReasons(), que informa los motivos de las cancelaciones de procesos recientes. Las apps pueden usarlo para recopilar información sobre el diagnóstico de fallas, por ejemplo, si la cancelación de un proceso se debe a ANR, problemas de memoria u otros motivos. Además, puedes usar el nuevo método setProcessStateSummary() a fin de almacenar información de estado personalizada para su posterior análisis.

El método getHistoricalProcessExitReasons() muestra instancias de la clase ApplicationExitInfo, que contiene información relacionada con la finalización del proceso de una app. Si llamas a getReason() en una instancia de esta clase, puedes determinar por qué se canceló el proceso de tu app. Por ejemplo, un valor de retorno de REASON_CRASH indica que se produjo una excepción no administrada en tu app. Si tu app necesita garantizar la exclusividad para los eventos de salida, puede mantener un identificador específico de la app, como un valor de hash basado en la marca de tiempo del método getTimestamp().

Cargadores de recursos

Android 11 presenta una nueva API que permite a las apps ampliar de forma dinámica la manera en que se buscan y se cargan los recursos. Las nuevas clases de API de ResourcesLoader y ResourcesProvider son las principales responsables de proporcionar la nueva funcionalidad. En conjunto, ofrecen la capacidad de proporcionar recursos y activos adicionales, o de modificar los valores de recursos y activos existentes.

Los objetos ResourcesLoader son contenedores que proporcionan objetos ResourcesProvider a la instancia de Resources de una app. A su vez, los objetos ResourcesProvider proporcionan métodos para cargar datos de recursos de APK y tablas de recursos.

Un caso práctico principal de esta API es la carga de elementos personalizados. Puedes usar loadFromDirectory() para crear un ResourcesProvider que redireccione la resolución de recursos y activos basados en archivos, lo que hace que busque un directorio específico, en lugar del APK de la aplicación. Puedes acceder a los activos a través de la familia de métodos open() de la clase de API AssetManager, al igual que con los activos empaquetados en el APK.

Esquema de firma de APK v4

En Android 11 se incluye compatibilidad con el esquema de firma de APK v4. Este esquema produce un nuevo tipo de firma en un archivo separado (apk-name.apk.idsig), pero es similar a v2 y v3. No se realizaron cambios en el APK. Este esquema es compatible con la instalación de APK de ADB incremental, lo que acelera la instalación de APK.

Filtros de intents dinámicos

Para recibir intents, una app debe declarar durante el tiempo de compilación qué tipos de datos puede recibir definiendo un filtro de intents en el manifiesto de la app. En Android 10 y versiones anteriores, las apps no tienen forma de cambiar sus filtros de intents durante el tiempo de ejecución. Es un problema para las apps de virtualización (como las máquinas virtuales y las computadoras de escritorio remoto), ya que no tienen forma de saber exactamente qué software instalará el usuario en ellas.

Android 11 presenta grupos de MIME, un elemento nuevo de manifiesto que permite a una app declarar un conjunto dinámico de tipos de MIME en un filtro de intents y modificarlo de manera programática durante el tiempo de ejecución. Para usar un grupo de MIME, incluye un elemento de datos en el manifiesto de tu app con el atributo android:mimeGroup nuevo:

<intent-filter>
  <action android:name="android.intent.action.SEND"/>
  <category android:name="android.intent.category.DEFAULT"/>
  <data android:mimeGroup="myMimeGroup"/>
</intent-filter>

El valor del atributo android:mimeGroup es un ID de string arbitrario que identifica el grupo de MIME durante el tiempo de ejecución. Para acceder a un grupo de MIME y actualizar el contenido, pasa su ID a los siguientes métodos nuevos en la clase de API PackageManager:

Cuando se agrega un tipo de MIME a un grupo de MIME de manera programática, funciona exactamente igual que un tipo de MIME estático declarado de manera explícita en el manifiesto.

Mejoras de Autocompletar

Android 11 presenta mejoras para los servicios de autocompletado.

Identificadores de sugerencia en AssistStructure.ViewNode

Los servicios de autocompletado suelen ser útiles para procesar un hash de firma para una vista basada en las propiedades de la vista. La sugerencia de vista es una propiedad que se recomienda incluir cuando se calcula un hash de firma, pero la string de sugerencia puede cambiar con la configuración regional del teléfono. Para resolver este problema, Android 11 expande AssistStructure.ViewNode con un nuevo método getHintIdEntry(), que muestra el identificador de recursos para el texto de sugerencia de una vista. Este método proporciona un valor independiente de la configuración regional que puedes usar para calcular hashes de firma.

Eventos mostrados en conjuntos de datos

Para ayudar a los servicios de autocompletado a mejorar sus sugerencias, Android 11 proporciona una forma de identificar casos en los que un servicio de autocompletado presentó conjuntos de datos, pero el usuario no seleccionó ninguno de ellos. En Android 11, FillEventHistory informa sobre un nuevo tipo de evento TYPE_DATASETS_SHOWN. FillEventHistory registra un evento de este tipo cada vez que el servicio de autocompletado presenta uno o más conjuntos de datos al usuario. Los servicios de autocompletado pueden usar estos eventos junto con el evento TYPE_DATASET_SELECTED existente para determinar si el usuario seleccionó alguna de las opciones de autocompletado.

Integración con el IME

Los teclados y otros IME ahora pueden mostrar sugerencias de autocompletado intercaladas, en una tira de sugerencias o una interfaz similar, en lugar de hacerlo en un menú desplegable. Para proteger la información sensible, como contraseñas y números de tarjetas de crédito, las sugerencias se muestran al usuario, pero el IME no las conoce hasta que el usuario selecciona una. Para obtener información sobre cómo los IME y los administradores de contraseñas pueden admitir esta función, consulta Cómo integrar el autocompletado con teclados.

Cómo compartir datos con el servicio de captura de contenido

A partir de Android 11, tu app puede compartir datos con el servicio de captura de contenido del dispositivo. Esta función facilita que un dispositivo entregue inteligencia contextual, como mostrar el nombre de una canción que se reproduce en el entorno del usuario.

A fin de que los datos de tu app estén disponibles para el servicio de captura de contenido, llama al método shareData() en una instancia de ContentCaptureManager. Si el sistema acepta la solicitud de uso compartido de datos, tu app recibirá un descriptor de archivo de solo escritura para compartir con el servicio de captura de contenido.