StrictMode: qué es, modo de reglas estrictas y depuración en Android

Qué es StrictMode

StrictMode es una API incluida en el SDK de Android desde el nivel de API 9 (Android 2.3 Gingerbread). Su tarea es detectar en tiempo de ejecución la ejecución accidental de operaciones pesadas en el hilo principal (UI) que podrían bloquear el renderizado de la interfaz. El hilo principal maneja el procesamiento de la entrada del usuario, el cálculo del diseño y el renderizado: cualquier bloqueo de más de 16 ms provoca la pérdida de un fotograma.

Filosofía de la herramienta

StrictMode sigue el principio de “fallar rápido”: detectar el problema lo antes posible, idealmente en el momento de su primera aparición. En lugar de esperar las quejas de los usuarios sobre ralentizaciones, el desarrollador recibe una señal (registros, diálogo o crash) directamente en la etapa de desarrollo. La herramienta no requiere bibliotecas adicionales ni configuración de Gradle: basta con unas pocas líneas de código en Application.onCreate, y funciona automáticamente en todos los dispositivos.

Público objetivo

StrictMode está diseñado para todos los desarrolladores de Android, independientemente de su experiencia. Para los principiantes, ayuda a formar buenos hábitos (no hacer solicitudes de red en el hilo de UI); para los experimentados, automatiza el control de calidad en el pipeline de CI/CD. Los proyectos grandes (Google, Uber, Spotify) incluyen StrictMode en las compilaciones de depuración con penaltyDeath, y lo desactivan en las compilaciones de lanzamiento mediante la comprobación de BuildConfig.DEBUG.

Cómo funciona StrictMode

StrictMode intercepta las llamadas al sistema que podrían bloquear el hilo y las compara con el conjunto de políticas activas. Si una llamada coincide con una política y se ejecuta en el hilo principal, StrictMode aplica la penalización especificada. El mecanismo de intercepción se implementa mediante un gancho dentro del proceso: no utiliza reflexión y opera con una sobrecarga mínima.

Mecanismo de detección

Cuando se activa la política de StrictMode, inyecta su manejador en los puntos de entrada de las llamadas al sistema (FileInputStream, FileOutputStream, Socket, URLConnection). Cuando la aplicación llama, por ejemplo, a URLConnection.openStream en el hilo principal, StrictMode comprueba el hilo actual: si es el hilo principal, la herramienta se activa. En Android 6.0+, el mecanismo se mejora: las llamadas de red en el hilo principal generan NetworkOnMainThreadException incluso sin StrictMode, pero StrictMode también permite controlar la E/S de disco.

Penalización

Cada política puede tener su propio tipo de penalización o combinación: penaltyLog — escribe en LogCat con un stack trace, penaltyDialog — muestra un diálogo al usuario (solo en depuración), penaltyDeath — lanza una excepción y causa un crash de la aplicación, penaltyDropBox — guarda datos en DropBoxManager para análisis posterior. Para pipelines de CI/CD, se recomienda penaltyDeath — garantiza que ninguna fusión con violaciones pase desapercibida.

class App : Application() {
    override fun onCreate() {
        super.onCreate()
        if (BuildConfig.DEBUG) {
            StrictMode.setThreadPolicy(
                StrictMode.ThreadPolicy.Builder()
                    .detectDiskReads()
                    .detectDiskWrites()
                    .detectNetwork()
                    .penaltyLog()
                    .penaltyDeath()
                    .build()
            )
        }
    }
}

Políticas de StrictMode

StrictMode divide las políticas en dos niveles: ThreadPolicy (a nivel de hilo — lo que no se puede hacer en el hilo principal) y VmPolicy (máquina virtual — fugas de memoria y recursos). Ambos niveles se configuran de forma independiente y funcionan en paralelo.

ThreadPolicy: Disco y Red

A nivel de hilo, StrictMode controla cuatro tipos de violaciones: lecturas de disco (detectDiskReads), escrituras en disco (detectDiskWrites), operaciones de red (detectNetwork) y llamadas lentas personalizadas (detectCustomSlowCalls). disk_read se activa ante cualquier lectura de SharedPreferences, SQLite o archivos en el hilo principal. network se activa ante solicitudes HTTP, WebSocket y conexiones Socket. En Android 11+, se agregó detectUnbufferedIO para detectar E/S sin búfer.

VmPolicy: Fugas de Memoria

VmPolicy controla las fugas a nivel de la máquina virtual ART: detectActivityLeaks (actividades que no fueron destruidas), detectLeakedClosableObjects (Cursor, Stream, Socket no cerrados), detectLeakedRegistrationObjects (BroadcastReceiver, ServiceConnection no registrados). Si VmPolicy detecta que una Activity fue creada pero no destruida después de llamar a onDestroy, muestra un stack trace completo: ahorra horas de depuración de fugas de memoria.

Llamadas lentas personalizadas

A través de detectCustomSlowCalls, puedes marcar tus propios métodos como “sospechosos” y recibir una advertencia cuando se supere un umbral especificado. Por ejemplo, si tu método loadUserProfile() normalmente toma 5 ms pero a veces toma 200 ms — envuélvelo en StrictMode.noteSlowCall(“loadUserProfile”). Si la duración supera el umbral (por defecto 2000 ms), StrictMode generará una penalización. El umbral se configura mediante setSlowCallDurationThreshold.

Cómo configurar StrictMode

La configuración básica de StrictMode toma 10 líneas de código y se realiza en el método onCreate de una clase Application personalizada. La regla principal: StrictMode se activa solo en compilaciones de depuración — en compilaciones de lanzamiento ralentiza la aplicación y puede crear falsos positivos.

Configuración básica

Crea una clase que extienda Application, regístrala en AndroidManifest.xml mediante el atributo android:name y agrega la configuración de StrictMode. ThreadPolicy.Builder incluye todos los detectores y todos los tipos de penalización (excepto dialog — solo funciona cuando hay un depurador conectado). VmPolicy.Builder agrega detectores para fugas de Activity y objetos Closable. Para proyectos grandes (100+ pantallas), se recomienda configurar VmPolicy con penaltyDeath en el detector de fugas de Activity — es estricto pero efectivo.

class App : Application() {
    override fun onCreate() {
        super.onCreate()
        if (BuildConfig.DEBUG) {
            StrictMode.setVmPolicy(
                StrictMode.VmPolicy.Builder()
                    .detectActivityLeaks()
                    .detectLeakedClosableObjects()
                    .detectLeakedRegistrationObjects()
                    .penaltyLog()
                    .penaltyDeath()
                    .build()
            )
        }
    }
}

Integración en CI/CD

Para el control automático en CI/CD, usa penaltyDeath — si algún test viola la política, la aplicación fallará con una excepción. Combínalo con Android Test Orchestrator para que cada test se ejecute en un proceso limpio. Para tests de UI (Espresso, Compose Test), escribe un TestRule personalizado que intercepte las violaciones de StrictMode y las convierta en fallos de aserción. Ejemplo: en @Before, activa StrictMode, y en @After, comprueba que no hubo violaciones.

Configuración de umbrales

Por defecto, el umbral para customSlowCall es 2000 ms, para disk_read y disk_write — sin umbral (cualquier operación activa). Mediante setSlowCallDurationThreshold y setSlowIoDurationThreshold, puedes establecer tus propios valores en milisegundos. Si tu aplicación lee legítimamente SharedPreferences en el hilo principal (configuración pequeña), aumenta el umbral a 10–20 ms — esto filtrará las lecturas rápidas pero mantendrá las lentas.

Mejores prácticas de StrictMode

StrictMode es una herramienta potente pero delicada. Una configuración incorrecta genera millones de falsos positivos, lo que hace que los desarrolladores dejen de prestarles atención. A continuación, prácticas probadas recopiladas de la experiencia de grandes equipos de Android.

Activar solo en compilaciones de depuración

Esta es una regla estricta: StrictMode NUNCA debe estar activo en compilaciones de lanzamiento. Usa el flag BuildConfig.DEBUG o un buildConfigField personalizado. En compilaciones de lanzamiento, muchas bibliotecas de terceros realizan legítimamente operaciones en el hilo principal (inicialización de SDK, escritura de caché), y StrictMode creará falsos positivos. Además, penaltyDialog en una compilación de lanzamiento mostrará un diálogo al usuario final — lo cual es inaceptable.

Usar tres niveles de rigor

Para proyectos pequeños (1–10 pantallas), configura penaltyLog — los registros son suficientes para el análisis manual. Para proyectos medianos (10–50 pantallas), agrega penaltyDeath en network y customSlowCalls. Para proyectos grandes (50+ pantallas), activa el conjunto completo de políticas con penaltyDeath en CI/CD, y penaltyLog para el desarrollo local. Esta gradación evita sobrecargar a los desarrolladores con falsos crashes mientras controla estrictamente la calidad en el pipeline.

Manejo de falsos positivos

Algunas bibliotecas (Firebase, Crashlytics, Adjust) realizan legítimamente operaciones en segundo plano que StrictMode podría detectar incorrectamente. Soluciones: agrega la biblioteca a una lista blanca mediante penaltyListener, actualiza la biblioteca a una versión con cambio explícito a un hilo en segundo plano, o usa StrictMode.vmPolicy. En Android 11+, se introdujo StrictMode.OnVmViolationListener para el filtrado programático de violaciones por stack trace.

// Filtrado de falsos positivos mediante penaltyListener
StrictMode.setThreadPolicy(
    StrictMode.ThreadPolicy.Builder()
        .detectAll()
        .penaltyListener { violation ->
            val stack = violation.stackTraceToString()
            if ("com.google.firebase" !in stack) {
                logViolation(violation)
            }
        }
        .build()
)

StrictMode vs Android Lint vs Perfiladores

StrictMode no es la única herramienta de control de calidad en el ecosistema Android. Para entender su lugar, comparémosla con Android Lint, Android Profiler y Perfetto según criterios clave: tiempo de comprobación, profundidad de análisis y automatización.

La mejor estrategia es combinar los tres enfoques: Android Lint detecta errores obvios en tiempo de compilación (por ejemplo, un IdleHandler olvidado), StrictMode detecta problemas en tiempo de ejecución, y Android Profiler / Perfetto se usa para análisis profundos cuando las dos primeras herramientas no dan respuestas. En proyectos reales (Google Maps, Instagram), StrictMode se introduce en la segunda semana de desarrollo — justo después de configurar la arquitectura básica.

Ejemplos de código con StrictMode

Veamos dos escenarios reales donde StrictMode ayuda a detectar y solucionar problemas de rendimiento: lectura de SharedPreferences en el hilo principal y fuga de Activity a través de un callback no registrado.

Detección de SharedPreferences lentos

Al iniciar la aplicación, StrictMode con la política detectDiskReads detectará la lectura de SharedPreferences en el hilo principal. Solución: cargar la configuración de forma asíncrona mediante CoroutineScope o almacenarla en caché en memoria al inicio. SharedPreferences lee sincrónicamente un archivo XML del disco — incluso con un archivo pequeño (1–2 KB), la operación toma de 1 a 5 ms, y hasta 20 ms en dispositivos baratos, lo que puede provocar la pérdida de fotogramas.

// ❌ Código problemático — lectura de SharedPrefs en el hilo de UI
class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        // StrictMode detectDiskReads → ¡VIOLACIÓN!
        prefs = getSharedPreferences("config", MODE_PRIVATE)
    }
}

// ✅ Código corregido — lectura mediante Coroutine
class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        loadConfigAsync()
    }
}

Detección de fugas de Activity

StrictMode con VmPolicy.detectActivityLeaks detectará una Activity que ha salido de la pila (se llamó a finish) pero el objeto Activity permanece en memoria debido a una referencia estática o un callback no registrado. Escenario típico: registro de EventBus o LocationListener en onResume sin llamar a unregister en onPause. VmPolicy mostrará un stack trace indicando la línea donde se creó la referencia.

// ❌ Fuga — callback no cancelado
private var locationCallback: LocationCallback? = null

override fun onResume() {
    super.onResume()
    locationCallback = LocationCallback(this::onLocationUpdated)
    locationManager.register(locationCallback) // StrictMode → ¡FUGA!
}

override fun onPause() {
    super.onPause()
    // Olvidaste: locationManager.unregister(locationCallback)
}