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.
![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](https://developer.android.com/static/images/android-7.0/doze-diagram-1.png?authuser=9&hl=es)
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.
![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](https://developer.android.com/static/images/android-7.0/doze-diagram-2.png?authuser=9&hl=es)
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 deCONNECTIVITY_ACTION
si registran suBroadcastReceiver
conContext.registerReceiver()
, y ese contexto sigue siendo válido. - El sistema ya no envía transmisiones
ACTION_NEW_PICTURE
niACTION_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/oMODE_WORLD_WRITEABLE
, activará unSecurityException
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 URIfile://
activa unFileUriExposedException
La forma recomendada de compartir el contenido de un archivo privado usaFileProvider
. -
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 aCOLUMN_LOCAL_FILENAME
. Orientación de aplicaciones Android 7.0 o versiones posteriores activan unaSecurityException
cuando intentando accederCOLUMN_LOCAL_FILENAME
aplicaciones heredadas que establecen la ubicación de descarga en una ubicación pública mediante medianteDownloadManager.Request.setDestinationInExternalFilesDir()
oDownloadManager.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 exponeDownloadManager
usaContentResolver.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.
![Pantalla que muestra el tamaño sin zoom de un dispositivo que ejecuta una imagen del sistema Android 7.0](https://developer.android.com/static/images/android-7.0/screen-zoom-1.png?authuser=9&hl=es)
![Pantalla que muestra el efecto de aumentar el tamaño de visualización de un dispositivo con una imagen del sistema Android 7.0](https://developer.android.com/static/images/android-7.0/screen-zoom-2.png?authuser=9&hl=es)
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
ygetJNIEnv
delibandroid_runtime.so
:AndroidRuntime::getJavaVM -> GetJavaVM from <jni.h> AndroidRuntime::getJNIEnv -> JavaVM::GetEnv or JavaVM::AttachCurrentThread from <jni.h>.
- Usa
__system_property_get
en lugar delproperty_get
privado. símbolo delibcutils.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
dellibcrypto.so
. Por ejemplo, debes vincular estáticamentelibcyrpto.a
en tu archivo.so
o incluir una versión delibcrypto.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 unIllegalArgumentException
- 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étodoscreateAndInitializeUser()
dejaron de estar disponibles. el nuevo El métodoDevicePolicyManager.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 denull
. - 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 porDevicePolicyManager.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 laDevicePolicyManager
; puedes obtener este padre llamando aDevicePolicyManager.getParentProfileInstance()
. Por ejemplo, si llamas ellockNow()
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 permisoWRITE_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 arrojarTransactionTooLargeExceptions
comoRuntimeExceptions
, en lugar de registrarlas o suprimirlas en silencio. Uno ejemplo común es almacenar demasiados datos enActivity.onSaveInstanceState()
, lo que provoca queActivityThread.StopInfo
arroje unaRuntimeException
cuando tu app se oriente a Android 7.0. -
Si una app publica tareas de
Runnable
en unaView
View
no está conectado a una ventana, el sistema pone en cola la tareaRunnable
con elView
; la tareaRunnable
no se ejecuta hasta que Se adjuntóView
a una ventana. Este comportamiento corrige los siguientes errores: -
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 esperarSTATUS_PENDING_USER_ACTION
como el estado de retorno cuando invocanPackageInstaller.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