Android FLAG_SECURE: cómo bloquear las capturas y las grabaciones de pantalla

De vez en cuando uno se topa con un indicador de Android que parece casi magia. FLAG_SECURE es uno de ellos. Al activarlo, su aplicación se vuelve de pronto «imposible de capturar»: la combinación habitual de botones deja de funcionar, las grabaciones de pantalla se ven negras de forma misteriosa y su interfaz desaparece de la vista previa de aplicaciones recientes. Parece una especie de interruptor DRM de alto nivel.

No lo es. En el fondo, FLAG_SECURE es muy simple: es una forma de decirle a Android que «esta ventana concreta es sensible; no permita que se capturen sus píxeles». Eso es todo. Sin cifrado, sin apretones de manos secretos, solo una indicación firme al sistema sobre cómo tratar esa ventana cuando alguien intenta capturar lo que hay en pantalla.

En este artículo repasaremos qué hace FLAG_SECURE en la práctica, cómo funciona conceptualmente, cómo usarlo en el código, dónde tiene sentido activarlo, algunos patrones para utilizarlo sin molestar a los usuarios y las limitaciones que no debe ignorar bajo ningún concepto.

1. Qué hace realmente FLAG_SECURE

Empecemos por lo que la gente ve realmente cuando está activado, porque es ahí donde suelen comenzar las preguntas.

Cuando se establece FLAG_SECURE en una ventana (por ejemplo, en una Activity), Android deja de tratarla como una interfaz normal que admite la captura y la marca como «intocable» para cualquier cosa que quiera obtener píxeles.

El primer efecto que se nota es que las capturas de pantalla quedan bloqueadas. El atajo habitual del sistema (por ejemplo, encendido + bajar volumen) se niega a hacer la captura o genera una imagen completamente negra o en blanco mientras la ventana segura está en primer plano. Desde el punto de vista del usuario, simplemente parece que el dispositivo no puede capturar esa pantalla. Por debajo, Android está siguiendo fielmente la regla: la ventana está marcada como segura, así que los píxeles no salen.

No solo se bloquea la función de captura integrada. La mayoría de las aplicaciones de captura de terceros se encuentran en la misma situación. También dependen de mecanismos a nivel de sistema para capturar lo que hay en pantalla y, cuando solicitan los píxeles de una ventana segura, la plataforma les entrega literalmente nada. El resultado suele ser el mismo: una imagen negra o en blanco, o un fallo directo. Pero tenga presente que utilizar otra cámara para fotografiar la pantalla sigue funcionando.

Pasemos a la grabación de pantalla, donde ocurre algo similar. Los grabadores de pantalla suelen mostrar un área negra en lugar del contenido de su aplicación allí donde se muestra la ventana segura. Se obtiene un vídeo, pero en cualquier punto del fotograma donde aparezca su ventana segura solo hay un rectángulo oscuro. Algunos grabadores aún pueden mostrar la interfaz del sistema u otras ventanas no seguras en los bordes, pero su ventana permanece oculta. Es como abrir un agujero en la grabación justo donde se encuentra el contenido sensible.

Luego está la pantalla de aplicaciones recientes / Overview, la que aparece al deslizar hacia arriba o al pulsar el botón de recientes. Normalmente, Android toma una instantánea de la interfaz de su aplicación y la usa como pequeña tarjeta de vista previa. Con FLAG_SECURE activado, esa instantánea es deliberadamente inútil. En la pantalla Overview / aplicaciones recientes del sistema, Android no mostrará una imagen de su ventana segura. Normalmente aparece como un rectángulo de color liso o negro, lo que evita que la información sensible sea visible cuando la aplicación está en segundo plano o cuando alguien hojea las aplicaciones abiertas por encima del hombro.

Y todo esto tiene un alcance muy deliberado. FLAG_SECURE no bloquea todo el dispositivo ni afecta a todas las aplicaciones. Solo se aplica a la ventana concreta (Activity, Dialog, etc.) en la que se establece. Si no se establece el indicador en otra Activity, esa otra pantalla se comporta con normalidad: las capturas funcionan, las grabaciones funcionan y la vista previa de aplicaciones recientes muestra la interfaz.

En resumen, FLAG_SECURE protege lo que el usuario (u otra aplicación) puede capturar visualmente de su aplicación a través del propio flujo de visualización de Android, pero lo hace por ventana y no como un «modo de privacidad» global.

2. Cómo funciona FLAG_SECURE por dentro

Ahora que hemos visto el comportamiento visible, hablemos de lo que ocurre realmente a nivel conceptual.

La forma más sencilla de pensar en este indicador es como un interruptor de privacidad de una ventana:

• Interruptor activado → Se le indica a Android: «nunca permita que los píxeles de esta ventana salgan del flujo de visualización seguro de forma que puedan capturarse».
• Interruptor desactivado → La ventana se comporta como una normal; se permiten las capturas y las grabaciones.

Por dentro, cuando una ventana tiene FLAG_SECURE establecido, el compositor de Android registra que esa ventana es «segura». Cada vez que se le pide al sistema capturar la pantalla (ya sea mediante la API de capturas, la grabación de pantalla, la generación de la miniatura de tareas recientes o, en algunos escenarios, la transmisión o el reflejo de la pantalla), debe construir una imagen a partir de todas las ventanas visibles. Para las ventanas que no son seguras, copia sus píxeles a la captura sin problema. Para las ventanas que sí son seguras, cualquier intento de capturar la pantalla excluye la ventana segura o la sustituye por un marcador negro o en blanco.

Lo importante es que esto lo impone el sistema, no la lógica de su aplicación. No es necesario interceptar eventos de captura ni intentar adivinar cuándo se está ejecutando un grabador. Una vez establecido el indicador, es Android mismo quien se encarga de que los píxeles de esa ventana no se filtren a capturas, grabaciones ni miniaturas. Otras aplicaciones que intenten ser ingeniosas y usen las API oficiales para capturar la pantalla siguen sujetas a las mismas reglas: solicitan píxeles, el compositor aplica la política de seguridad y su contenido no aparece.

Por eso FLAG_SECURE es razonablemente robusto frente a intentos casuales, e incluso moderadamente decididos, de capturar su interfaz por software. Pero es fundamental tener en cuenta lo que no cubre: solo controla la captura visual a través del flujo de renderizado de Android. No protege mágicamente sus datos en el almacenamiento, en la red ni en ningún otro lugar.

3. Cómo usar FLAG_SECURE en el código

La parte de la implementación es la más fácil. No hay ninguna API secreta ni permisos especiales: solo un indicador en la ventana.

Normalmente se activa en una Activity durante onCreate, antes o alrededor del momento en que se llama a setContentView. En Java, tiene este aspecto:

Cómo usar FLAG_SECURE en Java:

import android.os.Bundle;
import android.view.WindowManager;
import androidx.appcompat.app.AppCompatActivity;

public class SecureActivity extends AppCompatActivity {

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);

        getWindow().setFlags(
            WindowManager.LayoutParams.FLAG_SECURE,
            WindowManager.LayoutParams.FLAG_SECURE
        );

        setContentView(R.layout.activity_secure);
    }
}

Cómo usar FLAG_SECURE en Kotlin:

import android.os.Bundle
import android.view.WindowManager
import androidx.appcompat.app.AppCompatActivity

class SecureActivity : AppCompatActivity() {

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        window.setFlags(
            WindowManager.LayoutParams.FLAG_SECURE,
            WindowManager.LayoutParams.FLAG_SECURE
        )

        setContentView(R.layout.activity_secure)
    }
}

Eso es todo lo que hace falta para que la ventana de esa Activity sea segura mientras siga activa.

A veces, sin embargo, no se quiere que la ventana sea segura todo el tiempo. Quizá una parte de la pantalla sea sensible y otra no, o quizá exista un modo concreto en el que se desee permitir las capturas. En esos casos, puede quitar FLAG_SECURE en tiempo de ejecución cuando ya no sea necesario:

Cómo quitar FLAG_SECURE en tiempo de ejecución cuando ya no es necesario en Kotlin:

window.clearFlags(WindowManager.LayoutParams.FLAG_SECURE)

Cómo quitar FLAG_SECURE en tiempo de ejecución cuando ya no es necesario en Java:

getWindow().clearFlags(WindowManager.LayoutParams.FLAG_SECURE);

Un detalle clave es que FLAG_SECURE es por ventana, no por aplicación. La constante es:

WindowManager.LayoutParams.FLAG_SECURE

No existe ningún ajuste en el manifiesto que lo aplique automáticamente a toda la aplicación. Debe establecerlo (o quitarlo) en cada ventana:

• Cada Activity que desee proteger.
• Cada Dialog o ventana personalizada que deba ser segura.

Es a la vez una ventaja y una trampa: se obtiene un control detallado, pero también hay que asegurarse de cubrir cada superficie sensible.

4. Casos de uso habituales de FLAG_SECURE

Entonces, ¿dónde tiene sentido en el mundo real? La respuesta corta es: en cualquier lugar donde se muestre información que realmente no se quiere que acabe sin más en el archivo de capturas de alguien, en una copia de seguridad en la nube o en un historial de chat.

Repasemos algunas categorías habituales.

4.1 Aplicaciones bancarias y financieras

Las aplicaciones bancarias y financieras son el ejemplo más evidente. Las pantallas que muestran saldos de cuentas, extractos bancarios, historiales de transacciones, números de tarjeta o contraseñas de un solo uso (OTP) están cargadas de datos que son a la vez sensibles y muy reutilizables si caen en manos equivocadas. Si esas vistas permiten capturas sin más, esa información puede acabar en la galería de fotos del usuario, sincronizada con el almacenamiento en la nube o reenviada en una aplicación de mensajería, normalmente sin ningún cifrado ni control de acceso.

Al activar FLAG_SECURE en estas pantallas financieras, se coloca un obstáculo básico en esa vía de fuga. No detiene a quien esté decidido a fotografiar la pantalla con otro dispositivo, pero sí evita muchos de esos momentos casuales de «voy a hacer una captura rápida de esto» que luego se vuelven en contra de las personas.

4.2 Aplicaciones de autenticación y seguridad

Si está creando cualquier cosa relacionada con la autenticación o los secretos (gestores de contraseñas, generadores de 2FA / OTP, flujos de verificación de identidad), FLAG_SECURE debería estar firmemente en su radar.

Estas aplicaciones muestran de forma rutinaria secretos de gran valor: contraseñas, claves de recuperación, códigos de respaldo, códigos de inicio de sesión de corta duración, etc. Si los usuarios pueden capturar esas pantallas, tienden a acabar almacenadas justo en los lugares donde no se quiere que estén: carretes de fotos, galerías en la nube y aplicaciones de notas cualesquiera. A partir de ahí, no hace falta mucho para que se filtren aún más.

Aplicar FLAG_SECURE a las partes de la aplicación que revelan estos secretos significa que el sistema operativo no permite capturarlas de forma trivial. Los usuarios tienen que dar un paso más deliberado, como anotarlos o usar otra cámara, si quieren conservarlos. Eso no resuelve todos los problemas, pero reduce drásticamente la exposición accidental que se produce cuando las capturas se permiten en todas partes.

4.3 Aplicaciones de salud y medicina

Las aplicaciones de salud y medicina forman una categoría especial en la que los datos son extremadamente personales y, en muchas jurisdicciones, están estrictamente regulados.

Las pantallas que muestran historiales médicos personales, resultados de análisis de laboratorio, diagnósticos, detalles de tratamientos o notas detalladas de consultas no son simplemente «algo privadas»; a menudo están sujetas a leyes de privacidad estrictas. Si esas vistas pueden capturarse como imágenes o vídeo y luego respaldarse o compartirse automáticamente, se habrá creado un camino fácil para que datos muy sensibles salgan del control de su aplicación.

Usar FLAG_SECURE en estas vistas ayuda a reducir ese riesgo. No sustituye al cifrado adecuado, a los controles de acceso ni al trabajo de cumplimiento normativo, pero aborda un problema muy concreto: personas que hacen una captura rápida de sus resultados y, sin saberlo, envían esas imágenes a entornos que nunca se diseñaron para la privacidad médica.

4.4 Herramientas empresariales e internas

Dentro de las organizaciones suelen encontrarse paneles internos, consolas de administración y herramientas de depuración que exponen todo tipo de información que nadie quiere ver en Twitter. Piense en métricas internas, datos de clientes, cronologías de incidentes, pantallas de configuración o vistas de registros con identificadores y secretos repartidos por todas partes.

En estos entornos, que los empleados hagan capturas y las compartan internamente puede ser perfectamente normal, hasta que una de esas capturas se filtra fuera de la organización o aparece en un lugar donde no debería estar bajo ningún concepto. Las herramientas de depuración usadas sobre sistemas de producción son especialmente arriesgadas, porque a menudo muestran datos en bruto que nunca estuvieron pensados para ser visibles para el cliente.

Activar FLAG_SECURE en las pantallas de administración y las herramientas internas especialmente sensibles es una forma pragmática de limitar el alcance de ese tipo de comportamiento. Las personas aún pueden documentar lo que hacen, pero ya no resulta tan sencillo capturar y distribuir copias exactas, píxel por píxel, de sus interfaces internas más sensibles.

4.5 Comunicación crítica para la privacidad y escenarios de quiosco

También hay toda una clase de aplicaciones en las que la sensibilidad tiene más que ver con cómo las usan las personas que con el dominio concreto. La mensajería segura, los chats efímeros y los mensajes autodestructivos son buenos ejemplos.

Si se anuncia que «este mensaje desaparece» pero la interfaz se puede capturar sin esfuerzo, la experiencia y la expectativa no están alineadas. No se puede impedir que alguien apunte otro teléfono a la pantalla, pero al menos se puede evitar respaldar la vía de captura integrada y fácil. Marcar esas conversaciones especiales con FLAG_SECURE envía una señal bastante clara: esto no está pensado para vivir para siempre en la galería de fotos.

Las aplicaciones tipo quiosco son otro caso interesante. Piense en terminales de registro, sistemas de turnos, formularios de autoservicio o cualquier dispositivo compartido al que las personas se acercan para usarlo en espacios semipúblicos. A menudo, esas pantallas muestran brevemente nombres, identificaciones, datos de reservas u otros datos personales. Al activar FLAG_SECURE en esos flujos, resulta mucho más difícil que usuarios oportunistas, o software malicioso que se ejecute en el dispositivo, recopilen discretamente lo que se muestra en pantalla.

5. Patrones de diseño: dónde y cuándo activarlo

Esparcir FLAG_SECURE al azar por la aplicación no es una estrategia. Conviene recurrir a patrones deliberados que equilibren la seguridad y la usabilidad.

Un patrón sencillo es la Activity «siempre segura». En ciertas pantallas, todo lo que se muestra es sensible. Ejemplos clásicos son algo como OtpVerificationActivity o CardDetailsActivity. En ellas, basta con establecer FLAG_SECURE en onCreate y no quitarlo nunca. Cada vez que el usuario llegue a esa Activity, las capturas y las grabaciones quedan descartadas, sin excepciones.

Un patrón más matizado es la alternancia según el estado. Imagine una única MainActivity que normalmente muestra contenido inofensivo, pero que a veces revela un panel de «Detalles sensibles», por ejemplo una hoja inferior con números de cuenta completos. Mientras ese panel está oculto, no hay motivo para bloquear las capturas. En cuanto se muestra, se activa el indicador; cuando se cierra, se vuelve a desactivar. En Kotlin, podría verse así:

fun showSensitiveContent() {
    window.setFlags(
        WindowManager.LayoutParams.FLAG_SECURE,
        WindowManager.LayoutParams.FLAG_SECURE
    )
    // Show a fragment or view containing sensitive data
}

fun hideSensitiveContent() {
    window.clearFlags(WindowManager.LayoutParams.FLAG_SECURE)
    // Hide that fragment or view
}

Este patrón ofrece lo mejor de ambos mundos: las personas aún pueden capturar la interfaz genérica, pero los momentos realmente sensibles quedan protegidos.

Después está el enfoque del contenido seguro solo en diálogos. A veces, lo único sensible de todo el flujo es un diálogo transitorio, por ejemplo una ventana emergente que revela un número de tarjeta completo, una frase de recuperación o un secreto de un solo uso. En esos casos, puede tener sentido establecer FLAG_SECURE en la ventana propia del diálogo en lugar de en toda la Activity. La pantalla base sigue permitiendo capturas, pero el contenido del diálogo nunca aparece en ellas.

Sea cual sea el patrón elegido, lo esencial es ser coherente: definir qué pantallas o estados se consideran sensibles, aplicar FLAG_SECURE ahí y dejar todo lo demás intacto. De ese modo no se sorprende a los usuarios de forma aleatoria y se aplica el indicador exactamente donde más reduce el riesgo.

6. Limitaciones y malentendidos

Ahora viene la parte que es tan importante como las funciones: lo que FLAG_SECURE no hace.

Lo principal: no bloquea cámaras ni dispositivos externos. Un usuario puede apuntar otro teléfono, una cámara réflex, una webcam o lo que prefiera a la pantalla y capturarla. FLAG_SECURE solo controla la captura basada en software dentro de Android. Si su modelo de amenazas incluye a alguien que esté físicamente presente fotografiando el dispositivo, este indicador no le sirve de ayuda.

Además, FLAG_SECURE no cifra ni protege de ningún otro modo sus datos. Protege la visualización, pero no:

• La comunicación de red
• El almacenamiento en disco
• Los registros, cachés o copias de seguridad

Si envía datos sensibles por la red, sigue necesitando HTTPS (y sigue necesitando validar correctamente los certificados). Si almacena secretos en disco, sigue necesitando mecanismos de cifrado como bases de datos cifradas o EncryptedSharedPreferences. Si registra valores sensibles en los logs, FLAG_SECURE no le salvará cuando esos registros se envíen a un servidor central.

También está el problema del alcance. Como el indicador es por ventana y no global, es muy fácil proteger una ruta y olvidar otra. Si sus datos sensibles también son accesibles desde otra Activity o vista que no establece FLAG_SECURE, esa otra pantalla sí puede capturarse. Hay que pensar en términos de «todos los lugares donde aparece esta información» y no de «esta única pantalla».

Otro punto sutil: FLAG_SECURE no protege retroactivamente las capturas anteriores. Las capturas o grabaciones realizadas antes de activar el indicador no se ven afectadas. Permanecen donde el usuario las haya almacenado: la galería local, la copia de seguridad en la nube o una aplicación de mensajería. El indicador solo se aplica a los intentos de captura mientras está activo.

Por último, hay compromisos en la experiencia de usuario. Algunos usuarios dependen mucho de las capturas para informar de errores, guardar instrucciones o documentar flujos de trabajo. Cuando se bloquean las capturas en lugares que no perciben como especialmente sensibles, se los frustra. El uso excesivo de FLAG_SECURE puede dar la impresión de que su aplicación está innecesariamente restringida, sobre todo si no se explica con claridad por qué no se permite una captura.

La conclusión: FLAG_SECURE es una herramienta específica que resuelve muy bien un problema concreto. No es una bala de plata. Sigue siendo necesario un diseño de seguridad real a su alrededor.

7. Interacciones con la transmisión de pantalla y las pantallas externas

Un último detalle que a menudo sorprende: cómo se comporta FLAG_SECURE cuando se transmite o se refleja la pantalla.

Según la versión de Android y el dispositivo, el contenido marcado con FLAG_SECURE puede no aparecer en absoluto en ciertas pantallas externas. Si el sistema considera que la pantalla externa es «no segura» (por ejemplo, algunos destinos de transmisión o pantallas reflejadas), aplica esencialmente la misma lógica que para las capturas y las grabaciones.

En la práctica, esto significa que durante las sesiones de reflejo o transmisión de pantalla:

• Las ventanas seguras pueden aparecer como un área en blanco o negra en la pantalla remota.
• La interfaz no segura y el marco del sistema pueden seguir siendo visibles.
• Su aplicación puede parecer que «le falta» parte de su interfaz en la salida transmitida siempre que haya una ventana segura al frente.

Este comportamiento coincide con la redacción que a veces se ve en la documentación: «Impide que el contenido de la ventana aparezca en las capturas de pantalla o que se vea en pantallas no seguras». «Pantallas no seguras» es aquí una forma abreviada de referirse a las salidas en las que Android no confía plenamente para imponer las mismas garantías que puede ofrecer en la pantalla principal del dispositivo.

Si su aplicación se utiliza mucho en presentaciones, demostraciones o escenarios de asistencia remota, conviene probar cómo se comportan sus pantallas seguras al transmitir y decidir si eso es aceptable. En algunos casos, puede ser necesario ofrecer flujos alternativos para esas situaciones o, al menos, un mensaje amable que explique por qué no se puede compartir la pantalla.

8. Resumen

FLAG_SECURE (WindowManager.LayoutParams.FLAG_SECURE) es un indicador de ventana de Android que dice: «no permita que se capturen los píxeles de esta ventana». Una vez establecido en una ventana, impide que funcionen las capturas de pantalla estándar, hace que las grabaciones de pantalla muestren negro donde aparece esa ventana, oculta las miniaturas significativas en la vista de aplicaciones recientes e incluso puede evitar que el contenido aparezca en ciertas pantallas externas.

Se usa estableciendo el indicador en las ventanas que importan (normalmente Activities o Dialogs concretos) y, si es necesario, quitándolo de nuevo cuando la interfaz ya no muestra datos sensibles:

window.setFlags(
    WindowManager.LayoutParams.FLAG_SECURE,
    WindowManager.LayoutParams.FLAG_SECURE
)

// Later, if needed:
window.clearFlags(WindowManager.LayoutParams.FLAG_SECURE)

Conviene plantearse su uso en pantallas que muestren información verdaderamente sensible o regulada: datos bancarios, secretos de autenticación, datos de salud, paneles internos, chats críticos para la privacidad, flujos de quiosco y casos similares. Pero también debe tener muy claro lo que no hace: no detiene las cámaras, no cifra nada, no se aplica globalmente a menos que usted lo haga y no limpia las capturas anteriores.

Usado con criterio, FLAG_SECURE es una forma muy práctica de cerrar una fuga concreta y muy común: los píxeles que salen de su aplicación mediante capturas y grabaciones de pantalla. No es toda la historia de la seguridad en Android, pero para las pantallas adecuadas es una historia que sin duda querrá contar.