Cambios de comportamiento en Android 7.0

Además de las nuevas funciones y capacidades, Android 7.0 incluye varios cambios de comportamiento del sistema y de la API. Este documento se destacan algunos de los cambios clave que debe comprender y tener en cuenta. en tus apps.

Si publicaste anteriormente una app para Android, ten en cuenta que podrían verse afectadas por estos cambios en la plataforma.

Batería y memoria

Android 7.0 incluye cambios en el comportamiento del sistema para mejorar la duración de la batería de los dispositivos y reducir el uso de RAM. Estos cambios pueden afectar el acceso de tu app a los recursos del sistema y la forma en que tu app interactúa con otras apps a través de determinados intents implícitos.

Descanso

El modo Descanso, presentado en Android 6.0 (nivel de API 23), mejora la duración de la batería en Diferir las actividades de CPU y red cuando un usuario deja un dispositivo desconectado estacionaria y con la pantalla apagada. Android 7.0 ofrece aún más mejoras a Descanso mediante la aplicación de un subconjunto de restricciones de CPU y red mientras el dispositivo está desenchufado con la pantalla apagada, pero no necesariamente estacionario, por ejemplo, cuando un teléfono viaja en el bolsillo del usuario.

Figura 1: Ilustración de cómo Descanso aplica un primer nivel de restricciones de actividad del sistema para prolongar la duración de la batería.

Cuando un dispositivo funciona con la batería y la pantalla estuvo apagada durante cierta cantidad de tiempo tiempo, el dispositivo entra en Descanso y aplica el primer subconjunto de restricciones: se desactiva el acceso de las apps a la red y aplaza tareas y sincronizaciones. Si el dispositivo es inmóvil durante un tiempo determinado tras activar el modo Descanso, el sistema aplica el resto de las restricciones de Descanso a PowerManager.WakeLock AlarmManager alarmas, GPS y escaneos de Wi-Fi. Independientemente de sin importar si se aplican algunas o todas las restricciones del modo Descanso, el sistema activa el dispositivo por períodos de mantenimiento breves, durante los cuales se permiten las aplicaciones no tienen acceso a la red y pueden ejecutar tareas o sincronizaciones aplazadas.

Figura 2: Ilustración de cómo Descanso aplica un segundo nivel de restricciones de actividad del sistema después de que el dispositivo permanece quieto durante un tiempo determinado.

Ten en cuenta que, cuando se activa la pantalla o se enchufa el dispositivo, se desactivan las funciones Descanso y quita estas restricciones de procesamiento. El comportamiento adicional afectan las recomendaciones y prácticas recomendadas para adaptar tu app al versión de Descanso, presentada en Android 6.0 (nivel de API 23), como se explica en Cómo optimizar para Descanso y App Standby. De todos modos sigue esas recomendaciones, como usar Firebase Cloud Messaging (FCM) para enviar y recibir mensajes, y comenzar a planificar actualizaciones para adaptarse a los comportamiento adicional de Descanso.

Project Svelte: Optimizaciones en segundo plano

En Android 7.0, se quitan tres transmisiones implícitas para ayudar a optimizar ambas el uso de memoria y el consumo de energía. Este cambio es necesario porque el a menudo inician aplicaciones registradas para escucharlas en segundo plano. Quitar estas transmisiones puede beneficiar al dispositivo del rendimiento y la experiencia del usuario.

Los dispositivos móviles están en movimiento con frecuencia entre Wi-Fi y datos móviles. Actualmente, las apps pueden supervisar los cambios registrando un receptor para la transmisión implícita CONNECTIVITY_ACTION en su . Debido a que muchas aplicaciones se registran para recibir esta transmisión, un único switch de red puede hacer que todos se activen y procesen la transmisión en una vez.

Del mismo modo, en versiones anteriores de Android, las apps podían registrarse para recibir transmisiones implícitas ACTION_NEW_PICTURE y ACTION_NEW_VIDEO de otras apps, como Cámara. Cuando un usuario toma una foto con la app de Cámara, estas apps se activan para procesar la transmisión.

Para corregir estos problemas, en Android 7.0 se aplica lo siguiente: optimizaciones:

• Las apps que se orientan a Android 7.0 (nivel de API 24) y versiones posteriores no recibirán transmisiones de CONNECTIVITY_ACTION si declaran su receptor de emisión en el manifiesto. Las apps seguirán recibiendo transmisiones de CONNECTIVITY_ACTION si registran su BroadcastReceiver con Context.registerReceiver(), y ese contexto sigue siendo válido.
• El sistema ya no envía transmisiones ACTION_NEW_PICTURE ni ACTION_NEW_VIDEO. Esta optimización afecta a todas las apps, no solo a las orientadas a Android 7.0.

Si tu app usa alguno de estos intents, debes quitar las dependencias en ellos lo antes posible para poder orientar los dispositivos con Android 7.0 correctamente. El framework de Android ofrece varias soluciones para mitigar la necesidad de estas transmisiones implícitas. Por ejemplo, la API de JobScheduler proporciona un mecanismo sólido para programar operaciones de red cuando se establecen condiciones específicas, como una conexión a un de red no medida. Incluso puedes usar JobScheduler para reaccionar a los cambios realizados en los proveedores de contenido.

Para obtener más información sobre las optimizaciones en segundo plano en Android 7.0 (nivel de API) 24) y cómo adaptar tu app, consulta Contexto Optimizaciones.

Cambios en los permisos

En Android 7.0, se incorporan cambios en permisos que pueden afectar tu app.

Cambios en los permisos del sistema de archivos

Para mejorar la seguridad de los archivos privados, el directorio privado de Las apps orientadas a Android 7.0 o versiones posteriores tienen acceso restringido (0700). Este parámetro de configuración evita la filtración de metadatos de archivos privados, como su tamaño o existencia. Este cambio en los permisos tiene varios efectos secundarios:

• El propietario ya no debería flexibilizar los permisos de archivo de los archivos privados. y un intento de hacerlo utilizando MODE_WORLD_READABLE y/o MODE_WORLD_WRITEABLE, activará un SecurityException

  Nota: Por el momento, esta restricción no se aplicará por completo. Las aplicaciones aún pueden modificar los permisos de su directorio privado con las APIs nativas o la API de File. Sin embargo, y desalentar la flexibilización de los permisos para el directorio privado.

• Si pasas URI de file:// fuera del dominio del paquete, es posible que con una ruta inaccesible. Por lo tanto, los intentos de pasar El URI file:// activa un FileUriExposedException La forma recomendada de compartir el contenido de un archivo privado usa FileProvider.
• DownloadManager ya no puede compartir contenido de forma privada archivos almacenados por nombre de archivo. Las aplicaciones heredadas pueden tener un ruta inaccesible cuando se accede a COLUMN_LOCAL_FILENAME. Orientación de aplicaciones Android 7.0 o versiones posteriores activan una SecurityException cuando intentando acceder COLUMN_LOCAL_FILENAME aplicaciones heredadas que establecen la ubicación de descarga en una ubicación pública mediante mediante DownloadManager.Request.setDestinationInExternalFilesDir() o DownloadManager.Request.setDestinationInExternalPublicDir() aún pueden acceder a la ruta en Sin embargo, COLUMN_LOCAL_FILENAME, este no se recomienda. La forma preferida de acceder a un archivo que expone DownloadManager usa ContentResolver.openFileDescriptor()

Intercambio de archivos entre apps

En las apps orientadas a Android 7.0, el framework de Android aplica la política de la API de StrictMode que prohíbe exponer los URIs de file:// fuera de tu app. Si una intent con un URI de archivo sale de tu app, esta falla con una excepción FileUriExposedException.

Para compartir archivos entre aplicaciones, debes enviar un URI de content:// y otorgas un permiso de acceso temporal en el URI. La forma más sencilla de otorgar este permiso es con la clase FileProvider Más información sobre permisos y uso compartido de archivos, consulta Cómo compartir archivos.

Mejoras de accesibilidad

Android 7.0 incluye cambios destinados a mejorar la usabilidad de la plataforma para usuarios con baja o discapacidad visual. Estos cambios deben generalmente no requieren cambios de código en tu app, pero debes revisar estas funciones y probarlas con tu app para evaluar el posible impacto en el usuario una experiencia fluida a los desarrolladores.

Zoom de la pantalla

Android 7.0 permite a los usuarios configurar el Tamaño de la pantalla, que amplía o reduce todos los elementos de la pantalla, lo que mejora la accesibilidad del dispositivo para usuarios con baja visión. Los usuarios no pueden hacer zoom en la pantalla más allá de un mínimo de pantalla ancho de sw320dp, que es el ancho de un Nexus 4, un teléfono común de tamaño medio.

Figura 3: En la pantalla de la derecha, se muestra el efecto de aumentar el tamaño de la pantalla de un dispositivo con una imagen del sistema Android 7.0

Cuando cambia la densidad del dispositivo, el sistema notifica a las apps en ejecución en la de la siguiente manera:

• Si una aplicación está orientada al nivel de API 23 o a un nivel inferior, el sistema finaliza automáticamente la aplicación todos sus procesos en segundo plano. Esto significa que si un usuario cambia esa app, abra la pantalla Configuración y cambie la Display size, el sistema cierra la app del mismo de la manera en que lo haría en una situación de poca memoria. Si la app tiene elementos en primer plano de configuración, el sistema notifica a esos procesos sobre el cambio de configuración a medida como se describe en Administración Cambios en tiempo de ejecución, como si hubiera cambiado la orientación del dispositivo.
• Si una app se orienta a Android 7.0, todos sus procesos (en primer y segundo plano) reciben una notificación del cambio de configuración como como se describe en Administración Cambios en el entorno de ejecución

La mayoría de las aplicaciones no necesitan hacer cambios para admitir esta función, siempre y cuando las apps sigan las prácticas recomendadas de Android. Verificaciones específicas que deben realizarse:

• Prueba la app en un dispositivo con un ancho de pantalla de sw320dp. y asegúrate de que funcione bien.
• Cuando cambie la configuración del dispositivo, actualiza los elementos que dependan de la densidad información almacenada en caché, como mapas de bits o recursos almacenados en caché que se cargan desde en cada red. Comprueba si hay cambios en la configuración cuando se reanude la actividad de la app después de la pausa para cada estado.

  Nota: Si almacenas en caché datos que dependen de la configuración, será un es buena idea incluir metadatos relevantes, como la pantalla o la densidad de píxeles de los datos. Guardar estos metadatos te permite decidir si necesitas actualizar los datos almacenados en caché después de una configuración cambio.

• Evita especificar dimensiones con unidades px, ya que no escalan con densidad de la pantalla. En cambio, especifica dimensiones con valores independientes de la densidad unidades de píxeles (dp).

Vision Settings en el asistente de configuración

Vision Settings se incluye en la pantalla de bienvenida de Vision Settings, donde los usuarios pueden establece la siguiente configuración de accesibilidad en un dispositivo nuevo: Gesto de ampliación, Tamaño de fuente Tamaño de la pantalla y TalkBack Este cambio aumenta la visibilidad de errores relacionados con diferentes configuraciones de pantalla. Para evaluar el impacto de esta función, debes probar tus apps con estos configuración habilitada. Puedes encontrar los parámetros en Configuración > Accesibilidad.

Apps del NDK con vínculos a bibliotecas de plataformas

A partir de Android 7.0, el sistema evita que las apps se vinculen dinámicamente. contra bibliotecas que no pertenecen al NDK, lo que puede provocar que tu app falle. Este cambio en El comportamiento tiene como objetivo crear una experiencia coherente de la app en todas las actualizaciones de la plataforma. y diferentes dispositivos. Aunque es posible que tu código no se vincule con bibliotecas privadas, es posible que una biblioteca estática de terceros de tu la app podría hacerlo. Por lo tanto, todos los desarrolladores deben comprobar que sus apps no fallen en dispositivos con Android 7.0. Si tu app usa código nativo, solo debes usar API públicas del NDK.

Existen tres formas en las que tu app podría estar tratando de acceder a una plataforma privada APIs:

• Tu app accede directamente a bibliotecas de plataformas privadas. Deberías actualizar tu app para incluir su propia copia de esas bibliotecas o usar las APIs públicas del NDK.
• Tu app usa una biblioteca de terceros que accede a una plataforma privada bibliotecas. Aunque estés seguro de que tu app no accede a bibliotecas privadas directamente, debes probar tu app para este caso.
• Tu app hace referencia a una biblioteca que no está incluida en su APK. Para ejemplo, esto podría suceder si intentas usar tu propia copia de OpenSSL, pero te olvidaste de empaquetarla con el APK de la app. Es posible que la app se ejecute normalmente en versiones de la plataforma de Android que incluye libcrypto.so. Sin embargo, la app podría fallar en versiones posteriores de Android que no incluyan esta biblioteca (por ejemplo, Android 6.0 y versiones posteriores). Para solucionar este problema, asegúrate de agrupar todos los las bibliotecas que no pertenecen al NDK con tu APK.

Las apps no deben usar bibliotecas nativas que no estén incluidas en el NDK debido a pueden cambiar o quitarse entre diferentes versiones de Android. El de OpenSSL a BoringSSL es un ejemplo de este cambio. Además, porque no hay requisitos de compatibilidad para bibliotecas de plataformas incluidos en el NDK, los diferentes dispositivos pueden ofrecer distintos niveles de compatibilidad.

Para reducir el impacto que esta restricción puede tener de apps lanzadas, un conjunto de bibliotecas que se usa mucho, como libandroid_runtime.so, libcutils.so, libcrypto.so y libssl.so, son temporalmente accesibles en Android 7.0 (nivel de API 24) para apps orientadas al nivel de API 23, o menor. Si tu app carga una de estas bibliotecas, logcat genera una advertencia. y aparecerá un aviso en el dispositivo de destino para notificarte. Si ves estas alertas, debes actualizar tu app para que incluya su propia copia o solo usa las APIs públicas del NDK. Versiones futuras de Android de Google puede restringir por completo el uso de bibliotecas privadas y provocar que de tu app a fallar.

Todas las apps generan un error de tiempo de ejecución cuando llaman a una API que no está activa pública ni accesible temporalmente. El resultado es que System.loadLibrary y dlopen(3) regresan NULL y puede causar que tu app falle. Debes revisar tu código de la app para quitar el uso de APIs de plataformas privadas y probar por completo tus apps con un dispositivo o emulador con Android 7.0 (nivel de API 24). Si eres Para saber si tu app usa bibliotecas privadas, puedes consultar logcat para identificar el error en tiempo de ejecución.

La siguiente tabla describe el comportamiento que deberías esperar en un según el uso de bibliotecas nativas privadas y su API objetivo nivel superior (android:targetSdkVersion).

Bibliotecas	Nivel de API objetivo	Acceso en tiempo de ejecución por medio de un vinculador dinámico	Comportamiento de Android 7.0 (nivel de API 24)	Comportamiento de la plataforma Android futura
Pública incluida en el NDK	Cualquiera	Accesible	Funciona como se espera.	Funciona como se espera.
Privada (bibliotecas privadas temporalmente disponibles)	23 o inferior	Temporalmente disponible	Funciona como se espera, pero aparece una advertencia de logcat.	Error en tiempo de ejecución
Privada (bibliotecas privadas temporalmente disponibles)	24 o superior	Restringido	Error en tiempo de ejecución	Error en tiempo de ejecución
Privada (otra)	Cualquiera	Restringido	Error en tiempo de ejecución	Error en tiempo de ejecución

Verifica si tu app usa bibliotecas privadas

Para ayudarte a identificar problemas cuando cargas bibliotecas privadas, Logcat puede generar un o error de entorno de ejecución. Por ejemplo, si tu app tiene como objetivo el nivel de API 23 o anterior e intenta acceder a una biblioteca privada en un dispositivo con Android 7.0, es posible que veas una advertencia similar a la siguiente:

03-21 17:07:51.502 31234 31234 W linker  : library "libandroid_runtime.so"
("/system/lib/libandroid_runtime.so") needed or dlopened by
"/data/app/com.popular-app.android-2/lib/arm/libapplib.so" is not accessible
for the namespace "classloader-namespace" - the access is temporarily granted
as a workaround for http://b/26394120

Estas advertencias de logcat indican qué biblioteca está intentando acceder a un API de plataforma privada, pero no hará que falle la app. Si la aplicación tiene como objetivo el nivel de API 24 o uno superior; sin embargo, logcat genera lo siguiente: tiempo de ejecución y tu app podría fallar:

java.lang.UnsatisfiedLinkError: dlopen failed: library "libcutils.so"
("/system/lib/libcutils.so") needed or dlopened by
"/system/lib/libnativeloader.so" is not accessible for the namespace
"classloader-namespace"
  at java.lang.Runtime.loadLibrary0(Runtime.java:977)
  at java.lang.System.loadLibrary(System.java:1602)

También es posible que veas estos resultados de logcat si tu app usa bibliotecas de terceros. que se vinculan dinámicamente a APIs de plataformas privadas. La herramienta readelf de la Android 7.0DK te permite generar una lista de todas las bibliotecas compartidas bibliotecas de un archivo .so determinado mediante la ejecución del siguiente comando:

aarch64-linux-android-readelf -dW libMyLibrary.so

Actualiza tu app

Estos son algunos pasos que puedes seguir para corregir estos tipos de errores y hacer que Asegúrate de que tu app no falle en futuras actualizaciones de la plataforma:

• Si tu app usa bibliotecas de plataformas privadas, debes actualizarla para incluir su propia copia de esas bibliotecas o usar las APIs públicas del NDK.
• Si tu app usa una biblioteca de terceros que accede a símbolos privados, comunícate con que el autor de la biblioteca la actualice.
• Asegúrate de incluir todas las bibliotecas que no pertenezcan al NDK en tu APK.
• Usa funciones JNI estándar en lugar de getJavaVM y getJNIEnv de libandroid_runtime.so:

  AndroidRuntime::getJavaVM -> GetJavaVM from <jni.h>
  AndroidRuntime::getJNIEnv -> JavaVM::GetEnv or
  JavaVM::AttachCurrentThread from <jni.h>.
  

• Usa __system_property_get en lugar del property_get privado. símbolo de libcutils.so. Para hacerlo, usa __system_property_get. que incluye lo siguiente:

  #include <sys/system_properties.h>
  

  Nota: La disponibilidad y el contenido de las propiedades del sistema son los siguientes: no se probó con el CTS. Una mejor solución sería evitar usar estas propiedades por completo.

• Usa una versión local del símbolo SSL_ctrl del libcrypto.so. Por ejemplo, debes vincular estáticamente libcyrpto.a en tu archivo .so o incluir una versión de libcrypto.so vinculada de forma dinámica de BoringSSL/OpenSSL y empaquetarla en el APK.

Android for Work

Android 7.0 contiene cambios para apps orientadas a Android for Work, que incluyen cambios en la instalación de certificados, restablecimiento de contraseñas, usuarios administración de identidades y acceso a identificadores de dispositivos. Si estás creando apps para Android for Work, debes revisar y modificar estos cambios tu app según corresponda.

• Debes instalar un instalador de certificados delegados para que se pueda configurar el DPC que la modifica. En el caso de las apps de propietarios de perfiles y de dispositivos orientadas a Android 7.0 (nivel de API 24), deberías instalar el instalador del certificado delegado antes que la política de dispositivo llamadas al controlador (DPC) DevicePolicyManager.setCertInstallerPackage() Si el instalador aún no está instalado, el sistema arroja un IllegalArgumentException
• Las restricciones de restablecimiento de contraseñas para administradores de dispositivos ahora se aplican al perfil propietarios. Los administradores del dispositivo ya no pueden usar DevicePolicyManager.resetPassword() para borrar contraseñas o cambiar con los que ya están establecidos. Los administradores de dispositivos aún pueden establecer una contraseña, pero solo cuando el dispositivo no tiene contraseña, PIN ni patrón.
• Los propietarios de dispositivos y perfiles pueden administrar cuentas incluso si hay restricciones automático. Los propietarios de dispositivos y perfiles pueden llamar a las APIs de Account Management incluso si hay restricciones para usuarios de DISALLOW_MODIFY_ACCOUNTS.
• Los propietarios de dispositivos pueden administrar usuarios secundarios de manera más sencilla. Cuando un dispositivo está que se ejecuta en el modo de propietario del dispositivo, la restricción DISALLOW_ADD_USER se configura automáticamente. Esto evita que los usuarios creen cuentas usuarios. Además, CreateUser() y Los métodos createAndInitializeUser() dejaron de estar disponibles. el nuevo El método DevicePolicyManager.createAndManageUser() los reemplaza.
• Los propietarios de dispositivos pueden acceder a identificadores de dispositivos. Los propietarios de dispositivos pueden acceder a la dirección MAC de Wi-Fi de un dispositivo, con DevicePolicyManager.getWifiMacAddress() Si la conexión Wi-Fi nunca ha en el dispositivo, este método muestra un valor de null.
• La configuración Work Mode controla el acceso a las apps de trabajo. Cuando el modo de trabajo está desactivado, l launcher del sistema indica que las aplicaciones de trabajo no están disponibles atenuándolas. Habilitando el modo de trabajo restablece el comportamiento normal.
• Cuando se instala un archivo de PKCS #12 que contiene una cadena de certificados de cliente y la clave privada correspondiente de la IU de Configuración, el certificado de la AC en la ya no se instala en el almacenamiento de credenciales de confianza. Esto No afecta el resultado de KeyChain.getCertificateChain() cuando las apps intentan recuperar el cliente. de la cadena de certificados más adelante. Se debe instalar el certificado de la AC si es necesario al almacenamiento de credenciales de confianza a través de la IU de configuración por separado, con un Formato de codificación DER con una extensión de archivo .crt o .cer.
• A partir de Android 7.0, la inscripción con huellas digitales y el almacenamiento se administran por usuario. Si el Cliente de política de dispositivo (DPC) del propietario de un perfil se orienta al nivel de API 23 (o versiones anteriores) en un dispositivo con Android 7.0 (nivel de API 24), el usuario es es posible configurar una huella dactilar en el dispositivo, pero las aplicaciones de trabajo Acceder a la huella digital del dispositivo. Cuando el DPC se orienta al nivel de API 24 o superior, el usuario puede establecer huella dactilar específicamente para el perfil de trabajo en Configuración > Seguridad > Seguridad del perfil de trabajo
• El nuevo estado de encriptación ENCRYPTION_STATUS_ACTIVE_PER_USER es devuelta por DevicePolicyManager.getStorageEncryptionStatus() a indican que la encriptación está activa y que la clave está vinculada a la usuario. El nuevo estado solo se muestra si el DPC se orienta al nivel de API 24 y a niveles superiores. Para las apps orientadas a niveles de API anteriores, ENCRYPTION_STATUS_ACTIVE si la clave de encriptación es específica del usuario o perfil.
• En Android 7.0, varios métodos que normalmente afectarían la totalidad El dispositivo se comporta de manera diferente si este tiene un perfil de trabajo instalado con una desafío de trabajo separado. En lugar de afectar a todo el dispositivo, estas se aplican solo al perfil de trabajo. (La lista completa de dichos métodos se encuentra en la documentación de DevicePolicyManager.getParentProfileInstance()). Por ejemplo: DevicePolicyManager.lockNow() bloquea solo el perfil de trabajo, en lugar de bloqueando todo el dispositivo. Para cada uno de estos métodos, puedes obtener comportamiento llamando al método en la instancia superior de la DevicePolicyManager; puedes obtener este padre llamando a DevicePolicyManager.getParentProfileInstance(). Por ejemplo, si llamas el lockNow() de la instancia superior , se bloqueará todo el dispositivo.

Retención de anotaciones

Android 7.0 soluciona un error por el cual se ignoraba la visibilidad de las anotaciones. Este problema permitió que el tiempo de ejecución accediera a anotaciones que no debían que no puedas. Entre estas anotaciones, se incluyen las siguientes:

• VISIBILITY_BUILD: Se diseñó para ser visible solo en el tiempo de compilación.
• VISIBILITY_SYSTEM: destinada a ser visible en el tiempo de ejecución, pero solo para el en el sistema subyacente.

Si tu aplicación se basa en este comportamiento, agrega una política de retención a las anotaciones que deben estar disponibles en el tiempo de ejecución. Para ello, usa @Retention(RetentionPolicy.RUNTIME).

Cambios en la configuración predeterminada de TLS/SSL

En Android 7.0, se realizan los siguientes cambios en la configuración predeterminada de TLS/SSL que usan las apps para HTTPS y otro tráfico TLS/SSL:

• Los conjuntos de algoritmos de cifrado RC4 ahora están inhabilitados.
• Ahora están habilitados los conjuntos de algoritmos de cifrado CHACHA20-POLY1305.

Si RC4 está inhabilitado de forma predeterminada, es posible que se produzcan fallas en HTTPS, TLS o SSL cuando el servidor no negocia conjuntos modernos de cifrado. La solución preferida es mejorar la configuración del servidor para habilitar conjuntos de algoritmos de cifrado y protocolos de cifrado más modernos. Idealmente, TLSv1.2 y AES-GCM y los conjuntos de algoritmos de cifrado de confidencialidad directa (ECDHE) habilitar y preferir.

Una alternativa es modificar la app para que use un SSLSocketFactory personalizado para comunicarse con el servidor. El fábrica debería estar diseñada para crear SSLSocket instancias que tienen algunos de los conjuntos de algoritmos de cifrado requeridos por el servidor además de los conjuntos de algoritmos de cifrado predeterminados.

Nota: Estos cambios no se relacionan con WebView.

Apps orientadas a Android 7.0

Estos cambios de comportamiento se aplican exclusivamente a las apps para las que se segmentan Android 7.0 (nivel de API 24) o una versión posterior Apps que se compilan con Android 7.0, o configura targetSdkVersion en Android 7.0 o una versión posterior sus apps para admitir estos comportamientos correctamente, cuando corresponda.

Cambios de serialización

Android 7.0 (nivel de API 24) corrigió un error en el cálculo de la configuración serialVersionUID no coincide con la especificación.

Clases que implementan Serializable y no especifiques un campo serialVersionUID explícito, noten un cambio en su serialVersionUID predeterminado, lo que generaría una excepción cuando se intenten deserializar instancias de la clase que se serializados en una versión anterior o serializados por una aplicación orientada a una versión anterior versión. El mensaje de error se verá de la siguiente manera:

local class incompatible: stream classdesc serialVersionUID = 1234, local class serialVersionUID = 4567

Para solucionar estos problemas, es necesario agregar un campo serialVersionUID a cualquier clase afectada con el valor de stream classdesc serialVersionUID del mensaje de error, p.ej., 1234 in este caso. El cambio cumple con todas las recomendaciones de prácticas recomendadas para Escribir código de serialización, y funcionará en todas las versiones de Android.

El error específico que se corrigió estaba relacionado con la presencia de imágenes estáticas métodos de inicialización, p.ej., <clinit>. Según el específica la presencia o ausencia de un método de inicializador estático en la afectará el valor de serialVersionUID predeterminado que se calcula para esa clase. Antes de la corrección de errores, el cálculo también verificaría la superclase para ver si hay un un inicializador estático si una clase no tenía uno.

Para aclarar, este cambio no afecta a las apps orientadas a los niveles de API 23 o inferior, clases que tienen un campo o clases serialVersionUID que tienen un método de inicialización estático.

Otros aspectos importantes

• Cuando una app se ejecuta en Android 7.0, pero tiene como objetivo un nivel de API inferior, y el usuario cambia el tamaño de la pantalla, se cierra el proceso de la app. La app debe ser capaz de manejar correctamente esta situación. De lo contrario, fallará. cuando el usuario la restaura desde Recientes.

  Debes probar tu app para asegurarte de que para que este comportamiento no ocurra. Puedes hacerlo causando una falla idéntica. cuando se cierra la app de forma manual a través de DDMS.

  Las apps orientadas a Android 7.0 (nivel de API 24) y versiones posteriores no se desaparezca por cambios en la densidad; pero aún pueden responder mal a cambios de configuración.

• En Android 7.0, las apps deben tener capacidad para manejar correctamente los cambios de configuración. y no debería fallar en inicios posteriores. Puedes verificar el comportamiento de la app cambiando el tamaño de la fuente (Configuración > Pantalla > Tamaño de fuente) y, luego, restablecer la aplicación desde Recientes.
• Debido a un error en versiones anteriores de Android, el sistema no indicaba la escritura a un socket TCP en el subproceso principal como una violación del modo estricto. Android 7.0 resuelve este error. Las apps que demuestran este comportamiento ahora arrojan una android.os.NetworkOnMainThreadException. Generalmente, no se recomienda realizar operaciones de red en el subproceso principal, ya que estas operaciones suelen tener una latencia alta que provoca errores de ANR y bloqueos.
• La familia de métodos Debug.startMethodTracing() ahora es la configuración predeterminada. almacenar los resultados en el directorio específico del paquete en el almacenamiento compartido en lugar de en el nivel superior, de la tarjeta SD. Esto significa que las apps ya no necesitan solicitar el permiso WRITE_EXTERNAL_STORAGE para usar estas APIs.
• Muchas APIs de la plataforma ya comenzaron a verificar si se envían cargas útiles grandes en las transacciones de Binder, y la el sistema ahora vuelve a arrojar TransactionTooLargeExceptions como RuntimeExceptions, en lugar de registrarlas o suprimirlas en silencio. Uno ejemplo común es almacenar demasiados datos en Activity.onSaveInstanceState(), lo que provoca que ActivityThread.StopInfo arroje una RuntimeException cuando tu app se oriente a Android 7.0.
• Si una app publica tareas de Runnable en una View View no está conectado a una ventana, el sistema pone en cola la tarea Runnable con el View; la tarea Runnable no se ejecuta hasta que Se adjuntó View a una ventana. Este comportamiento corrige los siguientes errores:
  • Si una app publicó en un View desde una conversación que no sea la prevista de la ventana, es posible que Runnable se ejecute en el subproceso incorrecto.
  • Si la tarea Runnable se publicó desde una conversación que no sea un subproceso de generador de bucles, la app podría exponer la tarea Runnable.
• Si una app tiene Android 7.0 con DELETE_PACKAGES permiso intenta borrar un paquete, pero otra app lo había instalado el sistema requiere la confirmación del usuario. En esta situación, las apps deben esperar STATUS_PENDING_USER_ACTION como el estado de retorno cuando invocan PackageInstaller.uninstall()
• El proveedor de JCA llamado Crypto dejó de estar disponible porque su único SHA1PRNG, es criptográficamente débil. Las apps ya no pueden usar SHA1PRNG para derivar (de forma no segura) claves debido a que este proveedor ya no está disponibles. Para obtener más información, consulta el blog publicación Seguridad "Crypto" proveedor obsoleto en Android N