Cada año, en Google I/O, Google destaca algunos de los cambios más interesantes que llegarán a la próxima versión de Android. Si bien la mayoría de los usuarios juzgan las versiones de Android por los cambios visuales que afectan su experiencia, cada actualización de Android también trae consigo un montón decambios en las APIyel comportamiento de la plataforma. Es importante que los desarrolladores de aplicaciones tomen nota de estos cambios y preparen sus aplicaciones para ellos, ya que pueden alterar fundamentalmente las formas en que los usuarios finales pueden consumir sus aplicaciones. Con la próxima versión de Android, Android 11, Google facilitará a los desarrolladores la prueba y la preparación de sus aplicaciones para los próximos cambios con una nueva configuración de "Compatibilidad de aplicaciones" en las Opciones de desarrollador.

Cada vez que Google lanza una nueva versión de Android, los desarrolladores de aplicaciones que estén interesados ​​en mantener sus aplicaciones de forma activa deben leer sobre los nuevos cambios y la documentación que acompaña a estos cambios. Luego pueden decidir actualizar su aplicación para agregar estas nuevas funciones de API si lo desean o migrar su uso de API existentes a API más nuevas, una ruta que puede ser opcional o no. Los desarrolladores de aplicaciones no tienen que actualizar la API de destino de sus aplicaciones de inmediato, pero sí deben hacerlo eventualmente para cumplir con losrequisitos cambiantes de la API de destino de Google Play Store. Después de esto, los desarrolladores también deben probar realmente su aplicación en la nueva versión de Android, y esto se puede hacer en un dispositivo emulado, un dispositivo alojado en la nube o un dispositivo local. Las pruebas son parte de la rutina de desarrollo, pero las pruebas se vuelven aún más importantes cuando hay cambios importantes involucrados.

Además, cuando Google quiere introducir cambios importantes en el comportamiento de la plataforma, no implementa inmediatamente el cambio en el lanzamiento de la nueva versión de Android. Esto es para proteger a los usuarios de que muchas de sus aplicaciones se rompan y pierdan funcionalidad, y también les da a los desarrolladores más tiempo para actualizar sus aplicaciones. Por ejemplo, en Android 7 Nougat, Google decidiólimitar algunas transmisiones implícitaspara ahorrar batería. Con Android 8 Oreo, Googlerestringió por completo que las aplicaciones registren receptores de transmisión implícita. Pero antes de que se lanzara Android 8 Oreo, Google quería que los desarrolladores se prepararan para un escenario en el que sus aplicaciones ya no pudieran registrar receptores de transmisión implícita. Y para esto, los desarrolladores podríanusar un comando ADB en Android 7 Nougat para simular una condición en la que las transmisiones implícitas no estén disponibles:

adb shell cmd appopssetRUN_IN_BACKGROUNDignore

Los comandos ADB como el anterior son un ejemplo de cómo Google permite a los desarrolladores de aplicaciones probar cómo se comportarían sus aplicaciones ante cambios de comportamiento de la plataforma Android.

Otro ejemplo reciente es cómo en Android Q Beta 2,Google pidió a los desarrolladores que probaran Scoped Storageen sus aplicaciones ejecutando este comando ADB:

adb shell cmd appopssetyour-package-nameandroid:legacy_storagedefault&& \

Como desarrollador de aplicaciones, se puede suponer que se siente cómodo con los comandos ADB y que no es particularmente reacio a usarlos para probar estos cambios de la plataforma. Pero siempre hay margen de mejora y Google está facilitando este proceso de prueba al presentar una interfaz de usuario sencilla para controlar estos cambios.

Con el nuevoproyecto PlatformCompat, los desarrolladores ya no necesitan ejecutar comandos ADB para cada cambio de comportamiento de la plataforma. Con Android 11, Android tendrá un nuevo submenú dentro de las Opciones de desarrollador para alternar rápidamente los nuevos cambios de comportamiento de la plataforma por aplicación, sin necesidad de enviar ningún comando de shell ADB. Habrá diferentes secciones para cada nivel de API de destino; por ejemplo, el nivel de API > 29 tendrá su propio conjunto de cambios de comportamiento que se pueden alternar, mientras que el nivel de API > 30 tendrá su propio conjunto de cambios.

Cambios en la compatibilidad de aplicaciones de Android 11

En la captura de pantalla anterior que muestra la sección Compatibilidad de aplicaciones (de un AOSP creado a partir de código fuente que se ejecuta en un emulador), la sección "Cambios habilitados de forma predeterminada" incluye cambios de la API de Android 11 que se habilitarán de forma predeterminada en todas las aplicaciones, independientemente de su SDK de destino. La sección "Habilitado para la versión de SDK de destino > 29" son cambios de la API de Android 11 que se habilitan solo para las aplicaciones que apuntan a Android 11/nivel de API 30.

Si bien este cambio en particular no entusiasmará directamente a los usuarios finales, sí facilita el trabajo de los desarrolladores de aplicaciones, y eso siempre es bueno.

Gracias al desarrollador reconocido de XDAluca020400por el consejo y por proporcionar la captura de pantalla adjunta.

Más información sobre Android 11: