Cambios en el comportamiento: apps orientadas a Android 12

Al igual que las versiones anteriores, Android 12 incluye cambios de comportamiento que podrían afectar tu app. Los siguientes cambios se aplican exclusivamente a las apps orientadas a Android 12 o versiones posteriores. Si tu app está orientada a Android 12, debes modificarla para que admita estos comportamientos correctamente, cuando corresponda.

Asegúrate de revisar también la lista de cambios en el comportamiento que afectan a todas las apps que se ejecutan en Android 12.

Experiencia del usuario

Notificaciones personalizadas

En Android 12, se cambia la apariencia y el comportamiento de las notificaciones totalmente personalizadas. Antes, las notificaciones personalizadas podían usar toda el área de notificaciones y proporcionar sus propios diseños y estilos. De esta manera, se producían antipatrones que podían confundir a los usuarios y causar errores de compatibilidad en diferentes dispositivos.

En el caso de las apps orientadas a Android 12, las notificaciones con vistas de contenido personalizado ya no utilizan el área de notificaciones completa. En su lugar, el sistema aplica una plantilla estándar. Esta plantilla garantiza que las notificaciones personalizadas tengan la misma decoración que otras notificaciones en todos los estados, como el ícono y las opciones de expansión de la notificación (en el estado contraído), el ícono o el nombre de la app y la opción de contracción (en el estado de expansión). Este comportamiento es casi idéntico al comportamiento de Notification.DecoratedCustomViewStyle.

De esta manera, Android 12 permite que todas las notificaciones sean visualmente coherentes y fáciles de analizar, con una expansión de notificaciones familiar y fácil de encontrar para los usuarios.

En la siguiente ilustración, se muestra una notificación personalizada en la plantilla estándar:

Los siguientes ejemplos muestran cómo se procesarían las notificaciones personalizadas en un estado contraído y expandido:

El cambio en Android 12 afecta a las apps que definen subclases de Notification.Style personalizadas o que usan los métodos setCustomContentView(RemoteViews), setCustomBigContentView(RemoteViews) y setCustomHeadsUpContentView(RemoteViews) de Notification.Builder.

Si la app usa notificaciones totalmente personalizadas, te recomendamos que pruebes con la plantilla nueva lo antes posible.

1. Habilita el cambio de notificaciones personalizadas:

   1. Cambia el elemento targetSdkVersion de tu app a S para habilitar el nuevo comportamiento.
   2. Vuelve a compilar.
   3. Instala la app en un dispositivo o emulador que ejecute Android 12.

2. Prueba todas las notificaciones que usan vistas personalizadas a fin de asegurarte de que se vean como esperabas en el panel. Durante la prueba, ten en cuenta estas consideraciones y realiza los ajustes necesarios:

   • Cambiaron las dimensiones de las vistas personalizadas. En general, la altura otorgada a las notificaciones personalizadas es menor que antes. En el estado contraído, la altura máxima del contenido personalizado disminuyó de 106 dp a 48 dp. Además, hay menos espacio horizontal.

   • Todas las notificaciones se pueden expandir en las apps que se orientan a Android 12. Es decir, por lo general, si usas setCustomContentView, también querrás usar setBigCustomContentView para asegurarte de que los estados contraídos y expandidos sean coherentes.

   • Para asegurarte de que el estado de "Atención" se vea como esperas, no olvides aumentar la importancia del canal de notificaciones a "HIGH" (ventana emergente).

Cambios en la verificación de Android App Links

En las apps que se orientan a Android 12 o versiones posteriores, el sistema realiza varios cambios en la manera en que se verifica Android App Links. Estos cambios mejoran la confiabilidad de la experiencia de vinculación de apps y les brindan más control a los desarrolladores de apps y los usuarios finales.

Si dependes de la verificación de Android App Link para abrir vínculos web en la app, asegúrate de usar el formato correcto cuando agregues filtros de intents para esta verificación. En especial, asegúrate de que estos filtros de intents incluyan la categoría BROWSABLE y admitan el esquema https.

También puedes verificar de forma manual los vínculos de la app para probar la confiabilidad de las declaraciones.

Mejoras en el comportamiento de pantalla en pantalla

En Android 12, se introducen mejoras en el comportamiento del modo de pantalla en pantalla (PiP) y se recomiendan mejoras estéticas en las animaciones de transición para la navegación por gestos y la navegación basada en elementos.

Consulta Mejoras de pantalla en pantalla para obtener más información.

Nuevo diseño de avisos

En Android 12, se rediseñó la vista de avisos. Los avisos ahora están limitados a dos líneas de texto y muestran el ícono de la aplicación junto al texto.

Consulta Descripción general de los avisos para obtener más información.

Seguridad y privacidad

Ubicación aproximada

En los dispositivos que ejecutan Android 12 o versiones posteriores, los usuarios pueden solicitar la precisión de la ubicación aproximada de tu app.

Nuevas cookies de SameSite en WebView

El componente WebView de Android se basa en Chromium, el proyecto de código abierto que potencia el navegador Chrome de Google. Chromium introdujo cambios en el manejo de cookies de terceros con el objetivo de proporcionar mayor seguridad y privacidad, y ofrecer a los usuarios más transparencia y control. A partir de Android 12, estos cambios también se incluyen en WebView cuando las apps se orientan a Android 12 (nivel de API 31) o versiones posteriores.

El atributo SameSite de una cookie controla si se puede enviar con cualquier solicitud o solo con solicitudes del mismo sitio. Los siguientes cambios de protección de la privacidad mejoran el manejo predeterminado de cookies de terceros y protegen contra el uso compartido entre sitios no deseados:

• Las cookies que no tienen un atributo SameSite se consideran SameSite=Lax.
• Las cookies con SameSite=None también deben especificar el atributo Secure, lo que significa que requieren un contexto seguro y deben enviarse mediante HTTPS.
• Los vínculos entre las versiones HTTP y HTTPS de un sitio ahora se tratan como solicitudes entre sitios, por lo que las cookies no se envían, a menos que se marquen de forma adecuada como SameSite=None; Secure.

Para los desarrolladores, la práctica general es identificar las dependencias de cookies entre sitios en tus flujos de usuarios críticos y garantizar que el atributo SameSite esté establecido de forma explícita con los valores apropiados cuando sea necesario. Debes especificar de forma explícita las cookies que pueden funcionar en sitios web o en distintas navegaciones del mismo sitio que pasan de HTTP a HTTPS.

Si deseas obtener más información para desarrolladores web acerca de estos cambios, consulta los artículos Explicación de las cookies de SameSite y Schemeful SameSite.

Prueba los comportamientos de SameSite en tu app

Si tu app usa WebView, o si administras un sitio web o servicio que usa cookies, te recomendamos que pruebes tus flujos en WebView de Android 12. Si encuentras problemas, es posible que debas actualizar tus cookies para admitir los nuevos comportamientos de SameSite.

Observa los problemas en los accesos y el contenido integrado, en los flujos de registro, en las compras y en otros flujos de autenticación en los que el usuario comienza en una página insegura y pasa a una página segura.

Si quieres probar una app con WebView, debes completar uno de los siguientes pasos con el fin de habilitar los nuevos comportamientos de SameSite para la app que deseas probar:

• Habilita manualmente los comportamientos de SameSite en el dispositivo de prueba. Para ello, activa la marca de IU webview-enable-modern-cookie-same-site en las herramientas para desarrolladores de WebView.

  Este enfoque te permite realizar pruebas en cualquier dispositivo que ejecute Android 5.0 (nivel de API 21) o una versión posterior, incluido Android 12, y WebView versión 89.0.4385.0 o posterior.

• Compila tu app para que se oriente a Android 12 (nivel de API 31) mediante targetSdkVersion.

  Si usas este enfoque, debes usar un dispositivo que ejecute Android 12.

Para obtener información sobre la depuración remota de WebView en Android, consulta Cómo comenzar a usar los dispositivos Android de depuración remota.

Otros recursos

Para obtener más información sobre los nuevos comportamientos de SameSite y su implementación en Chrome y WebView, visita la página de actualizaciones de Chromium SameSite. Si encuentras un error en WebView o Chromium, puedes informarlo en la herramienta pública de seguimiento de errores de Chromium.

Límite de frecuencia para los sensores de movimiento

Para proteger información posiblemente sensible sobre los usuarios, si la app se orienta a Android 12 o versiones posteriores, el sistema establece un límite en la frecuencia de actualización de los datos a partir de ciertos sensores de movimiento y de posición.

Obtén más información sobre el límite de frecuencia para los sensores.

Hibernación de apps

En Android 12, se expande el comportamiento del restablecimiento automático de permisos que se introdujo en Android 11 (nivel de API 30). Si la app se orienta a Android 12 y el usuario no interactúa con ella por algunos meses, el sistema restablece automáticamente los permisos otorgados y coloca la app en un estado de hibernación.

Obtén más información en la guía sobre la hibernación de apps.

Declaración de atribución en la auditoría de acceso a los datos

La API de auditoría de acceso a los datos, que se introdujo en Android 11 (nivel de API 30), te permite crear etiquetas de atribución, según los casos de uso de la app. Estas etiquetas te permiten determinar, con mayor facilidad, qué parte de la app realiza un tipo específico de acceso a los datos.

Si la app se orienta a Android 12 o versiones posteriores, debes declarar estas etiquetas de atribución en el archivo de manifiesto de la app.

Restricción de copia de seguridad de adb

Para ayudar a proteger los datos de apps privadas, Android 12 cambia el comportamiento predeterminado del comando adb backup. En el caso de las apps orientadas a Android 12 (nivel de API 31) o versiones posteriores, cuando un usuario ejecuta el comando adb backup, los datos de la app se excluyen de otros datos del sistema que se exportan del dispositivo.

Si tus flujos de trabajo de prueba o desarrollo usan los datos de la app con adb backup, ahora puedes habilitar la exportación de los datos configurando android:debuggable como true en el archivo de manifiesto de tu app.

Exportación de componentes más segura

Si tu app está orientada a Android 12 o versiones posteriores, y contiene actividades, servicios o receptores de emisión que usan filtros de intents, debes declarar explícitamente el atributo android:exported para esos componentes de la app.

Si el componente de la app incluye la categoría LAUNCHER, establece android:exported en true. En la mayoría de los casos, establece android:exported en false.

El siguiente fragmento de código muestra un ejemplo de un servicio que contiene un filtro de intents cuyo atributo android:exported se establece en false:

<service android:name="com.example.app.backgroundService"
         android:exported="false">
    <intent-filter>
        <action android:name="com.example.app.START_BACKGROUND" />
    </intent-filter>
</service>

Mensajes en Android Studio

Si la app incluye una actividad, un servicio o un receptor de emisión que utilice filtros de intents, pero no declara android:exported, aparecen los siguientes mensajes de advertencia, según la versión de Android Studio que uses:

Android Studio 2020.3.1 Canary 11 o posterior

Se muestran los siguientes mensajes:

1. En el archivo de manifiesto, aparece la siguiente advertencia de lint:

   When using intent filters, please specify android:exported as well
   

2. Cuando intentas compilar la app, aparece el siguiente mensaje de error de compilación:

   Manifest merger failed : Apps targeting Android 12 and higher are required \
   to specify an explicit value for android:exported when the corresponding \
   component has an intent filter defined.
   

Versiones anteriores de Android Studio

Si intentas instalar la app, Logcat muestra el siguiente mensaje de error:

Installation did not succeed.
The application could not be installed: INSTALL_FAILED_VERIFICATION_FAILURE
List of apks:
[0] '.../build/outputs/apk/debug/app-debug.apk'
Installation failed due to: 'null'

Mutabilidad de PendingIntent

Si tu app está orientada a Android 12, debes especificar la mutabilidad de cada objeto PendingIntent que cree la app. Este requisito adicional mejora la seguridad de tu app.

Prueba el cambio de mutación del intent pendiente

Para determinar si falta alguna declaración de mutación en tu app, busca la siguiente advertencia de lint en Android Studio:

Warning: Missing PendingIntent mutability flag [UnspecifiedImmutableFlag]

Lanzamientos no seguros de intents

Con el objetivo de mejorar la seguridad de la plataforma, Android 12 y versiones posteriores proporcionan una función de depuración que detecta lanzamientos no seguros de intents. Cuando el sistema detecta un lanzamiento no seguro, se produce un incumplimiento de StrictMode.

Rendimiento

Restricciones para el inicio del servicio en primer plano

Las apps orientadas a Android 12 o versiones posteriores no pueden iniciar servicios en primer plano mientras se ejecutan en segundo plano, excepto en algunos casos especiales. Si una app intenta iniciar un servicio en primer plano mientras se ejecuta en segundo plano, se produce una excepción (salvo en algunos casos especiales).

Procura usar WorkManager para programar y comenzar a realizar trabajos acelerados mientras tu app se ejecuta en segundo plano. Para completar acciones urgentes que solicita el usuario, inicia los servicios en primer plano dentro de una alarma exacta.

Permiso de alarmas exactas

Con el fin de motivar que las apps conserven los recursos del sistema, las apps que se orienten a Android 12 y versiones posteriores, y que establezcan alarmas exactas, deben tener acceso a la función "Alarmas y recordatorios" que aparece en el pantalla de Acceso especial de apps en la configuración del sistema.

Para obtener este acceso especial de apps, solicita el permiso SCHEDULE_EXACT_ALARM en el manifiesto.

Las alarmas exactas solo deben usarse para las funciones para el usuario. Obtén más información sobre los casos de uso aceptables para establecer una alarma exacta.

Cómo inhabilitar el cambio de comportamiento

Mientras preparas la app para que se oriente a Android 12, puedes inhabilitar, de forma temporal, el cambio de comportamiento en la variante de compilación depurable con fines de prueba. Para hacerlo, realiza una de las siguientes tareas:

• En la pantalla de configuración Opciones para desarrolladores, selecciona Cambios de compatibilidad con apps. En la pantalla que aparece, presiona el nombre de la app y desactiva REQUIRE_EXACT_ALARM_PERMISSION.

• En una ventana de la terminal de la máquina de desarrollo, ejecuta el siguiente comando:

  adb shell am compat disable REQUIRE_EXACT_ALARM_PERMISSION PACKAGE_NAME
  

Restricciones del trampolín de notificaciones

Cuando los usuarios interactúan con las notificaciones, algunas apps responden a los toques en ellas mediante el inicio de un componente de la app que, eventualmente, inicia la actividad que el usuario ve y con la que interactúa. A este componente de app se lo conoce como trampolín de notificaciones.

Para mejorar el rendimiento y la UX de las apps, las apps orientadas a Android 12 o versiones posteriores no pueden iniciar actividades de servicios ni receptores de emisión que se usen como trampolines de notificaciones. En otras palabras, después de que el usuario presiona una notificación o un botón de acción dentro de la notificación, tu app no puede llamar a startActivity() dentro de un servicio o receptor de emisión.

Cuando tu app intenta iniciar una actividad desde un servicio o receptor de emisión que funciona como trampolín de notificaciones, el sistema impide que se inicie la actividad y aparece el siguiente mensaje en Logcat:

Indirect notification activity start (trampoline) from PACKAGE_NAME, \
this should be avoided for performance reasons.

Identifica los componentes de la app que funcionan como trampolines de notificaciones

Cuando pruebas la app, después de presionar una notificación, puedes identificar el servicio o el receptor de emisión que funcionan como el trampolín de notificaciones en la app. Para ello, consulta el resultado del siguiente comando de la terminal:

adb shell dumpsys activity service \
  com.android.systemui/.dump.SystemUIAuxiliaryDumpService

Una sección del resultado incluye el texto "NotifInteractionLog". Esta sección contiene la información necesaria para identificar el componente que se inicia como resultado de presionar una notificación.

Actualiza tu app

Si tu app inicia una actividad desde un servicio o receptor de emisión que funciona como trampolín de notificaciones, completa los siguientes pasos de migración:

1. Crea un objeto PendingIntent que esté asociado a la actividad que los usuarios ven después de presionar la notificación.
2. Usa el objeto PendingIntent que creaste en el paso anterior como parte de la compilación de tu notificación

A fin de identificar el origen de la actividad, por ejemplo, para realizar registros, usa valores adicionales cuando publiques la notificación. Para el registro centralizado, usa ActivityLifecycleCallbacks o los observadores del ciclo de vida de Jetpack.

Activa o desactiva el comportamiento

Cuando pruebas una versión depurable de la app, puedes habilitar e inhabilitar esta restricción con la marca de compatibilidad de apps NOTIFICATION_TRAMPOLINE_BLOCK.

Copia de seguridad y restablecimiento

Se realizan cambios en la manera en que funcionan la copia de seguridad y el restablecimiento en apps que se ejecutan en Android 12 (nivel de API 31) y que se orientan a esta. La copia de seguridad y el restablecimiento de Android tienen dos formatos:

• Copias de seguridad en la nube: Los datos del usuario se almacenan en Google Drive de un usuario para que después se puedan restablecer en ese dispositivo o en uno nuevo.
• Transferencias de un dispositivo a otro (D2D): Los datos del usuario se envían directamente a su dispositivo nuevo desde su dispositivo anterior, por ejemplo, mediante un cable.

Para obtener más información sobre cómo se crean copias de seguridad de los datos y se restablecen, consulta Cómo crear una copia de seguridad automática de los datos del usuario y Cómo crear una copia de seguridad de los pares clave-valor con Android Backup Service.

Cambios en la funcionalidad de la transferencia de D2D

Apps que se ejecutan en Android 12 y versiones posteriores, y se orientan a estas:

• Si especificas las reglas de inclusión y exclusión con el mecanismo de configuración de XML, no se afectará a las transferencias de D2D, aunque sí a las copias de seguridad y el restablecimiento basados en la nube (como las copias de seguridad de Google Drive). Si deseas especificar reglas para las transferencias de D2D, debes usar la configuración nueva, que se trata en la siguiente sección.

• En los dispositivos de algunos fabricantes, si especificas android:allowBackup="false", se inhabilitan las copias de seguridad en Google Drive, pero no las transferencias de D2D para la app.

Formato nuevo de inclusión y exclusión

Las apps que se ejecutan en Android 12 y versiones posteriores, y se orienten a estas usan un formato diferente para la configuración de XML. Este formato logra que sea explícita la diferencia entre la copia de seguridad en Google Drive y la transferencia de D2D, ya que requiere que especifiques por separado las reglas de inclusión y exclusión para las copias de seguridad en la nube y para las transferencias de D2D.

De forma opcional, también puedes usar este formato con el fin de especificar reglas para las copias de seguridad; en ese caso, se ignora la configuración que se usó anteriormente en dispositivos que se ejecutan en Android 12 o versiones posteriores. Todavía se necesita la configuración anterior para dispositivos que ejecutan Android 11 o versiones anteriores.

Cambios en el formato XML

El siguiente formato se usa para configurar las copias de seguridad y el restablecimiento en Android 11 y versiones anteriores:

<full-backup-content>
    <include domain=["file" | "database" | "sharedpref" | "external" |
                     "root"] path="string"
    requireFlags=["clientSideEncryption" | "deviceToDeviceTransfer"] />
    <exclude domain=["file" | "database" | "sharedpref" | "external" |
                     "root"] path="string" />
</full-backup-content>

A continuación, se muestran en negrita los cambios en el formato.

<data-extraction-rules>
  <cloud-backup [disableIfNoEncryptionCapabilities="true|false"]>
    ...
    <include domain=["file" | "database" | "sharedpref" | "external" |
                        "root"] path="string"/>
    ...
    <exclude domain=["file" | "database" | "sharedpref" | "external" |
                        "root"] path="string"/>
    ...
  </cloud-backup>
  <device-transfer>
    ...
    <include domain=["file" | "database" | "sharedpref" | "external" |
                        "root"] path="string"/>
    ...
    <exclude domain=["file" | "database" | "sharedpref" | "external" |
                        "root"] path="string"/>
    ...
  </device-transfer>
</data-extraction-rules>

Si deseas obtener más información, consulta la sección correspondiente en la guía para crear una copia de seguridad de los datos del usuario con la copia de seguridad automática.

Marca del manifiesto para apps

Orienta las apps a la configuración nueva de XML mediante el atributo android:dataExtractionRules en el archivo de manifiesto. Cuando lo haces, se ignora el atributo android:fullBackupContent que se orienta a la configuración anterior en dispositivos que ejecutan Android 12 o versiones posteriores. En la siguiente muestra de código, se observan las entradas nuevas en el archivo de manifiesto:

<application
    ...
    <!-- The below attribute is ignored. -->
    android:fullBackupContent="old_config.xml"
    <!-- You can point to your new configuration using the new
         dataExtractionRules attribute . -->
    android:dataExtractionRules="new_config.xml"
    ...>
</application>

Conectividad

Permisos de Bluetooth

En Android 12, se introducen los permisos BLUETOOTH_SCAN, BLUETOOTH_ADVERTISE y BLUETOOTH_CONNECT. Estos permisos facilitan la interacción con dispositivos Bluetooth para las apps que se orientan a Android 12, en especial para las que no requieren acceso a la ubicación del dispositivo.

Si deseas preparar el dispositivo para que se oriente a Android 12 o versiones posteriores, actualiza la lógica de la app. En lugar de declarar un conjunto heredado de permisos de Bluetooth, declara un conjunto más moderno de estos.

Conexión simultánea a Internet y entre pares

Para las apps que se orienten a Android 12 (nivel de API 31) o versiones posteriores, los dispositivos compatibles con conexiones simultáneas a Internet y entre pares pueden mantener, a la vez, conexiones Wi-Fi al dispositivo de intercambio de tráfico y a la red principal de Internet, lo que permite que la experiencia del usuario sea más fluida. Las apps que se orientan a Android 11 (nivel de API 30) o versiones anteriores todavía experimentan el comportamiento heredado, en el que la red Wi-Fi principal se desconecta antes de conectarse al dispositivo de intercambio de tráfico.

Compatibilidad

WifiManager.getConnectionInfo() puede mostrar WifiInfo para una sola red. Como consecuencia, en Android 12 y versiones posteriores, el comportamiento de la API se modificó de las siguientes maneras:

• Si solo hay una red Wi-Fi disponible, se mostrará WifiInfo.
• Si hay más de una red Wi-Fi disponible y la app que realiza la llamada activó una conexión entre pares, se muestra el objeto WifiInfo que corresponde al dispositivo de intercambio de tráfico.
• Si hay más de una red Wi-Fi disponible y la app que realiza la llamada no activó una conexión entre pares, se muestra el objeto WifiInfo de la conexión principal de Internet.

Con el fin de ofrecer una mejor experiencia del usuario en dispositivos compatibles con redes Wi-Fi simultáneas de doble banda, recomendamos que todas las apps, en especial las que activan conexiones entre pares, migren para evitar llamar a WifiManager.getConnectionInfo(). En su lugar, usa NetworkCallback.onCapabilitiesChanged() a fin de obtener todos los objetos WifiInfo que coincidan con el objeto NetworkRequest que se usa para registrar NetworkCallback. A partir de Android 12, getConnectionInfo() dejó de estar disponible.

En la siguiente muestra de código, se observa cómo obtener WifiInfo en NetworkCallback:

val networkCallback = object : ConnectivityManager.NetworkCallback() {
  ...
  override fun onCapabilitiesChanged(
           network : Network,
           networkCapabilities : NetworkCapabilities) {
    val transportInfo = networkCapabilities.getTransportInfo()
    if (transportInfo !is WifiInfo) return
    val wifiInfo : WifiInfo = transportInfo
    ...
  }
}

final NetworkCallback networkCallback = new NetworkCallback() {
  ...
  @Override
  public void onCapabilitiesChanged(
         Network network,
         NetworkCapabilities networkCapabilities) {
    final TransportInfo transportInfo = networkCapabilities.getTransportInfo();
    if (!(transportInfo instanceof WifiInfo)) return;
    final WifiInfo wifiInfo = (WifiInfo) transportInfo;
    ...
  }
  ...
};

API nativa de mDNSResponder

Android 12 cambia el momento en que pueden interactuar las apps con el daemon mDNSResponder mediante la API nativa de mDNSResponder. Anteriormente, cuando una app registraba un servicio en la red y llamaba al método getSystemService(), el servicio de NSD del sistema iniciaba el daemon mDNSResponder, incluso si la app todavía no había llamado a ningún método NsdManager. Luego, el daemon suscribía el dispositivo a los grupos de multidifusión de todos los nodos, lo que provocaba que el sistema se activara con más frecuencia y usara energía adicional. A fin de minimizar el uso de la batería, en Android 12 y versiones posteriores, el sistema ahora inicia el daemon mDNSResponder solo cuando es necesario para los eventos de NSD y lo detiene después.

Como este cambio produce efectos cuando está disponible el daemon mDNSResponder, las apps que consideren que este daemon se iniciará después de llamar al método getSystemService() podrían recibir mensajes del sistema que notifiquen que el daemon mDNSResponder no está disponible. Este cambio no afecta a las apps que usan NsdManager y no usan la API nativa de mDNSResponder.

Bibliotecas de proveedores

Bibliotecas nativas compartidas que proporcionan los proveedores

De forma predeterminada, no se puede acceder a las bibliotecas nativas compartidas que no pertenecen al NDK que proporcionan proveedores de silicio o fabricantes de dispositivos si la app se orienta a Android 12 (nivel de API 31) o versiones posteriores. Solo se puede acceder a las bibliotecas cuando se solicitan de manera explícita con la etiqueta <uses-native-library>.

Si la app se orienta a Android 11 (nivel de API 30) o versiones anteriores, no se requiere la etiqueta <uses-native-library>. En ese caso, se puede acceder a cualquier biblioteca nativa compartida, independientemente de si es una biblioteca de NDK.

Actualización de restricciones que no pertenecen al SDK

Android 12 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 12, 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 pertenece 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 12. Para obtener más información sobre interfaces que no pertenecen al SDK en general, consulta Restricciones en interfaces que no pertenecen al SDK.