Reglas de lint de ChromeOS en Android Studio

En ChromeOS, nos comprometemos a mejorar las herramientas y los frameworks para desarrolladores que permiten a los desarrolladores de apps para Android optimizar sus apps para Chromebooks sin problemas. Para ello, debemos buscar constantemente formas de brindar a los desarrolladores conjuntos de herramientas eficaces que mejoren la experiencia de crear apps para pantallas grandes y ChromeOS.

ChromeOS evolucionó a lo largo de los años a medida que se presentaron nuevos desafíos. Uno de estos desafíos es identificar los problemas críticos para los ingenieros de forma temprana y frecuente. Las reglas de Lint son la base de la calidad, ya que proporcionan indicadores de alerta a los desarrolladores sobre los problemas que surgirán si no se corrigen. Nuestras reglas de lint actualizadas brindan a los desarrolladores más visibilidad sobre cómo se ejecutan sus apps en ChromeOS, y muestran problemas, tanto de software como de hardware, que sin duda causarán problemas en las aplicaciones para Android que se ejecuten en cualquier dispositivo ChromeOS.

Para obtener más contexto sobre la existencia de estas reglas de lint y su importancia, lee nuestra entrada de blog.

¿Dónde se encuentran estas reglas de lint?

Hemos estado en desarrollo activo durante algunos meses. Con el cronograma de lanzamientos de Android Studio, se están introduciendo algunas reglas de lint con las compilaciones de Electric Eel Canary. Algunas de estas reglas de lint también están disponibles en las versiones de Canary de Flamingo. Seguiremos trabajando para que estas funciones estén disponibles en las versiones estables de Android Studio en los próximos meses.

Otro aspecto importante que debes tener en cuenta es que estas reglas estarán habilitadas de forma predeterminada en las versiones más recientes de Android Studio. El objetivo es brindar una orientación más sólida sobre cómo queremos ayudar a los ingenieros a compilar para ChromeOS y pantallas más grandes en el futuro.

Nuevas reglas de Lint (actualizadas a partir de Flamingo Canary 3)

Compatibilidad con ABI x86/x86_64

La mayoría de las Chromebooks ejecutan la arquitectura Intel, lo que las convierte en una plataforma arquitectónica predominantemente x86. Para que ChromeOS sea compatible correctamente cuando se incluye código del NDK como parte del objeto binario, tener x86 es una mejora del rendimiento, ya que se elimina la traducción requerida de las bibliotecas de ARM. Por lo tanto, se recomienda encarecidamente que tu equipo de desarrollo agregue compatibilidad con la arquitectura x86 o, preferentemente, x86_64, ya que esto mejoraría el rendimiento de cualquier código nativo en ChromeOS o en cualquier dispositivo Intel.

Solución

Si es posible, agrega x86 y x86_64 dentro de tu abiSplits en tu build.gradle. Además, asegúrate de agregar el código a las carpetas correspondientes para admitir estas ABIs. Para obtener más información, consulta la documentación sobre ABI de Android y la charla sobre compatibilidad con ABI de ADS.

Nota: Asegúrate de que las bibliotecas de terceros incluidas que se utilicen también tengan objetos binarios x86 y x86_64.

Limitación de hardware de ChromeOS

La mayoría de los dispositivos ChromeOS incluyen un conjunto de muestra más pequeño de sensores de hardware y otras funciones en comparación con un teléfono Android. El objetivo de esta regla es indicar a los desarrolladores que, si usan la marca <uses-feature> con android:required=true, su app no estará disponible en Google Play Store en ChromeOS. Una recomendación importante para garantizar que se pueda acceder a tu app en la mayor cantidad posible de dispositivos es asegurarte de que la función de hardware no sea obligatoria de forma predeterminada. En su lugar, puedes agregar código defensivo para verificar hardware específico en el tiempo de ejecución. Un ejemplo de esto sería

<uses-feature android:name="android.hardware.camera" android:required="true">

Solución

Asegúrate de que las funciones que se encuentran dentro de tu aplicación sean realmente necesarias y, si no lo son, cambia el parámetro android:required a false y agrega programación defensiva cuando se requieran llamadas a la API. Para obtener más información, consulta la documentación sobre las funciones declaradas de forma explícita.

Actividades que no se pueden cambiar de tamaño

De forma predeterminada, Android Runtime para ChromeOS, que ejecuta Android R o versiones posteriores en Chromebooks, inicia una app para Android en la versión para teléfonos o tablets de la aplicación, según el estado predeterminado de la IU. Sin embargo, existe una tercera opción que ofrece una mejor experiencia para los usuarios de ChromeOS: el modo redimensionable. Si habilitas este parámetro como parte de tu actividad, los usuarios que puedan usar tu aplicación en cualquier entorno multiventana podrán aprovechar el cambio de tamaño de tu aplicación al tamaño adecuado. Estos cambios permitirán a los usuarios ajustar la escala de la IU para satisfacer sus necesidades. Después de agregar estos cambios a tu manifiesto, prueba tu aplicación en el emulador de escritorio que se menciona a continuación.

Prueba tu aplicación en el emulador de escritorio

Solución

Agrega el atributo resizableActivity="true" a tu actividad en el archivo AndroidManifest.xml. Para obtener más información, consulta la documentación sobre las restricciones de pantallas grandes.

Cambios de configuración

Una advertencia importante sobre las pantallas redimensionables es que onConfigurationChanged() se llama cada vez que un usuario cambia el tamaño de la aplicación. Si tu app emite un nuevo dibujo completo dentro de ese método, habrá implicaciones de rendimiento asociadas a él. Actualmente, verificamos que no se llame a finish() dentro de onConfigurationChanged, ya que deberías controlar el savedInstanceState con más detalle en lugar de forzar un redibujo completo. Seguiremos buscando casos en los que se produzca una degradación del rendimiento y actualizaremos esta regla según corresponda.

Solución

Asegúrate de que no se llame a finish() dentro de la API de onConfigurationChanged() en tus actividades y fragmentos. Para obtener más información, consulta la documentación sobre cómo administrar los cambios de configuración.

Compatibilidad con teclado y mouse

Con la creciente adopción de Jetpack Compose, queríamos asegurarnos de que la compilación con esas bibliotecas también incluyera la funcionalidad para la compatibilidad con mouse y teclado en el futuro. Con el tiempo, seguiremos aumentando la usabilidad del mouse, el teclado, el panel táctil y otras interacciones periféricas. Para obtener las experiencias de referencia, deberás actualizar tus dependencias de Gradle a las versiones mínimas requeridas.

Solución

Actualiza androidx.compose.foundation:foundation a una versión mínima de 1.2. Para obtener más información, consulta las notas de la versión de Compose.

Nota: El 90% de los usuarios interactúan con las apps en Chromebooks usando un teclado y un mouse. (Fuente: Datos internos de Google de 2022*)

Comentarios

El equipo busca constantemente mejorar estas herramientas y la documentación relacionada con las optimizaciones para pantallas grandes. Un paso fundamental en este proceso es brindarnos comentarios sobre la precisión y la utilidad de las reglas de lint implementadas en Android Studio. Para ello, proporciona comentarios sobre la regla. Cuando aparezca la regla de lint en Android Studio, haz clic en "Provide feedback on this warning". Deberías ver un diálogo similar al siguiente. Cuanto más precisa y descriptiva sea la información proporcionada, más rápido podremos realizar los cambios adecuados.

Diálogo de comentarios en Android Studio