Google ha decidido poner orden en uno de los vectores de ataque más explotados del ecosistema Android. La compañía está probando, como parte de Android 17 Beta 2, una restricción que impide que determinadas aplicaciones accedan a la API de servicios de accesibilidad. El cambio, reportado inicialmente por Android Authority, representa un giro significativo en la política de seguridad del gigante tecnológico.

La medida se enmarca dentro del Android Advanced Protection Mode (AAPM), un modo de protección reforzada que Google introdujo en Android 16 el año pasado. Cuando el usuario activa esta funcionalidad, el dispositivo entra en un estado de seguridad elevada con múltiples capas de defensa adicionales. Ahora, en Android 17, esa protección se extiende al control estricto de quién puede y quién no puede utilizar los servicios de accesibilidad.

¿Por qué la API de accesibilidad es tan sensible? En teoría, estos servicios están diseñados para ayudar a personas con discapacidades: lectores de pantalla como TalkBack, navegación por voz, ampliadores de pantalla. Sin embargo, la API otorga permisos extraordinarios: puede leer todo lo que aparece en pantalla, simular toques, interceptar pulsaciones de teclas y controlar prácticamente cualquier interacción del usuario. Eso la convierte en un objetivo privilegiado para los creadores de malware.

De hecho, durante años, los investigadores de ciberseguridad han documentado cómo familias de malware como Anatsa, Cerberus o Flubot han abusado sistemáticamente de estos permisos. Un atacante convence al usuario de activar los servicios de accesibilidad para su app maliciosa —a menudo disfrazada de herramienta legítima— y a partir de ese momento tiene acceso total al dispositivo: puede leer contraseñas bancarias, confirmar transacciones no autorizadas, interceptar códigos de verificación y desactivar otras medidas de seguridad.

La solución de Google es radical pero lógica: si una aplicación no es un servicio de accesibilidad reconocido, simplemente no podrá solicitar estos permisos bajo el AAPM. Esto elimina de raíz la ingeniería social que permite a los atacantes convencer a los usuarios de conceder privilegios peligrosos. La superficie de ataque se reduce drásticamente.

No obstante, la medida no está exenta de debate. La comunidad de desarrolladores de apps de automatización y herramientas de productividad —como Tasker, MacroDroid o ciertas apps de control remoto— ha utilizado históricamente la API de accesibilidad para funciones legítimas que van más allá de la accesibilidad. Estos desarrolladores podrían verse afectados si sus aplicaciones no cumplen con los criterios de Google para ser clasificadas como servicios de accesibilidad válidos.

Para el usuario promedio, el cambio será prácticamente invisible. Google ha optado por integrar esta protección dentro de un modo opcional avanzado, lo que sugiere que no pretende imponer la restricción a todo el ecosistema de inmediato. Es una estrategia prudente: permite evaluar el impacto real antes de una posible implementación generalizada en futuras versiones.

Lo que resulta innegable es la dirección hacia donde se mueve la industria. Apple lleva años con un modelo más cerrado donde este tipo de abusos son prácticamente inexistentes. Google, consciente de que la apertura de Android es tanto su mayor fortaleza como su mayor vulnerabilidad, avanza gradualmente hacia un equilibrio donde la libertad del ecosistema no comprometa la seguridad del usuario.

Android 17 Beta 2 es, por ahora, una versión en pruebas, y las características pueden cambiar antes del lanzamiento estable. Pero el mensaje de Google es claro: la era de tolerar el abuso de APIs críticas está llegando a su fin. Para profesionales del sector hispanohablante, esto representa tanto una oportunidad —apps más seguras generan mayor confianza— como un desafío técnico que requerirá adaptación en el desarrollo de aplicaciones que dependan de estos permisos.