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 apps orientadas al nivel de API 29 o versiones posteriores. Si tu app establece la targetSdkVersion en "29" o una versión posterior, debes modificarla para que admita estos comportamientos correctamente, según corresponda.
Asegúrate también de revisar la lista de cambios de comportamiento que afecten a todas las apps que se ejecuten en Android 10.
Nota: Además de los cambios mencionados en esta página, Android 10 presenta varios cambios y restricciones basados en la privacidad, incluidos los siguientes:
- 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 las interfaces no pertenecientes al SDK que tu app puede usar en Android 9 (nivel de API 28). Android 10 incluye listas actualizadas de este tipo de interfaces que están basadas en 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), es posible que algunos de estos cambios no te afecten 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 certeza si tu app usa interfaces que no pertenecen al SDK, puedes probarla para averiguarlo. Si tu app depende de interfaces que no pertenecen al SDK, debes comenzar a planificar una migración hacia alternativas de SDK. Sin embargo, sabemos que algunas apps tienen casos prácticos válidos para usarlas. Si no encuentras una alternativa al uso de una interfaz que no pertenece al SDK para una función de tu app, deberías solicitar una nueva API pública.
Para obtener más información, consulta las actualizaciones de restricciones de interfaces que no pertenecen al SDK para Android 10 y las restricciones para interfaces que no pertenecen al SDK.
Memoria compartida
Ashmem cambió el formato de los mapas dalvik en /proc/<pid>/maps, lo que afecta a las apps que analizan directamente el archivo de mapas. Los desarrolladores de aplicaciones deben probar el formato /proc/<pid>/maps en dispositivos que ejecutan Android 10 o versiones posteriores, y analizarlo si su app depende de los formatos de mapas 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, deben usar la clase ASharedMemory del NDK o las APIs de Java de Android para crear regiones de memoria compartida. Este cambio aumenta la seguridad y la solidez cuando se trabaja 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 infracción 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 orientadas 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 pudo asignar PROT_EXEC a través de un descriptor de archivos que admite escritura. Esto incluye cualquier archivo de objeto (.so) compartido 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 el proceso de la aplicación. Este cambio implica que ART solo aceptará archivos OAT que haya generado el sistema.
Implementación de corrección AOT en ART
En el pasado, la compilación anticipada (AOT) que realizaba el entorno de ejecución de Android (ART) podía provocar fallas en el tiempo de ejecución si el entorno de ruta de clase no era el mismo en el tiempo de compilación y el de ejecución. Android 10 y las versiones posteriores siempre requieren que estos contextos de entorno sean iguales, lo que genera 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 se compilan 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 la compilación de primer uso puede ser demasiado costosa, lo que genera una latencia no deseada antes de la ejecución. Ten en cuenta que, para las apps, se recomienda adoptar divisiones y dejar de usar archivos DEX secundarios.
- Las bibliotecas compartidas en Android (las entradas <library> y <uses-library> en un manifiesto de Android) se implementan con una jerarquía de cargador de clases diferente a la que se usaba en versiones anteriores de la plataforma.
Cambios en los permisos para intents de pantalla completa
Las apps que se orientan a Android 10 o versiones posteriores y usan notificaciones con intents de pantalla completa deben solicitar el permiso USE_FULL_SCREEN_INTENT en el archivo de manifiesto de su app. Este es un permiso normal, por lo que el sistema se lo otorgará automáticamente a la app que lo solicite.
Si una app orientada a Android 10 o versiones posteriores intenta crear una notificación con un intent de pantalla completa sin solicitar el permiso necesario, el sistema ignora el intent de pantalla completa y genera el 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 de varias pantallas, todas las actividades enfocables principales en las pilas visibles están en estado reanudado, pero solo una de ellas, la actividad "más reanudada", en realidad tiene el foco. Cuando se ejecuta en versiones anteriores a Android 10, solo se puede reanudar una actividad en el sistema a la vez; todas las demás actividades visibles se pausan.
No confundas el "foco" con la actividad "más reanudada". El sistema asigna prioridades a las actividades basadas en el orden z para dar mayor prioridad a las actividades con las que el usuario interactuó por última vez. Una actividad puede ser de mayor reanudación, pero no estar enfocada (por ejemplo, si el panel de notificaciones se expande).
En Android 10 (nivel de API 29) y versiones posteriores, puedes suscribirte a la devolución de llamada onTopResumedActivityChanged() para recibir una notificación cuando tu actividad adquiera o pierda la posición reanudada más arriba. Esto equivale al estado reanudado antes de Android 10 y puede ser útil como sugerencia si tu app usa recursos exclusivos o singleton que tal vez deban compartirse con otras apps.
También cambió el comportamiento del atributo de manifiesto resizeableActivity. 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 cambie el tamaño de la pantalla disponible o si la app se mueve de una pantalla a otra.
Las apps pueden usar el atributo android:minAspectRatio, que se introdujo en Android 10, para indicar las relaciones de pantalla que admite tu app.
A partir de la versión 3.5, la herramienta emuladora de Android Studio incluye dispositivos virtuales de 7.3" y 8" para probar el código en pantallas más grandes.
Para obtener más información, consulta Cómo diseñar tus apps para dispositivos plegables.