Cambios de comportamiento: todas las apps

La plataforma de Android 11 incluye cambios de comportamiento que podrían afectar tu app. Los siguientes cambios se aplican a todas las apps cuando se ejecutan en Android 11, independientemente de la targetSdkVersion. Debes probar tu app y, luego, modificarla según corresponda para admitir estos cambios.

Asegúrate también de revisar la lista de cambios de comportamiento que solo afectan a las apps orientadas a Android 11.

Privacidad

Android 11 introduce cambios y restricciones para mejorar la privacidad del usuario, incluidos los siguientes:

• Permisos únicos: brinda a los usuarios la opción de otorgar mayor acceso temporal a los permisos de ubicación, micrófono y cámara.
• Visibilidad del diálogo de permisos: las denegaciones repetidas de un permiso implican "no volver a preguntar".
• Auditoría de acceso a los datos: obtén estadísticas sobre dónde accede tu app a los datos privados, tanto en el propio código de la app como en el de las bibliotecas dependientes.
• Permisos de la ventana de alerta del sistema: algunas clases de apps reciben automáticamente el permiso SYSTEM_ALERT_WINDOW cuando se lo solicita. Además, los intents que incluyen la acción de intent ACTION_MANAGE_OVERLAY_PERMISSION siempre dirigen a los usuarios a una pantalla en la configuración del sistema.

Para obtener más información, visita la página Privacidad.

Seguridad

Los sockets SSL usan el motor SSL de Conscrypt de forma predeterminada

La implementación predeterminada del SSLSocket de Android se basa en Conscrypt. Desde Android 11, esa implementación se compila internamente sobre el SSLEngine de Conscrypt.

Asignador de seguridad reforzada Scudo

Android 11 usa el Asignador de seguridad reforzada Scudo de forma interna para brindar servicio a las asignaciones de montón. Scudo es capaz de detectar y mitigar algunos tipos de infracciones relacionadas con la seguridad de la memoria. Si ves fallas relacionadas con Scudo (por ejemplo, Scudo ERROR:) en informes de fallas por error en código nativo, consulta la documentación de solución de problemas de Scudo.

Estadísticas de uso de apps

Para proteger mejor a los usuarios, Android 11 almacena en el almacenamiento encriptado por credencial las estadísticas del uso que cada usuario hace de las apps. Por lo tanto, ni el sistema ni las apps pueden acceder a esos datos, a menos que isUserUnlocked() muestre true, lo que ocurre después de uno de los siguientes eventos:

• El usuario desbloquea su dispositivo por primera vez después del inicio del sistema.
• El usuario cambia a su cuenta en el dispositivo.

Si tu app ya se vincula a una instancia de UsageStatsManager, comprueba que estés invocando métodos en este objeto después de que el usuario desbloquee su dispositivo. De lo contrario, la API muestra valores nulos o vacíos.

Compatibilidad del emulador con 5G

Android 11 agrega API de 5G para permitir que tus apps incluyan funciones de vanguardia. Para probar las funciones a medida que las agregas, puedes usar las nuevas capacidades del emulador del SDK de Android. Se agregó la nueva funcionalidad en la versión 30.0.22 del emulador. Cuando se selecciona la configuración de red 5G, se establece TelephonyDisplayInfo como OVERRIDE_NETWORK_TYPE_NR_NSA, se modifica el ancho de banda estimado y puedes configurar el uso medido para verificar que tu app responda correctamente a los cambios en el estado de NET_CAPABILITY_TEMPORARILY_NOT_METERED.

Rendimiento y depuración

La llamada a la API de JobScheduler limita la depuración

Android 11 ofrece compatibilidad de depuración para apps a fin de identificar posibles invocaciones de la API JobScheduler que superaron determinados límites de frecuencia. Los desarrolladores pueden utilizar esta función para identificar posibles problemas de rendimiento. En el caso de las aplicaciones con el atributo debuggable del manifiesto establecido como verdadero, las invocaciones de la API de JobScheduler que superen los límites de frecuencia mostrarán RESULT_FAILURE. Los límites se establecen de manera que los casos prácticos legítimos no se vean afectados.

Limpiador del descriptor de archivo (fdsan)

Android 10 presentó fdsan (limpiador del descriptor de archivo). fdsan detecta el procesamiento incorrecto de la propiedad del descriptor de archivo, como, por ejemplo, "usar después de cerrar" y "cerrar dos veces". El modo predeterminado de fdsan cambia en Android 11. Ahora, se anula fdsan cuando se detecta un error; el comportamiento anterior era registrar una advertencia y continuar. Si observas fallas debido a fdsan en tu aplicación, consulta la fdsan documentation.

Accesibilidad

Los lectores de pantalla requieren definiciones de acciones de accesibilidad basadas en clics.

En versiones anteriores de Android, el marco de trabajo despachaba eventos táctiles a los widgets que no administraban correctamente las acciones de accesibilidad basadas en clics. Por lo general, estas vistas controlan directamente los eventos táctiles en lugar de registrar un objeto de escucha de clics.

A fin de crear un comportamiento más coherente en las apps que defina correctamente las acciones de accesibilidad, Android 11 nunca despacha eventos táctiles. En lugar de esto, el sistema se basa completamente en las acciones de accesibilidad basadas en clics: ACTION_CLICK y ACTION_LONG_CLICK. Este cambio afecta el comportamiento de los lectores de pantalla.

El sistema controla los widgets que usan las interfaces OnClickListener y OnLongClickListener. Sin embargo, si tu app usa un widget más personalizado que se basa en la interfaz OnTouchListener, debes definir controladores personalizados para las acciones de accesibilidad basadas en clics. Para hacerlo, llama al método replaceAccessibilityAction() de cada acción, como se muestra en el siguiente fragmento de código:

Kotlin

// Assumes that the widget is designed to select text when tapped and select
// all text when long-tapped. In its strings.xml file, this app has set
// "select" to "Select" and "select_all" to "Select all", respectively.
ViewCompat.replaceAccessibilityAction(
            WIDGET,
            ACTION_CLICK,
            context.getString(R.string.select)
) { view, commandArguments ->
    selectText()
}

ViewCompat.replaceAccessibilityAction(
            WIDGET,
            ACTION_LONG_CLICK,
            context.getString(R.string.select_all)
) { view, commandArguments ->
    selectAllText()
}

Java

// Assumes that the widget is designed to select text when tapped and select
// all text when long-tapped. In its strings.xml file, this app has set
// "select" to "Select" and "select_all" to "Select all", respectively.
ViewCompat.replaceAccessibilityAction(WIDGET, ACTION_CLICK,
        context.getString(R.string.select),
        (view, commandArguments) -> {
            selectText();
        });

ViewCompat.replaceAccessibilityAction(WIDGET, ACTION_LONG_CLICK,
        context.getString(R.string.select_all),
        (view, commandArguments) -> {
            selectAllText();
        });

Nota: Incluso en versiones anteriores de Android, debes definir acciones de accesibilidad en tus widgets personalizados para que otros servicios de accesibilidad, como el de accesibilidad mejorada, se comporten según lo esperado. Para que tu app interactúe más fácilmente con los servicios de accesibilidad del sistema, te recomendamos extender los widgets del sistema desde la jerarquía de clases de la IU de Android.

Restricciones en interfaces no SDK

Android 11 incluye listas actualizadas de este tipo de interfaces que están basadas en la colaboración con desarrolladores de Android y las pruebas internas más recientes. Siempre que sea posible, nos aseguramos de que las alternativas públicas estén disponibles antes de restringir las interfaces que no pertenecen al SDK.

Si tu app no está orientada a Android 11, es posible que algunos de estos cambios no te afecten de inmediato. Sin embargo, aunque actualmente puedes usar algunas interfaces que no pertenecen al SDK (según el nivel de API al que esté orientada la app), utilizar cualquier método o campo que no pertenezca al SDK siempre implica un gran riesgo de error para tu app.

En caso de no saber con certeza si tu app usa este tipo de interfaces, puedes probarla para verificarlo. Si tu app depende de interfaces que no pertenezcan al SDK, deberías planificar una migración hacia otras alternativas que sí lo hagan. Sin embargo, sabemos que algunas apps tienen casos prácticos válidos para usarlas. Si no encuentras una alternativa al uso de una interfaz que no pertenezca al SDK para una función de tu app, deberías solicitar una nueva API pública.

Para obtener más información sobre los cambios implementados en esta versión de Android, consulta Actualizaciones a las restricciones de interfaces que no pertenecen al SDK en Android 11. Para obtener más información sobre interfaces que no pertenecen al SDK en general, consulta Restricciones en interfaces que no pertenecen al SDK.

Se quitó la biblioteca compartida de Maps v1

Se quitó por completo la versión 1 de la biblioteca compartida de Maps en Android 11. Esta biblioteca dejó de estar disponible y de funcionar para apps en Android 10. En su lugar, las apps que antes utilizaban esta biblioteca compartida para dispositivos con Android 9 (API nivel 28) deberían usar el SDK de Maps para Android.

Importante: Después de migrar al SDK de Maps para Android, recuerda quitar la referencia a la versión 1 de la biblioteca compartida de Maps del elemento <uses-library> en el archivo de manifiesto de tu app. Las apps ya no pueden usar el filtrado de Google Play con la biblioteca compartida de Maps v1 y el elemento <uses-library>.