Android 11 AMA: sin capturas de pantalla con desplazamiento, inicios de aplicaciones más rápidos y más

Ayer Google lanzó Android 11 Beta 2, brindando a los desarrolladores el SDK y NDK finalizados, las superficies orientadas a las aplicaciones, los comportamientos de la plataforma y las restricciones en las interfaces que no pertenecen al SDK. Hoy, Google responde preguntas relacionadas con Android 11 en la comunidad /r/AndroidDev de Reddit. después de responder preguntas la semana pasada. Aquí hay un resumen de todo lo que aprendimos de AMA (Ask Me Anything) de Google.

Una de las funciones más esperadas de Android 11 no estará disponible cuando el sistema operativo sale de la beta el 8 de septiembre: Desplazamiento de capturas de pantalla. Inicialmente planeado para su lanzamiento en Android 11, Google ahora ha confirmado que la característica "no pasó el corte para R". Vista previa para desarrolladores de Android 11 1 y Todas las versiones posteriores de DP y Beta tienen un botón de marcador de posición para tomar una captura de pantalla con desplazamiento que se puede

apareció manualmente con un comando de desarrollador oculto, pero al tocar el botón simplemente se muestra un mensaje de brindis que indica que la función "no está implementada".

Esperábamos que la función llegara a una versión beta o incluso solo a la versión estable, pero parece que eso simplemente no sucederá.

Es comprensible que esta noticia moleste a algunos usuarios. Después de todo, muchos fabricantes de equipos originales han tenido esta función en su propio software durante años, entonces, ¿por qué Google tarda tanto en agregarla a los teléfonos Pixel? Como explica Dan Sandler del equipo de System UI de Google, el problema es que Google quiere hacerlo bien. Algunas implementaciones de capturas de pantalla con desplazamiento simplemente emulan un desplazamiento y luego unen varias capturas de pantalla a medida que la pantalla se mueve. Si alguna vez ha tratado con la automatización de la interfaz de usuario en Android, sabrá que esto no siempre funciona ya que, como menciona el Sr. Sandler, las aplicaciones puede usar "un RecyclerView estándar o haber implementado su propio motor de desplazamiento acelerado por OpenGL". Dado que Google planea implementar esta función no solo para los teléfonos inteligentes Pixel sino para todo el ecosistema de Android como parte de AOSP, deben asegurarse funcionará todo aplicaciones y no sólo "una o dos aplicaciones cuidadosamente seleccionadas en un dispositivo en particular".

Porque el equipo tuvo que "concentrar [sus] recursos limitados", especialmente debido a los desafíos planteados por COVID-19, el equipo decidió dejar las capturas de pantalla con desplazamiento en un segundo plano para una futura versión de Android.

Nuevo requisito de CDD para informar a los usuarios sobre restricciones en segundo plano

No es ningún secreto que muchos fabricantes de equipos originales de Android, especialmente los chinos, tienen restricciones agresivas sobre las aplicaciones que se ejecutan en segundo plano. Algunos desarrolladores estaban tan frustrados con la eliminación de sus aplicaciones en segundo plano que se unieron para crear un sitio web llamado "No mates mi aplicación" para clasificar a los OEM en función de qué tan mal manejan los procesos de aplicaciones en segundo plano. Esos mismos desarrolladores incluso recientemente hizo un punto de referencia para que los usuarios puedan probar con qué agresividad su dispositivo elimina aplicaciones en segundo plano. La razón por la que a muchos OEM les encanta eliminar los procesos de aplicaciones en segundo plano es complicada, pero creo que se explica mejor en este comentario del Redditor /u/.posiblemente cuestionable. El comentario describe el complicado estado del desarrollo de aplicaciones para Android en China, cómo las empresas tecnológicas chinas están involucrados en complicar aún más las cosas, y cómo la falta de servicios de Google contribuye al continuo desorden.

De todos modos, es comprensible que muchos desarrolladores de aplicaciones se sientan frustrados por estos ajustes en el comportamiento de la plataforma Android, lo que ha resultado en que los desarrolladores envíen un comentario. preguntando a Google qué están haciendo al respecto a la cima de Reddit AMA. Aquí está la respuesta de Google:

Hay algunas cosas que sacar de esta respuesta. En primer lugar, Google quiere que los OEM sean más transparentes con los usuarios sobre las restricciones de las aplicaciones en segundo plano que están aplicando. Revisé el Documento de definición de compatibilidad (CDD) de Android 11 (inédito) y encontré la siguiente adición propuesta a la Sección 3.5 - Compatibilidad de comportamiento de API:

Si las implementaciones de dispositivos implementan un mecanismo propietario para restringir aplicaciones y ese mecanismo es más restrictivo que el depósito en espera "raro" en AOSP, ellos:

[C-1-5] DEBE informar a los usuarios si las restricciones de aplicación se aplican a una aplicación automáticamente. (NUEVO) Dicha información no DEBE proporcionarse antes de 24 horas antes de que se apliquen dichas restricciones.

(Nota) La detención forzada se considera más restrictiva que "rara" y DEBE cumplir con todos los requisitos establecidos en 3.5.1, incluido el nuevo 3.5.1/C-1-5.

Básicamente, Google no hace mucho para impedir que los OEM implementen sus propias funciones restrictivas para eliminar aplicaciones. Solo exigen que los OEM informen a los usuarios si las restricciones de sus aplicaciones se aplican automáticamente. Un OEM podría mostrar un cuadro de diálogo indicando que detendrá la ejecución de aplicaciones en segundo plano que consumen batería en el fondo, y el usuario podría dar su consentimiento sin darse cuenta de que las aplicaciones que realmente desea ejecutar en segundo plano también están ¡afectado! Google está responsabilizando a los desarrolladores de lidiar con los casos en los que su aplicación se cierra inesperadamente en segundo plano. De hecho, el comentario de Reddit continúa destacando el nuevo "motivos de salida del proceso de la aplicación"API que puede indicar a los desarrolladores si su aplicación fue eliminada por el usuario, el sistema operativo o si simplemente falló.

Por otro lado, Google finalmente está abordando la práctica desleal de los OEM que permiten que ciertas aplicaciones privilegiadas eviten las restricciones de sus aplicaciones en segundo plano. Esta publicación mediana del desarrollador Timothy Asiimwe entra en detalles sobre aplicaciones como WhatsApp, Facebook y otras aplicaciones que están automáticamente exentas de las duras restricciones de fondo de algunos software OEM. Google dice que "exigen que los fabricantes de dispositivos no creen listas de permitidos para las principales aplicaciones". No sabemos cómo se aplicará esto, pero Es bueno saber que los OEM finalmente se verán obligados a tratar a los desarrolladores externos en pie de igualdad, sin importar cuán grandes o pequeñas sean sus aplicaciones. son.

Finalmente, Google también menciona cómo Android 11 ha "agregado medidas adicionales para prevenir comportamientos abusivos por parte de aplicaciones que se comportan mal", lo que hace que sea menos atractivo para los OEM eliminar agresivamente los procesos en segundo plano. Sin embargo, la empresa no dio más detalles sobre lo que implican estas "medidas adicionales".

Copias de seguridad mejoradas de dispositivo a dispositivo

El mes pasado, detectamos un cambio en la documentación de Android 11 que insinuó soporte para mejores copias de seguridad de datos locales. En Android 11, el sistema ignorará el atributo enableBackup Manifest para cualquier aplicación que tenga como objetivo el nivel de API 30 cuando el usuario inicie una migración de archivos de aplicación "de dispositivo a dispositivo". El Googler Eliot Stock afirma que esta función pretende hacer "mucho más fácil para los fabricantes de teléfonos crear herramientas de migración de dispositivo a dispositivo", como el "excelente producto Smart Switch de Samsung" para ayudar a "garantizar que las aplicaciones se transfieran de manera más confiable entre dispositivos desde la perspectiva del usuario". Lamentablemente, esto no se aplica a las copias de seguridad basadas en la nube, ya que Google quiere "dar a los desarrolladores de software control sobre lo que sucede con los datos de sus aplicaciones". Como tal, Android 11 seguirá respetando el atributo enableBackup para cualquier copia de seguridad y restauración basada en la nube, como a través del Google Drive integrado del servicio Google Play. respaldo. Por último, Google reconoce que el límite de respaldo de 25 MB por aplicación puede no ser suficiente para algunos desarrolladores, por lo que están buscando formas de resolverlo. Sin embargo, no se están considerando realizar copias de seguridad locales en una PC y Google reitera su plan para eliminar gradualmente la copia de seguridad adb en una futura versión de Android.

Se anima a los desarrolladores a implementar métodos de migración de datos sin fricciones. El nueva biblioteca Block Store, que forma parte de la biblioteca de servicios de identidad de Google, está diseñado para facilitar el inicio de sesión en aplicaciones restauradas. desde la nube en dispositivos nuevos, pero depende de los desarrolladores elegir si quieren implementar esto o no. biblioteca.

Velocidades de inicio de aplicaciones más rápidas con el proceso de lectura anticipada de E/S (IORap)

Google siempre está experimentando formas de mejorar el rendimiento en Android. Una de las características poco conocidas que agregaron en Android 10 se llama Grupo de procesos de aplicaciones no especializadas (USAP). Esta característica elimina la bifurcación de Zygote durante el proceso de inicio de la aplicación, lo que ahorra aproximadamente ~5 ms en la velocidad promedio de inicio de la aplicación en un dispositivo Pixel 2. La característica es actualmente deshabilitado por defecto en AOSP, y Google explica que su uso adicional de memoria aún necesita pruebas. Sin embargo, lo que es más interesante es una nueva característica que llegará a Android 11 llamada Proceso de lectura anticipada de E/S (IORap). Según Google, esta característica conducirá a "inicios en frío más de un 5% más rápidos y los casos de héroes alcanzarán un 20% más rápido". Esta característica "buscará previamente los artefactos de las aplicaciones (como código y recursos) durante el proceso de inicio" para impulsar el lanzamiento de la aplicación velocidades.

Google también ha "realizado mejoras en los perfiles utilizados para optimizar la ruta de clase de arranque y la imagen del sistema". lo que mejorará el rendimiento de la aplicación y reducirá el costo de memoria y almacenamiento asociado con el sistema artefactos. Estos cambios beneficiarán principalmente a los dispositivos con mayores cantidades de RAM, aunque Google no ha dicho cuál es el límite para ver los mayores beneficios.

Cambios en el almacenamiento con alcance de Android 11: ¿por qué está restringido el acceso a /Descargas?

Aplicaciones orientadas a Android 11 y utilizan la intención ACTION_OPEN_DOCUMENT_TREE para solicitar acceso a directorios específicos en el externo El almacenamiento ya no podrá solicitar a los usuarios acceso al directorio raíz del almacenamiento externo (/data/media/{user}), la opción Descargar directorio (/data/media{user}/Download), o cualquiera de los directorios de datos específicos de la aplicación en el almacenamiento externo (/Android/data o /Android/obb). ¿Por qué está restringido el acceso al directorio de descargas? Según Google Roxanna Aliabadi, es porque la carpeta de descargas "es la que tiene mayor riesgo de tener información privada". A modo de ejemplo, los usuarios que descargan su impuesto las devoluciones o los extractos bancarios no deberían tener que preocuparse por la posibilidad de que las aplicaciones abusen de su acceso de lectura continua al directorio. Google dice que el selector de documentos tendrá "texto actualizado... para indicar que Android ha restringido ciertas carpetas para ser seleccionado." Con suerte, esto reducirá la confusión sobre por qué no pueden otorgar acceso a las aplicaciones a ciertos directorios ya no.

Para obtener más información sobre los próximos cambios en las políticas de Scoped Storage y Play, consulte este artículo.

Temas varios

• La postura de Google sobre el rooting/modding
  • Jeff Bailey, del equipo AOSP de Google, reitera la postura de la empresa sobre el apoyo a las opciones. Google "continuará asegurándose de que sea posible modificar/rootear la línea de dispositivos Pixel", pero también "apoyará la elección de los OEM de no permitir que sus dispositivos ser rooteado". Además, Google está dando a los desarrolladores de software la opción de "no permitir que su software se ejecute en dispositivos rooteados", en referencia a cambios recientes en detección de manipulación de software de la API de certificación SafetyNet.
• ¿Qué pasó con "abrir y configurar como predeterminado"?
  • Android 10 hecho Es un poco molesto configurar una aplicación como controlador predeterminado. para enlaces específicos, lo que según Google se hizo para proteger a los usuarios de "aplicaciones explotadoras". Google dio marcha atrás sobre este cambio después de repensarlo, realizando una "serie de cambios detrás de escena" para proteger al usuario.
• ¿Utiliza la API de gráficos Vulkan para representar la interfaz de usuario?
  • Google eventualmente planea usar la API de gráficos Vulkan para representar la interfaz de usuario, lo que producirá algunas mejoras de rendimiento. Esto es todavía siendo evaluado, pero la empresa no tenía ningún detalle que compartir.
• Falta CallScreeningService en muchos dispositivos
  • Las aplicaciones de Android pueden implementar la API de servicio de detección de llamadas para interceptar nuevas llamadas entrantes y salientes, permitiéndoles identificar a la persona que llama y aceptar o rechazar la llamada. Aunque se trata de una API documentada oficialmente, aparentemente hay muchos OEM que no la implementan correctamente, según el desarrollador /u/_ceromod_. Google confirma que esta API está validada por Compatibility Test Suite (CTS), un conjunto de pruebas automatizadas que todos los dispositivos deben pasar para ser considerados compatibles con Android. Por alguna razón, esta API devuelve nulo cuando se llama a dispositivos de fabricantes de equipos originales como Huawei, Vivo, Xiaomi o Samsung, por lo que es probable que estos fabricantes de equipos originales tengan un error en su software.
• No hay planes para un marco de complementos de audio
  • Un desarrollador preguntó a Google si planea implementar un marco de complementos de audio como las Audio Units de Apple, pero la respuesta es que es poco probable que suceda en un futuro próximo.

Puedes leer todas las respuestas del equipo de ingeniería de Android. aquí. El equipo habla un poco sobre Java, Kotlin, el sistema de compilación de Android, la API CameraX y otros temas en algunos comentarios. También hay varios comentarios sobre Wear OS, Android TV y Android Auto, pero Google reitera principalmente su trabajo existente en estas plataformas y les dice a los desarrolladores que estén atentos para obtener más información durante el "Android más allá de los teléfonos"Semana que comienza el 10 de agosto.