Android 10 incluye cambios actualizados de comportamiento del sistema que podrían afectar a tu app.
Los cambios que se indican en esta página se aplican exclusivamente a las aplicaciones a las que se les oriente
Nivel de API 29 o superior. Si tu app establece targetSdkVersion en "29" o
debes modificar tu app
para que admita correctamente estos comportamientos
cuando corresponda.
Asegúrate también de revisar la lista de cambios de comportamiento que afectan a todas las apps que se ejecuten en Android 10.
Nota: Además de los cambios que se indican en esta página, Android 10 introduce una gran cantidad de cambios y restricciones basados en la privacidad, incluidas lo siguiente:
- Almacenamiento específico
- Acceso al número de serie del dispositivo USB
- Capacidad de habilitar, inhabilitar y configurar Wi-Fi
- Permisos de ubicación para las APIs de conectividad
Estos cambios, que afectan a las apps orientadas al nivel de API 29 o versiones posteriores, mejoran la privacidad del usuario. Para obtener más información sobre cómo admitir estos cambios, consulta la página Cambios en la privacidad.
Actualizaciones a restricciones de interfaces no SDK
Para garantizar la estabilidad y compatibilidad de las apps, la plataforma comenzó a restringir qué interfaces que no pertenecen al SDK que tu app puede usar en Android 9 (nivel de API 28). Android 10 incluye listas actualizadas de interfaces restringidas que no pertenecen al SDK en función de la colaboración con desarrolladores de Android y las pruebas internas más recientes. Nuestro objetivo es asegurarnos de que las alternativas públicas estén disponibles antes de restringir las interfaces que no pertenecen al SDK.
Si no orientarás tu app a Android 10 (nivel de API 29), algunos de estos cambios podría no afectarte de inmediato. Sin embargo, aunque actualmente puedes usar algunas interfaces que no pertenecen al SDK (según el nivel de API al que esté orientada la app), utilizar cualquier método o campo que no pertenezca al SDK siempre implica un gran riesgo de error para tu app.
Si no sabes con seguridad si tu app usa este tipo de interfaces, puedes probarla para verificarlo. Si tu app depende de interfaces que no pertenecen al SDK, deberías planificar migración a alternativas de SDK. Sin embargo, sabemos que algunas apps tienen casos prácticos válidos para usarlas. Si no encuentras una alternativa a usar una interfaz que no pertenece al SDK para una función de tu app, debes solicitar una nueva API pública
Para obtener más información, consulta Actualizaciones a las restricciones de interfaces que no pertenecen al SDK para Android 10. y consulta Restricciones en interfaces que no pertenecen al SDK.
Memoria compartida
Ashmem cambió el formato de los mapas dalvik en /proc/<pid>/maps que afectan a las apps que analizan directamente el archivo de mapa. Los desarrolladores de aplicaciones deberían probar el formato /proc/<pid>/maps en dispositivos que se ejecutan Android 10 o versiones posteriores, y realiza los análisis correspondientes si la app depende de y otros formatos de mapa de dalvik.
Las apps orientadas a Android 10 no pueden usar ashmem (/dev/ashmem) directamente, sino que deben acceder a la memoria compartida mediante la clase ASharedMemory del NDK.
Además, las apps no pueden enviar IOCTL directos a descriptores de archivos ashmem existentes.
y, en su lugar, debe usar la clase ASharedMemory del NDK o la biblioteca de Java para Android
APIs para crear regiones de memoria compartida. Este cambio incrementa la seguridad y firmeza del trabajo con memoria compartida, lo que mejora el rendimiento y la seguridad de Android en general.
Se quitó el permiso de ejecución para el directorio principal de la app
La ejecución de archivos desde el directorio principal de la app que admite escritura es una Incumplimiento de W^X. Las apps deben cargar solo el código binario incorporado en el archivo APK de una app.
Las apps no confiables que se orientan a Android 10 no pueden invocar a execve() directamente en archivos dentro del directorio principal de la app.
Además, las apps que se orientan a Android 10 no pueden modificar el código ejecutable en la memoria de los archivos que se abrieron con dlopen() y esperar que esos cambios se escriban en el disco, ya que la biblioteca no se puede asignar a PROT_EXEC a través de un descriptor de archivos de escritura. Esto incluye cualquier
Archivos de objeto compartido (.so) con reubicaciones de texto.
El tiempo de ejecución de Android solo acepta archivos OAT generados por el sistema
El entorno de ejecución de Android (ART) ya no invoca dex2oat desde la aplicación.
el proceso de administración de recursos. Este cambio implica que ART solo aceptará archivos OAT que se hayan
que generó el sistema.
Implementación de corrección AOT en ART
En el pasado, la compilación por adelantado (AOT) que realizaba el equipo de El tiempo de ejecución (ART) podría causar fallas en el tiempo de ejecución si el entorno de ruta de clase no estaba de la misma manera en el tiempo de ejecución y compilación. Android 10 y versiones posteriores solicitar siempre que estos contextos de entorno sean iguales, lo que da como resultado la los siguientes cambios de comportamiento:
- Los cargadores de clases personalizados, es decir, los cargadores de clases escritos por apps (a diferencia de los del paquete
dalvik.system), no serán compilados por AOT. Esto se debe a que ART no puede conocer la implementación de búsqueda de clase personalizada en el tiempo de ejecución. - Los archivos dex secundarios, es decir, los archivos dex que las apps cargan manualmente y no se encuentran en el APK principal, son compilados por AOT en segundo plano. Esto se debe a que el primer uso Es posible que la compilación sea demasiado costosa, lo que genera latencia no deseada antes ejecución. Ten en cuenta que, en el caso de las apps, adoptar divisiones se recomienda usar archivos dex.
- Bibliotecas compartidas en Android (las entradas <library> y <uses-library> en un manifiesto de Android) se implementan con una clave diferente, de clase del cargador de clases del cargador de clases que se usaba en las versiones anteriores de la plataforma.
Cambios en los permisos para intents de pantalla completa
Apps que se orientan a Android 10 o versiones posteriores y usan notificaciones con
pantalla completa
intents deben solicitar
el
USE_FULL_SCREEN_INTENT
en el archivo de manifiesto de su app. Esta es una situación normal
permiso, por lo que el sistema
se lo otorga automáticamente a la app solicitante.
Si una app orientada a Android 10 o versiones posteriores intenta crear una con un intent de pantalla completa sin solicitar los permiso, el sistema ignora el intent de pantalla completa y genera lo siguiente: mensaje de registro:
Package your-package-name: Use of fullScreenIntent requires the USE_FULL_SCREEN_INTENT permission
Compatibilidad con dispositivos plegables
Android 10 tiene cambios compatibles con dispositivos de pantalla grande y plegables.
Cuando una app se ejecuta en Android 10, los métodos onResume() y onPause() funcionan de manera diferente. Cuando aparecen varias apps al mismo tiempo en el modo multiventana o
modo de varias pantallas, todas las actividades principales enfocables en pilas visibles
están en el estado de "reanudada", pero solo una de ellas es la "más reanudada" actividad,
esté enfocado. Cuando se ejecuta en versiones anteriores a Android 10, solo se puede
una sola actividad en el sistema se puede reanudar a la vez, todas las demás actividades
se detengan las actividades.
No confundas el "foco" con la actividad "más reanudada". El sistema se basa en el orden Z para asignar importancia a las actividades y priorizar más aquellas con las que el usuario interactuó por última vez. Una actividad puede ser más reanudadas, pero que no están enfocadas (por ejemplo, si el panel de notificaciones está expandido).
En Android 10 (nivel de API 29) y versiones posteriores, puedes suscribirte a la devolución de llamada onTopResumedActivityChanged() para recibir una notificación si tu actividad adquiere o pierde la posición de más reanudada. Esta equivale al estado reanudado antes de Android 10 y puede servir de indicio si tu app está usando recursos exclusivos o singleton que tal vez deban compartirse con otras apps.
El comportamiento del
resizeableActivity
manifiesto también cambió. Si una app establece
resizeableActivity=false en Android 10 (nivel de API 29) o versiones posteriores, es posible que se establezca el modo de compatibilidad
cuando cambia el tamaño de la pantalla disponible o si la aplicación pasa de una pantalla a
con el otro.
Las apps pueden usar la
android:minAspectRatio
, que se introdujo en Android 10, para indicar la pantalla
proporciones que admite tu app.
A partir de la versión 3.5, la herramienta de emulación de Android Studio incluye dispositivos virtuales de 7.3" y 8" para que pruebes tu código con pantallas más grandes.
Para obtener más información, consulta Cómo diseñar tus apps para dispositivos plegables.