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 la API. 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 debes revisar las áreas en las que los cambios en la plataforma podrían afectar tus apps. Para obtener más información, consulta las siguientes páginas:
- Cambios de comportamiento que afectan a las apps cuando se segmentan para Android 17
- Cambios de comportamiento que afectan a todas las apps, independientemente de
targetSdkVersion.
Funcionalidad principal
Android 17 agrega las siguientes funciones nuevas relacionadas con la funcionalidad principal de Android.
Nuevos activadores de ProfilingManager
Android 17 agrega varios activadores del sistema nuevos a ProfilingManager para ayudarte a recopilar datos detallados y depurar problemas de rendimiento.
Los nuevos activadores son los siguientes:
TRIGGER_TYPE_COLD_START: El activador se ejecuta durante el inicio en frío de la app. Proporciona una muestra de la pila de llamadas y un registro del sistema en la respuesta.TRIGGER_TYPE_OOM: El activador se activa cuando una app arroja unOutOfMemoryErrory proporciona un volcado de montón de Java en respuesta.TRIGGER_TYPE_KILL_EXCESSIVE_CPU_USAGE: El activador se produce cuando se cierra una app debido a un uso de CPU anormal y excesivo, y proporciona una muestra del registro de pila en la respuesta.
Para comprender cómo configurar el activador del sistema, consulta la documentación sobre el registro de perfil basado en activadores y cómo recuperar y analizar los datos de registro de perfil.
APIs de JobDebugInfo
Android 17 introduce nuevas APIs de JobDebugInfo para ayudar a los desarrolladores a depurar sus trabajos de JobScheduler: por qué no se ejecutan, cuánto tiempo se ejecutaron y otra información agregada.
El primer método de las APIs de JobDebugInfo expandidas es getPendingJobReasonStats(), que devuelve un mapa de motivos por los que el trabajo estaba en un estado de ejecución pendiente y sus respectivas duraciones pendientes acumulativas. Este método une los métodos getPendingJobReasonsHistory() y getPendingJobReasons() para brindarte información sobre por qué un trabajo programado no se ejecuta según lo previsto, pero simplifica la recuperación de información al hacer que la duración y el motivo del trabajo estén disponibles en un solo método.
Por ejemplo, para un jobId especificado, el método podría devolver PENDING_JOB_REASON_CONSTRAINT_CHARGING y una duración de 60,000 ms, lo que indica que el trabajo estuvo pendiente durante 60,000 ms debido a que no se cumplió la restricción de carga.
Privacidad
Android 17 incluye las siguientes funciones nuevas para mejorar la privacidad del usuario.
Selector de contactos de Android
El selector de contactos de Android es una interfaz estandarizada y navegable para que los usuarios compartan contactos con tu app. Disponible en dispositivos con Android 17 o versiones posteriores, el selector ofrece una alternativa que preserva la privacidad al permiso amplio READ_CONTACTS. En lugar de solicitar acceso a toda la libreta de direcciones del usuario, tu app especifica los campos de datos que necesita, como números de teléfono o direcciones de correo electrónico, y el usuario selecciona contactos específicos para compartir. Esto le otorga a tu app acceso de lectura solo a los datos seleccionados, lo que garantiza un control detallado y, al mismo tiempo, proporciona una experiencia del usuario coherente con funciones integradas de búsqueda, cambio de perfil y selección múltiple sin tener que compilar ni mantener la IU.
Para obtener más información, consulta la documentación del selector de contactos.
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)
El modo de Protección avanzada de Android ofrece a los usuarios de Android un nuevo y potente conjunto de funciones de seguridad, lo que marca un paso significativo en la protección de los usuarios, en especial aquellos que corren un mayor riesgo, contra ataques sofisticados. Diseñada como una función opcional, la AAPM se activa con un solo parámetro de configuración que los usuarios pueden activar en cualquier momento para aplicar un conjunto de protecciones de seguridad basadas en opiniones.
Estas configuraciones principales incluyen el bloqueo de la instalación de apps de fuentes desconocidas (transferencia local), la restricción de la señalización de datos por USB y la obligatoriedad del análisis de Google Play Protect, lo que reduce significativamente la superficie de ataque del dispositivo.
Los desarrolladores pueden integrar esta función con la API de AdvancedProtectionManager para detectar el estado del modo, lo que permite que las aplicaciones adopten automáticamente una postura de seguridad reforzada o restrinjan la funcionalidad de alto riesgo cuando un usuario habilita el modo.
Conectividad
Android 17 agrega las siguientes funciones para mejorar la conectividad de dispositivos y apps.
Redes satelitales restringidas
Se implementaron optimizaciones para permitir que las apps funcionen de manera eficaz en redes satelitales con ancho de banda bajo.
Experiencia del usuario y la IU del sistema
Android 17 incluye los siguientes cambios para mejorar la experiencia del usuario.
Handoff
Handoff es una nueva función y API que se incluirán en Android 17 y que los desarrolladores de apps pueden integrar para proporcionar continuidad entre dispositivos a sus usuarios. Permite al usuario iniciar una actividad de la app en un dispositivo Android y hacer la transición a otro dispositivo Android. Handoff se ejecuta en segundo plano en el dispositivo del 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 vincula directamente al usuario a la actividad designada. Como alternativa, el traspaso de la app a la Web se puede ofrecer como opción de resguardo o implementarse directamente con el traspaso de URL.
La compatibilidad con la transferencia se implementa por actividad. Para habilitar Handoff, llama al método setHandoffEnabled() para la actividad. Es posible que se deban pasar datos adicionales junto con la transferencia para que la actividad recreada en el dispositivo receptor pueda restablecer el estado adecuado. Implementa la devolución de llamada onHandoffActivityRequested() 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:
NotificationNotification.MetricNotification.ProgressStyle.PointNotification.ProgressStyle.Segment
Colorear
- Verde: Se asocia con la seguridad. Este color se debe usar en el caso en que se les informa a las personas que estás en una situación segura.
- Naranja: Para designar precaución y marcar peligros físicos Este color se debe usar en situaciones en las que los usuarios deben prestar atención para establecer una mejor configuración de protección.
- Rojo: Por lo general, indica peligro o detención. Se debe presentar en el caso en que se necesite la atención de las personas con urgencia.
- Azul: Color neutro para el contenido informativo que debe destacarse del resto.
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 UWB Downlink-TDoA para Android 17
La medición del tiempo de diferencia de llegada (TDoA) de vínculo descendente (DL-TDoA) permite que un dispositivo determine su posición relativa con respecto a varios anclajes midiendo los tiempos de llegada relativos de las señales.
En el siguiente fragmento, se muestra cómo inicializar Ranging Manager, verificar las capacidades del dispositivo y comenzar una sesión de DL-TDoA:
Kotlin
class RangingApp {
fun initDlTdoa(context: Context) {
// Initialize the Ranging Manager
val rangingManager = context.getSystemService(RangingManager::class.java)
// Register for device capabilities
val capabilitiesCallback = object : RangingManager.CapabilitiesCallback {
override fun onRangingCapabilities(capabilities: RangingCapabilities) {
// Make sure Dl-TDoA is supported before starting the session
if (capabilities.uwbCapabilities != null && capabilities.uwbCapabilities!!.isDlTdoaSupported) {
startDlTDoASession(context)
}
}
}
rangingManager.registerCapabilitiesCallback(Executors.newSingleThreadExecutor(), capabilitiesCallback)
}
fun startDlTDoASession(context: Context) {
// Initialize the Ranging Manager
val rangingManager = context.getSystemService(RangingManager::class.java)
// Create session and configure parameters
val executor = Executors.newSingleThreadExecutor()
val rangingSession = rangingManager.createRangingSession(executor, RangingSessionCallback())
val rangingRoundIndexes = intArrayOf(0)
val config: ByteArray = byteArrayOf() // OOB config data
val params = DlTdoaRangingParams.createFromFiraConfigPacket(config, rangingRoundIndexes)
val rangingDevice = RangingDevice.Builder().build()
val rawTagDevice = RawRangingDevice.Builder()
.setRangingDevice(rangingDevice)
.setDlTdoaRangingParams(params)
.build()
val dtTagConfig = RawDtTagRangingConfig.Builder(rawTagDevice).build()
val preference = RangingPreference.Builder(DEVICE_ROLE_DT_TAG, dtTagConfig)
.setSessionConfig(SessionConfig.Builder().build())
.build()
// Start the ranging session
rangingSession.start(preference)
}
}
private class RangingSessionCallback : RangingSession.Callback {
override fun onDlTdoaResults(peer: RangingDevice, measurement: DlTdoaMeasurement) {
// Process measurement results here
}
}
Java
public class RangingApp {
public void initDlTdoa(Context context) {
// Initialize the Ranging Manager
RangingManager rangingManager = context.getSystemService(RangingManager.class);
// Register for device capabilities
RangingManager.CapabilitiesCallback capabilitiesCallback = new RangingManager.CapabilitiesCallback() {
@Override
public void onRangingCapabilities(RangingCapabilities capabilities) {
// Make sure Dl-TDoA is supported before starting the session
if (capabilities.getUwbCapabilities() != null && capabilities.getUwbCapabilities().isDlTdoaSupported) {
startDlTDoASession(context);
}
}
};
rangingManager.registerCapabilitiesCallback(Executors.newSingleThreadExecutor(), capabilitiesCallback);
}
public void startDlTDoASession(Context context) {
RangingManager rangingManager = context.getSystemService(RangingManager.class);
// Create session and configure parameters
Executor executor = Executors.newSingleThreadExecutor();
RangingSession rangingSession = rangingManager.createRangingSession(executor, new RangingSessionCallback());
int[] rangingRoundIndexes = new int[] {0};
byte[] config = new byte[0]; // OOB config data
DlTdoaRangingParams params = DlTdoaRangingParams.createFromFiraConfigPacket(config, rangingRoundIndexes);
RangingDevice rangingDevice = new RangingDevice.Builder().build();
RawRangingDevice rawTagDevice = new RawRangingDevice.Builder()
.setRangingDevice(rangingDevice)
.setDlTdoaRangingParams(params)
.build();
RawDtTagRangingConfig dtTagConfig = new RawDtTagRangingConfig.Builder(rawTagDevice).build();
RangingPreference preference = new RangingPreference.Builder(DEVICE_ROLE_DT_TAG, dtTagConfig)
.setSessionConfig(new SessionConfig.Builder().build())
.build();
// Start the ranging session
rangingSession.start(preference);
}
private static class RangingSessionCallback implements RangingSession.Callback {
@Override
public void onDlTdoaResults(RangingDevice peer, DlTdoaMeasurement measurement) {
// Process measurement results here
}
}
}
Configuraciones fuera de banda (OOB)
El siguiente fragmento proporciona un ejemplo de datos de configuración OOB de DL-TDoA para Wi-Fi y BLE:
Java
// Wifi Configuration
byte[] wifiConfig = {
(byte) 0xDD, (byte) 0x2D, (byte) 0x5A, (byte) 0x18, (byte) 0xFF, // Header
(byte) 0x5F, (byte) 0x19, // FiRa Sub-Element
(byte) 0x02, (byte) 0x00, // Profile ID
(byte) 0x06, (byte) 0x02, (byte) 0x20, (byte) 0x08, // MAC Address
(byte) 0x14, (byte) 0x01, (byte) 0x0C, // Preamble Index
(byte) 0x27, (byte) 0x02, (byte) 0x08, (byte) 0x07, // Vendor ID
(byte) 0x28, (byte) 0x06, (byte) 0xCA, (byte) 0xC8, (byte) 0xA6, (byte) 0xF7, (byte) 0x6F, (byte) 0x08, // Static STS IV
(byte) 0x08, (byte) 0x02, (byte) 0x60, (byte) 0x09, // Slot Duration
(byte) 0x1B, (byte) 0x01, (byte) 0x0A, // Slots per RR
(byte) 0x09, (byte) 0x04, (byte) 0xE8, (byte) 0x03, (byte) 0x00, (byte) 0x00, // Duration
(byte) 0x9F, (byte) 0x04, (byte) 0x67, (byte) 0x45, (byte) 0x23, (byte) 0x01 // Session ID
};
// BLE Configuration
byte[] bleConfig = {
(byte) 0x2D, (byte) 0x16, (byte) 0xF4, (byte) 0xFF, // Header
(byte) 0x5F, (byte) 0x19, // FiRa Sub-Element
(byte) 0x02, (byte) 0x00, // Profile ID
(byte) 0x06, (byte) 0x02, (byte) 0x20, (byte) 0x08, // MAC Address
(byte) 0x14, (byte) 0x01, (byte) 0x0C, // Preamble Index
(byte) 0x27, (byte) 0x02, (byte) 0x08, (byte) 0x07, // Vendor ID
(byte) 0x28, (byte) 0x06, (byte) 0xCA, (byte) 0xC8, (byte) 0xA6, (byte) 0xF7, (byte) 0x6F, (byte) 0x08, // Static STS IV
(byte) 0x08, (byte) 0x02, (byte) 0x60, (byte) 0x09, // Slot Duration
(byte) 0x1B, (byte) 0x01, (byte) 0x0A, // Slots per RR
(byte) 0x09, (byte) 0x04, (byte) 0xE8, (byte) 0x03, (byte) 0x00, (byte) 0x00, // Duration
(byte) 0x9F, (byte) 0x04, (byte) 0x67, (byte) 0x45, (byte) 0x23, (byte) 0x01 // Session ID
};
Si no puedes usar una configuración OOB porque falta o si necesitas cambiar los valores predeterminados que no están en la configuración OOB, puedes compilar parámetros con DlTdoaRangingParams.Builder como se muestra en el siguiente fragmento. Puedes usar estos parámetros en lugar de DlTdoaRangingParams.createFromFiraConfigPacket():
Kotlin
val dlTdoaParams = DlTdoaRangingParams.Builder(1)
.setComplexChannel(UwbComplexChannel.Builder()
.setChannel(9).setPreambleIndex(10).build())
.setDeviceAddress(deviceAddress)
.setSessionKeyInfo(byteArrayOf(0x01, 0x02, 0x03, 0x04))
.setRangingIntervalMillis(240)
.setSlotDuration(UwbRangingParams.DURATION_2_MS)
.setSlotsPerRangingRound(20)
.setRangingRoundIndexes(byteArrayOf(0x01, 0x05))
.build()
Java
DlTdoaRangingParams dlTdoaParams = new DlTdoaRangingParams.Builder(1)
.setComplexChannel(new UwbComplexChannel.Builder()
.setChannel(9).setPreambleIndex(10).build())
.setDeviceAddress(deviceAddress)
.setSessionKeyInfo(new byte[]{0x01, 0x02, 0x03, 0x04})
.setRangingIntervalMillis(240)
.setSlotDuration(UwbRangingParams.DURATION_2_MS)
.setSlotsPerRangingRound(20)
.setRangingRoundIndexes(new byte[]{0x01, 0x05})
.build();