Demasiadas clases en main main-dex-list, la capacidad principal dex excedida

Primero entendamos el problema:

En dispositivos pre-Lollipop, el framework solo carga main dex. Para soportar aplicaciones multi-dex, debe parchear explícitamente application class loader con todos los archivos secundarios dex (esta es la razón por la que su clase de aplicación tiene que extender MultiDexApplication class o llamar MultiDex#install).

Esto significa que el dex principal de su aplicación debe contener todas las clases que son potencialmente accesibles antes de parchear el cargador de clases.

Recibirá java.lang.ClassNotFoundException si el código de su aplicación intentará hacer referencia a una clase que se empaquetó en uno de sus archivos dex secundarios antes de parchear con éxito el cargador de clases de la aplicación.

He documentado aquí cómo el plugin decide qué clases deben empaquetarse en main-dex.
Si la cantidad total de métodos a los que hacen referencia esas clases excede el límite de 65,536, entonces la compilación fallará con Too many classes in --main-dex-list, main dex capacity exceeded error.

Se me ocurren tres posibles soluciones para este problema:

1. (La solución más fácil, pero no adecuada para la mayoría de los aplicaciones) Cambie su minSdkVersion a 21.
2. Reduzca el código de su aplicación. Esto fue discutido muchas veces anteriormente (ver aquí y aquí).
3. Si ninguna de las soluciones anteriores funciona para usted, puede intentar usar mi solución para este problema : estoy parcheando el gradle de Android plugin para no incluir clases de actividad en dex principal. Es un poco raro, pero funciona bien para mí.

Hay un problema en Android bug Tracker con respecto a este error. Esperamos que el equipo de Herramientas proporcione una mejor solución pronto.

Actualizar (4/27/2016)

La versión 2.1.0 del complemento Gradle permite filtrar las clases de la lista main-dex.
Advertencia: esto está utilizando una api no compatible que se reemplazará en el futuro.

Para ejemplo, para excluir todas las clases de actividad puedes hacer:

afterEvaluate {
  project.tasks.each { task ->
    if (task.name.startsWith('collect') && task.name.endsWith('MultiDexComponents')) {
      println "main-dex-filter: found task $task.name"
      task.filter { name, attrs ->
        def componentName = attrs.get('android:name')
        if ('activity'.equals(name)) {
          println "main-dex-filter: skipping, detected activity [$componentName]"
          return false
        } else {
          println "main-dex-filter: keeping, detected $name [$componentName]"
          return true
        }
      }
    }
  }
}

También puede comprobar mi proyecto de ejemplo que demuestra este problema (y aplica el filtrado anterior).

Actualizar 2 (7/1/2016)

La versión 2.2.0-alpha4 del complemento Gradle (con build-tools v24) finalmente resuelve este problema al reducir la lista de mantenimiento multidex a un mínimo .
El filtro no soportado (e indocumentado) de la versión 2.1.0 ya no debería usarse. He actualizado mi proyecto de ejemplo, que demuestra que la compilación tiene éxito ahora sin ninguna lógica de compilación personalizada.