Android 7.0 para desarrolladores

Android 7.0 Nougat presenta una variedad de 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 las áreas en las que los cambios de la plataforma podrían afectar tus apps.

Si quieres 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 el modo multiventana.

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

• En teléfonos y tablets que ejecutan Android 7.0, los usuarios pueden ejecutar dos apps en paralelo o una encima de la otra en el modo de pantalla dividida. Los usuarios pueden cambiar el tamaño de las aplicaciones arrastrando la línea divisoria que se encuentra entre ellas.
• En los dispositivos Android TV, las apps pueden habilitar el modo de pantalla en pantalla, lo que les permite seguir mostrando contenido mientras el usuario explora otras apps o interactúa con ellas.

Especialmente en tablets y otros dispositivos de pantallas más grandes, la compatibilidad con el modo multiventana ofrece nuevas formas de atraer a los usuarios. Incluso puedes habilitar la función de arrastrar y soltar en tu app para permitir que los usuarios arrastren contenido desde o hacia ella de manera conveniente. Esta es una excelente manera de mejorar su experiencia.

Es sencillo agregar compatibilidad con el modo multiventana a tu app y configurar la manera en que controla la visualización multiventana. Por ejemplo, puedes especificar las dimensiones mínimas permitidas de tu actividad y evitar así que los usuarios cambien el tamaño de la actividad por debajo de ese tamaño. También puedes inhabilitar la visualización multiventana para tu app, lo que garantiza que el sistema solo muestre tu app en modo de pantalla completa.

Para obtener más información, consulta la documentación para desarrolladores sobre Compatibilidad con el modo multiventana.

Mejoras en las notificaciones

En Android 7.0, rediseñamos 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 hero image 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 mensaje: 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 de contenido.
• Notificaciones agrupadas: El sistema puede agrupar mensajes (por ejemplo, por tema) y mostrar el grupo. Un usuario puede aplicar acciones, como Descartar o Archivar, en ellos. Si implementaste 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 Android admite respuestas en línea para que los usuarios puedan responder rápidamente un SMS o mensaje de texto directamente dentro de la interfaz de notificaciones.
• Vistas personalizadas: Hay dos APIs nuevas que te permiten aprovechar las decoraciones del sistema, como los encabezados y las acciones de notificaciones, cuando usas vistas personalizadas en las notificaciones.

Figura 2: Notificaciones integradas y respuesta directa.

Si quieres obtener información para implementar las funciones nuevas, consulta la guía sobre 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 que le permite mejorar constantemente el rendimiento de las apps para Android mientras se ejecutan. El compilador JIT complementa el compilador Ahead of Time (AOT) actual de ART y ayuda a mejorar el rendimiento del tiempo de ejecución, ahorrar espacio de almacenamiento y acelerar las actualizaciones de apps y del sistema.

La compilación guiada por perfiles permite que ART administre la compilación de AOT y JIT de cada app según su uso real, así como las condiciones del dispositivo. Por ejemplo, ART mantiene un perfil de los métodos activos de cada app y puede compilar previamente y almacenar en caché esos métodos para obtener el mejor rendimiento. 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 ayuda a reducir el espacio total en RAM de una app, incluidos los objetos 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 está inactivo y en carga, lo que 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 tangibles del compilador JIT de ART es la velocidad de instalación de apps y las actualizaciones del sistema. Incluso las apps de mayor tamaño, que necesitaban varios minutos de optimización e 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, ya que no hay más paso de optimización.

Descanso sobre la marcha...

Android 6.0 introdujo Descanso, un modo del sistema que ahorra batería aplazando las actividades de CPU y red de las apps cuando el dispositivo está inactivo, por ejemplo, cuando está sentado en una mesa o en un cajón.

Ahora, en Android 7.0, Descanso aplica un subconjunto de las restricciones de CPU y red conocidas a las apps cada vez que la pantalla permanece apagada durante un tiempo y el dispositivo está desenchufado. Esto significa que los usuarios pueden ahorrar batería incluso cuando llevan sus dispositivos en los bolsillos.

Figura 3: Ahora, Descanso aplica restricciones para mejorar la duración de batería, incluso cuando el dispositivo no está quieto.

Poco tiempo después de que la pantalla se apaga, cuando el dispositivo está encendido, Descanso 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 o sincronizaciones diferidas. Al encender la pantalla o enchufar el dispositivo, se desactiva el modo Descanso.

Cuando el dispositivo vuelve a estar quieto, con la pantalla apagada y con la batería durante un tiempo, Descanso aplica las restricciones completas de CPU y red en las alarmas PowerManager.WakeLock y AlarmManager, y las búsquedas de GPS o Wi-Fi.

Las prácticas recomendadas para adaptar tu app a Descanso son las mismas independientemente de si el dispositivo está en movimiento o no. Por lo tanto, si ya actualizaste tu app para que controle correctamente el modo Descanso, ya está todo listo. De lo contrario, comienza a adaptar tu app al modo Descanso ahora.

Project Svelte: Optimizaciones en segundo plano

Project Svelte es un esfuerzo continuo por minimizar el uso de RAM por parte del sistema y las apps en los diferentes dispositivos Android del ecosistema. En Android 7.0, Project Svelte se centra en optimizar la forma 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 bien, puede hacer que la experiencia del usuario sea increíble: inmediata, rápida y contextual. Cuando no se maneja de forma correcta, el procesamiento en segundo plano puede consumir innecesariamente RAM (y batería) y afectar el rendimiento del sistema de otras apps.

A partir de Android 5.0, JobScheduler ha sido la forma preferida de realizar trabajos en segundo plano de modo conveniente para los usuarios. Las apps pueden programar trabajos 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 todas las apps lo usen.

Otra buena opción es GCMNetworkManager, que forma parte de los Servicios de Google Play y ofrece una programación de trabajos similar con compatibilidad con versiones heredadas de Android.

Continuaremos ampliando JobScheduler y GCMNetworkManager para cumplir con más casos de uso. Por ejemplo, en Android 7.0, ahora puedes programar trabajos en segundo plano según los cambios en los proveedores de contenido. Al mismo tiempo, comenzaremos a dar de baja algunos de los patrones anteriores que pueden reducir el rendimiento del sistema, en especial en dispositivos con poca memoria.

En Android 7.0, quitaremos tres transmisiones implícitas de uso general (CONNECTIVITY_ACTION, ACTION_NEW_PICTURE y ACTION_NEW_VIDEO), ya que pueden activar los procesos en segundo plano de varias apps a la vez y sobrecargar la memoria y la batería. Si tu app recibe estas, aprovecha Android 7.0 para migrar a JobScheduler y las APIs relacionadas.

Consulta la documentación sobre Optimizaciones en segundo plano para obtener más detalles.

SurfaceView

Android 7.0 ofrece el movimiento síncrono a la clase SurfaceView, que proporciona un mejor rendimiento de la batería que TextureView en ciertos casos: al renderizar contenido de video o 3D, las apps con desplazamiento y posición de video animado consumen menos energía con SurfaceView que con TextureView.

La clase SurfaceView permite una composición más eficiente en términos de batería en la pantalla, ya que se compone en hardware dedicado, independientemente del contenido de la ventana de la app. Como resultado, se realizan menos copias intermedias que TextureView.

La posición de contenido de un objeto SurfaceView ahora se actualiza de forma síncrona con el contenido de la app que lo contiene. Un resultado de este cambio es que las traducciones simples o las escalas de un video que se reproduce en un SurfaceView ya no producen barras negras junto a la vista a medida que se mueve.

A partir de Android 7.0, te recomendamos que ahorres energí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 suele superar el costo del propio dispositivo. Para muchos usuarios, los datos móviles son un recurso costoso que desean conservar.

Android 7.0 presenta el modo Ahorro de datos, un nuevo servicio del sistema que ayuda a reducir el uso de datos móviles por parte de las apps, ya sea con roaming, cerca del final del ciclo de facturación o en un pequeño paquete de datos prepago. El Ahorro de datos les brinda a los usuarios el control sobre la manera en que las apps usan los datos móviles y permite que los desarrolladores proporcionen un servicio más eficiente cuando el Ahorro de datos está activado.

Cuando un usuario habilita el Ahorro de datos en la Configuración y el dispositivo está en una red de uso medido, el sistema bloquea el uso de datos en segundo plano y señala a las apps que usen 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, aplazando el almacenamiento en caché previo optimista, etcétera. Los usuarios pueden permitir que apps específicas permitan el uso de datos medidos en segundo plano, incluso cuando está activado el Ahorro de datos.

Android 7.0 extiende ConnectivityManager para proporcionarles a las apps una forma de recuperar las preferencias del Ahorro de datos del usuario y supervisar los cambios en las preferencias. Todas las apps deben verificar si el usuario habilitó el Ahorro de datos y esforzarse por limitar el uso de datos en primer y segundo plano.

API de Vulkan

Android 7.0 integra VulkanTM, una nueva API de renderización en 3D, en la plataforma. Al igual que OpenGLTM ES, Vulkan es un estándar abierto para gráficos y renderizaciones 3D que mantiene 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 de manera más directa. Vulkan también permite una mejor paralelización, ya que permite que varios subprocesos realicen trabajos, como la construcción del búfer de comandos, a la vez.

Las herramientas y las bibliotecas de desarrollo de Vulkan son parte del SDK de Android 7.0. Entre ellas, se incluyen las siguientes:

• 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 estrechamente con nuestros socios para que Vulkan pueda usarse en más dispositivos lo antes posible.

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

Quick Settings Tile API

La Configuración rápida es una forma popular y simple de exponer parámetros de configuración y acciones clave directamente desde el panel de notificaciones. En Android 7.0, expandimos el alcance de la Configuración rápida para que sea aún más útil y conveniente.

Agregamos más espacio para tarjetas adicionales de Configuración rápida, a las que los usuarios pueden acceder desde un área de visualización paginada si deslizan el dedo hacia la izquierda o la derecha. También permitimos que los usuarios determinen qué tarjetas de la Configuración rápida aparecerán y dónde se mostrarán; pueden agregar o mover tarjetas con solo arrastrarlas y soltarlas.

Para los desarrolladores, en Android 7.0 también se agrega una nueva API que les permite definir sus propios mosaicos de Configuración rápida para brindar a los usuarios acceso fácil a controles y acciones clave en tu app.

Las tarjetas de Configuración rápida están reservadas para controles o acciones que se requieren con urgencia o se usan con frecuencia, y no deben usarse como accesos directos para iniciar una app.

Una vez que hayas definido tus tarjetas, puedes dejarlas a los usuarios, quienes podrán agregarlas a la Configuración rápida con solo arrastrarlas y soltarlas.

Si deseas obtener información para crear una tarjeta de app, consulta la documentación de referencia de Tile.

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 mantengan una lista de números bloqueados. La app de SMS predeterminada, la app telefónica predeterminada y las apps de operadores pueden leer y escribir 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 los restablecimientos y después de los dispositivos mediante la función Copia de seguridad y restablecimiento.
• Varias apps pueden usar la misma lista de números bloqueados.

Además, la integración de apps de operadores a través de Android permite que estos lean la lista de números bloqueados en el dispositivo y realicen el bloqueo del servicio para el usuario a fin de evitar que reciba llamadas y mensajes de texto no deseados a través de cualquier medio, como un extremo VoIP o teléfonos con desvío de llamadas.

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

Filtración de llamadas

Android 7.0 permite que la app predeterminada de un teléfono filtre las llamadas entrantes. Para ello, la aplicación para teléfonos implementa el nuevo CallScreeningService, que permite que la aplicación para teléfonos realice una serie de acciones según el Call.Details de una llamada entrante, como las siguientes:

• 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 la documentación de referencia de CallScreeningService.

Compatibilidad con varias configuraciones regionales y más idiomas

Android 7.0 ahora permite a los usuarios seleccionar varias configuraciones regionales en Configuración para brindar una mejor compatibilidad con casos de uso bilingües. Las apps pueden usar una API nueva para obtener las configuraciones regionales seleccionadas del usuario y, luego, ofrecer experiencias más sofisticadas para usuarios que usan varias configuraciones regionales, como mostrar resultados de la búsqueda en varios idiomas y no ofrecer traducir páginas web en un idioma que el usuario ya conoce.

Además de la compatibilidad con varias configuraciones regionales, en Android 7.0 también se amplía la variedad de idiomas disponibles para los usuarios. Se ofrecen más de 25 variantes, cada una 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 que estableció el usuario llamando a LocaleList.GetDefault(). Para admitir la cantidad expandida de configuraciones regionales, Android 7.0 está cambiando la forma en que resuelve los recursos. Asegúrate de probar y verificar que tus apps funcionen como se espera con la nueva lógica de resolución de recursos.

Para obtener más información sobre el nuevo comportamiento de resolución de recursos y las prácticas recomendadas que debes seguir, consulta Asistencia multilingüe.

Nuevos emojis

En Android 7.0, se presentan más emojis y funciones relacionadas con emojis, como emojis de tono de piel y compatibilidad con selectores de variación. Si tu app admite emojis, sigue los lineamientos que se indican a continuación para aprovechar estas funciones relacionadas con emojis.

• Comprueba que el dispositivo contenga un emoji antes de insertarlo. Para comprobar qué emojis están 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 tu app muestra los emojis intercalados con el texto, 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 obtener una lista completa de los caracteres con variantes, consulta la sección de secuencias de variación de emojis de la documentación de Unicode sobre las variaciones.
• Comprobar que el emoji admita el tono de piel Android 7.0 permite a los usuarios modificar el tono de piel renderizado de los emojis según su preferencia. Las apps de teclado deben proporcionar indicaciones visuales para los emojis que tienen varios tonos de piel y permitir que los usuarios seleccionen el que prefieran. Para determinar qué emojis del sistema tienen modificadores de tono de piel, usa el método hasGlyph(String). Puedes determinar qué emojis usan tonos de piel en la documentación de Unicode.

Las ICU4J API en Android

Android 7.0 ahora ofrece un subconjunto de las APIs de ICU4J en el framework de Android, en el paquete android.icu. La migración es fácil y, en su mayoría, implica solo un cambio del espacio de nombres com.java.icu a android.icu. Si ya usas un paquete ICU4J en tus apps, cambiar a las APIs de android.icu proporcionadas en el framework de Android puede reducir notablemente el tamaño del APK.

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

WebView

Chrome + WebView, juntos

A partir de la versión 51 de Chrome en Android 7.0 y versiones posteriores, el APK de Chrome de tu dispositivo se usa para proporcionar y renderizar WebViews del sistema Android. Este enfoque mejora el uso de memoria en el propio dispositivo y también reduce el ancho de banda necesario para mantener WebView actualizado (ya que el APK de WebView independiente ya no se actualizará mientras Chrome permanezca habilitado).

Para elegir tu proveedor de WebView, habilita las Opciones para desarrolladores y selecciona Implementación de WebView. Puedes usar cualquier versión compatible de Chrome (para desarrolladores, beta o estable) que esté instalada en tu dispositivo o el APK de WebView independiente para que actúe como implementación de WebView.

Multiproceso

A partir de la versión 51 de Chrome en Android 7.0, WebView ejecutará contenido web en un proceso independiente de zona de pruebas cuando se habilite la opción para desarrolladores "Multiprocess WebView".

Esperamos recibir comentarios sobre la compatibilidad y el rendimiento del tiempo de ejecución en N antes de habilitar WebView multiproceso en una versión futura de Android. En esta versión, se esperan regresiones en el tiempo de inicio, el uso total de memoria y el rendimiento de la renderización de software.

Si encuentras problemas inesperados en el modo multiproceso, nos gustaría conocerlos. Comunícate con el equipo de WebView en el registro 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 página nueva. 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 una vez que la página haya comenzado a cargarse.

Ubicación geográfica en orígenes inseguros

A partir de las apps orientadas a Android 7.0, la API de ubicación geográfica solo se permitirá en orígenes seguros (a través de HTTPS). Esta política se diseñó para proteger la información privada de los usuarios cuando usen una conexión no segura.

Pruebas con WebView Beta

WebView se actualiza con regularidad, por lo que te recomendamos que, a menudo, pruebes la compatibilidad con tu app mediante el canal beta de WebView. Para comenzar a probar las versiones previas al lanzamiento de WebView en Android 7.0, descarga e instala Chrome Dev o Chrome Beta, y selecciónalo como implementación de WebView en las opciones para desarrolladores, como se describió anteriormente. Informa los problemas mediante el registro de errores de Chromium para que podamos corregirlos antes de que se lance una nueva versión de WebView.

API de OpenGLTM ES 3.2

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), excepto 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. Cuando uses 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 API de OpenGL ES.

Grabación de Android TV

Android 7.0 agrega la capacidad de grabar y reproducir contenido de los servicios de entrada de Android TV a través de nuevas APIs de grabación. A partir de las APIs de pausa en directo existentes, los servicios de entrada de TV pueden controlar qué datos de canales se pueden grabar y cómo se guardan las sesiones grabadas, y administrar la interacción del usuario con el contenido grabado.

Para obtener más información, consulta las APIs de grabación de Android TV.

Android for Work

Android for Work suma muchas funciones y API nuevas para dispositivos con Android 7.0. A continuación, se incluyen algunos aspectos destacados. Para obtener más detalles, consulta la Lista de funciones de Android Enterprise.

Comprobación de seguridad para perfiles de trabajo

Los propietarios de perfiles que se orientan al SDK de N pueden especificar una comprobación de seguridad independiente para las apps que se ejecutan en el perfil de trabajo. La comprobación 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 desencripta si es necesario. En el caso de los propietarios de perfiles, ACTION_SET_NEW_PASSWORD le solicita al usuario que configure una verificación de trabajo, y ACTION_SET_NEW_PARENT_PROFILE_PASSWORD le solicita configurar un bloqueo del dispositivo.

Los propietarios de perfiles pueden establecer políticas de contraseñas distintas para la comprobación de trabajo (por ejemplo, la longitud del PIN o si se puede usar una huella dactilar para desbloquear el perfil) con setPasswordQuality(), setPasswordMinimumLength() y métodos relacionados. El propietario del perfil también puede establecer el bloqueo del dispositivo con la instancia de DevicePolicyManager que muestra el nuevo método getParentProfileInstance(). Además, los propietarios de perfiles pueden personalizar la pantalla de credenciales para la comprobación de trabajo mediante 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 modo está desactivado, el usuario administrado se cierra temporalmente, lo que inhabilita las apps del perfil 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á desactivado, el sistema muestra un ícono de estado persistente para recordarle al usuario que no puede iniciar apps de trabajo. El selector indica que no se puede acceder a las apps ni los 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 automáticamente esa VPN después de que se inicia el dispositivo.

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

Debido a que el sistema puede vincular directamente los servicios de VPN sin interacción con la app, los clientes de VPN deben controlar los puntos de entrada nuevos para la VPN siempre activada. Al igual que antes, los servicios se indican al sistema con una acción de coincidencia de filtro de intents android.net.VpnService.

Los usuarios también pueden configurar manualmente clientes de VPN siempre activados que implementen métodos VPNService mediante Configuración> Más> VPN. La opción para habilitar la VPN siempre activada desde la configuración solo está disponible si el cliente de VPN se orienta al nivel de API 24.

Aprovisionamiento personalizado

Una app puede personalizar los flujos de aprovisionamiento del propietario del perfil y del propietario del dispositivo con colores y logotipos 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 con mayor facilidad las funciones de accesibilidad en sus dispositivos, incluidos el gesto de ampliación, el tamaño de la fuente, el tamaño de la pantalla y TalkBack.

Cuando estas funciones de accesibilidad adquieren una posición más destacada, es más probable que los usuarios prueben tu app con ellas habilitadas. Asegúrate de probar tus apps antes con estos parámetros de configuración habilitados. Puedes habilitarlas en Configuración > Accesibilidad.

Además, los servicios de accesibilidad de Android 7.0 ahora pueden ayudar a los usuarios con discapacidades motrices a tocar la pantalla. La nueva API permite crear servicios con funciones como el seguimiento de rostros o la vista o la búsqueda puntual, entre otros, para satisfacer las necesidades de esos usuarios.

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

Inicio directo

El inicio directo mejora los tiempos de inicio del dispositivo y permite que las apps registradas tengan una funcionalidad limitada, incluso después de un reinicio inesperado. Por ejemplo, si un dispositivo encriptado se reinicia mientras el usuario duerme, las alarmas, los mensajes y las llamadas entrantes registradas ahora pueden continuar notificando al usuario como de costumbre. Esto también significa que los servicios de accesibilidad también pueden estar disponibles inmediatamente 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 la app. El sistema usa un almacén encriptado por el dispositivo para determinados datos del sistema y datos de apps registrados de forma explícita. De forma predeterminada, se usa un almacén encriptado con credenciales para todos los demás datos del sistema, datos del usuario, apps y datos de apps.

Durante el inicio, el sistema se inicia en un modo restringido con acceso solo 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 una marca en el manifiesto. Después del reinicio, el sistema activa componentes registrados transmitiendo el intent LOCKED_BOOT_COMPLETED. El sistema garantiza que estén disponibles los datos de apps encriptados por el dispositivo registrados antes del desbloqueo. No es posible acceder a los demás datos hasta que el usuario confirme sus credenciales de pantalla de bloqueo para desencriptarlos.

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

Certificación de claves

Android 7.0 presenta la certificación de claves, una nueva herramienta de seguridad que te ayuda a garantizar que los pares de claves almacenados en el almacén de claves con copia de seguridad en hardware del dispositivo protejan adecuadamente la información sensible que usa tu app. Cuando usas esta herramienta, aumentas la confianza de que tu app interactúa con claves que residen en hardware seguro, incluso si el dispositivo que la ejecuta tiene permisos de administrador. Si usas claves del almacén de claves guardadas en hardware en tus apps, debes usar esta herramienta, especialmente si usas las claves para verificar información sensible en tu app.

La certificación de claves te permite verificar que se creó un par de claves RSA o EC y que se almacenó en un almacén de claves guardadas en hardware del dispositivo, dentro del entorno de ejecución confiable (TEE) del dispositivo. La herramienta también te permite usar un servicio fuera del dispositivo, como el servidor de backend de tu app, para determinar y verificar con precisión los usos y la validez del par de claves. Estas funciones proporcionan un nivel adicional de seguridad que protege el par de claves, incluso si alguien tiene permisos de administrador en el dispositivo o pone en riesgo la seguridad de la plataforma de Android que se ejecuta en el dispositivo.

Nota: Solo una pequeña cantidad de dispositivos con Android 7.0 admiten certificación de claves a nivel del hardware. En todos los demás dispositivos con Android 7.0, se usa certificació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 certificación de claves a nivel del hardware. Para ello, debes comprobar que la cadena de certificación contenga un certificado raíz firmado por la clave raíz de certificación de Google y que el elemento attestationSecurityLevel dentro de la estructura de datos de la descripción de la clave se configure a nivel de seguridad de TrustedEnvironment.

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

Configuración de seguridad de la red

En Android 7.0, las apps pueden personalizar el comportamiento de sus conexiones seguras (HTTPS y TLS) de manera segura, sin modificar el código, mediante la Configuración de seguridad de la red declarativa en lugar de usar las APIs programáticas convencionales propensas a errores (p.ej., X509TrustManager).

Funciones admitidas:

• Anclas de confianza personalizadas. Permite personalizar qué autoridades certificadoras (AC) son de confianza para las conexiones de seguridad de una aplicación. Por ejemplo, confiar en certificados autofirmados particulares o en un conjunto restringido de AC públicas.
• Anulaciones solo de 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.
• Inhabilitación del tráfico de texto simple. Permite que una aplicación se proteja a sí misma del uso accidental de tráfico de texto simple.
• Fijación de certificados: Es una función avanzada que permite que una aplicación limite las claves de servidor en las que se pueda confiar para conexiones seguras.

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

Entidad de certificación de confianza predeterminada

De forma predeterminada, las apps que se orientan a Android 7.0 solo confían en los certificados proporcionados por el sistema y ya no confían en las autoridades certificadoras (CA) agregadas por el usuario. Las apps orientadas a Android 7.0 (nivel de API 24) que deseen confiar en las AC agregadas por el usuario deben usar la configuración de seguridad de red para especificar cómo se deben considerar las AC de usuario.

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 tiempos de instalación de apps más rápidos y más 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.

Si bien te recomendamos que apliques el esquema de firma de APK v2 a 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 el esquema nuevo. La inhabilitación del proceso hace que Android Studio 2.2 y el complemento de Android para Gradle 2.2 firmen tu app con el esquema de firma tradicional. Para firmar solo con el esquema tradicional, abre el archivo build.gradle a nivel del módulo y, luego, 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
      }
    }
  }

Precaución: Si firmas la app con el esquema de firma de APK v2 y realizas más cambios en la app, 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 que describen cómo firmar una app en Android Studio y cómo 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 APIs nuevas para solicitar acceso a directorios de almacenamiento externo específicos, incluidos los directorios de medios extraíbles, como tarjetas SD. Las nuevas APIs simplifican enormemente la manera en que tu aplicación accede a directorios de almacenamiento externo estándares, como Pictures. Las apps de fotos, como las de fotos, pueden usar estas APIs en lugar de READ_EXTERNAL_STORAGE, que otorga acceso a todos los directorios de almacenamiento, o al framework de acceso al almacenamiento, que hace que el usuario navegue al directorio.

Además, las nuevas APIs simplifican los pasos que debe seguir el usuario para otorgar acceso al almacenamiento externo a tu app. Cuando usas las APIs nuevas, el sistema emplea una IU de permisos simple que detalla con claridad a qué directorio solicita acceso la aplicación.

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

Ayuda en las combinaciones de teclas

En Android 7.0, el usuario puede presionar Meta + / para activar una pantalla de combinaciones de teclas que muestra todas las combinaciones de teclas disponibles desde el sistema y la app en primer plano. El sistema recupera estas combinaciones de teclas automáticamente desde el menú de la app, si existen. También puedes proporcionar tus propias listas de combinaciones de teclas optimizadas para la pantalla. Para ello, anula el método onProvideKeyboardShortcuts().

Nota: La tecla Meta no está presente en todos los teclados: en un teclado de Macintosh, es la tecla Comando, en el teclado de Windows, es la tecla Windows y en Pixel C y en los teclados de ChromeOS, es la tecla de Búsqueda.

Para activar la Ayuda de combinaciones de teclas desde cualquier parte de la app, llama a requestShowKeyboardShortcuts() desde la actividad relevante.

Custom Pointer API

Android 7.0 presenta la API de Custom Pointer, que te permite personalizar la apariencia, la visibilidad y el comportamiento del puntero. Esta función es especialmente útil cuando un usuario utiliza un mouse o un panel táctil para interactuar con objetos de la IU. El puntero predeterminado usa un ícono estándar. Esta API también incluye funciones avanzadas, como cambiar el aspecto del ícono del puntero según movimientos específicos del mouse o del panel táctil.

Para establecer 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 las apps de larga duración, ya que el sistema limita los motores del sistema 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 crean apps de alto rendimiento y ejecución prolongada.

Para abordar estas limitaciones, Android 7.0 incluye compatibilidad con el modo de rendimiento sostenido, lo que permite que los OEM proporcionen sugerencias sobre las capacidades de rendimiento del dispositivo para las apps de larga duración. Los desarrolladores de apps pueden usar estas sugerencias para ajustar las apps y alcanzar un nivel predecible y uniforme de rendimiento del dispositivo durante períodos prolongados.

Los desarrolladores de apps solo pueden probar esta nueva API en Android 7.0 en dispositivos Nexus 6P. Si quieres usar esta función, configura la marca de rendimiento sostenido para la ventana que deseas ejecutar en el modo de rendimiento sostenido. Configura esta marca con el método Window.setSustainedPerformanceMode(). El sistema inhabilita automáticamente este modo cuando la ventana deja de estar en primer plano.

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 de alta calidad para dispositivos móviles para los usuarios. Se realizaron mejoras de rendimiento, como 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 el modo RV. Lo más importante es que Android 7.0 proporciona gráficos de muy baja latencia. Para obtener información completa sobre cómo compilar apps de RV para Android 7.0, consulta el SDK de RV de Google para Android.

Mejoras en el servicio de impresión

En Android 7.0, los desarrolladores de servicios de impresión ahora pueden mostrar 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 llamar a setIconResourceId() para configurar un ícono desde el ID de un recurso.
• Puedes mostrar un ícono de la red llamando a setHasCustomPrinterIcon() y configurando una devolución de llamada para cuando se solicite el ícono mediante onRequestCustomPrinterIcon().

Además, puedes proporcionar una actividad por impresora para mostrar información adicional llamando a 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 setProgress() y setStatus(), respectivamente.

API de Frame Metrics

La API de Frame Metrics permite que una app supervise el rendimiento de la renderización de la IU. La API proporciona esta función mediante la exposición de una API de Pub/Sub de transmisión para transferir información sobre el tiempo de los fotogramas de la ventana actual de la app. Los datos que se muestran son equivalentes a los que muestra adb shell dumpsys gfxinfo framestats, pero no se limitan a los últimos 120 fotogramas.

Puedes usar la API de Frame Metrics para medir el rendimiento de la IU a nivel de interacción en producción, sin una conexión USB. Esta API permite recopilar datos con un nivel de detalle mucho mayor que adb shell dumpsys gfxinfo. Este nivel de detalle mayor es posible porque el sistema puede recopilar datos de interacciones particulares en la app. No es necesario que el sistema capture un resumen global del rendimiento de toda la app ni borre ningún estado global. Puedes usar esta capacidad para recopilar datos de rendimiento y detectar regresiones en el rendimiento de la IU para casos de uso reales dentro de una app.

Para supervisar una ventana, implementa el método de devolución de llamada OnFrameMetricsAvailableListener.onFrameMetricsAvailable() y regístralo en esa ventana.

La API proporciona un objeto FrameMetrics, que contiene datos de tiempo que el subsistema de renderización informa sobre varios eventos importantes en el ciclo de vida de un fotograma. Las métricas admitidas 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 seleccionen archivos de sus cuentas de almacenamiento en la nube, como Google Drive. Sin embargo, no había forma de representar los archivos que no tenían una representación directa en código de bytes; cada archivo debía proporcionar un flujo de entrada.

Android 7.0 agrega el concepto de archivos virtuales al framework de acceso al almacenamiento. La función de archivos virtuales permite que tu DocumentsProvider muestre los URIs de documentos que se pueden usar con un intent ACTION_VIEW, incluso si 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, virtuales o de otro tipo.

Para obtener más información sobre cómo abrir archivos virtuales, consulta Cómo abrir archivos virtuales en la guía de frameworks de acceso a almacenamiento.