Al desarrollar aplicaciones en Android, es común encontrarse con excepciones al intentar mostrar un Dialog utilizando un contexto que no sea una instancia de Activity. Este comportamiento, aunque frustrante al principio, responde a la arquitectura de gestión de ventanas del sistema. A continuación, analizaremos por qué ocurre esto y cómo interactúa el sistema con los Tokens de ventana.

El error común: Uso de Application Context

Si intentamos inicializar un cuadro de diálogo pasando el contexto global de la aplicación (Application Context), el compilador no mostrará errores, pero la aplicación fallará en tiempo de ejecución al invocar el método show().

// Intento erróneo de crear un Dialog con Application Context
Context contextoGlobal = getApplicationContext();
Dialog dialogoFallido = new Dialog(contextoGlobal);

TextView mensaje = new TextView(contextoGlobal);
mensaje.setText("Probando instancia de diálogo");
dialogoFallido.setContentView(mensaje);

// Lanza WindowManager$BadTokenException
dialogoFallido.show();

El registro de errores (Logcat) mostrará una excepción similar a esta:

android.view.WindowManager$BadTokenException: Unable to add window -- token null is not for an application
at android.view.ViewRootImpl.setView(ViewRootImpl.java:517)
at android.view.WindowManagerImpl.addView(WindowManagerImpl.java:301)

Esta traza nos indica que el fallo se origina en ViewRootImpl.setView y está directamente relacionado con la ausencia de un Token válido.

¿Qué es el Token en el sistema Android?

En el ecosistema de Android, un Token es esencialmente un objeto Binder que actúa como una credencial de seguridad y un identificador único. Su propósito es facilitar la comunicación segura entre tres procesos clave:

• ActivityManagerService (AMS): Gestiona el ciclo de vida de los componentes.
• WindowManagerService (WMS): Controla la visualización de las ventanas en pantalla.
• El Proceso de la Aplicación: Donde reside el código de nuestra interfaz.

Cuando una Activity se inicia, el AMS crea un registro (ActivityRecord) y genera un Token asociado. Este Token se comparte con el WMS para que este sepa que existe una ventana autorizada para renderizarse. Cuando la aplicación solicita añadir una ventana (como un Dialog), el WMS verifica si el Token enviado en los LayoutParams coincide con el Token de una Activity registrada y activa. Si el contexto utilizado es el de la aplicación (Application), este no posee un Token de ventana asociado, resultando en el BadTokenException.

Por qué WMS exige un Token vinculado a una Activity

La razón principal es el posicionamiento y la jerarquía. El WMS necesita saber en qué "contenedro" debe colocar la nueva ventana. Sin un Token, el WMS no puede determinar a qué pila de actividades pertenece el diálogo ni cuál es su ventana padre. Los diálogos estándar son ventanas de tipo subordinado (Type Application) y, por diseño, deben estar ancladas a una ventana principal existente.

Existe una excepción: las ventanas de sistema (System Windows). Si se posee el permiso SYSTEM_ALERT_WINDOW y se define el tipo de ventana como TYPE_APPLICATION_OVERLAY, el WMS crea un Token específico en un contenedor global (DisplayArea.Tokens), permitiendo que el diálogo aparezca incluso fuera de una Activity.

Análisis del flujo de creación de un Dialog

Al examinar el constructor de la clase Dialog, observamos cómo se establecen las bases para su renderización:

Dialog(Context context, int themeResId) {
    // 1. Obtiene el WindowManager desde el contexto proporcionado
    mWindowManager = (WindowManager) context.getSystemService(Context.WINDOW_SERVICE);
    
    // 2. Instancia una PhoneWindow propia del diálogo
    Window w = new PhoneWindow(mContext);
    mWindow = w;
    
    // 3. Configura los callbacks para eventos de usuario
    w.setCallback(this);
    
    // 4. Vincula la ventana al WindowManager
    w.setWindowManager(mWindowManager, null, null);
    w.setGravity(Gravity.CENTER);
}

El punto crítico es el paso 4. Si el context es una Activity, el WindowManager recuperado ya contiene la información del Token del padre. Si es el contexto de la aplicación, el WindowManager obtenido es el global del sistema, el cual no tiene la referencia a la ventana actual del usuario, provocando que al llamar a show(), el WMS rechace la petición de añadir una nueva vista (DecorView) a la pantalla.