- Android 17 incorporará un bloqueo nativo de aplicaciones individuales mediante la nueva API LOCK_APPS integrada en el sistema.
- La función se apoyará en la autenticación biométrica y el PIN, sin recurrir a apps de terceros ni a permisos de accesibilidad invasivos.
- Este App Lock nativo complementará al Espacio Privado y unificará las soluciones de bloqueo entre distintos fabricantes y launchers.
- Su llegada prevista con Android 17 reforzará la privacidad diaria de los usuarios, especialmente en móviles con Android «limpio».
La privacidad en el móvil se ha convertido en un tema delicado para cualquiera que lleve el teléfono siempre encima: mezclamos apps del banco, correo del trabajo, historiales médicos y fotos personales en el mismo dispositivo, y cada vez que lo dejamos a otra persona siempre aparece la misma duda de fondo: qué podrá abrir y qué preferirías que permaneciera cerrado a cal y canto, además de otras medidas de privacidad como desactivar el rastreo de ubicación.
Durante años, en Android la solución ha sido una especie de «patchwork» de apps de bloqueo de terceros, trucos de fabricantes y funciones poco intuitivas como el Espacio Privado. Mientras tanto, muchos usuarios miraban con algo de envidia a quien podía bloquear WhatsApp o la Galería con la huella de forma directa desde el sistema. Con Android 17, todo apunta a que Google por fin va a meter mano en serio al problema con un bloqueo nativo de aplicaciones individuales integrado en el propio sistema.
Qué es el bloqueo nativo de apps que prepara Android 17
Las primeras pistas de esta función vienen del análisis de versiones Canary de Android, compilaciones de prueba muy tempranas donde Google va introduciendo novedades del sistema antes de que lleguen a las betas públicas. En ese código se han localizado referencias claras a un nuevo mecanismo de bloqueo de aplicaciones que no depende de ninguna capa de personalización ni de apps extra: funciona directamente en el núcleo del sistema operativo.
Esta característica gira en torno a una API específica de bloqueo de apps conocida internamente como App Lock, que se integra con el servicio del sistema LauncherApps, responsable de gestionar el lanzador, los iconos y el listado de aplicaciones instaladas. Eso significa que el bloqueo no será un «truco» exclusivo de los Pixel, sino algo que cualquier fabricante o desarrollador de launchers podrá aprovechar de forma estándar en capas como One UI de Samsung o HyperOS de Xiaomi.
La idea de uso es muy sencilla: el usuario elige qué aplicaciones quiere proteger y, al intentar abrirlas, Android exige una autenticación previa. Esa comprobación se hará a través del sistema biométrico habitual del teléfono (huella o reconocimiento facial) o mediante un PIN o contraseña, usando la misma infraestructura de seguridad que protege la pantalla de bloqueo.
Con este enfoque, aplicaciones tan sensibles como la del banco, la galería de fotos, WhatsApp o el correo corporativo seguirán visibles en el escritorio y en el cajón de apps, pero quedarán detrás de una «segunda puerta» que se abre solo con tu huella, tu cara o tu código. No se ocultan ni se mueven a otro perfil, simplemente se blindan para que nadie pueda cotillear cuando prestas el móvil «solo un segundo».
La API LOCK_APPS y el papel de App Lock en Android 17
El hallazgo clave en el código de Android 17 es una nueva estructura de permisos llamada LOCK_APPS, diseñada para gestionar el bloqueo de aplicaciones a nivel de sistema. Esta API define quién puede activar o desactivar el bloqueo y cómo se comunica el lanzador con los servicios de seguridad centrales de Android.
La documentación y el análisis de esas builds tempranas apuntan a que solo las apps de sistema y los lanzadores que tengan el rol HOME (es decir, los que actúan como pantalla de inicio principal) podrán usar esta capacidad. Con ello, Google busca evitar que cualquier herramienta de terceros se apropie del mecanismo y lo utilice de forma abusiva, lo que encaja con su estrategia actual de reforzar la seguridad y reducir permisos excesivos.
Según lo que se ha visto hasta ahora, el flujo de funcionamiento será muy natural: bastará con mantener pulsado el icono de una app compatible en el launcher y, si la función está disponible, aparecerá una opción del tipo “Bloquear aplicación” o similar. En ese momento, el lanzador enviará una solicitud SET_APP_LOCK al servicio central de seguridad de Android para marcar esa app como protegida.
Tras esa solicitud, el sistema mostrará una pantalla de confirmación en la que se preguntará explícitamente si deseas bloquear o desbloquear la aplicación seleccionada. Una vez confirmado, la próxima vez que alguien intente abrirla se desplegará la ventana estándar de Biometric Prompt, pidiendo huella, rostro o PIN, como ocurre al desbloquear el teléfono o autorizar un pago.
Al apoyarse en la API de autenticación biométrica nativa (Biometric Prompt) y en los servicios del sistema, desaparece la necesidad de recurrir a superposiciones de pantalla, accesos a accesibilidad o monitorización constante de lo que ocurre en el dispositivo, algo que era habitual en muchas apps de bloqueo de la Play Store y que consumía batería además de generar dudas de privacidad.
Diferencias con Espacio Privado y otras funciones actuales de Android
Para entender por qué este cambio es tan importante, conviene comparar el futuro App Lock nativo de Android 17 con lo que Google ofrece hoy como solución oficial: el llamado Espacio Privado, introducido en versiones recientes del sistema. A simple vista, ambos conceptos parecen orientados a proteger la privacidad, pero su planteamiento es muy distinto.
El Espacio Privado funciona como un perfil de usuario independiente dentro del propio teléfono, una especie de «sistema operativo dentro del sistema operativo» donde las apps se instalan o se clonan y donde los datos quedan completamente aislados del perfil principal. Es una solución muy robusta para ocultar por completo determinadas aplicaciones y su contenido.
Sin embargo, ese aislamiento tiene un precio: la experiencia de uso resulta bastante más engorrosa para el día a día. No todas las apps del Espacio Privado se integran bien con el resto del sistema, los accesos rápidos son limitados y mover archivos o información entre el espacio principal y el privado puede ser poco fluido, algo que muchos usuarios perciben como un incordio para tareas cotidianas.
El nuevo bloqueo nativo de Android 17 viene a cubrir justo ese hueco intermedio que faltaba: no crea un entorno separado ni oculta por completo las apps, sino que permite seguir utilizándolas en el perfil principal con su icono normal, pero obligando a pasar por una capa extra de autenticación al abrirlas. Es, en esencia, una herramienta pensada para combinar seguridad y comodidad.
Esta diferencia de filosofía se nota en el tipo de uso: Espacio Privado encaja mejor con contenidos que quieres mantener «bajo llave» sin que nadie sospeche siquiera que están ahí, mientras que el bloqueo nativo será ideal para las aplicaciones que abres varias veces al día pero que no quieres dejar a la vista de cualquiera cuando prestas el móvil.
Ventajas frente a las apps de terceros y las soluciones de los fabricantes
Hasta ahora, la ausencia de un bloqueo de apps nativo en Android puro ha llevado a muchos usuarios a depender de aplicaciones de la Play Store dedicadas a bloquear otras apps, con resultados muy dispares. El enfoque habitual de estas herramientas pasaba por superponer una pantalla de bloqueo sobre la aplicación objetivo o por vigilar constantemente qué app se abría en cada momento.
Para funcionar, muchas de estas soluciones de terceros exigían permisos de accesibilidad muy sensibles y capacidad para dibujar sobre otras aplicaciones. En manos de un desarrollador malintencionado, eso puede convertirse en un problema serio: acceso indirecto a lo que se muestra en pantalla, a las pulsaciones o a notificaciones que se consideran privadas. Por eso, iniciativas como la verificación de desarrolladores son relevantes.
Otro punto débil de esas apps de bloqueo era que, en la práctica, bastaba con desinstalarlas para desactivar cualquier protección. Cualquiera con un poco de picardía podía ir a Ajustes, eliminar la app que hacía de «candado» y volver a abrir libremente todo lo que antes estaba protegido.
En paralelo, varias marcas como Xiaomi, Samsung, OnePlus o Realme llevaban años ofreciendo sistemas de bloqueo de aplicaciones integrados en sus propias capas de personalización, ya fuera en forma de carpetas seguras, cajones ocultos o funciones de bloqueo con huella desde el propio lanzador. El problema de este enfoque es que cada fabricante lo resuelve a su manera, sin un estándar común.
Esa falta de homogeneidad provoca que la experiencia de bloqueo de apps cambie radicalmente al cambiar de teléfono. Quien se acostumbra al bloqueo de HyperOS o al Secure Folder de Samsung puede echarlo mucho de menos cuando pasa a un Pixel o a un móvil con Android casi «stock» donde no existe algo equivalente, obligando a volver al ecosistema de apps de terceros.
Con Android 17, la introducción de App Lock y la API LOCK_APPS persigue precisamente homogeneizar este panorama: Google define un estándar de sistema que los lanzadores y las capas de los fabricantes pueden aprovechar, de modo que el mecanismo básico sea similar en cualquier dispositivo, sin depender de inventos paralelos ni parches temporales.
Otro punto a favor es que el nuevo sistema se apoya en la infraestructura de seguridad biométrica ya integrada en Android, lo que evita duplicidades y reduce la necesidad de conceder permisos invasivos a herramientas externas. Y, al estar embebido en el propio sistema, no es posible saltarse el bloqueo simplemente quitando una app de la ecuación.
Cómo funcionará el bloqueo de aplicaciones en el día a día
Las pruebas de las builds Canary dejan entrever un flujo de uso pensado para que el bloqueo sea algo tan natural como organizar iconos o crear carpetas en el escritorio. No se trata de tener que abrir un menú escondido ni navegar entre ajustes enrevesados, sino de integrarlo en los gestos que ya hacemos habitualmente.
Según lo que se ha visto, el primer paso será mantener pulsado el icono de cualquier app en el launcher. Si el sistema admite bloquearla, aparecerá una opción específica en el menú contextual. Al seleccionarla, el lanzador enviará la petición SET_APP_LOCK a los servicios internos de seguridad, que evaluarán si la aplicación es apta para este tipo de protección.
Una vez validada, Android mostrará una ventana de confirmación pidiendo al usuario que indique si quiere bloquear o desbloquear esa app. A partir de ese momento, cada vez que alguien intente abrirla, el sistema invocará la Biometric Prompt estándar para exigir huella, cara o PIN, igual que cuando desbloqueas el móvil tras un reinicio.
Siguiendo la línea de lo que ya ofrece Xiaomi en su App Lock clásico, esta implementación a nivel de sistema debería resultar más eficiente a nivel energético y menos intrusiva que las soluciones de terceros, al no necesitar procesos en segundo plano que estén constantemente monitorizando qué se abre o se cierra.
Además, hay margen para que Google y los fabricantes definan detalles adicionales, como si existirá un tiempo de gracia tras el desbloqueo para no pedir la huella en cada apertura seguida, o si se podrá configurar qué ocurre con las notificaciones de las apps bloqueadas (por ejemplo, ocultar su contenido en la pantalla de bloqueo o en el panel de avisos).
Qué dispositivos podrán usar el bloqueo nativo de apps
El código analizado de Android 17 también deja entrever que Google está poniendo límites claros al alcance de esta función: el bloqueo nativo de aplicaciones se centrará en dispositivos de mano como teléfonos móviles, dejando fuera de momento otras categorías donde los flujos de uso son muy diferentes.
En concreto, las referencias indican que no se activará este mecanismo en sistemas Android para coche, como Android Auto o Android Automotive, donde el foco de diseño pasa más por simplificar la interacción y evitar distracciones al volante que por bloquear apps individuales con huella.
También quedarán fuera los relojes inteligentes con Wear OS, cuyo modelo de interacción y autenticación es mucho más básico, y donde introducir un bloqueo per-app podría resultar poco práctico dada la limitación de tamaño de pantalla y la forma de uso cotidiana.
En la misma línea, las plataformas basadas en Android TV o Google TV tampoco tendrían acceso a esta función, ya que el consumo de contenidos desde el salón tiene otras necesidades de seguridad y normalmente se gestiona con perfiles de usuario y controles parentales más que con bloqueos por aplicación.
Con estas restricciones, Google intenta garantizar que el bloqueo nativo de aplicaciones de Android 17 mantenga un comportamiento coherente y manejable en los dispositivos donde más sentido tiene, evitando complicarse en entornos donde el modelo de interacción es completamente distinto al del móvil que llevamos en el bolsillo.
Calendario previsto y papel de Android 17 en la hoja de ruta de seguridad
A nivel de tiempos, todo apunta a que no veremos este bloqueo nativo completamente operativo hasta el lanzamiento estable de Android 17. Android 16 se encuentra ya en una fase avanzada de desarrollo, y sus actualizaciones QPR (Quarterly Platform Releases) rara vez incorporan APIs de este calibre, por lo que la ventana lógica para App Lock es la siguiente gran versión.
El hecho de que ya existan referencias a LOCK_APPS y al flujo de bloqueo en compilaciones Canary indica que Google está priorizando esta característica dentro de su hoja de ruta de seguridad móvil. No es un experimento aislado, sino una pieza que encaja con su objetivo de reforzar la protección de datos sin complicar en exceso la experiencia de uso.
Para fabricantes como Xiaomi, que llevan años ofreciendo bloqueo de apps integrado desde versiones antiguas de MIUI hasta el actual HyperOS, la llegada de este estándar de sistema puede ser una ventaja. Al alinearse con la implementación nativa de Google, su sistema de bloqueo podría ganar en eficiencia, coherencia y compatibilidad entre dispositivos, en lugar de apoyarse únicamente en sus propias soluciones.
Algo parecido ocurrirá con capas como One UI o las soluciones de seguridad de marcas como Samsung o Motorola, que han ido creando carpetas seguras, espacios aislados y herramientas de protección a medida. Con App Lock sobre la mesa, muchas de estas funciones podrán simplificarse o integrar mejor el bloqueo nativo, ofreciendo una experiencia menos fragmentada al usuario.
En el caso de los teléfonos con Android más «limpio» —como la gama Pixel o algunos modelos de Motorola y Nokia—, la mejora será todavía más visible, porque pasarán de no tener bloqueo nativo de apps a disponer de una solución directa integrada en el sistema, sin necesidad de recurrir ya a parches de terceros ni a Espacio Privado para casos de uso que son mucho más sencillos.
Impacto en la privacidad diaria en España y en Europa
Más allá de lo técnico, la introducción de un bloqueo nativo de apps en Android 17 tiene un impacto muy práctico para millones de personas, especialmente en regiones como la Unión Europea, donde la protección de datos y la privacidad digital son temas de primer orden. No se trata solo de evitar cotillas, sino de mantener a salvo información realmente delicada, y complementarlo con medidas para recuperar tu privacidad en la red.
En el ámbito laboral, muchos profesionales utilizan un solo dispositivo para todo y mezclan apps personales, cuentas de correo corporativo y herramientas de trabajo remoto. Tener la posibilidad de bloquear con huella determinadas aplicaciones sin tener que crear siempre un perfil de trabajo separado puede aliviar bastante la gestión diaria de la seguridad en el móvil.
Dentro de casa, la función puede marcar la diferencia en situaciones muy habituales: padres que dejan el móvil a sus hijos para ver vídeos, amigos que piden el teléfono para hacer una llamada o parejas que usan el mismo dispositivo puntualmente. Bloquear de manera rápida el banco, el correo del trabajo o la carpeta de fotos más privada aporta tranquilidad sin tener que volverse loco configurando usuarios y perfiles.
También es un movimiento importante a nivel de competencia, ya que Apple ha introducido en iOS 18 opciones nativas para bloquear u ocultar aplicaciones, acercando la experiencia de iPhone a lo que muchos usuarios llevaban tiempo pidiendo. Con Android 17, Google recorta esa distancia y ofrece una alternativa sólida para quienes valoran mucho la privacidad pero prefieren seguir en el ecosistema Android.
Para quienes ya usaban trucos como Espacio Privado, carpetas seguras de fabricantes o apps de bloqueo de terceros, el nuevo sistema de Android 17 supone una simplificación del día a día y una mejora en seguridad: menos permisos sospechosos, menos duplicidad de funciones y una protección más difícil de saltarse, todo integrado «de serie» en el propio sistema operativo.
Con todo lo que se sabe hasta ahora, el bloqueo nativo de aplicaciones en Android 17 apunta a convertirse en una de esas funciones discretas pero tremendamente útiles que cambian la forma en que compartimos el móvil y protegemos nuestras apps más sensibles; no es la característica más vistosa de la actualización, pero puede ser la que marque la diferencia cada vez que prestas el teléfono y quieres estar seguro de que ciertos iconos, aunque se vean, solo se abren cuando tú decides.
