Android 7.0 para desarrolladores

Android 7.0 Nougat presenta varias funciones y capacidades nuevas para usuarios y desarrolladores. En este documento, se destacan las novedades para desarrolladores.

Asegúrate de revisar los cambios de comportamiento de Android 7.0 para obtener información sobre áreas en las cuales los cambios en la plataforma pueden afectar tus apps.

Si deseas obtener más información sobre las funciones de Android 7.0 para consumidores, visita www.android.com.

Compatibilidad con ventanas múltiples

En Android 7.0, presentamos una nueva y muy solicitada función multitarea en la plataforma: la compatibilidad con ventanas múltiples.

Los usuarios ahora pueden abrir dos apps al mismo tiempo en la pantalla.

• En teléfonos y tablets con Android 7.0, los usuarios pueden ejecutar dos apps en paralelo o una encima de la otra en el modo de pantalla dividida. También pueden modificar el tamaño de las apps arrastrando la línea divisoria que se encuentra entre ellas.
• En los dispositivos con Android TV, las apps pueden habilitar de forma automática el modo “picture-in-picture”. Esto les permite continuar mostrando contenido mientras el usuario explora otras apps o interactúa con ellas.

En las tablets, en particular, y en otros dispositivos de pantallas más grandes, la compatibilidad con ventanas múltiples te ofrece nuevas maneras de atraer a los usuarios. Puedes, incluso, habilitar acciones de arrastrar y soltar en tu app para que los usuarios arrastren contenido hacia o desde ella de manera práctica; es una excelente manera de mejorar su experiencia.

Es sencillo agregar compatibilidad con ventanas múltiples a tu app y configurar la manera en que administra la visualización de estas ventanas. Por ejemplo, puedes especificar las dimensiones mínimas permitidas de tu actividad y evitar así que los usuarios den a la actividad un tamaño inferior. También puedes inhabilitar la visualización de ventanas múltiples para tu app, lo cual garantizará que el sistema solo muestre tu app en el modo de pantalla completa.

Para obtener más información, consulta la documentación de Compatibilidad con ventanas múltiples para desarrolladores.

Mejoras en las notificaciones

En Android 7.0, hemos rediseñado las notificaciones para facilitar y agilizar su uso. Entre los cambios, se incluyen los siguientes:

• Actualizaciones de plantillas: actualizaremos las plantillas de notificaciones para poner nuevo énfasis en la imagen de héroe y el avatar. Los desarrolladores podrán aprovechar las nuevas plantillas con una cantidad mínima de ajustes en el código.
• Personalización del estilo del Centro de Mensajes: puedes personalizar más etiquetas de la interfaz de usuario asociadas con tus notificaciones usando la clase MessagingStyle. Puedes configurar el mensaje, el título de la conversación y la vista del contenido.
• Notificaciones agrupadas: el sistema puede agrupar mensajes (por ejemplo, por tema) y mostrar el grupo. Un usuario puede aplicar acciones, como Dismiss o Archive, en ellos. Si has implementado notificaciones para Android Wear, ya estarás familiarizado con este modelo.
• Respuesta directa: en el caso de las apps de comunicación en tiempo real, el sistema de Android admite respuestas en línea para que los usuarios puedan responder rápidamente a un mensaje SMS o de texto de manera directa dentro en la interfaz de notificaciones.
• Vistas personalizadas: dos API nuevas te permiten aprovechar las decoraciones del sistema, como los encabezados y las acciones de notificaciones, al usar vistas personalizadas en las notificaciones.

Figura 2: Notificaciones agrupadas y respuesta directa.

Para obtener información acerca de cómo implementar las nuevas funciones, consulta la guía Notificaciones.

Compilación de JIT y AOT guiada por perfiles

En Android 7.0, agregamos un compilador Just in Time (JIT) con generación de perfiles de código para ART, lo cual te permite mejorar constantemente el rendimiento de las apps de Android mientras se ejecutan. El compilador JIT complementa el compilador Ahead of Time (AOT) actual de ART y permite mejorar el rendimiento del tiempo de ejecución, ahorrar espacio de almacenamiento y acelerar las actualizaciones de las apps y del sistema.

La compilación guiada por perfiles permite que ART maneje la compilación de AOT y JIT de cada app conforme a su uso real, además de las condiciones en el dispositivo. Por ejemplo, ART conserva un perfil de los métodos directos de cada app y puede compilar previamente y almacenar en caché dichos métodos para obtener el mejor rendimiento. A su vez, deja otras partes de la app sin compilar hasta que se usan.

Además de mejorar el rendimiento de partes clave de la app, la compilación guiada por perfiles permite reducir la superficie de memora RAM total de una app, incluidos los archivos binarios asociados. Esta función tiene particular importancia en los dispositivos de memoria reducida.

ART administra la compilación guiada por perfiles de una manera que minimiza el impacto en la batería del dispositivo. Realiza compilaciones previas únicamente cuando el dispositivo se encuentra inactivo y en proceso de carga, lo cual permite ahorrar tiempo y batería haciendo el trabajo de manera anticipada.

Ruta de acceso rápida a la instalación de aplicaciones

Uno de los beneficios más palpables del compilador JIT de ART es la velocidad de instalación de las apps y de actualización del sistema. Incluso las apps de mayor tamaño, en las cuales se necesitaban varios minutos para la optimización y la instalación en Android 6.0, ahora pueden instalarse en cuestión de segundos. Las actualizaciones del sistema también son más rápidas, debido a que ya no hay un paso de optimización.

Descanso sobre la marcha...

En Android 6.0, se presentó Descanso, un modo de sistema que ahorra batería aplazando actividades de CPU y red de las apps cuando el dispositivo se encuentra inactivo; por ejemplo, al hallarse sobre una mesa o en un cajón.

Ahora, en Android 7.0, el modo Descanso ofrece el beneficio adicional de ahorrar batería sobre la marcha. Siempre que la pantalla permanezca apagada durante un tiempo y el dispositivo esté desenchufado, el modo Descanso aplicará a las apps un subconjunto de las restricciones de CPU y red conocidas. Esto significa que los usuarios pueden ahorrar batería aun cuando lleven sus dispositivos en los bolsillos.

Figura 3: El modo Descanso ahora aplica restricciones para prolongar la duración de la batería aun cuando el dispositivo no está quieto.

Poco tiempo después de que la pantalla se apaga, cuando el dispositivo no está enchufado, este modo restringe el acceso a la red y aplaza tareas y sincronizaciones. Durante períodos de mantenimiento breves, las aplicaciones tienen acceso a la red y se ejecutan todas las tareas y sincronizaciones aplazadas. Ten en cuenta que cuando se activa la pantalla o se enchufa el dispositivo se desactiva el modo Descanso.

Cuando el dispositivo vuelve a estar quieto, desenchufado y con la pantalla apagada durante un tiempo, el modo Descanso aplica todas las restricciones de CPU y redes en PowerManager.WakeLock, alarmas de AlarmManager y análisis de GPS o Wi-Fi.

Las prácticas recomendadas para adaptar tu app al modo Descanso no varían si el dispositivo está en movimiento o no. Por lo tanto, si ya la actualizaste para que administre este modo correctamente, no será necesario nada más. Si no lo hiciste, comienza a adaptarla al modo Descanso en este momento.

Project Svelte: optimizaciones en segundo plano

Project Svelte representa un esfuerzo constante por minimizar el uso de memoria RAM a través del sistema y de las aplicaciones en los diferentes dispositivos Android del ecosistema. En Android 7.0, el objetivo principal de Project Svelte es optimizar la manera en que las apps se ejecutan en segundo plano.

El procesamiento en segundo plano es esencial en la mayoría de las apps. Cuando se maneja en forma adecuada, puede hacer que la experiencia de tu usuario sea increíble: inmediata, rápida y pertinente al contexto. Cuando no se maneja de tal manera, el procesamiento en segundo plano puede suponer un consumo innecesario de memoria RAM (y batería) y afectar el rendimiento del sistema para otras apps.

A partir de Android 5.0, JobScheduler ha sido el método preferido para ejecutar tareas en segundo plano con resultados positivos para los usuarios. Las apps pueden programar tareas y, al mismo tiempo, permitir que el sistema se optimice según las condiciones de memoria, energía y conectividad. JobScheduler ofrece control y simplicidad, y nuestro deseo es que se use en todas las apps.

Otra buena opción es GCMNetworkManager, que forma parte de Google Play Services y ofrece una capacidad similar de programación de tareas con compatibilidad en versiones heredadas de Android.

Continuaremos ampliando JobScheduler y GCMNetworkManager para que se apliquen a más casos de uso de tus apps; por ejemplo, en Android 7.0 ahora puedes programar procesos en segundo plano según los cambios de los proveedores de contenido. Al mismo tiempo, comenzaremos a discontinuar el uso de algunos de los patrones anteriores que pueden reducir el rendimiento del sistema, en especial en dispositivos de memoria reducida.

En Android 7.0, eliminaremos tres transmisiones implícitas que se usan normalmente (CONNECTIVITY_ACTION, ACTION_NEW_PICTURE y ACTION_NEW_VIDEO), ya que pueden activar los procesos en segundo plano de varias apps al mismo tiempo, y así exigir la memoria y la batería. Si tu app recibe estas transmisiones, aprovecha Android 7.0 y realiza la migración a JobScheduler y las API relacionadas como alternativa.

Para obtener información detallada, consulta la documentación Optimizaciones en segundo plano.

SurfaceView

Android 7.0 ofrece movimiento sincrónico a la clase SurfaceView, que proporciona un mejor rendimiento de la batería que TextureView en determinados casos: Cuando se representa contenido 3D o de video, las apps con desplazamiento y posición de video animado consumen menos energía con SurfaceView que con TextureView.

La clase SurfaceView permite lograr una composición más eficaz en cuanto al uso de la batería en la pantalla, porque se compone en hardware dedicado, independientemente del contenido de la ventana de la app. Como resultado, se producen menos copias intermedias que con TextureView.

La posición del contenido de un objeto SurfaceView ahora se actualiza de forma sincronizada con el contenido de la app contenedora. Un resultado de este cambio es que las simples traducciones o escalas de un video que se reproduce en una clase SurfaceView ya no producen barras negras junto a la vista a medida que esta se mueve.

A partir de Android 7.0, te recomendamos mucho ahorrar batería usando SurfaceView, en lugar de TextureView.

Ahorro de datos

Durante la vida útil de un dispositivo móvil, el costo de un plan de datos móviles puede superar fácilmente el costo del propio dispositivo. Para muchos usuarios, los datos móviles son un recurso costoso que conviene conservar.

En Android 7.0, se presenta el modo de ahorro de datos, un nuevo servicio del sistema que permite reducir el uso de datos móviles de las apps, ya sea con itinerancia, cerca del final del ciclo de facturación o con un pequeño paquete de datos prepagos. El ahorro de datos permite que los usuarios controlen la manera en que las apps usan los datos móviles y que los desarrolladores brinden un servicio más eficaz cuando el ahorro de datos se encuentra activo.

Cuando un usuario habilita el ahorro de datos en Settings y el dispositivo está conectado a una red, el sistema bloquea el uso de datos en segundo plano y ordena a las apps usar menos datos en primer plano siempre que sea posible (por ejemplo, limitando la tasa de bits para la transmisión, reduciendo la calidad de la imagen y aplazando el valor optimista de almacenamiento previo en caché, entre otras posibilidades). Los usuarios pueden incluir apps específicas en la lista blanca para permitir el uso de datos medidos en segundo plano, incluso cuando está activado el ahorro de datos.

Android 7.0 extiende ConnectivityManager para que las apps tengan una manera de recuperar las preferencias de ahorro de datos del usuario y controlar cambios en estas. Todas las apps deben verificar si el usuario habilitó el ahorro de datos e intentar limitar el uso de datos en primer y segundo plano.

Vulkan API

Android 7.0 integra Vulkan™, una nueva API de visualización 3D, en la plataforma. Al igual que OpenGL™ ES, Vulkan es un estándar abierto para gráficos y visualización 3D, cuyo mantenimiento está a cargo de Khronos Group.

Vulkan se diseñó desde el principio para minimizar la sobrecarga de CPU en el controlador y permite que tu aplicación controle el funcionamiento de la GPU más directamente. También permite contar con un mejor trabajo en paralelo, ya que permite que varios subprocesos realicen tareas a la vez, como la construcción del búfer de comandos.

Las herramientas y las bibliotecas de desarrollo de Vulkan son parte de Android 7.0DK. Esto incluye lo siguiente:

• encabezados;
• capas de validación (bibliotecas de depuración);
• compilador SPIR-V;
• biblioteca de compilación de tiempo de ejecución de SPIR-V.

Vulkan solo está disponible para apps en dispositivos con hardware compatible con Vulkan, como Nexus 5X, Nexus 6P y Nexus Player. Estamos trabajando en estrecha colaboración con nuestros socios para que Vulkan pueda usarse en más dispositivos lo más pronto posible.

Para obtener más información, consulta la documentación de la API.

Quick Settings Tile API

Quick Settings es una manera popular y simple de exhibir configuraciones y acciones claves directamente desde el panel de notificaciones. En Android 7.0, expandimos el alcance de Quick Settings para que sea aún más útil y práctico.

Agregamos más espacio para mosaicos adicionales de Quick Settings, a los cuales los usuarios pueden acceder desde un área de visualización paginada deslizando el dedo hacia la izquierda o la derecha. También permitimos que los usuarios determinen los mosaicos de Quick Settings que aparecerán y los puntos en los cuales se mostrarán; pueden agregar o mover mosaicos con solo arrastrarlos y soltarlos.

Para los desarrolladores, en Android 7.0 también se agrega una nueva API que permite a estos definir mosaicos de Quick Settings propios a fin de facilitar, dentro de sus apps, el acceso a controles y acciones claves por parte de los usuarios.

Los mosaicos de Quick Settings se reservan para controles o acciones que se necesiten con urgencia o se usen con frecuencia; no deben emplearse como combinaciones de teclas para iniciar una app.

Una vez que hayas definido tus mosaicos, puedes dejarlos a disposición de los usuarios, quienes tendrán la posibilidad de agregarlos a Quick Settings con solo arrastrarlos y soltarlos.

Para obtener información sobre la creación de un mosaico de app, consulta la documentación de android.service.quicksettings.Tile en la Referencia de API descargable.

Bloqueo de números

Android 7.0 ahora admite el bloqueo de números en la plataforma y proporciona una API de framework para que los proveedores de servicios dispongan de una lista con números bloqueados. La app de SMS predeterminada, la app telefónica predeterminada y las apps de proveedores tienen capacidad de lectura y escritura en la lista de números bloqueados. Otras apps no pueden acceder a la lista.

Al hacer que el bloqueo de números sea una función estándar de la plataforma, Android permite que las apps admitan de manera uniforme el bloqueo de números en una amplia variedad de dispositivos. Entre los demás beneficios que pueden aprovechar las apps, se encuentran los siguientes:

• Los números bloqueados en las llamadas también se bloquean en los mensajes de texto.
• Los números bloqueados pueden perdurar tras procesos de restablecimiento y cambios de dispositivos con la función Backup & Restore.
• Varias apps pueden usar la misma lista de números bloqueados.

De manera adicional, la integración de apps de proveedores a través de Android permite que estos lean la lista de números bloqueados del dispositivo y realicen un bloqueo de servicio para el usuario, a fin de evitar que este reciba llamadas y mensajes de texto no deseados por cualquier medio, como terminales VOIP o teléfonos con transferencia de llamadas.

Para obtener más información, consulta android.provider.BlockedNumberContract en la Referencia de API descargable.

Filtración de llamadas

Android 7.0 permite que la app predeterminada de un teléfono filtre las llamadas entrantes. La app hace esto a través del nuevo CallScreeningService, que le permite realizar varias acciones según la clase Call.Details de la llamada entrante. Algunos ejemplos:

• rechazar la llamada entrante;
• no permitir el ingreso de la llamada en el registro de llamadas;
• no mostrar al usuario una notificación de la llamada.

Para obtener más información, consulta android.telecom.CallScreeningService en la Referencia de API descargable.

Compatibilidad con varias configuraciones regionales y más idiomas

Android 7.0 ahora permite a los usuarios seleccionar varias configuraciones regionales en Settings, para brindar una mejor compatibilidad con casos de uso de dos idiomas. Las apps pueden usar una nueva API para obtener las configuraciones regionales seleccionadas del usuario y luego ofrecer experiencias más sofisticadas para usuarios que usen varias configuraciones regionales; por ejemplo, pueden mostrar resultados de búsqueda en varios idiomas y no ofrecer traducciones de páginas web con idiomas que el usuario ya conozca.

Además de ofrecerse la compatibilidad con varias configuraciones regionales, en Android 7.0 también se amplía la variedad de idiomas disponibles para los usuarios. Se brindan más de 25 variantes, cada una de ellas para idiomas de uso común, como el inglés, el español, el francés y el árabe. También se agrega compatibilidad parcial con más de 100 idiomas nuevos.

Las apps pueden obtener la lista de configuraciones regionales establecida por el usuario llamando a LocaleList.GetDefault(). A fin de admitir la cantidad ampliada de configuraciones regionales, en Android 7.0, se modificará la forma de resolver recursos. Asegúrate de controlar que tus apps funcionen de la manera esperada con la nueva lógica de resolución de recursos.

Para obtener información sobre el nuevo comportamiento de resolución de recursos y las prácticas recomendadas que debes aplicar, consulta Compatibilidad con varios idiomas.

Nuevos emojis

En Android 7.0 se presentan más emojis y funciones relacionadas con estos, como diferentes tonos de piel y compatibilidad con selectores de variación. Si tu app admite emojis, sigue las pautas a continuación para aprovechar estas funciones relacionadas con emojis.

• Comprueba que el dispositivo contenga el emoji antes de insertarlo. Para corroborar los emojis presentes en la fuente del sistema, usa el método hasGlyph(String).
• Comprueba que un emoji admita selectores de variación. Los selectores de variación te permiten presentar determinados emojis en color o en blanco y negro. En los dispositivos móviles, las apps deben representar los emojis en color en lugar de hacerlo en blanco y negro. Sin embargo, si en tu app se muestran los emojis alineados con el texto, esta debe usar la variación de blanco y negro. A fin de determinar si un emoji tiene una variación, usa el selector de variación. Para conocer la lista completa de caracteres con variaciones, consulta la sección de secuencias de variación de emojis de la documentación de Unicode sobre variaciones.
• Comprueba que el emoji admita tonos de piel. Android 7.0 permite que los usuarios modifiquen el tono de piel presentado de los emojis según su preferencia. Las apps de teclado deben brindar indicaciones visuales para los emojis que tengan varios tonos de piel y permitir que los usuarios seleccionen el que prefieran. Para determinar los emojis del sistema que tienen modificadores de tono de piel, usa el método hasGlyph(String). Puedes determinar los emojis que usan tonos de piel leyendo la documentación de Unicode.

Las ICU4J API en Android

Android 7.0 ahora ofrece un subconjunto de las ICU4J API dentro del framework de Android, en el paquete android.icu. La migración es sencilla y en mayor medida implica simplemente un cambio del espacio de nombres com.java.icu a android.icu. Si ya usas el paquete ICU4J en tus apps, el cambio a las android.icu API en el framework de Android puede reducir notablemente el tamaño del APK.

Para obtener más información sobre las ICU4J API de Android, consulta Compatibilidad con ICU4J.

WebView

Chrome + WebView, juntos

A partir de Chrome 51 en Android 7.0 y versiones posteriores, el APK de Chrome de tu dispositivo se usa para ofrecer y presentar WebViews del sistema Android. Este enfoque mejora el uso de la memoria en el propio dispositivo y, además, reduce el ancho de banda necesario para mantener WebView actualizado (debido a que el APK de WebView independiente ya no se actualizará mientras Chrome permanezca habilitado).

Puedes elegir tu proveedor de WebView habilitando Developer Options y seleccionando WebView implementation. Puedes usar cualquier versión de Chrome compatible (Dev, Beta o estable) que esté instalada en tu dispositivo o el APK de WebView independiente para que funcione como implementación de WebView.

Multiproceso

A partir de Chrome 51 en Android 7.0, WebView ejecutará contenido web en procesos individuales de zonas de pruebas cuando se habilite la opción “Multiprocess WebView” para desarrolladores.

Esperamos recibir comentarios sobre compatibilidad y rendimiento de tiempo de ejecución en N antes de habilitar Multiprocess WebView en versiones futuras de Android. En esta versión, pueden darse regresiones en el tiempo de inicio, uso total de la memoria y rendimiento de la representación de software.

Si experimentas problemas inesperados en el modo de multiproceso, quisiéramos que compartieras la información con nosotros. Mantente en contacto con el equipo de WebView en el seguimiento de errores de Chromium.

Ejecución de Javascript antes de la carga de página

A partir de las apps orientadas a Android 7.0, el contexto de Javascript se restablecerá cuando se cargue una nueva página. Actualmente, el contexto de la primera página cargada se mantiene en una instancia de WebView nueva.

Los desarrolladores que deseen introducir JavaScript en WebView deben ejecutar la secuencia de comandos luego de que la página haya comenzado a cargarse.

Ubicación geográfica en orígenes inseguros

Comenzando por las apps orientadas a Android 7.0, solo se permitirá el uso de la API de ubicación geográfica en orígenes seguros (en HTTPS). Esta política se ha diseñado para proteger la información privada del usuario cuando use una conexión insegura.

Pruebas con WebView Beta

WebView se actualiza con frecuencia; por lo tanto, recomendamos que a menudo pruebes la compatibilidad con tu app por medio del canal beta de WebView. Para comenzar con las pruebas de versiones de Webview previas al lanzamiento en Android 7.0, descarga e instala Chrome Dev o Chrome Beta y selecciónalo como implementación de WebView en las opciones de desarrollador, tal como se describió anteriormente. Notifica los problemas por medio del seguimiento de errores de Chromium para que podamos solucionarlos antes del lanzamiento de una nueva versión de WebView.

OpenGL™ ES 3.2 API

En Android 7.0, se agregan interfaces de framework y compatibilidad de plataforma para OpenGL ES 3.2. Se incluye lo siguiente:

• todas las extensiones del paquete de extensiones de Android (AEP), a excepción de EXT_texture_sRGB_decode;
• búferes de fotogramas de punto flotante para HDR y sombreado aplazado;
• llamadas a draw a través de BaseVertex para mejorar el procesamiento por lotes y la transmisión;
• sólido control de acceso a búfer para reducir la sobrecarga de WebGL.

En Android 7.0, la API de framework para OpenGL ES 3.2 se proporciona con la clase GLES32. Al usar OpenGL ES 3.2, asegúrate de declarar el requisito en tu archivo de manifiesto con la etiqueta <uses-feature> y el atributo android:glEsVersion.

Para obtener información sobre el uso de OpenGL ES, incluida la manera de comprobar la versión de OpenGL ES que admite el dispositivo durante el tiempo de ejecución, consulta la guía de la OpenGL ES API.

Grabación de Android TV

En Android 7.0, se agrega la capacidad de grabar y reproducir contenido de servicios de entrada de Android TV a través de las nuevas API de grabación. Aprovechando las mejoras existentes de las API time shifting, los servicios de entrada de TV pueden controlar los datos de canales que pueden grabarse y la manera en que se guardan las sesiones grabadas, y administrar la interacción del usuario con el contenido grabado.

Para obtener más información, consulta Android TV Recording APIs.

Android for Work

Android for Work suma muchas funciones y API nuevas para dispositivos con Android 7.0. A continuación, se muestran algunos aspectos destacados. Para ver la lista completa de cambios, consulta Actualizaciones de Android for Work.

Comprobación de seguridad para perfiles de trabajo

Los propietarios de perfiles orientados al SDK de Android N pueden especificar una comprobación de seguridad independiente para las apps que se ejecutan en el perfil de trabajo. La comprobación para perfiles de trabajo se muestra cuando un usuario intenta abrir apps de trabajo. Cuando la comprobación de seguridad es exitosa, se desbloquea el perfil de trabajo y se descifra si es necesario. Para quienes posean perfiles, ACTION_SET_NEW_PASSWORD solicita al usuario establecer una comprobación de trabajo y ACTION_SET_NEW_PARENT_PROFILE_PASSWORD le solicita establecer un bloqueo de dispositivo.

Quienes posean perfiles pueden establecer políticas de contraseñas diferentes para la comprobación de seguridad de trabajo (por ejemplo, la extensión que debe tener el PIN o la posibilidad de usar una huella dactilar para desbloquear el perfil) usando setPasswordQuality(), setPasswordMinimumLength() y métodos relacionados. También pueden establecer el bloqueo del dispositivo usando la instancia de DevicePolicyManager mostrada por el nuevo método getParentProfileInstance(). Además, tienen la posibilidad de personalizar la pantalla de credenciales de la comprobación de trabajo usando los nuevos métodos setOrganizationColor() y setOrganizationName().

Desactivación del modo de trabajo

En dispositivos con perfil de trabajo, los usuarios pueden alternar el modo de trabajo. Cuando este último está inactivo, el usuario administrado queda inhabilitado temporalmente, con lo cual se inhabilitan las apps de perfiles de trabajo, la sincronización en segundo plano y las notificaciones. Esto incluye la aplicación del propietario del perfil. Cuando el modo de trabajo está inactivo, en el sistema se muestra un ícono de estado persistente para recordar al usuario que no puede iniciar apps de trabajo. El lanzador indica que no es posible acceder a apps ni a widgets de trabajo.

Always on VPN

Los propietarios de dispositivos y perfiles pueden asegurarse de que las apps de trabajo siempre se conecten a través de una VPN especificada. El sistema inicia dicha VPN en forma automática después del inicio del dispositivo.

Los nuevos métodos de DevicePolicyManager son setAlwaysOnVpnPackage() y getAlwaysOnVpnPackage().

Debido a que los servicios de VPN pueden enlazarse directamente a través del sistema sin interacción con apps, los clientes de VPN deben administrar nuevos puntos de entrada para Always on VPN. Al igual que antes, los servicios se indican al sistema con una clase android.net.VpnService de acción de coincidencia de filtro de intents.

Los usuarios también pueden establecer manualmente clientes Always on VPN que implementen métodos VPNService dirigiéndose a Settings > More > Vpn. La opción para habilitar Always on VPN desde Settings está disponible únicamente si el cliente de VPN está orientado al nivel de API 24.

Aprovisionamiento personalizado

En una aplicación, se pueden personalizar los flujos de aprovisionamiento del propietario del perfil y del dispositivo con logotipos y colores corporativos. DevicePolicyManager.EXTRA_PROVISIONING_MAIN_COLOR personaliza el color del flujo. DevicePolicyManager.EXTRA_PROVISIONING_LOGO_URI personaliza el flujo con un logotipo corporativo.

Mejoras de accesibilidad

Android 7.0 ahora ofrece Vision Settings directamente en la pantalla de bienvenida para la configuración de dispositivos nuevos. Esto permite a los usuarios descubrir y configurar de manera mucho más sencilla funciones de accesibilidad en sus dispositivos, como el gesto de ampliación, el tamaño de fuente, el tamaño de pantalla y TalkBack.

Al tener estas funciones de accesibilidad una disposición más prominente, es más probable que tus usuarios prueben tu app con ellas habilitadas. Asegúrate de probar tus apps de manera anticipada con esta configuración habilitada. Puedes habilitarla en Settings >Accessibility.

Además, los servicios de accesibilidad de Android 7.0 ahora pueden asistir en el uso de la pantalla a usuarios con discapacidades motrices. La nueva API permite crear servicios con funciones como el seguimiento de rostros u ojos y la exploración por puntos, entre otros, para satisfacer las necesidades de estos usuarios.

Para obtener más información, consulta android.accessibilityservice.GestureDescription en la Referencia de API descargable.

Inicio directo

El inicio directo mejora los tiempos de inicio del dispositivo y permite que las apps registradas tengan funcionalidad limitada, incluso luego de un reinicio inesperado. Por ejemplo, si un dispositivo encriptado se reinicia mientras el usuario duerme, este último puede continuar recibiendo de manera normal notificaciones de alarmas, llamadas entrantes y mensajes registrados. Esto también significa que los servicios de accesibilidad también pueden estar disponibles de inmediato después de un reinicio.

El inicio directo aprovecha la encriptación basada en archivos en Android 7.0 a fin de habilitar políticas de encriptación detalladas para los datos del sistema y de apps. El sistema usa un espacio de almacenamiento encriptado por el dispositivo para datos de sistema seleccionados y datos de apps explícitamente registrados. De forma predeterminada, se usa un depósito encriptado con credenciales para los datos de sistema, los datos de usuario, las apps y los datos de apps restantes.

Durante el inicio, el sistema se inicia en un modo restringido con acceso únicamente a datos encriptados por el dispositivo y sin acceso general a apps o datos. Si hay componentes que deseas ejecutar en este modo, puedes registrarlos configurando un indicador en el manifiesto. Después del reinicio, el sistema activa componentes registrados transmitiendo la intent LOCKED_BOOT_COMPLETED. El sistema garantiza que antes de la desactivación del bloqueo estén disponibles los datos de apps encriptados por el dispositivo que estén registrados. No es posible acceder a los demás datos hasta que el usuario confirme sus credenciales de pantalla bloqueada para descifrarlos.

Para obtener más información, consulta Inicio directo.

Atestación de claves

En Android 7.0 se presenta la atestación de claves, una nueva herramienta de seguridad que te permite garantizar que los pares de claves almacenados dentro del depósito de claves guardadas en hardware de un dispositivo protejan correctamente la información confidencial que usa tu app. Por medio de esta herramienta, tendrás mayores garantías de que tu app interactúe con claves que residan en un hardware seguro, incluso cuando se acceda a derechos administrativos en el dispositivo que ejecute tu app. Si usas claves del depósito de claves guardadas en hardware en tus apps, debes usar esta herramienta, en especial si usas las claves para verificar información confidencial dentro de tu app.

La atestación de claves te permite verificar que un par de claves RSA o EC se haya creado y almacenado en el depósito de claves guardadas en hardware de un dispositivo dentro del entorno de ejecución confiable (TEE) de dicho dispositivo. La herramienta también te permite usar un servicio que no dependa del dispositivo (por ejemplo, el servidor de backend de tu app), para determinar y verificar estrictamente los usos y la validez del par de claves. Estas funciones ofrecen un nivel adicional de seguridad que protege dicho par, incluso si alguien accede a derechos administrativos del dispositivo o compromete la seguridad de la plataforma Android que se ejecuta en él.

Nota: Solo unos pocos dispositivos con Android 7.0 admiten atestación de claves a nivel de hardware; en todos los demás dispositivos con Android 7.0 se usa atestación de claves a nivel de software. Antes de verificar las propiedades de las claves guardadas en hardware de un dispositivo en un entorno de producción, debes asegurarte de que el dispositivo admita atestación de claves en el nivel del hardware. Para esto, debes comprobar que la cadena del certificado de atestación contenga un certificado raíz firmado por la clave raíz de atestación de Google y que el elemento attestationSecurityLevel dentro de la estructura de datos de la descripción de la clave se configure en el nivel de seguridad TrustedEnvironment.

Para obtener más información, consulta la documentación de atestación de claves para desarrolladores.

Configuración de seguridad de la red

En Android 7.0, las apps pueden personalizar el comportamiento de sus conexiones protegidas (HTTPS y TLS) de manera segura, sin modificaciones en el código, a través de la Configuración de seguridad de la red en lugar de las API de programación convencionales, propensas a generar errores (p. ej., X509TrustManager).

Funciones admitidas:

• Anclajes de confianza personalizados: permite personalizar las entidades de certificación (CA) de confianza para las conexiones de seguridad de una aplicación. Por ejemplo, la confianza en certificados autofirmados particulares o un conjunto restringido de CA públicas.
• Anulaciones de solo depuración: permite que el desarrollador de una aplicación depure de manera segura conexiones protegidas de su aplicación sin riesgos adicionales para la base instalada.
• Desactivación del tráfico de Cleartext: permite que una aplicación se proteja a sí misma contra el uso accidental de tráfico de Cleartext.
• Fijación de certificados: esta es una función avanzada que permite a una aplicación limitar las claves de servidores en las cuales se pueda confiar para conexiones seguras.

Para obtener más información, consulta Configuración de seguridad de la red.

Entidad de certificación de confianza predeterminada

De manera predeterminada, en las apps orientadas a Android 7.0 solo se consideran como confiables los certificados proporcionados por el sistema y ya no se da esta misma consideración a las entidades de certificación (CA) agregadas por usuarios. En aquellas apps orientadas a Android N para las cuales se desee considerar tales CA como válidas, se debe usar la Configuración de seguridad de la red a fin de especificar los términos de confianza de dichas CA.

Esquema de firma de APK v2

Android 7.0 presenta el esquema de firma de APK v2, un nuevo esquema de firma de apps que ofrece una instalación de apps más rápida y mayor protección contra alteraciones no autorizadas de archivos APK. De forma predeterminada, Android Studio 2.2 y el complemento de Android para Gradle 2.2 firman tu app con el esquema de firma de APK v2 y el esquema de firma tradicional, que usa la firma JAR.

Aunque te recomendamos implementar el esquema de firma de APK v2 en tu app, este esquema nuevo no es obligatorio. Si la app no se compila correctamente con el esquema de firma de APK v2, puedes inhabilitar este esquema nuevo. Si se inhabilita el proceso, Android Studio 2.2 y el complemento de Android para Gradle 2.2 firman tu app con el esquema de firma tradicional únicamente. Para firmar solo con el esquema tradicional, abre el archivo build.gradle del nivel del módulo y, a continuación, agrega la línea v2SigningEnabled false a la configuración de firma de la versión:

  android {
    ...
    defaultConfig { ... }
    signingConfigs {
      release {
        storeFile file("myreleasekey.keystore")
        storePassword "password"
        keyAlias "MyReleaseKey"
        keyPassword "password"
        v2SigningEnabled false
      }
    }
  }

Advertencia: Si firmas la app con el esquema de firma de APK v2 y luego la modificas, se invalidará la firma. Por este motivo, usa herramientas como zipalign antes de firmar la app con el esquema de firma de APK v2, no después.

Para obtener más información, lee los documentos de Android Studio en los que se describe la manera de firmar una app en Android Studio y de configurar el archivo de compilación para firmar apps con el complemento de Android para Gradle.

Acceso a directorios determinados

En Android 7.0, las apps pueden usar nuevas API para solicitar acceso a directorios de almacenamiento externo específicos, incluidos los directorios de medios extraíbles, como las tarjetas SD. Las nuevas API simplifican enormemente la manera en que tu aplicación accede a directorios de almacenamiento externo estándares, como Pictures. Las apps de fotografía, por ejemplo, pueden usar estas API en lugar de READ_EXTERNAL_STORAGE, que otorga acceso a todos los directorios de almacenamiento, o al framework de acceso a almacenamiento, con lo cual el usuario accede al directorio.

A su vez, las nuevas API simplifican los pasos que un usuario debe seguir para otorgar a tu app acceso a almacenamiento externo. Cuando se usan las nuevas API, el sistema emplea una IU de permisos simple en la que se detallan claramente los directorios a los cuales la aplicación solicita acceso.

Para obtener más información, consulta la documentación Acceso a directorios determinados para desarrolladores.

Ayuda en las combinaciones de teclas

En Android 7.0, el usuario puede presionar Meta + / para activar una pantalla de combinaciones de teclas en la que se muestran todas las combinaciones de teclas disponibles, tanto en el sistema como en la app que esté en foco. El sistema recupera estas combinaciones de teclas automáticamente desde el menú de la app si estas existen. Además, puedes proporcionar tus propias listas de combinaciones de teclas personalizadas para la pantalla. Puedes hacerlo anulando el nuevo método Activity.onProvideKeyboardShortcuts(); esto se describe en la Referencia de API descargable.

Nota: La tecla Meta no está presente en todos los teclados. En un teclado Macintosh, se trata de la tecla Command; en el teclado Windows, es Windows; en los teclados de Pixel C y del Sistema Operativo Chrome, Search.

Para activar la ayuda de combinaciones de teclas desde cualquier ubicación de la app, llama a Activity.requestKeyboardShortcutsHelper() para la actividad en cuestión.

Custom Pointer API

En Android 7.0 se presenta la Custom Pointer API, que te permite personalizar la apariencia, la visibilidad y el comportamiento de este. Esta capacidad es particularmente útil cuando un usuario usa un mouse o panel táctil para interactuar con objetos de la IU. El puntero predeterminado usa un ícono estándar. Esta API también incluye funcionalidades avanzadas; por ejemplo, el cambio de apariencia del ícono del puntero según los movimientos específicos del mouse o del panel táctil.

Para configurar un ícono de puntero, anula el método onResolvePointerIcon() de la clase View. Este método usa un objeto PointerIcon para dibujar el ícono que corresponde a un evento de movimiento específico.

Sustained Performance API

El rendimiento puede fluctuar considerablemente en apps de ejecución prolongada, ya que el sistema limita los motores de sistemas en chip cuando los componentes del dispositivo alcanzan sus límites de temperatura. Esta fluctuación presenta un objetivo móvil para los desarrolladores que creen apps de alto rendimiento y ejecución prolongada.

En Android 7.0 se incluye compatibilidad opcional para un modo de rendimiento sostenido, lo cual permite que los OEM proporcionen datos sobre las capacidades de rendimiento de dispositivos para apps de ejecución prolongada. Los desarrolladores de apps pueden usar estos datos para perfeccionar sus apps y alcanzar un nivel uniforme y predecible de rendimiento en el dispositivo durante períodos de tiempo prolongados.

Los desarrolladores de apps solo pueden probar esta API nueva en Android 7.0, en dispositivos Nexus 6P. Para usar esta función, establece el indicador de rendimiento sostenido de la ventana que desees ejecutar en el modo de rendimiento sostenido. Establece este indicador con el método Window.setSustainedPerformanceMode(). El sistema inhabilita automáticamente este modo cuando la ventana deja de estar en foco.

Compatibilidad RV

Android 7.0 agrega compatibilidad y optimizaciones de plataforma para un modo de RV nuevo, con el objetivo de que los desarrolladores puedan crear experiencias de RV móviles de alta calidad para los usuarios. Hay varias mejoras en el rendimiento; entre ellas se incluye el acceso a un núcleo de CPU exclusivo para apps de RV. Dentro de tus apps, puedes aprovechar el seguimiento de cabeza inteligente y las notificaciones en sonido estéreo que funcionan para RV. Un dato muy importante es que Android 7.0 admite gráficos de latencia muy baja. Si deseas obtener información completa sobre la compilación de apps de RV para Android 7.0, consulta Google VR SDK para Android.

Mejoras en el servicio de impresión

En Android 7.0, los desarrolladores de servicios de impresión ahora pueden publicar información adicional sobre impresoras y trabajos de impresión individuales.

Al enumerar las impresoras individuales, un servicio de impresión ahora puede establecer íconos por impresora de dos maneras:

• Puedes establecer un ícono desde el ID de un recurso llamando a PrinterInfo.Builder.setResourceIconId().
• Puedes mostrar un ícono de la red llamando a PrinterInfo.Builder.setHasCustomPrinterIcon() y configurando un callback para cuando se solicite el ícono con android.printservice.PrinterDiscoverySession.onRequestCustomPrinterIcon().

Además, puedes proporcionar las actividades por impresora para mostrar información adicional llamando a PrinterInfo.Builder.setInfoIntent().

Puedes indicar el progreso y el estado de los trabajos de impresión en la notificación de trabajo de impresión llamando a android.printservice.PrintJob.setProgress() y android.printservice.PrintJob.setStatus(), respectivamente.

Para obtener más información sobre estos métodos, consulta la Referencia de API descargable.

FrameMetricsListener API

La FrameMetricsListener API permite que una app controle el rendimiento de la representación de su IU. La API brinda esta capacidad mediante la exposición de una transmisión de API Pub/Sub a fin de transferir información sobre el intervalo de los fotogramas para la ventana actual de la app. Los datos devueltos son equivalentes a los que muestra adb shell dumpsys gfxinfo framestats, pero no se limitan a los últimos 120 fotogramas.

Puedes usar FrameMetricsListener para medir el rendimiento de la IU del nivel de interacción en producción sin contar con conexión USB. Esta API permite recopilar datos con una especificidad muy superior a la de adb shell dumpsys gfxinfo. Esta especificidad mayor es posible porque el sistema puede recopilar datos de interacciones determinadas de la app, no es necesario que obtenga un resumen general del rendimiento de toda la app ni borre un estado general. Puedes usar esta capacidad con el objetivo de recopilar datos de rendimiento e identificar regresiones en el rendimiento de la IU para casos de uso reales dentro de una app.

Para controlar una ventana, implementa el callback FrameMetricsListener.onMetricsAvailable() y regístralo en esa ventana. Para obtener más información, consulta la documentación de la clase FrameMetricsListener en la Referencia de API descargable.

La API proporciona un objeto FrameMetrics, el cual contiene datos de intervalos que el subsistema de representación transmite sobre varios hitos en el ciclo de vida de un fotograma. Las métricas compatibles son las siguientes: UNKNOWN_DELAY_DURATION, INPUT_HANDLING_DURATION, ANIMATION_DURATION, LAYOUT_MEASURE_DURATION, DRAW_DURATION, SYNC_DURATION, COMMAND_ISSUE_DURATION, SWAP_BUFFERS_DURATION, TOTAL_DURATION y FIRST_DRAW_FRAME.

Archivos virtuales

En versiones anteriores de Android, tu app podía usar el framework de acceso al almacenamiento para permitir que los usuarios seleccionaran archivos de sus cuentas de almacenamiento en la nube, como Google Drive. Sin embargo, no se podían representar los archivos que no tenían una representación directa en código de bytes; cada archivo debía brindar un flujo de entrada.

Android 7.0 incorpora el concepto de archivos virtuales al framework de acceso al almacenamiento. La función de archivos virtuales permite que tu DocumentsProvider muestre URI de documentos que se pueden usar en una intent ACTION_VIEW incluso cuando no tienen una representación directa en código de bytes. Android 7.0 también te permite ofrecer formatos alternativos para archivos del usuario y virtuales, entre otros.

Para obtener un URI de un documento virtual en tu app, primero crea una Intent a fin de abrir la IU del selector de archivos. Debido a que una app no puede abrir directamente un archivo virtual con el método openInputStream(), la app no recibe ningún archivo virtual si incluyes la categoría CATEGORY_OPENABLE.

Cuando el usuario realiza una selección, el sistema llama al método onActivityResult(). La app puede recuperar el URI del archivo virtual y obtener un flujo de entrada, como se demuestra en el fragmento de código a continuación.

  // Other Activity code ...

  final static private int REQUEST_CODE = 64;

  // We listen to the OnActivityResult event to respond to the user's selection.
  @Override
  public void onActivityResult(int requestCode, int resultCode,
    Intent resultData) {
      try {
        if (requestCode == REQUEST_CODE &&
            resultCode == Activity.RESULT_OK) {

            Uri uri = null;

            if (resultData != null) {
                uri = resultData.getData();

                ContentResolver resolver = getContentResolver();

                // Before attempting to coerce a file into a MIME type,
                // check to see what alternative MIME types are available to
                // coerce this file into.
                String[] streamTypes =
                  resolver.getStreamTypes(uri, "*/*");

                AssetFileDescriptor descriptor =
                    resolver.openTypedAssetFileDescriptor(
                        uri,
                        streamTypes[0],
                        null);

                // Retrieve a stream to the virtual file.
                InputStream inputStream = descriptor.createInputStream();
            }
        }
      } catch (Exception ex) {
        Log.e("EXCEPTION", "ERROR: ", ex);
      }
  }

Para obtener más información sobre el acceso a archivos del usuario, consulta la guía Frameworks de acceso a almacenamiento.