Descripción general de las funciones y API

Android 12 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. A fin de 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 12 para apps orientadas a Android 12 y todas las apps.

Nuevas experiencias

Mejoras de widgets

Android 12 renovó la API de Widgets existente para mejorar la experiencia del usuario y del desarrollador en la plataforma y los launchers. Creamos una guía para ayudarte a que te asegures de que el widget sea compatible con Android 12 y para actualizarlo con funciones nuevas.

Consulta Mejoras de widgets en Android 12 para obtener más información.

Efecto táctil vinculado con audio

Las apps de Android 12 pueden generar respuestas táctiles derivadas de una sesión de audio mediante el vibrador del teléfono, lo cual proporciona una oportunidad para experiencias de juego y audio más envolventes. Por ejemplo, los tonos mejorados con respuesta táctil pueden ayudar a identificar a los emisores, o un juego de conducción podría simular la sensación de un terreno empinado.

Consulta la documentación de referencia de HapticGenerator para obtener más información.

API de pantalla de presentación

En Android 12, se introduce una animación nueva de inicio para todas las apps, la cual incluye un movimiento de entrada a la app desde el punto de inicio, una pantalla de presentación que muestra el ícono de la app y una transición a la app en sí misma. Consulta la API de pantalla de presentación para obtener más información.

Notificaciones nuevas de llamadas telefónicas que permiten clasificar la importancia de las llamadas entrantes

En Android 12, se agrega el estilo nuevo de notificación Notification.CallStyle para llamadas telefónicas. Usar esta plantilla permite que la app indique la importancia de las llamadas activas. Para ello, muestra un chip destacado que indica la hora de la llamada en la barra de estado; el usuario puede presionar este chip si desea volver a la llamada.

Como las llamadas entrantes y en curso son las más relevantes para los usuarios, estas notificaciones se clasifican, y se muestran las principales en el panel. Esta clasificación también permite que, posiblemente, el sistema desvíe estas llamadas con prioridad a otros dispositivos.

Implementa el siguiente código para todos los tipos de llamadas.

Kotlin

// Create a new call with the user as caller.
val incoming_caller = Person.Builder()
    .setName("Jane Doe")
    .setImportant(true)
    .build()

Java

// Create a new call with the user as caller.
Person incoming_caller = new Person.Builder()
    .setName("Jane Doe")
    .setImportant(true)
    .build();

Usa forIncomingCall() a fin de crear una notificación con estilo para una llamada entrante.

Kotlin

// Create a call style notification for an incoming call.
val builder = Notification.Builder(context, CHANNEL_ID)
    .setContentIntent(contentIntent)
    .setSmallIcon(smallIcon)
    .setStyle(
         Notification.CallStyle.forIncomingCall(caller, declineIntent, answerIntent))
    .addPerson(incoming_caller)

Java

// Create a call style notification for an incoming call.
Notification.Builder builder = Notification.Builder(context, CHANNEL_ID)
    .setContentIntent(contentIntent)
    .setSmallIcon(smallIcon)
    .setStyle(
        Notification.CallStyle.forIncomingCall(caller, declineIntent, answerIntent))
    .addPerson(incoming_caller);

Usa forOngoingCall() a fin de crear una notificación con estilo para una llamada en curso.

Kotlin

// Create a call style notification for an ongoing call.
val builder = Notification.Builder(context, CHANNEL_ID)
    .setContentIntent(contentIntent)
    .setSmallIcon(smallIcon)
    .setStyle(
         Notification.CallStyle.forOnGoingCall(caller, hangupIntent))
    .addPerson(second_caller)

Java

// Create a call style notification for an ongoing call.
Notification.Builder builder = Notification.Builder(context, CHANNEL_ID)
    .setContentIntent(contentIntent)
    .setSmallIcon(smallIcon)
    .setStyle(
        Notification.CallStyle.forOnGoingCall(caller, hangupIntent))
    .addPerson(second_caller);

Usa forScreeningCall() a fin de crear una notificación con estilo para filtrar una llamada.

Kotlin

// Create a call style notification for screening a call.
val builder = Notification.Builder(context, CHANNEL_ID)
    .setContentIntent(contentIntent)
    .setSmallIcon(smallIcon)
    .setStyle(
         Notification.CallStyle.forScreeningCall(caller, hangupIntent, answerIntent))
    .addPerson(second_caller)

Java

Notification.Builder builder = Notification.Builder(context, CHANNEL_ID)
    .setContentIntent(contentIntent)
    .setSmallIcon(smallIcon)
    .setStyle(
        Notification.CallStyle.forScreeningCall(caller, hangupIntent, answerIntent))
    .addPerson(second_caller);

Compatibilidad con imágenes mejoradas para notificaciones

En Android 12, ahora, puedes mejorar la experiencia de notificaciones de la app con imágenes animadas en las notificaciones de MessagingStyle() y BigPictureStyle(). Además, la app ahora puede permitir que los usuarios envíen mensajes de imagen cuando responden mensajes desde el panel de notificaciones.

API de esquinas redondeadas

En Android 12, se introducen RoundedCorner y WindowInsets.getRoundedCorner(int position), que brindan el radio y el punto central de las esquinas redondeadas. Con estas API, la app puede evitar que los elementos de la IU se trunquen en pantallas con esquinas redondeadas.

Cuando estas API se implementan en la app, no producen efectos en los dispositivos con pantallas sin esquinas redondeadas.

Imagen que muestra las esquinas redondeadas con los radios y un punto central

Para implementar esta función, obtén la información de RoundedCorner mediante WindowInsets.getRoundedCorner(int position) en relación con los límites de la aplicación. Si la app no ocupa toda la pantalla, para aplicar la esquina redondeada, la API basa el punto central de este tipo de esquina en los límites de la ventana de la app.

En el siguiente fragmento de código, se muestra un ejemplo simple de cómo usar una app a fin de evitar los truncamientos de la IU. Para ello, configura un margen de la vista en función de la información de RoundedCorner. En este caso, es la esquina redondeada superior derecha.

// Get the top-right rounded corner from WindowInsets.
final WindowInsets insets = getRootWindowInsets();
final RoundedCorner topRight = insets.getRoundedCorner(POSITION_TOP_RIGHT);
if (topRight == null) {
   return;
}

// Get the location of the close button in window coordinates.
int [] location = new int[2];
closeButton.getLocationInWindow(location);
final int buttonRightInWindow = location[0] + closeButton.getWidth();
final int buttonTopInWindow = location[1];

// Find the point on the quarter circle with a 45 degree angle.
final int offset = (int) (topRight.getRadius() * Math.sin(Math.toRadians(45)));
final int topBoundary = topRight.getCenter().y - offset;
final int rightBoundary = topRight.getCenter().x + offset;

// Check whether the close button exceeds the boundary.
if (buttonRightInWindow < rightBoundary && buttonTopInWindow > topBoundary) {
   return;
}

// Set the margin to avoid truncating.
int [] parentLocation = new int[2];
getLocationInWindow(parentLocation);
FrameLayout.LayoutParams lp = (FrameLayout.LayoutParams) closeButton.getLayoutParams();
lp.rightMargin = Math.max(buttonRightInWindow - rightBoundary, 0);
lp.topMargin = Math.max(topBoundary - buttonTopInWindow, 0);
closeButton.setLayoutParams(lp);

Mejoras de pantalla en pantalla (PiP)

En Android 12, se introducen funciones nuevas para el modo de pantalla en pantalla (PiP). Consulta Mejoras de pantalla en pantalla para obtener más información.

Mejoras en el modo envolvente para la navegación por gestos

Android 12 simplifica el modo envolvente para facilitar la navegación por gestos y mantener la coherencia con el resto de la experiencia de actividades, como mirar un video y leer un libro. Las apps pueden protegerse de los gestos accidentales en las experiencias de juego de pantalla completa, de manera que los usuarios no salgan accidentalmente de las apps durante una partida. Todas las demás experiencias envolventes en pantalla completa ahora permiten a los usuarios navegar por su teléfono con solo deslizar el dedo.

A fin de lograr esto, los comportamientos existentes para experiencias envolventes no fijas (BEHAVIOR_SHOW_BARS_BY_TOUCH, BEHAVIOR_SHOW_BARS_BY_SWIPE) dejaron de estar disponibles a partir de Android 12. Se reemplazaron por el comportamiento predeterminado (BEHAVIOR_DEFAULT) que permite gestos con un deslizamiento cuando oculta las barras del sistema. Esta marca muestra diferentes comportamientos visuales y funcionales según el modo:

  • En el modo de tres botones, el comportamiento visual y funcional es el mismo que el modo envolvente en versiones anteriores a Android 12.
  • En el modo de navegación por gestos, el comportamiento es el siguiente:
    • Visualmente, es lo mismo que el modo envolvente en Android 11 y versiones anteriores.
    • En cuanto a la funcionalidad, se permiten los gestos incluso cuando la barra está oculta, el sistema requiere solo un deslizamiento para invocar elementos en lugar de los dos deslizamientos que se necesitan con Android 11. No se requieren deslizamientos adicionales para bajar la barra de notificaciones o ir a la página principal.

El modo envolvente fijo (BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE) no cambió en Android 12. Ten en cuenta la siguiente retrocompatibilidad con esta función:

  • Apps que se ejecutan en Android 12 y están orientadas a Android 11 y versiones anteriores:
    • BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE se comporta de la misma manera en cuanto a lo visual y lo funcional.
    • La configuración predeterminada se mapea a BEHAVIOR_SHOW_BARS_BY_SWIPE.
  • Apps que se ejecutan en Android 11 (nivel de API 30) y versiones anteriores que se orientan a Android 12:

Inserción de contenido enriquecido

Android 12 introduce una nueva API unificada que te permite recibir contenido enriquecido de cualquier fuente disponible: portapapeles, teclado o arrastrar y soltar.

Si quieres obtener más información, consulta API unificada para recibir contenido.

Cámara

Compatibilidad con sensores Quad Bayer de la cámara

En la actualidad, muchos dispositivos Android incluyen sensores de la cámara de ultraalta resolución, por lo general, con patrones Quad/Nona Baker, y estos ofrecen gran flexibilidad en términos de calidad de imagen y rendimiento con poca luz. En Android 12, se introducen API nuevas de plataforma que permiten que las apps de terceros aprovechen al máximo estos sensores versátiles. Las API nuevas admiten el comportamiento único de estos sensores y tienen en cuenta la posibilidad de que sean compatibles con diferentes configuraciones y combinaciones de transmisión cuando funcionan en modo de resolución completa o "resolución máxima" en comparación con el modo "predeterminado".

Imágenes y gráficos

Bríndales a las apps acceso directo a los seguimientos de tombstone

A partir de Android 12, puedes acceder a la tombstone de fallas por error en código nativo de la app como un búfer de protocolo mediante el método ApplicationExitInfo.getTraceInputStream(). El búfer de protocolo se serializa con este esquema. Anteriormente, la única manera de obtener acceso a esta información era mediante Android Debug Bridge (adb).

Este es un ejemplo de cómo implementarla en la app:

ActivityManager activityManager: ActivityManager = getSystemService(Context.ACTIVITY_SERVICE);
MutableList<ApplicationExitInfo> exitReasons = activityManager.getHistoricalProcessExitReasons(/* packageName = */ null, /* pid = */ 0, /* maxNum = */ 5);
for ( ApplicationExitInfo aei: exitReasons ) {
    if ( aei.getReason() == REASON_CRASH_NATIVE ) {
        // Get the tombstone input stream.
        InputStream tombstoneInputStream = aei.getTraceInputStream();
        // The tombstone parser built with protoc uses the tombstone schema, then parses the trace.
        Tombstone tombstone = Tombstone.parseFrom(trace);
    }
}

Compatibilidad con imágenes AVIF

Android 12 introduce compatibilidad con imágenes que usan el formato de archivo de imagen AV1 (AVIF). AVIF es un formato de contenedor para imágenes y secuencias de imágenes codificadas con AV1. Aprovecha el contenido codificado en el marco de la compresión de video. Mejora notablemente la calidad de imagen para el mismo tamaño de archivo en comparación con formatos de imagen más antiguos, como JPEG. Si quieres obtener más información sobre las ventajas de este formato, consulta la entrada de blog de Jake Archibald.

Difuminación, filtros de color y otros efectos más sencillos

En Android 12, se agrega la clase RenderEffect nueva, que aplica efectos frecuentes de gráficos, como difuminación, filtros de color, efectos de sombreador de Android, etc., en objetos View y jerarquías de renderización. Los efectos pueden combinarse como efectos en cadena (que crean un efecto interno y externo) o efectos combinados. Es posible que los diferentes dispositivos Android no admitan la función debido a la potencia limitada de procesamiento.

También se pueden aplicar los efectos a la clase RenderNode subyacente para View mediante una llamada a View.setRenderEffect(RenderEffect).

En el siguiente ejemplo de código, se muestra cómo implementar RenderEffect:

view.setRenderEffect(RenderEffect.createBlurEffect(radiusX, radiusY, SHADER_TILE_MODE))

Decodificación de imágenes animadas nativas

En Android 12, se expandió la API ImageDecoder del NDK para decodificar todos los marcos y los datos de sincronización de las imágenes que usan formatos de archivo GIF y WebP animados. Cuando se introdujo en Android 11, esta API decodificaba solo la primera imagen de las animaciones en estos formatos.

Usa ImageDecoder en lugar de bibliotecas de terceros para reducir el tamaño del APK y aprovechar las actualizaciones futuras relacionadas con la seguridad y el rendimiento.

Para obtener más información sobre la API, consulta la referencia y el ejemplo en GitHub.

Multimedia

Transcodificación de contenido multimedia compatible

Android 12 puede transcodificar automáticamente los videos HEVC (H.265) y HDR (HDR10 y HDR10+) grabados en el dispositivo a AVC (H.264), un formato ampliamente compatible con los jugadores estándar. Aprovecha los códecs modernos cuando están disponibles sin sacrificar la compatibilidad con las aplicaciones más antiguas.

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

Clase de rendimiento

A partir de Android 12, Android introduce un estándar que se denomina clase de rendimiento. Una clase de rendimiento especifica las capacidades de hardware más allá de los requisitos del modelo de referencia de Android. Cada dispositivo Android declara la clase de rendimiento que admite. Los desarrolladores pueden verificar la clase de rendimiento del dispositivo en el tiempo de ejecución y ofrecer experiencias mejoradas que aprovechen al máximo las capacidades del dispositivo.

Consulta Clase de rendimiento para obtener más información.

Mejoras de codificación de video

En Android 12, se define un conjunto estándar de claves a fin de controlar el valor del parámetro de cuantización (QP) para la codificación de video, lo que les permite a los desarrolladores evitar el código específico del proveedor.

Las claves nuevas están disponibles en la API de MediaFormat, además de en la biblioteca de medios del NDK.

A partir de los codificadores de video de Android 12, se aplica de manera forzosa un umbral mínimo de calidad. De esta manera, se garantiza que los usuarios no experimenten una calidad extremadamente baja cuando codifiquen videos con una complejidad alta de escena.

Enfoque de audio

A partir de Android 12, cuando una app solicita el foco de audio mientras otra en reproducción lo tiene, el marco de trabajo aplica un fundido de salida en la app en reproducción.

Consulta Mejoras de foco de audio para obtener más información.

Actualizaciones de MediaDrm

Para determinar si se requiere un componente de decodificador seguro con las API actuales de MediaDrm, debes seguir estos pasos:

  1. Crea un elemento MediaDrm.
  2. Abre una sesión para obtener un ID.
  3. Crea MediaCrypto con el ID de sesión.
  4. Llamar a MediaCrypto.requiresSecureDecoderComponent(mimeType)

Con los métodos nuevos requiresSecureDecoder(@NonNull String mime) y requiresSecureDecoder(@NonNull String mime, @SecurityLevel int level), puedes determinarlo en cuanto crees MediaDrm.

Seguridad y privacidad

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.

Obtén más información en la guía sobre los permisos nuevos de Bluetooth.

Panel de privacidad

En un cronograma vertical, se muestran las diferentes apps que accedieron a la información de la ubicación y la hora en la que se produjo el acceso.
Figura 1: Pantalla de uso de la ubicación, parte del panel de privacidad

En los dispositivos compatibles con Android 12, aparece una pantalla del panel de privacidad en la configuración del sistema. En esta pantalla, los usuarios pueden acceder a distintas pantallas que se muestran cuando las apps acceden a la información de la ubicación, la cámara y el micrófono. En cada una, se muestra un cronograma del momento en que diferentes apps accedieron a un tipo específico de datos. En la figura 1, se muestra el cronograma de acceso a los datos para la información de la ubicación.

La app puede mostrarles los motivos a los usuarios para que comprendan por qué la app accede a la información de la ubicación, la cámara o el micrófono. Estos motivos pueden aparecer en la pantalla nueva del panel de privacidad, en la pantalla de permisos de la app o en ambas.

Muestra los motivos del acceso a los datos

Para explicar por qué la app accede a la información de la ubicación, la cámara y el micrófono, sigue estos pasos:

  1. Agrega una actividad que, cuando se inicie, brinde algún motivo que explique por qué la app realiza un tipo particular de acción para acceder a datos.

    Si la app se orienta a Android 12 o versiones posteriores, debes definir un valor para el atributo android:exported de forma explícita.

  2. Agrega el siguiente filtro de intents a la actividad recién añadida:

    <!-- android:exported required if you target Android 12. -->
    <activity android:name=".DataAccessRationaleActivity"
              android:permission="android.permission.START_VIEW_PERMISSION_USAGE"
              android:exported="true">
           <!-- VIEW_PERMISSION_USAGE shows a selectable information icon on
                your app permission's page in system settings.
                VIEW_PERMISSION_USAGE_FOR_PERIOD shows a selectable information
                icon on the Privacy Dashboard screen. -->
        <intent-filter
           android:action="android.intent.action.VIEW_PERMISSION_USAGE"
           android:action="android.intent.action.VIEW_PERMISSION_USAGE_FOR_PERIOD" ... >
        </intent-filter>
    </activity>
    
  3. Decide qué debe mostrar la actividad de los motivos del acceso a tus datos. Por ejemplo, puedes mostrar el sitio web de la app o un artículo del Centro de ayuda. Para brindar una explicación más detallada sobre los tipos de datos a los que accede la app y el momento en que se produjo este acceso, controla los valores adicionales que el sistema incluye cuando invoca el intent de uso de permisos:

Según los filtros de intents que agregues, los usuarios verán un ícono de información junto al nombre de la app en determinadas pantallas:

  • Si agregas el filtro de intents que incluye la acción VIEW_PERMISSION_USAGE, los usuarios verán el ícono en la página de permisos de la app en la configuración del sistema.
  • Si agregas el filtro de intents que incluye la acción VIEW_PERMISSION_USAGE_FOR_PERIOD, los usuarios verán el ícono junto al nombre de la app cada vez que esta aparezca en la pantalla del panel de privacidad.

Cuando los usuarios seleccionan ese ícono, se inicia la actividad de los motivos de la app.

Oculta ventanas de superposición de aplicaciones

A fin de brindarles a los desarrolladores más control sobre el contenido que ven los usuarios cuando interactúan con la app del desarrollador, en Android 12, se introduce la habilidad de ocultar ventanas de superposición que dibujan las apps con el permiso SYSTEM_ALERT_WINDOW..

Después de declarar el permiso HIDE_OVERLAY_WINDOWS, una app puede llamar a setHideOverlayWindows() para indicar que todas las ventanas de tipo TYPE_APPLICATION_OVERLAY deben ocultarse cuando la propia ventana de la app está visible. Las apps pueden decidir hacerlo cuando muestran pantallas sensibles, como flujos de confirmación de transacciones.

Las apps que muestran ventanas del tipo TYPE_APPLICATION_OVERLAY deben tener en cuenta alternativas que sean más apropiadas para su caso de uso, como pantalla en pantalla o burbujas.

Marca de protección de permisos de firmantes conocidos

En Android 12, se introduce el atributo knownCerts para los permisos de nivel de firma. Con este atributo, puedes hacer referencia a los resúmenes de los certificados de firma conocidos en el momento de la declaración.

La app puede declarar este atributo y usar la marca knownSigner nueva en el atributo protectionLevel para un permiso determinado de nivel de firma. Cuando la app lo hace, el sistema le otorga permiso a la app que realiza la solicitud si algún firmante en el linaje de firmas de la app, incluido el firmante actual, coincide con uno de los resúmenes que se declaró con el permiso en el atributo knownCerts

La marca knownSigner permite que los dispositivos y las apps les otorguen permisos de firma a otras apps sin tener que firmarlas en el momento de la fabricación y el envío de los dispositivos.

Certificación de propiedades del dispositivo

Android 12 expande el conjunto de apps que pueden verificar las propiedades del dispositivo que se encuentran en un certificado de atestación cuando estas apps generan una clave nueva.

A partir de Android 9 (nivel de API 28), los propietarios de las políticas del dispositivo (DPO) que usan Keymaster 4.0 o versiones posteriores pueden verificar las propiedades del dispositivo en estos certificados de atestación. A partir de Android 12, cualquier app que se oriente a Android 12 puede realizar esta verificación con el método setDevicePropertiesAttestationIncluded().

Las propiedades del dispositivo generadas incluyen los siguientes campos Build:

  • BRAND
  • DEVICE
  • MANUFACTURER
  • MODEL
  • PRODUCT

Protege las acciones de notificación de la pantalla de bloqueo

En Android 12, la marca nueva setAuthenticationRequired se agrega a Notification.Action.Builder. Esta marca te permite agregar una capa de seguridad adicional a las notificaciones en dispositivos bloqueados.

Cuando esta marca se aplica con un valor de true a una acción de notificación determinada, un usuario que invoca esa acción en un dispositivo bloqueado siempre genera una solicitud de autenticación. Anteriormente, el sistema solicitaba la autenticación en dispositivos bloqueados solo si el usuario, cuando invocaba una acción de notificación, iniciaba una actividad o redactaba una respuesta directa.

Para implementar esta función, agrega setAuthenticationRequired a una acción de notificación:

Notification n1 = new Notification.Builder(context, NotificationListenerVerifierActivity.TAG)
...
.addAction(new Notification.Action.Builder(R.drawable.ic_stat_charlie,
context.getString(R.string.action_test_title), makeBroadcastIntent(context))

// Make sure this notification action will always request authentication when
// invoked from a lock screen
.setAuthenticationRequired(true).build())

.build();

Conectividad

Mejoras en la estimación del ancho de banda

En Android 12, se mejoran las capacidades de estimación del ancho de banda que proporcionan getLinkDownstreamBandwidthKbps() y getLinkUpstreamBandwidthKbps() para Wi-Fi y conexión móvil. Ahora, los valores que se muestran representan la capacidad promedio y ponderada de procesamiento por proveedor o SSID Wi-Fi, tipo de red y nivel de señal, con la que cuenta el usuario en todo momento, en todas las aplicaciones del dispositivo. De esa manera, es posible mostrar una estimación más precisa y realista de la capacidad de procesamiento esperada, y proporcionar estimaciones sobre un inicio en frío de la aplicación, y se requieren menos ciclos en comparación con el uso de otros métodos de estimación de este tipo de capacidad.

Mantén activas las apps complementarias

A fin de brindar compatibilidad con la necesidad de que las apps complementarias continúen ejecutándose para administrar el dispositivo, en Android 12, se introducen API que hacen lo siguiente:

  • Te permiten activar una app cuando un dispositivo complementario se encuentra dentro del alcance.
  • Garantizan que el proceso continuará ejecutándose mientras el dispositivo permanezca dentro del rango

Para usar las API, los dispositivos deben estar conectados mediante el administrador de dispositivo complementario. Para obtener más información, consulta CompanionDeviceManager.startObservingDevicePresence() y CompanionDeviceService.onDeviceAppeared().

Perfiles del administrador de dispositivo complementario

Ahora, las apps asociadas que se orientan a Android 12 y versiones posteriores pueden usar perfiles de dispositivos complementarios cuando se conectan a un reloj. Usar un perfil simplifica el proceso de inscripción, ya que se agrupa en un solo paso el otorgamiento de un conjunto de permisos específicos del tipo de dispositivo.

Captura de pantalla de un teléfono que muestra un mensaje en el que se ofrece otorgar permisos

Los permisos agrupados se le otorgan a la app complementaria una vez que se conecta el dispositivo y solo duran el tiempo en el que esté asociado. Borrar la app o quitar la asociación elimina los permisos.

Para obtener más información, consulta AssociationRequest.Builder.setDeviceProfile().

Mejoras de Wi-Fi Aware (NAN)

En Android 12, se agregaron algunas mejoras a Wi-Fi Aware:

  • En dispositivos que ejecutan Android 12 y versiones posteriores, puedes usar la devolución de llamada onServiceLost() para recibir una alerta cuando tu app pierda un servicio detectado dado que dejó de funcionar o salió del rango de alcance.
  • Cambiará la forma en que están configuradas varias rutas de datos (rutas de datos NAN) para que resulten más eficientes. Las versiones anteriores usaban mensajería L2 para intercambiar información de pares de los iniciadores, lo que introdujo la latencia. En los dispositivos que ejecutan Android 12 y versiones posteriores, la respuesta (servidor) se puede configurar para aceptar cualquier par, es decir, no necesita conocer la información del iniciador de antemano. De esta manera, se acelera la aparición de la ruta de datos y se habilitan varios vínculos de punto a punto con una sola solicitud de red.
  • Para evitar que el marco de trabajo rechace las solicitudes de detección o conexión debido a la falta de recursos, en dispositivos que ejecutan Android 12 y versiones posteriores, puedes llamar a WifiAwareManager.getAvailableAwareResources(). El valor de retorno de este método te permite obtener la cantidad de rutas de datos, de sesiones de publicación y de sesiones de suscripción disponibles.

Conexión simultánea a Internet y entre pares

Cuando los dispositivos orientados a Android 12 y versiones posteriores se ejecuten en dispositivos con compatibilidad de hardware, el uso de conexiones entre pares no desconectará la conexión Wi-Fi existente durante la creación de la conexión al dispositivo par. Para verificar la compatibilidad de esta función, usa WifiManager.isMultiStaConcurrencySupported().

Storage

En Android 12, se introducen varios cambios en las API de administración de almacenamiento, que se describen en las siguientes secciones.

Directorio nuevo para grabaciones de voz

El sistema reconoce como grabaciones los archivos de audio que se almacenan en la carpeta nueva Environment.DIRECTORY_RECORDINGS. Cuando la app realiza consultas en la tienda de contenido multimedia del sistema, puedes recuperar grabaciones mediante la marca IS_RECORDING.

Acceso a la administración del contenido multimedia

Los usuarios pueden confiar en que una app determinada llevará a cabo la administración del contenido multimedia, por ejemplo, realizará, con frecuencia, cambios en los archivos multimedia. Si la app se orienta a Android 11 (nivel de API 30) o versiones posteriores, y no es la galería predeterminada del dispositivo, deberás mostrarle un diálogo de confirmación al usuario cada vez que esta intente modificar o borrar un archivo.

Si la app se orienta a Android 12, puedes pedirle al usuario que otorgue el permiso de la app para realizar cada una de las siguientes acciones sin necesidad de solicitarle que ejecute la operación de cada archivo:

Para ello, completa los siguientes pasos:

  1. Declara el permiso MANAGE_MEDIA nuevo y el permiso READ_EXTERNAL_STORAGE en el archivo de manifiesto de la app.

    Para llamar a createWriteRequest() sin mostrar un diálogo de confirmación, también declara el permiso ACCESS_MEDIA_LOCATION.

  2. En la app, muéstrale al usuario una IU para explicarle por qué es posible que desee otorgarle a la app el acceso a la administración del contenido multimedia.

  3. Invoca la acción de intent ACTION_REQUEST_MANAGE_MEDIA, que lleva a los usuarios a la pantalla Apps de administración de multimedia en la configuración del sistema. En esta pantalla, los usuarios pueden otorgar el acceso especial de apps.

Acceso al almacenamiento de la app

Una app puede declarar y crear una actividad personalizada que, cuando se inicie, permita que el usuario administre los datos que la app almacenó en el dispositivo del usuario. Las apps declaran esta actividad personalizada para "administrar el espacio" mediante el atributo android:manageSpaceActivity en el archivo de manifiesto. Las apps de administración de archivos pueden iniciar esta actividad para "administrar el espacio" incluso cuando estas no exportan la actividad, es decir, cuando la actividad establece android:exported en false.

En Android 12, las apps que tienen los permisos MANAGE_EXTERNAL_STORAGE y QUERY_ALL_PACKAGES, como las apps de administración de archivos, pueden usar el método nuevo getManageSpaceActivityIntent() a fin de enviar a los usuarios a la actividad personalizada para "administrar el espacio" de otra app, si se definió una actividad para esta otra app.

El método getManageSpaceActivityIntent() asimila el nombre de un paquete y el código de una solicitud, y muestra uno de los siguientes resultados:

  • PendingIntent, si la app con el nombre del paquete especificado definió una actividad personalizada para "administrar el espacio". La app que llamó al método getManageSpaceActivityIntent() puede invocar el intent que se muestra para enviar a los usuarios a la actividad personalizada.
  • null, si la app con el nombre del paquete especificado no define una actividad para "administrar el espacio".

Compatibilidad con el acceso extendido a archivos

Ahora, el método getMediaUri() admite los URI de MediaDocumentsProvider, además de la compatibilidad existente con los URI de ExternalStorageProvider. El sistema ahora le otorga estos URI al llamador antes de mostrarlos.

Además, ahora, los URI de contenido multimedia que otorga createWriteRequest() admiten las API en la clase File. Estas API brindan la capacidad de leer archivos, escribirlos, cambiarles el nombre y borrarlos.

Funcionalidad principal

Actualizaciones automáticas de apps

En Android 12, se introduce el método setRequireUserAction() para las apps que usan la API de PackageInstaller. Este método permite que las apps instaladoras realicen actualizaciones de apps sin la necesidad de que el usuario confirme la acción.

Información sobre el chipset del dispositivo

En Android 12, se agregan dos constantes a android.os.Build que exponen la información sobre el modelo y el proveedor del chipset SoC mediante el SDK. Puedes recuperar esta información si llamas a Build.SOC_MANUFACTURER y Build.SOC_MODEL, respectivamente.