Características y API

Android 17 incluye excelentes funciones y APIs para desarrolladores. En las siguientes secciones, se resumen estas funciones para ayudarte a comenzar a usar las APIs relacionadas.

Para obtener una lista detallada de las APIs nuevas, modificadas y quitadas, consulta el informe de diferencias de APIs. Para obtener detalles sobre las nuevas APIs, consulta la referencia de la API de Android. Las nuevas APIs están destacadas para que sea más fácil identificarlas.

También deberías revisar las áreas en las que los cambios de la plataforma podrían afectar a tus apps. Si deseas obtener más información, consulta las siguientes páginas:

• Cambios de comportamiento que afectan a las apps cuando se orientan a Android 17
• Cambios de comportamiento que afectan a todas las apps, independientemente de targetSdkVersion

Nota: En esta página, se enumeran algunas de las funciones nuevas más importantes. Para obtener información más detallada, consulta las notas de la versión de Android 17.

Funcionalidad principal

Android 17 agrega las siguientes funciones nuevas relacionadas con la funcionalidad principal de Android.

Nuevos activadores de ProfilingManager

Android 17 向 ProfilingManager 添加了多个新的系统触发器，可帮助您收集深入的数据来调试性能问题。

新触发条件包括：

• TRIGGER_TYPE_COLD_START：在应用冷启动期间发生触发。它在响应中同时提供调用堆栈示例和系统跟踪。
• TRIGGER_TYPE_OOM：当应用抛出 OutOfMemoryError 时触发，并提供 Java 堆转储作为响应。
• TRIGGER_TYPE_KILL_EXCESSIVE_CPU_USAGE：当应用因 CPU 使用率异常和过高而被终止时，会发生触发，并提供正在运行的后台系统跟踪的快照作为响应。
• TRIGGER_TYPE_ANOMALY：检测系统性能异常，例如 binder 调用过多和内存用量过多。

如需了解如何设置系统触发器，请参阅有关基于触发器的性能分析以及如何检索和上传配置文件和分析性能分析数据的文档。

应用异常性能分析触发器

Android 17 引入了设备端异常值检测服务，用于监控资源密集型行为和潜在的兼容性回归。此服务与 ProfilingManager 集成，可让您的应用接收由系统检测到的特定事件触发的性能分析工件。

使用 TRIGGER_TYPE_ANOMALY 触发器检测系统性能问题，例如 Binder 调用过多和内存用量过多。当应用超出操作系统定义的内存限制时，异常触发器可让开发者接收应用专属堆转储，以帮助识别和修复内存问题。此外，对于过多的 binder 垃圾内容，异常触发器会提供 binder 事务的堆栈采样分析。

此 API 回调会在系统强制执行任何操作之前发生。例如，它可以帮助开发者在应用因超出内存限制而被系统终止之前收集调试数据。

fun registerAnomalyTrigger(context: Context) {
    val profilingManager =
        context.getSystemService(ProfilingManager::class.java) ?: return
    val triggers = listOf(
        ProfilingTrigger.Builder(ProfilingTrigger.TRIGGER_TYPE_ANOMALY).build()
    )
    val callbackExecutor: Executor = Executors.newSingleThreadExecutor()
    val resultCallback = Consumer<ProfilingResult> { profilingResult ->
        if (profilingResult.errorCode == ProfilingResult.ERROR_NONE) {
            // Upload profile result to server for further analysis
            profilingResult.resultFilePath?.let { setupProfileUploadWorker(it) }
        }
    }
    profilingManager.registerForAllProfilingResults(
        callbackExecutor,
        resultCallback
    )
    profilingManager.addProfilingTriggers(triggers)
}

APIs de JobDebugInfo

Android 17 introduces new JobDebugInfo APIs to help developers debug their JobScheduler jobs--why they aren't running, how long they ran for, and other aggregated information.

The first method of the expanded JobDebugInfo APIs is getPendingJobReasonStats(), which returns a map of reasons why the job was in a pending execution state and their respective cumulative pending durations. This method joins the getPendingJobReasonsHistory() and getPendingJobReasons() methods to give you insight into why a scheduled job is not running as expected, but simplifies information retrieval by making both duration and job reason available in a single method.

For example, for a specified jobId, the method might return PENDING_JOB_REASON_CONSTRAINT_CHARGING and a duration of 60000 ms, indicating the job was pending for 60000ms due to the charging constraint not being satisfied.

Reduce los bloqueos de activación con la compatibilidad de objetos de escucha para las alarmas de tipo allow-while-idle

Android 17 presenta una nueva variante de AlarmManager.setExactAndAllowWhileIdle que acepta un OnAlarmListener en lugar de un PendingIntent. Este nuevo mecanismo basado en devoluciones de llamada es ideal para las apps que actualmente dependen de bloqueos de activación continuos para realizar tareas periódicas, como las apps de mensajería que mantienen conexiones de socket.

Privacidad

Android 17 incluye las siguientes funciones nuevas para mejorar la privacidad del usuario.

Compatibilidad de la plataforma con Encrypted Client Hello (ECH)

Android 17 introduce compatibilidad de la plataforma con Encrypted Client Hello (ECH), una mejora significativa de la privacidad para las comunicaciones de red. ECH es una extensión de TLS 1.3 que encripta la indicación del nombre del servidor (SNI) durante el protocolo de enlace TLS inicial. Esta encriptación ayuda a proteger la privacidad del usuario, ya que dificulta que los intermediarios de la red identifiquen el dominio específico al que se conecta una app.

La plataforma ahora incluye las APIs necesarias para que las bibliotecas de redes implementen ECH. Esto incluye nuevas capacidades en DnsResolver para consultar registros DNS HTTPS que contengan configuraciones de ECH y nuevos métodos en los objetos SSLEngines y SSLSockets de Conscrypt para habilitar ECH pasando estas configuraciones cuando se conecta a un dominio. Los desarrolladores pueden configurar las preferencias de ECH, como habilitarla de forma oportunista o exigir su uso, a través del nuevo elemento <domainEncryption> dentro del archivo de configuración de seguridad de la red, que se aplica de forma global o por dominio.

Se espera que las bibliotecas de redes populares, como HttpEngine, WebView y OkHttp, integren estas APIs de la plataforma en futuras actualizaciones, lo que facilitará que las apps adopten ECH y mejoren la privacidad del usuario.

Para obtener más información, consulta la documentación de Encrypted Client Hello.

Selector de contactos de Android

The Android Contact Picker is a standardized, browsable interface for users to share contacts with your app. Available on devices running Android 17 (API level 37) or higher, the picker offers a privacy-preserving alternative to the broad READ_CONTACTS permission. Instead of requesting access to the user's entire address book, your app specifies the data fields it needs, such as phone numbers or email addresses, and the user selects specific contacts to share. This grants your app read access to only the selected data, ensuring granular control while providing a consistent user experience with built-in search, profile switching, and multi-selection capabilities without having to build or maintain the UI.

For more information, see the contact picker documentation.

Seguridad

Android 17 agrega las siguientes funciones nuevas para mejorar la seguridad de los dispositivos y las apps.

Modo de Protección avanzada de Android (AAPM)

Android Advanced Protection Mode offers Android users a powerful new set of security features, marking a significant step in safeguarding users—particularly those at higher risk—from sophisticated attacks. Designed as an opt-in feature, AAPM is activated with a single configuration setting that users can turn on at any time to apply an opinionated set of security protections.

These core configurations include blocking app installation from unknown sources (sideloading), restricting USB data signaling, and mandating Google Play Protect scanning, which significantly reduces the device's attack surface area. Developers can integrate with this feature using the AdvancedProtectionManager API to detect the mode's status, enabling applications to automatically adopt a hardened security posture or restrict high-risk functionality when a user has opted in.

Firma de APKs con PQC

Android ahora admite un esquema de firma de APK híbrido para preparar la identidad de firma de tu app para el futuro contra la posible amenaza de ataques que usan la computación cuántica. Esta función presenta un nuevo esquema de firma de APK, que te permite vincular una clave de firma clásica (como RSA o EC) con un nuevo algoritmo de criptografía poscuántica (PQC) (ML-DSA).

Este enfoque híbrido garantiza que tu app siga siendo segura contra futuros ataques cuánticos y, al mismo tiempo, mantenga la retrocompatibilidad total con las versiones y los dispositivos de Android más antiguos que dependen de la verificación de firmas clásica.

Nota: Deberás crear una nueva clave de firma clásica para vincularla con la clave de PQC. No puedes reutilizar tu clave de firma clásica anterior a la híbrida.

Impacto en los desarrolladores

• Apps que usan la firma de apps de Play: Si usas la firma de apps de Play, puedes esperar a que Google Play te dé la opción de actualizar a una firma híbrida con una clave de PQC generada por Google Play, lo que garantiza que tu app esté protegida sin necesidad de administrar las claves de forma manual.
• Apps que usan claves autoadministradas: Los desarrolladores que administran sus propias claves de firma pueden usar las herramientas de compilación de Android actualizadas (como apksigner) para rotar a una identidad híbrida, que combina una clave de PQC con una clave clásica nueva. (Debes crear una clave clásica nueva, no puedes reutilizar la anterior).

Conectividad

Android 17 agrega las siguientes funciones para mejorar la conectividad de los dispositivos y las apps.

Redes satelitales restringidas

Se implementaron optimizaciones para permitir que las apps funcionen de manera eficaz en redes satelitales con ancho de banda bajo.

Nota: Esta función se lanzó con la versión trimestral QPR2 de Android 16. Para obtener más información, consulta Cómo desarrollar para redes satelitales con restricciones.

Experiencia del usuario y la IU del sistema

Android 17 incluye los siguientes cambios para mejorar la experiencia del usuario.

Reproducción independiente del volumen del asistente

Android 17 introduces a dedicated Assistant volume stream for Assistant apps, for playback with USAGE_ASSISTANT. This change decouples Assistant audio from the standard media stream, providing users with isolated control over both volumes. This enables scenarios such as muting media playback while maintaining audibility for Assistant responses, and the other way around.

Assistant apps with access to the new MODE_ASSISTANT_CONVERSATION audio mode can further improve the volume control consistency. Assistant apps can use this mode to provide a hint to the system about an active Assistant session, ensuring the Assistant stream can be controlled outside of the active USAGE_ASSISTANT playback or with connected Bluetooth peripherals.

Handoff

Handoff es una nueva función y API que llegará a Android 17 y con la que los desarrolladores de apps pueden integrarse para proporcionar continuidad multidispositivo a sus usuarios. Permite que el usuario inicie una actividad de la app en un dispositivo Android y la transfiera a otro. Handoff se ejecuta en segundo plano en el dispositivo de un usuario y muestra las actividades disponibles de los otros dispositivos cercanos del usuario a través de varios puntos de entrada, como el selector y la barra de tareas, en el dispositivo receptor.

Las apps pueden designar Handoff para iniciar la misma app nativa para Android, si está instalada y disponible en el dispositivo receptor. En este flujo de app a app, se dirige al usuario a la actividad designada a través de un vínculo directo. Como alternativa, la transferencia de app a Web se puede ofrecer como una opción de resguardo o se puede implementar directamente con la transferencia de URL.

La compatibilidad con Handoff se implementa por actividad. Para habilitar Handoff, llama al método setHandoffEnabled() de la actividad. Es posible que se deban pasar datos adicionales junto con la transferencia para que la actividad que se vuelve a crear en el dispositivo receptor pueda restablecer el estado adecuado. Implementa la devolución de llamada onHandoffActivityDataRequested() para devolver un objeto HandoffActivityData que contenga detalles que especifiquen cómo Handoff debe controlar y recrear la actividad en el dispositivo receptor.

Actualización en vivo: API de color semántico

Con Android 17, Live Update lanza las APIs de Semantic Coloring para admitir colores con significado universal.

Las siguientes clases admiten el color semántico:

• Notification
• Notification.Metric
• Notification.ProgressStyle.Point
• Notification.ProgressStyle.Segment

Colorear

• Verde: Se asocia con la seguridad. Este color se debe usar para que las personas sepan que estás en una situación segura.
• Naranja: Para indicar precaución y marcar peligros físicos. Este color se debe usar en la situación en la que los usuarios deben prestar atención para establecer un mejor parámetro de configuración de protección.
• Rojo: Por lo general, indica peligro, detenerse. Se debe presentar en el caso de que se necesite la atención de las personas con urgencia.
• Azul: Es un color neutro para el contenido informativo que debe destacarse de otro contenido.

En el siguiente ejemplo, se muestra cómo aplicar estilos semánticos al texto de una notificación:

  val ssb = SpannableStringBuilder()
        .append("Colors: ")
        .append("NONE", Notification.createSemanticStyleAnnotation(SEMANTIC_STYLE_UNSPECIFIED), 0)
        .append(", ")
        .append("INFO", Notification.createSemanticStyleAnnotation(SEMANTIC_STYLE_INFO), 0)
        .append(", ")
        .append("SAFE", Notification.createSemanticStyleAnnotation(SEMANTIC_STYLE_SAFE), 0)
        .append(", ")
        .append("CAUTION", Notification.createSemanticStyleAnnotation(SEMANTIC_STYLE_CAUTION), 0)
        .append(", ")
        .append("DANGER", Notification.createSemanticStyleAnnotation(SEMANTIC_STYLE_DANGER), 0)

    Notification.Builder(context, channelId)
          .setSmallIcon(R.drawable.ic_icon)
          .setContentTitle("Hello World!")
          .setContentText(ssb)
          .setOngoing(true)
              .setRequestPromotedOngoing(true)

API de Downlink-TDoA de UWB para Android 17

Downlink Time Difference of Arrival (DL-TDoA) ranging lets a device determine its position relative to multiple UWB anchors by measuring the relative arrival times of signals.

Note: To use DL-TDoA ranging, the calling app must request and be granted Manifest.permission.ACCESS_FINE_LOCATION, and Manifest.permission.ACCESS_BACKGROUND_LOCATION if ranging is required while the app is in the background. For more information, see Request location permissions.

For more information and code samples, see UWB Downlink-TDoA API.