Android 11 introducirá una opción de desarrollador de "Compatibilidad de aplicaciones" para ayudar a probar los cambios en la plataforma

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 viene con un montón de cambios en las API y comportamiento de la plataforma. Es importante que los desarrolladores de aplicaciones tomen nota de estos cambios y preparen sus aplicaciones, ya que pueden alterar fundamentalmente la forma en que los usuarios finales pueden consumir sus aplicaciones. Con la próxima versión de Android, Android 11, Google facilitará a los desarrolladores probar y preparar sus aplicaciones para los próximos cambios con una nueva configuración de "Compatibilidad de aplicaciones" en Opciones de desarrollador.

Cada vez que Google lanza una nueva versión de Android, los desarrolladores de aplicaciones interesados ​​en mantenerla activamente sus aplicaciones deben leer sobre los nuevos cambios y la documentación que viene con estos cambios. Luego, pueden decidir actualizar su aplicación para agregar estas nuevas funciones de API si así lo desean o migrar el uso de las 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 inmediatamente, pero sí tienen que hacerlo eventualmente para cumplir con los requisitos. Cambiando los requisitos de API de destino de Google Play Store. Después de esto, los desarrolladores también deben probar 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 se vuelven aún más importantes cuando implican cambios importantes.

Además, cuando Google quiere introducir cambios importantes en el comportamiento de la plataforma, no implementa inmediatamente el cambio en 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ícitas para ahorrar batería. Con Android 8 Oreo, Google aplicaciones completamente restringidas para que no registren receptores de transmisión implícitos. 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ícitos. Y para ello, los desarrolladores podrían use 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 appops set RUN_IN_BACKGROUND ignore

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 bajo los 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 Storage en sus aplicaciones ejecutando este comando ADB:

adb shell cmd appops set your-package-name android: legacy_storage default && \

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 plataforma. Pero siempre hay margen de mejora y Google está facilitando este proceso de prueba introduciendo una interfaz de usuario sencilla para controlar estos cambios.

con el nuevo Proyecto PlatformCompat, los desarrolladores ya no necesitan ejecutar comandos ADB para todos y cada uno de los nuevos cambios de comportamiento de la plataforma. Con Android 11, Android tendrá un nuevo submenú dentro de Opciones de desarrollador para alternar rápidamente 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 objetivo; por ejemplo, el nivel de API > 29 tendrá su propio conjunto de cambios de comportamiento que se pueden alternar, mientras que el nivel API > 30 tendrá su propio conjunto de cambios.

En la captura de pantalla anterior que muestra la sección Compatibilidad de aplicaciones (de un AOSP creado en código fuente que se ejecuta en un emulador), la opción "Predeterminada La sección "Cambios habilitados" incluye cambios en la API de Android 11 que se habilitarán de forma predeterminada en todas las aplicaciones, independientemente de su objetivo. SDK. La sección "habilitada para targetSDKversion > 29" son cambios de API de Android 11 que están habilitados solo para aplicaciones orientadas 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 XDA lucas020400 por el consejo y por proporcionar la captura de pantalla adjunta.

Cobertura adicional sobre Android 11:

• Android 11 finalmente puede eliminar el límite de tamaño de archivo de 4 GB de Android para grabaciones de video
• La programación del modo oscuro podría llegar en Android 11
• El modo avión finalmente puede dejar de apagar el audio Bluetooth, a partir de Android 11 R
• Google está desaprobando la API AsyncTask de Android en Android 11
• Google hará que los desarrolladores de administradores de archivos envíen un formulario para obtener un amplio acceso al almacenamiento de archivos en Android 11
• Android 11 finalmente puede traer una implementación ADB inalámbrica nativa adecuada