Tres de las mejores funciones de Android 11 no aparecerán en todos los teléfonos inteligentes y tabletas. Esto se debe a que Google no exige estas funciones.
Cada año, Google lanza una nueva versión del sistema operativo Android. Google lanzó la primera vista previa para desarrolladores de Android 11 en febrero, seguida de la segunda, tercera y cuarta vistas previas para desarrolladores en los últimos meses. A principios de este mes, Google dio a conocer el primera versión beta de Android 11 y habló en profundidad sobre las mejores funciones para que las disfruten los usuarios y las implementen los desarrolladores. Sin embargo, ahora hemos aprendido que tres de las funciones principales de Android 11 no estarán disponibles en todos los dispositivos Android.
Para entender cómo es posible, tenemos que explicar brevemente cómo se distribuye el sistema operativo Android desde Google a los fabricantes de teléfonos inteligentes. Android es un sistema operativo de código abierto Con licencia Apache 2.0, lo que significa que cualquier persona, desde desarrolladores independientes hasta grandes empresas, es libre de modificar y distribuir el sistema operativo en sus propios dispositivos. La mayoría de las nuevas funciones del sistema operativo que Google presentó para Android 11 serán parte del Proyecto de código abierto de Android (AOSP) que el teléfono inteligente Los fabricantes de dispositivos basan su propio software, pero la licencia Apache 2.0, como mencioné antes, permite que cualquiera modifique el software como mejor le parezca. adaptar. Para mantener la coherencia en las API y el comportamiento de la plataforma entre dispositivos Android, Google agrupa la distribución de los servicios móviles de Google (que incluyen aplicaciones y marcos como Google Play Store y Google Play Services) con acuerdos de licencia que exigen que los dispositivos cumplan con las reglas de Google "
En el CDD, Google enumera las características de software y hardware que los fabricantes de dispositivos "DEBEN" implementar, que sólo son "MUY RECOMENDABLES" implementar o "NO DEBEN" implementar. Si una función aparece como "DEBE" implementarse, entonces el fabricante del dispositivo debe agregar esa función o no podrá enviar aplicaciones de Google a sus dispositivos. Si una función aparece como "NO DEBE" implementarse, entonces el fabricante del dispositivo no puede agregar esa función o no puede agrupar aplicaciones de Google. Finalmente, si una función aparece como "MUY RECOMENDADA", entonces depende del fabricante del dispositivo si desea implementarla o no. El CDD es un documento en constante cambio, incluso antes de su publicación cada año tras el lanzamiento público de una nueva versión de Android. Google actualiza con frecuencia el documento para eliminar funciones, cambiar el idioma para que sea más claro y flexibilizar los requisitos en función de los comentarios de sus socios. Sin embargo, una vez que Google haga público un CDD para una versión particular de Android, esos requisitos quedarán grabados en piedra para los dispositivos certificados por Google que ejecutan esa versión del sistema operativo Android.
El CDD de Android 11 no se hará público hasta finales de este año, probablemente a principios de septiembre. Sin embargo, desarrollador @eliminar paisaje compartió una copia preliminar de un documento que detalla los cambios que se producirán en el CDD, lo que nos brinda una visión temprana de cómo Google está dando forma a Android 11 en todo el ecosistema. La gran mayoría de los más de 60 cambios al CDD no son muy interesantes para los usuarios: describen cómo Los fabricantes de dispositivos tienen que implementar ciertas API, declarar ciertas características e implementar ciertos kernel. características. Sin embargo, 3 de los cambios en el CDD nos llamaron la atención porque se relacionan con algunas de las características más interesantes de Android 11. Esto es lo que descubrimos.
Controles del dispositivo
Controles de dispositivos es una función de Android 11 que permite que los controles de automatización del hogar inteligente se muestren en el menú de encendido. Puede apagar las luces, abrir la puerta del garaje, encender la aspiradora, cambiar la temperatura de su casa y hacer mucho más sin abrir una docena de aplicaciones diferentes para el hogar inteligente. Google agregó API que los desarrolladores de aplicaciones para el hogar inteligente pueden usar para mostrar controles en el menú de encendido. Creemos que esta es una característica interesante que Por fin lleva tu teléfono inteligente al hogar inteligente. Desafortunadamente, no existe ningún requisito para que los OEM lo implementen. Si un OEM piensa que la característica es poco convincente o quiere tomar una ruta diferente (como permitir solo controles domésticos desde dispositivos en su propio ecosistema), entonces simplemente pueden desactivar la compatibilidad con dispositivos Control S.
Cuando Google agregó por primera vez controles de dispositivos al CDD el 25 de febrero de 2020, exigió su inclusión agregando un requisito "DEBE" en la Sección 2.2.3: Requisitos de software portátil. Sin embargo, el 20 de mayo de 2020, Google actualizó el texto para eliminar el "DEBE" propuesto. La nueva Sección 3.8.16 - Controles de dispositivos describe cómo se debe implementar la función, ¡pero en realidad no requiere que se implemente en primer lugar! Esperamos que los OEM no deshabiliten esta ingeniosa característica, pero no hay forma de que sepamos si la han deshabilitado hasta que estén listos para presentar sus propias versiones de Android basadas en Android 11, lo que no sucederá hasta dentro de varios meses. ahora.
Sección propuesta 3.8.16 (nueva): controles de dispositivos (actualizado el 20/05/2020)
3.8.16 Controles del dispositivo
Android incluye ControlsProviderService y Control API para permitir a los desarrolladores publicar controles de dispositivos para obtener estados y acciones rápidas para los usuarios.
3.8.16.1 Asequibilidad del usuario de los controles del dispositivo
Si los dispositivos implementan controles de dispositivos, entonces:
- [C-1-1] DEBE informar que el indicador android.software.controls.feature es VERDADERO
- [C-1-2] DEBE proporcionar al usuario la posibilidad de agregar, editar, seleccionar y operar los favoritos del usuario desde los controles registrados por las aplicaciones de terceros a través de android.service.controls. ControlsProviderService y android.service.controls. Controlar las API.
- [C-1-3] DEBE proporcionar acceso a esta prestación de usuario dentro de tres interacciones desde el Iniciador
- [C-1-4] DEBE representar con precisión en esta opción de usuario el nombre y el ícono de cada aplicación de terceros que proporciona controles a través de android.service.controls. ControlsProviderService API, así como cualquier icono, texto de estado, tipo de dispositivo, nombre, estructura, zona, color personalizado y subtítulo especificados proporcionados por android.service.controls. API de control
Por el contrario, si las implementaciones de dispositivos no implementan dichos controles, entonces
- [C-2-1] DEBE informar Nulo para ControlsProviderService y las API de control.
leer más
Conversaciones en notificaciones
Una de las mayores ventajas de Android en comparación con iOS es cómo el primero maneja las notificaciones. Esa brecha en usabilidad se hará aún más amplia en Android 11 con la introducción de "Conversaciones". En Android 11, notificaciones de las aplicaciones de mensajería se agrupan y se muestran en una sección separada en el panel de notificaciones encima de la mayoría de las demás notificaciones. Esto le permite ver y responder mensajes rápidamente sin tener que desplazarse por todas las demás notificaciones pendientes. Desafortunadamente, es posible que este ingenioso cambio en las notificaciones no esté disponible en todos los dispositivos. Google ofrece a los OEM la opción de elegir si quieren "agrupar y mostrar notificaciones de conversación antes de notificaciones que no son de conversación". Los OEM personalizan con frecuencia el panel de notificaciones, por lo que no sorprende que Google les ofrezca a los OEM una elección aquí. Aún así, es lamentable que Google no elija imponer una mayor coherencia en las notificaciones en Android 11.
Cambios propuestos a la Sección 3.8.3.1 - Presentación de Notificaciones (Actualizado el 08/04/2020)
Si las implementaciones de dispositivos permiten que aplicaciones de terceros notifiquen a los usuarios sobre eventos importantes, estas:
...
Android R presenta compatibilidad con notificaciones de conversaciones, que son notificaciones que utilizan NotificationManager. MessageStyle y proporciona un ID de acceso directo de personas publicado.
Las implementaciones de dispositivos son:
- [H-SR] MUY RECOMENDABLE agrupar y mostrar notificaciones de conversación antes de las que no son conversaciones notificaciones con excepción de las notificaciones de servicio en primer plano en curso e importancia: alta notificaciones.
Si las notificaciones de conversación se agrupan en una sección separada, las implementaciones del dispositivo
- [H-1-8] DEBE mostrar las notificaciones de conversación antes que las notificaciones que no son de conversación, con la excepción de las notificaciones de servicio en primer plano en curso y de importancia: notificaciones altas.
Las implementaciones de dispositivos son:
- [H-SR] MUY RECOMENDABLE brindar acceso a las siguientes acciones desde las notificaciones de conversación: mostrar esta conversación como una burbuja si la aplicación proporciona los datos requeridos para las burbujas
La implementación de AOSP cumple con estos requisitos con la interfaz de usuario, la configuración y el iniciador del sistema predeterminados.
leer más
IdentityCredential - Licencias de conducir móviles
Finalmente, una de las características que más me entusiasma es la API IdentityCredential. Como detallamos el año pasado, la API IdentityCredential está diseñada para permitir que las aplicaciones almacenen documentos de identidad, como licencias de conducir móviles, en el dispositivo. Varios países (y algunos estados de EE. UU.) alrededor del mundo ya permiten a sus ciudadanos almacenar sus licencias de conducir en una aplicación móvil. Sin embargo, Google está trabajando para hacer esto más seguro al almacenar los datos sin conexión en un entorno seguro.
El código fuente de Android 11 incluye la API IdentityCredential (a la que los desarrolladores llamarán para almacenar documentos de identidad en la memoria del teléfono). entorno seguro) y IdentityCredential HAL (que interactúa con el entorno seguro del teléfono), pero los OEM no están obligados a implementarlos. Cuando Google propuso por primera vez la inclusión de IdentityCredential en el CDD el 10 de enero de 2020, lo incluyeron como un requisito. Sin embargo, relajaron este requisito el 18 de marzo de 2020 y ahora solo recomiendan encarecidamente que los OEM admitan esta función. No nos sorprende que Google haya relajado este requisito: agregar un cambio que afecte el entorno de ejecución confiable requerirá un esfuerzo por parte de los OEM para implementarlo. Es posible que los OEM simplemente necesiten más tiempo para prepararse para este cambio. Sin embargo, para los usuarios, eso significa que no hay garantía de que su teléfono inteligente con Android 11 en particular admita el almacenamiento seguro de una licencia de conducir móvil en el entorno seguro del teléfono.
Debemos tener en cuenta que no existe ninguna limitación técnica que impida la adopción generalizada del sistema IdentityCredential entre los dispositivos con Android 11. Uno de los requisitos para implementar el sistema IdentityCredential es que el dispositivo tenga un Trusted Execution Entorno (TEE) o un procesador seguro dedicado en el que una "aplicación confiable" interactúa con la identidad almacenada documentos. Desde Android 7.0 Nougat, Google ha requerido que todos los dispositivos Android modernos admitan un "entorno de ejecución aislado" (según Sección 2.2.5 - Modelo de Seguridad en el DDC). Los dispositivos con procesadores ARM normalmente cuentan con ARM Zona de confianza TEE y Google proporciona la SO confiable que se ejecuta en TrustZone. La presencia de un TEE es suficiente para admitir el sistema IdentityCredential, aunque sería más seguro si las credenciales se almacenaran en una CPU segura integrada (como en el Unidad de procesamiento seguro de algunos procesadores Qualcomm Snapdragon) o una CPU segura discreta (como en Titán M de Google o Los nuevos chips de seguridad de Samsung). En particular, los dispositivos con CPU seguras discretas también pueden admitir la función "modo de acceso directo" del sistema IdentityCredential. lo que permitirá al usuario obtener su documento de identidad incluso cuando no quede suficiente energía en el dispositivo para iniciar el sistema operativo principal.
Sección propuesta 9.11.3 (nueva) - Credencial de identidad (actualizado el 18/03/2020)
El sistema de credenciales de identidad permite a los desarrolladores de aplicaciones almacenar y recuperar documentos de identidad de los usuarios.
Implementaciones de dispositivos:
- Se RECOMIENDA ENCARECIDAMENTE a los [C-SR] implementar el Sistema de Credenciales de Identidad.
Si las implementaciones de dispositivos implementan el sistema de credenciales de identidad:
- [C-0-1] DEBE devolver un valor no nulo para el IdentityCredentialStore#getInstancia() método.
- [C-0-2] DEBE implementar las API `android.security.identity.*` con código que se comunica con un proveedor confiable Aplicación que se ejecuta en un entorno de ejecución confiable (TEE) o en un entorno seguro dedicado. procesador. La aplicación confiable debe implementarse de manera que el Base informática confiable para el Sistema de Credenciales de Identidad no incluye el Sistema Operativo Android.
leer más
Google también está trabajando en una biblioteca IdentityCredential Jetpack para facilitar a los desarrolladores agregar soporte para almacenar identidades de forma segura. documentos en Android, pero el verdadero desafío será lograr que los gobiernos autoricen aplicaciones que utilicen esta API para almacenar de forma segura identificaciones gubernamentales. De acuerdo a Engadget, Corea del Sur acaba de implementar soporte para almacenar licencias de conducir en una aplicación móvil, por lo que estamos comenzando a ver un aumento en la aceptación de esta tecnología. Yo, por mi parte, estoy emocionado de ver a dónde va esto porque significará una cosa menos que llevar conmigo cuando salga.
El documento que obtuvimos enumeró los cambios en el CDD en la fecha en que se realizaron esos cambios. Los últimos cambios se realizaron el 10 de junio de 2020, lo que significa que el documento que tenemos está bastante actualizado. Es posible que Google pueda incumplir estos cambios y volver a imponer todos los requisitos antes del lanzamiento público de Android 11, pero dudamos que Google haga de repente el CDD. más riguroso. Es probable que estos cambios se hayan relajado debido a los comentarios de los OEM, quienes son los que tendrán que regresar e implementar estas características si aún no estaban planeados hacerlo. Eso requiere tiempo, esfuerzo y dinero, lo que retrasaría aún más el lanzamiento de Android 11 para dispositivos que no sean de Google. Aún así, si Google vuelve a exigir estas funciones, publicaremos una actualización en el Portal XDA.