Además de nuevas funciones y capacidades, Android 7.0 incorpora varios cambios en el comportamiento del sistema y de la API. En este documento, se destacan algunos de los cambios claves que debes comprender y contemplar en tus apps.
Si publicaste anteriormente una app para Android, ten en cuenta que tu app podría verse afectada por estos cambios en la plataforma.
Batería y memoria
En Android 7.0 se incluyen cambios en los comportamientos del sistema para mejorar la duración de la batería de los dispositivos y reducir el uso de la memoria RAM. Estos cambios pueden afectar el acceso de tu app a recursos del sistema, y también la manera en que tu app interactúa con otras mediante determinadas intents implícitas.
Descanso
La función Descanso, presentada en Android 6.0 (nivel de API 23), prolonga la duración de la batería aplazando actividades de CPU y red cuando un usuario deja un dispositivo desenchufado, quieto y con la pantalla apagada. En Android 7.0 se ofrecen más mejoras para Descanso mediante la aplicación de un subconjunto de restricciones de CPU y red mientras el dispositivo se encuentra desenchufado y con la pantalla apagada, aunque no necesariamente quieto; por ejemplo, al ir dentro del bolsillo de un usuario en movimiento.

Figura 1: Ilustración del modo en que 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 permanece apagada durante un tiempo determinado, se activa en este el modo Descanso y se aplica el primer subconjunto de restricciones: Se desactiva el acceso de las apps a la red y se aplazan tareas y sincronizaciones. Si el dispositivo permanece quieto durante un tiempo determinado tras activarse el modo Descanso, el sistema aplica el resto de las restricciones del modo a PowerManager.WakeLock
, alarmas de AlarmManager
, GPS y análisis de Wi-Fi. Independientemente de que se apliquen algunas restricciones del modo Descanso o todas ellas, el sistema activa el dispositivo durante períodos de mantenimiento breves en los cuales las aplicaciones tienen acceso a la red y pueden ejecutar sincronizaciones o procesos aplazados.

Figura 2: Ilustración del modo en que 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 desactiva el modo Descanso y se quitan estas restricciones de procesamiento. El comportamiento adicional no tiene efecto sobre las recomendaciones ni las prácticas recomendadas para adaptar tu app a la versión anterior de Descanso, presentada en Android 6.0 (nivel de API 23), según lo descrito en Optimización para Descanso y App Standby. De todos modos, debes seguir las recomendaciones; por ejemplo, la de usar Google Cloud Messaging (GCM) para enviar y recibir mensajes, y la de planificar actualizaciones para adaptar el comportamiento adicional de Descanso.
Project Svelte: optimizaciones en segundo plano
En Android 7.0, se quitan tres transmisiones implícitas para ayudar a optimizar el uso de la memoria y el consumo de energía. Este cambio es necesario porque las transmisiones implícitas a menudo inician apps registradas para recibirlas en segundo plano. La eliminación de estas transmisiones puede mejorar sustancialmente el rendimiento del dispositivo y la experiencia del usuario.
Los dispositivos móviles están sujetos a cambios de conectividad frecuentes; por ejemplo, al realizar cambios de datos Wi-Fi a móviles. Actualmente, las apps pueden realizar controles en busca de cambios en la conectividad registrando un receptor para la transmisión implícita CONNECTIVITY_ACTION
en su manifiesto. Debido a que muchas apps se registran para recibir esta transmisión, un único cambio de red puede hacer que todas se activen y procesen la transmisión a la vez.
Asimismo, en versiones anteriores de Android, las apps podían registrarse para recibir las 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 Cámara, estas apps se activan para procesar la transmisión.
Para corregir estos problemas, en Android 7.0 se aplican las siguientes optimizaciones:
- Las apps orientadas a Android 7.0 no reciben transmisiones
CONNECTIVITY_ACTION
, aun cuando contengan entradas de manifiesto que les permitan solicitar notificaciones de estos eventos. Las apps que se ejecutan aún pueden recibirCONNECTIVITY_CHANGE
en su subproceso principal si solicitan una notificación conBroadcastReceiver
. - Las apps no pueden enviar ni recibir transmisiones
ACTION_NEW_PICTURE
oACTION_NEW_VIDEO
. Esta optimización afecta a todas las apps, no solo a aquellas orientadas a Android 7.0.
Si la app usa alguna de estas intents, debes quitar las dependencias en ellas lo antes posible a fin de 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 JobScheduler
API proporciona un mecanismo sólido para programar operaciones de red cuando se cumplen las condiciones especificadas, como una conexión a una red de uso no medido. Puedes, incluso, usar JobScheduler
para responder a cambios en proveedores de contenido.
Para obtener más información sobre optimizaciones en segundo plano en Android N y la manera de adaptar tu app, consulta Optimizaciones en segundo plano.
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 tiene acceso restringido (0700
). Esta configuración evita la fuga de metadatos de archivos privados, como su tamaño o existencia. Este cambio en los permisos tiene varios efectos secundarios:
-
Los propietarios ya no pueden reducir los permisos de archivo de los archivos privados, y un intento de hacerlo usando
MODE_WORLD_READABLE
oMODE_WORLD_WRITEABLE
activará unaSecurityException
.Nota: A partir de ahora, esta restricción no se aplicará plenamente. Las apps pueden seguir modificando los permisos para sus directorios privados con las API nativas o la
File
API. Sin embargo, desaconsejamos totalmente reducir los permisos para el directorio privado. -
La transferencia de URI
file://
fuera del dominio del paquete puede dar al receptor una ruta de acceso inaccesible. Por lo tanto, los intentos de pasar un URIfile://
activarán unaFileUriExposedException
. La manera recomendada de compartir el contenido de un archivo privado consiste en usar elFileProvider
. -
El
DownloadManager
ya no puede compartir archivos almacenados de manera privada por nombre de archivo. Las aplicaciones heredadas pueden terminar con una ruta de acceso inaccesible cuando acceden aCOLUMN_LOCAL_FILENAME
. Las apps orientadas a Android 7.0 o versiones posteriores activan unaSecurityException
cuando se intenta acceder aCOLUMN_LOCAL_FILENAME
. Las apps heredadas que establecen la ubicación de descarga en una ubicación pública usandoDownloadManager.Request.setDestinationInExternalFilesDir()
oDownloadManager.Request.setDestinationInExternalPublicDir()
siguen teniendo acceso a la ruta de acceso enCOLUMN_LOCAL_FILENAME
; sin embargo, se desaconseja mucho seguir este método. El método preferido para acceder a un archivo expuesto por elDownloadManager
es usarContentResolver.openFileDescriptor()
.
Intercambio de archivos entre apps
En las apps orientadas a Android 7.0, el framework de Android aplica la política de la StrictMode
API que prohíbe exponer URI file://
fuera de tu app. Si una intent con un URI de archivo sale de tu app, esta última experimenta una falla con una excepción FileUriExposedException
.
Para compartir archivos entre apps, debes enviar un URI content://
y otorgar un permiso de acceso temporal en el URI. La forma más sencilla de otorgar este permiso es a través de la clase FileProvider
. Para obtener más información sobre permisos e intercambio de archivos, consulta Intercambio de archivos.
Mejoras de accesibilidad
En Android 7.0, se incluyen cambios destinados a mejorar la usabilidad de la plataforma para usuarios con defectos o discapacidades visuales. Estos cambios generalmente no deben exigir modificaciones en el código de tu app. Sin embargo, debes revisar estas funciones y probarlas con tu app para evaluar el posible impacto en la experiencia del usuario.
Zoom de la pantalla
Android 7.0 permite a los usuarios configurar Display size, el ajuste que expande o contrae todos los elementos de la pantalla, lo cual mejora la accesibilidad al dispositivo para usuarios con poca visión. Estos no podrán superar el valor de zoom mínimo de sw320dp para el ancho de pantalla, que es el ancho de un Nexus 4, un teléfono común de tamaño intermedio.


Figura 3: En la pantalla de la derecha, se muestra el efecto que tiene aumentar Display size para un dispositivo con una imagen de sistema de Android 7.0.
Al cambiar la densidad del dispositivo, el sistema notifica a las apps en ejecución de las siguientes maneras:
- Si una app se orienta hacia el nivel de API 23 o uno inferior, el sistema automáticamente finaliza todos los procesos en segundo plano. Esto significa que, si un usuario hace a un lado dicha app para abrir la pantalla Settings y cambiar la configuración de Display size, el sistema finalizará la app tal como lo haría en una situación de bajos recursos de memoria. Si en la app hay procesos en primer plano, el sistema notifica a estos procesos el cambio en la configuración como se indica en Manejo de cambios en tiempo de ejecución, así como lo haría si cambiara la orientación del dispositivo.
- Si una app se orienta hacia Android 7.0, se notifica a todos los procesos (en primer y segundo plano) el cambio en la configuración, como se indica en Manejo de cambios en tiempo de ejecución.
En la mayoría de las apps no se necesitan cambios para admitir esta función si en ellas se siguen las prácticas recomendadas de Android. Verificaciones específicas que deben realizarse:
- Prueba tu app en un dispositivo con ancho de pantalla
sw320dp
y asegúrate de que funcione bien. - Cuando se modifique la configuración del dispositivo, actualiza la información almacenada en caché que dependa de la densidad, como los mapas de bits o recursos almacenados en caché que se carguen desde la red. Busca cambios en la configuración cuando se reanude la actividad de la app, después de la pausa.
Nota: Si almacenaste en caché datos que dependen de la configuración, te convendrá incluir metadatos relacionados, como el tamaño de pantalla correspondiente o la densidad de píxeles para dichos datos. Guardar estos metadatos te permite decidir si necesitas actualizar los datos almacenados en caché después de un cambio en la configuración.
- Evita especificar dimensiones con unidades px, ya que no responden a la densidad de pantalla. En lugar de ello, recurre a unidades de píxeles (
dp
) independientes de la densidad.
Vision Settings en el asistente de configuración
Vision Settings se incluye en la pantalla de bienvenida de Android 7.0, en la cual los usuarios pueden configurar los siguientes ajustes de accesibilidad para un nuevo dispositivo: Magnification gesture, Font size, Display size y TalkBack. Este cambio aumenta la visibilidad de errores relacionados con diferentes ajustes de pantalla. Para evaluar el impacto de esta función, debes probar tus apps con estos ajustes habilitados. Puedes encontrarlos en Settings > Accessibility.
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 con bibliotecas que no pertenezcan al NDK, lo cual puede hacer que tu app falle. El objetivo de este cambio en el comportamiento es crear una experiencia de app coherente en diferentes actualizaciones de plataforma y dispositivos. Si bien es posible que tu código no se vincule con bibliotecas privadas, es posible que una biblioteca estática de terceros de tu app sí lo haga. Por lo tanto, todos los desarrolladores deben garantizar que sus apps no fallen en dispositivos con Android 7.0. Si tu app usa código nativo, solo debes usar NDK API públicas.
Hay tres formas en las cuales tu app puede intentar acceder a API de plataformas privadas:
- Tu app accede directamente a bibliotecas de plataformas privadas. Debes actualizar tu app para incluir su propia copia de esas bibliotecas o usar las NDK API públicas.
- Tu app usa una biblioteca de terceros que accede a bibliotecas de plataformas privadas. Aun cuando estés seguro de que tu app no acceda a bibliotecas privadas de manera directa, deberás hacer pruebas en tu app.
- Tu app hace referencia a una biblioteca que no está incluida en su APK. Por ejemplo, esto podría suceder si intentaras usar tu propia copia de OpenSSL y olvidaras integrarla al APK de tu app. La app puede ejecutarse normalmente en versiones de la plataforma Android que incluyan
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 esto, asegúrate de vincular todas las bibliotecas que no pertenezcan al NDK con tu APK.
Las apps no deben usar bibliotecas nativas que no estén incluidas en el NDK porque pueden cambiar o desaparecer entre diferentes versiones de Android. El cambio de OpenSSL a BoringSSL es un ejemplo de modificaciones como esta. A su vez, los diferentes dispositivos pueden ofrecer distintos niveles de compatibilidad, debido a que no existen requisitos de compatibilidad para bibliotecas de plataformas no incluidas en el NDK.
A fin de reducir el impacto de esta restricción sobre las apps lanzadas actualmente, identificamos un conjunto de bibliotecas que se usa mucho (por ejemplo, libandroid_runtime.so
, libcutils.so
, libcrypto.so
y libssl.so
) y al cual se puede acceder temporalmente en Android N para las apps orientadas al nivel de API 23 o a niveles inferiores. Si tu app carga una de estas bibliotecas, logcat genera una advertencia y aparece una notificación en el dispositivo objetivo. Si ves estas advertencias, debes actualizar tu app para incluir su propia copia de esas bibliotecas o usar solo las NDK API públicas. Las versiones futuras de la plataforma Android pueden restringir el uso de bibliotecas privadas y hacer que tu app falle.
Todas las apps generan un error en tiempo de ejecución cuando llaman a una API a la que no se puede acceder de forma pública ni temporal. Como resultado, System.loadLibrary
y dlopen(3)
muestran un valor NULL
, y pueden hacer que tu app falle. Debes revisar el código de tu app para quitar el uso de API de plataformas privadas y probar por completo tus apps con un dispositivo de vista previa o emulador. Si no estás seguro acerca de si tu app usa bibliotecas privadas, puedes revisar logcat para identificar el error en tiempo de ejecución.
En la siguiente tabla, se describe el comportamiento que deberías esperar de una app según su uso de bibliotecas nativas privadas y su nivel de API de destino (android:targetSdkVersion
).
Bibliotecas | Nivel de API de destino | Acceso en tiempo de ejecución por medio de un vinculador dinámico | Comportamiento de N Developer Preview | Comportamiento de la versión N final | Comportamiento de la plataforma Android futura |
---|---|---|---|---|---|
Pública incluida en el NDK | Cualquiera | Accesible | Funciona como se espera. | Funciona como se espera. | Funciona como se espera. |
Privada (bibliotecas privadas temporalmente disponibles) | 23 o inferior | Temporalmente disponible | Funciona como se espera, pero aparecen una advertencia de logcat y un mensaje en el dispositivo de destino. | 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 | Error en tiempo de ejecución |
Privada (otra) | Cualquiera | Restringido | Error en tiempo de ejecución | Error en tiempo de ejecución | Error en tiempo de ejecución |
Verifica si tu app usa bibliotecas privadas
Para ayudarte a identificar problemas al cargar bibliotecas privadas, logcat puede generar una advertencia o un error en tiempo de ejecución. Por ejemplo, si tu app se orienta al nivel de API 23 o a niveles inferiores e intenta acceder a una biblioteca privada en un dispositivo con Android 7.0, es posible que recibas 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 te indican la biblioteca que intenta acceder a una API de plataforma privada, pero no harán que falle tu app. Si la app se orienta al nivel de API 24 o a niveles superiores, sin embargo, logcat genera el siguiente error en tiempo de ejecución y tu app puede 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 visualices estos resultados de logcat si tu app usa bibliotecas de terceros que dinámicamente se vinculan a API de plataformas privadas. Ejecutando el comando que se muestra a continuación, la herramienta readelf de Android 7.0DK te permite generar una lista de todas las bibliotecas compartidas de un archivo .so
determinado que se vinculan dinámicamente:
aarch64-linux-android-readelf -dW libMyLibrary.so
Actualiza tu app
Aquí te presentamos algunos pasos que puedes seguir para solucionar estos tipos de errores y asegurarte 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 NDK API públicas.
- Si tu app usa una biblioteca de terceros que accede a símbolos privados, comunícate con el autor de la biblioteca para actualizarla.
- Asegúrate de incluir todas las bibliotecas que no pertenezcan al NDK en tu APK.
- Usa funciones JNI estándares 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 del símbolo privadoproperty_get
delibcutils.so
. Para hacerlo, usa__system_property_get
con el siguiente elemento:#include <sys/system_properties.h>
Nota: La disponibilidad y el contenido de las propiedades del sistema no se prueban mediante CTS. Una mejor solución sería evitar usar estas propiedades completamente.
- Usa una versión local del símbolo
SSL_ctrl
delibcrypto.so
. Por ejemplo, deberías vincular estáticamentelibcyrpto.a
en tu archivo.so
, o incluir una versión delibcrypto.so
de BoringSSL/OpenSSL vinculada dinámicamente e incluirla en tu APK.
Android for Work
Android 7.0 contiene cambios para apps orientadas a Android for Work, entre los que se incluyen modificaciones en la instalación de certificados, el restablecimiento de contraseñas, la gestión de usuarios secundarios y el acceso a identificadores de dispositivos. Si compilas apps para entornos de Android for Work, debes estudiar estos cambios y modificar tu app según corresponda.
- Debes usar un instalador de certificados delegados para que el DPC pueda configurarlo. Para apps de propietarios de perfiles y de dispositivos orientadas al SDK de Android N, debes usar el instalador de certificados delegados a fin de que el controlador de política del dispositivo (DPC) llame a
DevicePolicyManager.setCertInstallerPackage()
. Si el instalador no está instalado, el sistema emite unaIllegalArgumentException
. - Las restricciones de restablecimiento de contraseñas para administradores de dispositivos ahora se aplican a los propietarios de perfiles. Los administradores de dispositivos ya no pueden usar
DevicePolicyManager.resetPassword()
para borrar contraseñas ni modificar las que ya están establecidas. 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 aun cuando haya restricciones. Tienen la posibilidad de llamar a las Account Management API incluso al haber restricciones
DISALLOW_MODIFY_ACCOUNTS
para el usuario. - Los propietarios de dispositivos pueden administrar usuarios secundarios de manera más sencilla. Cuando un dispositivo funciona en el modo de propietario de dispositivo, automáticamente se establece la restricción
DISALLOW_ADD_USER
. Esto evita que los usuarios creen usuarios secundarios no administrados. A su vez, los métodosCreateUser()
ycreateAndInitializeUser()
ya no están disponibles; los reemplaza el nuevo métodoDevicePolicyManager.createAndManageUser()
. - Los propietarios de dispositivos pueden acceder a identificadores de dispositivos. Tienen la posibilidad de acceder a la dirección MAC de Wi-Fi de un dispositivo a través de
DevicePolicyManagewr.getWifiMacAddress()
. Si nunca se habilitó la función Wi-Fi en el dispositivo, este método devuelve un valornull
. - La configuración Work Mode controla el acceso a las apps de trabajo. Cuando este ajuste se desactiva, el lanzador del sistema indica que las apps de trabajo no están disponibles atenuándolas. Para restaurar el comportamiento normal, habilita el modo de trabajo nuevamente.
- Cuando se instala un archivo PKCS #12 que contiene una cadena de certificados de cliente y la clave privada correspondiente de la IU de configuración, el certificado de CA de la cadena ya no se instala en el almacenamiento de credenciales confiable. Esto no afecta el resultado de
KeyChain.getCertificateChain()
cuando las apps intentan recuperar la cadena de certificados de cliente más tarde. Si es necesario, el certificado de CA debe instalarse en el almacenamiento de credenciales confiable mediante la IU de configuración por separado, con un formato de codificación DER y una extensión de archivo .crt o .cer. - A partir de Android 7.0, el almacenamiento y la inscripción con huellas digitales se administran por usuario. Si el cliente de política de dispositivo (DPC) de un propietario de perfil se orienta a una versión anterior a Android N en un dispositivo con Android N, el usuario puede configurar la huella dactilar en el dispositivo, pero las aplicaciones de trabajo no pueden acceder a dicha huella. Cuando el DPC se orienta a Android N y versiones posteriores, el usuario puede configurar la huella dactilar específicamente para el perfil de trabajo dirigiéndose a Settings > Security > Work profile security.
- Un nuevo estado de encriptación
ENCRYPTION_STATUS_ACTIVE_PER_USER
es devuelto porDevicePolicyManager.getStorageEncryptionStatus()
, para indicar que la encriptación está activa y la clave de encriptación está vinculada al usuario. El nuevo estado solo se muestra si el DPC se orienta al nivel de API 24 y a niveles superiores. En el caso de las apps que se orientan a niveles de API anteriores, se muestraENCRYPTION_STATUS_ACTIVE
, incluso si la clave de encriptación es específica para el usuario o el perfil. - En Android 7.0, varios métodos que normalmente afectarían al dispositivo en su totalidad se comportan de manera diferente si este tiene un perfil de trabajo instalado con una comprobación de trabajo separada. En lugar de tener efecto sobre todo el dispositivo, estos métodos se aplican únicamente al perfil de trabajo. (La lista completa de dichos métodos se encuentra en la documentación sobre
DevicePolicyManager.getParentProfileInstance()
). Por ejemplo,DevicePolicyManager.lockNow()
bloquea solo el perfil de trabajo en lugar de todo el dispositivo. Para cada uno de estos métodos, puedes obtener el comportamiento antiguo llamando al método de la instancia primaria deDevicePolicyManager
; para acceder a esta instancia, llama aDevicePolicyManager.getParentProfileInstance()
. Por ejemplo, si llamas al métodolockNow()
de la instancia principal, se bloquea todo el dispositivo.
Para obtener más información sobre los cambios de Android for Work en Android 7.0, consulta Actualizaciones de Android for Work.
Retención de anotaciones
Android 7.0 soluciona un error por el cual se ignoraba la visibilidad de las anotaciones. Este problema permitía que el tiempo de ejecución accediera a notificaciones a las que no debía tener acceso. Entre estas anotaciones, se incluyen las siguientes:
VISIBILITY_BUILD
: destinada a ser visible solo en el momento de compilación.VISIBILITY_SYSTEM
: destinada a ser visible en el tiempo de ejecución, pero únicamente al sistema subyacente.
Si tu app se basa en este comportamiento, agrega una política de retención para las anotaciones que deben estar disponibles en el tiempo de ejecución. Para ello, usa @Retention(RetentionPolicy.RUNTIME)
.
Otros aspectos importantes
- Cuando una app funcione en Android 7.0, pero esté orientada a un nivel de API inferior y el usuario modifique el tamaño de pantalla, el proceso de la app finalizará. La app debe tener capacidad para manejar correctamente esta situación. De lo contrario, se bloqueará cuando el usuario la restaure desde Recents.
Debes probar tu app para garantizar que este comportamiento no tenga lugar. Puedes hacerlo generando un bloqueo idéntico cuando finalices manualmente el proceso de la app mediante DDMS.
Las apps orientadas a Android N y versiones posteriores no finalizarán automáticamente por cambios en la densidad; sin embargo, es posible que respondan de manera deficiente a los cambios en la configuración.
- En Android 7.0, las apps deben tener capacidad para manejar correctamente los cambios de configuración y no deben bloquearse durante inicios posteriores. Puedes verificar el comportamiento de las apps modificando el tamaño de la fuente (Setting > Display > Font size) y restaurándolas desde Recents.
-
Debido a un error en versiones anteriores de Android, el sistema no indicaba la escritura a un socket del TCP en el subproceso principal como una violación del modo strict. Android 7.0 resuelve este error. Las apps que demuestran este comportamiento ahora arrojan una
android.os.NetworkOnMainThreadException
. Generalmente, realizar operaciones de red en el subproceso principal no se recomienda, ya que estas operaciones suelen tener una latencia alta de cola que genera mensajes ANR y bloqueos. -
De manera predeterminada, la familia de métodos
Debug.startMethodTracing()
ahora almacena los resultados en el directorio específico del paquete en el almacenamiento compartido, en lugar de hacerlo en el nivel superior de la tarjeta SD. Esto significa que las apps ya no deben solicitar el permisoWRITE_EXTERNAL_STORAGE
para usar estas API. -
Muchas API de la plataforma han comenzado a realizar verificaciones en busca cargas grandes enviadas a través de transacciones
Binder
. Además, el sistema ahora vuelve a emitirTransactionTooLargeExceptions
comoRuntimeExceptions
, en lugar de registrarlas o suprimirlas silenciosamente. Un ejemplo común contempla el almacenamiento excesivo de datos enActivity.onSaveInstanceState()
. Esto hace queActivityThread.StopInfo
emita unaRuntimeException
cuando tu app se orienta a Android 7.0. -
Si una app publica tareas
Runnable
en unaView
, y laView
no se adjunta a una ventana, el sistema pone en cola la tareaRunnable
con laView
. La tareaRunnable
no se ejecuta hasta que laView
se adjunte a una ventana. Este comportamiento soluciona los siguientes errores:- Si una app realizaba publicaciones en una
View
desde un subproceso que no sea el subproceso de la IU de la ventana prevista, la tareaRunnable
podía ejecutarse en el subproceso incorrecto. - Si la tarea
Runnable
se publicaba desde un subproceso que no fuera un subproceso de looper, la app podía exponer la tareaRunnable
.
- Si una app realizaba publicaciones en una
-
Si una app en Android 7.0 con el permiso
DELETE_PACKAGES
intentaba borrar un paquete instalado por otra, el sistema solicitaba la confirmación del usuario. En esta situación, las apps podrán recibir el estadoSTATUS_PENDING_USER_ACTION
al invocarPackageInstaller.uninstall()
. - El proveedor de JCA llamado Crypto ya no está disponible, ya que su único algoritmo (SHA1PRNG) es débil desde el punto de vista criptográfico. Las apps ya no pueden usar SHA1PRNG para derivar (de forma insegura) claves debido a que este proveedor ya no está disponible. Para obtener más información, consulta la entrada de blog El proveedor de seguridad "Crypto" quedó en desuso en Android N.