Los ingenieros de Google hicieron un AMA en Reddit el otro día. La AMA fue sobre la versión beta de Android Q. Aquí hay un resumen de lo que aprendimos de sus respuestas.
El año pasado, el equipo de Android de Google organizó un Ask Me Anything (AMA) en el subreddit /r/AndroidDev de Reddit para responder preguntas sobre el Vista previa para desarrolladores de Android P. Este año, el equipo de ingeniería que trabaja en la versión beta de Android Q respondió preguntas en Reddit. La AMA Comenzó el 1 de agosto a las 12:00 p.m. PST y terminó aproximadamente una hora y media después. 33 ingenieros de Google participaron en la AMA y respondieron un montón de preguntas en el poco tiempo que duró la AMA. Aquí está nuestro resumen de toda la nueva información que aprendimos.
Android Q AMA: Todo lo que aprendimos de Google
Participantes del equipo beta de Android Q
- Adán Cohen: TLM en el iniciador de Android/UI del sistema
- Adán Powell: TLM en el marco/kit de herramientas de la interfaz de usuario; vistas, ciclo de vida, fragmentos, bibliotecas de soporte
- Alan Viverette: TLM, Jetpack/AndroidX
- Allen Huang: ¡PM para UI, iniciador, notificaciones, integraciones de búsqueda y más!
- Andrés Sappirstein: TLM en la configuración de Android
- Brahim Elbouchikhi: PM Director para cámara y aprendizaje automático de Android (NN API, ML Kit, CameraX, Camera Platform)
- Chad Brubaker: Ingeniero de software, seguridad de la plataforma Android
- Charmaine D'Silva: MP para privacidad
- Chet Haase: Defensor principal de Android, relaciones con los desarrolladores
- Diana Wong: PM, compatibilidad de aplicaciones, uso de API no SDK, ART, NDK
- Diana Hackborn: Responsable del equipo del framework Android (Recursos, Gestor de Ventanas, Gestor de Actividades, Multiusuario, Impresión, Accesibilidad, etc.)
- E.K. Chung: Director de UX
- Ian Lago: Ingeniero de Software, Jetpack (Fragmentos, Navegación, Componentes de Arquitectura)
- Iliyan Malchev: Ingeniero de software principal, proyecto Mainline
- Jacob Lehrbaum: Director de Relaciones con Desarrolladores para Android
- Jake Wharton: Ingeniero de software, Jetpack
- Jamal Eason: PM, estudio de Android
- Jeff Bailey: TLM, Proyecto de código abierto de Android (AOSP)
- Jeff Sharkey: Ingeniero de software, marco de Android
- jeffrey van gogh: Android Studio, compiladores
- Jen Chai: PM, ubicación y contexto, autenticación, autocompletar, uso de API sin SDK, ART
- Karen Ng: PM grupal para herramientas de desarrollo de Android, Android Studio, Android Tookit y Jetpack
- Paul Bankhead: Director de Gestión de Productos, Google Play
- Rohan Shah: Gerente de producto, interfaz de usuario del sistema Android
- chico romano: Responsable del equipo de Android Toolkit/Jetpack
- Sagar Kamdar: Director de Gestión de Productos, Android
- Sáb K: Director de Ingeniería, Conectividad Android
- Selim Cinek: Ingeniero de software, interfaz de usuario del sistema Android
- Stephanie Saad Cuthbertson: Director sénior de gestión de productos, Android
- Sumir Kataria: Ingeniero de software, Jetpack (WorkManager)
- Travis McCoy: PM, plataforma Android
- Trystan Upstill: Ingeniero distinguido, líder de inteligencia y interfaz de usuario del sistema Android
- Vinit Modi: PM, cámara Android
leer más
Los OEM ya no pueden eliminar aplicaciones cuando el usuario las elimina en los últimos tiempos
Si alguna vez ha utilizado un teléfono inteligente de una marca china, probablemente se haya enfrentado a molestas funciones de "optimización de la batería" que elimina todas tus aplicaciones favoritas en segundo plano. Este comportamiento no solo es molesto para los usuarios que esperan que ciertas aplicaciones continúen ejecutándose en segundo plano por cualquier motivo, pero también es molesto para los desarrolladores que tienen que sufrir malas críticas por parte de usuarios que no entienden que no es la aplicación. falla. Mientras Google es aún no abordar completamente este asunto (desecharon el problema afirmando que este comportamiento es probablemente ya infrinja los requisitos del Documento de definición de compatibilidad de Android), la empresa es tomando acción contra un cambio de comportamiento de "ahorro de batería" empleado por algunos fabricantes de equipos originales.
"Para ayudar con la situación, hemos agregado una prueba CTS en Android Q para garantizar que una aplicación no se elimine al ser eliminada de Recientes".
Android R puede traer más cambios en las capturas de pantalla de los que esperábamos
Google planea agregar capturas de pantalla con desplazamiento en Android R, pero al mismo tiempo, el El equipo de Android es "observando de cerca cómo [ellos] pueden mejorar toda la experiencia de pantalla [X] para R". Así, podemos Vea otras mejoras en el comportamiento de la captura de pantalla (Y del screencast) en la próxima versión principal de Android.
Aclarando el nuevo modo de escritorio de Android Q
El primera versión beta pública de Android Q trajo una interfaz de modo de escritorio oculto a AOSP y Pixel Launcher. Aunque Google mencionó brevemente la característica Durante una sesión de Google I/O, nunca escuchamos directamente de Google cómo encaja la nueva función en el ecosistema de Android. Google ahora aclara:
"En Q AOSP, el 'modo de escritorio' es una opción de desarrollador dirigida a desarrolladores de aplicaciones. Les permite probar sus aplicaciones en entornos de modo de ventana de forma libre y de pantalla múltiple. Anteriormente no existía una forma conveniente de probar el comportamiento de la aplicación en una pantalla secundaria y con ventanas de tamaño variable en Android estándar. Esta función no está disponible por sí sola y no está destinada a usuarios habituales por el momento. Sin embargo, es la base de la plataforma Android para que los OEM puedan innovar y crear excelentes productos".
Por lo tanto, podemos esperar ver que los OEM se basen en el modo de escritorio nativo de Android Q. Por ejemplo, el OnePlus 7 Pro admite visualización a través de HDMI, entonces es posible que OxygenOS 10 basado en Android Q tendrá su propia interfaz en modo escritorio en el futuro. También esperamos que Google desarrolle esta función en las próximas Píxel 4.
Modo oscuro basado en el tiempo
Android Q finalmente trae una característica muy solicitada: modo oscuro en todo el sistema. Actualmente, el modo oscuro se puede habilitar manualmente en Configuración o mediante un mosaico de Configuración rápida, o se puede activar automáticamente cuando se habilita el Ahorro de batería. Antes de Android Q, existía una opción para habilitar el modo oscuro basado en la hora del día, pero esa opción estaba en desuso. Según Chris Banes:
"Hay algunas razones por las que esto está obsoleto (no eliminado) en AppCompat v1.1.0: requiere que las aplicaciones soliciten Los permisos de ubicación son precisos, e incluso con una ubicación válida, los cálculos de la hora de salida y puesta del sol pueden ser calesa."
Cuando se le preguntó acerca de estos errores, el Sr. Banes afirma que "calcular la salida y la puesta del sol es notoriamente difícil, especialmente en lugares cercanos a polos norte/sur". Un usuario menciona que Night Light, disponible desde Android 7.1 Nougat, se puede alternar automáticamente según Sunset/Sunrise. horarios. El Sr. Banes luego afirma que dado que Night Light usa CalendarAstronomer de UCI4J, utiliza una "gran porción de código del que no queremos que dependa AppCompat". Sin embargo, el equipo no estado que esta característica es "algo que [ellos] estarán investigando".
Compatibilidad obligatoria con Camera2 API/Camera HAL3 para dispositivos de lanzamiento de Android Q
Google introdujo la API Camera2 para definir mejor cómo las aplicaciones pueden interactuar con las cámaras individuales conectadas a su teléfono inteligente. Mientras Google alienta Los proveedores de teléfonos inteligentes "exponen todas sus cámaras físicas a los desarrolladores", muchos proveedores optan por no hacerlo a pesar de que "la API en sí no es impidiéndolos hoy". Esto significa que muchas aplicaciones de cámara de terceros no pueden usar los módulos de cámara secundarios o terciarios en los dispositivos modernos. teléfonos inteligentes. Sin embargo, se están logrando avances, ya que Android Q ha mejorado LÓGICA_MULTI_CÁMARA, una API que brinda a los desarrolladores un mejor acceso a todas las cámaras de un dispositivo y que brinda a los OEM control sobre el consumo de energía y la administración de múltiples estados de la cámara.
Además, Google dice que ha agregado requisitos para que todos los dispositivos que se inician con Android Q sean compatibles de forma nativa con Camera2 API/Camera HAL3. Según Vinit Modi:
"A partir de Android P, los nuevos dispositivos que se envían con 1 GB o más de RAM deben utilizar HALv3/camera2 de forma nativa. Android Q en adelante, todos los dispositivos nuevos deben ser compatibles de forma nativa con HALv3/camera2. Desafortunadamente, las actualizaciones de HALv1 a HALv3 son bastante complejas por aire y pueden tener consecuencias inesperadas, por lo que tuvimos que limitar el alcance a nuevos dispositivos".
Curiosamente, la declaración de Modi sobre la RAM normal de los dispositivos de lanzamiento de Android P contradice lo que Google nos dijo anteriormente y lo que se publica en la página en línea de Image Test Suite.
Tematización dinámica de aplicaciones con Jetpack Compose
El marco temático OMS de Sony se agregó a AOSP hace bastantes lanzamientos, pero es solo destinado a fabricantes de equipos originales para construir sobre. eso ya lo sabemos Google está en contra el uso de superposiciones de recursos de tiempo de ejecución por parte de los usuarios para aplicaciones temáticas, pero para los desarrolladores, la empresa es esperando que es Interfaz de usuario de redacción de Jetpack El marco presentará "enfoques interesantes para la tematización dinámica".
Vulkan-backend para Skia para renderizar la interfaz de usuario
El año pasado, vimos una discusión entre los ingenieros de Google hablan sobre sus planes de que el marco de Android utilice la API de gráficos Vulkan para la representación de la interfaz de usuario. Si bien ahora es posible habilitar el backend acelerado por hardware de Vulkan sin su teléfono fallando, no hemos escuchado ningún plan concreto de Google sobre cuándo planean implementar estos cambios. Esta AMA no responde a esa pregunta, pero al menos tenemos confirmación de que todavía está en proceso. Según Romain Guy:
"El equipo ha estado trabajando en un backend de Vulkan para Skia, el renderizador 2D utilizado por Android, pero actualmente no está habilitado de forma predeterminada. La UI y Canvas todavía pasan por OpenGL ES."
Hacer que la barra de gestos de Android Q sea más dinámica
Algunos en XDA todavía piensan que Los nuevos gestos de Android son un desastre, pero personalmente creo que están bien. Sin embargo, si juegas un poco con los nuevos gestos en Android Q, notarás que la barra de gestos no se mueve con el dedo. También permanece en pantallas donde no es necesario, como la pantalla de inicio o la descripción general de aplicaciones recientes. Allen Huang dice que están "totalmente de acuerdo en que existen oportunidades" para hacer que la "línea de navegación sea menos estática". Él dice además que "esto es algo en lo que estamos trabajando, pero también equilibrando para que no distraiga aparecer/desaparecer."
Mejoras al marco de acceso al almacenamiento
Los numerosos cambios en Android Q han mejorado considerablemente la seguridad y privacidad de la plataforma. Uno de esos cambios, llamado "Almacenamiento con alcance", limita el acceso de las aplicaciones a los archivos en el almacenamiento externo de una manera que tiene sentido; las aplicaciones de música no deberían necesitar ver tu galería, por ejemplo. Las aplicaciones de administrador de archivos que se ejecutan en Android Q deben usar una API llamada Storage Access Framework para continuar funcionando normalmente, pero algunos desarrolladores ven esta API como inferior a lo que antes estaba disponible. Jeff Sharkey de Google dice el equipo ha abordado algunas de las quejas de estos desarrolladores:
"Hicimos algunas mejoras en el rendimiento de SAF en las últimas versiones Beta de Android Q; ¿Podrías comparar tus puntos de referencia con la última versión Beta? También asegúrese de utilizar ContentProviderClient cuando ejecute operaciones masivas".
Project Treble mejoró la adopción de Android Pie frente a Android Oreo
Ya hemos visto cómo Project Treble, una importante reestructuración de bajo nivel del marco de trabajo de Android, ha mejorado la adopción de versiones más nuevas del sistema operativo Android. Google atribuye a Treble el mérito de la gran cantidad de proveedores de teléfonos inteligentes que se unen al Android P beta el año pasado y Android Q beta este año. Iliyan Malchev, el líder del Proyecto Treble y Línea principal ingeniero, dice que la adopción de Android Pie fue "tres veces" mayor que la de Android Oreo a finales de 2018.
En el mismo comentario, Dick Dougherty se burla de que se están trabajando en métricas más útiles para el gráfico de distribución de versiones de Android. El gráfico fue última actualización en mayo, pero sus datos son más útiles para los periodistas que para los desarrolladores de aplicaciones.
La grabación de pantalla sigue siendo un WIP
Las primeras versiones beta de Android Q agregaron un indicador de función para una grabadora de pantalla básica, pero la plataforma en sí ha mejorado considerablemente la utilidad de la grabación de pantalla al permitiendo que las aplicaciones capturen el audio de otras aplicaciones. Stephanie Saad Cuthbertson dijo que el equipo estaba considerando "cómo podríamos mejorar las necesidades de grabación de pantalla tan recientemente como ayer". Otras marcas de teléfonos inteligentes como OnePlus, ASUS, Huawei y Samsung tienen grabadores de pantalla robustos que pueden grabar el audio interno, por lo que Google se pondrá al día aquí.
Tema oscuro ¡Todas las cosas!
En caso de que te lo hayas perdido, Google está agregando el modo oscuro a la mayoría de sus aplicaciones. Stephanie Saad Cuthbertson dice esperar que todas las "aplicaciones principales" admitan un tema oscuro "en el lanzamiento oficial [de Android Q]". Incluso Google Chrome, que actualmente fuerza una recarga de página cuando el tema oscuro en todo el sistema está habilitado, se actualizará para que ya no se actualice cuando el tema esté habilitado. cambió.
Sí, los lanzadores de terceros funcionarán con gestos (eventualmente)
Los gestos de Android son una especie de roto cuando usas un lanzador de terceros. Esto se debe a que la interfaz de usuario de las aplicaciones recientes está contenida en la aplicación de inicio de acciones y Google aún no la ha publicado. Descubrimos una manera de tener las mismas transiciones fluidas que vemos cuando usamos gestos con el Pixel estándar. Lanzacohetes. Adán Cohen afirma Los planes de Google para abordar estos problemas "lo más rápido posible después del lanzamiento". Dice además que la incompatibilidad "se abordará en la actualización posterior a Q y se respaldará para nuevos dispositivos que se lancen con P."
Las particiones dinámicas/lógicas no están aquí para eliminar las ROM personalizadas
Para poder apoyar Actualizaciones dinámicas del sistema En Android Q, ciertos dispositivos como Google Pixel 3 y Pixel 3 XL utilizan particiones lógicas. Estas particiones se pueden cambiar de tamaño dinámicamente. Este cambio tiene ha demostrado ser un desafío para lograr que el acceso root funcione, y a algunos desarrolladores les preocupa que se estén atacando las ROM personalizadas. Iliyan Malchev nos asegura que la intención no es limitar las ROM personalizadas. Como el explica:
"Las particiones dinámicas no están destinadas a limitar lo que se puede hacer con las ROM personalizadas. Son simplemente una solución al problema de los tamaños de partición fijos y la falta de una forma segura de reparticionar dispositivos en OTA. Antes de las particiones dinámicas, si un OEM cometía un error en el tamaño, p. la partición del sistema, entonces estaría limitado por esa elección, haciendo prácticamente imposible actualizar un dispositivo después de cierto punto. Algunos fabricantes de equipos originales reparticionan sus dispositivos en OTA como cuestión de práctica, pero esto a) no es oficialmente compatible con Android yb) cambiar la tabla de particiones se considera bastante arriesgado. Las particiones dinámicas tienen como objetivo aliviar el problema introduciendo un nivel de dirección indirecta entre la tabla de particiones físicas y el sistema operativo. Esto, a su vez, nos permite ajustar de forma segura el tamaño de las particiones en OTA. En cuanto a las ROM personalizadas, no debería estar más limitado que hoy en cuanto a lo que puede hacer. La compatibilidad con ROM personalizadas es y sigue siendo algo que cada OEM individual decide habilitar".
Línea principal del proyecto: módulo ART y duración del soporte
Mainline es una nueva iniciativa de Google que tiene como objetivo estandarizar ciertas bibliotecas y paquetes para que puedan actualizarse independientemente de las actualizaciones de la plataforma. Algunos se han preguntado por qué Android Runtime (ART) aún no es un módulo principal, pero en Google I/O me dijeron que eso la complejidad involucrada en la modularización de ART les impidió incluirlo como uno de los paquetes APEX iniciales. Como explicado por Iliyan Malchev y Diana Wong:
"Realizar actualizaciones en Runtime (especialmente correcciones de rendimiento y GC y bibliotecas principales) es definitivamente algo que estamos explorando en el contexto de la línea principal. Podemos ver muchos beneficios al poder hacer que estas actualizaciones sean consistentes en todos los dispositivos y en múltiples versiones con la línea principal. También es un gran desafío técnico mientras pensamos en cómo hacerlo mejor para los desarrolladores, y probablemente un esfuerzo de varios años. No es algo que Mainline pueda hacer actualmente, pero ciertamente es algo en lo que estamos pensando".
Si sigues a AOSP Gerrit, verás que, no obstante, Google ha sido duro en el trabajo haciendo un APEX en tiempo de ejecución. Actualmente parecen estar dividiendo Bionic y ART/libcore en módulos APEX separados.
Con respecto al beneficio de Project Mainline, un usuario preguntó sobre la duración de las actualizaciones de Mainline. En respuesta, Iliyan Malchev dice que "esta es una cuestión de política que todavía estamos evaluando, pero queremos actualizar los módulos Mainline en un dispositivo durante el mayor tiempo posible". Desarrollador reconocido por XDA lucas020400 Se preguntó si se proporcionarán módulos Mainline prediseñados para que los desarrolladores de ROM personalizados puedan fusionar actualizaciones y, en respuesta, Jeff Bailey. reitera que "los módulos que se separan de AOSP tendrán versiones de origen que coincidan con la versión de cada módulo". Ya podemos ver la progresión de nuevos módulos APEX en AOSP como uno para el API de redes neuronales.
CameraX se encuentra con el kit ML
En I/O este año, Google presentó el Biblioteca CameraX Jetpack. Esta biblioteca está diseñada para facilitar a los desarrolladores la compatibilidad con la API Camera2 de Android y al mismo tiempo mantener la compatibilidad desde Android Lollipop. Vinit Modi se burla que la empresa está trabajando en la integración de CameraX con Kit de aprendizaje automático, el SDK de Firebase de aprendizaje automático de Google, para que los desarrolladores puedan introducir marcos de imágenes en ML Kit para su análisis.
Extensiones de proveedores de CameraX y fecha de lanzamiento
El desarrollador de una aplicación de cámara lamenta el hecho de que las funciones avanzadas de la cámara, como Night Sight de Google Pixel, no sean accesibles para aplicaciones de cámara de terceros. Se supone que esto se puede solucionar con las extensiones del proveedor CameraX, a lo que Jeff Sharkey de Google dice que "todos los dispositivos Pixel están optimizados para CameraX Core". Se burla de que "el aspecto de Extensiones será compatible con dispositivos nuevos y futuros". Además, Google es "Trabajar con varios fabricantes para poder acercar las capacidades de sus dispositivos tanto a desarrolladores como a usuarios". Si bien no se confirma directamente, es posible que veamos características como Vista nocturna sobre el Google Píxel 4 estará disponible para aplicaciones de cámara de terceros que utilicen la biblioteca CameraX.
Sharkey afirma que Google tiene previsto lanzar una versión beta a finales de este año.
Mejoras en la gestión de la memoria en Android Q
El Pixel 3 fue criticado por tener numerosos problemas posteriores al lanzamiento, pero Google ha hecho mucho para abordar estos problemas a través de numerosos actualizaciones posteriores al lanzamiento. La gestión de la memoria ha sido uno de los aspectos más débiles del Pixel 3, pero las cosas deberían mejorar un poco en la versión de Android Q. Según Selim Cinek:
"En SystemUI, por ejemplo, tuvimos varios grandes esfuerzos de refactorización en Q para reducir el uso de RAM de notificaciones y otras superficies".
¿Finalmente tendremos ADB inalámbrico?
Si desea depurar su teléfono de forma inalámbrica, deberá rootear su dispositivo. Jamal Eason del equipo de Android Studio dice que actualmente están abordando la viabilidad de esta característica.
¿Google todavía realiza pruebas en tabletas?
Desarrollador reconocido por XDA luk1337 preguntó si Google todavía prueba AOSP UX en tabletas. Es una pregunta justa considerando el escasez de buenas tabletas Android y el errores presentes en las versiones actuales. Allen Huang dice que Google todavía "prueba y realiza correcciones cada año" y que la compañía está trabajando estrechamente con sus socios "para garantizar una buena experiencia con la tableta Android".
Hay muchas más publicaciones en el hilo completo de Reddit. Lo que he cubierto aquí resume toda la información nueva que aprendimos, pero varios empleados de Google (especialmente Dianne Hackborn) explican su razonamiento detrás de eliminar la función X o no implementar Y permiso. Te recomiendo que leas el AMA completo si quieres comprender un poco mejor la toma de decisiones del equipo de Android.
Lea el AMA completo en /r/AndroidDev