Google Android App Functions construyó una jaula de seguridad, pero la mayoría de los agentes de IA sigue fuera
Google ha creado para los agentes de Android una ruta controlada hacia otras aplicaciones, pero la mayoría de los usuarios aún no puede ver, gestionar ni utilizar de forma significativa esa vía. Google Android App Functions define ahora cómo los asistentes autorizados pueden descubrir y ejecutar acciones específicas entre aplicaciones. La tensión radica en que la arquitectura de seguridad ha llegado antes que un ecosistema amplio de agentes.
Esto es más que otra función inacabada de Android. Google está decidiendo quién puede actuar dentro de las aplicaciones, qué pueden descubrir esos actores y qué operaciones exponen los desarrolladores. Esas decisiones establecen el plano de control para futuros agentes que creen notas, encuentren fotos, inicien contenido multimedia o preparen carritos de compra.
También diferencian el enfoque de Google de los agentes que operan teléfonos interpretando pantallas e imitando toques. Los sistemas que controlan pantallas pueden funcionar sin una integración profunda con las aplicaciones, pero siguen siendo sensibles a cambios de diseño y contenido engañoso. App Functions ofrece una vía más limpia, aunque solo los agentes autorizados y las aplicaciones participantes pueden utilizarla.
Google ya ha demostrado integraciones limitadas, entre ellas Gemini recuperando fotos a través de Samsung Gallery. Android 17 amplía aún más el marco. Aun así, un propietario típico de Android no encontrará un panel universal de agentes lleno de asistentes de terceros y acciones compatibles.
Esa brecha explica la aparente contradicción. La jaula no está literalmente vacía, pero su población sigue siendo reducida, controlada y difícil de inspeccionar para los usuarios comunes. Google ha asegurado la entrada antes de abrir el mercado a su alrededor.
Google Android App Functions cambió la forma en que los agentes entran en las aplicaciones
App Functions sustituye el control simulado de pantallas por operaciones declaradas y estructuradas que Android puede identificar y restringir.
Una función de aplicación es una acción discreta que una aplicación pone a disposición de un solicitante autorizado. Una aplicación de notas podría exponer “crear nota”, mientras que una aplicación multimedia podría exponer “reproducir canción”. El agente envía parámetros estructurados en lugar de navegar por la interfaz visible de la aplicación.
El marco oficial de App Functions describe dos partes. Una aplicación proveedora declara una acción, y un agente de confianza la descubre y ejecuta. Android media el intercambio mediante AppFunctionManager y servicios relacionados.
Esta arquitectura importa porque una interfaz visual fue diseñada para el juicio humano. Una persona detecta que un botón se movió, que un destinatario parece incorrecto o que el total de una compra cambió. Un sistema automatizado puede continuar después de interpretar mal la pantalla o seguir instrucciones hostiles incrustadas en el contenido mostrado.
Las funciones estructuradas acotan la acción disponible. El agente no recibe control ilimitado simplemente porque pueda pedir a una aplicación que realice una operación. El proveedor define la función, sus entradas y el resultado que devuelve.
Android también registra si una función está habilitada. Una solicitud de ejecución puede fallar si la función no existe, no se encuentra o no está disponible. Esto establece un límite más claro que conceder a un agente acceso general a la interfaz de la aplicación.
El marco llegó a la plataforma en el nivel de API 36, la versión asociada con Android 16. La documentación de Google sigue describiendo App Functions como una vista previa beta o experimental. Android 17 añade registro en tiempo de ejecución, funciones vinculadas a actividades, niveles de acceso actualizados y controles de descubrimiento más detallados.
Estos cambios muestran que Google trata la capacidad de los agentes para actuar entre aplicaciones como una cuestión del sistema operativo. No deja que cada desarrollador de asistentes invente una capa de integración privada. La plataforma proporciona identificadores comunes, metadatos, gestión de estado, solicitudes, respuestas y comprobaciones de permisos.
La distinción se aprecia mejor en un escenario sencillo de toma de notas. Un agente recibe la instrucción: “Guarda la dirección del hotel en mis notas de viaje”. Busca una función compatible, identifica la aplicación de destino, proporciona el título y el contenido, y recibe un resultado.
En cambio, un agente que controla pantallas abriría la aplicación, localizaría un botón, elegiría un cuaderno, enfocaría un campo de texto, introduciría el contenido y pulsaría guardar. Cada transición visual añade otro punto donde la ambigüedad o la manipulación pueden entrar en la secuencia.
App Functions no garantiza que un agente haya entendido la solicitud original. Tampoco demuestra que una aplicación haya implementado su acción de forma segura. Reduce la superficie de exposición al sustituir un recorrido abierto por una interfaz por una operación que los desarrolladores declararon explícitamente.
Ese es el primer cambio importante. Android ahora tiene un vocabulario nativo para que los agentes actúen dentro de las aplicaciones, en lugar de limitarse a hablar sobre ellas o iniciar sus pantallas.
El segundo cambio es menos visible. Android sitúa la ejecución entre aplicaciones detrás de permisos que las aplicaciones ordinarias no pueden simplemente asumir. Esa decisión convierte App Functions de una API de conveniencia en un sistema de control de acceso.
El modelo de permisos pone el control en manos de Google y los fabricantes de dispositivos
La ventaja de seguridad proviene de limitar a los solicitantes capaces, pero esa misma restricción mantiene a los agentes independientes de Android fuera de la puerta.
Una aplicación puede ejecutar sus propias funciones sin autoridad especial. La ejecución entre paquetes es distinta. AppFunctionManager exige que el agente solicitante tenga un permiso de Android autorizado para descubrir o ejecutar funciones en otras aplicaciones.
El trabajo original del marco de Android asignó EXECUTE_APP_FUNCTIONS a aplicaciones preinstaladas o del sistema que tuvieran el rol de asistente. Un permiso de confianza relacionado servía a componentes de inteligencia del sistema estrictamente controlados. El historial de permisos muestra hasta qué punto Android vinculó explícitamente la ejecución de agentes a roles privilegiados.
El marco actual evoluciona hacia niveles de acceso más granulares. Los desarrolladores pueden marcar funciones para la propia aplicación, para solicitantes del sistema o para solicitantes certificados por Android. Sin embargo, la certificación no equivale a un permiso ordinario en tiempo de ejecución que cualquier asistente descargado recibe tras mostrar una solicitud.
Esta distinción explica por qué la función parece ausente en un teléfono normal. Los usuarios están acostumbrados a aprobar acceso a la cámara, el micrófono, los contactos y la ubicación. No necesariamente pueden instalar un asistente cualquiera y concederle una autoridad amplia sobre App Functions desde una pantalla de configuración estándar.
Google está evitando una peligrosa carrera hacia el mínimo común denominador. Si cualquier aplicación pudiera llamar a cada función expuesta tras una vaga solicitud de consentimiento, los asistentes agresivos buscarían una autoridad amplia. Los usuarios podrían aprobarla sin comprender cuántas acciones importantes pasan a estar disponibles.
Los agentes entre aplicaciones conllevan un riesgo distinto al de los chatbots pasivos. Una respuesta equivocada es inconveniente. Una acción equivocada puede enviar un mensaje a la persona incorrecta, divulgar un documento privado, modificar un registro o iniciar una transacción.
La inyección de prompts hace esta distinción aún más marcada. Un agente puede encontrarse con texto diseñado para anular la intención del usuario mientras lee una página web, un mensaje, un documento o una imagen. Una reciente investigación sobre agentes móviles examina específicamente cómo los agentes de Android basados en accesibilidad pueden quedar expuestos a la inyección indirecta de prompts.
Un límite de permisos no puede volver al modelo inmune a la manipulación. Puede restringir qué aplicaciones actúan como agentes y a qué funciones acceden esos agentes. También ofrece a las aplicaciones proveedoras una ruta de ejecución definida en la que pueden validar argumentos y aplicar sus propias comprobaciones.
Sin embargo, el control centralizado crea otro problema. Google y los fabricantes de dispositivos Android se convierten en los árbitros prácticos de qué asistentes reciben acceso de primera clase. Un agente independiente puede desarrollar un sofisticado planificador y aun así carecer de permiso para coordinar aplicaciones de terceros mediante el marco oficial.
Esa presión recae sobre tres grupos.
Primero, los desarrolladores de asistentes deben cumplir los requisitos de la vía de confianza de Android o recurrir a técnicas menos directas. Pueden usar enlaces profundos hacia aplicaciones, intents existentes, operar mediante servicios de accesibilidad o simular interacciones con herramientas de desarrollo. Ninguna ofrece el mismo acceso estandarizado.
Segundo, los desarrolladores de aplicaciones deben decidir qué funciones merece la pena exponer. Cada función exige implementación, pruebas, validación de entradas, gestión del ciclo de vida y trabajo de compatibilidad. Un equipo pequeño puede dudar hasta que suficientes usuarios dispongan de un agente que pueda llamar a esas funciones.
Tercero, los usuarios deben confiar en ambas partes de la transacción. Necesitan tener la certeza de que el asistente interpretó correctamente la solicitud y de que la aplicación proveedora no ejecutará una operación inesperadamente amplia.
Esto produce un conocido problema de arranque en frío de plataforma. Los agentes necesitan funciones útiles antes de atraer uso. Los desarrolladores de aplicaciones necesitan agentes activos antes de que la integración justifique tiempo de ingeniería. Google puede romper el ciclo con Gemini y socios destacados, pero los participantes independientes siguen dependiendo de sus políticas de acceso.
Por tanto, el diseño es a la vez una jaula de seguridad y una puerta de distribución. Restringir la ejecución reduce el abuso inmediato, mientras que la certificación y los privilegios de plataforma determinan quién puede crear una automatización significativa en Android.
El diseño de Google que prioriza la seguridad choca con un problema de adopción
La disyuntiva central es simple: un control más estricto hace que los agentes de Android sean más seguros de desplegar, mientras que un acceso más lento hace que el marco sea menos útil hoy.
Google llevó públicamente App Functions más allá de referencias oscuras de API en febrero de 2026. Su equipo de desarrolladores de Android calificó las capacidades como tempranas y describió la privacidad y la seguridad como prioridades fundamentales del diseño.
La empresa también presentó un despliegue concreto. Gemini podía interpretar una solicitud, activar una App Function en Samsung Gallery y devolver fotos seleccionadas dentro de la interfaz de Gemini. Según la integración de Samsung, esa experiencia comenzó en la serie Galaxy S26, con planes de expansión a más dispositivos Samsung.
Ese ejemplo demuestra que el marco no es una carcasa de código vacía. También revela lo limitado que sigue siendo el lanzamiento. La demostración involucra al asistente de Google, a un importante fabricante de Android, una aplicación de galería propia y dispositivos seleccionados.
Un ecosistema amplio tendría otro aspecto. Los usuarios podrían elegir entre agentes cualificados. Miles de aplicaciones expondrían operaciones documentadas. Android mostraría qué agente llamó a qué función, qué datos se movieron y qué acciones requieren confirmación.
El marco existente proporciona varias piezas de ese futuro, pero no toda su experiencia pública. Los desarrolladores pueden definir metadatos, publicar funciones, observar el estado y procesar solicitudes de ejecución. Android 17 también introduce un registro más dinámico y comportamientos específicos de cada actividad.
La actualización de Android 17 de Google incluye una aplicación de agente de prueba y comandos ADB para desarrollo. ADB, o Android Debug Bridge, es una interfaz para desarrolladores que permite controlar e inspeccionar dispositivos. Estas herramientas ayudan a los programadores a validar funciones antes de que los agentes de consumo las admitan de forma generalizada.
El soporte para pruebas es necesario, pero no equivale a adopción. Un desarrollador puede demostrar que “crear nota” devuelve la respuesta esperada sin saber cuántos asistentes reales la invocarán. Una función compatible puede permanecer inactiva en millones de dispositivos.
El marco también necesita esquemas compartidos. Dos aplicaciones para tomar notas pueden exponer acciones similares con nombres, argumentos y formatos de resultado distintos. Si cada proveedor inventa su propio contrato, los agentes deben comprender una colección creciente de interfaces propietarias.
Los esquemas estándar permiten que los agentes busquen por capacidad en lugar de memorizar cada aplicación. El modelo de metadatos de Android admite información de esquemas, pero una interoperabilidad útil sigue dependiendo de que los desarrolladores converjan en definiciones coherentes.
El control del usuario presenta otra capa sin resolver. Una aplicación puede mantener el estado habilitado de sus funciones, y los metadatos más recientes pueden expresar distintos niveles de acceso. Sin embargo, los usuarios comunes necesitan un modelo comprensible que responda preguntas prácticas.
¿Puede Gemini crear notas pero no eliminarlas? ¿Puede otro agente certificado buscar fotos sin compartirlas externamente? ¿La aprobación se aplica una vez, por aplicación, por función o por cada solicitud sensible? ¿Puede un usuario revisar el historial de acciones después de que algo salga mal?
Google debe equilibrar estos controles frente a la fricción. Confirmar cada acción inocua anula la comodidad de un agente. Aprobar categorías amplias puede ocultar riesgos. Un sistema útil necesita que las operaciones rutinarias avancen con rapidez mientras se detiene ante pasos irreversibles o sensibles.
Este problema se parece al diseño de permisos, pero la intención del agente cambia durante una tarea. Un permiso de cámara concede acceso a un sensor conocido. Un agente puede empezar leyendo una lista, inferir varias subtareas, consultar múltiples aplicaciones y proponer una compra. El límite trascendental aparece a mitad del flujo de trabajo.
Eso hace que la política sea más importante que un único permiso. Android debe combinar la identidad del solicitante, el alcance de la función, las reglas del proveedor, las preferencias del usuario, la sensibilidad de la transacción y el contexto actual.
La metáfora de la jaula solo captura una parte de este diseño. Android no está aislando un proceso no confiable dentro de una caja. Está coordinando solicitantes confiables a través de puertas estrechamente expuestas, y cada aplicación conserva la responsabilidad de lo que ocurre tras su puerta.
Para los desarrolladores, el cálculo inmediato sigue siendo incierto. Dar soporte a Google Android App Functions otorga a una aplicación un lugar en los futuros flujos de trabajo de agentes. También implica invertir en una interfaz beta cuya distribución, certificación y demanda de los usuarios aún están evolucionando.
Los agentes que controlan pantallas se lanzan más rápido y son más difíciles de confiar
El principal rival de Google no es otra plataforma móvil; es el atajo de permitir que los agentes operen pantallas como lo hacen las personas.
Un agente que controla pantallas puede comenzar con menos alianzas. Lee píxeles o un árbol de accesibilidad, decide dónde interactuar y genera toques, deslizamientos y entrada de texto. Si una persona puede completar una tarea a través de la interfaz, el agente puede intentar la misma ruta.
Esa generalidad resulta atractiva. Los desarrolladores no necesitan que cada aplicación objetivo publique una función. Los investigadores pueden probar agentes en software existente, y las startups pueden demostrar una cobertura amplia antes de negociar integraciones.
La propia investigación de Google sobre Android ayudó a establecer este enfoque. El conjunto de datos Android in the Wild contiene 715.000 episodios que cubren 30.000 instrucciones en múltiples versiones de Android y tipos de dispositivos. Refleja la escala necesaria para entrenar o evaluar sistemas que actúan a través de interfaces variadas.
Sin embargo, el control visual amplio sustituye contratos explícitos por inferencia. El agente debe determinar qué significa cada pantalla, si el contenido es confiable y si una interacción produjo el resultado previsto.
La etiqueta de un botón puede cambiar tras una actualización de la aplicación. Un cuadro de diálogo puede cubrir el objetivo esperado. Una página maliciosa puede colocar instrucciones donde el modelo las leerá. Un flujo de pago puede añadir una comisión o cambiar un artículo antes de la confirmación final.
Las personas también cometen errores en estas situaciones, pero los agentes pueden repetirlos más rápido y a mayor escala. Pueden operar en segundo plano, continuar entre aplicaciones y manejar información que el usuario nunca revisa directamente.
App Functions traslada la interpretación a una capa distinta. El agente sigue interpretando la solicitud del usuario, pero no necesita inferir la mecánica de cada pantalla. Elige una operación declarada y proporciona información tipada.
Esto se parece a la diferencia entre utilizar una interfaz de programación de aplicaciones y automatizar un sitio web a través de un navegador. Las API suelen ofrecer mayor estabilidad y entradas más claras. La automatización del navegador llega a servicios sin API, pero debe gestionar cambios de diseño, sesión y contenido.
La ruta estructurada también mejora la rendición de cuentas. Android puede identificar el paquete que realiza la llamada, la función objetivo, la solicitud y el resultado. Las aplicaciones proveedoras pueden rechazar argumentos inválidos o exigir su propia confirmación. La política de la plataforma puede tratar las funciones sensibles de forma distinta a las ordinarias.
Nada de esto elimina la necesidad de defensas a nivel de modelo. Un agente comprometido puede llamar a una función permitida por la razón equivocada. Un proveedor descuidado puede exponer una operación con validación débil. Un solicitante confiable todavía puede malinterpretar instrucciones ambiguas.
Las operaciones estructuradas también pueden hacer que las acciones dañinas sean más fiables. Un agente malicioso que llega a una función de «enviar pago» no necesita navegar por una interfaz confusa. El valor de seguridad depende de limitar el acceso, verificar la intención y exigir confirmación en el momento adecuado.
Por eso, abrir EXECUTE_APP_FUNCTIONS de forma demasiado amplia eliminaría gran parte del beneficio arquitectónico. Google no puede simplemente incluir el permiso en un diálogo estándar y dar el problema por resuelto. La plataforma necesita reglas de calificación y un comportamiento observable que los usuarios puedan comprender.
Al mismo tiempo, mantener el acceso limitado crea presión para utilizar automatización de pantalla. Los asistentes independientes seguirán la ruta que les permita lanzar su producto. Si la puerta oficial sigue inaccesible, algunos desarrolladores volverán a los servicios de accesibilidad, las herramientas basadas en ADB o la automatización de dispositivos.
El resultado es una paradoja de política. Google quiere que los agentes utilicen la ruta estructurada más segura, pero debe hacer que esa ruta sea suficientemente accesible como para desplazar alternativas más arriesgadas.
Los competidores y los proyectos de código abierto pueden aprovechar esa brecha ofreciendo agentes que parecen más capaces en aplicaciones existentes. Sus demostraciones pueden cubrir más tareas porque no esperan la integración del proveedor. El sistema de Google puede parecer limitado precisamente porque impone límites.
Los consumidores no evaluarán estas arquitecturas mediante documentación de API. Notarán si un agente puede completar una solicitud. Si un rival que controla pantallas maneja diez aplicaciones mientras la ruta estructurada de Gemini admite dos, la capacidad puede pesar más que la seguridad abstracta en la decisión de compra.
Los desarrolladores afrontan la misma tensión al diseñar flujos de trabajo de IA. La automatización fiable depende de entradas predecibles, acciones controladas y puntos de revisión visibles. El control general de interfaces ofrece alcance, mientras que las funciones estructuradas ofrecen garantías más claras.
Google debe cerrar esa brecha de capacidad sin convertir los agentes de Android en controles remotos sin restricciones. App Functions proporciona el mecanismo, pero la adopción y la política de acceso determinan si los desarrolladores realmente lo utilizan.
La verdadera prueba es si la jaula se convierte en un mercado
La próxima fase depende de la participación de las aplicaciones, el acceso de los agentes y el control visible para los usuarios, no de más clases del marco.
La primera señal que hay que observar es el número y la variedad de aplicaciones de producción que exponen App Functions. Samsung Gallery es una demostración útil porque la recuperación de fotos implica datos personales y una tarea reconocible para el usuario. No establece un soporte amplio en comunicación, productividad, finanzas, compras, viajes y medios.
Las aplicaciones principales deben exponer más que acciones promocionales de demostración. Los flujos de trabajo prácticos y repetidos mostrarán si el marco ahorra a los usuarios un esfuerzo significativo. Crear una nota, localizar una foto específica, iniciar una lista de reproducción y añadir artículos a un carrito son pruebas iniciales.
La adopción refuerza el enfoque de Google si varios desarrolladores de aplicaciones independientes anuncian integraciones funcionales. Debilita el argumento si el soporte sigue concentrado entre el software de Google, las aplicaciones de fabricantes de dispositivos y socios de lanzamiento seleccionados.
La segunda señal es el acceso para agentes ajenos a Google. Los metadatos más recientes de Android hacen referencia a solicitantes certificados por Android, lo que sugiere una vía más amplia que un único asistente propio. La pregunta decisiva es qué requiere la certificación y si los agentes externos cualificados pueden competir en condiciones razonables.
Un programa creíble necesita criterios publicados, obligaciones de seguridad, procedimientos de revocación y una revisión predecible. Los desarrolladores deberían saber cómo un agente obtiene acceso y qué comportamiento hace que lo pierda.
Sin esos detalles, el sistema de permisos corre el riesgo de convertirse en una ventaja privada de distribución para Gemini. Google puede argumentar que el acceso estricto protege a los usuarios, mientras que los rivales pueden sostener que las mismas reglas protegen la posición de Google como agente predeterminado de Android.
La evidencia de múltiples agentes certificados reforzaría la interpretación de seguridad ante todo. La exclusividad persistente para la primera parte reforzaría la interpretación de control de acceso. La legitimidad del marco depende de distinguir los requisitos de confianza del acceso preferencial.
La tercera señal es una experiencia de control y auditoría orientada al usuario. El despliegue más amplio de Gemini Intelligence de Google promete automatización proactiva en teléfonos y otros dispositivos. Una mayor acción en segundo plano hace que la visibilidad sea cada vez más importante.
Los usuarios necesitan ver qué funciones existen, qué agentes pueden llamarlas y qué permisos permanecen activos. También necesitan un historial que explique qué solicitó un agente y qué devolvió cada aplicación.
Una superficie de control útil debería separar la comodidad de bajo riesgo de la autoridad con consecuencias. Reproducir una canción no merece la misma fricción que enviar un mensaje o realizar un pedido. La plataforma debería comunicar esa diferencia antes de que ocurra un error.
El diseño de las confirmaciones será la parte más difícil. Demasiados avisos acostumbran a los usuarios a aprobarlo todo. Demasiados pocos dejan a los usuarios sorprendidos por acciones que no pretendían realizar. Las aprobaciones contextuales deben seguir siendo claras sin convertir cada flujo de trabajo en una secuencia de interrupciones.
Google también debería explicar dónde ocurre el procesamiento. Algunas funciones pueden ejecutarse sobre el estado local de la aplicación, mientras que el razonamiento del asistente puede involucrar servicios en la nube. Los usuarios necesitan entender cuándo sus datos salen del dispositivo y qué parte los recibe.
Los controles de estado del marco podrían admitir la revocación de emergencia. Si un agente se comporta de forma inesperada, los usuarios deberían poder desactivar su autoridad entre aplicaciones sin tener que buscar en cada aplicación individual. Las aplicaciones proveedoras también deberían poder suspender rápidamente las funciones sensibles.
Los desarrolladores también buscarán herramientas operativas. Necesitan registros de llamadas fallidas, validación de esquemas, pruebas de compatibilidad, notificación de abusos y un comportamiento claro entre versiones de Android. Un marco se convierte en un ecosistema solo cuando los equipos pueden darle soporte en producción.
El despliegue gradual de Google es defendible. Lanzar una capacidad de agencia entre aplicaciones sin restricciones antes de que existan los controles invitaría a fallos previsibles. En cambio, la empresa ha creado comprobaciones de permisos, contratos de proveedores, herramientas de prueba y API de plataforma en expansión antes de habilitar el acceso universal.
La visión escéptica es igualmente defendible. Un marco seguro con pocas funciones invocables no aporta mucho valor al consumidor. Una ruta estrictamente controlada también puede empujar a los desarrolladores independientes hacia la misma automatización de pantalla que el marco fue diseñado para sustituir.
Por tanto, las Google Android App Functions se sitúan en una transición importante, pero incompleta. Android cuenta ahora con un mecanismo nativo para que los agentes descubran y ejecuten operaciones acotadas. La plataforma aún no ha demostrado que este mecanismo pueda sostener un mercado de agentes abierto, competitivo y ampliamente adoptado.
Durante los próximos meses, habrá que observar integraciones en producción más allá de los socios de lanzamiento, reglas de acceso publicadas para agentes externos y un historial de permisos visible para los usuarios. En conjunto, esas señales revelarán si Google ha creado infraestructura compartida o un carril protegido para Gemini.
Para los propietarios de dispositivos Android, la cuestión práctica no es si un agente de IA puede tocar una pantalla. Los sistemas experimentales ya han demostrado que puede hacerlo. La pregunta es si Android puede permitir que los agentes actúen en aplicaciones personales sin exigir a los usuarios que renuncien a un control significativo.
Para los desarrolladores, la decisión llega antes. Deben identificar operaciones seguras y útiles que merezcan una exposición estructurada y definir dónde debe intervenir la confirmación. Esperar evita trabajo a corto plazo, pero puede dejar a una aplicación invisible cuando los usuarios empiecen a delegar tareas en lugar de abrir interfaces.
Google ha construido la puerta e instalado la cerradura. Ahora debe demostrar que los agentes de confianza, los desarrolladores independientes y los usuarios corrientes pueden recibir las llaves adecuadas.
